Ingénierie de boucles (Loop Engineering) - Du prompting à l'automatisation

J'ai décidé de consacrer cet article à la création de votre propre agent programmable qui fera le travail à votre place, pour que vous n'ayez plus à allumer votre ordinateur chaque matin et à lui donner des commandes encore et encore.

Il se réveillera tout seul, trouvera des tâches tout seul, identifiera des problèmes tout seul, et sauvegardera et présentera les résultats sur votre bureau pour que vous puissiez les examiner.

Préface

L'idée de Loop n'est pas sortie de nulle part - au cours d'une seule semaine de juin 2026, trois experts du secteur ont presque simultanément exprimé la même pensée : il était temps de commencer à développer ce niveau.

Une semaine plus tard, Andrew Ng a placé cette conversation dans le contexte plus large de "Building Products from 0 to 1", offrant une image plus complète.

Cet article part de cette histoire, puis vous guide dans la construction d'une boucle minimale mais complète à partir de zéro : 5 mouvements, 6 parties, une porte qui dit "non", et une porte humaine - le tout fonctionnant sur votre propre machine, et réutilisable sur n'importe quel projet logiciel.

Source : HuaShu Orange Book, Loop Engineering: Stop Asking Me What It Is (v260615, juin 2026)

La semaine où 3 personnes ont allumé la mèche

Juin 2026 : trois personnes, sans aucune coordination, ont dit presque la même chose à quelques jours d'intervalle.

Peter Steinberger, créateur d'OpenClaw, a posté deux phrases sur X qui ont atteint 8,9 millions de vues :

https://x.com/steipete/status/2063697162748260627

Ce post est l'endroit où le discours a réellement commencé. Ce n'était pas un manifeste ou un long essai, juste deux lignes qui nommaient quelque chose que les gens faisaient déjà discrètement.

Boris Cherny : Je n'invite plus Claude, j'ai des boucles qui tournent. Ce sont elles qui invitent Claude et déterminent quoi faire.

Addy Osmani : L'ingénierie de boucle consiste à vous remplacer en tant que personne qui invite l'agent. Vous concevez le système qui le fait à votre place.

La pratique a précédé le nom de plusieurs mois, tout le monde écrivait déjà des boucles, personne ne les avait encore nommées.

Ainsi, les boucles sont désormais un élément clé de la façon dont nous permettons aux agents IA de travailler de manière itérative sur le long terme pour créer des logiciels.

Andrew Ng a organisé les trois boucles de la plus interne à la plus externe en fonction de leurs échelles de temps : la boucle la plus interne est la plus rapide, et la boucle la plus externe est la plus lente. De plus, l'entrée de la boucle la plus externe provient de la sortie de la boucle la plus interne :

Boucle

Qui l'exécute

Durée du cycle

Ce qu'elle produit vers la couche externe

Boucle de codage agentique

l'agent lui-même

secondes - minutes

une version qui fonctionne

Boucle de feedback développeur

humain + agent

dizaines de minutes - heures

une vision et un cahier des charges produit plus clairs

Boucle de feedback externe

utilisateurs + équipe

heures - semaines

des données réelles qui font évoluer la vision

Andrew Ng nous a donné la carte par le temps : trois boucles fonctionnant à des vitesses différentes. Addy Osmani a dessiné une deuxième carte par abstraction : prompt -> contexte -> harnais -> boucle.

L'ingénierie de boucle se situe au sommet et ajoute trois verbes que le harnais n'a pas. Elle s'exécute sur une minuterie, génère des assistants, et se nourrit elle-même - la sortie d'aujourd'hui devient l'entrée de demain. Ce dernier point est ce qui en fait une boucle, et non la même tâche exécutée N fois.

L'intuition la plus importante : le même bug coûte un montant différent à chaque couche :

Couche

Ce qui l'importe

Question centrale

Ingénierie de prompt

écrire un prompt

quoi dire au modèle

Ingénierie de contexte

ce qui est chargé dans la fenêtre

quoi extraire, résumer, effacer

Ingénierie de harnais

armer une exécution unique

quels outils, quelles actions, ce qui compte comme terminé

Ingénierie de boucle

planification au-dessus du harnais

comment la faire fonctionner toute seule, tour après tour

Une boucle est par conception une machine qui rend le "nombre de tours" important. Chaque décision à partir de maintenant - évaluateur, porte humaine, limite de tokens, fichier d'état - existe pour raccourcir la distance entre "une erreur se produit" et "quelqu'un la voit".

