La commande /loop de Claude Code : comment l'utiliser pour des workflows de développement plus intelligents en 2026

Surya Pratap
By Surya Pratap

3 juillet 2026

8 min read

AI & Technology
Guide de la commande /loop de Claude Code

Si vous avez utilisé Claude Code pendant plus de quelques sessions, vous avez sans doute connu ce moment où vous auriez voulu que l'IA continue tout simplement (surveiller une compilation, guetter un changement, relancer quelque chose toutes les quelques minutes) sans avoir à la surveiller. C'est exactement à cela que sert /loop.

Ce guide explique comment fonctionne /loop, quand il est pertinent de l'utiliser et comment l'intégrer à de vrais workflows de développement : de la surveillance des exécutions de CI aux refactorisations itératives sur une grande base de code.

Qu'est-ce que /loop dans Claude Code ?

/loop est une commande slash intégrée à Claude Code qui demande à l'agent de répéter une tâche selon un rythme défini, ou de cadencer lui-même ses itérations, au lieu de s'arrêter après un tour. Elle est conçue pour les situations où quelque chose doit se produire de façon répétée : vérifier un statut, poursuivre une longue refactorisation, interroger un système externe ou attendre qu'une condition devienne vraie.

Dans sa forme la plus simple, la commande ressemble à ceci :

/loop <interval_in_seconds> <your prompt here>

Par exemple, pour vérifier le statut d'une exécution de CI toutes les 60 secondes :

/loop 60 Check if the GitHub Actions workflow has finished. Report the status and stop looping if it passed or failed.

Claude relancera ce prompt toutes les 60 secondes, avec tous ses outils disponibles (Bash, lecture de fichiers, requêtes web), jusqu'à ce que la condition soit remplie ou que vous l'interrompiez.

Les deux modes : intervalle fixe ou rythme autonome

Il existe deux façons d'utiliser /loop, et comprendre la différence compte pour la manière de formuler vos prompts.

Boucle à intervalle fixe

Passez un nombre de secondes comme premier argument. Claude se réveille à cet intervalle, exécute votre prompt et se rendort. C'est le bon mode pour interroger des systèmes externes (pipelines de CI, statuts de déploiement, endpoints de santé d'une API), où une horloge du monde réel détermine quand les choses changent.

/loop 120 Run npm test and report which tests are failing. Stop if all tests pass.

Boucle à rythme autonome (dynamique)

Omettez l'intervalle et Claude choisit sa propre cadence selon le contexte : le travail restant, la durée de chaque itération et ce qui a du sens pour la tâche. C'est utile pour un travail agentique ouvert où vous voulez que Claude continue sans horloge fixe, par exemple pour refactoriser une liste de fichiers un par un ou traiter un backlog de tickets.

/loop Go through each file in src/components/ and add missing TypeScript types. Work through them one at a time, commit after each file, and stop when all are done.

5 scénarios de développement réels où /loop excelle

1. Surveiller une exécution de CI

Vous poussez une branche et devez savoir quand le pipeline se termine, sans basculer vers GitHub toutes les cinq minutes. Réglez une boucle sur un intervalle raisonnable (les exécutions de CI changent rarement plus vite que toutes les 2–3 minutes) et demandez à Claude de rapporter le résultat puis de s'arrêter automatiquement.

/loop 90 Run: gh run list --branch my-feature --limit 1 --json status,conclusion,url
Report the status. If conclusion is "success" or "failure", report the full result and stop looping.

2. Refactorisation itérative sur une grande base de code

Quand 40 fichiers ont besoin du même traitement (ajouter des types aux props, migrer vers une nouvelle API, renommer une constante), le faire à la main est fastidieux. Avec une boucle à rythme autonome, Claude parcourt la liste dans l'ordre, fait un commit après chaque fichier et rend compte de sa progression pour que vous puissiez reprendre la main en cas de problème.

/loop Find all .tsx files that still use the old useAuth hook from @/hooks/auth-v1.
Migrate them one at a time to the new useSession hook from @/hooks/session.
Run TypeScript after each file to confirm no errors, then commit. Stop when none remain.

3. Surveiller un déploiement

Les déploiements en production peuvent prendre de 5 à 15 minutes et ont la fâcheuse habitude d'échouer de façon évidente si l'on regarde, mais facile à manquer si l'on s'éloigne. Faites tourner Claude en boucle sur votre endpoint de santé ou la CLI de déploiement pendant que vous allez prendre un café.

/loop 60 Run: curl -s https://myapp.example.com/api/health | jq '.status'
If status is "ok", tell me the deploy succeeded and stop.
If you see errors three times in a row, stop and show me the last response.

4. Corriger les tests progressivement

Vous avez une batterie de tests en échec et voulez que Claude les corrige progressivement, un échec à la fois, plutôt que de tout corriger d'un coup en créant un enchevêtrement de modifications contradictoires.

/loop Run the test suite with: npm test -- --bail 1
Pick the first failing test, read the error, fix it, and run again.
Commit after each passing test. Stop when the full suite is green.

5. Attendre un changement dans un fichier ou un journal

Pendant le développement, on veut parfois savoir quand une entrée précise apparaît dans un journal, quand un fichier de données initiales a fini de s'écrire ou quand un artefact de compilation est produit, sans mettre en place un vrai script de surveillance de fichiers.

/loop 30 Check if the file dist/bundle.js exists and is larger than 10kb.
If yes, run a quick size report (ls -lh dist/) and stop looping.
If not, tell me it is not ready yet.

La place de /loop dans un workflow agentique

