La boucle Ralph : comment une ligne de bash est entrée dans le modèle

« Les modèles d’avant ne comprenaient pas ce que voulait dire “terminé” », a dit Raj, de l’équipe IA appliquée d’OpenAI, au DevDay 2026. Ils avançaient bien, puis rendaient la main trop tôt. La solution a changé de place trois fois : d’abord une boucle bash autour de l’agent, appelée la boucle Ralph, puis une commande goal dans l’outil, et maintenant une persévérance apprise par le modèle lui-même.

Si vous faites tourner des agents de code, il vaut la peine de savoir laquelle de ces trois couches fait le travail aujourd’hui. Sinon, vous écrivez une boucle que votre modèle ou votre outil fait déjà tourner pour vous, et vous la payez deux fois.

La conférence s’appelle What Comes After Loops?, 24 minutes en anglais, par Raj et Eric d’OpenAI. C’est OpenAI qui raconte l’histoire de son propre produit, Codex. J’ai donc regardé l’autre côté aussi : comment Claude Code, l’outil d’Anthropic, gère le même problème.

La première solution, c’était taper « continue »

Avant que les outils aient une réponse, la réponse, c’était vous. L’agent s’arrêtait, vous tapiez « continue », et il repartait pour un moment.

Raj a montré un post de Peter Steinberger, le créateur d’OpenClaw. Pour garder son agent au travail, il mettait en file toute une pile de messages « continue », l’un après l’autre. Tout le monde faisait une version de ça.

La conférence appelle cela une « boucle externe » : quelque chose en dehors de l’agent qui le relance jusqu’à ce qu’il ait fini. Le modèle ne sait pas quand s’arrêter, alors une personne, ou un script, décide à sa place.

Les tâches longues, avant l’aide des outils

L’agent s’arrêtait trop tôt, alors on tapait continue

1. TravaillerL’agent avance bien sur la tâche.
2. S’arrêterIl rend la main avant la fin du travail.
3. RelancerVous tapez « continue », ou vous en mettez une pile en file.

Puis retour à l’étape 1, jusqu’à ce que le travail soit vraiment fini

Une boucle bash qui n’abandonne jamais

La boucle Ralph, c’est la même relance, écrite en script. Geoffrey Huntley l’a rendue populaire en juillet 2025, dans un article intitulé Ralph Wiggum as a "software engineer". Ralph Wiggum, c’est l’enfant des Simpson qui ne réussit jamais rien et n’arrête jamais d’essayer.

Dans sa forme la plus pure, c’est une ligne de bash :

while :; do cat PROMPT.md | claude-code ; done

La boucle lit un fichier de prompt et le donne à un agent de code. L’agent travaille jusqu’à ce qu’il s’arrête. Puis la boucle le relance, avec le même prompt, sans fin. Cette ligne n’a aucune condition de sortie.

Quatre idées la font fonctionner, et elles sont plus intéressantes que la boucle elle-même :

• Une mémoire vide à chaque passage. Chaque passage démarre avec une fenêtre de contexte vide, le texte que le modèle voit d’un coup. Aucun long historique ne la remplit ni ne fait sortir l’objectif.
• Les fichiers se souviennent. L’avancement vit sur le disque : le code, un dossier de spécifications, une par fichier, et un fichier de plan que Huntley appelle fix_plan.md. Chaque passage les lit pour savoir où on en est.
• Une seule chose par passage. La règle de Huntley : demandez à Ralph une seule chose par boucle. « Une seule. »
• Les tests résistent. Après chaque changement, l’agent lance les tests de cette partie du code. Un test qui échoue rejette un mauvais changement avant que le passage suivant construise dessus. Huntley appelle cela la contre-pression (backpressure).

Il ne cache pas ce que c’est. Il décrit la technique comme « déterministiquement mauvaise dans un monde non déterministe » : elle échoue de façon prévisible, donc on peut corriger ses échecs dans le prompt. Elle demande aussi « beaucoup de foi », parce que le code converge lentement, passage après passage.

Un passage d’une boucle Ralph

Chaque passage part de zéro, les fichiers se souviennent

