OpenAI ajoute une nouvelle brique à son offre destinée aux développeurs. Baptisée Decisions API, elle vise à faire choisir un modèle parmi des options prédéfinies plutôt qu’à lui confier une mission entièrement ouverte. Pour les PME, cette orientation replace le contrôle des décisions au centre des projets d’agents IA.

L’enjeu dépasse la performance technique. Dans un workflow commercial ou opérationnel, la valeur dépend surtout de la capacité à orienter une demande, déclencher la bonne procédure et transmettre les cas sensibles à un collaborateur. Un agent utile n’est pas celui qui agit sans limites, mais celui dont chaque action respecte un cadre métier explicite.

Des choix fermés pour mieux piloter les agents

Lors de la présentation rapportée par TechCrunch, OpenAI a décrit sa Decisions API comme un moyen de soumettre au modèle Luna un ensemble de choix. Le système attribue des probabilités aux options disponibles afin de sélectionner une catégorie d’image, un comportement d’agent ou une autre action prévue par le développeur. L’offre reste en avant-première limitée.

Cette logique se rapproche de Jev, un modèle de TypeSafe AI conçu pour l’automatisation logicielle. Dans les deux cas, le modèle n’a pas à produire une longue réponse ni à élaborer librement une stratégie. Il intervient comme un classificateur enrichi par les capacités de compréhension du langage et des images.

Pour une PME, le cas d’usage le plus immédiat se situe dans le routage. Une demande reçue par messagerie est dirigée vers le support, le service commercial ou la facturation. Dans le CRM, un message est associé à une intention, à un niveau d’urgence ou à une procédure validée. Une situation hors cadre est envoyée à une personne désignée au lieu de déclencher automatiquement une action sensible.

Cette architecture complète les interfaces conversationnelles déjà utilisées dans la relation client. Le cas de DoorDash, qui transforme la messagerie en canal de vente, montre que l’échange visible ne représente qu’une partie du système. En arrière-plan, l’entreprise doit reconnaître l’intention, vérifier les données disponibles et limiter les actions autorisées.

Séparer compréhension et exécution dans le CRM

Les grands modèles de langage restent adaptés à la rédaction, à la synthèse et à l’analyse de demandes complexes. Leur emploi systématique pour des décisions répétitives alourdit toutefois l’architecture. Un classement entre des catégories déjà définies n’exige pas le même traitement qu’une analyse commerciale complète.

La Decisions API traduit cette distinction en composant logiciel. Un modèle généraliste comprend le message, tandis qu’une couche spécialisée sélectionne le chemin prévu par l’entreprise. Le CRM conserve son rôle de source de référence, les règles métier fixent les limites et les collaborateurs gardent la responsabilité des exceptions.

Cette séparation améliore également la lisibilité opérationnelle. Lorsqu’un prospect est affecté à une équipe, le journal du workflow doit indiquer la catégorie retenue, les données consultées, l’action déclenchée et le motif d’une éventuelle escalade. Le responsable commercial dispose alors d’éléments concrets pour corriger les catégories ambiguës ou revoir une règle d’affectation.

La gestion de canaux et de langues variés renforce l’intérêt de ce modèle. Le panorama des réseaux sociaux au Maroc illustre la diversité des usages auxquels les équipes commerciales sont confrontées. Une couche de décision commune harmonise le traitement des demandes sans imposer un scénario conversationnel identique à tous les publics.

La rapidité annoncée par OpenAI ne suffit pas à valider un déploiement. L’entreprise doit évaluer le système sur ses propres messages, avec ses catégories et ses règles. La qualité du classement, le coût d’exécution, la fréquence des reprises humaines et les erreurs ayant une conséquence commerciale constituent des critères de pilotage plus utiles qu’une démonstration générale.

La gouvernance entre dans chaque workflow

Un choix prédéfini réduit le champ d’action de l’agent sans supprimer les risques. Les données envoyées au modèle, la durée de leur conservation, les droits d’accès et les conséquences d’une erreur doivent être documentés. Les ressources de la CNIL consacrées à l’intelligence artificielle fournissent un cadre pour intégrer la protection des données dès la conception et clarifier les responsabilités.

Le niveau d’encadrement dépend aussi de l’usage. Le tri d’une demande commerciale n’entraîne pas les mêmes conséquences qu’une décision liée au recrutement, à l’accès à un service essentiel ou aux droits d’une personne. La Commission européenne présente le cadre réglementaire de l’intelligence artificielle, fondé sur une approche tenant compte des risques associés aux systèmes et à leurs usages.

Pour les dirigeants, le signal est concret : l’autonomie maximale ne constitue pas le bon objectif pour tous les agents. Des options fermées, des sources de données identifiées et une escalade humaine explicite rendent l’automatisation plus gouvernable. La spécialisation des composants facilite aussi la mesure des résultats et l’identification des erreurs.

L’action prioritaire consiste à choisir en interne un workflow récurrent, puis à consigner ses décisions autorisées, ses données accessibles, ses cas d’arrêt, son responsable et son historique de contrôle avant toute connexion à un agent IA.