L'agent dit qu'il a fini, la base de données n'est pas d'accord : la fiabilité des agents se mesure dans l'état final

💡 En résumé

La leçon commune des publications de ce début octobre tient en une phrase : un appel d’outil n’est pas un résultat, et une réponse convaincante n’est pas une preuve. Microsoft et Hugging Face publient ThinkingBox, un banc d’essai qui note les agents sur l’état final de leurs systèmes plutôt que sur leurs phrases. Le verdict est brutal : sur 121 680 essais valides menés auprès de 12 modèles, 79 853 tentatives échouent aux contrôles exécutables, et 67,24 % de ces échecs terminent proprement — l’agent appelle un outil qui modifie l’état, ne renvoie aucune erreur finale, et laisse pourtant la mauvaise valeur en base. Côté recherche, la même intuition se décline partout : DeReAct externalise l’autorisation et la clôture, VERSE fait de l’optimiseur de harnais un agent vérifié, ArrivalBench rejoue les pipelines sous des ordonnancements adverses, et GHOST démontre qu’un agent peut violer une contrainte de sécurité énoncée vingt tours plus tôt (11,5 % sur GPT-5.5). La fiabilité cesse d’être une propriété du discours : elle devient une propriété de la trace.

🔥 Tendances : l’état final comme oracle

ThinkingBox : le juge, c’est le backend

Le billet de Microsoft et Hugging Face raconte une scène ordinaire. Une cliente écrit : son appareil de cuisine à 745 dollars est bloqué depuis quinze jours en « exception » chez le transporteur. L’agent travaille proprement — neuf appels d’outils, il récupère la commande, vérifie le suivi, consulte le profil, cherche deux fois la politique de remboursement, confirme qu’aucun ticket n’existe, en ouvre un, documente la chronologie. Puis il clôture le ticket avec le statut « résolu » et répond : « Puisque votre demande est résolue, puis-je vous aider pour autre chose ? »

Deux choses sont fausses. L’exception du transporteur est toujours ouverte : l’état final requis était « en attente », pas « résolu ». Et la cliente n’a jamais reçu de réponse à sa question réelle. Un évaluateur qui lit les appels d’outils voit neuf appels bien formés ; un évaluateur qui regarde la réponse voit une réponse polie. C’est la base de données qui n’est pas d’accord.

ThinkingBox mesure exactement cet écart. Sur 507 workflows métier à état, chaque tâche est exécutée 20 fois depuis un backend propre identique, et l’agent est noté sur l’état terminal et les effets de bord qu’il laisse. Le cadre statistique distingue trois nombres : le pass@1 (« comment ça se passe d’habitude ? »), le pass@20 (« est-ce qu’il peut y arriver au moins une fois ? ») et le observé 20/20 (« est-ce qu’il réussit toujours les 20 tentatives ? ») — un comptage littéral, sans estimateur ni lissage.

L’expérience la plus parlante est l’ablation en ensemble commun : 121 680 essais valides, 12 modèles, 79 853 échecs aux contrôles exécutables. Parmi ces échecs, 67,24 % ont terminé proprement — outil modifiant l’état appelé, aucune erreur finale signalée. Les contrôles ont ensuite trouvé des valeurs de champ erronées dans 77,61 % des cas, des effets supplémentaires non voulus dans 43,30 % et des effets requis manquants dans 25,36 %. Autrement dit : la majorité des défaillances ne lèvent aucun drapeau. Elles produisent, en silence, un système dans un état faux. Une trajectoire est une affirmation ; l’état de la base de données est la preuve.

ThinkingBox est disponible via OpenEnv sur Hugging Face, avec un jeu de serveurs MCP et un serveur d’environnement. La conséquence pratique est directe pour quiconque opère des agents en production : une sonde qui lit les logs et les réponses ne suffit pas. Il faut lire les records.

ArrivalBench : réexécuter sous un ordonnancement adverse

