Un agent IA qui tient le journal de ses erreurs dépasse un modèle trois fois plus gros

Une équipe de Google Research a mesuré ce que devient un agent IA quand on lui fait tenir le journal de ses propres échecs. Le gain est large, mais la mesure qui compte est ailleurs : elle dit que ce carnet ne doit surtout pas être mis entre les mains de l’agent au moment où il travaille.

L’étude s’appelle WikiSkill, elle a été déposée sur arXiv le 27 août sous la référence 2608.27454, et elle part d’un constat que reconnaîtra quiconque pilote un agent depuis quelques semaines : les consignes qu’on lui donne finissent par grossir sans qu’on sache plus très bien pourquoi chaque ligne est là.

Le problème que le papier attaque

Une compétence, au sens où l’entendent ces travaux, est un simple dossier sur le disque : un fichier SKILL.md avec une description courte et des instructions de procédure. C’est le format ouvert qu’Anthropic a poussé et que les agents savent lire. Son intérêt est d’accumuler du savoir sans toucher aux poids du modèle.

Plusieurs méthodes récentes font déjà écrire ces compétences par la machine : on lance l’agent sur des tâches d’entraînement, on lit ses traces d’exécution, et on réécrit la consigne en fonction de ce qu’on a vu. Les trois auxquelles WikiSkill se compare, Trace2Skill, EvoSkill et SkillOpt, partagent cette boucle.

Le reproche des auteurs tient en une phrase : ce qui a guidé la réécriture disparaît. Il reste la consigne finale, pas le raisonnement qui l’a produite, ni la liste des tentatives ratées. À l’itération suivante, la machine repart d’une page à moitié blanche et repropose parfois ce qui a déjà échoué.

Trois étages, et un seul qui ne s’efface jamais

La réponse de WikiSkill est de séparer ce que tout le monde mélange, en trois dossiers :

• raw/ garde les traces d’exécution brutes, complètes, et immuables : chaque appel d’outil, chaque réponse, chaque raisonnement.
• wiki/ compile ces traces en connaissances structurées. Un répertoire patterns/ où chaque fichier documente un mode de défaillance ou une stratégie qui marche, un journal d’évolution logs.md, et un skill-impact.md qui trace, proposition par proposition, ce qui a été tenté, le diff exact, le score obtenu et le verdict.
• skills/ contient les compétences actives, avec pour chacune un SKILL.md et un PURPOSE.md qui renvoie aux motifs du wiki qui l’ont motivée.

Quatre rôles se relaient à chaque tour : l’agent exécute les tâches avec les compétences du moment, un Wiki Maintainer analyse les traces et met à jour le wiki, un Skill Proposer lit le wiki et propose une seule modification de compétence, et un mécanisme de validation accepte ou annule.

Le point de conception qui porte tout le reste tient en une ligne : une compétence peut être annulée, le wiki jamais. Une proposition rejetée laisse quand même sa trace dans skill-impact.md, avec son diff et son score. C’est ce qui empêche la machine de retenter le même geste trois itérations plus tard.

Les chiffres, et ce qu’ils ne disent pas

Cinq modèles, cinq bancs d’essai : du raisonnement mathématique, de la recherche web, de la manipulation de tableurs, des questions sur documents longs et un environnement textuel interactif.

Sur la moyenne des cinq bancs, Gemini-3.5-Flash passe de 49,5 % sans compétences à 68,1 % avec celles que WikiSkill a fait évoluer. Qwen-3.6-27B passe de 39,4 % à 63,3 %. Le cas le plus spectaculaire est le tableur, où ce même Qwen passe de 40,8 % à 81,7 %. Face aux meilleures méthodes concurrentes, le gain de moyenne va de 3,3 à 12,0 points selon le modèle.

Trois précisions que le résumé du papier ne met pas en avant, et qui changent la lecture.

Sur l’environnement interactif ALFWorld, Gemini-3.5-Flash affiche 85,9 % partout, avec ou sans compétences, pour toutes les méthodes : il atteignait déjà 100 % sur le jeu de validation avant l’évolution, qui s’est donc arrêtée tout de suite. Ce n’est pas une égalité, c’est un banc saturé.

Sur les documents longs, le plus petit modèle testé régresse : Qwen-3.5-4B tombe de 30,2 % à 28,5 %. Les auteurs l’expliquent sans détour, il n’arrive pas à suivre les procédures de recherche en plusieurs étapes et revient à sa manière habituelle de lire.

Enfin, les jeux de validation sont minuscules. Dix tâches pour la recherche web, dix-huit pour les mathématiques, quarante pour le tableur. C’est sur ces poignées d’exemples que se décide l’acceptation ou le rejet de chaque compétence. Les auteurs le disent et compensent en moyennant trois exécutions complètes, mais l’ordre de grandeur mérite d’être connu.

Les trois trouvailles qui déplacent quelque chose

Le gain vient du wiki, pas de la boucle. L’expérience de retrait est sans ambiguïté : quand on prive le proposeur de compétences de son wiki, la moyenne tombe de 63,7 % à 48,7 %. Quinze points. La boucle seule, sans mémoire accumulée, ne vaut pas grand-chose.

