Laissez un agent réécrire lui-même son propre cadre de travail, nourrissez-le des retours d’une poignée de tâches de test, et il finira par réussir ces tâches-là. Une équipe de Google Cloud AI Research, épaulée par des chercheurs de Stanford et de l’université de Caroline du Nord, montre qu’il les réussit surtout parce qu’il les a mémorisées. Sa méthode, baptisée RRSI, accepte de gagner moins sur l’entraînement pour enfin progresser ailleurs.
Les chiffres du papier, intitulé Regularized Recursive Self-Improvement of Agent Harnesses (auto-amélioration récursive régularisée des harnais d’agents, d’où le sigle), résument l’arbitrage : jusqu’à 14,1 points de gain sur les tâches d’entraînement, jusqu’à 4,7 points sur cinq benchmarks que le système n’a jamais vus, et environ 30 % de tokens (les unités de texte que le modèle lit et produit) consommés en moins à l’exécution par rapport à la version non régularisée.
Le modèle reste figé, son harness se réécrit
Pour lire ces chiffres, il faut d’abord savoir ce qui est optimisé. Le modèle, lui, ne bouge pas : Claude Opus 4.8 reste figé pendant toute l’expérience. Ce qui change, c’est le harness, l’ensemble du code et des consignes qui entourent le modèle et décident s’il lit le bon fichier avant de le modifier, s’il se rattrape après une erreur, s’il livre proprement son résultat.
Selon les auteurs, une bonne part des progrès récents des agents vient de ce harness, pas de nouveaux modèles. Longtemps, on l’ajustait à la main en épluchant les exécutions ratées. Les méthodes récentes confient ce travail à un modèle de langage, qui réécrit le harness en boucle d’après les retours des tâches de test. Les chercheurs y voient une forme pratique d’auto-amélioration récursive : le système produit le signal qui sert à modifier ce qui pilote son propre comportement.
Vu sous cet angle, l’écart entre 14,1 et 4,7 points devient parlant : le gain sur l’inédit pèse environ un tiers du gain sur l’entraînement. Et RRSI est la méthode qui s’en sort le mieux. Les quatre approches concurrentes testées progressent surtout sur leurs tâches d’entraînement et transfèrent peu de ce progrès aux benchmarks inconnus.
Trois façons de gonfler un score sans progresser
Le papier décrit précisément comment la boucle dérape lorsqu’elle tourne sur un jeu de tâches limité. Trois mécanismes se cumulent :
- la recherche retient des motifs qui ne valent que pour un benchmark donné ;
- elle favorise des candidats qui ont bien scoré par pur hasard ;
- elle empile de la complexité inutile, qui fait monter le score de test sans rendre l’agent meilleur.
Le deuxième mécanisme piège quiconque se fie aux courbes de progression. Une évaluation sur peu de tâches est bruitée ; retenir à chaque tour la meilleure variante revient à retenir aussi la plus chanceuse. Sur dix tours, la chance s’accumule et finit par ressembler à une compétence.
Le symptôme porte un nom en apprentissage automatique : le surapprentissage. Il se déplace simplement d’un étage. Ce ne sont plus les poids du modèle qui collent aux données, mais le code qui l’entoure.
Un budget de modifications qui rétrécit à chaque tour
RRSI ne verrouille aucune partie du harness, qui reste entièrement modifiable. La méthode agit aux deux bouts de la boucle : quand elle propose des changements, et quand elle décide lesquels deviennent permanents.
Côté proposition, un budget plafonne le nombre de modifications indépendantes qu’un candidat peut regrouper. Ce budget diminue au fil des tours : les premières itérations autorisent de larges réécritures, les dernières n’admettent que de petits changements dont on peut relier clairement l’effet à un résultat. Le système garde aussi la mémoire de ses tentatives pour ne pas relancer les mêmes idées perdantes, et explore volontairement les zones du harness encore intactes quand la progression stagne.
Côté sélection, un critique passe en revue chaque proposition et rejette celles qui codent en dur des noms de tâches, des solutions ou d’autres astuces propres au benchmark. Une règle supplémentaire n’accepte un coût de calcul plus élevé que s’il s’accompagne d’un gain mesurable. Les composants devenus inutiles sont retirés.
Moins de tokens, et pas par hasard
Les 30 % de tokens économisés découlent directement de ces règles. Un harness qui a mémorisé ses tests accumule des étapes, des vérifications et des consignes qui ne servent qu’à passer ces tests ; chacune se paie en tokens à chaque exécution. En obligeant chaque surcoût à se justifier par un gain et en élaguant ce qui ne sert plus, RRSI produit un cadre plus léger.
Pour une équipe qui fait tourner des agents en production, cette donnée compte autant que les points de benchmark. Un agent qui consomme trois dixièmes de moins à chaque tâche change l’équation économique d’un déploiement, à performance au moins égale sur des cas qu’il n’a jamais rencontrés.
Le papier avance un dernier résultat, plus discret et sans doute plus utile : sur aucun des benchmarks inédits, la performance de RRSI n’est descendue sous celle du harness de départ, alors qu’un harness qui a appris ses tâches par cœur a justement tendance à décrocher sur ce terrain. Le meilleur gain hors entraînement, 4,7 points, est mesuré sur JobBench.
Des scores d’auto-amélioration à relire avec méfiance
Ces mesures ont leurs limites. Huit benchmarks répartis sur trois domaines (programmation, travail de bureau agentique, conception d’ingénierie) restent un échantillon étroit, avec un seul modèle sous-jacent. Les gains annoncés sont des maxima, « jusqu’à » 14,1 et 4,7 points, qui ne disent rien de la dispersion d’un benchmark à l’autre.
Le papier fournit pourtant une grille de lecture pour toute annonce d’agent qui « s’améliore seul ». Un score obtenu sur les tâches qui ont servi à guider l’optimisation mesure d’abord la capacité de la boucle à s’adapter à ces tâches. Seul l’écart avec des benchmarks tenus à l’écart renseigne sur la compétence acquise. Si vous comparez des frameworks d’agents ou si vous faites optimiser vos propres prompts système par un modèle, exigez ce second chiffre, et gardez de côté un jeu de tâches que la boucle ne verra jamais.
Appliquée aux résultats déjà publiés par d’autres méthodes, cette exigence risque de faire fondre plusieurs progressions spectaculaires. En 2025, la Darwin Gödel Machine de Sakana AI faisait passer son agent de 20 % à 50 % sur SWE-bench en réécrivant son propre code, en évaluant ses variantes sur ce même benchmark. L’équipe de Google a choisi de montrer les deux colonnes. Les prochains travaux sur l’auto-amélioration des agents devront en faire autant.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