Le même déplacement méthodologique structure ArrivalBench, qui s’attaque aux pipelines de données générés par des agents. Les bancs existants notent un pipeline en l’exécutant une fois contre un instantané figé. ArrivalBench le réexécute sous des ordonnancements de livraison adverses mais rejouables : enregistrements en retard, dupliqués, hors ordre, réessayés. Comme l’oracle recalcule l’état final au lieu de classer, un tableau faux et un plantage deviennent deux verdicts distincts — et c’est tout l’intérêt : un plantage est visible pour la supervision que l’équipe exécute déjà, un tableau faux ne l’est pas.

Sur les 40 tâches construites par les auteurs, la réimplémentation de la notation à exécution unique certifie 86 à 100 % des pipelines produits par onze modèles. La réexécution des mêmes artefacts révèle que 7,0 à 79,2 % des pipelines certifiés sont silencieusement faux. Le fossé n’est pas créé par la boucle de réparation : à modèle et tâche donnés, les pipelines réparés contre le test instantané échouent au rejeu à peu près autant que ceux qui l’avaient passé du premier coup. Un détail opérationnel : dans chaque modèle, les dangers d’idempotence échouent plus souvent que les dangers d’ordonnancement.

Le résultat le plus subtil concerne les interdictions : séparer un mauvais résultat d’un plantage change la lecture des interventions. Un avertissement de danger fait chuter l’échec silencieux d’un modèle de 48,2 % à 10,5 %, mais fait grimper son taux de plantage de 9,0 % à 37,0 % — si bien que l’échec global ne bouge que de 51,0 % à 44,0 %. Autrement dit, on convertit de la corruption invisible en panne visible. C’est un progrès, mais pas une solution.

DeReAct : séparer l’action de la décision

Si l’état final est le juge, comment un agent peut-il éviter de clôturer à tort ? DeReAct propose une réponse architecturale : externaliser deux politiques de portier. Un Critic valide les actions proposées avant exécution ; un Context Manager reconstruit un état soutenu par l’environnement et certifie la clôture de la tâche. Le constat de départ est net : un agent ReAct classique confie à une seule politique LLM la proposition d’actions, l’interaction avec l’environnement et la décision de fin. Ce couplage rend impossible d’imposer indépendamment l’autorisation d’agir et le contrôle de la clôture — d’où les erreurs qui se propagent et les clôtures non étayées.

Sur GAIA et SWE-bench Verified, DeReAct améliore le Pass@1 surtout pour les cerveaux faibles : +6,5 à 7,0 points pour Qwen3-Coder-480B, +4,2 à 5,2 points pour Claude Sonnet 4.5. Les gains s’estompent à mesure que le modèle central progresse. Avec Claude Opus 4.5, le Pass@1 reste comparable à ReAct, mais les trajectoires sont plus complètes en preuves et plus satisfaisantes en contraintes : le contrôle de clôture peut troquer une terminaison précoce contre un meilleur ancrage. La leçon est cohérente avec le reste de la journée — quand les échecs ciblés sont rares et que la politique de portier est suffisante, externaliser le contrôle ne coûte presque rien et rapporte de la rigueur.

Fast Models, Slow Evidence : le bilan d’un modèle de décision « System-1 »

Un harnais d’agent prend beaucoup de petites décisions typées par tâche : quel modèle appeler, quel outil utiliser, si le texte récupéré est pertinent, si l’entrée porte une injection. Les modèles de décision « System-1 » répondent en une seule passe avant, avec des probabilités de classe — promesse d’économies de coût et de latence par rapport aux appels LLM. L’étude « Fast Models, Slow Evidence » en donne une évaluation appariée : un modèle à poids ouverts (Laya) et un modèle hébergé (Jev), sur 11 points de décision construits à partir de 18 sources publiques, 7 283 cas de base plus 6 640 variantes de robustesse, entrées identiques au bit près, tests appariés, contrôles de reproductibilité inter-matériel et inter-jour.

Résultat : Jev est nettement plus précis sur 9 des 11 points (+10,8 à +46,0 points de pourcentage). Aucun des deux ne bat le hasard sur le routage de modèle zero-shot, et ils sont à égalité sur le filtrage de pertinence RAG. Laya change 30 % de ses réponses quand l’ordre des options est inversé, et s’effondre quand les candidats sont nombreux ou similaires : 31 % à 50 outils plus proches voisins, contre 98 % pour Jev sur les items à outil correct unique.

