Comment faire une loop avec Claude Code
Un prompt te donne une réponse. Une loop te donne un système qui bosse même quand t'as fermé ton laptop. Voilà comment en monter une, pour de vrai.
Par Mario, Fondateur Prompt Academy · 15 min de lecture · Gratuit, sans compte
Tu as appris à prompter. Des prompts précis, structurés, avec du contexte et des exemples — c'est devenu un réflexe. Sauf que le levier vient de bouger sous tes pieds : ce n'est plus le prompt parfait qui fait la différence, c'est le système qui envoie les prompts à ta place. Celui qui relit les résultats, décide de la suite, et recommence — sans toi.
Ce système, ça s'appelle une loop.
Boris Cherny, qui dirige Claude Code chez Anthropic, ne prompte quasiment plus Claude à la main : il écrit des loops qui promptent Claude. Peter Steinberger résume la bascule en une phrase — arrête de prompter tes agents, conçois les loops qui les promptent. Même métier, une couche au-dessus : tu ne tapes plus l'instruction, tu construis la machine qui la tape en boucle.
Une loop, au fond, c'est simple : un objectif récursif. Tu définis un but, l'agent itère dessus, encore et encore, jusqu'à une vraie condition d'arrêt — pas « j'ai l'impression d'avoir fini », mais un signal vérifiable.
Et toute l'architecture tient dans une seule phrase :
L'agent oublie tout entre les runs. La loop, non.
C'est ça que tu vas apprendre à monter : pas un prompt plus malin, mais le système autour de l'agent qui transforme « je lui redemande la même chose chaque matin » en « c'est déjà fait quand j'ouvre mon laptop ».
Ce qu'il te faut avant de commencer
Rien d'exotique. Si tu utilises déjà Claude Code au quotidien, tu as 90 % du matériel :
- Claude Code installé et fonctionnel — tu sais déjà lancer une session.
- Un repo git. Une loop travaille sur du code versionné : c'est ton filet de sécurité quand l'agent part en vrille, et la base des worktrees qu'on verra plus bas.
- Un terminal qui ne te fait pas peur. Tu vas lancer des commandes, lire des logs, éditer deux-trois fichiers de config.
Et deux notions utiles mais pas obligatoires — tu peux les apprendre en chemin :
- cron, le planificateur de tâches Unix/macOS, pour déclencher ta loop à heure fixe.
- les git hooks, pour la déclencher sur un événement (un commit, un push).
Si ces deux derniers mots ne te parlent pas, pas de panique : on ne s'en sert que pour le déclencheur, et je te montre exactement quoi taper.
Le problème que ça règle
Sois honnête : combien de fois par semaine tu rouvres une session pour redemander la même chose ? « Regarde les tests qui ont cassé. » « Reprends là où on en était. » « Refais-moi le tour des erreurs d'hier. » Tu re-poses le contexte, tu re-expliques l'objectif, tu re-lances. À la main. À chaque fois.
C'est du travail répétitif déguisé en travail intellectuel. Et c'est exactement ce qu'une loop fait disparaître : tu définis l'objectif une fois, le système le poursuit tout seul — la nuit, pendant ton déjeuner, pendant que tu fais autre chose. Tu ouvres ton laptop le matin : le boulot est là, ou au moins un rapport clair de là où ça a coincé.
Le terme et le cadre viennent d'Addy Osmani (Google), qui a posé le mot « loop » sur cette pratique et listé ses briques. Les retours de terrain qui nourrissent ce guide viennent de gens qui en montent pour de vrai : Boris Cherny, qui dirige Claude Code chez Anthropic ; Peter Steinberger, qui a fait de la conception de loops son mode de travail principal ; et Geoffrey Huntley, qui a documenté le piège le plus vicieux du genre (on y arrive plus bas). Ce guide traduit leurs idées en quelque chose que tu peux lancer ce soir.
Anatomie d'une loop : les 6 briques
Addy Osmani décompose une loop en six briques. Aucune n'est nouvelle si tu connais déjà Claude Code — la nouveauté, c'est de les assembler en un système qui tourne seul. Voici chacune, traduite en concret :
- Les automatisations — le déclencheur. En pratique : le mode headless
claude -p "..."lancé par un cron (à heure fixe) ou un git hook (sur un commit/push). Ou, à l'intérieur d'une session, les hooks Claude Code (SessionStart,PostToolUse,Stop) qui réagissent à des événements. C'est ce qui fait partir la loop sans que tu cliques. - Les worktrees — l'isolation.
git worktree addte donne plusieurs copies de travail du même repo. Indispensable dès que tu lances plusieurs agents en parallèle : sans ça, ils écrivent dans les mêmes fichiers en même temps et se marchent dessus. - Les skills — la procédure. Un fichier
SKILL.mdest un manuel que l'agent relit quand il en a besoin, au lieu que tu lui ré-expliques la même méthode run après run. Tu écris « comment on fait X » une fois, la loop s'en sert toujours. - Les connecteurs — l'accès au monde extérieur. Ce sont les serveurs MCP : ils branchent l'agent sur tes outils (ta base de données, ton API maison, Notion, GitHub…). Sans connecteurs, ta loop ne voit que le repo.
- Les sous-agents — la division du travail. Des fichiers
.mddans.claude/agents/, chacun avec sa mission et son propre contexte isolé. Un sous-agent peut fouiller un gros dossier pendant que l'agent principal garde son contexte propre. - La mémoire — la colonne vertébrale. Un simple fichier sur disque (
PROGRESS.md,STATE.md) que l'agent lit au début de chaque run et réécrit à la fin. C'est lui qui fait le pont entre deux exécutions. On le détaille tout de suite, parce que c'est la brique que les gens ratent.
La mémoire, en pratique
Souviens-toi de la phrase du début : l'agent oublie tout entre les runs, la loop non. Ce fichier, c'est précisément « la loop ». À chaque réveil, l'agent le lit pour savoir où il en est ; avant de s'arrêter, il le met à jour. Garde-le court et structuré — un état de mission, pas un journal de 2000 lignes que personne (ni toi, ni l'agent) ne relira jamais.
Un PROGRESS.md type tient en quatre sections :
Quatre titres, quelques lignes chacun. L'agent sait en trois secondes ce qui est fait, ce qu'il tient en main, ce qui le bloque, et où aller ensuite. C'est tout ce qu'il faut pour qu'un run reprenne proprement le travail du précédent.
Monte ta première loop
On assemble. Quatre étapes — et la règle d'or : commence petit. Une seule loop, un seul objectif, un seul déclencheur. Tu élargiras quand celle-là tournera proprement.
Résiste à l'envie de tout câbler d'un coup. Une loop = un trigger. Le plus simple pour démarrer : un cron qui lance Claude en mode headless (claude -p). Un objectif concret pour ton premier essai : « chaque matin à 8 h, lis les échecs CI d'hier et les commits récents, écris les findings dans PROGRESS.md ». Diagnostic only, aucune modif — tu veux d'abord voir la loop tourner sans risque.
Pose le PROGRESS.md à la racine du repo, même vide, avec ses quatre titres (Fait / En cours / Bloqué / À tester). C'est le point de rendez-vous entre deux runs : l'agent le lit en arrivant, le réécrit en partant. Sans lui, chaque réveil repart de zéro.
C'est le pattern evaluator-optimizer d'Anthropic. Un sous-agent produit (il code), un autre critique — mais contre un signal objectif : tests, type checker, build, lint. La nuance qui change tout : un simple « review this » sans gate dur, c'est juste un deuxième agent optimiste qui te dit que c'est bien. Le checker doit pouvoir répondre « non » sur la foi d'une commande qui échoue, pas d'une opinion.
Le réflexe naïf, c'est de laisser l'agent décider quand il a fini. Mauvaise idée (on voit pourquoi juste après). À la place : un Stop hook qui lance ton gate objectif et sort en exit code 2 tant qu'il n'est pas vert — ce qui force l'agent à repartir au lieu de s'arrêter. Et un plafond d'itérations (10–20) en garde-fou pour ne jamais boucler à l'infini.
Le déclencheur, concrètement
Une seule ligne de crontab suffit pour l'étape 1 :
La condition d'arrêt, concrètement
Tu câbles un Stop hook dans .claude/settings.json qui appelle un petit script de gate :
L'agent ne s'arrête plus parce qu'il pense avoir fini : il s'arrête quand npm test et le type checker passent. Ce gate, c'est ta définition du « terminé ».
Les pièges à éviter
Une loop qui tourne seule, c'est puissant — et c'est exactement pour ça que ses ratés coûtent cher : personne ne regarde pendant qu'elle se trompe. Trois pièges à connaître avant de lancer.
Le piège le plus vicieux, documenté par Geoffrey Huntley : l'agent émet le signal « c'est fini » trop tôt, et la loop sort sur un job à moitié fait — sans que rien ne l'arrête. Tout tient sur ce point : la condition d'arrêt doit être vérifiable par autre chose que l'agent lui-même. C'est toute la raison du Stop hook de l'étape 4. Un agent qui s'auto-évalue « terminé » est un agent qui se note lui-même. Le gate (npm test, le build, le type checker) ne ment pas.
Le coût en tokens
Une loop consomme, par définition, pendant que tu dors. Le pire scénario, c'est une loop bavarde lancée souvent. Estime-le avant : lance 3 à 5 itérations à la main, regarde ce que ça brûle, puis multiplie par ton plafond d'itérations et par la fréquence du cron. Une loop à 0,50 € le tour qui boucle 15 fois, 4 fois par jour, ce n'est pas 0,50 € — c'est 30 € par jour. Fais le calcul pour ton pire cas, pas pour le cas moyen.
La sécurité
Un agent en loop non surveillée avec un shell illimité, c'est un incident qui attend son heure. Mets une allowlist de commandes : npm, git, ls, cat… et rien d'autre. La logique est simple : sans garde-fou, ton problème de coût se transforme en problème de sécu — une commande mal interprétée qui supprime, pousse ou exfiltre, sans personne pour l'arrêter. Tu autorises explicitement le strict nécessaire ; tout le reste est refusé par défaut.
Pour aller plus loin : l'échelle d'autonomie
Tu n'es pas obligé de lâcher une loop full-autonome dès le premier jour — et tu ne devrais pas. Boris Cherny décrit une échelle d'autonomie en quatre niveaux. L'idée : tu montes d'un cran seulement quand le niveau actuel produit du boulot que tu validerais sans rien changer.
| Niveau | Ce que fait l'agent |
|---|---|
| 1 — Suggère | Il propose, point. Tu lis, tu appliques à la main. Zéro risque. |
| 2 — Drafte | Il prépare le changement (un diff, un brouillon) et attend ta validation avant quoi que ce soit. |
| 3 — Applique le low-risk | Il exécute seul les changements à faible risque, mais demande ton approbation avant tout merge ou publish. |
| 4 — Autonome | Il agit seul, de bout en bout — avec des logs d'audit pour tout retracer après coup. |
La règle d'or : commence TOUTE nouvelle loop au niveau 1 ou 2. Tu observes ce qu'elle produit pendant quelques jours. Le jour où tu te surprends à valider ses sorties sans y toucher une virgule, tu montes d'un cran. Pas avant. L'autonomie, ça ne s'active pas dans un réglage : ça se construit, run après run.