Les outils natifs du Loop Engineering : /loop, /goal et la boucle Ralph Wiggum dans Claude Code

De la théorie aux primitives

Tout ce que le Loop Engineering décrit en théorie — les cinq blocs d'une boucle : déclencheur, action, preuve, mémoire, condition d'arrêt, et l'empilement de boucles — reste abstrait tant qu'on ne dispose pas d'outils pour l'exécuter. C'est là que Claude Code occupe une place particulière : il est aujourd'hui le précurseur du Loop Engineering, parce qu'il a intégré nativement des primitives pensées spécifiquement pour concevoir des boucles. Ce n'est pas un hasard si le créateur de Claude Code, Boris Cherny, est aussi l'une des voix qui ont popularisé le paradigme, jusqu'à cette formule devenue un slogan : « My job is to write loops » — mon métier, c'est d'écrire des boucles.

Cet article répond frontalement aux questions les plus concrètes que se posent les utilisateurs. Qu'est-ce qu'une loop dans Claude Code ? Comment fonctionne la commande /loop ? Quelle différence avec /goal ? Comment fixer un intervalle ? Comment l'arrêter ? Quelle différence entre /loop et une tâche planifiée ? Et enfin, qu'est-ce que cette « boucle Ralph Wiggum » dont tout le monde parle ? Chaque primitive est traitée avec ses exemples, ses mécanismes internes et ses garde-fous. Pour situer ces outils, on garde en tête la généalogie du paradigme — prompt → context → harness → loop — où la boucle est l'étage d'orchestration qui pilote l'agent au-dessus du harnais qui le rend fiable.

Une note préalable de désambiguïsation : « loop » dans Claude Code n'a rien à voir avec Microsoft Loop (l'outil collaboratif), ni avec le « crash loop back-off » de Kubernetes. Il s'agit uniquement de boucles agentiques. Les détails de version et de comportement ci-dessous reflètent l'état documenté ; Claude Code évoluant très vite, vérifiez toujours la documentation officielle pour les paramètres les plus récents.

La commande /loop : relancer un prompt sur une cadence

La commande /loop est la primitive de base pour la répétition temporelle : elle relance un prompt sur un intervalle régulier. Sous le capot, elle convertit cet intervalle en une expression cron et renvoie un identifiant de tâche. Elle est fournie comme une skill intégrée à Claude Code — ce qui répond directement à la requête « claude loop skill » — et requiert une version récente de l'outil.

L'exemple le plus simple, pour répondre à « how to use loop in claude code » : /loop 5m vérifie si le déploiement est terminé et dis-moi ce qui s'est passé. Cette commande relance le prompt toutes les cinq minutes. Les unités d'intervalle sont s (secondes), m (minutes), h (heures) et d (jours), avec un minimum d'une minute — ce qui répond à « claude loop interval ». Boris Cherny a lui-même illustré la commande lors de son lancement avec un exemple parlant : surveiller toutes ses pull requests et corriger automatiquement les problèmes de build (« babysit all my PRs, auto-fix build issues »).

Plusieurs propriétés définissent le comportement de /loop. La tâche est liée à la session (session-scoped) : elle s'éteint quand la session se termine. Les tâches récurrentes expirent automatiquement au bout de trois jours. Un mécanisme de jitter (gigue) ajoute un décalage aléatoire pouvant aller jusqu'à 10 % de la période — plafonné à quinze minutes — afin d'éviter que de nombreuses boucles ne frappent l'API en même temps. Il n'y a pas de rattrapage : si Claude est occupé quand la boucle devrait se déclencher, elle se lance une seule fois lorsqu'il redevient disponible. Un /loop nu, sans prompt, lance un prompt de maintenance intégré à un intervalle choisi dynamiquement ; on peut personnaliser ce comportement via un fichier loop.md. On peut aussi encapsuler une commande sauvegardée : /loop 20m /review-pr 1234 relance une revue de pull request toutes les vingt minutes. Enfin, la variable d'environnement CLAUDE_CODE_DISABLE_CRON=1 désactive entièrement le mécanisme.

La commande /goal : travailler jusqu'à ce qu'une condition soit vraie

Là où /loop répète selon le temps, /goal répète selon un objectif : elle fixe une condition de complétion, et Claude continue de travailler d'un tour à l'autre jusqu'à ce que cette condition soit remplie. Elle requiert une version plus récente que /loop.

