Loop engineering : ce qui est vraiment nouveau (et ce que ma méthode faisait déjà)

Cette semaine, je suis tombé sur un article d'Addy Osmani qui théorise le « loop engineering » : ne plus prompter ses agents de code soi-même, mais concevoir le système qui les prompte à votre place. Il cite Boris Cherny, le créateur de Claude Code : « Je ne prompte plus Claude. J'ai des boucles qui tournent et qui promptent Claude. Mon travail, c'est d'écrire des boucles. » J'ai pris l'article comme un test : qu'est-ce que ma méthode couvrait déjà, et qu'est-ce qui me manquait vraiment ?

Les cinq briques du loop engineering

L'article décompose une boucle en cinq briques, plus une fondation : des automatisations qui se déclenchent toutes seules, des worktrees pour isoler les agents parallèles, des skills pour capitaliser la connaissance projet, des connecteurs MCP pour agir sur vos vrais outils, des sous-agents pour séparer celui qui produit de celui qui vérifie. Et en dessous de tout ça, une mémoire qui vit hors du contexte de conversation — un fichier markdown, un board, peu importe, du moment que ça survit à la session.

En confrontant cette grille à ma méthode, le bilan était plus flatteur que prévu :

Quatre briques sur cinq existaient déjà, parfois depuis plus d'un an. La mémoire versionnée est même la thèse centrale de ce blog : l'agent oublie tout entre deux sessions, le repo n'oublie rien. Mais la première brique — celle qui fait qu'une boucle est une boucle et pas un run qu'on relance à la main — me manquait entièrement. Tout mon système attendait que je le déclenche. C'est exactement la différence entre outiller ses agents et concevoir le système qui les fait travailler.

Ce qu'on a construit : une boucle fermée

J'ai donc passé une journée à fermer la boucle, avec Claude Code comme partenaire de conception. Le résultat tient en trois pièces, toutes versionnées dans le repo.

D'abord, une queue de fichiers : un dossier todo/ où chaque tâche est un fichier markdown autosuffisant — le scope complet, les contraintes découvertes, les décisions déjà tranchées. Quand je cadre un besoin en conversation avec Claude Code, la valeur de cette itération se capitalise dans le fichier au lieu de s'évaporer à la fin de la session. Une session de boucle réclame ensuite une tâche en la déplaçant vers doing/ (un déplacement de fichier fait un verrou très convenable), la traite, puis la range dans done/ avec son rapport. La boucle s'auto-alimente : une tâche finie, la suivante démarre.

Ensuite, un harnais d'exécution : pour chaque tâche, un workflow déterministe enchaîne implémentation, tests automatisés à trois niveaux — unitaires, fonctionnels de bout en bout, parcours complets — puis une boucle de convergence dont je reparle plus bas. Le point clé : un agent ne passe jamais à la suite si un test est rouge, et il n'a pas le droit d'affaiblir un test pour le faire passer. Le vérificateur qui compte n'est pas un autre agent qu'on peut convaincre, c'est une suite de tests qui ne négocie pas.

Enfin, une inbox de décisions : tout ce qui relève d'un choix produit — un comportement à trancher, un wording ambigu, un état manquant — sort de la boucle sous forme d'une page HTML que j'ouvre dans mon navigateur. Chaque décision propose Go, No-go ou À discuter, avec un champ de commentaire, et un bouton « Copier pour Claude Code » assemble ma réponse. Je la colle dans n'importe quelle session, les Go redeviennent des tâches dans la queue. Les agents ne tranchent jamais un choix produit à ma place : c'est une règle écrite dans le contrat, pas une bonne intention.

Là où ma méthode va plus loin que l'article

La littérature sur le sujet s'arrête en général à la revue de code : un agent écrit, un autre relit. C'est nécessaire, mais ça ne regarde que le code. Or ce que vos utilisateurs voient, c'est un écran.

Ma boucle de convergence ajoute donc une dimension que je n'ai vue nulle part ailleurs : à chaque tour, un agent lance l'application, capture chaque écran nouveau ou modifié — en desktop et en mobile — et confie ces captures à deux experts joués par des agents distincts. Un expert product design, qui cherche les problèmes de hiérarchie visuelle, les états vides ou d'erreur manquants, la lisibilité mobile. Un expert product management, qui vérifie que la valeur promise par la tâche est réellement perceptible à l'écran et que le parcours n'a pas de friction. C'est le prolongement direct de ce que j'avais expérimenté en faisant tester des maquettes par des personas joués par Claude — appliqué cette fois en continu, à chaque feature, sans intervention de ma part.

Leurs findings sont triés par une règle simple : ce qui est mécanique — un contraste insuffisant, une troncature, une duplication de code — est corrigé immédiatement par un nouvel agent, et les tests repassent. Ce qui est produit part dans mon inbox. La boucle est bornée : trois tours maximum, un seuil de sévérité pour ignorer le pinaillage, et une condition de convergence — un tour sans correction mécanique, c'est terminé. Sans ces bornes, une boucle de relecture devient une machine à polir indéfiniment, qui dégrade autant qu'elle améliore.

La première tâche réelle a d'ailleurs été instructive : deux frictions détectées dans la journée — un format d'argument mal passé entre agents, un port de développement déjà occupé par mon propre serveur — et deux corrections reportées le soir même dans les templates d'un installeur réutilisable. Ma boucle s'installe maintenant sur n'importe quel repo en une commande. C'est ça, le vrai livrable : pas une feature, un système qui s'améliore à chaque friction rencontrée.

Ce que la boucle ne fait toujours pas

L'article d'Osmani se termine sur une mise en garde que je partage entièrement : deux personnes peuvent construire exactement la même boucle et obtenir des résultats opposés. L'une s'en sert pour aller plus vite sur un travail qu'elle comprend en profondeur, l'autre pour éviter de comprendre. La boucle ne fait pas la différence. Vous, si.

Concrètement, ma boucle ne supprime ni la préparation — qui reste l'essentiel du travail — ni la revue humaine. Elle déplace mon levier : je ne prompte plus l'implémentation, je rédige des tâches autosuffisantes et je traite des décisions dans une inbox. Ma bande passante de relecture reste le plafond du système, et c'est un plafond que j'assume : le jour où je l'oublierai, la qualité de ce que je livre le rappellera à ma place.