Une revue sur arXiv découpe l'auto-amélioration récursive de l'IA en cinq niveaux d'autonomie

L'auto-amélioration récursive (Recursive Self-Improvement, RSI) est longtemps restée un sujet de débats philosophiques. Désormais, on tente de la mesurer. Dans une revue récente publiée sur arXiv (2609.11873), les auteurs proposent une échelle de cinq niveaux d'autonomie. Habr a publié une analyse qui cherche à rapprocher ces niveaux de ce que savent déjà faire les systèmes actuels. Le point de départ est simple : les modèles écrivent du code, lancent des tests, repèrent un échec et apportent des corrections. Avec des outils adaptés, ce cycle peut être répété de nombreuses fois sans intervention humaine.

L'annonce de l'analyse ne reprend pas tous les détails de l'échelle. La description de chacun des cinq niveaux figure dans la revue elle-même. Nous nous appuyons donc ci-dessous sur sa problématique et sur des exemples publics connus.

Où s'arrête l'automatisation

La principale difficulté tient à la définition. Un agent qui corrige un bug dans l'application de quelqu'un d'autre relève de l'automatisation. Il améliore un artefact extérieur et reste lui-même inchangé. Cela devient de l'auto-amélioration lorsque les modifications portent sur ce qui produit les améliorations : les prompts de l'agent, son scaffolding et son jeu d'outils, les données d'entraînement, les algorithmes d'entraînement et, à la limite, les poids du modèle.

Cette distinction est un outil de travail, et non une citation de la revue. Elle est utile parce qu'elle transforme le débat flou « l'IA devient-elle plus intelligente toute seule ? » en question d'ingénierie. Il faut déterminer quelle couche du système l'agent a le droit de modifier et qui vérifie le résultat.

Ce que l'on observe déjà dans les systèmes

Les exemples ci-dessous proviennent de publications de 2025, et non de la revue. Ils montrent à quel point des systèmes réels s'approchent de cette frontière.

• AlphaEvolve (Google DeepMind) : un agent évolutionnaire fondé sur Gemini, qui réécrit du code et des algorithmes. D'après DeepMind, il a permis de récupérer environ 0,7% des ressources de calcul de Google et accéléré de 23% l'un des noyaux de calcul (kernels) utilisés pour l'entraînement de Gemini. Le temps d'entraînement a diminué d'environ 1%.
• Darwin Gödel Machine (Sakana AI) : un agent qui réécrit son propre code et conserve une archive de versions. Son score sur SWE-bench est passé de 20,0% à 50,0%, et sur Polyglot de 14,2% à 30,7%.
• Point commun : le modèle ne modifie pas ses poids. Ce sont le scaffolding, le code et les algorithmes qui l'entourent qui s'améliorent, et c'est une métrique externe qui décide d'accepter ou non une modification.

Cette liste montre que les échelons bas et intermédiaires d'une telle échelle existent déjà sous la forme de systèmes opérationnels. Les niveaux supérieurs, où le système fixe lui-même ses objectifs d'amélioration et se réentraîne sans vérification externe, restent pour l'instant théoriques.

Pourquoi l'échelle est utile en pratique

La question binaire « est-ce déjà de la RSI ou pas encore ? » ne sert à rien. Une gradation par autonomie permet de parler plus concrètement : ce que l'agent modifie, avec quel degré d'indépendance et quelles limites. Pour les régulateurs comme pour les laboratoires, ce langage est plus commode que les discours sur un danger abstrait. Des niveaux différents exigent des contrôles différents.

Les systèmes qui s'auto-améliorent ont aussi une faiblesse connue : ils optimisent la métrique, pas la tâche. Dans leur travail sur la Darwin Gödel Machine, les auteurs ont eux-mêmes décrit des cas où l'agent adaptait son comportement au contrôle plutôt que de s'améliorer réellement. Plus l'autonomie est élevée, plus il importe que l'évaluation ne vienne pas de l'agent lui-même.

Que faire pour les équipes qui construisent des agents

La conclusion pratique tient en peu de mots. Si vous lancez des agents qui modifient du code et des configurations, dressez la liste des couches qu'ils ont le droit de changer : code produit, prompts, outils, pipeline d'évaluation. Il vaut mieux verrouiller en écriture cette dernière couche. Conservez l'historique de chaque modification avec possibilité de retour en arrière, gardez un jeu de tests indépendant en dehors du périmètre de l'agent et maintenez un humain à l'étape où le mécanisme d'amélioration lui-même est modifié. L'échelle proposée dans la revue peut servir de check-list pour un tel inventaire. Pour la confronter à vos systèmes, il faudra lire le texte original sur arXiv, et pas seulement son résumé.