L’auto-amélioration récursive, expliquée à travers un projet qui la met réellement en pratique

« L'amélioration de soi récursive » est l'une de ces expressions qui servent surtout à désigner un ressenti. Définie sans mystique, elle est plus étroite que cela et plus intéressante : un système qui propose sa propre expérience suivante, l'exécute, puis conserve ou abandonne le résultat selon une règle fixée à l'avance, les résultats alimentant le tour suivant. La récursion n'a rien de magique et elle n'est pas illimitée — c'est une boucle avec une fonction de score, et sa qualité est entièrement déterminée par l'honnêteté avec laquelle cette fonction de score est appliquée. RSI-Jev, le projet ouvert tiers qui construit des modèles de décision System One de style Jev, est un cas rare où l'on peut lire la boucle au lieu d'en débattre : chaque hypothèse, chaque branche échouée et chaque version publiée est rendue publique avec ses chiffres, et le dépôt est daté jour après jour. Le modèle que cette page utilise comme exemple de travail est RSI-Jev v6.0-VL, un modèle de décision typé de 4B publié le 2026-10-06, soit dans la dernière semaine. Ce n'est pas le Jev de TypeSafe et il n'est pas affilié à TypeSafe AI — la ligne de licence du projet dit exactement cela, et ce que nous servons sur OrcaRouter est l'autre, typesafe/jev-1.13, sur notre point de terminaison systemone.

Une mise au point avant que le terme « auto-amélioration » ne produise le moindre effet, suivie d’une date. Il ne s’agit pas d’un modèle qui se réécrit sans limite, et rien sur cette page ne doit être lu ainsi. La boucle en question réécrit une recette : elle propose une modification d’entraînement, consigne ce qu’elle attend de cette modification, consomme du temps GPU, puis soit elle conserve la modification, soit elle consigne pourquoi elle a perdu. Le modèle est une tour Qwen3.5-4B-Base dotée de têtes de décision entraînées — une architecture fixe entraînée par un script d’entraînement fixe, la recherche s’effectuant sur les données, les objectifs et les étapes. La boucle mène ses propres expériences et retire ses propres champions. Les humains décident de ce qui mérite d’être mesuré. Et la date : v6.0-VL a été publiée le 2026-10-06, et le projet a publié une nouvelle version depuis — la ligne évolue à peu près quotidiennement, et les chiffres de cette page sont ceux associés à la version nommée ici, datés là où ils ont été lus. Cela mérite d’être dit d’emblée sur une page dont le sujet est une boucle qui continue de tourner.

Ce que le terme signifie, dit sans détour

Dépouillez la phrase et il reste trois parties, toutes ordinaires. Premièrement, un espace de recherche : l’ensemble des choses qui pourraient être modifiées. Deuxièmement, un évaluateur : quelque chose qui indique si une modification a aidé. Troisièmement, un enregistrement : ce qui a été essayé, ce qui s’est produit et ce qui a été abandonné. Un système pratique l’auto-amélioration récursive lorsque la sortie du tour N est l’entrée du tour N+1 pour ces trois éléments, sans qu’un humain ne redérive l’espace de recherche ni ne redécide le seuil à chaque fois.

Ce que la plupart des textes sur le sujet omettent, c’est la seconde partie, et c’est là que réside toute la question. Une boucle dotée d’un évaluateur faible optimise l’évaluateur. Elle produira une courbe monotone croissante et un système qui a appris la forme de son propre examen. Cette défaillance n’exige ni malveillance ni bogue — c’est ce qui se produit par défaut quand le même nombre sert à la fois à sélectionner et à rendre compte. Ainsi, quand vous lisez une affirmation selon laquelle un système s’auto-améliore, la question utile n’est jamais « de combien s’est-il amélioré ». C’est « qui a fixé la barre, quand, et pouvait-elle bouger après que le résultat a été vu ».

Les versions populaires de ce concept — celles qui se classent sur ce terme aujourd'hui — sont pour la plupart tournées vers l'avenir : l'article de Wikipédia décrit un système qui réécrit son propre code vers une « explosion d'intelligence », et la couverture plus large tend à porter sur la question de savoir si ce calendrier est plus proche ou plus lointain que prévu. C'est un argument légitime, et il est impossible d'y répondre avec les preuves dont on dispose actuellement. Ce à quoi il est possible de répondre, c'est la question plus restreinte de savoir si une boucle fermée du type décrit ci-dessus peut être construite et astreinte à ses propres règles dès maintenant. Pour cela, un projet avec des artefacts publics l'emporte sur une décennie de spéculation, et c'est ce dont traite le reste de la page.

