loop-engineering : concevoir la boucle qui pilote l'agent, pas le prompt suivant

Le problème visé : la saisie de prompt comme goulot

Le README ouvre sur une formule nette : arrêter de prompter, concevoir la boucle. Le déplacement est là. Dans un usage courant d'un agent de code, l'humain relance, reformule, attend, corrige. Le travail avance au rythme de la frappe. loop-engineering propose autre chose : un système qui découvre le travail, le confie aux agents, vérifie les résultats et persiste un état. Vous ne tapez plus le prompt suivant, vous définissez ce qui génère les prompts.

Le dépôt se présente lui-même comme une bibliothèque de patterns pour opérer des agents autour d'une base de code, et prend soin de préciser ce qu'il n'est pas : un bouton qui réécrit un module. Cette précision compte, parce qu'elle fixe le public. Il s'agit d'équipes qui ont déjà un dépôt avec des issues, une CI, des dépendances, et qui veulent industrialiser la maintenance plutôt que de générer du code neuf à la chaîne. Le tableau des jobs du README oriente explicitement vers le chemin refactor pour livrer une fonctionnalité, et vers daily-triage pour garder le dépôt en bonne santé.

Ce que contient réellement le dépôt

Trois couches cohabitent. D'abord une collection de patterns documentés, chacun avec une cadence, un niveau de départ pour la première semaine et un coût annoncé : Daily Triage en 1 jour à 2 heures, Thin loop sur événement plus 1 jour, PR Babysitter en 5 à 15 minutes, CI Sweeper à la même cadence, Dependency Sweeper en 6 heures à 1 jour, Changelog Drafter, Post-Merge Cleanup, Issue Triage. Un registre YAML sert d'index, et une page de sélection interactive existe sur le site de présentation.

Ensuite une CLI TypeScript publiée sur npm sous @cobusgreyling/loop, avec cinq sous-commandes visibles dans le README : init, doctor, status, audit, cost. Les anciens paquets séparés (loop-init, loop-audit et les autres) restent pris en charge, ce qui évite de casser les usages existants mais laisse deux surfaces à maintenir.

Enfin des exemples par outil : Claude Code avec un plugin dédié, Grok, Codex, OpenClaw, Opencode, GitHub Actions. Le README mentionne aussi des dépôts compagnons (memory-engineering, harness-foundry, outerloop, fleet-engineering, goal-engineering) avec un avertissement inhabituel : ne pas les ajouter tant qu'une boucle n'a pas réellement tourné.

Le mécanisme : un état persistant et un vérificateur

Le cœur du modèle tient dans une phrase du README : vous concevez un système qui découvre le travail, le confie à des agents, vérifie les résultats et persiste l'état. Quatre étapes, donc, et la troisième est celle qu'on oublie le plus souvent quand on bricole un script d'automatisation.

La persistance passe par un fichier STATE.md. Le dépôt fournit un script de démonstration, scripts/empty-to-state-demo.sh, qui montre le trajet d'un dépôt vide jusqu'au premier STATE.md. Le starter thin-loop est présenté comme une alternative qui n'exige pas ce fichier, ce qui indique que STATE.md est le mécanisme par défaut et non une obligation absolue.

La vérification est traitée comme une composante de premier ordre, au point que le README conditionne le passage au niveau supérieur à sa fiabilité : ne monter en L2 puis L3 qu'après une semaine où le vérificateur a eu raison. C'est un critère observable, pas une intention. Une checklist de conception de boucle est fournie séparément dans docs/loop-design-checklist.md.

Le score Loop Ready mérite qu'on s'y arrête. Le README indique qu'il pondère désormais davantage les exécutions récentes que les fichiers présents sur disque, avec un exemple concret : un STATE.md vieux de trente jours ne vaut pas un niveau L3. Autrement dit, l'outil évalue une activité, pas une arborescence. C'est un choix défendable, mais il suppose que l'historique d'exécution soit disponible et lisible par l'outil.

