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

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), /loop (exécutions locales récurrentes), le plugin Ralph officiel (itération jusqu’à ce qu’une promesse soit tenue), les 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.234 (août 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 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.¹¹)

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 routine.

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 petit modèle rapide vérifie si la condition est remplie. Dans le cas contraire, Claude commence un autre tour au lieu de vous rendre le contrôle. »⁹ L’évaluateur (Haiku par défaut) répond par oui ou non et fournit une raison que Claude utilise comme instruction pour le tour suivant. 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.¹¹

Deux changements de la v2.1.234 renforcent le loop lui-même. Désormais, un goal s’efface en affichant une notification lorsqu’un tour échoue à cause d’une erreur irrécupérable — authentification révoquée, solde de crédits épuisé ou dépassement de la fenêtre de contexte — au lieu de rester actif dans une session qui ne peut plus agir. De plus, lorsque des tâches en arrière-plan maintiennent un goal en attente pendant 30 minutes ou plus, Claude vérifie leur état au lieu d’attendre indéfiniment (CLAUDE_CODE_GOAL_CHECKIN_MINUTES permet d’ajuster le seuil ; 0 rétablit l’ancien comportement d’attente illimitée).³³

/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 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. »¹³

La principale limite : /loop vit dans votre session. Fermez le terminal et le loop s’arrête — c’est précisément la raison d’être des routines.

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

Le plugin officiel ralph-wiggum de Anthropic transforme en produit la méthode de force brute favorite de la communauté : 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.¹⁴

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 (ou dites simplement « utilisez un workflow ») ; Claude écrit un script d’orchestration JavaScript — agent() lance un subagent avec des sorties facultatives conformes au schéma JSON, pipeline() fait passer les éléments par différentes étapes, tandis que les await, loops et conditions ordinaires assurent le flux de contrôle — puis un environnement d’exécution le lance en arrière-plan. « 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 : 16 agents simultanés, 1 000 par exécution (« pour éviter les loops incontrôlés »), aucune intervention de l’utilisateur en cours d’exécution ; les scripts enregistrés dans .claude/workflows/ deviennent des commandes slash réutilisables ; les exécutions peuvent être reprises grâce à la mise en cache des résultats des agents.¹⁶ 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. 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 (version de recherche préliminaire depuis la v2.1.32, février 2026) : 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 » — 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 (TaskCompleted avec code de sortie 2 pour bloquer) placent des contrôles automatisés entre le travail d’un coéquipier et son statut « terminé ».¹⁷

Routines — des loops qui survivent à votre ordinateur portable

Une 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 » dans le cloud géré par Anthropic ou sur vos propres runners auto-hébergés.¹⁸ Trois types de déclencheurs, qui peuvent être combinés : planification cron (intervalle minimal de 1 heure), déclenchement API (POST .../routines/{id}/fire) et événements GitHub. Création via /schedule ou claude.ai/code/routines. Les exécutions sont autonomes — sans demande d’autorisation — ce qui explique pourquoi la mise en garde de la documentation est essentielle : un statut d’exécution vert « ne signifie pas que la tâche de votre prompt a réussi. Ouvrez l’exécution pour lire la transcription et confirmer ce que Claude a réellement fait. »¹⁸

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 ».¹⁹ Les runners auto-hébergés (v2.1.224, Team/Enterprise) exécutent les sessions cloud et les routines sur vos propres machines — le socle nécessaire aux flottes à l’échelle d’une organisation.²⁰

Le Ralph Pattern

La communauté avait déjà ouvert la voie. En juillet 2025, Geoffrey Huntley a publié l’essai qui a donné à la technique le nom du personnage des Simpson : Ralph consiste littéralement à

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

— sa formule en 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 progression sur le système de fichiers pour conserver l’état entre les itérations, tandis que les tests et les lints servent de « backpressure ».²¹ La forme headless moderne de cette même structure est claude -p "$(cat PROMPT.md)" dans une boucle shell, ce qui correspond essentiellement au fonctionnement du harness de compilateur C de Anthropic.²³ Les résultats qu’il revendique (le MVP d’un contrat à 50 000 $ pour 297 $ de tokens ; six dépôts produits en une nuit lors d’un hackathon) s’accompagnaient de limites tout aussi claires : uniquement pour les projets greenfield, des implémentations factices ou dupliquées comme modes d’échec récurrents, et « les LLMs reflètent les compétences de l’opérateur ».

