L'échec le plus dangereux des agents n'est pas l'hallucination
2026-05-14 · Agentic AI
Discipline Claim-Action-Evidence pour les agents IA utilisant des outils
La plupart des conversations sur la fiabilité de l’IA utilisent encore le vocabulaire des chatbots. Le modèle a-t-il halluciné ? A-t-il répondu correctement ? Le raisonnement était-il bon ? A-t-il utilisé un outil ?
Ces questions comptent, mais elles ne suffisent plus une fois qu’un modèle devient un agent.
Quand un humain délègue du travail à un agent IA, la question centrale change :
L’agent peut-il transformer une obligation humaine en une action réelle, vérifier l’état résultant et rendre compte de manière véridique ?
C’est le problème de fiabilité que je rencontre sans cesse dans les environnements d’exécution d’agents proches de la production.
L’échec le plus dangereux n’est pas toujours que le modèle dise un fait faux.
L’échec le plus dangereux est celui-ci :
L’agent affirme qu’une action a changé le monde, mais l’état observable de l’exécution ne soutient pas cette affirmation.
J’appelle cela une fausse affirmation d’achèvement (False Completion Claim), ou plus généralement un échec Claim-Action-Evidence.
Un échec normal dit :
« Je n’ai pas pu le faire. »
Une fausse complétion dit :
« C’est fait. »
Alors que rien n’a été fait.
Cette distinction est tout.
Un utilisateur peut se remettre d’un échec visible.
Un utilisateur ne peut pas se remettre d’un faux succès auquel il fait confiance.
Il faut donc évaluer les agents outillés au niveau de la boucle complète, pas seulement au niveau de la réponse finale.
La boucle est simple :
- L’utilisateur formule une obligation.
- L’agent choisit une action.
- L’environnement d’exécution exécute ou bloque cette action.
- L’état observable change, ou ne change pas.
- L’agent rend compte.
La plupart des échecs deviennent dangereux à la cinquième étape.
L’agent peut avoir une preuve partielle, ambiguë, périmée, ou aucune preuve. S’il annonce malgré tout que le travail est terminé, il transforme une incertitude en faux fait opérationnel.
C’est ici que l’« exosquelette » d’exécution de l’agent compte : outils, fichiers, permissions, mémoire, environnement, journaux et canaux de vérification disponibles. Un bon agent doit savoir ce que cet exosquelette expose et ce qu’il n’expose pas.
Il ne doit pas généraliser à partir de ses données d’entraînement sur ce qu’il peut inspecter. Il doit inspecter l’environnement réel.
Pour les systèmes de production, cela donne une règle pratique de readiness :
- si l’agent ne peut pas agir, il doit le dire ;
- s’il a agi mais ne peut pas vérifier l’état obtenu, il doit le dire ;
- s’il n’a vérifié qu’une partie de l’obligation, il doit limiter son affirmation ;
- si l’environnement a bloqué ou modifié le plan, il doit rapporter la contrainte ;
- s’il affirme l’achèvement, cette affirmation doit être soutenue par une preuve observable.
Le but n’est pas de rendre les agents infaillibles.
Le but est de les rendre opérationnellement honnêtes.
La solution n’est donc pas seulement de meilleures réponses.
La solution est une discipline Claim-Action-Evidence :
OBLIGATION UTILISATEUR → ACTION CORRECTE → ÉTAT OBSERVABLE → AFFIRMATION FINALE VÉRIDIQUE
Un bon agent n’a pas besoin de toujours réussir.
Un bon agent doit savoir faire la différence entre :
- « Je l’ai fait. »
- « J’ai essayé et échoué. »
- « Je ne peux pas le vérifier. »
- « Il me manque une information. »
- « L’environnement d’exécution me bloque ici. »
Tant que les agents ne préservent pas ces distinctions de manière fiable, ils ne sont pas prêts pour une délégation sérieuse.
— Julien Talbot