Mise en route : trois commandes et un niveau de départ

Le README donne la séquence minimale :

npx @cobusgreyling/loop init . --pattern daily-triage --tool claude npx @cobusgreyling/loop doctor . npx @cobusgreyling/loop cost --pattern daily-triage --level L1

Le paramètre --tool vaut claude par défaut si on l'omet, et se remplace par grok, codex ou opencode. Le pattern se choisit par nom, ici daily-triage, l'un des huit documentés.

Le point de conception le plus intéressant est ailleurs : la première semaine est en report-only. La boucle observe et rapporte, elle n'agit pas. Le tableau des patterns décline ce principe par pattern, avec une colonne Week 1 qui indique L1 report pour Daily Triage, L1 snapshot pour Thin loop, L1 watch pour PR Babysitter, L2 cautious pour CI Sweeper, L2 patch-only pour Dependency Sweeper, L1 draft pour Changelog Drafter, L1 off-peak pour Post-Merge Cleanup et L1 propose-only pour Issue Triage. Deux patterns seulement démarrent en L2, et ce sont ceux dont le périmètre d'action est le plus restreint.

Le coût est annoncé par pattern, en qualitatif : Low, Very low, High, Very high, Medium. La commande cost accepte un niveau explicite, ce qui laisse penser qu'on peut estimer avant de lancer. Le README ne donne pas de chiffres, et je n'en inventerai pas.

Le coût en tokens comme argument de conception, pas comme note de bas de page

Le README écrit noir sur blanc que les coûts en tokens peuvent exploser et que les boucles non surveillées produisent des erreurs non surveillées. La phrase est courte, elle est placée dans la section operating and safety, et elle est cohérente avec le tableau des coûts par pattern.

Regardez la répartition. PR Babysitter tourne toutes les 5 à 15 minutes et coûte High. CI Sweeper tourne à la même cadence et coûte Very high. Dependency Sweeper, à 6 heures ou 1 jour, retombe à Medium. Daily Triage, à 1 jour ou 2 heures, est Low. La cadence est le premier facteur de coût, avant la complexité de la tâche. Un lecteur qui choisit PR Babysitter pour la réactivité achète aussi la facture correspondante, et le dépôt ne prétend pas le contraire.

C'est là que la commande cost prend son sens : elle sert à arbitrer entre patterns avant de les installer, pas à constater après coup. Le README ne documente pas le format de sortie, donc la valeur exacte de l'estimation reste à vérifier à l'usage.

Les limites que le dépôt reconnaît lui-même

Peu de projets listent leurs échecs dans leur propre README. Ici, une section entière est consacrée aux histoires, avec la mention wins and failures, et le formulaire de contribution demande explicitement de commencer par les échecs. Il existe aussi des documents dédiés aux modes de défaillance et aux anti-patterns. C'est un signal de maturité documentaire, pas une preuve de robustesse du code.

La limite structurelle est plus prosaïque. Une boucle qui tourne sans surveillance prend des décisions sans surveillance, et le seul garde-fou proposé est le vérificateur. Si le vérificateur se trompe de façon systématique, la boucle produit du bruit à cadence régulière. Le README traite ce risque par un délai : une semaine d'exécutions correctes avant de monter d'un niveau. Ce délai est une règle sociale, pas un verrou technique. Rien n'empêche de lancer init avec un pattern en L3 dès le premier jour.

Deuxième réserve : le projet est explicitement un amplificateur de jugement. Il ne remplace pas la lecture de ce que la boucle produit. Le README le formule sans détour : lisez ce que la boucle livre. Une équipe qui installe daily-triage et n'ouvre jamais les rapports n'a rien gagné, elle a déplacé le travail.