Anthropic n’emploie jamais ce nom dans sa documentation technique, mais le pattern fait désormais partie de la doctrine officielle à deux titres : l’essai de novembre 2025 sur les agents de longue durée prescrit exactement cette structure — un agent d’initialisation créant des listes de fonctionnalités et des fichiers de progression, puis de nouveaux agents de programmation pour chaque fenêtre de contexte, qui « commencent la session en lisant le fichier de notes de progression et les journaux de commits git »²² — tandis que 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 boucle simple », comme l’explique Nicholas Carlini — avec des verrous de tâches basés sur des fichiers et git comme couche de synchronisation, produisant environ 100 000 lignes de Rust au fil de quelque 2 000 sessions, pour un coût d’environ 20 000 $.²³ La phrase de l’essai consacrée à la vérification résume toute la théorie du pattern : « il est essentiel que le vérificateur de tâches soit presque parfait ».

Pourquoi un contexte neuf surpasse une longue session : l’efficacité diminue à mesure que le contexte d’une session se remplit — le consensus des praticiens situe le seuil de dérive autour de 100 000 tokens — et les résumés de compaction sont des paraphrases avec perte qui transforment les erreurs en affirmations assurées.²⁴ La conception de Ralph, fondée sur de nouvelles instances et des fichiers, contourne ces deux problèmes. (Les boucles au sein d’une même session du plugin officiel sacrifient en partie cet avantage au profit de la commodité ; pour les longues exécutions, la forme headless avec état externe reste le pattern le plus robuste.)

La mise en garde associée au pattern est elle aussi instructive : un praticien a exécuté le plugin avec une invite vague et max_iterations: 0 — ce qui signifie infini, et non désactivé — et Claude s’est posé 1 966 fois la même question de clarification, le hook Stop détournant ensuite chaque message.²⁵ Les limites d’itérations ne sont pas facultatives.

Quand les boucles deviennent des graphes

Une boucle unique suppose que ses itérations sont indépendantes ou strictement séquentielles. Dès que des travaux parallèles présentent des dépendances — la tâche B nécessite le résultat de A, deux agents modifieraient le même fichier — les boucles libres entrent en collision et une structure explicite devient nécessaire : une liste de tâches avec des tableaux de dépendances, l’attribution des fichiers et une discipline de fusion. Voilà le véritable enjeu du débat entre boucles et graphes : des boucles pour un dépôt et un objectif ; des graphes lorsque les travaux parallèles doivent être ordonnés.²⁶

Les options de graphes, par ordre croissant d’infrastructure :

1. Workflows dynamiques — les dépendances sont exprimées dans le flux de contrôle de JavaScript ; les barrières n’existent que lorsqu’une étape a réellement besoin de tous les résultats précédents. Les topologies nommées par Anthropic : distribution et synthèse, vérification contradictoire, génération et filtrage, tournoi (« Lancez N agents qui tentent chacun la même tâche selon des approches différentes », puis comparez-les deux à deux) et boucle jusqu’à l’achèvement.¹⁵
2. Équipes d’agents — une liste de tâches partagée avec suivi des dépendances et un responsable qui approuve les plans ; le graphe est constitué de données, pas de code.¹⁷ Un comportement par défaut a changé pour ce pattern : depuis la version v2.1.233, les outils de tâches (TaskCreate/Get/Update/List, TodoWrite) sont désactivés par défaut sur Opus 4.8, Sonnet 5, Fable 5 et les versions ultérieures — la documentation indique explicitement que les agents dépourvus des outils Task « se coordonnent par messages plutôt que par la liste de tâches partagée ». Ainsi, avec une configuration par défaut de génération actuelle, cette liste n’existe tout simplement pas. Définissez CLAUDE_CODE_ENABLE_TODO_TOOLS=1 pour la rétablir.³³
3. Orchestrateurs externes — le passage à l’échelle porté par la communauté : Gas Town de Steve Yegge exécute 20 à 30 instances de Claude Code sur des DAG de « beads » adossés à git (75 000 lignes de Go en 17 jours ; selon ses propres mots, c’est aussi « un gouffre financier » qui exige de solides compétences de la part de l’opérateur) ;²⁷ claude-flow/Ruflo (environ 31 000 stars) organise les essaims selon une hiérarchie reine/ouvriers ; les moteurs de type LangGraph ajoutent par-dessus une machine à états typée, avec Claude Code dans les nœuds.

