Dans les systèmes qui traitent des transferts d’argent, des soins de santé ou des infrastructures, il ne suffit pas qu’un agent d’IA réussisse la plupart du temps. L’idée centrale du premier niveau d’un modèle de maturité à six niveaux pour l’exploitation de systèmes de modèles de langage en production consiste à confiner le modèle dans un seul nœud, afin que tout ce qui l’entoure reste du code ordinaire pouvant être testé, révisé et audité.
L’article présente cette approche comme une « couche de déterminisme » : le système conserve la capacité du modèle à exercer son jugement sur des entrées complexes, mais l’empêche d’avoir une autorité directe sur l’état métier ou d’exécuter des actions sensibles.
L’agent propose, mais n’exécute pas
L’agent fonctionne comme une fonction pure qui transforme le contexte en décision proposée. Il produit l’identifiant de la décision, la capacité requise, la modification proposée, le niveau de confiance, le chemin d’orientation, ainsi que les raisons et les éléments probants, mais il ne modifie pas l’état métier. Le résultat est transmis à un composant distinct, appelé substrate dans l’article, qui ne l’applique qu’après avoir obtenu l’approbation requise.
Cette séparation confère au système trois propriétés pratiques : la possibilité de tester l’agent sans simuler le monde extérieur, la réduction de l’impact des sorties erronées à une proposition pouvant être rejetée, et la prévention des chaînes d’effets secondaires cachés entre les agents. La question vérifiable devient ainsi : qu’a proposé le modèle, qui l’a approuvé et qu’est-ce qui a réellement été appliqué ?
Un diagramme statique plutôt qu’une boucle libre
Plutôt que de laisser un modèle ReAct décider de l’étape suivante à chaque fois, l’article propose un diagramme statique pour chaque capacité. Selon l’exemple, la requête passe par des nœuds d’entrée de décision, de vérification des entrées et de chargement du contexte, puis par un seul nœud de raisonnement linguistique, suivi de barrières de sortie et de validation, d’un arbitrage facultatif, de l’agrégation de la confiance, de l’orientation, de la préparation de la proposition, puis de l’écriture de la mémoire et du registre de décision.
Cette structure rend le chemin d’exécution connu à l’avance, limite la durée et le coût d’exécution et permet de tester chaque nœud séparément. Le nœud non déterministe est llm_decision, qui reçoit une entrée structurée et produit une sortie structurée, tandis qu’un code spécialisé vérifie les valeurs autorisées, la conformité au schéma et les règles métier.
Les sorties structurées ne signifient pas que la décision est correcte
L’article met en garde contre le recours au texte libre, suivi d’une tentative d’en extraire la décision. L’alternative consiste à utiliser un schéma JSON, l’appel d’outils ou une génération contrainte par des règles grammaticales, puis à valider le résultat et à réessayer en cas de non-conformité, avec un nombre limité de tentatives et un échec fermé plutôt que de transmettre une supposition aux étapes suivantes.
Mais cette procédure contrôle la forme de la sortie, et non la justesse du jugement. Un objet JSON peut être syntaxiquement valide tout en contenant une décision erronée. Il faut donc maintenir la validation des règles métier, l’évaluation et les signaux de confiance indépendants dans les couches ultérieures.
Confiance, escalade et registre immuable
La confiance est composée à partir du signal du modèle, des résultats de validation et de l’examen par un second modèle lors de l’échantillonnage de décisions sensibles. Le système oriente ensuite la décision vers une exécution automatique, recommande un examen humain, l’impose ou rejette la décision. L’article souligne que le niveau de confiance ne devrait pas être un champ que l’agent détermine lui-même, mais le résultat calculé à partir de signaux indépendants, avec des seuils initialement conservateurs, abaissés uniquement lorsque les données démontrent que cela est sûr.
Chaque décision devrait également être enregistrée dans un registre supplémentaire et immuable, comprenant la version du modèle et du prompt, un résumé des entrées de la décision, la décision, le niveau de confiance et le chemin d’orientation. Les corrections ne modifient pas les enregistrements précédents ; elles sont ajoutées sous forme de nouveaux enregistrements faisant référence à la décision qu’elles remplacent. L’article recommande de stocker un hachage des entrées sensibles plutôt que les données brutes, sans interrompre l’écriture, même sous pression, car le registre constitue la référence principale et non de simples données de surveillance.
Quand autoriser la boucle itérative ?
La méthodologie ne rejette pas totalement les boucles ReAct, mais les limite aux situations où le nombre et l’ordre des étapes dépendent de ce que le modèle découvre au cours de sa recherche. Même lorsqu’elles sont utilisées, une limite explicite du nombre d’itérations, une liste d’outils autorisés pour chaque capacité et l’enregistrement de chaque étape doivent être imposés, et la sortie doit repasser par les mêmes barrières, validations, contrôles de confiance et mécanismes d’orientation. Si la limite est atteinte avant l’obtention d’un résultat, le chemin doit mener vers un examen humain plutôt que vers une boucle infinie.
Lecture éditoriale : le véritable changement ne consiste pas ici à choisir un meilleur modèle, mais à déplacer le centre de confiance de « l’autonomie de l’agent » vers l’ingénierie des limites qui l’entourent. Cette conception ne résout pas automatiquement le problème de la justesse du jugement ni celui du calibrage de la confiance, mais elle rend les défaillances isolables, reproductibles et révisables. Elle constitue donc une base fondatrice pour les systèmes à forts enjeux, et non un substitut à l’évaluation continue ou à la validation spécialisée de chaque capacité.