Ce qui se passe à l'intérieur d'un tour :

"Boucle" est souvent mal interprété comme "tourner en rond". Ce n'est pas le cas, chaque tour a 5 mouvements concrets. Supprimez-en un et la boucle ne fonctionnera pas - ou elle fonctionnera sans aller nulle part.

1. La vérification est le mouvement qui dit "non".
2. La planification est le mouvement qui alimente ce tour dans le suivant.

C'est exactement la partie qui en fait une boucle.

Appliqué au projet que nous allons construire : une boucle de triage matinal pour une petite équipe :

Action

Ce qu'elle fait

Dans la BOUCLE DE TRIAGE

Découverte

déterminer ce que ce tour doit faire

une compétence lit CI / issues / commits récents

Transfert

répartir la tâche et l'isoler

chaque résultat obtient son propre espace de travail

Vérification

introduire un autre agent pour dire non

un deuxième sous-agent en tant que relecteur, testant les compétences

Persistance

écrire l'état en dehors de la conversation

PR + ticket Linear + ./state/triage.md

Planification

laisser la boucle tourner tour après tour

déclencheur cron GitHub Actions à 06:00

Chacune des 5 leçons ci-dessous développe exactement un mouvement.

Cinq leçons = une boucle complète.

Et nous commençons par la première : la Découverte, car si la boucle ne peut pas décider ce qui vaut la peine d'être fait aujourd'hui, rien après cela n'a d'importance.

Leçon 1 Découverte : rédiger un SKILL.md de triage matinal

Des compétences, pas un mur de prompt.

Imaginez, c'est lundi 6h du matin. Votre ordinateur portable est fermé et GitHub Action se réveille et lance claude --skill morning-triage : ce qu'il lit, ce qu'il juge comme étant actionnable, où il écrit les résultats - tout cela vit à l'intérieur du SKILL.md que vous êtes sur le point d'écrire.

La phrase clé d'Osmani : l'automatisation devrait déclencher une compétence - une connaissance de projet écrite et mise à jour, pas un mur de prompt collé dans une tâche cron. Le prompt collé pourrit là, parce que personne ne revient jamais mettre à jour quelque chose d'enfoui dans un planning.

Votre tâche pour cette leçon : écrire une compétence dans .claude/skills/morning-triage/SKILL.md qui lit trois sources (CI / issues / commits) toute seule, décide ce qui vaut la peine d'être fait toute seule, écrit les résultats dans ./state/triage.md - et a une section Stop explicite qui précise ce que la boucle n'est PAS autorisée à faire.

Voici le modèle de départ - changez trois choses et il est à vous :

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invoqué par l'automatisation quotidienne
5---
6
7## Lire   (entrées de découverte — remplacez par les sources que VOTRE dépôt a réellement)
8- Les exécutions CI qui ont échoué depuis la dernière exécution      # gh run list --status failure
9- Les issues ouvertes dans les dernières 24h               # gh issue list --search "created:>=…"
10- Les commits fusionnés depuis hier              # git log --since=yesterday
11- Le précédent ./state/triage.md              # la passation "hier → aujourd'hui"
12
13## Juger  (le plafond — laissez la boucle choisir, ne lui donnez pas une liste)
14Pour chaque candidat, décidez :
15- est-ce ACTIONNABLE MAINTENANT, ou du bruit ?
16- cela bloque-t-il une release ? → priorité = P0
17- est-ce déjà suivi ? → ignorer
18Gardez uniquement ce qui vaut un espace de travail AUJOURD'HUI.
19
20## Écrire  (persistance — déposez-le en markdown, pas dans le chat)
21Ajoutez à ./state/triage.md :
22| résultat | source | priorité | statut |
23Validez le fichier pour que demain puisse le lire.
24
25## Transférer  (préparation pour la Leçon 2)
26Pour chaque résultat conservé, émettez une ligne de tâche :
27  worktree=fix/<slug>
28  goal=<condition-d-arret>
29
30## Arrêter   (la SEULE section non générique — réfléchissez bien ici)
31Ne jamais fusionner. Ne jamais supprimer.
32Tout ce dont vous êtes moins que confiant → ./inbox/ pour un humain.
33PAS une PR.

Trois sections font le vrai travail ici :

Lire : c'est l'entrée de la Découverte - listez des sources concrètes, jusqu'à la commande réelle. Souvenez-vous, "lire le contexte" n'est pas une source, mais gh run list --status failure en est une.