La formalisation de cette trajectoire par Cherny est l’échelle Steps of AI Adoption, publiée par Anthropic en juillet 2026 : Gated (0 agent) → Assisted (environ 1) → Parallel (environ 10) → Supervised autonomy (environ 100, où « la plupart des agents sont lancés par Claude, et non par des humains ») → AI-native (1 000+). Le conseil qui l’accompagne : « à chaque étape… vous devez identifier et éliminer la prochaine série de goulots d’étranglement, puis mettre en place la prochaine série de garde-fous ».²⁸

Ingénierie de la vérification

Tout ce qui précède relève de la plomberie. Cette section traite du produit.

L’échelle de progression de Anthropic, tirée du document actuel sur les bonnes pratiques : donnez à Claude quelque chose qui produit une réussite ou un échec, et « la boucle se referme d’elle-même » → une condition /goal revérifiée par un évaluateur distinct → un hook Stop comme « porte déterministe » → « un subagent de vérification ou un workflow dynamique qui vérifie ses propres conclusions demande à un nouveau modèle d’essayer de réfuter le résultat, afin que l’agent chargé du travail ne soit pas celui qui le note ».²⁹ La norme de preuve qui l’accompagne : « Demandez à Claude de présenter des preuves plutôt que d’affirmer sa réussite. »

Les trois catégories de feedback, tirées de l’essai sur Agent SDK : le feedback fondé sur des règles (« des règles clairement définies pour un résultat, suivies d’une explication indiquant lesquelles ont échoué et pourquoi » — la meilleure forme), le feedback visuel (captures d’écran, différences entre pixels) et LLM-as-judge (critères flous — selon les mots de Anthropic, « ce n’est généralement pas une méthode très robuste »).⁷ Privilégiez-les dans cet ordre ; un contrôle déterministe existant 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. Son expérience instrumentée fournit le chiffre à retenir : 67 % des tokens consommés par la boucle n’ont produit aucune amélioration, car rien ne lui indiquait que les rendements étaient devenus logarithmiques.³⁰ 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. D’après la doctrine de Anthropic sur les agents de longue durée : « Il est inacceptable de supprimer ou de modifier des tests, car cela pourrait masquer des fonctionnalités manquantes ou défectueuses. »²² Les boucles exploitent les spécifications — elles réussissent les tests visibles tout en trahissant l’intention cachée — le vérificateur doit donc lui-même être protégé de l’agent qu’il évalue.

Évaluez les résultats, pas les chemins suivis. D’après l’essai sur les évaluations : « Évaluez ce que l’agent a produit, et non le chemin qu’il a suivi », utilisez des évaluateurs fondés sur le code pour les critères objectifs et des évaluateurs fondés sur des modèles pour les grilles d’évaluation, puis calibrez : « Vous ne saurez pas si vos évaluateurs fonctionnent correctement tant que vous n’aurez pas lu 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 de dérive qui compare des horodatages, un vérificateur de liens, une sentinelle de build : ce sont des scripts shell exécutés selon un calendrier, sans aucun token, en quelques secondes et de manière parfaitement reproductible. Réservez les boucles pilotées par des modèles aux itérations qui nécessitent du jugement. La boucle la moins chère est celle qui n’appelle jamais de modèle.

Discipline en matière de coûts et de sécurité

La principale objection de la communauté à l’ingénierie des boucles concerne les coûts, et les post-mortems la confirment : un bug de lancement de subagents consommant 4 millions de tokens en cinq minutes ; des boucles nocturnes coûtant des milliers de dollars ; des limites d’utilisation atteintes « bien plus vite que prévu ».³² L’une de ces limites a depuis été déplacée : depuis la version v2.1.234, une session reprend automatiquement lorsqu’une limite d’utilisation de claude.ai est réinitialisée (désactivez cette option dans /config → « Continue automatically at usage limit ») — une boucle nocturne qui s’arrêtait auparavant à la limite reprend désormais lorsque la fenêtre se rouvre, ce qui renforce l’importance des contrôles budgétaires ci-dessous au lieu de la réduire.³³ La discipline qui en a découlé, chaque élément correspondant à un contrôle livré :