Mais le plus instructif est l’auto-audit. Trois erreurs d’analyse et un confond de conception ont déformé les conclusions de déploiement : un coût de pré-filtrage omis (économie annoncée de 23,9 %, réelle de 4,3 %), une précision de portier présentée comme qualité bout-en-bout (58 % contre 98 %), des seuils choisis in-sample (cible 5 %, jusqu’à 17 % de ratés hors échantillon), et un « effet de canal » sur les faux positifs d’injection qui disparaît avec du contenu natif au canal. Deux autres confonds suspectés n’ont pas changé les conclusions. Tous les cas, sorties brutes et code d’analyse sont publics. Le papier ne vend pas un modèle : il vend une méthode d’évaluation.

VERSE : l’optimiseur qui s’optimise, mais seulement avec vérification

VERSE pose une question simple : un optimiseur de harnais peut-il mieux améliorer un agent s’il améliore aussi sa propre manière de diagnostiquer, d’éditer et de tester ? Deux observations guident la conception. D’abord, une étude contrôlée montre que l’auto-évolution d’optimiseur échoue à améliorer la performance sans vérification par exécution, mais atteint le meilleur résultat de l’étude quand la vérification est disponible. Ensuite, sur cinq exécuteurs, les optimiseurs auto-évolutifs se construisent leurs propres outils d’analyse de défaillance, de vérification, d’audit d’entraînement et de contrôle de workflow.

VERSE laisse l’optimiseur tester ses brouillons d’édition, rejouer les défaillances et perturber les étapes suspectées avant soumission, en suivant les correctifs et les régressions d’un tour à l’autre. Sous protocole partagé, il améliore les quatre optimiseurs de harnais évalués sur des tâches SWE-rebench tenues à l’écart et des tâches hors distribution plus récentes en cinq langages. Le meilleur harnais sélectionné en validation atteint 42,3 % et 37,7 % de précision, contre 39,2 % et 29,3 % pour les meilleurs baselines.

GHOST : la contrainte oubliée vingt tours plus tôt

Le papier GHOST pointe une faille de gouvernance propre aux agents longue portée. Sous des conditions d’interaction bénignes, un agent peut exécuter une action qui viole une contrainte de sécurité spécifiée plusieurs tours auparavant — d’où l’acronyme : Governance Hazard from Overlooked Safety Constraints across Turns. Ces événements ne sont pas isolés : le taux d’occurrence atteint 11,5 % sur GPT-5.5. Les auteurs montrent théoriquement que si le danger de violation conditionnelle résiduel le long de chaque préfixe sûr est minoré par une suite non sommable, l’exécution entre dans la région de danger presque sûrement. D’où STAR-Guard, une défense à deux couches : restauration sémantique des contraintes historiques applicables, puis audit déterministe avant exécution. Dans les expériences sous GPT-5.5, plus aucun événement GHOST n’est observé.

🤖 Nouveaux outils : mémoire, contexte, recherche, coût

Sous la question de la fiabilité, plusieurs briques concrètes.

GraphMemory / « Decoupling Memory from Context » formule la mise à jour d’un système de mémoire d’agent comme une procédure d’optimisation sur le contexte du modèle, puis propose GraphMemory, une mémoire légère sous forme de graphe qui accumule, raffine, organise et relie des stratégies réutilisables. Pour chaque requête, seul le sous-graphe pertinent est récupéré : sous récupération bornée, la quantité de mémoire récupérée reste constante à mesure que le nombre d’exemples traités croît. La méthode obtient des performances comparables aux baselines en utilisant environ 81 à 85 % de tokens en moins pour construire la mémoire.

Trained Agentic Context Management prend le problème par l’autre bout. Au lieu d’entraîner un contexte long natif ou de concevoir un harnais de contexte long, on entraîne un modèle sur le harnais le plus simple possible : un outil pour s’appeler soi-même avec n’importe quel prompt, et un outil pour lire une plage de tokens du contexte d’entrée. En affinant Qwen3.6-35B-A3B sur un jeu synthétique diversifié avec ce harnais, 8 000 tokens de contexte suffisent pour égaler GPT-5.4 avec 1M de tokens sur OOLONG-synth quand les documents dépassent 40K tokens.