Juger : c'est le plafond de votre boucle entière. La boucle décide "actionnable vs bruit" elle-même - elle ne reçoit pas une liste de votre part, car si vous lui donnez encore une liste chaque matin, vous avez automatisé l'exécution mais pas le choix. Et le choix est généralement l'étape la plus coûteuse. Peu importe la qualité de vos sources, si cette section choisit des déchets, les quatre autres mouvements tournent sur un travail sans valeur.

Arrêter : la seule partie de ce fichier qui n'est pas générique. La boucle fera tout ce que la compétence dit, et seulement ce que la compétence dit. Si vous n'écrivez pas "ne jamais fusionner" - elle fusionnera pour vous un jour.

Énoncez les lignes rouges : ne jamais fusionner, ne jamais supprimer, ne jamais pousser vers main, tout ce qui est incertain va dans ./inbox/ pour un humain, pas dans une PR.

Encore une chose qui mérite d'être connue : cette même structure de compétence fonctionne au-delà du triage matinal : remplacez la section Lire par "les logs d'accès d'hier + les nouvelles issues + la version de déploiement actuelle" et elle devient une boucle de santé de site en soirée. Ajoutez une ligne à Juger - "est-ce une régression par rapport à hier ?" - et elle développe une comparaison inter-jours.

La maladie que cette leçon prévient - la Boucle Aveugle :

La plus courante "ressemble à une boucle mais n'en est pas une." : la boucle tourne, mais vous assignez toujours le travail chaque matin ("hé, regarde ces trois bugs"). C'est une automatisation de l'exécution, pas une automatisation de la découverte.

Symptôme : la boucle ne vous surprend jamais, car elle ne fait que ce que vous saviez déjà devoir être fait.

Correctif : mettez Juger à l'intérieur de la compétence et laissez-la choisir le travail d'aujourd'hui elle-même.

Avant de passer à la suite, répondez à ces trois questions :

1/ Combien de lignes votre section Arrêter a-t-elle ?

