En bref
Un agent marque une tâche comme accomplie. Le résultat est techniquement conforme. Pourtant, la tâche n’est pas vraiment réussie. Ce scénario n’est pas un cas limite — les recherches récentes montrent qu’il constitue entre 27 % et 78 % des succès rapportés selon les benchmarks (Cao, Driouich, Thomas, 2026). Le problème n’est pas l’agent qui échoue : c’est l’agent qui croit avoir réussi, et le système qui le confirme.
En clair : imaginez un livreur qui dépose un colis à la mauvaise adresse mais marque “livré” dans son application. Le système enregistre un succès. Le destinataire, lui, n’a rien reçu. Pour les agents IA, entre un quart et trois quarts des succès rapportés sont du même tonneau — formellement clos, fonctionnellement faux.
Le succès binaire ne mesure pas ce qu’on croit
L’évaluation des agents repose depuis l’origine sur un critère binaire : la tâche est complétée ou non. Ce critère est simple à mesurer et facile à automatiser. Il est aussi structurellement insuffisant.
Cao, Driouich et Thomas (2026) ont introduit le cadre Procedure-Aware Evaluation (PAE) pour auditer ce que les benchmarks classent comme “succès”. Leur verdict : entre 27 % et 78 % des tâches marquées réussies sont des succès corrompus — la tâche est formellement terminée, mais l’agent a violé des contraintes procédurales ou d’intégrité en chemin. PAE évalue selon quatre dimensions : utilité, efficacité, qualité d’interaction, intégrité procédurale. Les résultats varient fortement selon les modèles : certains distribuent les violations sur plusieurs dimensions, d’autres les concentrent sur une seule (ex. fidélité politique ou fidélité aux instructions). [NON VÉRIFIÉ pour les proportions exactes par modèle]
L’illusion est amplifiée par les benchmarks eux-mêmes. Xue et al. (2025, COLM 2025) ont montré sur Online-Mind2Web (300 tâches réalistes) qu’un agent peut afficher de bonnes performances en laboratoire tout en échouant systématiquement sur des tâches équivalentes en production. WebArena (Zhou et al., 2023) quantifie l’écart : le meilleur agent GPT-4 atteint 14,41 % de taux de succès, contre 78,24 % pour les humains — et malgré cela, le critère “succès” reste défini par le benchmark, pas par la réalité de la tâche.
Le processus compte autant que le résultat
Si le résultat final ne suffit pas comme critère, que faut-il mesurer ?
Fan et al. (2026, AgentProcessBench) ont constitué le premier benchmark dédié à la qualité des trajectoires étape par étape, sur 1 000 trajectoires et 8 509 annotations humaines (accord inter-annotateurs : 89,1 %). Leur diagnostic central : les évaluations actuelles capturent le résultat final mais ignorent la qualité du chemin. Un agent qui s’arrête trop tôt peut afficher un excellent taux de succès par étape — simplement parce qu’il produit peu d’étapes fautives. Il échoue globalement, mais ses métriques locales sont flatteuses.
Shahnovsky et Dror (2026) illustrent le même problème sous un angle différent : le même agent atteint 38 % de succès global selon une métrique, et 89 % de précision par élément selon une autre. Le chiffre dépend de la définition adoptée, pas de la réalité de l’exécution.
Gulli (2025, Ch.11) formule ce principe côté conception : un agent sans capacité de monitoring continu reste confiné aux tâches réactives à étape unique. La boucle de rétroaction — comparer l’état courant à l’état-cible selon des métriques observables — est la condition nécessaire pour détecter les écarts avant qu’ils se transforment en échecs invisibles. Sans cette boucle, l’agent ne sait pas où il en est.
Qui vérifie ? L’agent, un juge externe, ou personne
Trois approches existent pour vérifier si une tâche est vraiment accomplie. Aucune n’est générale.
L’auto-vérification — SmartSnap (Cai et al., 2025) propose une transition du contrôle post-hoc vers l’auto-vérification in-situ : l’agent sélectionne proactivement un ensemble minimal de preuves décisives pendant l’exécution, plutôt que d’analyser rétrospectivement l’intégralité de l’historique. Gains mesurés : jusqu’à 26 % pour les modèles 8B. La limite est structurelle : un agent qui se trompe sur la tâche peut se tromper avec la même cohérence sur son propre succès.
La vérification externe — TrustBench (Sharma et al., 2026, AAAI 2026) positionne le contrôle au moment critique : après qu’un agent formule une action, avant son exécution. Ce placement permet de réduire les actions nuisibles de 87 % avec une latence inférieure à 200 ms. Le modèle LLM-as-a-Judge — un LLM séparé évalue les sorties d’un autre agent selon une rubrique structurée — surpasse généralement les modèles de récompense appris (Venkataramani et al., 2026, MAS-ProVe). Mais cette approche requiert un oracle externe et un coût de calcul supplémentaire.
La vérification de processus dans les systèmes multi-agents — MAS-ProVe (Venkataramani et al., 2026) conduit l’analyse empirique la plus systématique sur ce point. Résultat central : la vérification de processus n’améliore pas les performances de façon constante. La variance est forte selon les configurations. La granularité optimale — vérifier au niveau de l’agent ou au niveau de l’itération — reste une question ouverte.
Gulli (2025, Ch.19) cadre cette tension avec le concept de trajectoire : évaluer un agent, c’est comparer sa trajectoire réelle à une trajectoire idéale, étape par étape. Dans un système multi-agents, la question se dédouble — chaque agent individuel performe-t-il sa tâche, et l’ensemble du système respecte-t-il le plan global ?
Quelle approche de vérification choisir ?
| Contexte de la tâche | Recommandation | Pourquoi |
|---|---|---|
| Tâche simple, agent unique, faible enjeu | Auto-vérification (SmartSnap-like) | Bon compromis coût/qualité, gains jusqu’à 26% sur 8B — limites partagées avec l’agent |
| Tâche à enjeux, action irréversible imminente | Vérification externe avant exécution (TrustBench) | -87% d’actions nuisibles, latence < 200ms — coût d’un appel LLM de plus |
| Pipeline multi-agents avec contrats explicites | Modèle contractuel (Gulli Ch.19) | Critères d’acceptation définis avant exécution, propagation des succès corrompus détectable |
| Recherche/benchmarks, qualité prime sur coût | LLM-as-a-Judge externe | Surpasse les modèles de récompense appris (MAS-ProVe), mais oracle externe coûteux |
En clair : aucune approche n’est universelle. L’auto-vérification est rapide mais aveugle aux angles morts de l’agent. La vérification externe est plus fiable mais coûte un appel LLM supplémentaire. Le modèle contractuel demande une discipline en amont (rédiger le contrat) que peu d’équipes acceptent. Le bon choix dépend de l’enjeu de la tâche et du budget de calcul.
Vers une définition formelle du succès : le modèle contractuel
Une piste structurelle pour sortir de cette ambiguïté : définir le succès avant l’exécution, pas après. Gulli (2025, Ch.19) propose le modèle du “contractor” : l’agent opère à partir d’un contrat formel qui spécifie les livrables attendus, le périmètre, les ressources autorisées et les critères de validation. Ce contrat est la source de vérité unique pour juger si la tâche est réussie.
Le modèle repose sur quatre piliers : spécification formelle initiale, phase de négociation agent-utilisateur avant exécution, boucle d’auto-validation pendant l’exécution (générer-réviser-améliorer), et décomposition hiérarchique en sous-tâches formelles. Ce dernier point est directement applicable à la vérification multi-niveaux : chaque sous-tâche porte ses propres critères d’acceptation, ce qui rend la propagation des succès corrompus détectable à l’étape où elle se produit.
La distinction entre trajectoires acceptable (in-order match), exacte (exact match) et flexible (any-order match) que Gulli formalise en Ch.19 répond précisément au problème de Shahnovsky et Dror — la définition du succès est explicite dans le contrat, pas implicite dans la métrique choisie a posteriori.
Le problème de la mémoire et des boucles longues
TIDE (Yan et al., 2026) ajoute une dimension temporelle que les métriques actuelles ignorent. L’évaluation doit décomposer la dynamique globale de l’exécution selon trois axes : la progression globale dans le temps, l’identification des boucles récursives (l’agent tourne en rond sans le détecter), et l’impact réel de la mémoire accumulée sur la résolution. Un agent peut exhiber une amélioration apparente lors d’une session longue — par adaptation de sa mémoire — sans que cette amélioration corresponde à une meilleure capacité de résolution. TIDE formalise cette confusion comme un biais de mesure : l’évaluation de l’amélioration n’est pas équivalente à l’évaluation du succès.
La difficulté s’accentue dans les tâches dépassant vingt tours d’interaction. À ce niveau de longueur, la définition du succès n’est pas encore standardisée dans la littérature. La vérification dans les boucles longues reste le gap le plus sous-étudié du domaine — et le plus critique pour des agents déployés en production sur des tâches complexes.
Ce qu’il faut retenir
- Entre 27 % et 78 % des succès rapportés par les benchmarks dissimulent des violations procédurales non détectées par le critère binaire (Cao et al., 2026).
- La qualité du processus — comment l’agent a exécuté — n’est pas capturée par le résultat final. AgentProcessBench est le premier benchmark à le mesurer directement.
- L’auto-vérification améliore les performances mais partage les angles morts de l’agent qu’elle évalue. La vérification externe (LLM-as-a-Judge) est plus fiable mais coûteuse.
- La vérification de processus dans les systèmes multi-agents ne produit pas d’amélioration constante — c’est un problème ouvert, pas une solution disponible (MAS-ProVe).
- Il n’existe pas encore de définition consensuelle de ce que “réussir” signifie pour un agent. Les benchmarks définissent chacun leur propre critère, rendant les comparaisons peu fiables.
- Concevoir un agent sans boucle de rétroaction explicite, c’est concevoir un agent qui ne peut pas détecter ses propres écarts (Gulli, Ch.11).
- Le modèle contractuel (Gulli, Ch.19) propose une alternative structurelle : définir les critères d’acceptation avant l’exécution, pas après. Sans spécification formelle du succès en amont, tout jugement a posteriori reste arbitraire.