/loop n'a rien de magique : c'est une couche de planification au-dessus de la même session Claude. Chaque itération a pleinement accès aux fichiers de votre projet, aux commandes bash et aux outils web. L'idée d'architecture essentielle, c'est que Claude hérite aussi du contexte des itérations précédentes au sein de la même boucle : il se souvient de ce qu'il a trouvé la dernière fois, des fichiers déjà traités et de l'état actuel.

Les boucles se combinent ainsi avec d'autres schémas de Claude Code :

  • Avec CLAUDE.md : les règles de votre fichier CLAUDE.md s'appliquent automatiquement à chaque itération de la boucle. Si vous avez défini des conventions de commit ou des restrictions de fichiers, elles sont conservées.
  • Avec les sous-agents : vous pouvez demander à Claude de lancer des sous-agents dans une boucle pour paralléliser le travail, par exemple traiter plusieurs fichiers simultanément à chaque itération.
  • Avec les hooks : les hooks de Claude Code se déclenchent à chaque appel d'outil, si bien que les contrôles de sécurité au niveau des outils s'appliquent dans les boucles comme dans les sessions normales.

Le préchauffage du cache et pourquoi le choix de l'intervalle compte

Une considération de performance pratique change la façon de choisir l'intervalle : le cache de prompts d'Anthropic a un TTL de 5 minutes. Si votre boucle dort plus de 5 minutes (300 secondes), le réveil suivant relit tout le contexte de la conversation sans cache, ce qui est plus lent et consomme plus de tokens.

Un modèle mental utile pour choisir l'intervalle :

  • 60–270 secondes : le cache reste chaud. Idéal pour interroger des exécutions de CI, des endpoints de santé ou tout état externe qui évolue vite.
  • 300+ secondes : défaut de cache à chaque réveil. Ne vaut le coup que si ce que vous attendez met réellement autant de temps à changer. Un déploiement de 12 minutes mérite deux attentes de 270 s, pas 12 interrogations d'une minute.
  • Évitez exactement 300 s : c'est le pire des deux mondes ; vous payez le défaut de cache sans obtenir une attente nettement plus longue.

Quand NE PAS utiliser /loop

/loop est un outil puissant, avec les modes de défaillance des outils puissants. Quelques points de vigilance :

  • Les boucles infinies sans condition de sortie : dites toujours explicitement à Claude quand s'arrêter. « Arrête-toi quand les tests passent » ou « Arrête-toi si tu vois trois échecs d'affilée » ; sans condition, une boucle tournera jusqu'à ce que le contexte de la session soit plein.
  • Les opérations destructrices : les boucles qui modifient des fichiers ou poussent des commits amplifient les erreurs. Demandez d'abord à Claude une simulation, ou limitez le travail à une unité par itération avec un point de confirmation manuel.
  • Le travail en arrière-plan que le harness sait déjà suivre : si vous lancez une tâche en arrière-plan avec l'outil Agent, Claude Code est prévenu automatiquement quand elle se termine ; pas besoin de boucle d'interrogation. N'utilisez /loop que pour les systèmes externes que le harness ne peut pas observer.
  • Les tâches qui demandent votre intervention entre les étapes : si vous devez relire et approuver des modifications avant la prochaine itération, une boucle n'est pas la bonne structure. Utilisez plutôt une conversation normale avec des relances manuelles.

Bien rédiger ses prompts de boucle

La qualité de votre boucle dépend presque entièrement de la précision avec laquelle vous décrivez la condition d'arrêt et l'action de chaque itération. Un prompt de boucle faible produit un agent qui fait quelque chose toutes les N secondes jusqu'à ce que vous l'interrompiez. Un prompt de boucle solide produit un agent qui résout le problème puis s'efface.

Check-list pour les prompts de boucle

  • ✓Une action claire par itération : que doit faire exactement Claude à chaque réveil ?
  • ✓Une condition d'arrêt explicite : quand la boucle doit-elle se terminer ? Nommez l'état ou le résultat, pas un vague « quand c'est fini ».
  • ✓La gestion des échecs : que doit-il se passer en cas de problème ? S'arrêter et rendre compte, ou réessayer jusqu'à N fois ?
  • ✓Des comptes rendus de progression : demandez à Claude de vous dire ce qu'il a trouvé à chaque itération pour pouvoir l'interrompre si quelque chose cloche.
  • ✓Des modifications circonscrites : pour les boucles qui modifient des fichiers, une unité de travail par itération (un fichier, un test, un commit) limite le rayon d'impact.

La vue d'ensemble : des schémas de développement autonome

/loop est une pièce d'un changement plus large dans la façon d'écrire du logiciel en 2026. Le modèle mental passe de « j'écris le code, l'IA m'assiste » à « l'IA travaille, je relis et je pilote ». Les boucles permettent la version à plus long horizon de cette idée : au lieu de guider Claude à chaque étape, vous décrivez le résultat attendu et le laissez itérer vers lui en autonomie.

Cela ne fonctionne en toute sécurité que si vous prévoyez des points de contrôle : des conditions d'arrêt explicites, des commits à chaque itération et des comptes rendus de progression qui vous donnent de la visibilité sans vous obliger à rester derrière. Les fondateurs et développeurs qui tirent le meilleur de l'IA agentique ne sont pas ceux qui donnent les instructions les plus détaillées. Ce sont ceux qui écrivent des conditions de sortie précises et font confiance à l'IA pour remplir le reste.

Le bon usage de /loop n'est pas de tout automatiser. C'est d'automatiser les attentes ennuyeuses et les passes répétitives, pour que votre attention reste sur les parties qui ont vraiment besoin d'un humain dans la boucle.

Pour démarrer vite : essayez /loop 60 Run npm test. Report how many tests pass and fail. Stop when the full suite passes. dans un projet avec un test instable. Regardez Claude le diagnostiquer et le corriger sans que vous ayez à écrire un autre prompt.

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :