← Toutes les notes
10 min//

Après le prompt, la loop : apprends à écrire la tienne

Boris Cherny, le créateur de Claude Code, ne prompte plus : il écrit des loops. Ce que ça veut dire quand tu n'es pas dev, et trois loops de PM à construire, prompts inclus.

loopsagentsautomatisationclaude-codeveillefeedback

Tu promptes. Tu lis la réponse. Pas tout à fait ça. Tu précises, tu relances. Tu relis. Mieux, mais le ton dérape sur la fin. Tu corriges, tu relances encore. Au troisième tour, c'est bon, tu copies-colles.

Ce cycle, tu le connais par cœur. Regarder où en est le travail, décider quoi demander, lancer le modèle, vérifier le résultat, recommencer ou s'arrêter. C'est une boucle. Et le composant qui la fait tourner, celui qui vérifie et qui décide, c'est toi.

Ce que tu obtiens à la fin de cet article

Une définition claire de la loop sans jargon de dev, le canevas en cinq lignes pour concevoir la tienne, trois loops de PM complètes (veille concurrente, tri du feedback, prep de weekly) avec les briefs à copier, et les trois pièges qui transforment une loop utile en bruit de fond.

C'est quoi une loop ?

Début juin, Boris Cherny, qui a créé Claude Code chez Anthropic, a résumé sa façon de travailler en une phrase :

I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops.

Boris Cherny · créateur de Claude Code, Anthropic · juin 2026

Une loop, c'est un petit programme qui fait tourner le cycle ci-dessus sans toi. La différence avec une automatisation classique type Zapier : Zapier déclenche une action quand X arrive, selon une règle fixe que tu as cliquée. Une loop juge si X compte. La décision à chaque tour vient du modèle, qui applique ton critère écrit en français.

1Observeroù en est le travail, qu'est-ce qui a changé
2Déciderquelle action a du sens dans cet état
3Agirexécuter : chercher, écrire, comparer
4Vérifierle résultat passe-t-il le critère ?
Continuer ou s'arrêter : à chaque tour, c'est le modèle qui tranche. Toi, tu as écrit le critère.

Relis le cycle du premier paragraphe : c'est le même. La seule chose qui change, c'est qui vérifie et qui décide de relancer.

Le déplacement

Dans ton workflow actuel, celui qui vérifie et relance, c'est toi. Dans une loop, c'est le modèle. Ton travail se déplace : tu ne fais plus tourner la boucle, tu la conçois.

Schéma : à gauche, la boucle manuelle (prompter, lire, corriger, relancer) avec toi au centre. À droite, la loop (observer, agir, vérifier, décider) avec le modèle au centre et toi au-dessus, qui écris le critère.
Le même cycle dans les deux cas. Ce qui change : qui est au centre, et qui écrit le critère.
La question que tout le monde se pose Et si je ferme ou éteins mon PC ?
/loop

Elle s'arrête. La loop vit dans ta session de terminal. PC fermé, session fermée, loop terminée. Les tours manqués ne sont pas rattrapés.

tâche planifiée

Elle survit aux redémarrages. Elle se déclenche à l'heure dite si la machine est allumée, avec accès à tes fichiers. Machine éteinte au moment du passage : le tour saute, c'est tout.

/schedule (cloud)

Elle tourne, PC éteint ou pas. Mais elle ne voit pas les fichiers de ta machine : elle travaille sur un repo GitHub. Le détail à l'étape 4 de la Loop 1.

Prompt, agent, loop : les trois crans

Cran 1 Le prompt toi à chaque tour
Tu poses une question, tu reçois une réponse. Tout le reste t'appartient : juger, corriger, relancer, assembler. C'est le chatbot dans un onglet.
+
Cran 2 L'agent toi à la fin
Tu donnes un objectif, il enchaîne les étapes tout seul : il lit tes fichiers, lance ses recherches, produit le livrable. Mais à la fin, il s'arrête et te rend la main. Si le résultat ne va pas, c'est toi qui relances.
+
Cran 3 La loop toi au-dessus
Le même agent, plus une condition. Tant que le texte n'atteint pas le niveau visé, recommence. Toutes les nuits, vérifie. Dès que quelque chose bouge, préviens-moi. Tu n'es plus dans la boucle.

Le cran 2, je l'ai détaillé dans Cinq agents en parallèle. Le reste de ce guide construit le cran 3, sur trois morceaux de ton quotidien de PM. Prérequis : Claude Code installé et un premier run réussi. Si non : Démarrer ici.

L'anatomie : cinq lignes avant tout

Une loop se conçoit en français, dans un fichier, avant de tourner. Cinq éléments, toujours les mêmes :

canevas.md
1Tu es ma loop de [nom].
2État : le fichier qui dit ce que tu sais déjà
3Action : ce que tu observes ou produis à chaque tour
4Critère : ce qui compte comme changement, ou comme "bon"
5Sortie : où tu écris, le format, la longueur max
6Budget : quand tu as le droit de me solliciter

