9 min de lecture - Agents IA contraints par des règles : trois contrôles avant d’agir

Un agent IA peut citer une politique, sauter une confirmation obligatoire et agir sur des faits que l'utilisateur n'a jamais fournis.

Trois études indépendantes soumises le 20 août 2026 rendent ces modes d'échec particulièrement concrets. La première examine des questions juridiques incomplètes, la deuxième confronte des agents à des règles financières exécutables et la troisième évalue des contrôles portant sur l'ensemble d'un workflow de service client. Elles ne démontrent pas l'existence d'une solution universelle. Ensemble, elles constituent toutefois un signal de conception utile pour les startups, les PME et les ETI qui souhaitent faire passer un agent de la conversation à l'action opérationnelle.

La conclusion pratique est la suivante : ne considérez pas que « le modèle connaît la politique » constitue un contrôle. Placez trois contrôles distincts autour de l'agent — suffisance des entrées, état du workflow et preuves d'exécution — puis testez-les séparément.

Ce que montrent réellement les nouvelles études

Le premier signal concerne l'étape qui précède la réponse. Le preprint InsufficiencyBench, soumis le 20 août, évalue si les modèles repèrent les informations juridiquement déterminantes absentes d'une question. Ses 202 éléments couvrent six domaines juridiques et 24 juridictions américaines, avec des annotations réalisées par des juristes en exercice. Sur dix modèles de pointe, les auteurs indiquent qu'aucun n'a dépassé un score F2 de 0,46 pour l'identification des éléments manquants ; le rappel médian était de 0,44. Les modèles formulaient souvent des réserves trop générales ou répondaient à partir d'hypothèses qu'ils n'avaient pas explicitées.

Le jeu de données reste réduit, américain et limité à un tour ; l'accord entre les modèles-juges était modéré et non validé par une notation humaine. La leçon métier est donc étroite : la qualité ne suffit pas sans vérifier si la question peut déjà recevoir une réponse.

Le deuxième signal porte sur le chemin entre la demande et le résultat. Le preprint PolicyGuide transforme des politiques organisationnelles en graphes de workflow, conserve la position de l'agent et utilise un vérificateur externe pour proposer l'étape conforme suivante. Dans trois domaines anglophones de service client, les auteurs indiquent que la fiabilité moyenne sur quatre exécutions passe de 0,42 pour la baseline à 0,62 avec PolicyGuide. Le gain le plus important apparaît dans le domaine des télécommunications, où la procédure est la plus structurée.

Il s'agit de benchmarks avec un utilisateur simulé, pas de clients réels. Le gain global dans le commerce de détail n'était pas statistiquement significatif et la mesure des séquences, conçue par les auteurs, n'a pas été comparée à un second annotateur. L'hypothèse utile reste que les procédures longues peuvent exiger un état suivi hors du modèle, pas seulement davantage de politique dans le prompt.

Le troisième signal concerne ce qui s'est passé lors de l'exécution. Le preprint ReguSim distingue quatre éléments : le raisonnement déclaré par l'agent, l'ordre tenté, le résultat du mécanisme de contrôle et les preuves montrées au dispositif de surveillance. Dans son environnement contrôlé de conformité financière, la présence visible des règles réduisait les actions rejetées sans les éliminer. Des justifications assurées pouvaient également tromper un moniteur indépendant lorsque les preuves du contrôle d'exécution étaient absentes. Sur l'échantillon synthétique, de simples baselines structurées égalaient ou dépassaient les moniteurs fondés uniquement sur un prompt de LLM.

ReguSim n'est ni un marché complet ni un système d'arbitrage juridique. Son apport est de séparer intention, tentative, contrôle et preuve : une explication fluide ne prouve pas qu'une action autorisée a été exécutée ou qu'une action interdite a été bloquée.

Le modèle opérationnel à trois contrôles

Ces études analysent des domaines différents et leurs résultats ne doivent pas être fusionnés en un benchmark unique. Le modèle suivant est une déduction opérationnelle d'Exceev à partir de leur motif commun. Il est cohérent avec le cadre de gestion des risques liés à l'IA du NIST, qui intègre la gestion des risques à la conception, au développement, à l'utilisation et à l'évaluation des systèmes d'IA.

L'ordre compte. Un échec au premier contrôle déclenche une clarification ou une transmission. Au deuxième, l'agent ne peut pas sauter un prérequis. Au troisième, l'action ne passe pas, même avec une justification convaincante. Le même modèle ne doit pas être acteur, approbateur et auditeur : un validateur de schéma, un moteur de règles ou une contrainte de base de données sera parfois plus solide qu'un second modèle.

Appliquer les contrôles à un workflow réel

Prenons un agent de support autorisé à créditer un compte. Il vérifie d'abord le client, la transaction, le motif et la solution demandée ; une donnée manquante déclenche une question précise. Le système charge ensuite la politique actuelle, contrôle l'éligibilité et conserve hors de la conversation les diagnostics et validations déjà réalisés. Enfin, un service déterministe vérifie le montant, la devise, l'autorisation et la clé d'idempotence avant d'appeler l'outil. Le journal conserve la demande et le résultat réel, pas seulement l'explication de l'agent.

