Ingénierie des boucles : les boucles gagnent là où la vérification coûte peu

Boris Cherny, l’ingénieur à l’origine de Claude Code, garde cinq à dix sessions ouvertes, avec quelques centaines d’agents en activité dans la journée et quelques milliers chaque nuit.² Quand un extrait où il déclare « je ne rédige plus de prompts pour Claude… mon travail consiste à écrire des boucles » a circulé sur X au cours de la semaine écoulée, la plupart des commentaires y ont vu une prophétie sur le développement logiciel autonome, et quelques jours plus tard Addy Osmani baptisait une discipline d’après cette phrase : l’ingénierie des boucles (loop engineering).⁷ J’ai récupéré les transcriptions intégrales des trois interventions dont l’extrait est tiré. Elles racontent une histoire plus discrète, et c’est sur cette version-là qu’il vaut la peine de bâtir : chaque boucle que Cherny cite nommément possède une condition de réussite qu’une machine peut vérifier gratuitement. Ce n’est pas la construction de la boucle qui décide de ce que vous pouvez automatiser, mais le coût de la vérification. Je fais tourner des boucles en production depuis février, et mes journaux confirment ce que disent les transcriptions — y compris deux incidents qui m’ont enseigné la leçon à la dure.

En bref / points clés

• La citation virale provient de l’entretien de Cherny dans Acquired Unplugged, où il présente les boucles comme l’étape suivante d’un continuum allant des cartes perforées à l’assembleur, puis aux langages de haut niveau, puis au prompting.¹ Il assigne à cette transition une durée de vie courte : « les prochains mois, et peut-être le reste de l’année ».¹
• La mécanique est volontairement banale. Dans son intervention chez Sequoia, Cherny décrit /loop comme Claude qui utilise cron pour planifier une tâche récurrente.² Les boucles qu’il cite surveillent des pull requests, maintiennent la CI en bonne santé et regroupent les retours Twitter toutes les 30 minutes.²
• Toutes ces boucles relèvent de l’intendance. Chacune a un état final vérifiable par une machine : CI au vert, PR rebasée, retours regroupés. Aucun des exemples qu’il cite ne construit de fonctionnalité sans surveillance.
• Le métier consistant à écrire des boucles est déjà en train de se dissoudre dans le modèle. Cherny rapporte que les modèles récents lancent des boucles de leur propre initiative, et il qualifie la construction de boucles côté utilisateur de « problème de conception produit », dont il tire ce constat : « je fais mal mon travail ».⁵
• La compétence durable sous le mème : décider ce qu’il est sûr d’automatiser sans surveillance. Cette décision relève d’un jugement sur la vérifiabilité, et elle vous restera acquise longtemps après la disparition de la syntaxe des boucles.

Ce qu’il a réellement dit

L’extrait que tout le monde a partagé provient d’un entretien Acquired enregistré en public. Cherny amène sa formule par une histoire de famille : son grand-père programmait sur cartes perforées en Union soviétique, et son père écrivait de l’assembleur et « se serait moqué de moi parce que j’écris du Python ». Puis vient le passage qui a fait le tour du réseau :

« C’est un peu la nature de la programmation : le niveau d’abstraction monte toujours… Il y a un an, je codais en écrivant du code avec une forme d’autocomplétion dans un IDE. En novembre, j’ai désinstallé mon IDE, parce que je ne m’en servais plus… À ce moment-là, je faisais tourner peut-être cinq ou dix instances de Claude en parallèle, et coder consistait à demander à Claude d’écrire du code. Aujourd’hui, le niveau est encore monté d’un cran… je ne rédige plus de prompts pour Claude. J’ai des boucles qui tournent. Ce sont elles qui sollicitent Claude et qui décident, en quelque sorte, de ce qu’il faut faire. Mon travail consiste à écrire des boucles. »¹

L’entretien Acquired Unplugged dans son intégralité ; le passage sur les boucles commence à 11:14.

Deux détails de la transcription intégrale n’ont jamais figuré dans les extraits. D’abord, Cherny date lui-même la transition : les boucles sont ce que « nous allons voir dans les prochains mois, et peut-être le reste de l’année ».¹ Il décrit une phase, pas une destination. Ensuite, une note de sourçage pour qui veut remonter le fil du débat : plusieurs publications virales attribuaient le passage sur les boucles à son apparition d’une heure dans le podcast Y Combinator. J’ai vérifié la transcription complète de cet épisode. Elle ne contient aucune mention de boucles ; l’épisode porte sur la genèse du produit et sur les sous-agents.⁶ La substance se trouve dans l’entretien Acquired et dans une intervention de 24 minutes chez Sequoia.

