Comment créer des boucles avec Claude Code

La plupart des workflows avec Claude sont encore des actions ponctuelles.

Vous écrivez un prompt. Claude répond. La session se termine. Le lendemain, vous repartez de zéro.

C'est acceptable pour des tâches uniques.

Mais pour un travail répétitif — revues quotidiennes, tri d'intégration continue, surveillance de projet, suivi de réunions — vous reconstruisez le même contexte chaque jour.

Ce n'est pas un workflow. C'est du travail manuel saupoudré d'IA.

La meilleure abstraction est une boucle.

Gardez ça. Vous l'utiliserez.

Ce qu'est réellement une boucle Claude

Une boucle n'est pas "juste redemander à Claude."

Une boucle est une structure de workflow reproductible autour du modèle.

Elle définit :

→ Ce qui déclenche l'exécution

→ Le contexte que Claude lit avant d'agir

→ Ce que Claude est autorisé à faire → Comment la sortie est vérifiée

→ Où l'état est stocké

→ Quand s'arrêter, répéter, ou demander une révision humaine

Le modèle fait toujours le raisonnement.

La boucle fournit la structure opérationnelle.

Ce changement est important car les sessions Claude sont temporaires.

Sans boucle, chaque exécution part de zéro. Avec une boucle, Claude lit ce qui s'est passé avant et continue à partir de là.

Les 6 parties essentielles de toute boucle Claude

Une boucle sans structure n'est qu'un prompt qui s'exécute deux fois.

Voici les 6 parties qui font qu'une boucle fonctionne réellement :

→ 1. Déclencheur

Ce qui lance l'exécution.

Commande manuelle. Minuteur programmé. Changement de fichier. Échec d'intégration continue. Événement Git.

→ 2. Contexte

Ce que Claude lit avant d'agir.

Définition de la tâche. Progrès précédent. Fichiers du projet. Instructions.

→ 3. Action

Ce que Claude fait.

Rédiger un rapport. Ébaucher une correction. Classifier les échecs. Mettre à jour un document.

→ 4. Vérification

Comment vous vérifiez le résultat.

Liste de contrôle. Suite de tests. Sections requises. Vérification des limites de sécurité.

→ 5. Mise à jour de l'état

Ce qui est mémorisé pour la prochaine fois.

PROGRESS.md mis à jour. Bloqueurs enregistrés. Prochaine exécution guidée.

→ 6. Décision

Arrêter. Répéter. Ou escalader vers un humain.

C'est la boucle complète.

Et chaque étape compte.

Sautez la vérification → la boucle se fait aveuglément confiance.

Sautez l'état → chaque exécution part de zéro.

Sautez la décision → la boucle ne sait jamais quand s'arrêter.

Le système à 4 fichiers qui fait fonctionner les boucles

Vous n'avez pas besoin d'infrastructure.

Vous avez besoin de 4 fichiers et d'un dossier.

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — L'objectif. Ce que cette boucle essaie d'accomplir.

LOOP_INSTRUCTIONS.md — La procédure opérationnelle. Comment Claude doit s'exécuter, ce qu'il est autorisé à faire, comment vérifier.

PROGRESS.md — La mémoire. Ce qui s'est passé la dernière fois, ce qui est bloqué, sur quoi la prochaine exécution doit se concentrer.

outputs/ — Là où Claude écrit les résultats. Prévisible. Inspectable. Sûr.

C'est tout.

Claude lit ces fichiers au début de chaque exécution. Les met à jour à la fin. La prochaine exécution continue là où la précédente s'est arrêtée.

C'est ce qui rend les boucles différentes des prompts répétés.

L'état vit en dehors du chat.

TASK.md — Définir l'objectif clairement

Ce fichier indique à Claude à quoi sert la boucle.

Restez à un niveau élevé. Ne mettez pas les détails opérationnels ici. Ceux-ci vont dans LOOP_INSTRUCTIONS.md.

Copiez ce modèle :

1# Boucle de Revue de Projet Quotidienne
2
3## Objectif
4Revoir ce dossier de projet, résumer ce qui a changé,
5identifier les bloqueurs, et produire un court rapport de revue quotidienne.
6
7## Résultat Attendu
8Chaque exécution doit produire ou mettre à jour :
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## Périmètre
13Claude peut inspecter les fichiers dans cet espace de travail et écrire
14des rapports dans le dossier `outputs/`.
15
16Claude NE doit PAS :
17- Modifier les fichiers source
18- Supprimer ou renommer des fichiers
19- Envoyer des messages ou ouvrir des tickets

Remarquez la dernière section.

La première version de toute boucle doit avoir des règles "ne pas faire" explicites.

