Ingénierie des boucles : boucles Claude Code, routines et workflows

En bref : Le loop engineering consiste à faire répéter aux agents des cycles de travail jusqu’à ce qu’une condition d’arrêt soit remplie, au lieu de les solliciter une étape à la fois. Boris Cherny, créateur de Claude Code chez Anthropic, décrit sans détour son propre workflow : « Je ne sollicite plus Claude. J’ai des loops en cours d’exécution. Ce sont elles qui sollicitent Claude et déterminent ce qu’il faut faire. Mon travail consiste à écrire des loops. »¹ Claude Code propose désormais toute une gamme de surfaces de loop : /goal (répétition jusqu’à ce qu’un modèle distinct confirme qu’une condition est remplie ou la juge impossible), /loop (exécutions locales récurrentes), le plugin Ralph officiel (itération jusqu’à ce qu’une promesse soit tenue), les tâches planifiées dans le cloud (anciennement routines ; cron dans le cloud) et les workflows dynamiques (Claude écrit un graphe d’orchestration JavaScript et y exécute jusqu’à 1 000 subagents). Pourtant, aucune de ces fonctionnalités ne constitue le pilier de cette pratique : c’est la vérification. Une loop ne converge que lorsqu’un élément extérieur au générateur — un test, un modèle évaluateur, une comparaison de pixels ou un contrôle automatisé — décide que le travail est « terminé ». Si la vérification est bien conçue, les loops produisent des effets cumulatifs ; dans le cas contraire, vous financez une marche aléatoire extrêmement coûteuse. Ce guide couvre chaque surface de loop avec ses versions de référence, le pattern Ralph et ses modes de défaillance, les situations dans lesquelles les loops doivent devenir des graphes, l’échelle de vérification, la maîtrise des coûts et de la sécurité, ainsi que la gestion d’une flotte permanente. Informations à jour pour Claude Code v2.1.312 (octobre 2026).

Qu’est-ce que le loop engineering ?

Il y a deux ans, les ingénieurs écrivaient le code source à la main. Puis des agents ont écrit le code à partir de prompts humains. La transition actuellement à l’œuvre se situe un niveau plus haut : les agents envoient des prompts à d’autres agents, tandis que l’humain écrit le système qui décide quels prompts envoyer. Cherny mesure directement l’ampleur de cette évolution : « Le passage du code source aux agents était considérable ; les loops représentent une étape tout aussi importante et majeure. »²

Sa définition est d’une simplicité rafraîchissante : « Un loop est essentiellement une tâche cron exécutée localement pour Claude. Une routine, c’est la même chose, mais exécutée dans le cloud. »³ Cette pratique aux allures exotiques — « des centaines, parfois des milliers d’agents qui travaillent pendant 5, 10 ou 20 heures » durant la nuit,⁴ Claude Code « écrit à 100 % par Claude Code depuis plus de six mois »⁴ — se résume à quelques primitives : un prompt relancé selon une planification ou une condition, un état qui persiste d’une itération à l’autre et un contrôle qui met fin à l’exécution.

Anthropic a donné un nom à cette discipline en juin 2026 : les loops sont « des agents qui répètent des cycles de travail jusqu’à ce qu’une condition d’arrêt soit remplie », et « la qualité du résultat d’un loop dépend du système qui l’entoure ».⁵ C’est précisément ce système environnant que ce guide aborde.

Une précision sur l’origine des termes s’impose, car le discours a évolué rapidement à la mi-2026 : l’expression « graph engineering » — souvent attribuée à Cherny dans des publications virales — a été forgée par la communauté (avec la question de Peter Steinberger du 18 juillet, « parlons-nous toujours de loops ou sommes-nous déjà passés aux graphs ? », amplifiée par Hamel Husain), et non par Anthropic ou Cherny.⁶ La citation largement relayée « 85 % de nos ingénieurs… la méthode consiste à faire du graph engineering » ne circule que dans des publications de tiers ; lors de la préparation de ce guide, nous n’avons pu la retrouver dans aucune source primaire de ses interventions (la conversation à la YC Startup School, Odd Lots de Bloomberg, le compte rendu de Meta @Scale par TechCrunch). Considérez donc cette attribution comme non vérifiée. Sa pratique réelle adopte bien la forme d’un graph (des orchestrateurs qui lancent des subagents d’implémentation, de vérification et de correction, imbriqués jusqu’à une profondeur de 5), mais le vocabulaire attesté est celui des loops, des routines et des workflows — et c’est celui qu’emploie ce guide.

Parcours idéal en cinq minutes

Trois commandes suffisent pour passer des prompts aux loops :

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud scheduled task (formerly a routine): runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

La différence entre ces commandes et un prompt est structurelle, pas cosmétique : chacune possède une règle de relance (une condition, une horloge ou une tâche cron) et nécessite une règle d’arrêt. Tout le reste de ce guide explique comment rendre ces deux règles fiables.

Le loop central et la règle unique

Tous les systèmes agentiques suivent le même cycle interne, que la documentation Agent SDK de Anthropic consacre sous la forme recueillir le contexte → agir → vérifier le travail → recommencer.⁷ Le processus propre à Claude Code est lui aussi un loop : évaluer le prompt, appeler des outils, lire leurs résultats, puis recommencer jusqu’à obtenir une réponse sans appel d’outil.⁸

Le loop engineering enveloppe ce cycle interne de loops externes — et en hérite une règle non négociable, énoncée par toutes les sources sérieuses du domaine :

L’agent qui effectue le travail ne l’évalue jamais.

• Documentation /goal de Anthropic : « la réalisation est évaluée par un nouveau modèle, et non par celui qui effectue le travail. »⁹
• Essai de Anthropic sur la conception d’un harness : « Séparer l’agent qui effectue le travail de celui qui l’évalue s’avère être un levier puissant pour résoudre ce problème. »¹⁰
• Cherny, à propos de ce qui échappe aux praticiens : « La vérification est probablement l’élément le plus important que les gens ne maîtrisent pas. »³ Dans son exemple pratique, il donne cette consigne pour une réécriture d’Electron vers Swift en deux semaines : « exécutez l’application Electron dans la machine virtuelle Mac, faites-en une capture d’écran, puis examinez-la pixel par pixel. Comparez-la à la version Swift. Ne vous arrêtez pas avant d’avoir terminé. »³

