OpenAI et la Decisions API : confier au modèle un choix parmi des options définies

NNoor

Alors, l’idée centrale est de demander au modèle non pas de rédiger une réponse libre, mais de sélectionner une option dans un ensemble fixé à l’avance par l’application. OpenAI a présenté la Decisions API à DevDay 2026, et elle s’appuie sur GPT-6 Luna, d’après AlphaSignal. Le développeur précise la décision à prendre, les réponses autorisées et le contexte à examiner, qui peut être du texte ou une image. Le modèle renvoie l’une des réponses proposées, que l’application peut ensuite utiliser directement. Cette construction est importante parce qu’elle fait de la liste de réponses une partie de la demande, plutôt qu’une consigne de style ajoutée autour d’une conversation ouverte. Dans une réponse libre, le modèle pourrait expliquer son choix, employer un autre terme ou produire une formulation difficile à interpréter automatiquement. Ici, le rôle attendu est plus étroit : évaluer le contexte fourni et choisir dans le cadre transmis. Cela ne signifie pas que le modèle dispose d’une connaissance parfaite de la situation ; cela décrit surtout la forme de la tâche et des résultats possibles. L’annonce porte donc sur une interface conçue pour des décisions circonscrites, plutôt que sur une nouvelle manière de dialoguer sans limites avec un assistant.

NNoor

Dans une intégration classique, un développeur peut demander à un modèle de classer un message, puis lui donner des consignes pour obtenir une réponse dans un format particulier. Il lui faut ensuite vérifier que le résultat correspond à une catégorie attendue, parfois extraire l’étiquette d’une phrase, et prévoir quoi faire si la réponse sort du format demandé. La Decisions API place les choix autorisés au cœur de la requête : l’application demande une décision et fournit les réponses possibles. Le résultat est donc conçu pour être l’une des options définies, au lieu d’être un texte libre que le logiciel devrait interpréter. Cette approche peut réduire le travail de traitement autour de la réponse, notamment les étapes destinées à reconnaître une étiquette ou à gérer une sortie mal formée. Le gain envisagé concerne ainsi l’intégration logicielle et la validation de la forme, pas une garantie que la décision sera correcte. Un modèle peut respecter exactement la liste et néanmoins choisir une option inadaptée au contexte. Les développeurs doivent donc distinguer deux questions : le résultat appartient-il aux choix permis, et le choix retenu convient-il réellement à la situation ? La première est encadrée par le format annoncé ; la seconde dépend aussi de l’interprétation du contexte et des catégories prévues.

NNoor

Les usages annoncés concernent des tâches où il faut attribuer une catégorie, orienter une demande ou choisir une prochaine étape pour un agent logiciel. Par exemple, une application peut transmettre le contenu d’un ticket d’assistance et une liste d’équipes possibles, puis demander au modèle de sélectionner l’équipe qui convient. Le même mécanisme peut servir au routage de requêtes ou à la classification d’informations. Pour un agent, le choix peut porter sur l’action suivante, parmi celles que le développeur a inscrites dans la liste autorisée. Le contexte n’est pas limité à du texte : l’annonce prévoit aussi que le modèle puisse examiner une image avant de sélectionner une réponse. Cela ouvre la voie à des tâches de décision fondées sur différents types d’entrées, mais ne précise pas en soi les performances obtenues dans chaque situation. AlphaSignal décrit ces applications comme des domaines visés ; la source ne désigne pas une clientèle particulière et ne permet pas de dire quels secteurs adopteront l’outil. La cible pratique est donc toute intégration qui doit transformer un contexte en choix parmi des catégories prévues, sans que cela constitue une annonce de déploiement chez des clients déterminés. L’intérêt dépendra de la manière dont chaque développeur définit ses options et insère le résultat dans son propre processus.

NNoor

La Decisions API est proposée en préversion limitée à certains clients de l’API. Une disponibilité plus large est annoncée dans les jours suivants, mais cela ne signifie pas que l’accès est déjà ouvert à tous les développeurs. Les informations annoncées ne donnent pas de prix, de quota ni de modalités détaillées pour cette ouverture. Il faut donc séparer le lancement de l’API, qui est présenté, et la possibilité concrète pour chaque équipe d’y accéder, qui reste restreinte pendant cette phase. Une préversion de ce type permet aux clients sélectionnés d’utiliser le service avant une diffusion plus large, mais les éléments disponibles ne décrivent pas les critères de sélection ni les conditions de participation. Il n’est pas non plus possible d’en déduire le coût d’une décision, le volume de requêtes disponible ou les garanties associées au service. Le seul repère annoncé est une ouverture plus large attendue dans les jours suivants, sans calendrier plus précis. La préversion signale un déploiement progressif, pas encore une disponibilité générale.

NNoor

La limite principale est qu’une réponse conforme à la liste peut tout de même être erronée. Le contexte peut être ambigu, chercher à induire le modèle en erreur ou ne pas entrer clairement dans les catégories prévues ; dans ces cas, le système doit malgré tout choisir parmi les options disponibles. Les informations présentées signalent qu’un développeur peut ajouter un choix indiquant que le cas demande un réexamen, puis faire traiter ce résultat dans une procédure distincte. C’est une façon de ne pas forcer chaque entrée incertaine vers une catégorie ordinaire, mais elle ne supprime pas le besoin de concevoir correctement la liste et de vérifier les situations sensibles. Si la taxonomie est incomplète, ou si deux catégories se recouvrent, le modèle peut respecter la consigne tout en produisant une décision peu utile. Dans des processus à conséquences importantes, cette distinction compte : limiter les sorties possibles ne revient pas à certifier la justesse du résultat. L’API encadre la réponse, tandis que les règles de traitement, les catégories et les étapes de contrôle restent à définir autour de l’outil. On ne dispose pas ici d’éléments permettant d’affirmer que ces précautions sont automatiquement prises en charge par le service.

NNoor

Il faut retenir qu’OpenAI propose une interface où GPT-6 Luna reçoit un contexte textuel ou visuel et choisit une réponse dans une liste définie par le développeur. Les usages mis en avant sont la classification, le routage de requêtes et la sélection de la prochaine action d’un agent. Par rapport à une réponse libre, l’intérêt annoncé est de fournir directement une option prévue, ce qui peut éviter une partie du travail nécessaire pour analyser et valider le texte produit par un modèle. Mais la contrainte porte sur la forme du résultat et sur les choix disponibles, pas sur la certitude que le choix retenu est juste. Les développeurs devront donc prévoir des catégories adaptées, et une voie de réexamen pour les cas qui ne se rangent pas clairement dans une option. Il reste aussi à connaître les conditions d’accès et les modalités de déploiement, puisque l’API est en préversion limitée pour certains clients. Une disponibilité plus large est annoncée dans les jours suivants, sans que les détails pratiques soient précisés. À ce stade, l’annonce décrit une manière plus encadrée de brancher un modèle à des décisions logicielles ; elle ne fournit pas de résultats d’usage permettant d’évaluer sa précision réelle. L’essentiel est donc la promesse d’un choix contraint, avec les limites habituelles d’un système qui doit interpréter un contexte parfois incertain.