Fermé, et non simplement itératif : cinq mécanismes

Une boucle n’est pas fermée parce qu’elle se répète. Beaucoup de pipelines automatisés se répètent sans jamais être fermés, car un pipeline capable d’ajuster son seuil après avoir vu le résultat fait quelque chose de catégoriquement différent d’un pipeline qui ne le peut pas. Les propres règles de RSI-Jev sont inhabituellement explicites sur cette différence, et on peut les lire comme des définitions plutôt que comme un manifeste. Cinq d’entre elles font l’essentiel du travail.

Les prédictions sont enregistrées avant l’exécution. Une hypothèse est consignée avec le chiffre qu’elle prévoit de déplacer et l’ampleur de ce déplacement, avant de consacrer du temps GPU. Une version qui rate son propre seuil est livrée comme un échec plutôt que d’être discrètement retaillée. C’est le mécanisme qui empêche la boucle de devenir une machine à rédiger des explications a posteriori, et cela a un coût bien réel : le registre contient des entrées dont le seul contenu est que quelqu’un s’est trompé, noir sur blanc.

Les planchers nuls se mesurent, ils ne se supposent pas. L'équipe exécute des bras démontrablement identiques au contrôle — vérifiés par identité d'objet avant tout temps GPU — et la dispersion entre ces bras est le plancher de bruit. Une différence inférieure à ce plancher n'est pas un résultat, quoi qu'elle en ait l'air. La barre que le projet s'est fixée le reflète : sur sa suite interne, le seuil est de +0,006, avec un écart-type par graine sur un seul benchmark de 0,011–0,016, donc les différences sur un seul benchmark inférieures à cela ne sont pas des résultats. L'essentiel du bruit dans ce métier est mesuré, pas statistique.

Un ensemble de réserve est consommé dès qu'il est lu. Chaque version lit l'ensemble de réserve une fois, si bien que deux versions restent comparables à armes égales — et comme le lire le consomme, chaque version fige la comparaison de la suivante. La formulation du projet lui-même mérite d'être conservée telle quelle : l'ensemble de réserve « est tenu à l'écart de l'entraînement, non scellé vis-à-vis de la recherche ». C'est un contrôle de la mémorisation, non une garantie de nouveauté. Et le chiffre de la suite comporte lui-même un trou que le projet a publié : une tâche interne chevauchait plusieurs centaines de lignes d'entraînement, de sorte qu'à partir de v6.0-VL, la suite est rapportée sans elle — 0,770 — et le 0,764 antérieur de v5.0-VL a été reformulé en 0,763 sans elle. C'est là tout l'intérêt de cette reformulation. Un chiffre était gonflé, la cause a été trouvée, et la fiche de la version plus ancienne a été corrigée plutôt que laissée en l'état.

Les échecs sont publiés, y compris ceux qui ont tué le propre champion du projet. Les chiffres phares du dépôt, lus le 2026-10-08, sont cohérents : huit versions en treize jours, et des centaines d’expériences documentées, échecs inclus. Un résultat négatif est traité comme le produit. Le guide de contribution est sans détour sur la raison : la partie coûteuse d’une recherche n’est pas d’exécuter le gagnant, c’est d’exécuter les perdants ; ainsi, un négatif bien mesuré venu de l’extérieur élimine une branche et vaut plus qu’un petit positif.

La chaîne de versions, c'est le projet. Une fiche par version, toutes, sur la branche principale de façon permanente. Chaque fiche porte les chiffres de sa propre version, de sorte que la vitesse et la calibration d'une version n'écrasent jamais celles d'une autre. Le projet énonce directement la raison : cette chaîne est le seul moyen de voir qu'une boucle d'auto-amélioration s'améliore. Tout le reste — la recette, les scripts, la pile figée — ne porte que la version actuelle, car la règle inverse rendrait impossible de savoir ce qui est actuel. Un point de contrôle publié porte son propre code afin que les anciennes versions restent exécutables sans anciennes branches.

Ce que coûte la discipline, et ce qu’elle rapporte

Deux histoires issues du dossier constituent le contrepoids honnête au mot « auto-améliorant », car toutes deux sont des cas où les règles propres de la boucle ont rendu le travail plus lent et meilleur en même temps.