La raison est mécanique, et non morale : un modèle auquel on demande « avez-vous terminé ? » présente un biais d’autoévaluation positive, tandis qu’une transcription formulée avec assurance peut convaincre une condition de sortie évaluée par un modèle de conclure prématurément que le travail est « terminé ».¹¹ Une vérification externe — une suite de tests, un compilateur, une comparaison pixel par pixel ou un nouveau modèle sans intérêt dans la réponse — constitue le seul signal capable d’y résister.

L’échelle d’autonomie

Les surfaces de loop dans Claude Code forment une échelle allant de « appuyez de nouveau sur Entrée » à « s’exécute sans vous ». Chaque niveau échange davantage d’autonomie contre une charge de vérification accrue :

(La présentation par niveaux reprend la taxonomie publiée par pardel.dev en juillet 2026, la cartographie indépendante la plus claire du domaine.¹¹)

Une option locale se situe entre les niveaux 3 et 5 : les tâches planifiées Desktop s’exécutent sur votre machine sans session ouverte, à des intervalles pouvant descendre à 1 minute lorsque Claude les définit (1 heure dans les formulaires), et la documentation les recommande « lorsque vous avez besoin d’accéder à des fichiers et à des outils locaux ».¹²

La discipline de cette échelle est la suivante : commencez au niveau le plus bas qui résout votre problème et ne montez que lorsque la vérification de ce niveau a fait ses preuves. Un /goal dont la condition ne peut pas être formulée sous une forme vérifiable n’est pas prêt à devenir une tâche planifiée dans le cloud.

Les surfaces de loop en détail

(Ce guide porte sur les surfaces de loop elles-mêmes. Le guide Claude Code constitue la référence complète de CLI — configuration, autorisations, hooks, MCP — tandis que le guide sur l’architecture des agents explique comment les composants d’un harness s’articulent ; les loops sont ce que vous exécutez par-dessus ces deux couches.)

/goal — le loop évaluateur-optimiseur

/goal <condition> maintient Claude au travail jusqu’à ce que la condition soit remplie : « Après chaque tour, un modèle vérifie si la condition est remplie. S’il juge qu’elle ne l’est pas encore, Claude commence un autre tour au lieu de vous rendre le contrôle. »⁹ En coulisses, « /goal est un wrapper autour d’un Stop hook fondé sur un prompt et limité à la session », si bien qu’il est indisponible partout où les hooks sont désactivés (disableAllHooks, ou allowManagedHooksOnly dans les paramètres gérés). L’évaluateur est le petit modèle rapide que vous avez configuré, et il renvoie l’un des trois verdicts suivants, chacun accompagné d’une courte raison :⁹

Il fonctionne également en mode headless : claude -p "/goal ..." exécute le loop jusqu’à son terme.

Conseils de conception : rendez la condition observable (« les tests réussissent », « l’endpoint renvoie 200 », « aucune erreur TypeScript ») plutôt qu’aspirationnelle (« le code est propre »). Un vérificateur vague ne donne aucune direction au loop — et une transcription formulée avec assurance peut amener une condition évaluée par un modèle à donner son accord. Associez donc /goal à un contrôle automatisé chaque fois qu’il en existe un.¹¹ La documentation énonce clairement cette limite : l’évaluateur « n’exécute pas de commandes et ne lit pas de fichiers de lui-même ; formulez donc la condition comme quelque chose que la propre sortie de Claude peut démontrer ».⁹ Intégrez aussi la règle d’arrêt dans la condition : une clause telle que or stop after 20 turns est évaluée comme le reste, et une condition peut compter jusqu’à 4 000 caractères. Si Claude continue de répondre à l’évaluateur sans utiliser d’outil pendant plusieurs tours consécutifs, Claude Code arrête le loop et vous rend le contrôle, le goal restant défini.⁹

La gestion des échecs, renforcée une première fois dans la v2.1.234,³⁴ couvre désormais toutes les manières dont un tour peut échouer :

Lorsqu’un hôte comme l’application de bureau ou une session cloud gère les identifiants, un échec d’authentification laisse le goal actif, car l’hôte rétablit lui-même l’accès. Et lorsque du travail en arrière-plan fait attendre un goal, Claude vérifie son état au bout de 30 minutes, de nouveau 1 heure plus tard, puis toutes les 2 heures, avec au plus trois vérifications d’inactivité entre deux de vos prompts (CLAUDE_CODE_GOAL_CHECKIN_MINUTES définit le premier intervalle ; 0 désactive les vérifications et les nouvelles tentatives automatiques).⁹

/loop — exécutions locales récurrentes

/loop [interval] <prompt> réexécute un prompt selon une planification : fixe (/loop 5m check the deploy), adaptative (Claude choisit le prochain délai, entre une minute et une heure, selon ce qu’il a observé) ou simplement /loop pour une passe de maintenance intégrée. Le mécanisme repose sur CronCreate/CronList/CronDelete (cron à 5 champs, 50 tâches par session, expiration après 7 jours) et sur l’outil Monitor, qui diffuse la sortie d’un script en arrière-plan au lieu de l’interroger périodiquement.¹² Voici l’exemple de lancement de Cherny : « /loop surveille toutes mes PR. Corrige automatiquement les problèmes de build et, lorsque des commentaires arrivent, utilise un agent dans un worktree pour les traiter. »¹³ Pour remplacer le prompt de maintenance intégré, écrivez un fichier loop.md (.claude/loop.md dans le projet, qui est prioritaire, ou ~/.claude/loop.md) ; « les modifications de loop.md prennent effet à l’itération suivante », et le contenu au-delà de 25 000 octets est tronqué.¹²

La principale limite : /loop vit dans un processus Claude Code en cours d’exécution. « Les tâches ne se déclenchent que lorsque Claude Code est en cours d’exécution et inactif. » Quittez-le et elles cessent de se déclencher ; passez la session en arrière-plan et le loop continue de tourner sans terminal ; reprenez-la avec --resume ou --continue et les tâches planifiées avec CronCreate reviennent, mais pas un /loop à rythme adaptatif, qu’il faut donc relancer.¹² Pour le travail qui doit survivre à la session, la documentation compare trois surfaces :¹²

Le travail qui doit s’exécuter machine éteinte, c’est précisément la raison d’être des tâches planifiées dans le cloud.