Si c'est juste "ne jamais fusionner" - ajoutez-en une de plus : quoi d'autre cette boucle ne devrait-elle jamais faire pour vous ? (ne jamais fermer d'issues / ne jamais pousser vers main / ne jamais prendre plus de 3 résultats à la fois..)

2/ Réécrivez la première ligne de Lire en une commande qui s'exécute réellement dans VOTRE projet

**3/ Si cette compétence reste inchangée pendant un an - que se passe-t-il ?

**Maintenant comparez : que se passe-t-il avec un mur de prompt collé dans une tâche cron pendant un an ?

Leçon 2 Transfert : distribuer le travail et l'isoler

La compétence de la Leçon 1 vient de finir de s'exécuter. ./state/triage.md contient maintenant 5 résultats actionnables. La pensée la plus naturelle qui suit - lancer 5 agents à la fois, aller vite. Cette étape exacte est la façon dont vous développez une Boucle Emmêlée : plusieurs agents éditant les mêmes fichiers dans le même répertoire, et le jour de la fusion se transforme en archéologie.

L'antidote est une ligne : chaque résultat obtient son propre espace de travail.

git worktree est un mécanisme git intégré : un dépôt, plusieurs répertoires de travail indépendants, chacun extrait sur sa propre branche. git worktree add ../fix-auth fix/auth ouvre un espace de travail totalement isolé dans ../fix-auth. constructions, éditions, tests - rien ne touche personne d'autre. un espace de travail par résultat = agents physiquement séparés.

Votre tâche pour cette leçon : écrire un script qui lit chaque résultat de ./state/triage.md, ouvre un espace de travail isolé par résultat (nommé fix/<slug>), envoie un agent pour rédiger un correctif à l'intérieur - et définit un plafond de parallélisme pour qu'il ne génère pas à l'infini.

1# lire state/triage.md, un espace de travail par résultat
2# changez : MAX_PARALLEL selon ce que votre machine / facture peut gérer
3MAX_PARALLEL=3
4
5# changez : l'analyse pour correspondre aux colonnes réelles de votre triage.md
6resultats=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for resultat in $resultats; do
10  slug=$(echo "$resultat" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # la ligne clé : isolement physique par agent
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # changez : goal est la condition d'arrêt que l'évaluateur de la Leçon 3 lira
16  claude --worktree ../wt-$slug \
17    --goal "les tests dans tests/$slug passent et le lint est propre" \
18    "rédiger un correctif pour : $resultat" &
19done
20
21wait   # laissez tous les agents parallèles terminer
22
23# règle de clôture : les agents ne fusionnent jamais automatiquement — les espaces de travail attendent
24# la porte humaine de la Leçon 5
25echo "Tous les espaces de travail prêts pour la relecture :"
26git worktree list

Les règles qui comptent ici : ne jamais travailler sur main.

Main est la piste d'atterrissage pour la relecture humaine - pas le bureau des agents. Tous les agents vivent sur les espaces de travail fix/*.

Limitez le parallélisme : la génération illimitée est la porte d'entrée vers une explosion de tokens (la Leçon 5 revient là-dessus). choisissez MAX_PARALLEL basé sur une question honnête : pas "combien ma machine peut-elle exécuter" mais "combien de PRs puis-je réellement relire."

La fusion est une décision humaine : Stripe traite plus de 1 000 PRs par semaine via des boucles comme celle-ci, et les humains les relisent toujours. L'humain n'a pas quitté le processus - il a changé de bureau : de l'écriture de code à la relecture de code.

Et un détail du cas Stripe qui mérite d'être volé : ils ont utilisé contre-intuitivement un modèle plus petit avec des portes déterministes strictes au lieu du plus grand modèle disponible.

La leçon : une porte de vérification serrée bat la puissance brute du modèle pour le travail en boucle.

La maladie que cette leçon prévient - la Boucle Emmêlée :

Une boucle à agent unique semble parfaitement saine. Le problème n'apparaît que le jour où vous passez en parallèle - cinq agents s'exécutent, cinq diffs entrent en collision dans le même fichier, la fusion est le chaos.

Correctif : chaque tâche obtient son propre espace de travail, ne partagez jamais un répertoire de travail entre agents.

Avant de passer à la suite, répondez à ces trois questions :

**1/ Quel nombre avez-vous défini pour MAX_PARALLEL - et pourquoi ?

**(argent ? machine ? ou "combien de PRs puis-je honnêtement relire" ?)

**2/ Si un espace de travail plante - l'agent se termine sans rien toucher

**que devrait enregistrer le fichier d'état de demain à ce sujet ?

**3/ Stripe a utilisé un modèle plus petit + des portes déterministes strictes

**Au lieu du plus grand modèle, que signifie ce choix pour VOTRE boucle ?

Leçon 3 Vérification : installer une porte qui dit "non" (la leçon la plus lourde)

C'est le mouvement le plus difficile de l'ingénierie de boucle, et il mérite plus d'efforts que toute autre leçon.

L'ingénieur d'Anthropic Prithvi Rajasekaran, travaillant sur des applications agentiques de longue durée, a remarqué quelque chose : demandez à un agent de noter le code qu'il vient d'écrire, et il se félicitera presque toujours - même quand un humain peut voir d'un coup d'œil que c'est médiocre.

Ce n'est pas que le modèle soit stupide : noter son propre travail est structurellement cassé. Au moment où le code est terminé, le contexte de l'agent est bourré de la chaîne d'auto-justification expliquant pourquoi il a écrit les choses de cette façon. En regardant sa propre sortie, il ne voit pas le résultat - il voit l'argument pour le résultat.

Mettez cela à l'intérieur d'une boucle et cela se transforme en désastre : à chaque tour, la question "est-ce assez bon ?" est répondue par l'agent qui vient de l'écrire. Chaque tour s'approuve lui-même. Plus cela dure, plus cela s'éloigne de la qualité réelle. C'est la Boucle qui Acquiesce - et c'est la maladie la plus coûteuse de la liste.

Le correctif de Rajasekaran, dans ses propres mots :

"Régler un évaluateur autonome pour qu'il soit sceptique est bien plus réalisable que de rendre un générateur critique de son propre travail."

C'est un problème structurel, pas un problème de formulation. Vous ne pouvez pas demander à un auteur de sortir de sa propre tête, mais vous pouvez faire intervenir un agent différent, avec des instructions complètement différentes, regardant le code à partir de zéro - sans aucune chaîne d'auto-justification attachée.

L'analogie vient des GANs : un réseau construit, un autre attaque : le créateur et le vérificateur. La même vieille règle bancaire : la personne qui vire l'argent et la personne qui l'approuve doivent être des personnes différentes.

Votre tâche pour cette leçon - écrivez deux choses :

1) Un prompt système d'évaluateur dans .claude/agents/reviewer.md avec cinq sections : RÔLE + PRÉSOMPTION + VÉRIFIER + UTILISER + VERDICT.

2) Une commande /goal déclarant la condition d'arrêt de cette boucle - jugée par un nouveau modèle séparé, pas par le générateur.

