Les faits : une API conçue pour répondre par choix, score ou probabilité
OpenAI a ouvert le 6 octobre la version bêta publique de son API Decisions. Contrairement à un assistant qui rédige une réponse, ce service reçoit du texte ou des images et renvoie des résultats typés. Un prédicat estime la probabilité qu’une affirmation soit vraie. Un choix sélectionne une option dans une liste fermée et fournit un niveau de confiance. Un score situe l’entrée sur une échelle définie par le développeur. Une question peut aussi produire un refus. Au lancement, le service utilise GPT-6 Luna. OpenAI affirme qu’il peut rendre une décision jusqu’à dix fois plus vite que Luna utilisé par l’API Responses. Il peut traiter plusieurs questions ordonnées sur la même preuve et retourner la distribution des probabilités, l’option choisie ou le score. Ce sont les faits documentés par le fournisseur. La promesse de vitesse demeure toutefois une mesure d’OpenAI; la documentation publique ne fournit pas encore une étude indépendante couvrant les cas d’affaires réels.
L’interprétation : la conversation cède la place au routage
Le changement intéressant n’est pas qu’un modèle puisse dire oui ou non. Les systèmes informatiques font cela depuis longtemps. La nouveauté est de transformer rapidement une entrée floue, comme une plainte rédigée librement ou la photo d’un colis, en une sortie assez structurée pour déclencher un flux de travail. Une PME pourrait classer une demande entre remboursement, remplacement et révision manuelle. Un centre de services pourrait estimer si un message contient toutes les pièces nécessaires avant de l’acheminer. Cette interface rapproche le modèle d’un moteur de règles sans en faire réellement un. Une règle classique produit le même résultat lorsque les conditions sont identiques et visibles. Le modèle interprète plutôt le contexte, puis exprime une confiance. Il devient donc un composant de routage placé entre la demande et l’action. Notre interprétation est que cette couche sera très utile pour les tâches nombreuses, répétitives et réversibles. Elle devient plus délicate dès que le choix modifie un droit, un prix, un accès, une priorité clinique ou une relation d’emploi.
Un score de confiance ne définit pas le risque acceptable
Une probabilité de 0,92 semble précise, mais elle ne dit pas à elle seule si l’action proposée est sûre. Elle décrit la réponse du modèle selon l’entrée, les instructions, les options et sa propre distribution. Elle ne mesure pas automatiquement le coût d’une erreur. Classer à tort un courriel dans le mauvais dossier n’a pas la même conséquence que refuser une réclamation ou retarder une intervention urgente. Deux organisations peuvent donc recevoir le même score et devoir prendre des décisions différentes. Le cadre de gestion des risques du NIST insiste justement sur le rôle du jugement humain dans le choix des métriques et des seuils. Son guide recommande de tester avant le déploiement, de surveiller le système en continu et de documenter les interventions humaines, les renversements, les erreurs et les plaintes. Autrement dit, le seuil n’est pas une propriété magique du modèle. Il exprime la tolérance au risque de l’organisation. La vitesse de l’API réduit le délai technique; elle ne retire ni la responsabilité ni le besoin de mesurer les conséquences.
Trois zones valent mieux qu’un seuil magique
Une façon prudente de commencer consiste à définir trois zones. Dans la zone automatique, le système exécute uniquement une action faible risque et facile à annuler. Dans la zone de révision, une personne voit l’entrée, le choix proposé et les éléments pertinents avant de décider. Dans la zone d’abstention, le système ne fait rien et demande davantage d’information. Par exemple, une équipe pourrait automatiser un simple classement au-dessus d’un seuil testé, réviser les cas intermédiaires et suspendre ceux qui contiennent des données contradictoires. Les nombres doivent provenir d’un jeu d’essai représentatif, jamais d’une intuition ou d’un exemple de démonstration. Il faut mesurer séparément les erreurs coûteuses, les écarts entre groupes de clients, les changements après une mise à jour et la fréquence des refus. Chaque trace utile devrait conserver la version du modèle, les choix offerts, le résultat, la confiance, l’action finale et toute correction humaine, tout en limitant les renseignements personnels. Cette discipline transforme une sortie probabiliste en processus gouvernable. Elle permet aussi d’abaisser le seuil, de le relever ou d’arrêter l’automatisation lorsque les résultats dérivent.
Les limites : une bêta rapide laisse l’entreprise entièrement responsable
La bêta impose déjà des limites concrètes. La référence accepte du texte et des images intégrées, mais pas les rôles autres que l’utilisateur, les appels de fonction, les fichiers, l’audio ni les références vers des éléments externes. Les images doivent être transmises sous forme de données intégrées. L’API peut refuser une question, ce qui oblige l’application à prévoir une sortie sûre au lieu de supposer qu’une réponse arrivera toujours. OpenAI indique aussi que les journaux de surveillance des abus peuvent être conservés jusqu’à 30 jours par défaut, avec des options particulières pour les clients admissibles. Ces contraintes rappellent que le lancement fournit un outil, pas une politique de décision. Il reste à démontrer la stabilité des scores sur des données québécoises, en français canadien, avec les formulations, les photos et les exceptions propres à chaque organisation. Il faut aussi comparer le système à une règle simple et au travail humain, puis publier des critères de recours pour les personnes touchées. La bonne question n’est donc pas seulement de savoir si l’IA peut choisir dix fois plus vite. C’est de savoir quelles décisions méritent cette vitesse, qui fixe le seuil et qui répond lorsque le choix est mauvais.