Le canevas tient sur un post-it. Le remplir honnêtement prend une demi-heure, et c'est la vraie difficulté. Le reste est mécanique.

Loop 1 : la veille concurrente, en entier

On construit celle-ci pas à pas. Les deux suivantes iront plus vite.

1. Crée le fichier d'état

Ouvre Claude Code dans ton dossier de travail (celui de Démarrer ici). Tu ne crées rien à la main : demande-lui de créer un dossier veille/ avec ce fichier etat.md dedans, et colle-lui le contenu :

veille/etat.md
1# État de la veille
2Dernier passage : jamais
3
4## Concurrent A
5Pricing : (rien encore)
6Changelog : (rien encore)

Ce fichier est la mémoire de la loop. Sans lui, elle redécouvre les mêmes choses à chaque tour et te les re-signale. L'état, c'est la moitié du travail.

2. Écris le brief

Le brief, c'est ton canevas rempli pour cette loop. Même méthode : demande à Claude de créer veille/brief.md avec ce contenu, en remplaçant les crochets par tes vrais concurrents. Donne les URLs exactes des pages pricing et changelog, et ajoute les trois dans etat.md aussi :

veille/brief.md
1Tu es ma loop de veille concurrente.
2
3État : lis veille/etat.md. Il contient ce que tu as observé
4au dernier tour.
5Action : visite les pages pricing et changelog de
6[Concurrent A], [Concurrent B] et [Concurrent C]. Compare.
7Critère : un changement compte s'il touche le prix, une
8fonctionnalité ou le positionnement. Une reformulation
9marketing ne compte pas.
10Sortie : si changement, une note datée dans veille/notes/,
1110 lignes max, avec le lien et pourquoi c'est notable.
12Mets à jour veille/etat.md. Si rien, juste la date de passage.
13Budget : tu ne me notifies jamais. J'ouvre le dossier
14quand je veux.

Note la ligne surlignée. C'est elle qui sépare une veille utile d'un flux de bruit. Ta connaissance du marché, écrite en une phrase.

3. Teste un tour à la main

Avant de boucler, lance le brief une fois dans Claude Code et regarde ce qu'il produit :

Lis veille/brief.md et fais un tour.
Tour terminé. Un changement retenu : Concurrent B a ajouté un palier Enterprise à sa page pricing. Note écrite dans veille/notes/2026-06-12-concurrent-b-pricing.md. Le changelog de Concurrent A n'a pas bougé. J'ai ignoré la nouvelle baseline de Concurrent C : reformulation marketing, pas de changement de fond.
Tour 1 · manuel · veille/etat.md mis à jour

La note est trop longue ? Le critère laisse passer du bruit ? Ajuste le brief, relance. Deux ou trois tours manuels suffisent pour caler le tir.

4. Mets-la en boucle

Premier réflexe : dans une session Claude Code ouverte, la commande /loop relance le brief à intervalle régulier :

/loop 4h lis veille/brief.md et fais un tour
Loop armée · prochain passage dans 4 heures

Une précision qui évite une mauvaise surprise : la /loop vit dans ta session. Tu fermes ton PC, elle s'arrête, et elle ne rattrape pas les tours manqués. Bien pour tester sur une journée, pas pour du quotidien.

Pour du quotidien, deux options selon ton cas.

Ta machine est allumée à l'heure dite. Demande une tâche planifiée : "tous les matins à 8h, lis veille/brief.md et fais un tour". Elle a accès à tes fichiers et survit aux redémarrages. Sa seule limite : si la machine est éteinte au moment du passage, le tour saute.

Tu veux que ça tourne PC éteint. La commande /schedule crée une routine dans le cloud :

/schedule chaque nuit à 3h, lis veille/brief.md et fais un tour
Routine créée · tourne dans le cloud, sur ton repo GitHub

Le piège à connaître : une routine cloud ne voit pas les fichiers de ta machine. Elle travaille sur un repo GitHub, dont elle prend une copie fraîche à chaque passage, et elle y pousse ses notes. Ton dossier veille/ doit donc être un repo. C'est moins effrayant que ça en a l'air : GitHub expliqué aux utilisateurs d'IA, et Claude fait la mise en place pour toi.

Pour ta première loop, reste simple : la tâche planifiée locale suffit. Une veille concurrente n'a pas besoin de plus d'un passage par jour, et ton PC est rarement éteint à 8h du matin.

5. Surveille la première semaine

Ouvre veille/notes/ chaque matin et lis tout ce qu'elle a écrit pendant une semaine. Pas pour le plaisir : pour vérifier que ton critère tient. C'est maintenant que tu découvres que "changement de positionnement" était trop vague, ou que le concurrent B a un changelog illisible. Tu ajustes le brief, pas le résultat.