1# .claude/agents/reviewer.md  (changez 3 choses)
2RÔLE : Relecteur de code adversarial.
3PRÉSOMPTION : ce code est CASSÉ jusqu'à preuve du contraire.
4NE faites PAS d'éloges. Trouvez ce qui échoue.
5
6# changez : ordonnez VÉRIFIER par les modes d'échec réels de votre projet,
7# vérifications exécutables en premier
8VÉRIFIER, dans l'ordre :
9  1. Est-ce que ça s'exécute ?  (exécutez, ne lisez pas)
10  2. Tests : exécutez-les, collez la sortie réelle.
11  3. Cas limites que l'auteur a ignorés.
12  4. Le comportement correspond-il au ticket ?
13
14# changez : quel MCP dépend de ce que vous testez —
15# frontend → Playwright, API → curl/httpie
16UTILISER Playwright MCP : ouvrez la page, cliquez,
17capture d'écran, inspectez le DOM.
18Jugez le comportement, pas l'intention.
19
20VERDICT : PASS seulement si chaque vérification tient.
21         Sinon REJET + listez chaque raison.

1# condition d'arrêt — jugée par un nouveau petit modèle, PAS le générateur
2# changez : remplacez par la condition vérifiable réelle de votre résultat
3/goal tous les tests dans test/auth passent et l'étape de lint est propre
4
5# attention : /goal et /loop ne sont PAS la même chose
6#   /loop = relancer à intervalle (pas de jugement d'arrêt — dangereux)
7#   /goal = exécuter jusqu'à ce qu'un nouveau modèle juge la condition vraie

Deux agents, idéalement deux modèles : "même modèle, prompt différent" préserve souvent les mêmes angles morts. changez aussi le modèle si vous le pouvez.

Scepticisme par défaut : la base de l'évaluateur est PRÉSOMPTION CASSÉ - la confiance doit être gagnée en passant des vérifications, pas accordée par défaut.

Jugez le comportement, pas l'intention : "ce JSX a l'air bien" et "j'ai cliqué sur le bouton, la page a navigué, voici la capture d'écran" sont deux univers différents. l'évaluateur doit agir - exécuter les tests, cliquer sur la page, pas lire le code et ressentir.

Rejetez avec des raisons : un REJET sans raisons listées n'est pas un rejet - le générateur n'a aucune idée de quoi corriger.

Et le test décisif : votre évaluateur a-t-il réellement rejeté quelque chose au cours des 5+ derniers tours ? Une boucle qui n'a jamais dit "non" sur des centaines de tours est statistiquement impossible sur n'importe quelle charge de travail réelle. Cela prouve donc que l'évaluateur ne fonctionne pas.

La maladie que cette leçon prévient - la Boucle qui Acquiesce :

La boucle tourne, l'agent écrit du code, le même agent dit "ça a l'air bien." Chaque tour s'auto-approuve, empilant des erreurs plausibles à la vitesse de la machine. Correctif : toute cette leçon : séparation structurelle + scepticisme par défaut + jugement par l'action + une condition d'arrêt tierce.

Avant de passer à la suite, répondez à ces trois questions :

1/ Votre évaluateur est-il le même modèle avec un prompt différent, ou un modèle différent ? pourquoi ?

2/ Traduisez "jugez le comportement, pas l'intention" en une phrase concrète

de votre propre projet : "mon évaluateur ne lit pas le code il

exécute _____, et ne PASSE que lorsqu'il voit _____"

3/ Quelle est la probabilité qu'un nouveau modèle "assez bon" fasse passer à tort votre condition /goal ?

si votre mode d'échec le plus effrayant est X - ajoutez une vérification pour X à la condition d'arrêt maintenant

Leçon 4 Persistance : faire en sorte que le travail d'aujourd'hui survive jusqu'à demain

La Leçon 3 est terminée. Votre évaluateur a jugé trois résultats - deux PASS, un REJET. Question : où vivent ces trois verdicts en ce moment ?

Si la réponse est "dans la fenêtre de contexte" - alors demain à 6h, la boucle se réveille avec un contexte vidé et ne se souvient de rien. Elle refait le triage à partir de zéro, trébuche sur le REJET non corrigé d'hier, peut-être assigne un autre agent pour le corriger à nouveau, peut-être le rate complètement, peut-être tombe dans le même trou.