Cette dernière ligne mérite son propre paragraphe, car elle explique comment les praticiens les plus audacieux préservent la sécurité : faites de la pull request le rayon d’impact. Les agents permanents en arrière-plan de Cherny — l’un améliorant continuellement l’architecture, l’autre recherchant les abstractions dupliquées — soumettent des PR sans intervention humaine ;² rien n’est fusionné sans examen. Une boucle permanente dont le pire scénario est « une branche non fusionnée » peut fonctionner à plein régime ; une boucle qui écrit sur main ne le peut pas. Déployez les boucles progressivement : commencez en mode observation uniquement (rapports, aucune écriture), gagnez la confiance au fil d’exécutions sans incident, puis passez à la proposition de modifications — avec la preuve de l’ordre d’exécution (« la purge ne s’exécute qu’après le retour du nouveau marqueur par la vérification ») et une déclaration exhaustive du rayon d’impact consignées avant l’installation de la planification. L’économie de cette progression est le sujet de Les boucles gagnent lorsque la vérification est peu coûteuse : 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 supervision.

L’objection la plus profonde ne concerne pas les coûts, mais la capacité de revue — les boucles produisent du code plus vite que les humains ne peuvent l’examiner sérieusement.³⁴ Il n’existe aucune réponse astucieuse ; seule compte une délimitation honnête du périmètre : les boucles sans supervision ont leur place uniquement 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. »²⁹

Exécuter une flotte

L’aboutissement de la loop engineering n’est pas une boucle unique, mais une flotte permanente. Voici à quoi ressemble cette pratique une fois stabilisée :

• 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 d’expiration — qui réside dans le dépôt qu’elle sert. Si vous avez effectué trois fois la même vérification manuelle, elle devient une spécification.
• Deux niveaux, avec une promotion à mériter. Les boucles Observe peuvent tout lire, écrivent uniquement dans leur propre répertoire de rapports et peuvent être planifiées immédiatement. Les boucles Act agissent sur le monde réel et nécessitent la preuve d’ordonnancement, la déclaration du périmètre d’impact et un vérificateur distinct du créateur — le tout consigné avant même la création du calendrier. Les boucles commencent au niveau observe et doivent mériter leur promotion.
• La séparation exec/modèle. Les vérifications déterministes s’exécutent sous forme de scripts (zéro token, 1 à 2 secondes) ; les boucles de modèles sont réservées aux tâches qui exigent du discernement. Le battement quotidien d’une flotte peut ne rien coûter.
• Des contrats de rapport. 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 afin que l’humain consulte une seule page, pas trente.
• Des références qui se maintiennent elles-mêmes. Les meilleurs observateurs de dérive déduisent les attentes de l’artefact qu’ils surveillent — les horodatages consignés dans un guide, les hachages propres à un lockfile — de sorte que la mise à jour de l’artefact actualise également l’observateur, sans créer une seconde source de vérité susceptible d’être oubliée.
• Une planification qui perdure. Les flottes locales s’appuient sur le planificateur du système d’exploitation (launchd, cron, temporisateurs systemd) pour invoquer un script d’exécution ; les flottes cloud reposent sur des routines. Les boucles liées à une session (/loop) sont destinées aux tâches auxquelles vous assistez.

C’est l’idée de Cherny, « mon travail consiste à écrire des boucles », rendue concrète : le travail humain se déplace vers la définition des vérifications, des vérificateurs et des budgets — ainsi que vers la lecture des rapports.

Les deux premières boucles à créer

Si vous partez de zéro pour constituer une flotte, deux boucles sont immédiatement rentables — toutes deux ont fait leurs preuves dans le harness de ce site :

