À retenir
- L’auto-amélioration est souvent un ensemble de petites boucles : proposer un changement, le tester, conserver ce qui fonctionne et recommencer.
- La partie effrayante n’est pas seulement l’autonomie. C’est un système qui s’améliore selon une récompense mal définie ou une évaluation faible.
- Les builders peuvent utiliser ces boucles de manière sûre seulement lorsque les tests, les objectifs et les conditions d’arrêt sont clairs.
Quand vous entendez « auto-amélioration récursive », vous pensez probablement à l’une de deux choses. Soit c’est le début de l’AGI et nous devrions tous être terrifiés. Soit ce n’est que du prompt tuning avec un meilleur marketing. Les deux sont faux. Et les deux vont vous coûter cher si vous ne faites pas attention à ce qui se passe réellement en ce moment.
Andrej Karpathy a récemment rendu open source un projet appelé autoresearch. Un prompt Markdown. 630 lignes de code d’entraînement. Un seul GPU. Il l’a laissé tourner pendant deux jours. Le système a exécuté 700 expériences et trouvé 20 optimisations qui amélioraient l’entraînement. Aucun humain n’y a touché. Le CEO de Shopify l’a essayé la même semaine. Il l’a laissé tourner toute la nuit. 37 expériences. Un gain de performance de 19 % au matin.
Aidez-moi, gratuitement! Si vous avez l’habitude du blogue, pensez à vous abonner à la chaîne YouTube! C’est maintenant ou jamais! Après 6 ans de publications hebdomadaires, je suis en route vers les 100 000 abonnés cette année! Cliquez ici pour vous abonner et recevoir des tonnes de vidéos sur l’ingénierie IA, dont celle liée à cet article!
Ce n’est pas une démo de recherche. C’est un système qui a modifié son propre code, testé si le changement aidait, gardé ce qui fonctionnait, puis recommencé. Encore. Et encore. Et encore. Et cette boucle, sous différentes formes, apparaît partout en ce moment. Dans la manière dont DeepMind économise du compute. Dans la manière dont Sakana AI construit des agents de code. Dans la manière dont j’améliore mes propres skills Claude Code chaque jour sans écrire moi-même la moindre mise à jour.
Je suis Louis-François, CTO et cofondateur de Towards AI. Et aujourd’hui, je veux vous montrer comment cette boucle fonctionne réellement, pourquoi elle peut échouer d’une manière que la plupart des gens n’anticipent pas et comment vous pouvez en mettre une en place vous-même avec rien de plus qu’un fichier de prompt. Entrons dans le vif du sujet.
Le nom officiel de ce nouveau framework agentique que l’on voit apparaître est l’auto-amélioration récursive, mais c’est beaucoup plus simple que ça en a l’air.
Il s’agit simplement de faire en sorte que le système modifie certaines parties de son fonctionnement, teste la nouvelle version, conserve ce qui a aidé, stocke ce qu’il a appris, puis recommence.
C’est tout. Générer, vérifier, garder ou jeter, répéter. C’est ça, « l’auto-amélioration récursive », en quelques mots.
L’optimisation de prompts en fait partie. La recherche de récompenses en fait partie. Les boucles de raisonnement en font partie. Les agents de code qui se modifient eux-mêmes en font partie.
J’ai mentionné mes skills Claude Code plus tôt. Laissez-moi vous expliquer ce que je fais réellement. Dans chaque skill, j’ai une dernière étape qui analyse l’échange que je viens d’avoir avec elle. Ce qui a mal tourné. Ce avec quoi je n’étais pas d’accord. Ce qui pourrait être amélioré. Elle met ensuite à jour ses propres instructions pour la prochaine fois. Quelques lignes de code. Rien de complexe. Mais après plusieurs semaines, les skills deviennent nettement meilleures. Pas parce que je me suis assis pour les réécrire. Parce que les instructions s’enrichissent d’elles-mêmes.
Maintenant, beaucoup de gens entendent « auto-amélioration récursive » et s’imaginent un énorme système intelligent qui réécrit tout son propre fonctionnement. Ce n’est pas ça. C’est un ensemble de petites boucles. Une boucle améliore les traces de raisonnement. Une autre améliore les instructions ou les prompts. Une autre améliore les fonctions de récompense ou les objectifs de la skill. Une autre améliore le choix des prochaines expériences à essayer. Le point n’est pas qu’un seul système réécrive tout. C’est que de plus en plus de couches de la stack IA participent maintenant à leur propre amélioration. Et vous devez construire ces boucles pour vos propres cas d’utilisation.
Maintenant, rien de tout ça n’est apparu d’un seul coup avec le projet de Karpathy. Cette boucle évolue depuis des années. Et cette progression vaut la peine d’être comprise parce qu’elle montre comment nous sommes passés de la théorie à quelque chose que vous pouvez faire tourner sur votre laptop.
L’idée est ancienne. Très ancienne. En 1965, Irving John Good a exposé l’argument de base : si l’intelligence peut servir à concevoir une meilleure intelligence, les améliorations pourraient s’accumuler. En 2003, Schmidhuber l’a formalisée avec la Gödel Machine, un système auto-améliorant qui peut réécrire son propre code s’il peut prouver que la réécriture est bénéfique. Très élégant. Et pas du tout la manière dont l’ingénierie fonctionne réellement, parce qu’en pratique, vous ne prouvez pas à l’avance que votre prochain patch est bon. Vous l’exécutez, vous le testez, vous le comparez et vous le conservez s’il survit. Mais tout ça restait surtout théorique.
C’est cet écart entre la théorie et la pratique qui a changé entre 2022 et 2024.
STaR, sorti en mai 2022, a été l’un des premiers exemples qui a fait fonctionner cette boucle. Le modèle générait ses propres traces de raisonnement, filtrait celles qui menaient à des réponses correctes, puis faisait son fine-tuning sur ces meilleures traces. Le modèle ne faisait donc pas que résoudre des problèmes, il créait lui-même les données d’entraînement qui amélioraient son propre raisonnement au fil du temps. Une boucle simple, une vraie amélioration, pas de magie.
Puis il y a eu Promptbreeder, en 2023. Il a poussé la même idée dans le prompt engineering. Au lieu d’écrire un seul prompt à la main, il faisait évoluer des prompts sur de nombreuses itérations. Mais il faisait aussi évoluer les prompts de mutation qui génèrent de nouveaux prompts. Il n’améliorait donc pas seulement l’output. Il améliorait le mécanisme qui crée les candidats.
Ensuite, nous avons eu Eureka, en octobre 2023, de NVIDIA, qui a déplacé la boucle vers la conception de récompenses pour l’apprentissage par renforcement. Si vous avez déjà fait du RL, vous savez que façonner des fonctions de récompense à la main est l’une des parties les plus fragiles et pénibles de tout le processus. Eureka utilisait un LLM pour générer du code de récompense, testait ces récompenses en simulation et gardait les versions qui produisaient un meilleur comportement robotique. Il a surpassé des experts humains sur 83 % des tâches de leur benchmark. Et il a appris à une main robotique simulée à faire des figures avec un stylo, ce qui, honnêtement, a encore l’air complètement fou.
Puis nous avons eu FunSearch, en décembre 2023, celui qui a rendu tout ce pattern crédible à mes yeux. DeepMind a laissé un LLM générer des programmes candidats, mais la décision finale était prise par une évaluation mathématique rigoureuse, pas par la confiance du modèle lui-même. Cette combinaison, une génération créative accompagnée d’une vérification externe rigoureuse, explique pourquoi FunSearch est devenu une référence aussi importante. FunSearch a ensuite découvert de nouvelles solutions au problème du cap set en combinatoire, un problème que les mathématiciens n’avaient pas résolu. Et ça, ce n’est pas une amélioration incrémentale. C’est une IA qui trouve quelque chose que les humains n’avaient pas pu trouver.
Puis en 2024, quelque chose a changé. La boucle d’amélioration a commencé à se déplacer jusque dans l’évaluateur lui-même.
Self-Rewarding Language Models, en janvier 2024, a montré qu’un modèle peut améliorer certaines parties de son propre mécanisme de feedback, pas seulement sa performance sur une tâche. Self-Taught Evaluators, en août 2024, a poussé ça encore plus loin avec des évaluateurs qui s’améliorent sans aucune étiquette humaine. C’est plus important que ça en a l’air, parce qu’une fois que l’évaluateur devient meilleur, toutes les autres boucles d’auto-amélioration qui en dépendent deviennent aussi plus fortes.
The AI Scientist de Sakana AI a tenté d’automatiser de bout en bout de plus grandes parties du processus de recherche : génération d’idées, recherche bibliographique, expériences, écriture, révision. C’était important non pas parce que le système était parfait, mais parce qu’il montrait toute l’étendue du problème. On pouvait voir à la fois l’occasion et les fissures.
Puis Sakana a sorti la Darwin Gödel Machine, qui a poussé les agents de code auto-modifiants beaucoup plus loin. Elle maintenait une population de variantes d’agents, les faisait évoluer en les laissant réécrire leur propre code et gardait ceux qui obtenaient de meilleures performances aux benchmarks. Sur SWE-bench, elle a fait passer son taux de résolution de 20 % à 50 %. Et elle a développé des capacités que les chercheurs n’avaient pas explicitement programmées : une étape de vérification des patchs, une mémoire des erreurs pour éviter de répéter celles du passé et la capacité d’évaluer plusieurs propositions de solutions. Ces capacités ont émergé de la boucle évolutionnaire.
Et finalement, AlphaEvolve de DeepMind, en mai 2025, a montré à quoi ça ressemble à l’échelle de la production. Gemini Flash explore largement, Gemini Pro apporte de la profondeur, un algorithme évolutionnaire sélectionne les gagnants et des évaluateurs automatisés vérifient tout. Il a accéléré de 23 % un kernel dans la propre architecture d’entraînement de Gemini, trouvé des algorithmes plus rapides de multiplication matricielle et récupère maintenant en continu environ 0,7 % des ressources de compute mondiales de Google.
Et ça nous ramène à l’autoresearch de Karpathy. Ce qui le distingue d’AlphaEvolve ou de la Darwin Gödel Machine, c’est que vous n’avez pas besoin de l’infrastructure de DeepMind pour le faire tourner. Un fichier Markdown. Un seul GPU. De courts runs d’entraînement. Un setup que n’importe quel ingénieur peut reproduire.
Mais voici la partie que la plupart des gens ratent. Avec tous ces systèmes, générer des changements candidats n’est pas la partie difficile. Les modèles sont déjà bons pour produire des variations. La partie difficile est de savoir si une variation est réellement meilleure ou si elle a simplement trouvé un moyen de contourner votre mesure.
L’une des façons les plus rapides de vous tromper avec des agents est de les laisser « s’améliorer » eux-mêmes avec une boucle de feedback trop faible. Le benchmark ou vos métriques montent un peu. Les traces ont l’air plus propres. Le système semble plus organisé. Pendant ce temps, il devient simplement meilleur pour plaire à la métrique que vous lui avez donnée, pas pour faire ce qui vous importe réellement. J’ai vu ça arriver dans ma propre skill qui m’aide à faire de la recherche pour mes articles. Elle était en fait fine-tunée pour Twitter afin de privilégier les controverses plutôt que les sources auxquelles je faisais le plus confiance. J’ai donc dû imposer une contrainte stricte à cette optimisation dans ma boucle automatique d’amélioration par feedback.
L’écart entre ce que votre modèle optimise et ce que vous voulez réellement porte plusieurs noms. L’un d’eux est le reward hacking : l’agent trouve une façon d’obtenir un score élevé sans faire la bonne chose. Ensuite, il y a le surapprentissage du benchmark : le système devient meilleur au test, mais pas à la tâche. Il y a aussi la dérive de l’évaluateur : le juge lui-même se dégrade au fil des itérations. Et l’effondrement du modèle : l’entraînement récursif sur des données générées par le modèle érode la distribution et efface le signal utile au fil du temps. Ce dernier point a été démontré formellement en 2024 par Shumailov et al., et c’est une contrainte stricte pour toute boucle qui s’entraîne sur ses propres outputs.
Donc, pour récapituler, une boucle d’auto-amélioration fonctionne lorsqu’elle continue de toucher à la réalité : grâce à un vérificateur, à une suite de tests, à un simulateur, à une révision humaine (l’étape la plus importante!) et à des processus ancrés dans des métriques que vous contrôlez. Elle casse lorsque la boucle commence surtout à apprendre de ses propres artefacts et de son propre feedback de plus en plus déformé, sans beaucoup de contrôle de la part du builder.
Maintenant, c’est ici que les gens ont tendance à se diviser en deux camps, et les deux ont tort. L’un entend tout ça et affirme que la boucle est impossible à arrêter, que nous nous dirigeons vers l’AGI. L’autre dit que ce n’est que du prompt tuning avec un meilleur marketing.
Le bon modèle mental pour les ingénieurs n’est pas « l’auto-amélioration » au sens dramatique de l’AGI. C’est de l’optimisation guidée par un feedback récursif. Ça semble moins excitant, mais c’est en fait plus utile, parce que nous contrôlons ce processus et pouvons agir dessus.
Et lorsque vous commencez à penser à tout ça comme de l’ingénierie, les questions deviennent très concrètes. Qu’est-ce que le système a le droit de modifier? Quel est le coût de chaque itération? À quel point le mécanisme de rejet est-il robuste? Quelle mémoire la boucle conserve-t-elle? Comment éviter de contaminer l’itération suivante avec les déchets de la précédente? Comment détecter que les métriques internes montent alors que l’utilité plafonne?
Et la réponse, comme toujours, est de commencer par quelque chose de simple. Ajoutez de la complexité et des étapes supplémentaires seulement lorsque vous y êtes forcé. En passant, les agents de code sont plutôt mauvais à ça par défaut si vous les laissez faire.
N’essayez pas d’automatiser tout le laboratoire de recherche dès le premier jour. Placez une seule couche bien délimitée dans une boucle où le signal est clair, comme ajouter une étape dans le fichier de votre skill Claude qui analyse tout ce avec quoi vous étiez en désaccord pendant l’échange et met à jour la skill pour qu’elle fasse mieux la prochaine fois. Laissez le modèle générer. Laissez un vérificateur faire l’évaluation, ou faites-la vous-même. Gardez les versions gagnantes. Journalisez tout. Assurez-vous de pouvoir revenir facilement en arrière. Surveillez le reward hacking. Surveillez les faux progrès.
Donc oui, cette histoire de « boucle d’auto-amélioration récursive » est applicable aujourd’hui aussi. Sur vos propres fichiers de skills, vos propres prompts et vos propres pipelines d’agents. Les améliorations s’accumulent au fil du temps et, à mesure que les modèles deviennent meilleurs, vos instructions, vos outils et tout votre harness s’améliorent aussi.
Mais ça n’élimine pas le besoin d’humains. Ça change le travail. Le rôle de l’ingénieur ne consiste plus seulement à écrire des solutions, mais à concevoir les évaluateurs, les environnements, les permissions et les boucles de feedback qui produisent des solutions fiables. Le goulot d’étranglement passe de « demander une bonne réponse au modèle » à « créer les conditions dans lesquelles les meilleures versions survivent de façon fiable et les pires disparaissent tout aussi sûrement ».
Honnêtement, avec l’état actuel des LLMs et des agents, c’est là que le travail intéressant commence aujourd’hui.
Si vous avez déjà mis en place une forme de boucle d’auto-amélioration dans votre propre système, je veux en entendre parler. Quelle couche avez-vous automatisée en premier? Dites-le-moi dans les commentaires.
Merci d’avoir lu. Si ça vous a été utile, vous allez probablement aussi adorer la chaîne YouTube! Découvrez-la ici et pensez à vous abonner pour plus de contenu sur l’ingénierie IA :)
FAQ
Que signifie « IA auto-améliorante » ici?
Il s’agit d’une boucle assistée par l’IA qui modifie des prompts, du code, des expériences ou des instructions, teste le résultat et conserve les changements utiles.
Pourquoi l’auto-amélioration peut-elle vous tromper?
Si l’évaluation est faible, le système peut améliorer le score tout en empirant le comportement réel.
Comment les builders devraient-ils utiliser les boucles d’auto-amélioration?
Gardez un objectif bien délimité, journalisez les changements, exécutez de vrais tests et arrêtez la boucle lorsqu’elle commence à optimiser la mauvaise cible.
Comment un modèle peut-il créer ses propres données d’entraînement?
Il génère des solutions candidates ou des traces de raisonnement, puis les filtre avec des vérifications d’exactitude avant le fine-tuning.
Pourquoi la génération de récompenses peut-elle améliorer l’apprentissage d’un robot?
Un LLM peut proposer du code de récompense, tandis qu’une simulation teste quelles versions produisent réellement un meilleur comportement.
Qu’est-ce qui rendait crédible la boucle d’amélioration de FunSearch?
Le LLM proposait des programmes candidats, mais un évaluateur mathématique rigoureux décidait lesquels survivaient. Le modèle n’évaluait pas son propre travail.