Donner le wiki à l’agent qui exécute dégrade le résultat. C’est la mesure contre-intuitive, et c’est pour ça que la configuration retenue par les auteurs prive délibérément l’agent d’accès au wiki pendant son travail. Avec cet accès, la moyenne passe de 63,7 % à 60,9 %, et le banc de mathématiques chute de 72,6 % à 64,8 %. L’hypothèse avancée : l’agent va chercher la réponse directement dans le wiki au lieu de s’appuyer sur ses compétences, ses traces deviennent moins instructives, et la compétence produite à partir de ces traces est donc moins bonne.

Les compétences voyagent, et pas dans le sens qu’on croit. Celles évoluées par un Qwen-3.5-4B font passer Gemma-4-31B de 33,9 % à 73,1 % en mathématiques, alors que les compétences que ce même Gemma a écrites pour lui-même le mènent à 56,7 %. Le sens inverse marche aussi mal parfois : les compétences du petit Qwen font tomber Gemini-3.5-Flash de 50,5 % à 18,1 % sur le tableur. L’analyse d’erreurs des auteurs est instructive, le petit modèle avait encodé des rustines, des commandes Python d’une ligne et des règles de conversion de chaînes, qui l’empêchaient lui de se planter mais qui interdisent au gros modèle d’écrire le script complet dont il est capable.

Et la comparaison qui donne son titre à cet article : Qwen-3.5-9B avec ses compétences atteint 47,4 % de moyenne, quand Qwen-3.6-27B sans compétences plafonne à 39,4 %.

Ce que ça change dans votre usage quotidien

Rien de tout cela ne suppose une infrastructure de recherche. La leçon se transpose directement à un fichier de consignes, un CLAUDE.md, un AGENTS.md ou le prompt système que vous recopiez de projet en projet.

Séparez la trace, la connaissance et la consigne. Ce sont trois choses différentes, et les mélanger est exactement ce qui fait gonfler un fichier de consignes jusqu’à l’illisible. Ce qui s’est passé n’est pas ce que vous en avez compris, qui n’est pas ce qu’il faut faire la prochaine fois. Nous avions tiré la même conclusion en vidant le nôtre, dans ce qu’on met vraiment dans un CLAUDE.md.

Gardez la trace des consignes que vous avez retirées. C’est le geste le moins naturel et le plus rentable du papier. Quand une consigne n’a rien donné, la supprimer ne suffit pas : notez qu’elle a été tentée et qu’elle a échoué. Sans ça, vous la réécrirez dans trois semaines, avec la même conviction. Le skill-impact.md de WikiSkill ne fait rien d’autre.

Mesurez avant d’adopter. Chaque modification est ici acceptée ou annulée sur un score, pas sur une impression. Vous n’avez pas de jeu de validation, mais vous pouvez garder trois ou quatre tâches représentatives et les rejouer après avoir touché aux consignes. Sans cette contrepartie, on empile des règles dont aucune n’est mesurée.

Ne donnez pas tout le carnet à l’agent qui travaille. C’est la transposition directe de la mesure contre-intuitive. Le fichier qui sert à fabriquer les consignes n’est pas celui qu’on charge dans le contexte pendant l’exécution. Le second doit être court et impératif, le premier peut être long et documenté.

Relisez vos consignes quand vous changez de modèle. Une consigne née d’un contournement est une béquille : elle aide le modèle pour lequel elle a été écrite et bride celui qui n’en a pas besoin. Le passage de 50,5 % à 18,1 % cité plus haut n’a pas d’autre cause.

Une consigne courte n’est pas une consigne pauvre. La longueur des compétences produites varie du simple au triple selon le modèle : 119 à 129 lignes de markdown en moyenne chez les Qwen, 81 chez Gemini-3.5-Flash, 45 chez Gemma-4-31B. Le modèle qui obtient la meilleure moyenne de toute l’étude écrit donc des compétences un tiers plus courtes que les plus bavards.

Le principe général, chez nous, porte un autre nom mais fait le même travail : nos règles de méthode et notre journal de bord sont deux fichiers séparés, et une règle n’y entre que si elle cite l’erreur qui l’a produite. Le Stop hook qui empêche la répétition des mêmes erreurs en est la version automatisée.

Avant d’y croire tout à fait

Les auteurs listent leurs limites, et la première est la bonne. Pour isoler la qualité des compétences, ils les injectent toutes dans le prompt système. Autrement dit, ils n’évaluent jamais le problème qui commence au bout de trois mois d’usage réel : retrouver la bonne consigne quand il y en a cinquante, et ne pas charger les quarante-neuf autres. C’est aujourd’hui le point douloureux, et le papier le met explicitement hors de son périmètre.

Deuxième limite reconnue : le wiki grossit sans fin, et rien n’est prévu pour l’élaguer. Troisième : aucune tâche longue, de celles qui s’étalent sur des centaines d’actions.

Reste l’idée, empruntée à une note d’Andrej Karpathy sur le wiki des modèles de langage, et que ces mesures rendent difficile à écarter : ce qui fait progresser un agent n’est pas la quantité de consignes qu’on lui donne, c’est la qualité de ce qu’on a compris de ses échecs, et le fait de l’avoir écrit quelque part qui ne s’efface pas.