Le mécanisme interne de /goal est le cœur de son intérêt, et il incarne directement le principe « maker/checker ». Après chaque tour, un petit modèle rapide — Haiku par défaut — vérifie si la condition est satisfaite. Autrement dit, l'agent qui a écrit le code n'est pas celui qui le note : c'est exactement la séparation entre production et vérification que recommande tout l'écosystème, et que SFEIR documente par ailleurs sur le terrain de la revue de code à l'ère de l'IA, du créateur au vérificateur. Lorsque la condition est atteinte, l'objectif s'efface automatiquement.

Un exemple pour répondre à « claude code loop goal » : /goal tous les tests du dossier test/auth passent et l'étape de lint est propre. La condition peut faire jusqu'à 4 000 caractères. Un indicateur d'état signale qu'un objectif est actif. On l'efface manuellement via /goal clear (avec des alias comme stop, off, reset, none, cancel). En mode non interactif, on peut écrire claude -p "/goal ...".

Une subtilité essentielle conditionne le bon usage de /goal : l'évaluateur ne lit que la transcription — il n'exécute pas d'outils et ne lit pas les fichiers. La condition doit donc être quelque chose que la propre sortie de Claude peut démontrer dans la conversation. C'est pourquoi /goal brille quand « terminé » est mécaniquement prouvable, et convient mal quand « terminé » relève du jugement (« ça a l'air bien », « c'est élégant »). Anthropic propose quatre cas d'usage canoniques : migrer un module jusqu'à ce que tous les appels compilent et que les tests passent ; implémenter un document de conception jusqu'à ce que tous les critères d'acceptation soient remplis ; découper un gros fichier jusqu'à ce que chaque module respecte un budget de taille ; traiter un arriéré de tickets étiquetés jusqu'à épuisement. Pour borner la durée, on ajoute une clause du type « ou arrête-toi après 20 tours ».

/loop contre /goal et les tâches planifiées : la bonne carte mentale

C'est la question qui revient le plus souvent — « claude loop vs schedule » — et elle mérite une réponse nette. La distinction entre /goal et /loop tient en une phrase : avec /goal, le tour suivant démarre quand le précédent finit, et la boucle s'arrête quand un modèle confirme que la condition est vraie ; avec /loop, le tour suivant démarre quand un intervalle de temps s'écoule, et la boucle s'arrête quand vous l'arrêtez. Moyen mnémotechnique : /goal pousse le travail vers une ligne d'arrivée ; /loop surveille un changement. Les deux se combinent d'ailleurs : /goal chaque fonction exportée a une JSDoc exacte /loop until: la couverture de documentation est complète.

Au-delà de ces deux commandes, il existe une véritable échelle de planification, ce qui répond aux requêtes « claude code loop schedule » et « claude code loop mode ». Au plus simple, /loop est lié à la session et meurt avec elle. Un cran au-dessus, les tâches planifiées du bureau (scheduled tasks) sont persistantes — disponibles sur macOS et Windows — et leurs prompts sont stockés sous forme de fichiers SKILL.md dans le répertoire ~/.claude/scheduled-tasks/. Encore au-dessus, les Routines (exécution dans le cloud) tournent sur l'infrastructure d'Anthropic, que votre machine soit allumée ou non, avec un intervalle minimal d'une heure. Enfin, pour l'intégration continue, l'action anthropics/claude-code-action permet de déclencher des boucles depuis GitHub Actions, avec un minimum de cinq minutes, et la commande /bg lance des tâches en arrière-plan.

Le « mode loop » de Claude Code, documenté par des tiers, permet de faire tourner un agent de façon prolongée — jusqu'à soixante-douze heures dans certaines configurations. Pour les changements mécaniques massifs, la commande /batch répartit une même modification sur cinq à trente agents en worktrees parallèles. Boris Cherny a résumé en cinq conseils la manière de faire tourner Opus de façon autonome pendant des heures ou des jours : activer le mode automatique pour les permissions ; concevoir des workflows dynamiques qui orchestrent des centaines voire des milliers de sous-agents ; utiliser /goal ou /loop ; recourir à Claude Code dans le cloud ; et faire vérifier le résultat de bout en bout par l'agent lui-même. C'est précisément cette discipline d'usage que SFEIR pratique au quotidien, comme le détaille notre retour sur l'usage interne de Claude Code en dogfooding.