Pour les workflows à impact élevé, reliez cette conception à une piste d'audit des agents et commencez par un pilote limité avant tout accès aux données métier.

Ce qu'il faut tester avant la production

Une évaluation de production doit utiliser des cas appariés et des exécutions répétées, pas un seul chemin nominal.

1. Entrées complètes et incomplètes. Retirez un fait déterminant : l'agent doit identifier le manque sans refuser les demandes complètes.
2. Actions proches de la limite. Modifiez un seuil, un rôle, une séquence ou une validation et vérifiez que le résultat change.
3. Preuves contradictoires. Opposez le prompt au système faisant autorité : la source fiable doit l'emporter et le conflit être consigné.
4. Procédures longues. Redémarrez à mi-parcours, réessayez une étape et changez d'opérateur sans perdre l'état.
5. Pression persuasive. Invoquez l'urgence pour demander d'ignorer un contrôle ; la politique ne doit pas devenir un test de personnalité.
6. Échecs et doublons. Simulez délais, réussite partielle et réponse tardive. Le rapprochement et l'idempotence doivent éviter les effets en double.

Suivez les mesures par contrôle au lieu de les compresser en un seul « score de conformité ». Les indicateurs utiles comprennent le rappel des entrées déterminantes manquantes, le taux d'hypothèses non justifiées, la réalisation des prérequis, le taux de tentative d'action interdite, l'efficacité des blocages fermes, le taux de blocages injustifiés, la complétude de la piste d'audit et le délai de résolution humaine. Définissez des seuils adaptés au workflow et au préjudice possible ; les nouvelles études ne fixent pas d'objectifs universels pour la production.

Les arbitrages que la direction doit assumer

Trois contrôles ajoutent coûts et latence. Les politiques exigent un responsable et un versionnage. Un contrôle trop strict bloque des demandes valides ; un contrôle trop faible rassure à tort. Les journaux sensibles exigent aussi une conception adaptée de la conservation et des accès.

Choisissez donc le niveau d'autonomie. Un processus rare et critique peut rester humain, l'IA préparant les preuves. Un processus stable et fréquent peut être automatisé après des tests répétés. Des règles contestées, changeantes ou non testables indiquent que l'exécution autonome est prématurée.

Le métier approuve la politique et l'arrêt ; l'ingénierie assume le contrôle et l'observabilité ; la sécurité et la vie privée examinent accès et preuves. Des experts qualifiés valident les décisions réglementées à fort impact. Le modèle ne peut pas absorber ces responsabilités.

Une séquence pilote sur quatre semaines

• Semaine 1 — modéliser la décision. Sélectionnez une action bornée, identifiez les entrées déterminantes, cartographiez les sources faisant autorité et nommez le responsable de la politique.
• Semaine 2 — mettre en œuvre les contrôles. Ajoutez une collecte structurée, un état de workflow externe, un contrôle déterministe et un registre de décision en ajout uniquement.
• Semaine 3 — tester de manière adversariale. Exécutez à plusieurs reprises des cas incomplets, contradictoires, désordonnés, dupliqués et urgents.
• Semaine 4 — examiner les exceptions. Mesurez les escalades humaines et les blocages injustifiés, inspectez les traces complètes, puis décidez de poursuivre, de réduire le périmètre ou de conserver un pilotage humain.

Le livrable n'est pas seulement un agent. C'est un workflow versionné, un jeu d'évaluation, une piste de preuves, des responsables nommés et une décision de déploiement réversible.

Sources et limites

• InsufficiencyBench, soumis le 20 août 2026, est un preprint centré sur le droit américain, avec les limites de périmètre et de notation décrites plus haut.
• PolicyGuide, soumis le 20 août 2026, présente des résultats de benchmark dans trois domaines anglophones de service client, et non des résultats en production réelle.
• ReguSim, soumis le 20 août 2026, utilise un ensemble de règles borné et des données de surveillance synthétiques ; ses résultats ne constituent ni des conclusions juridiques ni une estimation de la fréquence de comportements réels sur les marchés.
• Le cadre de gestion des risques liés à l'IA du NIST est un référentiel volontaire. Il ne certifie pas l'architecture proposée et ne remplace pas les obligations sectorielles.

Les trois études constituent des preuves préliminaires. Aucune comparaison directe entre elles n'a été réalisée et leurs métriques ne sont pas interchangeables. Le modèle à trois contrôles présenté ici est une synthèse opérationnelle, pas un résultat revendiqué par leurs auteurs. Vérifiez à nouveau les sources et obtenez un avis qualifié avant toute décision juridique, financière, sociale ou réglementaire.

À retenir

Le signal actuel n'est pas que les agents seraient soudain devenus conformes. Il montre que l'évaluation se rapproche de la véritable unité de risque : le système en savait-il assez, a-t-il suivi la procédure exigée et a-t-il produit des preuves opposables de ce qu'il a réellement fait ?

Avant qu'un agent puisse agir, imposez les trois contrôles. Si les preuves sont incomplètes, le résultat le plus sûr et le plus utile peut être une question ciblée, une action bloquée ou une transmission propre à une personne.