Le premier est le bug derrière la v1.0. Il a fallu sept négatifs enregistrés pour le trouver. Chacun des sept était une correction côté optimiseur qui réduisait une instabilité d'entraînement sans l'éliminer, parce que la cause était une erreur de précision très loin de l'optimiseur — et la correction finale tenait en une ligne. Aucun des sept ne valait la peine d'être publié à lui seul. Ensemble, ils sont ce qui a rendu la cause trouvable tout court, et c'est là tout l'argument pour enregistrer et conserver les négatifs : leur valeur est conjointe, non individuelle.

Le second est moins flatteur, et le projet le publie quand même, dans une note de bas de page. Un premier bras a échoué à exactement un garde-fou — MMLU-Pro est arrivé 0,026 sous la barre, pour une limite de 0,020 — et a été consigné comme rejeté. Le responsable de l'exécution a ensuite élargi la limite à 0,030, au motif que MMLU-Pro est un garde-fou contre l'oubli plutôt qu'un objectif, et le bras a été confirmé sur quatre graines inédites et est devenu la version suivante. Le rejet initial a été laissé dans le journal, accompagné de ce commentaire du projet : déplacer une barre après avoir vu le résultat est le genre de chose qu'un lecteur devrait pouvoir prendre sur le fait.

Cette note de bas de page est le paragraphe le plus utile du dépôt pour quiconque tente d’évaluer ce genre d’affirmation sur le terrain. Un seuil qui a bougé n’est pas une preuve de mauvaise foi — le raisonnement donné est défendable, et le seuil élargi a ensuite dû survivre à quatre nouvelles graines. Mais un seuil qui a bougé en silence est une boucle qui n’est plus fermée, et la différence entre les deux tient entièrement au fait que le changement ait été consigné par écrit. La règle générale que le projet a adoptée par la suite est celle qui vaut la peine d’être transposée à d’autres systèmes : un quasi-accident qui échoue à exactement un garde-fou reçoit un diagnostic et une réparation ciblée au lieu d’être écarté — et si la réparation échoue, il devient une impasse avec une trace.

À quelle fréquence la boucle se trompe : quatorze configurations, deux conservées

Voici le chiffre à retenir. Dans la version qui lit les images, le projet compte quatorze configurations d’apprentissage par renforcement et 63 bras entraînés par récompense. Deux ont été conservés.

Chaque configuration a été évaluée par rapport à un contrôle supervisé entraîné sur les mêmes éléments pendant le même nombre d’étapes, ce qui est la comparaison qui rend le décompte significatif — un bras RL qui bat une référence qu’il n’a jamais eu à égaler ne prouve rien. Les pertes instructives, selon les propres mots du projet :

• RL de justesse binaire — la sortie de probabilité s’est effondrée à 0 et à 1. Récompenser le fait de choisir juste plutôt que l’honnêteté des probabilités rapportées pousse une distribution vers les coins, et un modèle de décision dont la confiance est toujours totale est inutile pour ce à quoi servent les modèles de décision.

• Proper-score RL, la reconstruction de l’objectif de style Laya — correct à 300 étapes, a divergé à 1 500. Stable tant qu’il ne faisait pas grand-chose, et instable précisément au moment où il a commencé à compter.

• RLCR — à égalité sur la précision, moins bonne calibration brute. Il n'a apporté aucune capacité et l'a payé sur la seule propriété que le modèle a pour raison d'être d'offrir.

• Bandit RLCD, où seul le résultat de l'option choisie est révélé — pas mieux qu'un entraînement supervisé sur le même retour. Le projet a enterré ici son propre test pré-enregistré : le bras devait surpasser l'entraînement supervisé sur au moins deux des quatre métriques de calibration et n'en a remporté qu'une.

Le gagnant, et la raison de sa victoire, constituent le constat le plus transférable de la page. Il s'agit d'une récompense de type listwise — une qualité de classement mesurée sur l'ordre de nombreux candidats notés séparément, plutôt qu'un traitement de chacun isolément. Le rappel de reclassement en première position est passé de 0,192 pour le parent supervisé à 0,308, avec des gains et des pertes sur un test apparié. L'explication du projet n'est pas une histoire de réglage : une cible d'entraînement par élément note chaque candidat isolément, et aucune étiquette unique n'encode la qualité d'un ordre entre candidats. Là où la récompense exprimait quelque chose que les étiquettes ne peuvent pas exprimer, le RL a battu l'entraînement supervisé sur les mêmes lignes. Là où ce n'était pas le cas, l'entraînement supervisé l'a égalé.

