Loop Engineering

Un matin, je tape une phrase dans mon agent et je pars me faire un café. Le temps de revenir, il a écrit du code, l’a testé, jeté les essais ratés, et me laisse deux ou trois choses à relire. Je n’ai pas écrit dix prompts. J’ai écrit une boucle. Le loop engineering, c’est concevoir cette boucle : décider ce que l’agent fait entre deux actions, quand il vérifie son travail, et comment il sait qu’il a fini.

De l’ingénierie de prompt à l’ingénierie de boucle

La bascule s’est faite en trois temps. En 2024, on écrivait de bons prompts, on était opérateur. En 2025, on lançait plusieurs agents en parallèle, on devenait manager. En 2026, les modèles sont devenus assez bons pour écrire leurs propres prompts, et le travail a encore remonté d’un cran : on conçoit le système qui fait tourner l’agent. La règle qui force ce changement est simple : si vous n’appuyez plus sur Entrée entre chaque étape, quelque chose d’autre doit décider quand le travail est assez bon.

Une boucle, concrètement

Avant, c’est vous qui étiez la boucle. Vous vous teniez entre chaque étape de l’agent : vous lisiez sa sortie, vous repériez l’erreur, vous décidiez de la suite, vous lui disiez de recommencer. Le loop engineering, c’est sortir de ce cycle-là et monter d’un cran, concevoir la piste sur laquelle l’agent court tout seul.

Voici la version la plus simple qui soit. Vous donnez à l’agent un objectif et une condition d’arrêt, et vous le laissez tourner :

C’est ça, une boucle. Et sur une tâche simple, ça marche vraiment. Débarrassée du jargon, elle tient en quatre gestes qui s’enchaînent et se répètent :

Mais pointez la même boucle vers quelque chose de plus flou, « améliore cette page », « fais des recherches sur ce sujet et rédige-les », et elle produit soit quelque chose d’excellent, soit, en silence, une coûteuse machine à médiocrité. Ce qui fait basculer d’un côté ou de l’autre, c’est la partie dont presque personne ne parle.

Le vérificateur est le goulot, pas le générateur

Une boucle, c’est un générateur branché sur un vérificateur : l’un produit, l’autre tranche si c’est au niveau. Et toute la différence se joue sur le second. Prenez la même tâche, deux fois, une fois sans barre, une fois avec :

Le générateur, le modèle qui produit, est devenu abondant et bon marché : on peut le relancer cent fois sans y penser. Le vérificateur, lui, reste rare. C’est le renversement du métier :

Écrire un bon vérificateur, c’est savoir précisément à quoi ressemble « du bon travail » pour votre problème. C’est ça, le vrai savoir-faire, et il ne se délègue pas au modèle : le générateur est interchangeable, votre définition du « bien », non. (Si vous avez fait du machine learning, c’est l’idée de la fonction de récompense : on ne dicte pas chaque geste à la machine, on définit ce qui compte comme réussi, et elle apprend à viser ça.) Une nuance, tout de même : tout ceci suppose que personne ne regarde la boucle tourner.

Quand un humain regarde, le vérificateur devient optionnel

Tout ce qui précède vaut quand la boucle tourne sans personne devant, une tâche planifiée, la nuit. Mais dès qu’un outil vous montre la boucle en train de tourner, et que vous êtes là, la donne change. Vous lisez, vous voyez le résultat, vous corrigez d’un geste, vous ajustez la barre, pendant que l’agent continue. Autrement dit, l’humain redevient le vérificateur, en direct. (C’est le parti pris de COGS, un agent de bureau qui rend la boucle visible au lieu de la lancer à l’aveugle.)

C’est même parfois la seule bonne option. Pour tout ce qui demande du goût ou du jugement, « ce texte est-il bon ? », « cette interface est-elle élégante ? », « cette analyse tient-elle la route ? », aucune règle automatique ne capture vraiment le « correct ». Un humain tranche d’un coup d’œil, et mieux qu’un script. Chercher à automatiser la vérification du goût, c’est se compliquer la vie pour un résultat plus faible.

Rien de tout cela n’enlève sa force au vérificateur automatique : quand la réussite est simple à chiffrer (un test qui passe, un nombre à atteindre), il fait le tri tout seul et garde les coûts sous contrôle, indispensable quand personne ne regarde. Mais dès qu’un humain est dans la boucle, il devient un confort, pas une obligation. On peut très bien faire tourner une boucle longtemps sur le seul jugement humain.

Les boucles s’emboîtent

Cet humain qui regarde, en fait, tient sa propre boucle, plus lente que celle de l’agent. Andrew Ng en décrit trois, emboîtées comme des poupées russes. La plus rapide (quelques minutes) est celle de l’agent, qui itère tout seul. Autour, une boucle plus lente (des heures) : vous relisez, vous ajustez la barre, vous donnez une direction. Et tout autour, la plus lente (des jours, des semaines) : le monde réel, des vrais utilisateurs, des vrais résultats qui reviennent du terrain.