1. LireLe prompt, le plan et les spécifications. Le contexte est vide.
2. Une seule choseUne tâche du plan, pas plus.
3. TesterUn test qui échoue rejette un mauvais changement avant le passage suivant.
4. L’écrireCommiter le code, mettre à jour le fichier de plan.

Puis la boucle relance l’agent, avec une mémoire vide

L’objectif est entré dans l’outil

L’étape suivante a été de mettre la boucle dans l’outil. OpenAI a ajouté une commande /goal à Codex, sortie avec Codex CLI 0.128 fin avril. Raj y voit le « loop engineering » intégré au produit.

Pour comprendre ce que ça apporte, il faut un mot de plus : la compaction. Quand la fenêtre de contexte se remplit, l’outil demande au modèle de résumer l’historique, et le travail repart de ce résumé. Ça garde une longue tâche en vie, mais chaque résumé peut perdre un détail. Après trois ou quatre compactions, les instructions de départ ont pu disparaître.

Un goal évite ça. Vous donnez un objectif à Codex, et l’outil le range en dehors de la conversation, là où la compaction ne peut pas le toucher. L’outil suit son état et vérifie après chaque tour si l’agent a fini. Sinon, il le relance.

L’agent peut aussi dire qu’il est bloqué. Face à un vrai blocage, il le signale et s’arrête, au lieu de tourner en rond sur un problème qu’il ne peut pas résoudre. La boucle bash n’a aucun moyen de faire ça.

La boucle bash face à une commande goal

Un goal garde l’objectif hors de portée de la compaction

La boucle bashUn goal dans l’outil

MémoireVide à chaque passageUne session, compactée à mesure

L’objectifUn fichier de prompt, relu à chaque passageRangé par l’outil, hors du contexte

Fini quandVous l’arrêtezUne vérification après chaque tour le dit

BloquéElle continue de tournerIl signale le blocage et s’arrête

Puis la persévérance est entrée dans le modèle

La dernière étape, dit OpenAI, a rendu la boucle inutile. Avec GPT-5.6, OpenAI a appris la persévérance au modèle lui-même. Le modèle vérifie son propre travail et continue jusqu’à ce que la tâche soit finie, sans goal et sans « continue ».

Raj a cité deux utilisateurs. Tobi Lütke, qui dirige Shopify, a dit que c’était le premier modèle qui n’avait plus besoin de /goal. Ethan Mollick, professeur à Wharton, a laissé Codex utiliser son ordinateur et jouer au jeu Slay the Spire 2 pendant environ cinq heures d’affilée. Ce sont les exemples d’OpenAI, sur la scène d’OpenAI.

Le mécanisme derrière est la partie intéressante. OpenAI regarde ce que les gens ajoutent au harnais, le code autour du modèle qui lance ses outils et gère son contexte. Puis l’entreprise apprend ce comportement au modèle suivant. La compaction a suivi le même chemin : d’abord un appel que fait l’outil, puis une compétence apprise par le modèle, qui sait repartir de son propre résumé.

Anthropic raconte une histoire proche de son côté. Au lancement de Claude Sonnet 4.5, en septembre 2025, l’entreprise a dit avoir vu le modèle garder sa concentration plus de 30 heures sur des tâches complexes. En novembre 2025, ses ingénieurs ont expliqué comment ils font travailler Claude sur plusieurs fenêtres de contexte. Ils nomment le même défaut : « Claude crie victoire sur tout le projet trop tôt. »

Leur solution ressemble beaucoup à Ralph. Un premier agent écrit une liste de plus de 200 fonctionnalités, toutes marquées en échec, plus un fichier d’avancement. Chaque session suivante travaille sur une seule fonctionnalité, commite, et écrit un résumé pour la suivante. Les agents peuvent seulement changer l’état d’une fonctionnalité, jamais la supprimer, donc personne ne peut déclarer finie une fonctionnalité absente.

Où vit le « continue »

La boucle est rentrée, de votre script jusqu’au modèle