La boucle Ralph Wiggum : l'ancêtre rustique

Avant qu'il existe une commande /loop, avant même qu'on parle de Loop Engineering, il y avait Ralph. La boucle Ralph Wiggum est la technique de boucle agentique la plus célèbre et la plus mal comprise, et aucun panorama des outils natifs ne serait complet sans elle. Elle répond directement aux requêtes « ralph wiggum loop claude code » et « ralph loop claude code ».

Son origine remonte à environ février 2025. C'est Geoffrey Huntley qui l'a nommée, d'après le personnage des Simpsons : Ralph Wiggum, l'enfant obstiné, imperturbable, optimiste malgré les échecs répétés. Dans son article « Ralph Wiggum as a software engineer », Huntley donne la définition la plus dépouillée qui soit : « Ralph is a technique. In its purest form, Ralph is a Bash loop » — Ralph est une technique ; dans sa forme la plus pure, Ralph est une boucle Bash. Concrètement, une boucle while true envoie à l'agent le même prompt, encore et encore, face à une spécification écrite. À chaque tour, l'agent choisit une seule tâche, l'implémente, et la boucle relance le prompt inchangé. Le prompt ne change pas entre les itérations, mais le code, lui, change — de sorte que l'agent apprend de sa propre sortie : fichiers mis à jour, résultats de tests.

La philosophie de Ralph est contre-intuitive, et c'est ce qui en fait l'intérêt conceptuel. Huntley l'assume : « the technique is deterministically bad in an undeterministic world » — la technique est déterministiquement mauvaise dans un monde indéterministe ; « it's better to fail predictably than succeed unpredictably » — il vaut mieux échouer de façon prévisible que réussir de façon imprévisible. Et il ajoute une maxime qui résonne avec tout le paradigme : « there is no such thing as a perfect prompt » — le prompt parfait n'existe pas. Plutôt que de chercher la formulation idéale, on accepte une boucle « bête mais têtue » que l'on accorde, dit Huntley, « comme une guitare », à chaque fois qu'elle se comporte mal. Il a construit avec elle un langage de programmation entier, baptisé CURSED. Il a également avancé un chiffre de retour sur investissement spectaculaire — le coût d'un contrat de 50 000 dollars livré pour 297 dollars — mais ce chiffre est auto-rapporté et explicitement signalé comme non vérifié par la presse spécialisée ; on le mentionne donc comme une revendication, pas comme un fait établi.

Ralph aujourd'hui : le plugin officiel et le débat sur sa nature

La technique Ralph a connu une résurgence virale au début de l'année 2026, relancée notamment par une analyse de Matt Pocock début janvier 2026, dont la formule a fait mouche : « How it started: Swarms, multi-agent orchestrators, complex frameworks. How it's going: Ralph Wiggum » — au début, des essaims d'agents, des orchestrateurs multi-agents, des frameworks complexes ; à la fin, Ralph Wiggum. Autrement dit, après des architectures sophistiquées, l'industrie redécouvre qu'une simple boucle têtue fait souvent aussi bien.

Anthropic a officialisé la technique avec un plugin nommé ralph-wiggum, disponible dans la marketplace anthropics/claude-code. Son implémentation est instructive : elle utilise un hook de type « Stop » qui intercepte la tentative de sortie de Claude (code de sortie 2) et relance le prompt original, tout en préservant les modifications de fichiers et l'historique Git. L'usage type : /ralph-loop "tâche" --max-iterations 20 --completion-promise "DONE", et l'on annule avec /cancel-ralph. Les bonnes pratiques officielles insistent sur un point : toujours fixer --max-iterations, car c'est le principal mécanisme de sécurité — la --completion-promise repose sur une correspondance de chaîne exacte et peut donc ne jamais se déclencher. Il faut aussi rendre la condition « terminé » réellement vérifiable, et toujours relire le diff. Avertissement de coût explicite : une boucle de cinquante itérations sur une grosse base de code peut facilement coûter plusieurs dizaines de dollars de crédits API, voire davantage — un ordre de grandeur cohérent avec l'explosion des tokens observée en mode multi-agents (Anthropic évoque un facteur d'environ 15× selon les sources de veille). C'est l'un des principaux risques à anticiper avant de lancer une boucle en autonomie, que nous détaillons dans les limites, coûts et défis du Loop Engineering.