C'est la Boucle Amnésique - chaque jour commence à la même case.

L'antidote en une ligne : la mémoire est un état écrit sur le disque, pas un contexte. un fichier markdown, un tableau Linear, une base de données - une fois que c'est écrit, peu importe à quel point l'agent oublie.

Ces deux choses sont constamment confondues, alors fixez la différence :

CONTEXTE = la fenêtre que l'agent voit CE tour -> effacée à chaque rafraîchissement.

MÉMOIRE = l'état qui vit à travers les tours et les jours -> écrit sur le disque (markdown / BD / tableau).

Une boucle fait le pont entre aujourd'hui -> demain uniquement à travers la MÉMOIRE.

Votre tâche pour cette leçon :

1. Créez ./state/triage.md avec au moins 4 colonnes (résultat / source / priorité / statut) - la compétence de la Leçon 1 l'écrit, les espaces de travail de la Leçon 2 le lisent.
2. Branchez un connecteur (MCP) : un verdict PASS ouvre automatiquement une PR, un verdict REJET met à jour le ticket automatiquement.
3. Vérifiez que la boucle de demain peut réellement lire l'état d'aujourd'hui.

1# ./state/triage.md  (la mémoire de la boucle — changez selon les besoins)
2
3| résultat        | source       | priorité | statut     |
4|-----------------|--------------|----------|------------|
5| test auth instable | CI #4821     | P0       | en cours de correction |
6| déréférencement nul | issue 92     | P1       | PR ouverte |
7| dépendance obsolète | commit a3f9c | P2       | inbox      |
8
9# étendez les colonnes selon les besoins : dernière_vision, nombre_de_tentatives, assigné_à
10# ce fichier DOIT être validé dans le dépôt —
11# sinon l'exécuteur cloud de demain ne peut pas le voir

1// .mcp/connectors.json — branchez la boucle dans le monde extérieur
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← DOIT être false. porte humaine = Leçon 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Bloqué", "reason": "${verdict.reasons}" }
15  }
16}

Pourquoi chaque colonne compte : pas de source -> vous ne pouvez pas auditer d'où vient un résultat. pas de priorité -> vous ne pouvez pas ordonner le travail. pas de statut -> demain ne peut pas prendre le relais.

Et la vérification pour cette leçon est la seule que vous ne pouvez pas simuler : attendez jusqu'à demain. Réveillez-vous, vérifiez - l'inbox est-elle toujours là ? Les résultats non terminés conservent-ils leur statut ? L'exécution de 6h a-t-elle repris là où hier s'est arrêté au lieu de recommencer ? Celui-ci, vous le découvrez en l'exécutant, pas en raisonnant dessus.

Une discipline silencieuse qui vient avec la persistance - lisez un échantillon, toujours.

Une fois que la persistance fonctionne, un piège s'ouvre : la boucle expédie des PRs à toute vitesse, vous vous sentez productif - et votre carte mentale du codebase dérive silencieusement. La règle : ne lisez pas tout (cela va à l'encontre du but de la boucle), mais lisez un échantillon de PR par jour et forcez-vous à expliquer ce que la boucle a changé et pourquoi.

Le moment où vous ne pouvez pas l'expliquer - votre carte a pris du retard. Corriger cela un matin calme coûte dix minutes. Le corriger pendant un incident de production coûte beaucoup plus cher.

La maladie que cette leçon prévient - la Boucle Amnésique :

La boucle trouve du bon travail, le fait, puis oublie qu'elle l'a fait - parce que le résultat ne vivait que dans un contexte vidé. Au tour suivant, elle redécouvre le même travail, ou pire - le refait et écrase la première tentative.

Symptôme : pas de progrès accumulé, chaque jour commence au même endroit. Correctif : fichier d'état sur le disque.

Avant de passer à la suite, répondez à ces trois questions :

1/ Traduisez "mémoire ≠ contexte" en une phrase concrète

de votre propre projet : "mon _____ est la mémoire, mon _____ est le contexte"

**2/ La boucle de demain se réveille - quelle COLONNE de state.md

**lit-elle en premier pour décider de son premier mouvement ? avez-vous nommé cette colonne correctement, ou avez-vous simplement enterré une mine pour elle ?

**3/ Discipline : à quelle heure de la journée lirez-vous votre