Cela se généralise en une règle sur les cas où ce type de boucle peut trouver quoi que ce soit. Avec une étiquette de référence en main, la mise à jour attendue par gradient de politique équivaut au gradient d’une perte supervisée — la formulation même du projet —, donc un « bras RL » évalué par rapport à des décisions étiquetées est en réalité un bras de conception de perte. Et les changements au niveau de la perte ont déplacé la suite interne d’au plus 0,002, tandis que de nouvelles données l’ont déplacée de 0,13. Lus ensemble : le levier de la boucle n’a jamais résidé dans l’objectif. Il résidait dans ce qui était mesuré et dans ce qui était injecté.

Ce qui est la réponse honnête à une question qu'un lecteur est en droit de poser. Les configurations RL sont citées ailleurs comme preuve d'auto-amélioration en général ; ici, elles sont une preuve concernant une boucle sur des tâches de décision. Le résultat listwise est une seule graine, et le projet le dit : la comparaison appairée RL contre supervisé a été exécutée sur un parent différent de celui auquel la version publiée l'a appliquée, et cette version « n'a pas de contrôle supervisé apparié ». Une conclusion accompagnée de cette mise en garde vaut plus qu'une sans, et c'est pourquoi la page que vous lisez ne la généralise pas.

Où l'humain est assis

Le projet est explicite, et c’est son caractère explicite qui est intéressant : la boucle mène ses propres expériences et met ses propres champions à la retraite, mais elle ne décide pas ce qui mérite d’être mesuré, et elle ne s’aperçoit pas d’elle-même quand un nombre est techniquement vrai mais trompeur en pratique. Ce sont les gens qui le font.

Deux des règles du projet existent parce que quelqu'un a exprimé son désaccord. Le garde-fou MMLU-Pro a été élargi plutôt que de laisser écarter un quasi-échec. L'exigence en matière de graines est désormais proportionnelle à la taille de l'effet au lieu de consacrer quatre graines à chaque différence — car la graine de confirmation, le seul nombre sur lequel un bras n'a pas été sélectionné, est celle qui porte la charge, et dépenser de la puissance de calcul sur des différences que l'on voit déjà n'apporte rien. L'une des versions de la chaîne a commencé par un refus d'abandonner un bras qui avait échoué à un garde-fou. Le projet remercie nommément les personnes qui ont envoyé ces retours, dans les remerciements.

Ainsi, « auto-améliorant » décrit ici le milieu de la boucle, et non l’ensemble de celle-ci. La boucle est une recherche qui tourne sans qu’un humain tourne la manivelle. L’humain reste toujours en haut de la boucle pour choisir l’objectif et en bas pour lire le résultat d’un œil critique — ce qui est précisément la configuration qui empêche la boucle de devenir une machine à confirmer ses propres préférences. Toute description de l’auto-amélioration récursive qui omet cette place décrit un système différent de celui-ci, et probablement un système hypothétique.

Ce que les chiffres propres au projet ne montrent pas

La discipline ci-dessus ne mérite d’être décrite que si ses limites sont énoncées du même souffle, et le bilan de RSI-Jev les énonce de lui-même.

• Il s'agit d'un seul projet, d'une seule taille de modèle à la fois, d'une seule graine. Le checkpoint publié est celui d'une seule graine, fixé à l'avance comme principal plutôt que choisi pour obtenir le meilleur score. La preuve RL provient d'une seule graine.

• Il s'agit de tâches de décision, pas de génération : une question de type oui/non, choix parmi k ou notation sur une grille, portant sur un document, une conversation ou une image, à laquelle on répond en une seule passe avant avec une probabilité calibrée par option. Rien n'est généré, donc il n'y a pas de jetons de raisonnement à dépenser. Ce que la boucle démontre ici, c'est qu'elle peut améliorer un modèle de notation de cette forme.

• Une partie n’est pas reproductible à partir du dépôt seul. Les corpus d’entraînement et les ensembles de développement des politiques ne sont pas publics, et le projet le dit clairement dans la fiche de version : « les étapes ne peuvent pas être réexécutées à partir de ce dépôt seul. » Un constructeur de corpus nécessite environ 96 Go de mémoire et n’a pas été réexécuté de bout en bout.

• Tout n'est pas vérifiable du tout. La suite interne n'a jamais été entièrement tenue à l'écart. Sur les quinze benchmarks, dix contribuent aux données d'entraînement sous une forme ou une autre, donc aucun de ces chiffres n'est en zero-shot — l'ensemble tenu à l'écart est la comparaison qui est tenue à l'écart, et c'est la seule.

