Un système a-t-il vraiment réalisé une auto-amélioration récursive ?

Aucun système n'a démontré la boucle cumulative que le terme désigne. Ce qui existe, ce sont des tours isolés contre un vérificateur externe, et de la recherche sur des échafaudages : réels tous les deux, et bornés tous les deux. Les résultats publiés sur un modèle se corrigeant sans retour externe sont notablement faibles, et s'entraîner sur des données auto-générées dégrade la qualité au fil des générations. Ces deux constats sont ce que toute affirmation de récursion doit dépasser.

Est-ce la même chose que la singularité ?

L'argument de la singularité prend l'auto-amélioration récursive pour moteur, mais ce sont deux affirmations distinctes. La RSI est un mécanisme qu'on peut chercher et mesurer ; la singularité est une prédiction sur des conséquences. On peut prendre le mécanisme au sérieux comme sujet d'ingénierie sans tenir aucune position sur la prédiction, et c'est la posture utile pour construire des systèmes.

Pourquoi le vérificateur compte-t-il autant ?

Parce que s'améliorer signifie « meilleur », et cela doit être décidé par quelque chose d'extérieur à ce qu'on améliore. Là où une machine peut vérifier la justesse — les tests passent, la preuve se ferme, la partie est gagnée — la boucle tourne et les gains sont réels. Là où la justesse relève du jugement, le système finit par optimiser le substitut que vous lui avez donné. La profondeur de la récursion est une propriété de votre vérificateur, pas de votre modèle.

Faut-il laisser des agents améliorer leurs propres prompts et outils en production ?

C'est raisonnable et beaucoup d'équipes le font, à trois conditions : que la note vienne d'un jeu réservé que la boucle ne peut pas voir, que tout changement adopté soit imputable à une exécution, et qu'une personne ou une politique commande l'adoption. Sans cela, vous n'avez pas automatisé l'amélioration, vous avez automatisé la dérive.

Qu'est-ce qui compterait comme preuve d'une vraie récursion ?

Une boucle qui tourne sur plusieurs générations sans que le taux d'amélioration baisse, un vérificateur que le système ne peut pas détourner, et une référence de départ qui sépare l'apport de la boucle du calcul dépensé. Rapporter ces trois choses est assez rare pour que leur absence soit la première chose à vérifier.

ConceptsMis à jour 2026-09-30 · Version 1.0

Qu'est-ce que l'auto-amélioration récursive (RSI) ?

L'auto-amélioration récursive est l'idée d'un système qui améliore sa propre capacité à s'améliorer : chaque tour d'automodification rend le suivant plus efficace, si bien que les gains se cumulent. Des parties étroites de cette boucle sont réelles et mesurées aujourd'hui — un modèle qui affine sa propre réponse, qui génère ses propres données d'entraînement, ou qui cherche un meilleur prompt et un meilleur jeu d'outils. La récursion cumulative que le terme désigne vraiment n'a pas été démontrée. Les boucles mesurées plafonnent, elles ont besoin d'un signal externe de correction pour fonctionner, et un système entraîné sur sa propre sortie se dégrade au lieu de s'améliorer.

Preuve: ThéoriqueConfiance: MoyenSource: Publication scientifiqueSource: Benchmark

Lisible par machine: JSON

Définition

L'auto-amélioration récursive est un processus par lequel un système d'IA se modifie lui-même — sa sortie, ses prompts et son échafaudage, ses données d'entraînement ou ses poids — afin d'augmenter sa propre capacité à poursuivre de telles modifications, chaque itération améliorant la suivante.

Points clés

Ce qui est affirmé, c'est la récursion, pas l'auto-amélioration : un tour d'affinage par soi-même est de l'ingénierie courante ; des tours qui se cumulent ne sont pas démontrés.
Toute boucle d'auto-amélioration mesurée repose sur un signal externe de correction — tests, vérificateur, récompense — et s'arrête sans lui.
Un modèle entraîné sur sa propre sortie se dégrade (effondrement du modèle) ; la boucle a besoin de vérité de terrain nouvelle, ce qui est un problème d'approvisionnement et non d'algorithme.
Ce qui part réellement en production relève de l'échafaudage : des systèmes qui réécrivent prompts, outils et batteries d'évaluation, avec des personnes qui tiennent le bouton de fusion.
Traitez « il s'est amélioré tout seul » comme une affirmation de mesure et demandez quel était le vérificateur, jusqu'où la récursion est allée et où elle s'est arrêtée.

