OpenAI a ouvert en préversion limitée Decisions API, une interface destinée à prendre des décisions structurées en temps réel dans une application. Propulsé par GPT-6 Luna, le service permet de définir une question et une liste de réponses possibles afin de classer un contenu, orienter une requête ou choisir la prochaine action d’un agent.
L’annonce a été publiée le 29 septembre par le compte OpenAI Developers. Elle vise un problème concret des systèmes d’agents : transformer un contexte variable en choix exploitable par un logiciel. Au lieu de demander au modèle une réponse libre, le développeur décrit la décision attendue et les options autorisées.
OpenAI présente Decisions API, propulsée par GPT-6 Luna, pour classer, router et choisir l’action suivante d’un agent.
— OpenAI Developers (@OpenAIDevs) 29 septembre 2026
Encadrer le choix plutôt que générer un long texte
Cette approche peut servir à envoyer une demande vers le bon service, attribuer une catégorie à un document ou sélectionner un outil dans une chaîne d’automatisation. Le résultat attendu est plus facile à intégrer qu’un paragraphe qu’il faudrait ensuite interpréter. Il peut aussi être journalisé et comparé à une règle métier.
Pour un agent, la décision se situe souvent entre deux étapes. Le système observe l’état d’une tâche, évalue les actions disponibles puis choisit celle qui doit suivre. Une interface dédiée peut réduire la quantité de code nécessaire pour construire ce routeur, tout en obligeant l’équipe à définir explicitement les choix possibles.
Le recours à GPT-6 Luna suggère qu’OpenAI privilégie ici un modèle rapide et moins coûteux que ses modèles les plus lourds. L’entreprise ne fournit toutefois pas encore, dans son annonce, de tarif propre à Decisions API, de mesure de latence, de taux d’erreur ni de date d’ouverture générale.
Une décision structurée n’est pas une garantie
Limiter la sortie à quelques options réduit les erreurs de format, mais ne garantit pas que le choix soit juste. La qualité dépend de la question, de la liste de réponses, du contexte transmis et des cas ambigus prévus par le développeur. Une catégorie « incertain » ou un transfert vers un opérateur humain reste nécessaire pour les décisions à fort impact.
Les équipes devront aussi surveiller les dérives dans le temps. Une modification des données entrantes peut rendre une taxonomie obsolète sans provoquer d’erreur technique visible. Les journaux, les jeux de tests et les seuils d’escalade restent donc indispensables, notamment pour la modération, le support client ou les opérations financières.
Un composant d’orchestration à évaluer
Decisions API se place entre le modèle généraliste et le moteur de règles classique. Il apporte de la souplesse lorsque les critères sont difficiles à écrire sous forme de conditions, tout en conservant une sortie bornée. Sa pertinence dépendra de la fiabilité observée sur des décisions réelles et du contrôle laissé aux développeurs.
La préversion limitée ne permet pas encore d’évaluer son adoption. Elle indique néanmoins la direction prise par OpenAI : proposer des briques spécialisées pour construire des agents, au-delà de la simple génération de texte. Les premiers retours devront préciser si ce composant simplifie réellement les architectures ou ajoute une nouvelle couche à surveiller.
