Les loops d'agents IA : comment un agent de code s'auto-corrige tout seul

La façon dont la plupart des gens utilisent encore un agent de code IA ressemble à du ping-pong. Tu promptes, il répond, tu repères ce qui cloche, tu re-promptes. C'est toi le moteur de correction, et tu es dans la boucle à chaque tour.

Un loop renverse ça. Tu décris ce que tu veux, l'agent se met au boulot, écrit sa propre checklist, repère ses points faibles, et recommence jusqu'à ce que le résultat tienne la route. Tu cesses d'être celui qui rattrape les erreurs. L'agent rattrape les siennes.

Ce basculement, ce n'est pas de la hype. Les gens qui ont construit ces outils s'appuient dessus. Boris Cherny et Cat Wu, les créateurs de Claude Code, parlent de coder en agent loops. Geoffrey Huntley, qui a baptisé le « Ralph loop », fait tourner des agents dans une simple boucle while la nuit. Le pattern a un nom maintenant, et ça vaut le coup de le comprendre avant de copier trois prompts vus sur Instagram.

Du ping-pong de prompts au loop

Un prompt isolé, c'est un coup unique. Tu demandes, tu obtiens une réponse, la transaction s'arrête. Pour l'améliorer, tu dois repérer l'écart et re-prompter. Passe ça à l'échelle d'une vraie feature et tu enchaînes des dizaines de micro-corrections à la main.

Un loop d'agent IA referme cet écart à l'intérieur de l'agent. Tu fixes un objectif, l'agent planifie, agit, regarde le résultat, corrige, encore et encore, jusqu'à atteindre l'objectif. Tu n'as pas disparu, tu relis à la fin. Mais tu n'es plus le goulot d'étranglement à chaque itération.

Le ping-pong de prompts te met dans la boucle à chaque tour. Un vrai loop y met l'agent.

Ce qu'est vraiment un loop d'agent IA

Tout loop agentique tourne sur les mêmes quatre temps : planifier, agir, observer, corriger. L'agent décide de l'étape suivante, la fait (écrit du code, lance une commande, lit un fichier), lit ce qui s'est passé, et ajuste. Claude écrit du code, lance les tests, voit un échec, corrige, relance les tests. Ce retour, c'est toute l'astuce. C'est ce qui rend le loop auto-correcteur, et pas juste répétitif.

La version la plus solide du loop répartit ces temps sur trois rôles : un qui planifie, un qui construit, un qui relit. Les garder séparés, c'est ce qui empêche l'agent de corriger sa propre copie dans le même souffle où il l'écrit.

Le loop en trois commandes que tu peux copier aujourd'hui

Voici le montage qui circule en ce moment, refait en trois commandes Claude Code. Tu colles chacune une fois, l'agent crée la commande, puis tu les lances dans l'ordre.

Le planificateur, /spec :

Interviewe-moi une question à la fois jusqu'à bien comprendre ce que je veux.
Puis écris un plan précis dans specs/projet.md : l'objectif, les besoins
exacts, les cas limites, et ce qui est dans le périmètre ou hors périmètre.
Garde-le court et net, pas un roman.

Le constructeur, /build :

Lis specs/projet.md et construis exactement ce qui est décrit, rien de plus.
Quand tu as fini, liste chaque besoin du plan et indique lesquels tu as
couverts.

Le relecteur, /review :

Compare ce qui a été construit à specs/projet.md, besoin par besoin.
Pour chacun, dis s'il est couvert. Écris les corrections nécessaires et
renvoie-les à /build. Ne valides que quand tout le plan est couvert.

Trois commandes, un loop : spec écrit le plan, build l'implémente, review le compare au plan et renvoie les corrections à build. Ça boucle jusqu'à ce que chaque besoin soit satisfait.

Le plan est la source de vérité. La relecture mesure la construction face à lui, pas face à une impression.

C'est du spec-driven coding sous le capot : c'est le spec écrit, pas l'historique de chat, qui sert de juge à l'agent. Le Spec Kit open-source de GitHub formalise la même idée avec /specify, /plan, /tasks et /implement, et il tourne aussi bien sur Claude Code, Copilot, Cursor, Codex CLI que Gemini CLI.

Pourquoi un contexte neuf fait marcher le loop : le Ralph loop

Geoffrey Huntley a baptisé la version la plus brute de tout ça à la mi-2025 : le Ralph loop. L'idée, c'est une simple boucle shell qui sert à l'agent le même prompt face à un spec écrit, le laisse choisir une tâche et la livrer, puis démarre un tout nouvel agent au contexte vierge et lui sert le prompt identique.

while reste_des_taches; do
  agent --prompt "Traite la prochaine tâche de todo.md" --non-interactive
done