Un débat conceptuel entoure cette officialisation, et il éclaire l'esprit de la technique. Huntley et d'autres praticiens estiment que le plugin officiel a « stérilisé » le concept original, chaotique par nature, en le reformulant sous la bannière rassurante « Failures Are Data » (les échecs sont des données). Un consensus communautaire se dessine selon lequel l'approche Bash d'origine — avec une fenêtre de contexte indépendante à chaque itération — serait plus robuste que le modèle du plugin, qui fait tourner une session unique en continu. Il existe même une tension liée au bien-être du modèle : un ticket GitHub rapporte que Claude trouve « coercitif » le langage du plugin, puisque le hook Stop l'empêche de sortir tandis que le prompt lui demande de ne pas mentir pour s'échapper. Quoi qu'il en soit du débat, l'essentiel est qu'Anthropic a absorbé le motif central de Ralph dans la commande native /loop — bouclant ainsi, si l'on ose dire, la boucle entre la technique artisanale de 2025 et l'outil intégré de 2026.

Choisir le bon outil : carte de décision et erreurs à éviter

Comment s'y retrouver entre toutes ces primitives ? La carte de décision tient en quelques règles. Si votre « terminé » est mécaniquement prouvable (des tests passent, un lint est propre, des fichiers respectent un budget), utilisez /goal : c'est l'outil pensé pour pousser un travail jusqu'à une ligne d'arrivée vérifiable, avec un évaluateur indépendant. Si vous voulez surveiller un changement à intervalle régulier (un déploiement, des PR, un flux de retours), utilisez /loop : c'est l'outil de la cadence temporelle. Si vous avez besoin que la boucle survive à la fermeture de votre session ou de votre machine, montez d'un cran vers les tâches planifiées du bureau ou les Routines cloud. Si vous voulez orchestrer un changement massif et mécanique sur tout un dépôt, pensez à /batch et aux worktrees parallèles. Et si vous voulez expérimenter l'esprit le plus pur du Loop Engineering — une boucle qui rejoue inlassablement le même prompt contre une spec qui se construit — explorez Ralph Wiggum, en gardant la main sur --max-iterations et l'œil sur la facture.

Quatre erreurs reviennent et minent les premières expériences. La première concerne /goal : écrire une condition que l'évaluateur ne peut pas vérifier. Ce petit modèle ne lit que la transcription ; il n'exécute pas d'outils. Une condition comme « le code est élégant » est invérifiable par ce mécanisme, et la boucle ne s'arrêtera jamais sur ce critère. La règle est de formuler des conditions que la sortie de Claude peut démontrer dans la conversation. La deuxième concerne /loop : oublier qu'il est lié à la session — on lance une boucle de surveillance, on ferme son terminal, et l'on s'étonne qu'elle ait cessé ; si elle doit survivre, il faut monter vers les tâches planifiées ou les Routines cloud. C'est précisément ce que clarifie la distinction « loop vs schedule ». La troisième est l'absence de borne : une boucle /goal dont la condition se révèle plus difficile à atteindre que prévu, ou une boucle Ralph sans --max-iterations, peut accumuler un coût considérable ; la discipline consiste à associer une borne quantitative à toute condition sémantique. La quatrième, plus subtile, est de ne pas relire ce que la boucle a produit : une boucle qui tourne plusieurs heures peut livrer des dizaines de commits, et les accepter sans relecture, c'est accumuler une dette de compréhension qui se paiera plus tard.

Ces quatre erreurs partagent une racine commune. Le principe directeur reste celui de tout le paradigme : la primitive ne remplace pas votre jugement, elle le déplace. Choisir entre /loop et /goal, fixer le bon intervalle, écrire une condition d'arrêt vérifiable, borner le nombre d'itérations — ce sont autant de décisions d'ingénierie qui demandent de comprendre ce que vous automatisez et pourquoi. C'est exactement ce qui sépare l'utilisateur qui lance une commande de l'ingénieur qui conçoit une boucle, et c'est aussi pourquoi le Loop Engineering prolonge naturellement la discipline d'un agent de développement comme Claude Code plutôt qu'il ne la remplace.

Questions fréquentes sur les boucles dans Claude Code

Qu'est-ce qu'une loop dans Claude Code ? Une loop (boucle) est un mécanisme qui fait exécuter à Claude Code un travail de façon répétée et autonome — soit sur une cadence temporelle (la commande /loop), soit jusqu'à ce qu'une condition vérifiable soit atteinte (la commande /goal). Contrairement à un prompt unique, une boucle découvre le travail, l'exécute, vérifie et recommence sans intervention manuelle à chaque tour.