Ce qui rend la boucle humaine irremplaçable, c’est que vous savez des choses que le modèle ignore : le contexte de votre métier, vos clients, ce qui compte vraiment. Aucun agent ne devine ça tout seul. Le rôle de l’humain, c’est d’apporter ce jugement-là, au bon moment, dans la bonne boucle.

Boucle ouverte vs boucle fermée

Toute boucle se situe entre deux pôles. Une boucle fermée : « refais ce rapport chaque lundi, dans ce format exact », les critères sont connus d’avance. Une boucle ouverte : « trouve un angle neuf pour ce lancement », on explore large. Choisir le bon pôle, puis écrire le vérificateur qui va avec : c’est ça, l’ingénierie.

Et surtout : prenez l’outil le moins autonome qui fait le travail. L’autonomie est un moyen ; ce qui compte, c’est le résultat livré.

Du loop au graph : les boucles sont des nœuds

Une couche a poussé au-dessus du loop engineering : le graph engineering. L’idée : au lieu d’une seule boucle, on en relie plusieurs. Chaque nœud est une boucle qui produit quelque chose ; les liens entre nœuds décident lequel tourne ensuite, par exemple, « si le brouillon dépasse 500 mots, passe au nœud relecture, sinon publie ». Le loop, c’est l’artisanat d’un nœud ; le graph, l’art de les câbler.

Comment ça marche dans COGS

Jusqu’ici, tout ceci vaut pour n’importe quel outil de ce genre. Rendons-le concret avec COGS, un agent de bureau, dans la lignée de Claude Code, dont le parti pris est de montrer la boucle : on la voit tourner, on la met en pause, on l’édite à chaud. Voici comment les pièces s’assemblent :

Concrètement, un tour de vérification exécute une condition d’arrêt déterministe à même la playlist :

{
  "title": "VERIFY : la définition du « fini »",
  "text": "Point d'étape :\n\n{{ python plans/2026-08-01_.../stop_condition.py }}\n\nAgis sur la sortie."
}

# exit 0  → stdout collé comme message  (⏳ rappel de ce qui reste  |  ✅ bilan)
# exit ≠0 → la playlist AUTO-PAUSE       (🛑 blocage réel → l'humain)

Tenir sur les longs scopes

Une boucle qui tourne dix minutes, n’importe quel outil la gère. Une boucle qui tourne des heures ou des jours, construire une app entière, dérouler un long process, bute sur deux murs : la mémoire de l’agent, et le fait de partir de zéro à chaque problème. Deux techniques les font tomber.

Le point cardinal : l’agent ne s’arrête (presque) jamais lui-même

Un agent a toujours quelque chose à faire, même quand il déclare « c’est fini », il sous-estime presque toujours ce qui reste. L’auto-arrêt doit donc rester l’exception. À chaque tour de vérification, la condition d’arrêt recalcule la définition du « fini » et renvoie l’un de trois états :

Et dans tous les cas, l’humain regarde de temps en temps et sait stopper la boucle lui-même : c’est la voie royale.

« Le loop engineering, c’est juste du buzz ? »

Depuis que le terme est devenu à la mode, les critiques ont pris du poids, et elles méritent d’être posées honnêtement, pas balayées :

• « Ça brûle du budget la nuit. »
• « Ça a quand même besoin des humains. »
• « C’est juste une boucle for avec des étapes, rien de neuf. »

Presque toutes décrivent, en fait, ce qui se passe quand on saute le vérificateur. Une boucle sans barre brûle effectivement du budget ; une boucle avec une barre claire + un humain qui regarde fait l’inverse. Et oui, la mécanique n’a rien de neuf, c’est justement le point : le neuf, c’est que définir « fini » est devenu la compétence rare, pas l’écriture des prompts. Les deux choses sont vraies à la fois : le mot surfe une vague, et le fond en dessous est réel.

Écrire le vérificateur, c’est le nouveau prompt engineering

Bien menée, la démarche tient en quatre réflexes : définir « fini » de façon mesurable avant la première consigne ; fixer les critères à l’avance ; poser une limite de tours pour ne jamais tourner à l’infini ; et joindre le compte-rendu de ce que la boucle a fait à ce que vous rendez à l’humain. Le reste, générer, est devenu la partie facile.

Ta checklist de démarrage

1. 1Prends la tâche répétable la moins risquée que tu as sous la main cette semaine.
2. 2AVANT d’écrire la moindre instruction, écris ce que « fini » veut dire, en mesurable.
3. 3Épingle les critères ; choisis boucle ouverte ou fermée.
4. 4Pose une limite de tours (max_loops), jamais l’infini.
5. 5Laisse tourner contre TA barre, pas celle du modèle ; regarde de temps en temps.
6. 6Joins le compte-rendu de la boucle à ce que tu rends (le bilan du stop-condition).

Questions fréquentes

Cet article s’appuie sur « Loop Engineering Guide (2026) » d’AI Builder Club, transposé sur notre stack COGS et enrichi de notre méthodologie (initiatives traçables, vérificateurs déterministes, Reality Driven Design).