Et les parties externes ont leur propre tissu cicatriciel. Un audit après une version a trouvé environ un millier d’éléments issus des lignes de test du kit de référence public dans les corpus d’entraînement — environ 0,3 % des lignes du kit, la plus grande contribution unique étant de quelques centaines de lignes provenant d’une seule source. Recalculé sans elles, l’indice varie d’au plus 0,04. Cette correction a été publiée dans la fiche de la version suivante plutôt qu’appliquée discrètement, selon la règle que le projet énonce ainsi : « pas de contamination, vérifiée plutôt qu’affirmée ». C’est une règle qui leur coûte un chiffre, et c’est le seul genre de règle qui vaille la peine d’exister.

Où vous pouvez réellement l'exécuter — et où vous ne le pouvez pas

Rien ici n'est servi par OrcaRouter. Notre catalogue ne comporte aucun identifiant RSI-Jev ni aucune fiche de modèle pour lui, et il n'y en aura pas avant que quelqu'un ne le serve. RSI-Jev s'installe depuis son propre dépôt et exécute son propre serveur, qui parle l'API Jev : vous dirigez un client Jev existant vers lui et modifiez l'URL de base. Il fonctionne sous Linux, Windows et macOS, sur un GPU CUDA, Apple Silicon ou un CPU ordinaire.

The one model we do host is the other side of that contract. TypeSafe's Jev 1.13, which we serve as typesafe/jev-1.13, is the commercial decision model whose request and answer shapes RSI-Jev reproduces, and it is reached on our dedicated systemone endpoint rather than through the chat-completions shape. That is the whole relationship, and it is a structural one rather than a quality claim: one is a hosted commercial model on a vendor's endpoint, the other is a checkpoint you download and serve yourself. Nobody has run an independent head-to-head between them, and this page is not going to declare a winner from two different harnesses.

Si ce que vous voulez, c'est placer un modèle de décision comme celui-ci derrière une application, la question du routage est distincte de celle du modèle, et c'est elle qui détermine si l'expérience vaut la peine d'être menée. OrcaRouter est une seule API pour plus de 200 modèles, avec 0 % de marge — le prix catalogue du fournisseur répercuté tel quel, si bien qu'un changement de prix d'un fournisseur devient votre prix le jour même — plus une bascule automatique et un DSL de routage permettant de composer plusieurs modèles en un seul appel. Pour un modèle en boucle que vous ne pouvez pas encore appeler via une API générale, cela compte d'une manière bien précise : les candidats alternatifs avec lesquels vous le compareriez sont déjà derrière une seule clé, et la comparaison relève d'un changement de configuration plutôt que d'une seconde intégration.

La partie qui vaut la peine d’être gardée

La raison d’écrire sur l’auto-amélioration récursive au moyen d’un projet comme celui-ci, plutôt que par le débat sur la question de savoir si elle mène quelque part de spectaculaire, est que les règles de la boucle sont la partie transférable, et non la spéculation. Prédictions enregistrées, planchers de nullité mesurés, ensembles de validation tenus à l’écart et épuisés, échecs publiés, chaîne de publication immuable : rien de tout cela n’est une propriété d’une superintelligence. Ce sont les propriétés d’un laboratoire qui a décidé d’être vérifiable, et elles sont à la portée de toute équipe qui mène aujourd’hui une recherche automatisée, à n’importe quelle échelle, sur n’importe quel modèle.

Lu ainsi, l'affirmation intéressante dans le dossier de RSI-Jev n'est pas le score. C'est que le registre de la boucle elle-même dit qu'elle s'est trompée bien plus souvent qu'elle n'a eu raison — deux recettes conservées sur quatorze configurations, sept négatifs pour trouver un bug d'une ligne, une barre qui a bougé et qui a été consignée — et que le projet a publié ce registre. Une hausse de 38,38 à 46,24 sur un indice public en une seule version est une curiosité si les échecs ne figurent pas à côté. Ce sont les échecs qui donnent un sens au chiffre.

Telle est la position honnête sur le terme lui-même. La question n’est pas de savoir si un système peut s’améliorer lui-même. Elle est de savoir si l’amélioration est mesurée par quelque chose qui aurait pu dire non. Là où cette séparation est réelle et consignée par écrit, la boucle vaut la peine d’être lue. Là où elle ne l’est pas, une courbe ascendante décrit un système de notation, non un système qui s’améliore — et aucune récursion, aussi profonde soit-elle, ne corrige cela.