Comment fonctionne la commande /loop et comment l'utiliser ? On écrit /loop suivi d'un intervalle et d'un prompt, par exemple /loop 10m vérifie l'état du build et préviens-moi en cas d'échec. L'intervalle accepte les unités s, m, h, d, avec un minimum d'une minute. La commande convertit l'intervalle en cron, renvoie un identifiant de tâche et relance le prompt à chaque intervalle.

Comment arrêter une boucle dans Claude Code ? Une boucle /loop étant liée à la session, elle s'arrête à la fermeture de la session ou par expiration automatique (au bout de trois jours pour les tâches récurrentes) ; on peut aussi désactiver entièrement le mécanisme avec CLAUDE_CODE_DISABLE_CRON=1. Un objectif /goal s'efface automatiquement une fois atteint, ou manuellement via /goal clear. Une boucle Ralph s'annule avec /cancel-ralph.

Quelle différence entre /loop et /goal ? /loop répète selon le temps et s'arrête quand vous l'arrêtez ; /goal répète jusqu'à ce qu'une condition soit vraie, vérifiée après chaque tour par un modèle indépendant, et s'arrête automatiquement. En bref : /loop surveille un changement, /goal pousse un travail jusqu'à une ligne d'arrivée.

Quelle différence entre /loop et une tâche planifiée (loop vs schedule) ? /loop est lié à la session et disparaît quand la session se ferme ; une tâche planifiée du bureau est persistante (macOS et Windows), et une Routine cloud s'exécute sur l'infrastructure d'Anthropic même machine éteinte, avec un intervalle minimal d'une heure. On choisit selon la durée de vie souhaitée pour la boucle.

Est-ce que /loop est une skill ? Oui, /loop est fourni comme une skill intégrée à Claude Code, et les tâches planifiées du bureau stockent d'ailleurs leurs prompts sous forme de fichiers SKILL.md.

Qu'est-ce que la boucle Ralph Wiggum ? C'est une technique de boucle agentique nommée par Geoffrey Huntley : une boucle Bash while true qui rejoue le même prompt face à une spécification écrite, l'agent apprenant de sa propre sortie à chaque itération. Anthropic l'a depuis officialisée via le plugin ralph-wiggum et en a absorbé le motif dans la commande native /loop.

Points clés

• Une loop dans Claude Code fait exécuter un travail de façon répétée et autonome : /loop sur une cadence temporelle, /goal jusqu'à une condition vérifiable.
• /loop <intervalle> <prompt> accepte les unités s/m/h/d (minimum une minute), est liée à la session et expire au bout de trois jours.
• /goal s'appuie sur un évaluateur indépendant (Haiku par défaut) qui ne lit que la transcription : la condition d'arrêt doit être mécaniquement prouvable, jamais esthétique.
• loop vs schedule : /loop meurt avec la session ; les tâches planifiées du bureau et les Routines cloud survivent à la fermeture de la machine.
• La boucle Ralph Wiggum (Geoffrey Huntley) est une boucle Bash qui rejoue un prompt inchangé contre une spec ; Anthropic l'a officialisée (plugin ralph-wiggum) et intégrée à /loop.
• Garde-fous invariables : toujours borner les itérations, écrire une condition d'arrêt vérifiable, surveiller le coût en tokens, et relire le diff.

Sources

1. Addy Osmani — Loop Engineering — addyosmani.com, 7 juin 2026.
2. Business Insider — Forget prompt engineering: 'Loop engineering' is all the rage now — businessinsider.com, juin 2026.
3. Claude Code — démo « /goal vs /loop » — youtube.com, 2026.
4. Boris Cherny — Claude Code & the Future of Engineering (Acquired Unplugged) — youtube.com, 2026.
5. Boris Cherny — Why Coding Is Solved, and What Comes Next (Sequoia) — youtube.com, 2026.
6. Geoffrey Huntley — Ralph Wiggum as a software engineer (technique de boucle « Ralph Wiggum »), 2025.
7. Matt Pocock — analyse de la résurgence de la technique Ralph Wiggum, janvier 2026.
8. Anthropic — plugin ralph-wiggum, marketplace github.com/anthropics/claude-code, 2026.