Contexte

L'idée est ancienne et les preuves sont minces. I. J. Good soutenait en 1965 qu'une machine capable de concevoir de meilleures machines déclencherait une « explosion d'intelligence », et ce cadrage a structuré la discussion depuis, davantage comme argument que comme mesure. Soixante ans plus tard, la question utile n'est pas de savoir si l'explosion vient, mais quelles parties de la boucle ont été construites et ce qui les a bornées.

Trois évolutions l'ont rouverte comme sujet d'ingénierie et non de philosophie. Les modèles peuvent dépenser plus de calcul à raisonner à l'inférence ; l'apprentissage par renforcement contre des récompenses vérifiables automatiquement fonctionne bien là où la justesse est vérifiable par machine ; et les agents agissent sur du code, le seul substrat où un système peut éditer ce qui l'a produit.

Cela compte précisément pour le travail d'échafaudage. Si vous exploitez des agents qui écrivent du code, choisissent des outils et ajustent leurs propres prompts, vous opérez déjà une partie d'une boucle d'auto-amélioration, avec une personne sur le chemin de la fusion. La question d'ingénierie est où cette personne se situe et quelles preuves lui permettent d'approuver, non si la boucle existe.

Architecture

Un système peut se modifier à quatre profondeurs, qui ne sont pas d'égale difficulté. La plus superficielle est la sortie : au sein d'une même exécution, le modèle critique et réécrit sa propre réponse. C'est courant, cela aide sur certaines tâches, et c'est borné — les résultats publiés montrent que sans retour externe un modèle ne distingue souvent pas de façon fiable ses mauvaises réponses de ses bonnes, de sorte qu'itérer sur son propre jugement peut laisser la qualité inchangée ou pire.

Viennent ensuite le prompt et l'échafaudage : chercher parmi les instructions, définitions d'outils, réglages de recherche documentaire et orchestration, en gardant ce qui obtient le meilleur score sur un jeu réservé. C'est là que vivent aujourd'hui presque tous les gains réels, parce que ce qu'on améliore est du code et de la configuration plutôt que le modèle, et parce que la note vient de l'extérieur du système.

Plus profond, les données : le système génère ses propres exemples d'entraînement, garde ceux qu'un vérificateur accepte et s'entraîne dessus. Cela marche là où la justesse est vérifiable — un test passe, une preuve se ferme, une partie est gagnée — et c'est le mécanisme derrière les meilleurs résultats récents. Là où la justesse relève du jugement, cela dégénère : le système optimise le vérificateur plutôt que la tâche.

Le plus profond, les poids, réentraînés ou renforcés sur un signal auto-généré. C'est là que l'affirmation cumulative devrait se trancher, et là que les preuves sont les plus faibles, car le mode de défaillance n'est pas une panne mais un rétrécissement lent : entraînez sur votre propre distribution et elle se contracte, génération après génération.

Dans les quatre cas, le composant porteur n'est pas le modèle, c'est le vérificateur. La profondeur de la récursion est bornée par votre capacité à distinguer le meilleur du pire sans le demander au système qui l'a produit. C'est pourquoi la boucle va loin en code et en jeux, et à peine dans le travail ouvert.

Composants

Proposeur : le modèle ou l'agent qui engendre une amélioration candidateVérificateur : le signal externe qui dit si c'est meilleur (tests, jeu réservé, récompense, une personne)Mémoire des tentatives : ce qui a déjà été essayé, pour que la recherche ne tourne pas en rondBudget : le calcul et le temps que la boucle peut dépenserPorte : la personne ou la politique qui décide de ce qui est adopté

Avantages

Les boucles étroites avec un vérificateur dur sont réellement productives : là où la justesse est vérifiable par machine, les données auto-générées et la recherche donnent des gains mesurés.
L'amélioration au niveau de l'échafaudage est peu coûteuse et réversible : prompts, outils et réglages de recherche sont de la configuration, donc un mauvais tour se réverte.
Elle met la pression sur l'évaluation, où se trouve le vrai travail : une boucle ne vaut que la note qu'elle optimise.
Le cadrage clarifie la gouvernance : la question « que ce système peut-il changer de lui-même, et qui l'approuve » a une réponse et elle est auditable.

Risques