1. Votre scriptUne boucle bash relance l’agent sur le même prompt. La boucle Ralph, juillet 2025.
2. L’outilUne commande goal range l’objectif et vérifie après chaque tour. Codex et Claude Code.
3. Le modèleLa persévérance apprise : il vérifie son travail et continue. Ce qu’OpenAI annonce pour GPT-5.6.

Chaque couche a repris le travail de celle qui l’entoure.

Comment Claude Code et Codex la gèrent aujourd’hui

Les deux outils ont maintenant les trois couches, et ils ont construit celle du milieu de façon différente.

Commençons par la boucle bash. Anthropic publie un plugin Ralph Loop officiel pour Claude Code. Vous lancez /ralph-loop "votre prompt" --max-iterations 10 --completion-promise "DONE". Un stop hook, un petit script qui se lance chaque fois que Claude veut s’arrêter, intercepte la sortie et redonne le même prompt. Il s’arrête quand Claude écrit le mot choisi, ou au plafond d’itérations.

Il y a une vraie différence avec l’original. Le plugin garde la même session, alors que la boucle de Huntley repart avec une mémoire vide à chaque passage. Huntley lui-même met sur sa page le lien d’une vidéo intitulée « why the claude code plugin isn’t it ». Avec Codex, on écrit encore la boucle à la main, avec codex exec, son mode non interactif, dans le while.

Ensuite, le goal. Les deux outils ont maintenant une commande /goal, et ils ne la vérifient pas de la même façon :

• Codex. Le goal est un état que l’outil garde pour la conversation. L’application montre son avancement au-dessus de la zone de saisie, avec des boutons pour le mettre en pause, le reprendre, le modifier ou l’effacer. Le modèle signale lui-même quand il est bloqué.
• Claude Code. Vous écrivez une condition, jusqu’à 4 000 caractères. Après chaque tour, un modèle séparé lit la conversation et répond : pas encore, atteint, ou impossible. La documentation précise que ce vérificateur « ne lance pas de commandes et ne lit pas de fichiers » de lui-même.

Ce dernier détail change la façon d’écrire un goal pour Claude Code. Le vérificateur ne voit que ce que montre la conversation. « Les tests passent » est faible. « npm test passe et sa sortie est affichée » est une condition qu’il peut vraiment vérifier. La documentation propose aussi une porte de sortie, écrite dans la condition elle-même : « or stop after 20 turns », arrête-toi après 20 tours.

Claude Code ajoute une chose que Codex n’a pas sous ce nom : /loop. Elle relance un prompt selon un rythme, toutes les cinq minutes par exemple, ou à un rythme que Claude choisit, entre une minute et une heure. C’est fait pour surveiller quelque chose, comme un déploiement, pas pour finir une tâche.

Claude Code et Codex, novembre 2026

Les mêmes couches, des vérifications différentes

Claude CodeCodex

La boucle bashPlugin Ralph Loop officiel : un stop hook redonne le promptÀ écrire soi-même : codex exec dans une boucle while

Un goalUne condition qu’un modèle séparé vérifie après chaque tourUn objectif que l’outil garde : pause, reprise, modification, effacement

Selon un rythme/loop : toutes les quelques minutes, ou à son rythmePas couvert ici

Les aidesDes sous-agents qui rendent compte. Des équipes d’agents qui s’écrivent, encore expérimentalesDes sous-agents, activés par défaut, et /subagents pour passer de l’un à l’autre

N’ajoutez des agents que si le travail le demande

Une fois qu’un agent continue tout seul, la question suivante est la vitesse : pourquoi pas dix agents ? La réponse d’Eric, dans la deuxième moitié de la conférence : attendez. Commencez avec un seul agent, donnez-lui une tâche claire et un moyen de vérifier son travail. Pour beaucoup de tâches, ça suffit.

N’en ajoutez que quand le travail se découpe tout seul. Relire cinq pull requests se découpe facilement : un agent d’appoint par pull request, chacun avec son propre contexte. Une race condition difficile est moins évidente, mais deux agents d’appoint peuvent chercher à deux endroits en même temps.