Ce n'est pas que Claude n'est pas digne de confiance.

C'est vous qui êtes un bon ingénieur.

PROGRESS.md — La mémoire de la boucle

C'est le fichier le plus important du système.

Sans lui, chaque exécution part de zéro. Avec lui, Claude sait ce qui s'est passé et continue à partir de là.

La structure qui fonctionne réellement :

1# Progression de la Boucle
2
3## État Actuel
4- Statut : Actif
5- Objectif principal : Revue de projet quotidienne
6- Focus actuel : [ce qui compte maintenant]
7- Dernière mise à jour : [date]
8
9## Dernière Exécution
10- Date :
11- Résumé :
12- Fichiers examinés :
13- Résultat produit :
14
15## Éléments Ouverts
16-
17
18## Bloqueurs
19-
20
21## Nécessite une Révision Humaine
22-
23
24## La Prochaine Exécution Devrait
25-
26
27## Décisions Prises
28-
29
30## Ne Pas Répéter
31-

La section "Ne Pas Répéter" est cruciale.

Elle empêche Claude de réessayer des choses qui ont déjà échoué.

La section "Nécessite une Révision Humaine" est cruciale.

Elle empêche la boucle de continuer silencieusement quand elle ne le devrait pas.

Deux règles pour garder PROGRESS.md utile :

→ Si Claude en a besoin pour décider de la prochaine action → gardez-le dans PROGRESS.md → Si vous voulez juste un enregistrement → déplacez-le vers outputs/history/

Les fichiers d'état qui grossissent indéfiniment deviennent inutiles.

Gardez PROGRESS.md comme un panneau de contrôle, pas une archive.

LOOP_INSTRUCTIONS.md — La procédure opérationnelle

Ce fichier est la couche de contrôle autour de Claude.

Il indique à Claude exactement quoi lire, quoi écrire, quoi ne pas toucher, et comment vérifier le résultat avant de s'arrêter.

Le modèle qui fonctionne :

1# Instructions de la Boucle
2
3Vous exécutez une boucle de revue de projet quotidienne.
4
5## Avant de Commencer
61. Lisez `TASK.md`
72. Lisez `PROGRESS.md`
83. Inspectez le dossier du projet
94. Identifiez ce qui a changé, ce qui est incomplet, ce qui nécessite une révision humaine
10
11## Ce Que Vous Devez Faire
12Rédigez une courte revue quotidienne dans `outputs/daily-review.md` incluant :
13- Résumé de l'état actuel
14- Fichiers examinés
15- Changements significatifs
16- Bloqueurs ou questions non résolues
17- Actions suivantes recommandées
18
19Après avoir écrit, mettez à jour `PROGRESS.md` avec :
20- Date de cette exécution
21- Résumé de ce qui s'est passé
22- Fichiers vérifiés
23- Ce que la prochaine exécution doit faire
24- Si une révision humaine est nécessaire
25
26## Règles de Sécurité
27- Ne supprimez pas de fichiers
28- Ne renommez pas ou ne déplacez pas de fichiers
29- Ne modifiez pas les fichiers source
30- Écrivez uniquement dans `outputs/daily-review.md` et `PROGRESS.md`
31- En cas de doute sur la permission d'une action → arrêtez-vous et demandez
32
33## Liste de Vérification
34Avant de terminer l'exécution, confirmez :
35- `outputs/daily-review.md` existe avec toutes les sections requises
36- `PROGRESS.md` a été mis à jour
37- Aucun fichier en dehors des chemins autorisés n'a été modifié
38
39## Politique en Cas d'Échec
40Si la vérification échoue :
411. Section manquante dans le rapport → corrigez une fois
422. PROGRESS.md non mis à jour → mettez à jour une fois
433. Fichier interdit modifié → arrêtez immédiatement
444. Même vérification échoue deux fois → marquez comme nécessitant une révision humaine

Remarquez la politique en cas d'échec en bas.

La plupart des boucles n'ont pas de politique en cas d'échec.

Alors quand quelque chose tourne mal, Claude improvise.

C'est là que les boucles créent des problèmes.

Définissez le chemin d'échec explicitement. Toujours.

Exécuter votre première boucle manuellement

Ne planifiez pas encore.

Exécutez d'abord manuellement.

Ouvrez le dossier dans Claude Code ou Claude Desktop/Cowork. Utilisez ce prompt :