Une boucle, c’est une tâche cron

L’intervention chez Sequoia fournit la mécanique, et elle est délibérément ennuyeuse :

« Ça se résume à ceci : vous demandez à Claude d’utiliser cron pour planifier une tâche à un moment futur, et c’est une tâche récurrente. Elle peut tourner toutes les minutes, toutes les cinq minutes, tous les jours. »²

L’intervention chez Sequoia fournit tous les détails mécaniques que les extraits viraux ont laissés de côté ; la section sur les boucles commence à 7:56.

Cherny en fait tourner des dizaines. Celles qu’il nomme : une boucle qui surveille ses PR (réparation de la CI, rebase automatique), une boucle qui maintient la CI en bonne santé (elle répare les tests instables), et une boucle qui récupère les retours sur Twitter et les regroupe toutes les 30 minutes.² Routines, annoncé lors de l’événement Code with Claude d’Anthropic en mai, déplace le même schéma côté serveur, si bien que la boucle survit à un ordinateur portable refermé.² Simon Willison, qui couvrait la keynote en direct, a consigné la formule employée par Anthropic elle-même : les Routines sont des « prompts d’ordre supérieur ».¹² Cherny répétait depuis des mois que /loop et /schedule figuraient parmi les fonctionnalités les plus puissantes du produit ; son exemple canonique pour débuter est une boucle de cinq minutes qui surveille les PR.¹¹

Le schéma a un ancêtre plus rustique. La technique Ralph Wiggum de Geoffrey Huntley se résume, selon ses propres mots, à « Ralph, c’est une boucle Bash » : un while true qui alimente indéfiniment un agent avec le même fichier de prompt, la progression étant conservée dans les fichiers et l’historique git entre deux itérations.⁹ Anthropic distribue désormais Ralph sous forme de plugin officiel, qui intercepte les tentatives de sortie de l’agent et lui renvoie le prompt jusqu’à ce qu’une chaîne de fin apparaisse ou qu’un plafond d’itérations soit atteint.⁹ The Register a confirmé que Cherny utilise lui-même Ralph, et a repris l’avertissement de Huntley sur la direction que prend l’économie du procédé : des startups s’en serviront pour cloner des entreprises SaaS existantes et casser leurs prix, puisque le codage agentique revient à une dizaine de dollars de l’heure.¹⁰ Cette filiation compte parce qu’elle révèle l’âge réel de l’idée : la boucle est la plus ancienne structure de contrôle de l’informatique, et il n’y a rien de neuf dans la construction elle-même.¹⁵

Toutes les boucles qu’il cite relèvent de l’intendance

Voici l’observation que le débat a sautée. Reprenez la liste des boucles de Cherny et regardez leur état final :

Chacune possède soit une condition de réussite vérifiable par une machine, soit une sortie dont les erreurs ne coûtent rien. Aucun des exemples qu’il cite ne dit « construis la fonctionnalité pendant que je dors ». L’homme qui fait tourner quelques milliers d’agents chaque nuit décrit son automatisation personnelle comme de la réparation de CI, du rebase et du tri de retours utilisateurs.

Le contre-exemple apparent confirme la règle. L’équipe d’ingénierie d’Anthropic a fait tourner 16 agents en boucles infinies pendant deux semaines et a produit un compilateur C de 100 000 lignes écrit en Rust, pour un coût d’environ 20 000 dollars de calcul.⁸ Un compilateur est l’artefact le plus vérifiable qui soit en informatique : un gigantesque corpus de programmes de test se compile et s’exécute correctement, ou non. L’équipe a choisi une cible où la vérification est quasi gratuite — et même dans ce cas, Nicholas Carlini, qui a mené l’expérience, a écrit que voir des programmeurs déployer des logiciels qu’ils n’ont jamais vérifiés eux-mêmes constitue « un vrai motif d’inquiétude ».⁸

L’essai d’Addy Osmani qui baptise la discipline « loop engineering » aboutit à la même contrainte, du côté de la conception : « Une boucle qui tourne sans surveillance est aussi une boucle qui commet des erreurs sans surveillance. »⁷ L’architecture qu’il propose — des agents vérificateurs distincts, pour que le fabricant ne note jamais son propre travail — est une tentative de fabriquer une vérification bon marché là où elle n’existe pas naturellement.⁷

Ce que mes propres boucles m’ont appris

J’ai écrit en février sur mon système d’agents nocturnes, à une époque où le terme poli pour désigner la technique était encore une référence aux Simpson.¹⁶ Depuis, les boucles qui ont survécu dans mon installation ont toutes convergé vers la même forme, et celles qui ont échoué m’ont appris davantage que celles qui ont fonctionné.