La boucle de contrôle — le principe créateur-vérificateur appliqué à tout ce que vous publiez. Un nouvel évaluateur (sans mémoire des cycles précédents) note l’artefact selon un seuil explicite ; vous corrigez chaque problème signalé ; un nouvel évaluateur attribue une nouvelle note ; la boucle s’arrête lorsque le seuil est atteint ou après un nombre maximal strict de cycles. Deux enseignements tirés d’un sprint de quinze articles : les corrections peuvent introduire de nouveaux défauts (la modification d’un cycle 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 d’eux a « corrigé » avec assurance une affirmation pourtant exacte. Les corrections précises sont donc vérifiées à la source avant d’être appliquées. Le vérificateur ne fait pas autorité ; la source, si.

Le groundskeeper — le point d’entrée du niveau act. Une seule petite correction objectivement vérifiable par exécution, effectuée sur une branche, avec des tests au vert avant l’ouverture de la PR, et la boucle ne fusionne jamais les modifications. Deux règles assurent sa sécurité : tout élément ambigu est signalé, pas corrigé (la première exécution supervisée a refusé à juste titre d’intervenir sur un faux positif du détecteur), et tout échec préexistant sur main est indiqué comme tel, sans jamais être intégré au diff de la boucle.

Un détail d’exploitation des flottes mérite d’être repris : attribuez aux boucles de modèles sans surveillance un bail de session — reportez toute exécution lorsqu’une session interactive est active dans le même dépôt. Deux processus d’écriture partageant un même checkout finiront par entremêler leurs commits ; par conception, le bail oblige la boucle à céder la priorité à l’humain.

FAQ

Qu’est-ce que la loop engineering ?

Il s’agit de faire répéter aux agents IA des cycles de travail jusqu’à ce qu’une condition d’arrêt soit satisfaite, au lieu de les guider tour après tour avec des prompts. Le rôle de l’ingénieur ne consiste plus à rédiger des prompts, mais à concevoir la boucle : sa règle de redéclenchement (une condition, un calendrier, un événement), son état entre les itérations, son vérificateur et son budget. Anthropic a donné un nom à cette discipline en juin 2026 ; ses interfaces Claude Code sont /goal, /loop, le plugin Ralph, les routines et les workflows dynamiques.

Qu’est-ce qu’une boucle Ralph ?

Un modèle d’autonomie par force brute nommé par Geoffrey Huntley en juillet 2025 : exécuter Claude Code dans une boucle shell while, en lui transmettant le même prompt avec un contexte neuf à chaque itération, tandis que des fichiers de progression et git conservent l’état entre les passages et que les tests exercent une contre-pression. Anthropic fournit un plugin officiel ralph-wiggum qui exécute la boucle dans la session au moyen d’un Stop hook, avec --max-iterations comme principal mécanisme de sécurité.

Comment exécuter Claude Code dans une 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 que votre session reste ouverte ; /ralph-loop pour itérer sur une tâche jusqu’à une promesse d’achèvement ; /schedule pour créer une routine cloud qui s’exécute via cron sans dépendre de votre machine. En mode headless, la forme classique consiste à placer claude -p dans une boucle shell assortie d’une vérification externe.

Les boucles remplacent-elles les prompts ?

Le prompt ne disparaît pas — il se déplace. Vous l’écrivez une seule fois dans la spécification de la boucle, qui le redéclenche ; de plus en plus souvent (workflows dynamiques, formule de Cherny selon laquelle « c’est en réalité un autre Claude qui se charge des prompts »), un agent orchestrateur rédige les prompts propres à chaque tâche. Dans le savoir-faire humain, la conception de la vérification remplace le travail d’élaboration des prompts : il s’agit d’énoncer des conditions qu’une machine ou un nouveau modèle peut contrôler.

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

Une boucle (/loop) réexécute un prompt selon un calendrier au sein de votre session locale et s’arrête avec elle. Une routine reprend la même idée sous une forme conçue pour s’exécuter sur une infrastructure cloud — déclenchée par cron, API ou un événement GitHub, sans nécessiter d’ordinateur portable. Un workflow est le graphe d’orchestration d’une exécution unique : un script JavaScript écrit par Claude, qui lance et coordonne jusqu’à 1 000 subagents, les boucles et les branchements étant conservés dans le code plutôt que dans le contexte.

Combien coûtent les boucles d’agents ?

En toute honnêteté, la fourchette va de « rien » à « ruineux », selon la conception. Les observateurs déterministes ne coûtent rien — ce sont des scripts planifiés. Les boucles de modèles sont facturées à l’itération : plafonnez-les (--max-iterations, --max-budget-usd), rendez les résultats observables afin que la boucle puisse s’arrêter lorsque les rendements diminuent, et considérez chaque plafond comme une règle d’arrêt, pas comme une gêne. Les analyses post-mortem des échecs — des milliers de dollars dépensés en une nuit, 4 millions de tokens en quelques minutes — ont toutes la même cause profonde : l’absence de condition d’arrêt externe.

Quand une boucle doit-elle devenir un graphe ?

Lorsque des dépendances apparaissent dans le travail parallèle : une tâche a besoin du résultat d’une autre, ou deux agents modifieraient 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 se produisent réellement — cette structure supplémentaire nuit à l’observabilité et demande davantage de configuration.

Journal des modifications