Effondrement du modèle : s'entraîner sur une sortie auto-générée rétrécit la distribution et dégrade la qualité d'une génération à l'autre, donc une boucle sans vérité de terrain nouvelle décline au lieu de se cumuler.
Détournement de la récompense : avec un vérificateur faible, le système améliore la note et non la tâche, et la métrique annonce un succès que la capacité ne suit pas.
Affirmations infalsifiables : « le système s'est amélioré tout seul » n'est pas vérifiable sans le vérificateur, la référence de départ et la profondeur de la récursion, et ce sont justement les parties qu'on omet.
Perte du chemin de supervision : plus l'automodification est profonde, plus il est difficile de dire ce qui a changé et pourquoi, ce qui est exactement ce dont un audit a besoin.
Opacité de capacité : un système qui réécrit son propre échafaudage peut acquérir une portée que personne ne lui a accordée, ce qui est une question de confinement avant d'être une question de capacité.

Outils et technologies

Vérificateurs automatiques : batteries de tests, vérificateurs de types, assistants de preuve, simulateursJeux d'évaluation réservés et batteries de régressionRecherche de prompt et d'échafaudage contre un objectif notéÉchantillonnage par rejet et génération de données filtrée par vérificateurOutillage de trace et de provenance, pour pouvoir imputer un changement adopté

Exemples

Un agent de code qui écrit un correctif, lance la batterie de tests et réessaie en cas d'échec : un tour d'auto-amélioration avec vérificateur dur, et le mécanisme derrière les progrès mesurés sur des jeux d'épreuves issus de dépôts réels.
Un modèle qui apprend à se servir d'un outil à partir d'exemples qu'il a lui-même générés puis filtrés, en ne gardant que les appels qui amélioraient sa prédiction.
De l'apprentissage par renforcement sur des problèmes dont la réponse peut être vérifiée automatiquement, où le signal d'entraînement vient du vérificateur et non d'une étiquette humaine.
Une recherche de prompt et d'échafaudage qui propose des variantes, note chacune sur un jeu réservé et promeut la gagnante : de l'amélioration sans toucher au modèle.

FAQ

Un système a-t-il vraiment réalisé une auto-amélioration récursive ?: Aucun système n'a démontré la boucle cumulative que le terme désigne. Ce qui existe, ce sont des tours isolés contre un vérificateur externe, et de la recherche sur des échafaudages : réels tous les deux, et bornés tous les deux. Les résultats publiés sur un modèle se corrigeant sans retour externe sont notablement faibles, et s'entraîner sur des données auto-générées dégrade la qualité au fil des générations. Ces deux constats sont ce que toute affirmation de récursion doit dépasser.
Est-ce la même chose que la singularité ?: L'argument de la singularité prend l'auto-amélioration récursive pour moteur, mais ce sont deux affirmations distinctes. La RSI est un mécanisme qu'on peut chercher et mesurer ; la singularité est une prédiction sur des conséquences. On peut prendre le mécanisme au sérieux comme sujet d'ingénierie sans tenir aucune position sur la prédiction, et c'est la posture utile pour construire des systèmes.
Pourquoi le vérificateur compte-t-il autant ?: Parce que s'améliorer signifie « meilleur », et cela doit être décidé par quelque chose d'extérieur à ce qu'on améliore. Là où une machine peut vérifier la justesse — les tests passent, la preuve se ferme, la partie est gagnée — la boucle tourne et les gains sont réels. Là où la justesse relève du jugement, le système finit par optimiser le substitut que vous lui avez donné. La profondeur de la récursion est une propriété de votre vérificateur, pas de votre modèle.
Faut-il laisser des agents améliorer leurs propres prompts et outils en production ?: C'est raisonnable et beaucoup d'équipes le font, à trois conditions : que la note vienne d'un jeu réservé que la boucle ne peut pas voir, que tout changement adopté soit imputable à une exécution, et qu'une personne ou une politique commande l'adoption. Sans cela, vous n'avez pas automatisé l'amélioration, vous avez automatisé la dérive.
Qu'est-ce qui compterait comme preuve d'une vraie récursion ?: Une boucle qui tourne sur plusieurs générations sans que le taux d'amélioration baisse, un vérificateur que le système ne peut pas détourner, et une référence de départ qui sépare l'apport de la boucle du calcul dépensé. Rapporter ces trois choses est assez rare pour que leur absence soit la première chose à vérifier.