1Exécutez la boucle de revue de projet quotidienne pour cet espace de travail.
2
3Suivez `LOOP_INSTRUCTIONS.md` exactement.
4
5Avant d'agir, lisez :
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10Ensuite, inspectez l'espace de travail, rédigez la revue quotidienne dans
11`outputs/daily-review.md`, mettez à jour `PROGRESS.md`,
12exécutez la liste de vérification, et rapportez ce qui a changé.
13
14Ne modifiez aucun fichier sauf
15`outputs/daily-review.md` et `PROGRESS.md`.

Après l'exécution, vérifiez deux choses :

→ outputs/daily-review.md — rapport structuré avec toutes les sections

→ PROGRESS.md — état mis à jour, guide pour la prochaine exécution, indicateurs de révision humaine

Si les deux semblent corrects → la boucle fonctionne.

Maintenant, exécutez-la 3 à 5 fois de plus avec de petits changements.

Ajoutez un fichier de notes. Ajoutez un bloqueur à PROGRESS.md. Changez quelque chose dans l'espace de travail.

Chaque exécution doit prendre en compte les changements sans repartir de zéro.

Cette continuité est tout l'intérêt.

Vérification : la partie que la plupart des gens sautent

Voici le mode d'échec dont personne ne parle.

Claude exécute la boucle. Dit que c'est fini. Met à jour l'état. S'arrête.

Tout semble bien.

Mais le rapport manque de sections requises. Ou PROGRESS.md n'a pas été réellement mis à jour. Ou Claude a discrètement modifié un fichier qu'il n'aurait pas dû.

Vous ne le découvrez que quand quelque chose casse.

C'est pourquoi la vérification existe.

La boucle ne doit pas s'arrêter parce que Claude dit qu'elle est terminée.

Elle s'arrête parce qu'une condition concrète a été vérifiée.

Une bonne vérification ressemble à ceci :

Exécutez un passage de vérification pour la dernière exécution de la boucle.

Vérifiez le résultat par rapport à la Liste de Vérification

dans \LOOP_INSTRUCTIONS.md\.

Rapportez :

1. Quelles vérifications ont réussi
2. Quelles vérifications ont échoué
3. Quels fichiers ont été modifiés
4. Si l'exécution peut être acceptée en toute sécurité
5. Si une révision humaine est requise

Ne modifiez aucun fichier pendant ce passage de vérification.

Exécutez le worker. Puis exécutez le vérificateur. Séparément.

Avec le temps, vous pouvez les fusionner. Mais pendant les premiers tests, gardez-les séparés.

Le vérificateur a besoin d'un standard réussite/échec.

"Révisez ceci et dites-moi si ça a l'air bien" n'est PAS un vérificateur.

"Vérifiez ces 7 conditions et marquez l'exécution comme acceptée seulement si les 7 passent" EST un vérificateur.

Planification avec /loop

La boucle s'exécute de manière fiable manuellement.

Maintenant, planifiez-la.

Dans Claude Code, utilisez /loop :

1/loop 24h Exécutez la boucle de revue de projet quotidienne pour cet espace de travail.
2
3Suivez `LOOP_INSTRUCTIONS.md` exactement.
4Lisez `TASK.md` et `PROGRESS.md` d'abord.
5Rédigez le rapport dans `outputs/daily-review.md`.
6Mettez à jour `PROGRESS.md` avant de vous arrêter.
7Exécutez la liste de vérification.
8S'il n'y a pas de changements significatifs → gardez le rapport court.
9Si une révision humaine est nécessaire → marquez-le clairement dans `PROGRESS.md`.
10Ne modifiez aucun fichier sauf `outputs/daily-review.md`
11et `PROGRESS.md`.

Les options d'intervalle :

→ /loop 15m — Cadence de test (à utiliser en regardant)

→ /loop 1h — Surveillance horaire

→ /loop 24h — Revue quotidienne

→ /loop 7d — Nettoyage ou résumé hebdomadaire

Important : /loop n'est pas magique.

Il répète simplement le prompt.

La qualité de la boucle vient de la structure autour du prompt — les fichiers, les instructions, la vérification, l'état.

/loop fournit seulement le déclencheur.

Sachez aussi à propos de /goal :

/loop = exécutez à nouveau parce que le temps a passé.

/goal = continuez à exécuter jusqu'à ce qu'une condition soit remplie.

1/goal outputs/daily-review.md existe, PROGRESS.md est mis à jour,
2la liste de vérification passe, aucun fichier interdit modifié.

Utilisez /loop pour le travail basé sur le temps (revues quotidiennes, surveillance).

Utilisez /goal pour le travail basé sur l'achèvement (corrigez jusqu'à ce que les tests passent, écrivez jusqu'à ce que toutes les sections soient faites).

L'échelle de permissions

C'est là que la plupart des boucles déraillent.

Les gens construisent une boucle qui fonctionne. Puis lui donnent immédiatement trop de pouvoir.