**échantillon de PR ? définissez le rappel calendrier maintenant - c'est un contrat avec vous-même.

Leçon 5 Planification : rendez-la réelle, rendez-la sûre, gardez une porte ouverte

Les Leçons 1 à 4 sont installées, mais la boucle s'arrête toujours au moment où vous arrêtez d'appuyer sur le bouton. Le dernier mouvement est un verbe : accrochez-la à un déclencheur.

Mais la partie la plus dangereuse de cette leçon n'est pas de mal configurer cron. C'est de bien configurer cron correctement - parce qu'alors la boucle fonctionne vraiment seule, et un seul bug peut la faire tourner toute la nuit, des assistants générant des assistants, jusqu'à ce que vous vous réveilliez avec une facture que vous ne reconnaissez pas.

Donc cette leçon fait en réalité trois choses : accrocher le déclencheur, définir les limites, garder une porte humaine.

D'abord - choisissez votre planificateur :

1Cloud (GH Actions)   Bureau planifié   /loop (dans CC)
2s'exécute où          cloud                votre machine        votre machine
3machine allumée ?    pas nécessaire        nécessaire           nécessaire
4session ouverte ?    pas nécessaire        pas nécessaire        nécessaire
5intervalle min       1 heure               1 minute             1 minute
6voit les fichiers locaux ?   non                   oui                  oui

La question décisive : ce travail peut-il quitter votre ordinateur portable ?