Le plugin Ralph — itérer jusqu’à tenir la promesse

Le plugin officiel ralph-loop de Anthropic transforme en produit la méthode de force brute favorite de la communauté. Il s’appelle ralph-loop dans le dépôt anthropics/claude-plugins-official depuis le 6 janvier 2026, date à laquelle Anthropic l’a renommé de ralph-wiggum en ralph-loop « conformément à un avis juridique ». Le 26 octobre 2026, le dépôt claude-code a supprimé sa propre copie obsolète de ralph-wiggum, et sa marketplace installe désormais ralph-loop depuis le dépôt officiel, de sorte que « les identifiants de plugin existants continuent de fonctionner ».¹⁴ Le mécanisme : un Stop hook intercepte la tentative de Claude de terminer la session et réinjecte le prompt, de sorte que le modèle itère en continu au sein d’une même session. /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" le démarre ; /cancel-ralph l’interrompt. Le README indique explicitement que --max-iterations est « votre principal mécanisme de sécurité » — la correspondance exacte de la chaîne de fin peut échouer indéfiniment.¹⁴ Une limite du harness s’applique sous chaque loop fondé sur un Stop hook : « Si le hook bloque huit arrêts d’affilée sans appel d’outil entre eux, Claude Code passe outre le blocage suivant et met fin au tour » (CLAUDE_CODE_STOP_HOOK_BLOCK_CAP relève ce plafond).²⁹ Cela met fin à un loop qui ne progresse plus ; cela n’arrête pas un loop Ralph qui continue d’appeler des outils, si bien que le plafond d’itérations reste indispensable.

Workflows dynamiques — Claude écrit le graph

Introduits avec Claude Code v2.1.154 (mai 2026) et détaillés dans la publication de lancement de Anthropic du 2 juin 2026, les workflows dynamiques représentent le plus grand saut conceptuel : « Claude peut désormais écrire son propre harness à la volée, conçu sur mesure pour la tâche à accomplir. »¹⁵ Vous décrivez la tâche, dites « utilisez un workflow » ou incluez le mot-clé ultracode ; Claude écrit un script d’orchestration JavaScript, dans lequel agent() lance un subagent avec des sorties facultatives conformes au schéma JSON, pipeline() en exécute un par élément d’une liste, parallel() en exécute un ensemble simultanément, et les await, loops et conditions ordinaires assurent le flux de contrôle ; un environnement d’exécution le lance ensuite en arrière-plan. /effort ultracode va plus loin : Claude « planifie un workflow pour chaque tâche substantielle de la session », et une telle session « atteint une limite de session ou hebdomadaire plus tôt que le même travail sans ce mode ».¹⁶ « Un workflow transfère le plan dans le code… Un script de workflow conserve lui-même le loop, les branchements et les résultats intermédiaires, si bien que le contexte de Claude ne contient que la réponse finale. »¹⁶

Limites et structure, selon la documentation :¹⁶

Les scripts enregistrés dans .claude/workflows/ deviennent des commandes slash réutilisables. Une exécution reprend à partir des résultats d’agents enregistrés lorsque Claude la relance, mais un agent en échec « est réexécuté, de même que chaque agent que le script lance après lui, y compris ceux qui avaient terminé », et une exécution que vous passez en arrière-plan ou quittez en cours de route « ne reprend pas d’elle-même ».¹⁶

La topologie caractéristique est dispersion / réfutation / convergence : des agents de recherche indépendants, suivis de vérificateurs contradictoires chargés de réfuter chaque résultat, le tout répété jusqu’à ce que les réponses résistent. Anthropic en livre désormais une instance : le workflow intégré /deep-research « répartit des recherches web sur une question selon plusieurs angles, récupère et recoupe les sources qu’il trouve, vote sur chaque affirmation et renvoie un rapport sourcé dont sont filtrées les affirmations qui n’ont pas résisté au recoupement », et lorsque ses vérificateurs ne peuvent pas contrôler une affirmation, « le rapport la signale comme non vérifiée au lieu de la compter comme réfutée ».¹⁶ Résultat phare présenté lors du lancement : le portage par Bun de sa base de code Zig de 535 496 lignes vers Rust — produisant une base de code Rust dépassant le million de lignes — en onze jours (du 3 au 14 mai 2026) grâce à 64 agents parallèles, selon le récit de Jarred Sumner.¹⁵

Équipes d’agents — le graph pair-à-pair

Derrière CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (fonctionnalité ajoutée en version de recherche préliminaire dans la v2.1.32, février 2026 ; la documentation indique désormais : « Les équipes d’agents sont expérimentales et désactivées par défaut ») : un responsable d’équipe et des coéquipiers qui « travaillent indépendamment, chacun dans sa propre fenêtre de contexte, et communiquent directement entre eux ». On obtient ainsi un graph pair-à-pair plutôt qu’une arborescence de subagents, coordonné par une liste de tâches partagée avec dépendances, verrouillage des fichiers revendiqués et boîtes aux lettres propres à chaque agent. Des quality gates imposés par les hooks placent des contrôles automatisés entre le travail d’un coéquipier et son statut « terminé » : TaskCompleted avec code de sortie 2 bloque l’achèvement, et TeammateIdle avec code de sortie 2 maintient un coéquipier au travail.¹⁷ Deux comportements à connaître avant de l’activer : tant que les équipes d’agents sont activées, « un subagent que Claude nomme est lancé comme coéquipier, si bien que des équipes peuvent se former même si vous n’en avez pas demandé », et « un coéquipier ne peut pas approuver une demande d’autorisation ni donner son consentement à votre place ».¹⁷

Routines — des loops qui survivent à votre ordinateur portable