La partie contre-intuitive, c'est la remise à zéro du contexte. Une longue session pourrit : la fenêtre se remplit de vieux raisonnements, d'impasses et de contenus de fichiers périmés, et le modèle se met discrètement à lâcher des instructions. Chaque itération Ralph est un nouvel agent qui lit le repo et la liste de tâches depuis le disque, fait une unité de travail, commit, et sort propre. Huntley l'a nommé d'après le personnage des Simpson exprès : ça a l'air trop bête pour marcher, et ça marche. Si tu as déjà vu une longue session commencer à halluciner, tu sais déjà pourquoi une fenêtre neuve bat une fenêtre saturée.

Les commandes /loop et /goal de Claude Code

Claude Code embarque directement des primitives de loop. /goal fixe un état final persistant, à quoi ressemble « fini », et Claude évalue sa progression face à lui après chaque passe, au lieu de juste lancer l'étape suivante. /loop répète une tâche à une cadence ou jusqu'à ce qu'une condition tienne, avec des formes comme /loop every 10m ou /loop until: <condition>. Ensemble, ils créent un loop auto-dirigé et auto-terminé : Claude travaille l'écart entre l'état actuel et l'objectif, et s'arrête quand l'objectif est atteint ou que tu fais Ctrl+C.

Le détail qui compte : un loop garde la continuité. Il se souvient de ce qu'il a essayé et pourquoi ça a échoué, donc chaque passe s'appuie sur la précédente au lieu de répéter la même impasse. C'est l'arbitrage inverse de la remise à zéro de Ralph, et les deux sont valables. La continuité pour une auto-correction serrée, le contexte neuf quand la fenêtre pourrit. Savoir lequel dégainer, c'est ça la vraie compétence.

Le même loop, chez chaque provider

Les loops ne sont pas une feature Claude, c'est la direction que prend tout le secteur. Les noms changent, la forme non.

Codex CLI a poussé le loop le plus loin en public. L'équipe d'OpenAI a présenté son /goal comme sa version du Ralph loop, et Andrew Chen, d'a16z, l'a laissé tourner toute une nuit sur un pilote de périphérique, 14 heures d'affilée sans intervention. Il a aussi noté que ça allait « multiplier par 10 000 la conso de tokens », ce qui est le coût honnête de laisser un agent moudre pendant une demi-journée.

Le piège : un loop amplifie tout

Un loop n'amplifie pas que le bon output, il amplifie aussi un mauvais plan. Pointe un agent auto-correcteur sur un spec flou et il construira la mauvaise chose avec aplomb, la relira face au même spec flou, et validera. Le plan, c'est le levier. Un spec net économise dix prompts, un spec brumeux en gâche cent.

Deux modes d'échec à surveiller. Le coût s'emballe : chaque itération brûle des tokens, et un loop sans borne sur un objectif flou peut en brûler beaucoup. Et le loop peut tourner à l'infini, en criant victoire ou en chassant une cible qu'il ne pourra jamais satisfaire. Borne-le : une condition until claire, un plafond de tokens, ou un point de contrôle humain avant le merge. Un loop sans arrêt, ce n'est pas de l'autonomie, c'est un emballement.

Faire tourner des loops sur toute une flotte

Un seul agent auto-correcteur, c'est facile à surveiller. Le levier apparaît quand tu en fais tourner plusieurs en même temps, chacun bouclant sur sa propre tâche, et c'est précisément là que surveiller un terminal cesse de passer à l'échelle.

C'est pour ça qu'AgentsRoom est conçu. C'est un cockpit multi-agents : chaque agent a un rôle, un point de statut en direct et sa propre couleur, et tu supervises toute la flotte depuis une seule fenêtre. Pose un ticket sur le backlog et un agent le ramasse, déroule son loop plan-build-review, et te rend un diff propre. C'est le spec-driven AI coding en pratique : le ticket est le spec, l'agent déroule le loop, tu relis le résultat.

Comme les longs loops pourrissent le contexte, AgentsRoom le guette. Chaque agent écrit un statut d'une ligne à la fin de chaque tour, et quand un agent arrête de le mettre à jour deux tours d'affilée, un avertissement apparaît avec un redémarrage en un clic sur un contexte propre, exactement la même remise à zéro de fenêtre sur laquelle s'appuie le Ralph loop. Découvre comment ça marche sur la page détection de dérive de contexte.

Et comme le loop est agnostique du provider, tu n'es enfermé chez aucun. Lance un ticket sur Claude Code, le suivant sur Codex, un autre sur Gemini CLI, tout dans le même dashboard, chacun bouclant dans son propre git worktree pour que les agents parallèles ne se télescopent jamais. Lance-les avant de couper, relis les diffs au matin, c'est tout l'intérêt des agents de code en arrière-plan et de l'équipe de nuit.

Fixe l'objectif une fois, laisse le loop le refermer, relis à la fin. Télécharge AgentsRoom, consulte la matrice de compatibilité des providers, et lis-en plus sur la relecture par agent et le support multi-provider.