Anthropic paie ses ingénieurs 80 000 $ par mois. Ces ingénieurs fusionnent désormais 8 fois plus de code par jour qu'il y a un an. Non pas parce que le modèle est devenu plus intelligent. Mais parce qu'ils ont cessé de solliciter Claude par des prompts pour commencer à construire des systèmes qui le font à leur place.
Brian Cherny, responsable de Claude Code chez Anthropic : « Je ne fais plus de prompts pour Claude. J'ai des boucles qui s'exécutent, qui sollicitent Claude et déterminent ce qu'il faut faire. Mon travail consiste à écrire des boucles. »
La plupart des développeurs lisent cela sans comprendre ce que cela signifie concrètement. À la fin de cet article, vous le saurez, et vous aurez tout ce qu'il faut pour construire votre première boucle ce week-end.
Ce qu'est réellement une boucle
Un prompt est une instruction unique. Une boucle est un objectif vers lequel l'IA travaille en continu jusqu'à l'atteindre.
La différence réside dans celui qui est aux commandes. Avec un prompt, vous guidez Claude manuellement à chaque étape. Avec une boucle, vous définissez l'objectif une seule fois et le système exécute le cycle complet par lui-même : trouver le travail, l'exécuter, vérifier le résultat et décider de la suite. Le tout sans que vous ayez à intervenir.
1Prompt | vous tapez, Claude répond, vous tapez à nouveau2Boucle | le système trouve le travail, Claude exécute,3 | le système vérifie le résultat, répète jusqu'à la fin
Chaque véritable boucle comporte cinq étapes :
1Découverte | trouver ce qui doit être fait2Planification | décider comment le faire3Exécution | effectuer le travail4Vérification | vérifier par rapport à l'objectif5Itération | pas terminé ? réinjecter le résultat et recommencer
Trois de ces étapes effectuent tout le travail réel.
La vérification est le cœur du système. Sans une véritable vérification du résultat, vous n'avez pas une boucle, mais un agent qui s'auto-valide en boucle. La vérification doit être objective. Un test qui réussit ou échoue. Une compilation qui aboutit ou non. Un linter qui renvoie zéro ou une erreur. Il ne s'agit pas de demander à un second agent de « réviser ». Deux optimistes qui sont d'accord ne constituent pas une vérification.
L'état (state) est ce qui permet à la boucle d'apprendre. À chaque passage, l'IA doit se souvenir de ce qu'elle a déjà essayé, sinon elle répétera indéfiniment la même erreur. Une vraie boucle conserve un historique en dehors de la conversation : ce qui est fait, ce qui a échoué, ce qui suit. L'agent oublie entre les sessions. Le fichier, lui, ne l'oublie pas.
Une condition d'arrêt est ce qui garantit la stabilité. Une boucle sans sortie s'exécute jusqu'à ce qu'elle réussisse, qu'elle casse quelque chose ou qu'elle épuise votre budget. Toute boucle sérieuse possède deux façons de s'arrêter : le succès et une limite stricte. Sans cela, vous avez construit une machine qui vous facture en silence.
Le test en 4 conditions avant de construire quoi que ce soit
Une boucle n'est rentable que lorsque ces quatre conditions sont réunies. Si l'une manque, contentez-vous d'un prompt manuel.
1Condition 1 | la tâche se répète au moins chaque semaine2 | moins fréquent - le coût de configuration ne sera jamais rentabilisé34Condition 2 | quelque chose peut rejeter automatiquement les mauvais résultats5 | un test, une build, un linter, une vérification de type6 | sans porte automatique - vous finirez par vérifier chaque diff78Condition 3 | l'agent peut effectuer le travail de bout en bout9 | ne pas vous renvoyer la moitié du travail en cours de route1011Condition 4 | « terminé » est objectif, pas une question de goût12 | si la qualité est subjective, l'humain reste meilleur
Bonnes premières boucles :
1Tri des échecs CI | chaque nuit, classer les échecs, rédiger des correctifs2Mises à jour de dépendances | hebdomadaire, scanner les mises à jour, ouvrir des PR3Passages de lint-and-fix | sur chaque PR, appliquer les corrections de style automatiquement4Ébauches d'Issue-to-PR | sur les bases de code avec une forte couverture de tests
Mauvaises premières boucles - gardez un humain aux commandes :
1Réécriture d'architecture | jugement humain requis, la boucle dérivera2Code d'auth ou paiements | erreurs irréversibles trop coûteuses3Déploiements en prod | nécessite une approbation humaine4Travail produit vague | « terminé » n'est pas objectif
Les cinq briques de construction
Chaque boucle fonctionnelle est assemblée à partir de cinq parties. Claude Code intègre ces cinq éléments.
1 - L'automatisation (le battement de cœur)
C'est ce qui fait d'une boucle une véritable boucle et non une exécution unique. Un déclencheur se lance selon un calendrier ou un événement, confie la tâche à Claude et rapporte les résultats sans que vous ayez à vérifier.
1/loop | réexécute un prompt selon une cadence2/goal | continue jusqu'à ce qu'une condition que vous avez écrite soit vraie3hooks | déclenche des commandes à des moments précis du cycle de vie de l'agent4cron | s'exécute après que vous ayez fermé l'ordinateur via GitHub Actions
Le plus important est /goal. Un petit modèle séparé vérifie si la condition est remplie ; ainsi, l'agent qui a écrit le code n'est pas celui qui le note.
1/loop 30m /goal "Tous les tests dans test/auth passent et le lint est propre."2Scanner src/auth pour les échecs, rédiger des correctifs, ouvrir une PR quand l'objectif est atteint.
2 - Compétences (écrire la connaissance du projet une seule fois)
Une compétence (skill) est le moyen d'arrêter de réexpliquer le même contexte de projet à chaque session. Un fichier SKILL.md contient les instructions, conventions et règles que la boucle lit à chaque exécution.
Sans compétences, la boucle redéduit l'intégralité de votre projet à partir de zéro à chaque cycle. Avec des compétences, l'intention se cumule : les conventions, les étapes de build, les erreurs passées... écrites une fois, lues pour toujours.
1skills/2 ci-triage.md - règles de classification, modèles de correctifs, critères d'escalade3 frontend.md - Tailwind, Next.js, SEO, règles d'accessibilité4 security.md - modèles d'auth, validation d'entrée, liste des zones interdites5 deps.md - règles de mise à jour, vérifications de compatibilité, modèles de rollback
L'automatisation appelle la compétence par son nom. Le travail récurrent reste maintenable au lieu de pourrir dans un calendrier que personne ne met à jour.
3 - Sous-agents (séparer le créateur du vérificateur)
C'est l'élément structurel le plus utile dans toute boucle. Séparez l'agent qui écrit de l'agent qui vérifie.
Le modèle qui a écrit le code est trop indulgent pour noter son propre travail. Un second agent avec des instructions différentes — et parfois un modèle plus puissant — détecte ce que le premier a ignoré.
1Agent créateur | modèle rapide et peu coûteux - explore, implémente, rédige2Agent vérificateur | modèle puissant, haute exigence - révise, vérifie, rejette
1.claude/agents/2 explorer.md | lecture seule, modèle rapide, trouve ce qui doit être fait3 implementer.md | écrit le correctif, exécute les tests4 reviewer.md | audit de sécurité, qualité du code, porte objective
Un modèle. Trois spécialistes. La boucle tourne pendant que vous ne regardez pas, et le vérificateur est la seule raison pour laquelle vous pouvez réellement vous éloigner.
4 - Connecteurs (pour agir, pas seulement suggérer)
C'est la différence entre une boucle qui dit « voici le correctif » et une boucle qui ouvre la PR, lie le ticket et envoie un message sur Slack une fois que la CI est au vert.
1GitHub | lire les dépôts, créer des branches, ouvrir des PR, réagir aux webhooks2Linear | mettre à jour les tickets, lier les PR, fermer les éléments une fois vérifiés3Slack | poster les résultats du tri, alerter les humains en cas d'escalade4Sentry | enquêter sur les alertes en direct, rédiger des correctifs pour les alertes fréquentes
Sans connecteurs, la boucle décrit ce qu'elle ferait. Avec des connecteurs, elle le fait.
5 - Le fichier d'état (l'agent oublie. Le fichier, non.)
La pièce qui semble trop simple pour être importante, mais qui est la colonne vertébrale de toute boucle fonctionnelle. Un fichier Markdown en dehors de la conversation qui enregistre ce qui est fait, ce qui a échoué et ce qui suit.
1# État de la boucle - ci-triage23## Dernière exécution42026-06-09 03:30 UTC - 7 échecs classés, 3 correctifs rédigés, 4 escaladés56## En cours7- claude/fix-auth-token-refresh - tests passant localement, en attente de CI89## Terminé aujourd'hui10- claude/bump-axios-1.7.4 - fusionné, CI au vert1112## Escaladé aux humains13- src/billing/refund.ts - tests échouant de 3 manières, cause racine floue1415## Leçons apprises16- 2026-06-08 : PowerShell rencontre un problème TLS sur le runner Windows. Utiliser bash.17- 2026-06-07 : tests/e2e/checkout nécessite le secret webhook Stripe. Ignorer si manquant.
L'exécution de demain lit ce fichier et reprend là où elle s'était arrêtée. Sans cela, chaque exécution repart de zéro.
À quoi ressemble une vraie boucle
Le tri des échecs CI est l'une des meilleures premières boucles, car la vérification est automatique et les risques liés à une mauvaise sortie sont faibles.
1Déclencheur | chaque nuit à 3h ou sur événement d'échec CI2Compétence | ci-triage.md3Lecture état | STATE.md - ce qui a échoué hier, ce qui a été corrigé
La boucle s'exécute :
1Étape 1 | lit les échecs CI depuis GitHub via connecteur2Étape 2 | classe chaque échec : env / flake / bug / dépendance / infra3Étape 3 | pour chaque échec corrigible - ouvre un worktree, envoie l'agent implémenteur4Étape 4 | l'agent réviseur vérifie le correctif par rapport aux tests et règles de sécurité5Étape 5 | la porte est franchie - ouvre une PR et lie le ticket Linear6Étape 6 | la porte échoue - escalade vers la boîte de réception de tri humain7Étape 7 | met à jour STATE.md8Étape 8 | poste un résumé de la nuit sur Slack
Le matin, vous vous réveillez avec un message Slack, une boîte de réception de tri contenant uniquement les problèmes complexes et une série de PR ayant déjà passé la revue automatisée. Vous n'avez pas eu à taper un seul prompt.
La boucle qui se cumule à l'échelle de toute l'entreprise
La version la plus puissante n'est pas une seule boucle. Ce sont plusieurs boucles écrivant dans un système d'artefacts partagés afin qu'elles apprennent les unes des autres.
Chez SuperDesign, leurs boucles couvrent le support, le SEO, la croissance produit et les publicités. Chacune a son propre déclencheur et flux de travail. Mais elles écrivent toutes dans le même magasin de signaux partagé.
La boucle de support remarque que cinq utilisateurs demandent comment exporter quelque chose. Elle crée un signal :
1type: signal2titre: L'export est trop difficile à trouver3fréquence: 54catégorie: friction5tags: [feedback, tarification, conversion]
La boucle SEO remarque une page avec un fort trafic mais une faible conversion. Elle crée un autre signal. La boucle de croissance produit lit les deux signaux ainsi que les analyses et identifie que la friction liée à l'export est plus importante que ce que les données brutes suggéraient, car deux sources indépendantes confirment le même problème. La boucle publicitaire trouve une lacune dans les mots-clés et l'injecte directement dans la boucle SEO.
1Boucle support | trouve la friction, écrit le signal2Boucle SEO | trouve une lacune de contenu, écrit le signal3Boucle produit | lit les deux signaux, identifie la priorité4Boucle pub | trouve une lacune de mots-clés, alimente la boucle SEO
Aucune de ces boucles n'est une automatisation isolée. Elles fonctionnent à partir d'une base de connaissances partagée sur ce que l'entreprise apprend. Chaque boucle rend chaque autre boucle plus intelligente. C'est cela, la capitalisation.
Les échecs dont personne ne vous avertit
La boucle Ralph Wiggum. Un agent censé signaler l'achèvement uniquement lorsqu'il a terminé le fait trop tôt. La boucle s'arrête sur un travail à moitié fait et continue de tourner et de facturer sans rien produire. Solution : une porte stricte capable d'échouer objectivement le travail, pas un « ça a l'air bien » complaisant.
La dérive de l'objectif sur les longues sessions. Les contraintes disparaissent au tour 47 à mesure que le contexte se résume. Solution : un AGENTS.md permanent que l'agent relit au début de chaque exécution.
La dette de compréhension. Plus la boucle livre rapidement du code que vous n'avez pas écrit, plus l'écart se creuse entre ce qui existe et ce que vous comprenez. La facture qui fait mal n'est pas celle des tokens. C'est le jour où vous déboguez un système que personne dans l'équipe n'a lu. Solution : lisez chaque diff que la boucle ouvre.
La capitulation cognitive. La tentation d'arrêter de se forger une opinion et d'accepter tout ce que la boucle renvoie. Concevoir la boucle est le remède quand vous le faites avec discernement, et l'accélérateur quand vous le faites pour éviter de réfléchir. Même action, résultat opposé.
Les coûts en tokens qui s'accumulent. Chaque itération de boucle relit le contexte complet et la pile grossit à chaque passage. Suivez le coût par changement accepté. En dessous de 50 % de taux d'acceptation, la boucle coûte plus cher qu'elle ne rapporte.
L'ordre de construction qui fonctionne réellement
Tous ceux qui déploient des boucles qui survivent en production procèdent de la même manière :
1Étape 1 | rendre UNE exécution manuelle fiable d'abord2Étape 2 | la transformer en compétence - sauvegarder les instructions dans SKILL.md3Étape 3 | envelopper la compétence dans une boucle - ajouter la porte et la condition d'arrêt4Étape 4 | PUIS la mettre sur un calendrier
Planifier quelque chose que vous n'avez pas rendu fiable manuellement est exactement la façon dont les boucles explosent pendant que vous dormez. Prouvez-le une fois. Renforcez-le. Ensuite, automatisez-le.
La métrique qui compte n'est pas le nombre de tokens dépensés ou de tâches tentées. C'est le coût par changement accepté. Si la boucle vous donne dix résultats et que vous en rejetez six, vous faites le travail de revue qu'elle était censée vous épargner.
Le changement qui a déjà eu lieu
En 2024, l'effet de levier se situait au niveau du prompt. Meilleur prompt, meilleure sortie, meilleur développeur. En 2026, l'effet de levier se situe un étage au-dessus : le système qui décide sur quoi Claude travaille, quand, avec quelle porte et quel état survit entre les exécutions.
Les ingénieurs d'Anthropic fusionnent 8 fois plus de code par jour non pas parce qu'ils ont trouvé une meilleure façon de poser des questions à Claude. Mais parce qu'ils ont cessé de poser des questions et ont commencé à construire des systèmes qui posent des questions à Claude en leur nom, en continu, pendant la nuit, pendant qu'ils dorment.
La boucle ne rend pas le travail plus facile. Elle déplace l'endroit où le travail se produit. De la saisie de prompts à la conception du système qui saisit les prompts. De la manipulation de l'outil à la construction de l'usine.
La plupart des développeurs continueront à faire des prompts à la main et se demanderont pourquoi l'écart ne cesse de se creuser. Quelques-uns passeront un week-end à construire leur première boucle — une automatisation, une compétence, un fichier d'état, une porte — et ne reviendront jamais en arrière.
