Par Tsuky 
Un agent d'intelligence artificielle peut avoir besoin d'effectuer des dizaines de choix avant de terminer une seule tâche.
Il doit déterminer quel outil utiliser, savoir si une information est pertinente, décider si une opération présente un risque ou choisir à quel service transmettre une demande.
Ces décisions ne nécessitent pas toujours un raisonnement long ni la génération d'un texte complet.
Pourtant, les applications utilisent fréquemment des modèles conversationnels généralistes pour effectuer ces opérations. Chaque appel ajoute de la latence et consomme des ressources informatiques.
OpenAI veut modifier cette organisation avec sa Decisions API.
Le service est disponible généralement depuis le 22 octobre 2026, après une première présentation lors de DevDay et une bêta publique lancée le 6 octobre.
Son principe consiste à demander à GPT-6 Luna de produire une réponse limitée à un ensemble de résultats définis à l'avance, plutôt que de générer librement plusieurs phrases.
Le modèle analyse toujours le contexte fourni. Ce qui change, c'est la forme de la réponse et l'optimisation du traitement.
Une API pour choisir plutôt que rédiger
Dans la Responses API, un développeur peut demander à un modèle de rédiger une analyse, produire du code, construire une réponse structurée ou utiliser des outils.
La Decisions API vise des besoins plus restreints.
Le développeur définit une question, précise les réponses possibles et transmet les éléments nécessaires pour effectuer le choix.
Ces éléments peuvent comprendre du texte, des images ou des données JSON.
L'API produit ensuite une réponse spécialisée que l'application peut directement exploiter.
Imaginons une entreprise recevant des milliers de demandes de support.
Le système doit déterminer si chaque message relève de la facturation, d'un problème technique, d'une livraison ou d'une autre catégorie.
Un modèle conversationnel pourrait rédiger une explication pour chaque demande. Mais si l'application attend seulement un nom de catégorie, cette génération supplémentaire n'apporte pas nécessairement de valeur.
Avec Decisions, le développeur peut définir les quatre catégories autorisées et récupérer directement celle que le modèle sélectionne.
L'application décide ensuite de l'action à réaliser.
Cette séparation entre analyse du contexte et production d'une réponse longue constitue la logique centrale de la nouvelle interface.
Trois types de décisions, trois usages différents
OpenAI propose trois formes de réponses.
La première, predicate, permet d'évaluer la probabilité qu'une condition soit vraie.
Un commerce peut par exemple analyser une photographie pour déterminer si un produit présente des dommages visibles.
Le système renvoie une estimation de probabilité comprise entre zéro et un.
Cette valeur ne constitue pas une certitude mathématique. Elle représente l'estimation produite par le modèle à partir des informations disponibles.
La deuxième forme, choice, consiste à sélectionner une réponse parmi plusieurs options prédéfinies.
Elle convient notamment au classement des messages, au routage des demandes et au choix de l'étape suivante dans un workflow.
Le troisième type, score, évalue une entrée selon une échelle ordonnée.
Un développeur peut définir différents niveaux de gravité pour des incidents techniques, allant d'un défaut cosmétique à une interruption complète de service.
L'API renvoie un score calculé à partir des probabilités attribuées aux niveaux disponibles.
Le résultat peut donc se situer entre deux niveaux.
Ces trois catégories couvrent de nombreux besoins courants, mais elles ne remplacent pas une génération complexe de documents ou d'objets JSON personnalisés.
Pourquoi OpenAI annonce une accélération pouvant atteindre dix fois
OpenAI affirme que la Decisions API peut prendre certaines décisions jusqu'à dix fois plus rapidement que GPT-6 Luna utilisé par la Responses API.
La comparaison porte sur deux manières d'utiliser la même famille de modèles, et non sur une affirmation selon laquelle GPT-6 Luna serait devenu dix fois plus intelligent.
Une réponse conversationnelle peut nécessiter la production successive de nombreux tokens.
Lorsque l'application attend seulement une sélection parmi plusieurs catégories ou une probabilité, une interface spécialisée peut éviter une partie du travail nécessaire à une réponse textuelle classique.
La réduction du temps de traitement devient particulièrement importante lorsqu'un agent enchaîne plusieurs décisions.
Une différence de quelques centaines de millisecondes peut sembler négligeable pour une opération isolée.
Répétée au cours de dizaines d'étapes, elle peut modifier sensiblement le temps total nécessaire pour accomplir une tâche.
Toutefois, le facteur dix annoncé par OpenAI constitue une performance pouvant être atteinte dans certaines conditions.
La latence réelle dépend notamment de la quantité de contexte, du nombre de questions, des caractéristiques de l'entrée et des conditions de traitement.
Un développeur ne doit donc pas supposer que toutes ses applications deviendront automatiquement dix fois plus rapides.
0,10 dollar par million de tokens d'entrée
L'autre argument central de la Decisions API est son prix.
OpenAI annonce un tarif standard de 0,10 dollar par million de tokens d'entrée.
Lorsqu'un contexte déjà traité peut être réutilisé à travers le mécanisme de cache, le prix annoncé pour les lectures correspondantes descend à 0,01 dollar par million de tokens.
Aucun coût par token de sortie n'est facturé.
Cette tarification correspond à la logique d'une API qui renvoie des réponses bornées plutôt que de longs textes générés.
Elle ne signifie pas que chaque appel est gratuit.
L'application reste facturée pour les tokens d'entrée traités selon les conditions applicables.
Certaines options, notamment le traitement régional et les durées particulières de conservation du cache, peuvent entraîner des modalités tarifaires supplémentaires.
Il faut également distinguer le coût de cette API de celui des autres composants d'un agent.
Si une application utilise Decisions pour choisir un outil puis sollicite un autre modèle pour rédiger une réponse complexe, ce second appel conserve sa propre facturation.
La réduction des coûts dépend donc de la proportion de tâches qui peuvent réellement être transférées vers la nouvelle interface.
Jusqu'à 400 questions dans une seule requête
La disponibilité générale s'accompagne de nouvelles capacités.
La Decisions API permet désormais de soumettre jusqu'à 400 questions par requête, contre 200 précédemment.
Les questions peuvent partager un même contexte.
Une entreprise pourrait par exemple analyser une photographie de produit pour vérifier sa catégorie, rechercher des dommages visibles et évaluer différents critères de qualité.
Plutôt que d'envoyer plusieurs fois la même image à travers des appels indépendants, elle peut regrouper certaines évaluations.
Cette organisation peut faciliter le traitement de volumes importants.
Elle présente cependant une limite importante.
La documentation recommande de regrouper les questions indépendantes.
Lorsqu'une décision dépend du résultat d'une question précédente, il faut organiser les appels successivement.
Par exemple, une application peut d'abord décider si un objet est endommagé, puis choisir un type de réparation uniquement lorsque la première réponse le justifie.
Le regroupement de 400 questions n'est donc pas équivalent à l'exécution automatique d'un workflow comportant 400 étapes interdépendantes.
Une intégration native avec GPT-Live pour les applications vocales
OpenAI ajoute également une intégration native entre Decisions et GPT-Live.
L'objectif est de permettre aux applications vocales de choisir une action pendant qu'un utilisateur parle ou au cours de la réponse d'un assistant.
La fluidité des conversations vocales dépend fortement de la rapidité avec laquelle le système comprend ce qu'il doit faire ensuite.
Si un assistant doit interroger un modèle généraliste pour chaque décision simple, les délais cumulés peuvent nuire à la qualité de l'échange.
Decisions peut intervenir pour sélectionner rapidement une action, classer une demande ou déterminer la prochaine étape.
OpenAI cite notamment Speak, une application destinée à l'apprentissage des langues.
Selon Andrew Hsu, directeur technique de Speak, l'intégration de Decisions à GPT-Live a permis, dans les tests de l'entreprise, de réduire le délai avant l'action suivante de 1,4 seconde à 0,13 seconde.
La baisse dépasse 90 % dans ce scénario.
Ce résultat concerne l'environnement et les mesures rapportés par Speak.
Il ne constitue pas une garantie de latence pour toutes les conversations vocales utilisant GPT-Live.
L'intérêt du mécanisme est néanmoins évident : rendre une interaction plus réactive lorsque plusieurs petites décisions sont nécessaires à la continuité d'une conversation.
Box, Datadog et Ramp présentent leurs premiers résultats
OpenAI accompagne son annonce de plusieurs exemples d'entreprises ayant expérimenté la Decisions API.
Box utilise notamment l'interface pour classer des documents professionnels et déterminer leur destination dans différents processus.
Dans une évaluation portant sur 30 certificats d'assurance, Box annonce un choix de routage environ cinq fois plus rapide que son approche fondée sur la Responses API, avec une précision comparable.
Cette expérience concerne un échantillon limité et un cas d'usage précis.
Datadog utilise de son côté Decisions pour évaluer le risque de certaines commandes générées par des agents avant leur exécution dans des procédures de remédiation.
L'entreprise affirme avoir obtenu une latence au 95e percentile quarante fois inférieure à celle de modèles frontier disponibles, pour une précision comparable.
Cette comparaison est rapportée par Datadog dans la communication d'OpenAI. Les modèles exacts et les conditions complètes du test ne sont pas présentés comme un benchmark indépendant généralisable.
Ramp rapporte une autre application : attribuer les dépenses d'intelligence artificielle aux tâches qui les ont réellement provoquées.
La société annonce une opération quatre fois plus rapide et 30 % moins chère qu'avec GPT-6 Luna dans son approche précédente, sans dégradation de précision observée pendant son évaluation.
Ces exemples montrent la diversité des usages envisagés.
Ils illustrent également la difficulté d'établir une comparaison universelle : chaque entreprise mesure une tâche, un environnement et un point de référence différents.
Sierra utilise Decisions pendant les conversations clients
La société Sierra constitue un autre exemple intéressant.
Elle utilise la Decisions API pour choisir certaines actions au cours de conversations avec des clients.
Selon son témoignage, ces décisions sont traitées en moins de 280 millisecondes au 95e percentile.
Sierra annonce également une exécution environ trois fois plus rapide et un coût par appel réduit de 90 % par rapport à son approche précédente.
L'entreprise précise ne pas avoir observé de dégradation des résultats clients dans cette comparaison.
Là encore, il s'agit de mesures communiquées par un utilisateur de la technologie.
Il serait incorrect de conclure que la Decisions API réduit systématiquement de 90 % le coût de tous les agents conversationnels.
Les économies dépendent du travail effectivement délégué à l'interface spécialisée.
Une conversation nécessitant principalement la rédaction de réponses détaillées continuera de mobiliser d'autres capacités de génération.
En revanche, les étapes intermédiaires de classification et de sélection d'actions constituent un terrain particulièrement adapté à cette nouvelle API.
Pourquoi la confiance affichée par le modèle ne suffit pas
Les réponses structurées de Decisions peuvent inclure des probabilités et des indicateurs de confiance.
Ces valeurs sont utiles pour concevoir des systèmes qui orientent les cas incertains vers un examen humain.
Elles ne doivent pas être traitées comme une garantie de justesse.
Une décision peut être erronée même lorsque le modèle lui attribue une probabilité élevée.
Inversement, un résultat apparemment incertain peut être suffisant pour une opération dont les conséquences sont faibles.
OpenAI recommande d'utiliser des exemples représentatifs afin de déterminer les seuils appropriés.
Pour une simple classification de documents, une entreprise peut accepter qu'une partie des cas soit corrigée ultérieurement.
Pour une décision autorisant l'exécution d'une commande sur un serveur, le niveau d'exigence doit être beaucoup plus élevé.
Le coût des faux positifs et des faux négatifs détermine les précautions nécessaires.
Une API rapide ne dispense donc pas de tests, d'évaluations et de protections indépendantes.
Décider vite ne signifie pas autoriser toutes les actions
La Decisions API pourrait devenir un composant central de nombreux systèmes d'agents.
Mais elle ne doit pas être confondue avec un mécanisme complet d'autorisation ou de sécurité.
Un résultat indiquant qu'une action semble acceptable ne remplace pas les permissions imposées par le système informatique.
Une application qui utilise Decisions pour sélectionner une commande doit encore vérifier que celle-ci respecte les droits de son utilisateur.
Les opérations financières, les modifications de données sensibles et les actions irréversibles peuvent également nécessiter une confirmation humaine.
La vitesse du système augmente l'importance de cette séparation.
Si un agent peut enchaîner des décisions en quelques centaines de millisecondes, une erreur répétée peut produire rapidement plusieurs actions problématiques.
Il reste donc nécessaire de conserver des mécanismes de limitation, de journalisation et de contrôle des permissions.
L'API fournit une estimation ou un choix ; elle ne détermine pas à elle seule les droits effectifs d'un agent.
Le traitement régional arrive aux États-Unis et en Europe
OpenAI annonce également des possibilités de traitement régional aux États-Unis et dans l'Union européenne.
Cette évolution peut intéresser les entreprises qui imposent certaines contraintes géographiques au traitement de leurs données.
Les applications peuvent aussi bénéficier de capacités supplémentaires dans plusieurs régions d'Asie afin de réduire certains délais liés à l'infrastructure.
OpenAI précise que la Decisions API peut être utilisée avec les mécanismes de Zero Data Retention lorsque les clients remplissent les critères d'éligibilité.
Cette disponibilité ne signifie pas que toutes les organisations bénéficient automatiquement des mêmes conditions de résidence et de conservation.
Les développeurs doivent vérifier les options de traitement, les exigences contractuelles et les paramètres applicables à leur compte.
La présence d'une région européenne de traitement ne constitue pas, à elle seule, une certification générale de conformité réglementaire pour chaque application.
Les obligations dépendent aussi de la nature des données transmises, des usages et des autres fournisseurs impliqués dans le workflow.
Responses API et Decisions API sont complémentaires
Le lancement ne signifie pas qu'OpenAI souhaite remplacer entièrement la Responses API.
Les deux interfaces répondent à des besoins différents.
La Responses API reste adaptée à la génération libre, à la production de réponses complexes et aux interactions avancées avec les outils.
Elle permet également d'utiliser des Structured Outputs lorsqu'une application nécessite un objet JSON respectant un schéma personnalisé.
Decisions privilégie les réponses bornées : probabilité, sélection ou score.
Un agent peut donc combiner les deux.
Il peut utiliser Decisions pour choisir le prochain outil, puis solliciter la Responses API pour réaliser une analyse approfondie ou produire une réponse destinée à l'utilisateur.
Cette spécialisation pourrait contribuer à rendre les architectures agentiques plus efficaces.
Elle implique toutefois une conception plus fine des workflows.
Les développeurs doivent déterminer quelles tâches justifient un modèle généraliste et lesquelles peuvent être résolues par une décision spécialisée.
Cette organisation n'est pas nécessairement plus simple qu'un système reposant sur un seul modèle, mais elle peut apporter un meilleur équilibre entre coût, latence et flexibilité.
Un nouveau marché pour les décisions intermédiaires
L'intérêt stratégique de la Decisions API dépasse les exemples de classification.
À mesure que les logiciels utilisent davantage d'agents, les choix intermédiaires représentent une partie croissante de leur fonctionnement.
Un agent peut avoir besoin de décider quand demander une confirmation, quel modèle utiliser, quelle information rechercher ou vers quelle équipe transmettre un problème.
Ces opérations sont souvent moins complexes que la tâche finale.
Les traiter systématiquement avec un grand modèle conversationnel peut augmenter les délais et les coûts.
OpenAI propose donc de séparer deux fonctions : produire un contenu élaboré et sélectionner rapidement une action.
Cette séparation répond à une difficulté concrète de l'industrie des agents autonomes.
Le coût d'un agent ne dépend pas seulement des réponses qu'il rédige, mais aussi du nombre d'opérations nécessaires pour arriver à cette réponse.
Réduire le coût et la latence de ces opérations intermédiaires pourrait améliorer l'économie de nombreuses applications.
Mais les bénéfices réels dépendront des charges de travail et de la qualité des décisions produites.
Une disponibilité confirmée, des performances à mesurer selon les usages
Au 23 octobre 2026, la Decisions API est officiellement disponible généralement avec GPT-6 Luna.
Les développeurs peuvent l'utiliser à travers l'endpoint dédié et expérimenter leurs questions dans le Decisions Playground.
Les nouvelles capacités comprennent l'intégration GPT-Live, le cache de contexte, les entrées JSON, les images et la prise en charge de 400 questions par requête.
OpenAI annonce une vitesse pouvant atteindre dix fois celle de Luna via la Responses API.
Les résultats communiqués par Box, Datadog, Ramp, Sierra et Speak indiquent des gains importants dans des contextes particuliers, sans constituer un benchmark indépendant universel.
La véritable mesure de réussite sera la capacité des développeurs à transférer les bonnes tâches vers cette interface sans dégrader la précision ni les protections de leurs applications.
Le lancement illustre une évolution de l'industrie : rendre les agents plus utiles ne consiste plus seulement à améliorer la qualité des modèles, mais aussi à réduire le prix et le temps nécessaires à chacune de leurs décisions.