Les survivantes ont toutes la forme d’une vérification. Une boucle nocturne lit les commits du jour, associe les fichiers modifiés aux URL en production, charge chaque page concernée et signale succès ou échec avec les temps de chargement. Une boucle de sécurité surveille les endpoints pendant la nuit et rédige un briefing matinal. Une boucle d’exploration lit l’activité de Googlebot et de Bingbot sur mes sites et signale les dérives d’indexation. Aucune ne crée quoi que ce soit. Chacune observe, compare à un état attendu, et rend compte. Quand l’une se trompe, le coût est un rapport périmé, pas un produit cassé. La lecture du matin prend quelques minutes parce que la sortie est binaire, ligne par ligne : succès, échec, regardez ici.

Les échecs, ce sont les boucles qui agissaient. Une fonctionnalité d’isolation qui créait automatiquement des worktrees git pour les agents parallèles a supprimé à deux reprises des répertoires de travail qu’elle avait jugés jetables ; le rayon d’action de l’automatisation englobait des fichiers qu’elle n’avait pas créés et qu’elle ne comprenait pas. Une purge de cache planifiée s’est un jour exécutée dans le mauvais ordre par rapport à un déploiement, et les robots des moteurs de recherche ont reçu pendant 11 heures des 404 pour des pages qui existaient, parce que la purge avait évincé des réponses correctes en cache avant que l’origine ne serve leurs remplaçantes.¹⁶ Aucun de ces deux échecs ne venait d’un mauvais modèle. Les deux venaient de moi : j’avais accordé un accès en écriture à une boucle dont je n’avais pas fixé les préconditions. Chacune a désormais son garde-fou : l’automatisation des worktrees est purement et simplement bloquée, et les purges ne se déclenchent qu’après validation de la vérification du déploiement. La règle générale que j’en ai tirée : une boucle qui se contente de lire a besoin d’une planification ; une boucle qui écrit a besoin d’une preuve d’ordonnancement et d’une limite de rayon d’action avant de mériter cette planification.

Cette règle explique aussi la partie de l’installation de Cherny que l’on a le plus de mal à croire. « En fait, je fais désormais la majeure partie de mon travail depuis mon téléphone », dit-il, en lançant ses sessions depuis l’onglet code de l’application Claude.² Un téléphone est un très mauvais endroit pour relire du code et un excellent endroit pour lire un rapport succès/échec. L’argument du téléphone est un argument de vérification déguisé : ses boucles produisent une sortie assez lisible pour être acceptée ou rejetée d’un coup d’œil, ce qui n’est possible que si les conditions de réussite ont été conçues avant le lancement de la boucle.

L’échelle du coût de vérification

Si la thèse tient, choisir ce qu’il faut automatiser se ramène à une seule question : qui vérifie le résultat, et combien coûte cette vérification ? Voici l’échelle que j’applique avant d’accorder une planification à une tâche.

La colonne qui décide, c’est la deuxième, et la difficulté de la tâche n’y figure jamais. Une tâche difficile dotée d’un vérificateur gratuit (le test instable) s’automatise avant une tâche facile dont la vérification coûte cher (un changement de texte d’une ligne qu’un humain doit approuver). Les boucles de Cherny, le compilateur d’Anthropic et mes survivantes se situent tous dans la moitié haute de l’échelle ; les commentaires viraux, eux, supposaient la moitié basse.

La forme qui survit à cette échelle ressemble toujours au même schéma de supervision, quelle que soit son ampleur :

L’anatomie d’une boucle qui mérite sa planification. Le vérificateur est dessiné plus épais parce que c’est lui qui porte la charge : retirez-le et la boucle continue de tourner, mais plus personne ne sait ce qu’elle a fait.

La plus petite boucle qui vaille la peine d’être lancée est en lecture seule, autovérifiante et lisible d’un coup d’œil, ce qui la rend sûre à écrire aujourd’hui et ennuyeuse à observer demain :

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

Dans Claude Code, la même boucle tient en une ligne : /loop 24h suivi de l’instruction. La promotion vient plus tard. Une fois que le rapport est resté ennuyeux pendant un mois, la boucle a mérité qu’on envisage de la faire monter d’un barreau, et pas avant.

Le métier qui reste