Troisième réserve : l'écosystème de dépôts compagnons suggère que le périmètre de base ne couvre pas la mémoire longue ni l'orchestration multi-agents. Le README conseille de ne pas les ajouter trop tôt, ce qui revient à dire que le besoin apparaîtra plus tard, quand une première boucle aura tourné assez longtemps pour révéler ses manques.

Comparaison : ce que change un pattern par rapport à un script maison

L'alternative la plus évidente n'est pas un produit concurrent, c'est un cron et un script shell qui appelle l'agent. La différence porte sur trois points précis.

Le premier est le niveau d'autonomie comme paramètre nommé. Un script maison agit ou n'agit pas, il n'a pas de L1, L2, L3. Ici le niveau est une entrée de configuration, avec une progression documentée et un critère de passage (le vérificateur a eu raison pendant une semaine). Cela force à écrire ce que la boucle a le droit de faire, au lieu de le découvrir en production.

Le deuxième est le score Loop Ready et sa pondération par récence. Un script maison n'a pas de mesure de sa propre santé. L'outil doctor produit une évaluation, et le README insiste sur le fait qu'un STATE.md ancien ne suffit pas à déclarer une boucle mature. On peut discuter la métrique, mais elle rend visible un phénomène réel : les boucles meurent en silence et laissent des fichiers derrière elles.

Le troisième est le catalogue. Huit patterns avec cadence, niveau de départ et coût annoncés évitent de réinventer la répartition des tâches. Un script maison reproduit en général un seul de ces patterns, celui que l'auteur avait en tête, sans la colonne des coûts.

Ce que le dépôt ne fait pas, en revanche, c'est choisir à votre place. Le tableau des jobs et le sélecteur interactif orientent, mais la décision de cadence et de niveau reste la vôtre, et c'est précisément là que se joue la facture.

Maintenance, licence et coût de mise à jour

Le dépôt est sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver l'avis de licence. Ce n'est pas un avis juridique : lisez le fichier LICENSE du dépôt avant toute intégration dans un produit distribué.

La maintenance côté utilisateur se répartit en deux postes. Le premier est la mise à jour de la CLI, publiée sur npm sous @cobusgreyling/loop, avec des versions rapprochées visibles dans l'historique : v1.5.0 en juin 2026, v1.6.0 en juillet 2026. Le README signale que les anciens paquets restent pris en charge, ce qui laisse le choix entre migrer vers la commande unifiée ou rester sur les paquets séparés. Rester en arrière est possible, mais cela signifie suivre deux lignes de publication.

Le second poste est le contenu de la boucle elle-même : les patterns, les exemples par outil et les documents de sécurité évoluent. Comme la boucle s'appuie sur des fichiers présents dans votre dépôt (STATE.md, configuration du pattern), une montée de version peut demander de relire ces fichiers. Le README ne documente pas de procédure de migration entre versions majeures de la CLI, et c'est une lacune à connaître avant de s'engager.

Enfin, le coût récurrent le plus élevé n'est pas logiciel : c'est le temps humain consacré à lire les rapports et à juger le vérificateur. C'est ce que le projet demande en échange de l'automatisation, et le README le dit à sa manière en rappelant que l'ingénierie de boucle amplifie le jugement.

Conclusion éditoriale

Adoptez loop-engineering si vous avez déjà un dépôt vivant et que vous voulez cadrer la façon dont un agent y travaille, en commençant par daily-triage en L1 report-only. N'y allez pas si vous cherchez un bouton qui réécrit un module, ou si vous n'avez pas la discipline d'attendre une semaine avant de passer en L2. Avant tout, lancez npx @cobusgreyling/loop init . --pattern daily-triage --tool claude puis npx @cobusgreyling/loop doctor . sur un dépôt réel, et vérifiez ce que le score Loop Ready pondère : le README précise qu'il pèse davantage les exécutions récentes que les fichiers présents sur disque.

Sources officielles

1. cobusgreyling/loop-engineering on GitHub
2. License: MIT
3. Project website
4. README
5. Releases