Évaluer un agent IA: compétence, résistance aux injections et mémoire

Deux travaux publiés sur les agents IA pointent le même angle mort: quand un modèle agit dans un environnement outillé, il ne suffit plus de mesurer sa réponse, il faut tester ce qu’il fait, ce qu’il retient et ce qu’il interprète. D’un côté, un playbook propose une batterie d’évaluation pour vérifier qu’un agent peut traiter du contenu semi-sensible avec écriture réelle. De l’autre, une analyse rappelle qu’un agent peut transformer une exception de gestion en pseudo-politique. Le sujet compte pour les entreprises, car une erreur de mémoire ou d’autorité peut se propager vite, et proprement — ce qui est souvent le pire scénario.

Quand un agent écrit, le test change de nature

Le premier document décrit un playbook d’évaluation d’agents IA, conçu pour vérifier si un modèle peut être jugé digne de confiance dans un cadre où il a accès à des outils et à des écritures réelles. Le protocole a été validé sur quatre modèles — gpt-oss-120b, qwen-3.8-27b, gemma-4-31b et Claude Sonnet 5 — avec une même pile logicielle. L’idée est simple: ne pas confondre capacité à répondre avec capacité à agir.

Quatre axes sont testés séparément: la compétence sur la tâche, la résistance aux injections, la discrimination d’autorité et la fiabilité de la mémoire. Le playbook insiste aussi sur un point pratique: l’accès en écriture doit être borné mécaniquement, pas seulement “rappelé” à l’agent. Dans son exemple, Hermes est configuré avec un profil isolé, un mode manuel pour les approbations et un périmètre de travail limité à /opt/data. Bref, le bocal compte autant que le poisson.

Le piège des exceptions qui ressemblent à des règles

Le second texte s’attaque à un problème plus discret, mais redoutable en entreprise: un agent peut retrouver un historique exact, puis en tirer une conclusion fausse. Une exception accordée une fois devient, pour la machine, une preuve qu’elle peut être répétée. Un ticket fermé, une remise accordée ou un délai prolongé peuvent donc se transformer en pseudo-précédent si le contexte d’autorité n’est pas explicite.

L’analyse propose de classer les décisions en quatre catégories: policy pour une règle approuvée, procedure pour sa mise en œuvre, exception pour une dérogation limitée, et anecdote pour un simple antécédent sans autorité. Seules les deux premières devraient être réutilisables par défaut. Les exceptions, elles, méritent une “enveloppe” de contexte: qui a approuvé, pourquoi, pour quel périmètre, et jusqu’à quand. Sans cela, un agent peut faire de la gouvernance par mémoire, ce qui est une drôle d’idée à déléguer à une machine.

Les benchmarks jugent le moteur, pas seulement le volant

Le deuxième article apporte un contrepoint intéressant: il montre qu’on peut aussi évaluer le harness, c’est-à-dire tout le système d’exécution autour du modèle — boucle, outils, contexte, état, reprise et vérification. Ce que les auteurs de HarnessDev testent n’est plus seulement la qualité de la réponse, mais celle du dispositif runnable que le modèle construit. Le changement de cible est important pour les usages réels, car un agent mal armé peut échouer même avec de bons poids.

Les résultats sont contrastés. En Self-Eval, Opus 4.8 affiche la meilleure moyenne à 67,8, contre 86,2 pour une référence conçue par des humains. Mais l’écart varie selon les domaines: 69,3 sur SWE-Pro face à 80,0 pour la référence, 68,8 sur Terminal-Bench contre 88,8, et seulement 52,6 sur BrowseComp quand la référence atteint 92,2. À l’inverse, l’écriture et l’expérimentation ML résistent mieux, avec 84,6 sur EQ-Bench3 et 32,9 sur MLE-bench. Les auteurs soulignent aussi que le volume de code généré ne prédit pas la qualité, et que beaucoup de mécanique produite ne s’exécute jamais.

Ce que ça change pour les équipes IA

Pris ensemble, ces textes dessinent une règle de bon sens qui manque encore souvent aux déploiements d’agents: il faut tester non seulement ce que le modèle sait, mais ce qu’il est autorisé à conclure à partir de ce qu’il lit. Cela concerne les outils de support, les workflows métiers, la relation client, les droits d’accès ou la gestion de tickets. Dès qu’un agent peut relire l’historique et réécrire dans un système, le risque n’est plus seulement l’erreur factuelle. C’est l’erreur de statut.

La leçon vaut aussi pour les directions techniques: un bon score en benchmark ne dit pas grand-chose si l’harness est fragile, et une mémoire bien branchée ne garantit pas une bonne autorité d’usage. Les entreprises qui veulent industrialiser des agents devront donc documenter leurs sources, baliser leurs écritures et distinguer clairement ce qui relève d’une règle, d’une procédure ou d’une exception. Sinon, l’agent ne “comprendra” pas qu’une dérogation reste une dérogation.

Familles : Tech / Informatique / Digital, Droit, Secteur Public / Collectivités