Le passage le plus étrange de l’intervention chez Sequoia sape le mème qu’elle a engendré. Cherny raconte que les modèles récents se sont mis à lancer des boucles sans qu’on le leur demande : il réclame une requête sur des données, le modèle remarque que ces données évoluent dans le temps, propose un rapport récurrent toutes les 30 minutes et branche lui-même ce rapport sur Slack.⁵ Sa conclusion : « Ce n’est pas aux utilisateurs de comprendre comment mieux tenir l’outil… c’est en réalité un problème de conception produit, et je fais mal mon travail. »⁵ L’argument de la régression infinie que les sceptiques ont soulevé sur X (si les humains écrivent les boucles aujourd’hui, les modèles les écriront demain) se révèle être la feuille de route d’Anthropic, concédée par celui-là même dont le mème parle.

Il va plus loin : « À mesure que le modèle s’améliore, le cadre d’agent devient un peu moins important », en prédisant que les modes de permission, les défenses contre les injections de prompt et les points de contrôle humains s’effaceront à mesure que l’alignement progressera.³ Je prends le pari inverse sur la moitié de cette affirmation. L’échafaudage de sécurité rétrécira peut-être. L’échafaudage d’orchestration, lui, devient tout le métier, de son propre aveu : les agents des ingénieurs d’Anthropic se coordonnent entre eux via Slack pendant que leurs propriétaires travaillent, et « nous n’avons plus nulle part dans l’entreprise de code écrit à la main. Tout le SQL est écrit par des modèles ».⁴ Quelqu’un décide à quoi ces agents ont le droit de toucher, ce qui compte comme terminé, et ce qui se passe quand deux d’entre eux ne sont pas d’accord. Cette couche de décision, c’est la véritable interface des agents, et cron n’en est que la partie facile.

La compétence durable n’est donc pas la syntaxe des boucles, que le modèle est déjà en train d’absorber, ni le prompting, que les boucles ont absorbé les premières. La compétence durable, c’est le jugement qui sous-tend les deux : décider ce qu’il est sûr d’automatiser sans surveillance. Ce choix est toujours une question de coût de vérification. La réparation de la CI s’est automatisée en premier parce que la suite de tests faisait déjà office de vérificateur. Le regroupement des retours s’est automatisé parce que les erreurs n’y coûtent rien. Le développement de fonctionnalités résiste parce que la vérification coûte encore un humain qui lit le diff — et un ingénieur expérimenté a exposé sans détour, sur Hacker News, le piège qui en découle : l’outil exige un jugement aiguisé pour être piloté, et son usage érode précisément ce jugement.¹⁴

L’entretien de Casey Newton avec Cherny, dans Platformer, a paru sous le titre « Claude Code’s creator on the end of the software engineer ». Cherny y prédit que l’intitulé « ingénieur logiciel » se dissoudra d’ici la fin de l’année en quelque chose comme « constructeur », tandis que le nombre de personnes écrivant du code par l’intermédiaire d’agents sera multiplié par cent.¹³ Les constructeurs, dans cette prévision, sont ceux qui choisissent les boucles. Bien choisir, c’est savoir, avant que quoi que ce soit ne s’exécute, comment vous saurez que ça a marché.

Points clés

Pour les ingénieurs qui font tourner des agents de code : - Évaluez vos candidats à l’automatisation selon le coût de vérification, pas selon l’enthousiasme. La réparation de la CI, le rebase, la surveillance et la génération de rapports disposent aujourd’hui de vérificateurs gratuits : automatisez-les en premier. - Appliquez la séparation lecture/écriture : une boucle en lecture seule a besoin d’une planification, tandis qu’une boucle disposant d’un accès en écriture a besoin d’une contrainte d’ordonnancement explicite et d’une limite de rayon d’action avant de tourner sans surveillance. - Concevez le rapport avant la boucle. Si vous ne pouvez pas rejeter la sortie de la boucle depuis votre téléphone en 10 secondes, la boucle n’est pas prête à tourner la nuit.

Pour les responsables d’équipe : - C’est votre capacité de relecture, et non votre nombre d’agents, qui plafonne le parallélisme utile. Ajouter des agents au-delà de ce plafond produit des fusions non relues, pas du débit. - Séparez les fabricants des vérificateurs. Un agent qui vérifie son propre travail se contente d’affirmer qu’il est correct ; un vérificateur distinct, doté d’un autre point de vue, a au moins une chance de prendre cette affirmation en défaut.

Pour ceux qui construisent des outils : - Cherny qualifie la construction de boucles côté utilisateur d’échec de conception produit, et les modèles lancent déjà des boucles d’eux-mêmes.⁵ Construire une UX de rédaction de boucles, c’est construire pour une couche que le fournisseur du modèle compte absorber. La surface la plus durable, c’est la vérification : les preuves, les traces et l’ergonomie d’acceptation ou de rejet.

FAQ

Références