Une tâche planifiée dans le cloud (anciennement routine) est « une configuration Claude Code enregistrée : un prompt, un ou plusieurs dépôts et un ensemble de connecteurs, regroupés une seule fois puis exécutés automatiquement », qui s’exécute sur l’infrastructure cloud gérée par Anthropic ou dans l’environnement auto-hébergé de votre organisation.¹⁸ L’ancien nom subsiste là où le changer casserait quelque chose : l’adresse web (claude.ai/code/routines), l’alias /routines de /schedule et le chemin d’API /fire. Trois types de déclencheurs, qui peuvent être combinés : une planification (intervalle minimal de 1 heure pour une cadence récurrente, ou une exécution ponctuelle à une heure fixée), déclenchement API (POST .../routines/{id}/fire) et événements GitHub. Création via /schedule, l’application Desktop ou claude.ai/code/routines. La session d’une exécution démarre en mode Auto, sauf si celui-ci est indisponible ; un classificateur autorise ou bloque chaque action, et l’exécution s’interrompt pour attendre dans certains cas, par exemple une action qui demande une autorisation même en mode Auto (une règle ask) ou des blocages répétés. C’est précisément pourquoi la mise en garde de la documentation est essentielle : le résultat d’une exécution indique « comment la session s’est terminée, et non si Claude a accompli le travail décrit dans votre prompt ; ouvrez donc l’exécution et lisez sa transcription pour voir ce qui s’est passé ».¹⁸ Deux correctifs publiés depuis septembre montrent que cet écart est réel : jusqu’à la v2.1.286, les exécutions dont la session cloud n’avait jamais démarré apparaissaient comme Succeeded, et jusqu’à la v2.1.302, des exécutions apparaissaient « comme Completed après l’arrêt inattendu de leur session cloud ».³⁶ La même version a empêché qu’une exécution ayant échoué en cours de route soit relancée depuis le début, « ce qui pouvait répéter du travail, comme publier deux fois le même rapport », une bonne raison de rendre idempotent le travail déclenché.³⁶

Anthropic exécute « chaque jour environ 20 ou 30 de ces routines » dans ses propres bases de code — suppression du code mort, couverture des tests et mise en production d’expériences.³

Les rôles de soutien

Les subagents en arrière-plan (par défaut depuis la v2.1.198) maintiennent le travail délégué hors de votre contexte ; le panneau /agents permet de les surveiller. La messagerie intersessions (v2.1.224) transforme des sessions indépendantes en graph d’échange de messages au moyen de SendMessage, avec un principe de sécurité qui mérite d’être repris : un message provenant d’une autre session « ne vaut jamais consentement de votre part ».¹⁹ Depuis une session connectée à Remote Control, elle atteint aussi vos sessions sur d’autres machines (v2.1.225+) et dans le cloud. Pour les attentes entre loops, le paramètre notify_when_idle (v2.1.236+)³⁶ demande à une session de cette machine d’envoyer une seule notification lorsqu’elle redevient inactive ou se ferme, et Claude Code s’y abonne « sans démarrer de tour ni dépenser de tokens dans la session surveillée ».¹⁹ Les runners auto-hébergés (v2.1.224, Team/Enterprise) exécutent les sessions cloud et les tâches planifiées dans le cloud (anciennement routines) sur vos propres machines, le socle nécessaire aux flottes à l’échelle d’une organisation.²⁰

Le modèle Ralph

La communauté y est arrivée la première. En juillet 2025, Geoffrey Huntley a publié l’essai qui a donné à cette technique le nom du personnage des Simpson : Ralph, c’est littéralement

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

— sa commande sur une ligne, exactement telle qu’elle a été publiée — un dépôt, une tâche par itération, un contexte neuf à chaque passage, avec des fichiers de spécifications et de suivi sur le système de fichiers pour conserver l’état entre les itérations, et des tests et outils de lint jouant le rôle de « contre-pression ».²¹ La forme moderne sans interface repose sur claude -p "$(cat PROMPT.md)" dans une boucle shell, ce qui correspond pour l’essentiel à ce qu’exécutait le propre harness de compilation C de Anthropic.²³ Les résultats qu’il revendique (le MVP d’un contrat de 50 000 $ pour 297 $ de tokens ; six dépôts en une nuit lors d’un hackathon) s’accompagnaient de limites tout aussi claires : uniquement des projets créés de zéro, des implémentations factices ou dupliquées comme modes d’échec récurrents, et « les LLM sont le reflet des compétences de l’opérateur ».

Anthropic n’utilise jamais ce nom dans ses publications d’ingénierie, mais le modèle fait désormais partie de la doctrine officielle à double titre : l’essai de novembre 2025 sur les agents de longue durée prescrit exactement cette organisation — un agent d’initialisation crée des listes de fonctionnalités et des fichiers de suivi, puis de nouveaux agents de développement prennent le relais à chaque fenêtre de contexte et « commencent la session en lisant le fichier de notes de suivi et l’historique des commits git »²² — et le projet de compilateur C de février 2026 a fait travailler seize agents Claude en parallèle — « J’ai construit un harness qui place Claude dans une simple boucle », selon la description de Nicholas Carlini — avec des verrous de tâches fondés sur des fichiers et git comme couche de synchronisation, produisant environ 100 000 lignes de Rust au fil d’environ 2 000 sessions pour quelque 20 000 $.²³ La phrase de l’essai consacrée à la vérification résume toute la théorie du modèle : « le vérificateur de la tâche doit être presque parfait ».

Pourquoi un contexte neuf fait mieux qu’une longue session : l’efficacité diminue à mesure que le contexte d’une session se remplit — les praticiens s’accordent à situer le seuil de dérive autour de 100 000 tokens — et les résumés de compaction sont des reformulations avec perte d’information qui donnent aux erreurs l’apparence d’affirmations assurées.²⁴ La conception de Ralph, qui associe un nouvel agent à chaque itération à des fichiers persistants, contourne ces deux problèmes. (Les boucles au sein d’une même session du plugin officiel sacrifient une partie de ces avantages au profit de la commodité ; pour les exécutions longues, la forme sans interface avec un état externe reste le modèle le plus solide.)

La mésaventure qui sert de mise en garde est tout aussi instructive : un praticien a lancé le plugin avec un prompt vague et max_iterations: 0 — ce qui signifie infini, et non désactivé — et Claude s’est posé la même question de clarification 1 966 fois, tandis que le hook Stop détournait chaque message suivant.²⁵ Les plafonds d’itérations ne sont pas facultatifs.

Quand les boucles deviennent des graphes

Une boucle unique suppose que ses itérations sont indépendantes ou strictement séquentielles. Dès que le travail en parallèle comporte des dépendances — la tâche B a besoin du résultat de A, deux agents modifieraient le même fichier — les boucles sans coordination entrent en conflit, et une structure explicite devient nécessaire : une liste de tâches avec des tableaux de dépendances, un mécanisme de réservation des fichiers, des règles de fusion. Voilà le fond réel du débat entre boucles et graphes : des boucles pour un dépôt et un objectif ; des graphes quand le travail en parallèle exige un ordre d’exécution.²⁶