Loop 2 : le tri du feedback

Le cas : les retours clients arrivent de partout (exports support, notes de calls) et le tri attend toujours vendredi. La loop le fait au fil de l'eau. Une chose à savoir : c'est toi qui alimentes feedback/inbox/. Glisses-y tes exports et tes notes, n'importe quel format texte, la loop s'occupe du tri.

feedback/brief.md
1Tu es ma loop de tri du feedback.
2
3État : feedback/themes.md liste les thèmes connus,
4avec leurs verbatims.
5Action : lis les nouveaux retours dans feedback/inbox/.
6Range chaque retour sous un thème, avec verbatim et source.
7Critère : un retour sans thème va dans "Candidats".
8À partir de trois retours similaires, c'est un thème émergent.
9Sortie : pour un thème émergent, une ligne datée en haut
10de feedback/alertes.md avec les trois verbatims.
11Budget : une alerte par thème émergent, jamais deux fois le même.

Le point intéressant est dans le critère : la loop ne décide pas de ce qui est important. Elle compte. Trois signaux similaires, c'est un seuil que tu as choisi, et que tu peux régler.

Loop 3 : la prep de ta weekly

Celle-ci ne tourne qu'une fois par semaine, mais elle s'appuie sur les deux autres. C'est là que l'effet cumulé apparaît.

weekly/brief.md
1Tu es ma loop de prep de weekly. Tu tournes le vendredi matin.
2
3Action : compile ce qui a bougé depuis vendredi dernier :
4notes de veille (veille/notes/), alertes feedback
5(feedback/alertes.md), et metrics/ si j'y ai déposé un export.
6Sortie : un draft daté dans weekly/, structure fixe :
73 faits marquants, 1 risque, 1 décision à prendre. 20 lignes max.
8Critère : si un front n'a pas bougé, écris "rien à signaler".
9Ne remplis jamais pour remplir.

Elle se planifie comme la veille : une tâche planifiée le vendredi à 8h, "lis weekly/brief.md et fais un tour". Vendredi 9h, tu ouvres un draft au lieu d'une page blanche. Tu n'envoies pas le draft : tu le corriges, tu tranches la décision, et c'est ta weekly. La loop a fait la collecte, le jugement reste signé de ta main.

Les trois pièges

!
La loop bavarde
Sans budget de parole

Préviens-moi dès que tu vois quelque chose d'intéressant.

Elle trouve toujours quelque chose d'intéressant. Un ping par tour, et au bout de trois jours tu coupes les notifications.

Budget explicite

Si rien ne passe le critère, tu n'écris rien. Trois alertes par jour maximum.

Chez moi, ma loop de veille X a droit à trois messages par jour. Pas un de plus.

!
La loop amnésique
Sans fichier d'état

Regarde les pages pricing des concurrents et dis-moi ce qui est notable.

Chaque tour repart de zéro. Elle te re-signale le même palier Enterprise tous les jours.

Avec mémoire

Lis veille/etat.md, compare avec ce que tu vois, mets-le à jour après chaque tour.

La loop ne signale que ce qui a changé. Si elle radote, le problème est presque toujours là.

!
La loop trop autonome
Action directe

Si le changement est important, envoie un mail à l'équipe.

Un faux positif et toute l'équipe reçoit une alerte fantôme signée de ton nom.

Écriture seulement

Écris une note dans veille/notes/. C'est moi qui décide de ce qui sort.

D'abord des notes que tu lis, ensuite des drafts que tu corriges. Les actions directes, bien plus tard.

Ce qui reste à toi

La partie difficile n'a pas disparu, elle a changé de place. Écrire une loop, c'est écrire la condition d'arrêt. À partir de quand un texte est bon ? Qu'est-ce qui mérite une alerte ? Qu'est-ce qu'un changement significatif chez un concurrent ?

Ces questions, le modèle ne les tranche pas à ta place. Ce sont des questions de jugement, et le jugement, c'est ton métier. La loop exécute ta définition de "bon". Encore faut-il l'avoir écrite.

Commence petit :

  1. Choisir celle des trois qui touche ton irritant de la semaine. Une seule.
  2. Remplir le canevas en cinq lignes, honnêtement. C'est la demi-heure la plus utile.
  3. Tester trois tours à la main, et ajuster le brief à chaque tour.
  4. Boucler seulement ensuite, et tout lire pendant une semaine.

Tu seras la loop une dernière fois : le temps de la concevoir.

Si cet article t'a fait gagner du temps,

il en fera gagner à quelqu'un dans ton réseau.

PartagerLinkedIn

Newsletter · L’AI.ssentiel

Chaque vendredi,un signal IA qui compte.

Un outil à tester, un workflow à copier, une lecture qui remue. Pas de spam, désinscription en un clic.

↳ Reçois la prochaine édition

Hebdomadaire · sans engagement