La boucle poste directement sur Slack. Pousse du code sans révision. Ferme des tickets automatiquement.

Puis quelque chose tourne mal et c'est le chaos.

Utilisez plutôt l'échelle de permissions :

1Niveau 1 — Lecture seule
2Claude lit les fichiers, tickets, journaux, problèmes.
3
4Niveau 2 — Brouillons de sorties
5Claude écrit uniquement dans outputs/.
6Rapports, plans, recommandations.
7Rien d'externe.
8
9Niveau 3 — Modifications en bac à sable
10Claude modifie les fichiers dans un bac à sable contrôlé.
11Branche ou arbre de travail isolé.
12
13Niveau 4 — Brouillons d'actions externes
14Claude prépare une PR, un message Slack, une mise à jour de ticket.
15N'ENVOIE ni ne fusionne.
16
17Niveau 5 — Actions approuvées par un humain
18Claude applique les changements seulement après approbation explicite.
19
20Niveau 6 — Actions automatisées à faible risque
21Claude accomplit des tâches étroitement définies automatiquement.
22Avec journaux, limites et restauration possible.

Votre première boucle devrait vivre au Niveau 1 ou Niveau 2.

Ce n'est pas de la faiblesse. C'est de l'ingénierie.

Les boucles de Niveau 1 et 2 peuvent encore être extrêmement précieuses.

Claude peut inspecter vos problèmes GitHub, lire les échecs d'intégration continue, réviser les documents de spécification de produit, et tout résumer — sans toucher à rien d'important.

Prouvez d'abord que la boucle fonctionne au Niveau 2.

Ensuite, décidez si elle mérite le Niveau 3.