Les options de graphes, par ordre croissant de besoins en infrastructure :

1. Workflows dynamiques — les dépendances sont exprimées dans le flux de contrôle de JavaScript ; les barrières de synchronisation n’interviennent que lorsqu’une étape a réellement besoin de tous les résultats précédents. Les topologies citées par Anthropic : distribution puis synthèse, vérification contradictoire, génération puis filtrage, tournoi (« Lancez N agents qui tentent chacun la même tâche selon des approches différentes », puis comparez les résultats deux à deux), et boucle jusqu’à achèvement.¹⁵
2. Équipes d’agents — une liste de tâches partagée avec suivi des dépendances ; un coéquipier lancé pendant que le responsable est en mode plan envoie son plan pour approbation, et Claude Code l’approuve automatiquement ; le responsable ne l’examine que si vous basculez en mode plan un coéquipier en cours d’exécution dans le même processus (Shift+Tab) ; le graphe est représenté par des données, pas par du code.¹⁷ Un comportement par défaut a changé dans ce modèle, d’abord dans la v2.1.233 :³⁴ les outils de suivi des tâches (TaskCreate, TaskGet, TaskUpdate, TaskList, TodoWrite) sont désormais « disponibles par défaut uniquement sur Opus 4.7, Sonnet 4.6, Haiku 4.5 et les modèles antérieurs », un ensemble par défaut qui s’applique à partir de la v2.1.268.³⁸ Les agents qui en sont privés « se coordonnent par messages plutôt qu’au moyen de la liste de tâches partagée »,¹⁷ si bien que, sur un modèle actuel dans une session locale ordinaire, la liste de tâches est absente à moins de l’activer ; les sessions en arrière-plan et les sessions cloud disposent des outils sur tous les modèles.³⁸ Activez-les avec CLAUDE_CODE_ENABLE_TODO_TOOLS=1, --allowedTools TaskCreate ou une liste --tools qui les nomme. Une variable exportée n’atteint pas un coéquipier affiché dans un volet séparé ; pour lui donner les outils, lancez le responsable avec claude --settings '{"env":{"CLAUDE_CODE_ENABLE_TODO_TOOLS":"1"}}'.³⁸
3. Orchestrateurs externes — le passage à l’échelle proposé par la communauté : Gas Town de Steve Yegge fait travailler 20 à 30 instances de Claude Code sur des DAG de « beads » gérés dans git (75 000 lignes de Go en 17 jours, mais aussi, de son propre aveu, « un gouffre financier » exigeant un opérateur très compétent) ;²⁷ claude-flow/Ruflo (environ 31 000 étoiles) organise les essaims selon une hiérarchie reine/ouvriers ; les moteurs de type LangGraph ajoutent une machine à états typée, avec Claude Code à l’intérieur des nœuds.

Cherny formalise lui-même cette trajectoire sous la forme de l’échelle des Étapes de l’adoption de l’IA, publiée par l’intermédiaire de Anthropic en juillet 2026 : Accès contrôlé (0 agent) → Assistance (~1) → Parallélisme (~10) → Autonomie supervisée (~100, où « la plupart des agents sont lancés par Claude, pas par des humains ») → Organisation native de l’IA (1 000+). Il l’accompagne de ce conseil : « à chaque étape… vous devez repérer et lever les prochains goulets d’étranglement, puis mettre en place les garde-fous suivants ».²⁸

L’ingénierie de la vérification

Tout ce qui précède relève de la tuyauterie. Cette section, c’est le produit.

L’échelle de progression de Anthropic, tirée de la documentation actuelle sur les bonnes pratiques, part d’un conseil : « Donnez à Claude quelque chose qu’il peut exécuter et qui renvoie un verdict de réussite ou d’échec. Une fois qu’il en dispose, il peut continuer seul sans que vous ayez à le surveiller. » Les échelons vont ensuite de la décision de Claude à l’application par le harness : une ligne de prompt (run the auth tests after, and keep going until they pass) → une condition /goal qu’« un modèle distinct vérifie au regard de la conversation après chaque tour », ce qui « compte pour les longues exécutions en arrière-plan, où Claude termine parfois un tour par un résumé de progression alors que des éléments restent ouverts » → un hook Stop, « appliqué par Claude Code (le harness), de sorte que le tour ne se termine pas tant que la vérification des types n’a pas réussi ou que la limite de blocages n’est pas atteinte » → une revue « par quelqu’un qui n’a pas écrit le code », où /code-review « examine le diff dans un nouveau subagent qui n’a jamais vu votre conversation. Il n’est pas influencé par le raisonnement qui a produit le code ».²⁹ L’exigence de preuve qui l’accompagne : « demandez à Claude des preuves : la commande qu’il a exécutée et sa sortie, ou la capture d’écran », car « pour une session que vous ne surveilliez pas, c’est aussi la seule preuve dont vous disposez ».²⁹ La réfutation contradictoire, l’échelon sur lequel cette échelle se terminait auparavant, figure désormais dans la documentation des workflows, dont l’exemple de prompt demande à un workflow de « vérifier chaque résultat de manière contradictoire avant de le signaler ».¹⁶

La même documentation classe chaque instruction selon qu’elle relève de la décision de Claude ou de l’application par Claude Code. Trois de ses lignes correspondent aux règles d’arrêt, de budget et de fusion d’une boucle :²⁹

Une boucle sans surveillance a besoin d’une entrée de la colonne de droite dans chaque ligne ; la colonne de gauche est tout ce dont dispose une boucle quand personne n’en a écrit. La documentation abandonne aussi une habitude de prompt : des lignes comme « continue, boucle jusqu’à ce que ce soit fini, ne sois pas paresseux » sont « plus susceptibles de provoquer un excès de travail que de débloquer une impasse », et « pour les exécutions que personne ne surveille, /goal ou un hook Stop l’impose ».²⁹