MIRA (Meta-Reasoning for Iterative Research Agents) sépare l’allocation de recherche de l’exécution : une méta-raisonneuse de boucle externe organise le contexte à partir d’un dossier de recherche persistant, puis rédige un ordre de travail ; un exécuteur de boucle interne « frais » exécute chaque ordre, si bien que l’exécution devient la transition entre les actions de méta-raisonnement. Sans entraînement de politique, MIRA améliore l’inférence longue portée et alloue mieux le calcul supplémentaire en démonstration de théorèmes et en recherche ouverte d’architecture neuronale. Le critique génératif qui prévoit le retour restant surpasse les alternatives au niveau token.

Inherit-MAS rend l’héritage explicite à deux niveaux. Un méta-modèle synthétise un workflow d’agents travailleurs avec rôles, entrées de communication déclarées et permissions d’outils ; un juge score chaque candidat exécuté et diagnostique ses déficiences. L’héritage de workflow part du dernier candidat complété, peut écarter des nœuds jugés inutiles et appliquer une édition validée. L’héritage d’exécution ne réutilise les résultats stockés que si la requête résolue complète et le contexte d’exécution correspondent — évitant des appels redondants. Avec des travailleurs GPT-4o-mini : 55,4 % de complétion sur WorkBench et 49,7 % de F1 joint sur HotpotQA FullWiki, au-dessus d’EvoAgent, EvoMAS et TacoMAS. L’héritage d’exécution réduit les tokens des travailleurs de 29,1 % sur WorkBench et 34,6 % sur HotpotQA.

CITA (Comparative Inference for Tool-use Agents) attaque le crédit à long terme : au lieu de récompenser l’issue finale, l’agent doit estimer la valeur longue portée d’une invocation d’outil possible avant de l’exécuter. Comme les trajectoires journalisées ne contiennent que l’invocation réellement prise, CITA entraîne un modèle d’inférence comparatif à partir de signaux appariés mêlant comportement d’outil observé, supervision d’un simulateur bayésien de graphe d’outils, et comparaisons LLM. Sur trois bancs d’outils et plusieurs LLM, CITA améliore régulièrement Tool F1 et la réussite des tâches.

When Terminal-Agent Training Stalls documente les trois classes de panne d’un pipeline méta-agent (invalidité du banc, fragilité du harnais, désalignement de récompense). La refonte des prompts et l’extension du contexte multiplient par 5,6 la solvabilité de base, mais un modèle de 9B sature à 81,3 % de pass@2 moyen en 20 étapes sur des tâches générées par Claude Opus. Ajouter des tâches difficiles fait tomber ce pass@2 à 20,6 % sans changer la configuration d’entraînement : la bande de solvabilité est propre au modèle, et la fiabilité des méta-agents exige calibration de bande, audits de vérificateur et comptabilisation des erreurs d’infrastructure comme critères de première classe.

Lost in the Request rappelle qu’une même demande formulée différemment n’est pas la même tâche pour un agent. Les auteurs construisent des variantes validées selon cinq axes de style de communication et quatre conditions dialectales sur trois bancs (un pipeline RAG et deux agents à outils). Les requêtes indirectes réduisent la performance partout ; les requêtes formelles dégradent les deux bancs agentiques. Les causes diffèrent : les requêtes verbeuses nuisent surtout au récupérateur lexical ; les variantes indirectes et dialectales restent nuisibles même quand l’email pertinent est récupéré. En mode agentique, ces variantes font surtout omettre des actions requises, pas commettre plus d’actions non étayées. Une réponse réussie ne suffit donc pas à établir la robustesse.

📊 Analyse : de l’éloquence à la comptabilité

Ce corpus dessine un déplacement conceptuel que l’on peut formuler autrement : le champ des agents sort de la rhétorique et entre dans la comptabilité. Trois signaux le confirment.

D’abord, le choix de l’oracle. ThinkingBox et ArrivalBench ne jugent pas le texte de l’agent, ni même sa séquence d’actions : ils jugent l’état du monde qui résulte de l’exécution. C’est une rupture avec les habitudes d’évaluation dominantes, où un LLM juge lit les réponses. Elle a un coût — il faut un environnement rejouable, un backend instrumenté, un oracle qui recalcule — mais elle produit un verdict binaire incontestable : le champ vaut X, il devrait valoir Y. Le chiffre de ThinkingBox est d’ailleurs sans appel : 77,61 % des échecs portent sur des valeurs de champ erronées. Ce n’est pas de la dérive stylistique, c’est de la donnée corrompue.

Ensuite, la distinction entre panne visible et corruption invisible redevient centrale. ArrivalBench le quantifie de manière presque ironique : forcer une alerte de danger ne réduit pas tant l’échec global qu’il ne le déplace — plus de plantages, moins de tableaux faux. Pour une équipe d’exploitation, ces deux régimes appellent des réponses opposées. Un plantage se détecte, s’alerte, se corrige. Un tableau faux se propage dans des décisions. Toute la valeur d’un banc comme ArrivalBench est de rendre le second visible, et donc réparable.

Troisièmement, l’économie de la vérification devient un objet de recherche à part entière. VERSE montre que l’auto-évolution sans vérification par exécution ne s’améliore pas — et que le meilleur résultat n’arrive que quand la vérification est disponible. SR-OPD et les méthodes de distillation on-policy (voir notre article technique) posent la même question sous un autre angle : où dépenser les tokens de supervision ? DeReAct ajoute une nuance précieuse : externaliser le contrôle de clôture troque une terminaison précoce contre un meilleur ancrage. La rigueur a un prix en temps d’exécution, et ce prix doit être arbitré, pas subi.

Un fil traverse enfin tout le corpus : la longueur est l’ennemi. GHOST frappe parce que la contrainte oubliée vit à vingt tours de distance ; MIRA et GraphMemory attaquent la mémoire qui déborde ; Lost in the Request montre que la variation de formulation dégrade quand le rappel échoue ; le méta-raisonnement et l’héritage d’exécution cherchent à ne pas refaire le travail déjà fait. L’agent fiable du second semestre 2026 n’est peut-être pas celui qui raisonne le mieux, mais celui qui n’oublie pas ce qu’il a promis.

🎯 À retenir

Une réponse n’est pas une preuve. ThinkingBox note 507 workflows métier exécutés 20 fois chacun : 67,24 % des échecs terminent proprement, 77,61 % portent sur des valeurs de champ erronées. L’oracle doit être l’état final, pas le texte.
Le rejeu est le test. ArrivalBench certifie 86 à 100 % des pipelines à exécution unique, puis trouve 7,0 à 79,2 % de certifiés silencieusement faux sous ordonnancement adverse. Les dangers d’idempotence sont les plus fréquents.
Externaliser le contrôle paie surtout sur les modèles faibles. DeReAct gagne +6,5-7,0 points (Qwen3-Coder-480B) et +4,2-5,2 points (Claude Sonnet 4.5), avec des gains qui s’estompent à mesure que le cerveau progresse.
La vérification est la condition de l’auto-évolution. VERSE ne progresse pas sans vérification par exécution ; avec, il atteint 42,3 % et 37,7 % contre 39,2 % et 29,3 %.
Les contraintes de sécurité s’oublient. GHOST : 11,5 % d’occurrences sur GPT-5.5 sous interactions bénignes ; STAR-Guard les élimine dans les expériences rapportées.
Économiser la mémoire et le contexte est possible. GraphMemory : 81-85 % de tokens de construction en moins ; harnais entraîné : 8 000 tokens égalent 1M de tokens sur OLOONG-synth au-delà de 40K.
Méfiance sur les modèles « System-1 » et les routeurs. Fast Models, Slow Evidence : aucun modèle de décision ne bat le hasard sur le routage zero-shot, et 30 % des réponses de Laya changent quand l’ordre des options s’inverse.

Pour les équipes qui déploient des agents, la conséquence est opérationnelle : instrumentez le backend, pas seulement la conversation. Journalisez l’état final attendu, comparez-le à l’état obtenu, et rejouez sous conditions adverses. Le reste — l’éloquence, la fluidité, la politesse de la réponse — n’est qu’une hypothèse sur ce que le système a fait.