Quand les boucles tournent mal (et comment l'empêcher)

Mauvaise première boucle :

Chaque jour, améliorez la stratégie produit jusqu'à ce qu'elle semble plus solide.

→ Pas de condition d'arrêt → Pas de vérification → Pas d'état → "Semble plus solide" n'est pas un élément de liste de contrôle

Cette boucle soit ne fera rien d'utile, soit changera des choses qu'elle ne devrait pas.

Bonne première boucle :

Chaque vendredi, révisez le document de stratégie produit.

Identifiez les sections qui ont changé cette semaine.

Listez les hypothèses non résolues.

Rédigez une note de révision structurée dans outputs/strategy-review.md.

Ne modifiez pas le document de stratégie directement.

→ Calendrier clair → Périmètre limité → Fichier de sortie prévisible → Limite de permission sûre

La différence n'est pas l'intelligence. C'est la conception.

Les 5 choses qui coulent les boucles :

→ Planification avant les tests manuels

→ Pas de fichier d'état — chaque exécution redémarre de zéro

→ Pas de vérification — la boucle se fait confiance

→ Pas de politique en cas d'échec — les mauvais résultats improvisent

→ Trop d'outils trop tôt — le rayon d'explosion s'agrandit

Corrigez les cinq avant la première commande /loop.

Ajouter des outils et des connecteurs

Une fois que la boucle locale est stable, vous pouvez l'étendre.

GitHub. Slack. Linear. Jira. Journaux d'intégration continue.

Mais chaque nouvel outil agrandit le rayon d'explosion.

Suivez le même principe : lisez d'abord, rédigez en brouillon ensuite, écrivez seulement après des exécutions réussies répétées.

Les règles spécifiques aux outils vont dans LOOP_INSTRUCTIONS.md :

1## Politique de Permissions des Outils
2
3### GitHub
4Autorisé :
5- Lire les problèmes ouverts
6- Lire le statut des pull requests
7- Lire le statut de l'intégration continue
8- Rédiger un résumé dans `outputs/github-review.md`
9NON autorisé :
10- Pousser des commits
11- Fusionner des pull requests
12- Fermer des problèmes
13- Commenter publiquement sans approbation
14
15### Slack
16Autorisé :
17- Rédiger un message dans `outputs/slack-update.md`
18NON autorisé :
19- Envoyer des messages
20- Mentionner des utilisateurs
21- Poster dans des canaux
22
23### Linear/Jira
24Autorisé :
25- Lire les tickets assignés
26- Rédiger des mises à jour suggérées
27NON autorisé :
28- Changer le statut
29- Fermer des tickets
30- Créer des tickets sans approbation

Si l'outil n'est pas listé → arrêtez-vous et demandez une révision humaine.

Cela vous protège de la boucle qui fait des choses auxquelles vous n'aviez pas pensé.

À quoi ressemble votre première boucle complète

Voici la configuration complète à partir de zéro.

1## Politique de Permissions des Outils
2
3### GitHub
4Autorisé :
5- Lire les problèmes ouverts
6- Lire le statut des pull requests
7- Lire le statut de l'intégration continue
8- Rédiger un résumé dans `outputs/github-review.md`
9NON autorisé :
10- Pousser des commits
11- Fusionner des pull requests
12- Fermer des problèmes
13- Commenter publiquement sans approbation
14
15### Slack
16Autorisé :
17- Rédiger un message dans `outputs/slack-update.md`
18NON autorisé :
19- Envoyer des messages
20- Mentionner des utilisateurs
21- Poster dans des canaux
22
23### Linear/Jira
24Autorisé :
25- Lire les tickets assignés
26- Rédiger des mises à jour suggérées
27NON autorisé :
28- Changer le statut
29- Fermer des tickets
30- Créer des tickets sans approbation

Ensuite, remplissez chaque fichier (utilisez les modèles ci-dessus).

Ensuite, exécutez manuellement :

1Exécutez la boucle de revue de projet quotidienne pour cet espace de travail.
2
3Suivez `LOOP_INSTRUCTIONS.md` exactement.
4Avant d'agir, lisez TASK.md, PROGRESS.md,
5et LOOP_INSTRUCTIONS.md.
6Rédigez la revue quotidienne dans `outputs/daily-review.md`.
7Mettez à jour `PROGRESS.md` avant de vous arrêter.
8Exécutez la liste de vérification.
9Ne modifiez aucun fichier sauf
10`outputs/daily-review.md` et `PROGRESS.md`.

Ensuite, vérifiez :

1Exécutez un passage de vérification.
2Vérifiez par rapport à la Liste de Vérification dans
3`LOOP_INSTRUCTIONS.md`.
4Rapportez quelles vérifications ont réussi, lesquelles ont échoué,
5quels fichiers ont été modifiés, si une révision humaine est requise.
6Ne modifiez aucun fichier.

Exécutez 3 à 5 fois manuellement avec de petits changements dans l'espace de travail.

Ensuite, planifiez :

1/loop 24h Exécutez la boucle de revue de projet quotidienne...
2[même prompt que manuel, préfixé par /loop 24h]

Révisez la première semaine de sorties planifiées avant de lui faire confiance.

C'est le système complet.

Le changement qui transforme tout

Avant les boucles :

→ Vous écriviez un prompt

→ Claude répondait

→ Le lendemain, vous écriviez le même prompt

→ Claude n'avait aucun souvenir de la veille

→ Vous suiviez manuellement ce qui avait changé

→ Tout se réinitialisait à chaque session

Après les boucles :

→ TASK.md définit l'objectif une fois

→ PROGRESS.md porte la mémoire entre les exécutions

→ LOOP_INSTRUCTIONS.md contrôle le comportement

→ Claude lit, agit, vérifie, met à jour, s'arrête

→ Le lendemain, il continue là où il s'était arrêté

→ Vous révisez les sorties, pas les prompts

Le goulot d'étranglement passe de la génération du travail à la révision du travail.

C'est là le vrai levier.

Vous ne posez pas de meilleures questions à Claude.

Vous concevez un système qui continue de fonctionner sans vous.

10 boucles que vous pouvez construire cette semaine

→ Revue de projet quotidienne — lit l'espace de travail, écrit un résumé

→ Extracteur de suivi de réunion — transforme les notes en éléments d'action

→ Planificateur de nettoyage de dossier — organise, propose, ne touche pas

→ Tri d'échec d'intégration continue — lit les journaux, classifie les échecs, rédige une investigation

→ Résumeur de problèmes GitHub — lit les problèmes ouverts, regroupe par thème

→ Assistant de révision de PR — lit le diff, signale les problèmes potentiels

→ Boucle de recherche pour newsletter — rassemble les sources, rédige des résumés

→ Chercheur de lacunes dans la documentation — lit la documentation, signale les sections manquantes

→ Rédacteur de daily standup — lit PROGRESS.md, écrit le standup

→ Boucle de rétrospective hebdomadaire — révise la semaine, identifie les schémas

Chacune de ces boucles commence avec le même système à 4 fichiers.

La seule chose qui change est TASK.md et LOOP_INSTRUCTIONS.md.

Si cela a été utile :

→ Repostez pour le partager avec tous les développeurs qui utilisent Claude

→ Suivez @sairahul1 pour plus de systèmes qui fonctionnent sans vous

→ Mettez ceci en favori — les modèles sont prêts à être copiés-collés

Abonnez-vous à theaibuilders.co pour plus d'articles intéressants de ce type

J'écris sur l'IA, la construction de produits et les systèmes d'automatisation.