Les trois catégories de retours, tirées de l’essai Agent SDK : les retours fondés sur des règles (« des règles clairement définies pour un résultat, puis une explication des règles non respectées et des raisons de cet échec » — la meilleure forme), les retours visuels (captures d’écran, différences au niveau des pixels), et le LLM comme juge (grilles d’évaluation floues — selon Anthropic, « une méthode généralement peu robuste »).⁷ Privilégiez-les dans cet ordre ; un contrôle déterministe disponible vaut mieux qu’un juge qui donne son avis.

Conditions de convergence. L’analyse critique la plus incisive des boucles — celle de Yoko Li, publiée en août 2026 — ramène la convergence à quatre exigences : un état cible défini, un état actuel observable, des modifications locales précises et des règles d’arrêt extérieures au générateur. Le chiffre à retenir vient de son expérience instrumentée : 67 % des dépenses en tokens de la boucle n’ont produit aucune amélioration, car rien ne lui signalait que les gains suivaient désormais une courbe logarithmique.³⁰ Les plafonds budgétaires ne servent pas seulement à maîtriser les coûts ; ils constituent une règle d’arrêt de dernier recours.

Intégrité des tests. Selon la doctrine de Anthropic sur les agents de longue durée : « Il est inacceptable de supprimer ou de modifier des tests, car cela pourrait conduire à des fonctionnalités manquantes ou défectueuses. »²² Les boucles exploitent les failles des spécifications — elles réussissent les tests visibles sans répondre à l’intention sous-jacente —, il faut donc protéger le vérificateur lui-même de l’agent qu’il évalue.

Évaluez les résultats, pas les chemins empruntés. Selon l’essai sur les évaluations : « Évaluez ce que l’agent a produit, pas le chemin qu’il a emprunté », utilisez des évaluateurs fondés sur du code lorsque les critères sont objectifs et des évaluateurs fondés sur des modèles pour les grilles d’appréciation, puis calibrez-les : « Vous ne saurez pas si vos évaluateurs fonctionnent bien sans lire les transcriptions et les notes de nombreux essais. »³¹

Une autre distinction échappe à la plupart des discussions : lorsque tous les contrôles d’une boucle sont déterministes, aucun modèle n’a sa place dans cette boucle. Un outil de surveillance des dérives qui compare des horodatages, un vérificateur de liens, un outil de surveillance des builds — ce sont des scripts shell exécutés à intervalles réguliers : zéro token, quelques secondes par exécution, une répétabilité parfaite. Réservez les boucles pilotées par un modèle aux itérations qui exigent du jugement. La boucle la moins coûteuse est celle qui n’appelle jamais de modèle.

Maîtriser les coûts et les risques

Le coût est l’objection la plus forte que la communauté oppose à l’ingénierie des boucles, et les retours d’incident lui donnent raison : un bug de création de subagents engloutissant 4 millions de tokens en cinq minutes ; des boucles nocturnes consommant des milliers de dollars ; des limites d’utilisation atteintes « bien plus vite que prévu ».³² L’un de ces obstacles a depuis évolué : à partir de la v2.1.234, une session reprend automatiquement lorsque la limite d’utilisation de claude.ai est réinitialisée (le paramètre autoContinueAtUsageLimit ; désactivation dans /config → « Continue automatically at usage limit »).³⁴³⁷ Le périmètre est étroit. « La reprise automatique est activée par défaut dans les sessions interactives connectées avec un abonnement claude.ai » ; Claude Code ne lance pas l’attente de lui-même pour « une réinitialisation à plus de 24 heures », comme une limite hebdomadaire ; quitter Claude Code met fin à l’attente ; et Claude Code « ne propose pas du tout l’attente » dans les « sessions en arrière-plan et exécutions -p », ce qui couvre Ralph headless et claude -p "/goal ...".³⁷ Dans une session qui remplit ces conditions, les boucles suivent le mouvement : un /goal en pause reprend à la réinitialisation,⁹ et depuis la v2.1.271, une exécution de workflow attend la fin de la limite au lieu de faire échouer ses agents, deux fois au plus par exécution.¹⁶ Une boucle nocturne qui reste dans une session interactive ouverte peut désormais survivre au plafond ; celle qui tourne en headless ou dans une session en arrière-plan s’y arrête toujours. Cela rend les contrôles budgétaires ci-dessous encore plus importants. Voici la discipline qui s’est dégagée, chaque élément correspondant à un contrôle disponible :

Cette dernière ligne mérite son propre paragraphe, car elle explique comment les praticiens qui poussent l’automatisation le plus loin maîtrisent les risques : limitez le périmètre d’impact à la pull request. Les agents permanents de Cherny en arrière-plan — l’un améliore continuellement l’architecture, l’autre traque les abstractions dupliquées — soumettent des PR sans déclenchement humain ;² rien n’est fusionné sans revue. Une boucle permanente dont le pire scénario est « une branche non fusionnée » peut tourner à plein régime ; une boucle qui écrit sur main ne le peut pas. Les tâches planifiées dans le cloud en font le comportement par défaut : « Claude pousse son travail vers une branche préfixée par claude/, sauf si votre prompt lui demande de pousser vers une autre branche », et la protection de branche ou les rulesets GitHub déterminent où une exécution peut pousser.¹⁸ Faites évoluer les boucles progressivement : commencez par l’observation seule (des rapports, aucune écriture), établissez la confiance au fil d’exécutions sans histoire, puis passez aux propositions de modifications — en consignant la preuve de l’ordre d’exécution (« la purge ne s’exécute qu’après que la vérification a renvoyé le nouveau marqueur ») et une déclaration exhaustive du périmètre d’impact avant de mettre en place la planification. L’économie de cette progression est le sujet de Les boucles gagnent là où la vérification coûte peu : c’est le coût de la vérification, et non celui de la construction de la boucle, qui détermine ce qui peut fonctionner sans surveillance.

Aucune entrée de boucle ne vaut consentement. Quatre règles documentées concordent : un message provenant d’une autre session « ne vaut jamais consentement de votre part » ;¹⁹ un coéquipier « ne peut pas approuver une demande d’autorisation ni donner son consentement à votre place » ;¹⁷ le prompt déclenché d’une tâche planifiée dans le cloud « ne peut pas valoir approbation ou consentement pour des actions pendant l’exécution », et le texte envoyé avec un déclenchement API « arrive enveloppé dans un bloc <routine-fire-payload> qui le signale comme donnée non fiable » ;¹⁸ enfin, en mode Auto, le prompt qu’un script de workflow transmet à agent() « ne compte pas comme une demande de votre part », car « Claude Code le marque comme du texte calculé par le script ».¹⁶ Reprenez cette règle dans vos propres boucles : un texte produit par une machine est une donnée, et l’approbation vient d’une personne.

L’objection la plus profonde ne concerne pas le coût, mais la capacité de revue — les boucles produisent du code plus vite que les humains ne peuvent l’examiner sérieusement.³³ Il n’existe pas de réponse astucieuse ; il faut simplement être honnête sur le périmètre : les boucles sans surveillance ont leur place là où la vérification peut être effectuée par une machine, et nulle part ailleurs. Si vous ne pouvez pas le vérifier, ne le livrez pas.

Ce qu’une étude contrôlée révèle sur les composants du harness

La plupart des conseils sur les harness, y compris ceux de ce guide, viennent de praticiens qui modifient un élément à la fois en production. Une étude de septembre 2026 menée par UMass Amherst, Emory, UNC Charlotte et Zoom l’a fait dans un cadre contrôlé : un harness conçu pour l’expérience « dont la boucle d’exécution reste fixe tandis que trois composants varient : la planification, l’espace d’action et la gestion du contexte », testé sur « 176 configurations appariées couvrant cinq stratégies de gestion du contexte, quatre budgets de fenêtre de contexte et des ablations ciblées de la planification et de l’espace d’action » sur SWE-Bench Verified et Terminal-Bench 2.1, avec quatre modèles à poids ouverts, trois tailles de Nemotron-3 et Mistral-Medium-3.5-128B.³⁵ Ses quatre conclusions, selon les auteurs :

• « La gestion du contexte devient de plus en plus utile à mesure que le budget de fenêtre de contexte se resserre, l’essentiel de son bénéfice venant de la prévention des échecs dus au dépassement du contexte. »
• « Faire précéder la synthèse fondée sur LLM d’une suppression fondée sur des règles offre la meilleure efficacité globale parmi les stratégies de gestion du contexte, tandis que rendre le contenu supprimé récupérable ajoute des mécanismes que les modèles utilisent rarement et n’apporte aucun gain de précision. »
• « La planification passe d’un soutien à la précision pour les modèles les moins performants à un moyen de réduire les coûts pour les plus performants, avec peu de changement de précision. »
• « Les outils prédéfinis améliorent les performances des modèles qui maîtrisent moins bien bash, tandis que les modèles compétents en bash peuvent fonctionner efficacement avec une interface limitée à bash et réduire sensiblement les coûts, en particulier pour les tâches centrées sur la ligne de commande. »

À ma lecture, trois de ces conclusions concernent directement l’ingénierie des boucles. La gestion du contexte est une assurance contre les dépassements : une boucle de longue durée devrait prévoir un budget pour sa fenêtre et supprimer les sorties d’outils volumineuses avant de résumer quoi que ce soit, et elle peut se dispenser de mécanismes de récupération que le modèle n’utilisera pas. Pour un modèle performant, la planification est un réglage du coût plutôt qu’un levier de précision, ce qu’il est utile de savoir avant d’ajouter une phase de planification à une boucle qui utilise un tel modèle. Quant au résultat obtenu avec bash seul, il transpose la séparation exécution/modèle au niveau supérieur : lorsque l’acteur est compétent, des actions moins nombreuses et plus larges coûtent moins cher. Les réserves sont celles de l’étude elle-même. Quatre modèles, deux benchmarks et un harness construit pour l’expérience plutôt qu’un agent disponible : les résultats se transposent donc en orientations, pas en paramètres.³⁵

Exploiter une flotte

L’aboutissement de l’ingénierie des boucles n’est pas une boucle unique ; c’est une flotte permanente. Voici à quoi ressemble la pratique lorsqu’elle se stabilise :

• Des spécifications sous forme de fichiers. Chaque boucle est une spécification versionnée — nom, niveau, calendrier, objectif, vérificateur, outils autorisés, budget, délai maximal — conservée dans le dépôt qu’elle sert. Si vous avez saisi trois fois la même vérification manuelle, elle devient une spécification. Anthropic livre une version réduite de cette idée : un fichier loop.md remplace le prompt intégré du /loop sans argument, et ses modifications prennent effet à l’itération suivante.¹²
• Deux niveaux, une promotion qui se mérite. Les boucles d’observation peuvent tout lire, n’écrivent que dans leur propre dossier de rapports et peuvent être planifiées immédiatement. Les boucles d’action modifient l’environnement et exigent une preuve de l’ordre d’exécution, une déclaration du périmètre d’impact et un vérificateur distinct du créateur — le tout consigné avant toute planification. Les boucles commencent par l’observation et doivent mériter leur promotion.
• La séparation exécution/modèle. Les vérifications déterministes s’exécutent sous forme de scripts (zéro token, 1 à 2 secondes) ; les boucles utilisant un modèle sont réservées au jugement. Le contrôle quotidien d’une flotte peut ne rien coûter.
• Des contrats de compte rendu. Une ligne par vérification, PASS|FAIL <check>: <reason>, ajoutée à un fichier de rapport daté. Si vous ne pouvez pas définir une ligne PASS compréhensible d’un coup d’œil, la boucle n’est pas prête. Une boucle de synthèse lit les rapports de la flotte pour que l’humain lise une page, pas trente.
• Des références qui se maintiennent d’elles-mêmes. Les meilleurs dispositifs de surveillance des dérives déduisent leurs attentes de l’artefact qu’ils protègent — les horodatages consignés dans un guide, les empreintes d’un fichier de verrouillage — de sorte que la mise à jour de l’artefact met à jour la surveillance, sans seconde source de vérité à oublier.
• Une planification qui tient dans la durée. Les flottes locales utilisent le planificateur du système d’exploitation (launchd, cron, timers systemd) pour appeler un script d’exécution, ou s’appuient sur les tâches planifiées Desktop lorsque la machine reste allumée ; les flottes cloud prennent la forme de tâches planifiées dans le cloud (anciennement routines). Les boucles liées à une session (/loop) servent au travail auquel vous assistez, ou à une session passée en arrière-plan.¹²

C’est la traduction concrète du « mon travail consiste à écrire des boucles » de Cherny : le travail humain se déplace vers la définition des contrôles, des vérificateurs et des budgets — et la lecture des rapports.

Les deux premières boucles à construire

Si vous démarrez une flotte de zéro, deux boucles se rentabilisent immédiatement — toutes deux éprouvées dans le harness de ce site :

La boucle de validation — un binôme créateur-vérificateur pour tout ce que vous publiez. Un évaluateur neuf (sans mémoire des cycles précédents) note l’artefact selon un seuil explicite ; vous traitez chaque point signalé ; un nouvel évaluateur le note à nouveau ; la boucle s’arrête au seuil ou à un nombre maximal de cycles. Deux observations issues de son utilisation sur une série de quinze articles : les corrections peuvent introduire de nouveaux défauts (une correction a attribué un chiffre à la mauvaise source, ce que l’évaluateur du cycle suivant a détecté), et les évaluateurs se trompent dans les deux sens — l’un a « corrigé » avec assurance une affirmation exacte, de sorte que les corrections précises sont vérifiées à la source avant d’être appliquées. Le vérificateur ne fait pas autorité ; c’est la source qui fait foi.

La boucle d’entretien — le point d’entrée dans le niveau d’action. Une petite correction objectivement vérifiable par exécution, sur une branche, des tests au vert avant l’ouverture de la PR, et aucune fusion par la boucle. Deux règles assurent sa sûreté : tout ce qui est ambigu est signalé, pas corrigé (la première exécution supervisée a correctement refusé de traiter un faux positif du détecteur), et un échec préexistant sur main est signalé comme tel, jamais intégré au diff de la boucle.

Un détail d’exploitation de flotte à reprendre : donnez aux boucles utilisant un modèle sans surveillance un bail de session — différez toute exécution tant qu’une session interactive est active dans le même dépôt. Deux processus qui écrivent dans une même copie de travail finiront par entrelacer leurs commits ; le bail fait céder la place à l’humain par construction.

FAQ

Qu’est-ce que l’ingénierie des boucles ?

C’est la pratique qui consiste à faire répéter des cycles de travail à des agents d’IA jusqu’à ce qu’une condition d’arrêt soit remplie, au lieu de leur donner des prompts tour par tour. Le travail d’ingénierie passe de la rédaction des prompts à la conception de la boucle : sa règle de relance (une condition, un calendrier, un événement), son état entre les itérations, son vérificateur et son budget. Anthropic a nommé cette discipline en juin 2026 ; dans Claude Code, elle se décline à travers /goal, /loop, le plugin Ralph, les tâches planifiées dans le cloud (anciennement routines) et les workflows dynamiques.

Qu’est-ce qu’une boucle Ralph ?

Un schéma d’autonomie par force brute nommé par Geoffrey Huntley en juillet 2025 : exécuter Claude Code dans une boucle shell while, en lui fournissant le même prompt avec un contexte neuf à chaque itération, les fichiers de progression et git conservant l’état entre les passages, tandis que les tests font office de frein. Anthropic propose un plugin officiel ralph-loop (renommé depuis ralph-wiggum en janvier 2026) qui réalise la boucle au sein de la session via un hook Stop, avec --max-iterations comme principal mécanisme de sécurité.

Comment exécuter Claude Code en boucle ?

Choisissez le niveau le plus bas qui convient : /goal <condition> pour itérer jusqu’à ce qu’un évaluateur distinct confirme une condition ; /loop <interval> <prompt> pour des exécutions récurrentes tant qu’une session Claude Code est en cours d’exécution ; /ralph-loop pour itérer sur une tâche jusqu’à l’émission d’une promesse d’achèvement ; /schedule pour créer une tâche planifiée dans le cloud qui s’exécute via cron sans votre machine. Sans interface interactive, claude -p dans une boucle shell avec une vérification externe reste la forme classique.

Les boucles remplacent-elles les prompts ?

Le prompt ne disparaît pas — il change de place. Vous l’écrivez une fois dans la spécification de la boucle, qui le relance ensuite ; de plus en plus souvent (workflows dynamiques, « c’est en fait un autre Claude qui rédige les prompts » selon Cherny), un agent orchestrateur rédige les prompts propres à chaque tâche. Ce qui remplace la rédaction des prompts comme savoir-faire humain, c’est la conception de la vérification : formuler des conditions qu’une machine ou un modèle au contexte neuf peut contrôler.

Quelle est la différence entre une boucle, une routine et un workflow dans Claude Code ?

Une boucle (/loop) relance un prompt selon un calendrier au sein d’une session Claude Code locale et cesse de se déclencher lorsque ce processus se termine ; une session passée en arrière-plan la maintient en marche. Une tâche planifiée dans le cloud (anciennement routine) reprend la même idée pour l’exécuter sur une infrastructure cloud : déclenchée par cron, API ou un événement GitHub, sans ordinateur portable requis. Un workflow est le graphe d’orchestration d’une seule exécution : un script JavaScript écrit par Claude qui crée et coordonne jusqu’à 1 000 subagents, avec des boucles et des branchements inscrits dans le code plutôt que dans le contexte.

Combien coûtent les boucles d’agents ?

La fourchette honnête va de « zéro à ruineux », et la variable déterminante est la conception. Les dispositifs de surveillance déterministes ne coûtent rien — ce sont des scripts planifiés. Les boucles utilisant un modèle sont facturées à l’itération : plafonnez-les (--max-iterations, --max-budget-usd), rendez les gains observables pour que la boucle puisse s’arrêter lorsqu’ils diminuent, et traitez chaque plafond comme une règle d’arrêt, pas comme une gêne. Les retours d’incident — des milliers de dollars en une nuit, 4 millions de tokens en quelques minutes — ont une cause commune : l’absence de condition d’arrêt externe.

Quand une boucle doit-elle devenir un graphe ?

Lorsque des dépendances apparaissent entre des travaux parallèles : une tâche a besoin de la sortie d’une autre, ou deux agents risquent de modifier les mêmes fichiers. Les boucles gèrent un dépôt et un objectif ; les graphes (workflows dynamiques, équipes d’agents, orchestrateurs externes) ajoutent l’ordonnancement des dépendances, la réservation des fichiers et une discipline de fusion. Ne passez aux graphes que lorsque des collisions apparaissent réellement — cette structure supplémentaire a un coût en observabilité et en mise en place.

Historique des modifications