1"vérifier mon serveur de développement local chaque minute"
2   → doit être local + /loop (l'intervalle d'1 heure du cloud ne peut pas l'atteindre)
3
4"analyser les issues GitHub à 3h du matin et ouvrir des PRs"
5   → doit être cloud (votre ordinateur portable est fermé — la boucle ne peut
6     pas l'attendre)

Et l'auto-tromperie la plus sournoise de toute la pratique : traiter une minuterie locale comme "fonctionnant pendant que vous dormez." Ce n'est pas le cas. c'est "fonctionner quelques tours supplémentaires pendant que je suis encore là."

Votre tâche pour cette leçon :

1. Écrire .github/workflows/triage.yml avec un déclencheur cron qui exécute la compétence morning-triage.
2. Définir trois limites : budget par exécution, budget quotidien, nombre maximal de tentatives.
3. Terminer le workflow avec la règle : jamais de fusion automatique des PR, tout ce qui est incertain va dans ./inbox/.

1# .github/workflows/triage.yml  (modifier 3 choses)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # modifier : votre fuseau horaire à 06:00 UTC
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← limite par exécution · modifier
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: triage matinal
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← limite quotidienne · modifier
22          MAX_RETRIES: '3'          # ← limite de tentatives · modifier
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: ouvrir les PR (JAMAIS de fusion automatique)
29        run: |
30          # Les PR s'ouvrent automatiquement. La fusion reste humaine.
31          gh pr create --draft --base main \
32            --title "[boucle] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # il n'y a pas de `gh pr merge` ici — intentionnellement
35
36      - name: acheminer l'incertain vers la boîte de réception
37        run: |
38          ls ./inbox/ && echo "éléments en attente de révision humaine"

Les trois règles qui le maintiennent en vie au sixième mois :

Limitez avant de lancer : trois niveaux - délai d'exécution, budget quotidien, nombre maximal de tentatives - définis avant la première exécution autonome, pas après la première facture effrayante. Un plafond de jetons ne consiste pas à économiser de l'argent. C'est un disjoncteur qui transforme un risque ouvert en risque limité. Une boucle sans limites a délégué son autorité de dépense à ses propres bugs.

Pour l'échelle : Uber a plafonné les ingénieurs à 1 500 $ par personne par outil par mois après avoir épuisé son budget IA en quatre mois. Votre limite par boucle est la version granulaire de cette leçon.

Gardez une porte ouverte : Les PR ne fusionnent pas automatiquement. Les éléments incertains atterrissent dans la boîte de réception. Vous lisez un échantillon par jour. La porte n'est pas là parce qu'un humain la franchira toujours, elle est là parce que le fait que la porte existe vous maintient dans une position où vous le pouvez. Soudez chaque porte, et le jour où vous aurez besoin d'entrer, vous aurez perdu la clé.

Vérifiez qu'elle se réveille réellement. Exécutez-la pendant au moins 3 tours (les exécutions à blanc comptent). La défaillance la plus courante : éblouissante le jour de la démo, morte jeudi. « La dernière exécution date du jour de la démo » est la signature diagnostique d'une Boucle Manuelle.

Fonctionne de la même manière en dehors de Claude Code - les capacités ne sont pas verrouillées par un fournisseur, elles sont simplement renommées :

1CAPACITÉ             Claude Code          Codex
2planification        /loop · worker       Onglet Automations
3exécution condition  /goal                réexécution automatique + juge
4isolation parallèle  --worktree           worktree en arrière-plan
5sous-agents          .claude/agents/      .codex/agents/
6connexion externe    MCP + plugins        Connecteur MCP
7compétence explicite SKILL.md             $nom-compétence
8exécution hors ligne Cloud Routines       cloud (prévu)

La question n'a jamais été « quel fournisseur ». C'est « les six capacités sont-elles toutes installées ».

La maladie que cette leçon prévient - Boucle Manuelle :

Quatre actions magnifiquement construites, pas de cron. Ce n'est pas une boucle - c'est un script que vous avez exécuté une fois et oublié.

Correctif : accrochez un déclencheur qui ne dépend pas de votre mémoire.

Avant de lancer, répondez à ces trois questions :

1/ Quels sont les chiffres exacts de vos trois limites ?

Si un bug tourne toute la nuit - quelle limite amortit la chute en premier ? Si aucune ne le fait... Qu'est-ce que cela vous dit ?

2/ À quoi ressemble votre porte humaine ?

(Revue de PR / boîte de réception / échantillon quotidien / rapprochement hebdomadaire ?) Écrivez-le = signez le contrat avec vous-même

3/ La question conclusive : dans six mois, cette boucle vous aura-t-elle rendu plus fort (compréhension, jugement, ressenti du système) - ou vous aura-t-elle transformé en gardien d'une machine que vous ne pouvez pas lire ? Quel est votre plan pour éviter la seconde option ?

Les 4 dettes et rester l'ingénieur

Votre boucle est construite : elle se réveille, trouve du travail, se critique, se souvient et planifie son propre lendemain.

Pendant qu'une boucle tourne, quatre choses s'accumulent silencieusement - et leur trait commun est qu'aucune d'elles ne déclenche d'alarme.

1DETTE DE VÉRIFICATION     sortie non rejetée qui s'accumule
2DÉTÉRIORATION DE LA COMPRÉHENSION   la base de code grandit, votre carte mentale non
3REDDITION COGNITIVE       "Je n'ai plus envie d'examiner"
4EXPLOSION DE JETONS       un bug tourne toute la nuit → vous le voyez comme une facture

Ils s'alimentent mutuellement : une sortie non vérifiée érode votre compréhension -> une compréhension érodée invite à la reddition -> la reddition laisse la boucle tourner plus longtemps et dépenser plus -> ce qui produit plus de sortie non vérifiée.

Auditez votre nouvelle boucle contre les quatre avant sa première exécution en solo :

• Mon évaluateur rejette réellement - ce n'est pas une décoration.
• Je lis un échantillon de PR par jour et peux expliquer ce qui a changé.
• J'ai gardé l'habitude de dire « c'est faux ».
• Mes limites ont été définies AVANT la première exécution, pas après la première facture.

Et voici la partie qui décide de tout :

La même boucle, construite par deux personnes, peut aboutir à des endroits opposés. L'une l'utilise pour aller plus vite tout en lisant encore le code et en gardant le cap - la boucle amplifie le jugement qu'elle a déjà.

L'autre utilise exactement la même boucle spécifiquement pour ne plus jamais rien comprendre - six mois plus tard, la première est plus affûtée, et la seconde est un gardien pour une machine qu'elle ne peut pas lire.

Addy Osmani : « construisez la boucle, mais construisez-la comme quelqu'un qui a l'intention de rester l'ingénieur - pas seulement la personne qui appuie sur le bouton. »

Les boucles rendent la génération presque gratuite, ce qui reste rare, c'est le jugement : quel plan est le bon, sur quelle ligne s'arrêter, quelle chose tourne mais est fondamentalement erronée. La boucle ne dévalorise pas le jugement - elle dépouille tout ce qui n'est pas le jugement, et ne laisse que cela.

Une boucle est un multiplicateur fidèle :

Apportez la compréhension - elle amplifie la compréhension.

Apportez la paresse - elle amplifie la paresse.

Décidez ce que vous voulez voir amplifié - avant de le construire.

Restez à l'écoute !

Bonne chance :)