Le 22 octobre 2026, OpenAI a rendu l'API Decisions disponible pour tous les développeurs (disponibilité générale, GA). Présentée en beta publique le 6 octobre, cette API introduit un nouveau type d'endpoint dans l'écosystème OpenAI : au lieu de générer une réponse texte complète, le modèle répond à une série de questions structurées — probabilité, choix parmi des options, ou score sur une rubrique — en une seule requête, beaucoup plus rapidement et à un coût significativement inférieur aux appels classiques.
Pour les équipes qui construisent des applications IA ou des agents, cette API comble un manque concret : celui d'un mécanisme de décision léger et rapide pour les cas où l'on n'a pas besoin de texte généré, mais seulement d'une réponse binaire ou catégorielle. Classifier un contenu, router une requête vers le bon agent, scorer une priorité dans une file d'attente — autant de besoins que l'API Decisions traite sans générer de texte superflu.
Cet article explique le fonctionnement technique de l'API, sa tarification, les entreprises qui l'ont adoptée en beta, et les cas où elle apporte une valeur réelle dans une architecture d'agent IA connecté aux données de l'entreprise.
Comment fonctionne l'API Decisions ?
L'endpoint est POST /v1/decisions. Une requête contient trois éléments principaux :
- Un système (instructions générales sur le contexte et les règles d'évaluation) ;
- Un contexte (le texte, les images ou le JSON à analyser) ;
- Une liste de questions typées, jusqu'à 400 depuis la GA (contre 200 en beta).
Chaque question est d'un des trois types suivants :
- Probability : quelle est la probabilité que cette condition soit vraie ? (retourne un float entre 0 et 1) ;
- Choice : parmi ces options, laquelle correspond le mieux au contexte ? (retourne l'option sélectionnée) ;
- Score : évalue cet élément selon cette rubrique sur une échelle donnée (retourne un entier).
Le modèle retourne uniquement les réponses typées, sans générer de texte libre. Il n'y a pas de tokens de sortie à proprement parler — c'est ce qui explique la rapidité et la faible consommation de l'API. Depuis la GA, il est également possible de passer des entrées JSON natives et d'inclure des images dans les instructions de chaque question.
Cette approche est particulièrement adaptée aux patterns d'architecture d'agents pérennes où l'on souhaite séparer les décisions de routing (rapides, peu coûteuses) de la génération de réponses (plus lentes, plus coûteuses).
Tarification et modèle supporté
Au 22 octobre 2026, un seul modèle est disponible via l'API Decisions : gpt-6-luna. La tarification est la suivante :
- 0,10 $ par million de tokens d'entrée (input uniquement) ;
- Tokens de sortie non facturés — la réponse est typée et ne génère pas de texte comptabilisé en output ;
- Cache des prompts actif par défaut depuis la GA, avec réduction appliquée sur les hits.
À titre de comparaison, un appel classique à gpt-6-luna via l'API Responses coûte environ 1,25 $ par million de tokens d'entrée — soit 12,5 fois plus cher que l'API Decisions pour une classification équivalente. La différence de vitesse annoncée par OpenAI est jusqu'à 10 fois plus rapide en latence, ce qui est décisif pour les usages temps réel ou à fort volume.
Pour les équipes qui développent des applications à développement sur mesure, ce ratio coût/performance est un argument solide pour intégrer l'API Decisions dans les pipelines de classification ou de routing, plutôt que de multiplier les appels complets.
OpenAI précise également que la résidence des données en Europe est disponible pour les clients éligibles, ainsi que la rétention zéro (ZDR) — deux points importants pour les projets soumis au RGPD.
Qui l'utilise déjà et pour quoi ?
Plusieurs entreprises ont utilisé l'API Decisions pendant la phase beta et ont été mentionnées par OpenAI lors du passage en GA :
- Box — modération de contenus d'entreprise : classifier automatiquement les fichiers partagés selon des politiques de conformité ;
- Datadog — routage d'alertes et d'incidents : orienter automatiquement chaque alerte vers l'équipe ou le runbook approprié ;
- Ramp — classification de dépenses : catégoriser les transactions et détecter les anomalies dans les notes de frais ;
- Sierra — routage dans des assistants IA : diriger les requêtes entrantes vers l'agent spécialisé le plus adapté ;
- Speak — évaluation de la qualité de réponses dans l'apprentissage des langues : scorer les réponses orales ou écrites selon des rubriques pédagogiques.
Ces cas d'usage illustrent les trois grandes familles d'application de l'API Decisions : la modération et classification de contenu, le routing intelligent de flux, et l'évaluation structurée de qualité. Dans les trois cas, la valeur tient à la combinaison vitesse + coût faible + réponse structurée, sans besoin de texte généré.
Intégration dans une architecture multi-agents
Dans une architecture multi-agents, l'API Decisions joue le rôle d'un aiguilleur léger et rapide. Le schéma type est le suivant :
- Une requête entrante est reçue (message d'un utilisateur, événement système, document à traiter) ;
- L'API Decisions est appelée avec une question de type Choice : quel agent ou quel pipeline est le plus approprié pour traiter cette requête ? ;
- La réponse (typée, en quelques dizaines de millisecondes) détermine le routage ;
- L'agent spécialisé choisi prend la main et génère la réponse complète.
Ce pattern évite de lancer systématiquement un appel complet au LLM pour une décision qui peut être résolue avec quelques probabilités ou un choix catégoriel. Dans des pipelines à fort volume, la différence de coût et de latence est substantielle.
L'API Decisions se combine également bien avec les mécanismes d'évaluation en boucle : après chaque réponse générée par un agent, un appel Decisions peut scorer la qualité de la réponse selon des rubriques définies, avant de décider si elle doit être validée, améliorée ou rejetée — sans générer de nouveau texte.
Pour les équipes qui construisent des agents IA robustes, l'API Agents d'OpenAI pour l'orchestration et l'API Decisions sont complémentaires : l'une gère l'exécution des tâches, l'autre les décisions de routing et d'évaluation intermédiaires.
Limites et points de vigilance
Avant d'intégrer l'API Decisions dans un projet, plusieurs points méritent d'être connus :
- Modèle unique : seul gpt-6-luna est disponible au lancement GA. OpenAI n'a pas annoncé de support pour d'autres modèles dans l'immédiat ;
- Pas de génération de texte : l'API est strictement limitée aux réponses typées (probability, choice, score). Elle n'est pas adaptée à la synthèse, à la traduction ou à tout besoin de texte libre ;
- Retours beta mitigés : dans des tests indépendants effectués pendant la beta, certains développeurs n'ont pas constaté d'avantage clair de Luna par rapport à un appel classique sur des volumes faibles — les gains en vitesse et en coût sont surtout perceptibles à l'échelle ;
- Limite de 400 questions par requête : même si ce plafond a doublé depuis la GA, des batch très larges (évaluation de milliers d'entités) nécessitent de paginer les appels ;
- Dépendance à gpt-6-luna : la qualité des décisions dépend du modèle — sur des domaines très spécialisés ou des langues peu représentées, les résultats peuvent être moins fiables que sur des cas généraux.
Ces limites ne remettent pas en cause l'intérêt de l'API pour les cas d'usage bien définis, mais elles soulignent l'importance de tester sur vos propres données avant de construire un pipeline critique dessus. Pour un usage en production, un accompagnement technique permet d'évaluer si l'API Decisions est le bon outil pour votre architecture, ou si une approche différente convient mieux à vos contraintes.
FAQ — L'API Decisions d'OpenAI passe en GA : routage 10× plus rapide, 0,10 $ le million de tokens — pour qui et comment
Quelle est la différence entre l'API Decisions et l'API Responses d'OpenAI ?
L'API Responses génère du texte libre à partir d'un prompt — c'est l'API classique pour les chatbots, les résumés, les réponses en langage naturel. L'API Decisions renvoie uniquement des réponses typées (probabilité, choix parmi des options, score) sans générer de texte. Elle est plus rapide (jusqu'à 10×) et moins chère (0,10 $/M tokens d'input vs ~1,25 $ via Responses), mais elle ne peut pas créer de contenu textuel.
L'API Decisions fonctionne-t-elle avec d'autres modèles que gpt-6-luna ?
Non, au 22 octobre 2026. Seul gpt-6-luna est supporté. OpenAI n'a pas annoncé d'extension à d'autres modèles pour l'instant. Si votre projet utilise GPT-6 Sol ou un autre modèle, vous devrez continuer à passer par l'API Responses pour les tâches de classification et de routing en attendant une éventuelle extension.
L'API Decisions est-elle adaptée à la conformité RGPD ?
OpenAI propose depuis la GA la résidence des données en Europe et la rétention zéro (ZDR) pour les clients éligibles. Ces options répondent à des exigences RGPD clés sur la localisation et la durée de conservation. Cela dit, l'éligibilité dépend de votre niveau d'abonnement, et une analyse juridique complète reste recommandée pour les données personnelles sensibles.
Dans quels cas l'API Decisions apporte-t-elle une vraie valeur ?
Elle est particulièrement utile pour trois cas : (1) la modération et la classification de contenu à fort volume, où vous avez besoin d'une décision rapide et structurée sans texte généré ; (2) le routing de requêtes dans un système multi-agents, où elle oriente les entrées vers le bon pipeline ; (3) l'évaluation structurée de qualité en boucle, où elle score les sorties d'un agent selon des rubriques définies. En dehors de ces cas, l'API Responses classique reste souvent plus adaptée.
Comment tester l'API Decisions avant de l'intégrer en production ?
OpenAI met à disposition la documentation sur developers.openai.com. Le point de départ recommandé est de définir précisément vos questions (types probability, choice ou score), de les tester sur un échantillon représentatif de vos données réelles, et de comparer la précision avec vos méthodes actuelles. La beta a montré que les gains sont plus visibles à l'échelle — une évaluation sur un volume limité peut sous-estimer les bénéfices.