Le coût est réel. Chaque agent ajouté peut faire monter beaucoup la facture de tokens, sans rendre le travail plus rapide ni meilleur. Les deux éditeurs le disent dans leur documentation : les sous-agents de Codex « consomment plus de tokens », et les équipes d’agents de Claude Code en utilisent « nettement plus qu’une seule session ».

Eric a aussi nommé un piège, qu’il appelle la taxe du middle management. Chaque règle que vous ajoutez sur la façon dont les agents doivent travailler ensemble, et ils se mettent à attendre des validations dans des hiérarchies qui n’existent pas. Gardez donc une organisation simple. Si vous ne savez pas dire pourquoi un agent est là, retirez-le.

À l’autre bout de l’échelle, Raj a dit qu’OpenAI avait fait tourner 10 000 agents sur un célèbre problème ouvert de mathématiques, les équations de Navier-Stokes. Il a donné 2,7 millions de messages et environ 130 milliards de tokens en sortie. C’est le compte rendu d’OpenAI sur son propre modèle interne, et personne à l’extérieur ne l’a encore vérifié. Pour une équipe au travail, la leçon utile est celle d’avant : un seul agent d’abord.

Combien d’agents pour une tâche

Commencez avec un agent et un moyen de vérifier

Un seul agentUne tâche et une vérificationUne tâche claire et un moyen de vérifier le travail. La plupart des tâches s’arrêtent là.

Des aidesDes morceaux qui se séparentUn agent par pull request à relire, chacun rend compte.

Une équipeDes morceaux qui se parlentLes agents s’écrivent pendant le travail. Le plus de tokens.

Un journal court garde l’objectif

Le dernier conseil d’Eric est celui que j’essaierais en premier, parce qu’il marche avec n’importe quel outil. En regardant un agent travailler, on ajoute sans cesse de petites consignes oubliées dans le premier prompt. Après quelques compactions, l’agent peut s’éloigner de ce premier prompt, qui portait l’essentiel du contexte sur l’objectif.

Sa solution : demander à l’agent de tenir un journal de travail court. Il contient trois choses. L’objectif global. Le travail en cours. Et la façon dont votre dernière consigne s’accorde avec les deux.

Gardez-le court exprès. Un journal qui note chaque test raté devient un carnet que personne ne lit, et il remplit à nouveau le contexte. C’est la même idée que le fichier de plan de Ralph, tenu par l’agent à l’intérieur d’une seule longue session.

Il a conclu sur un avertissement qui va bien à toute cette note : les bonnes pratiques ont une date de péremption, alors ne vous attachez pas à votre façon de travailler. La boucle bash était la bonne pratique il y a un an.

Un journal de travail, en trois parties

Écrivez-le, pour que l’objectif survive à la compaction

1. L’objectif globalÀ quoi sert toute la tâche.
2. Le travail en coursCe qui avance maintenant.
3. Votre dernière consigneComment elle s’accorde avec les deux.

Court exprès : pas un carnet de chaque test raté.

À essayer

La boucle Ralph arrive vers 7:10 dans la vidéo, /goal juste après, et les conseils d’Eric sur les agents vers 11:00.

• OpenAI, What Comes After Loops?, DevDay 2026, 24 minutes, en anglais.
• Geoffrey Huntley, Ralph Wiggum as a "software engineer", l’article d’origine.
• Anthropic, Effective harnesses for long-running agents, la liste de fonctionnalités et le fichier d’avancement.
• Documentation de Claude Code : /goal, /loop, les équipes d’agents, et le plugin Ralph Loop.
• Documentation de Codex : les commandes slash, dont /goal, et les sous-agents.
• Forkez le harnais de votre agent, gardez le meilleur, sur l’amélioration du code autour du modèle.
• TokenOps : pourquoi un agent à 40 tours coûte 16×, et pas 4×, sur ce que coûtent les longues sessions.

Avant d’écrire votre propre boucle, regardez ce que votre outil et votre modèle font déjà. Donnez un goal à une tâche, avec une condition que le vérificateur peut voir, comme une commande de test et sa sortie. Puis dites-moi où il s’est arrêté, et pourquoi.

Texte brut: ralph-loop-moved-into-the-model.md · Flux Atom · Toutes les notes