Loop Engineering : les limites de la boucle

Le Loop Engineering a cinq semaines. Le 7 juin, Peter Steinberger poste sur X qu’on ne devrait plus prompter les agents mais concevoir les boucles qui les promptent. Des millions de vues en vingt-quatre heures. Addy Osmani publie l’essai fondateur le jour même, Business Insider suit, Andrew Ng y consacre une lettre du Batch. En face, un thread Hacker News de 1 800 commentaires répète que tout ça, c’est une while avec un appel LLM dedans.

Les deux camps parlent de code, et ils parlent de la même chose : la boucle. L’un trouve qu’elle change tout, l’autre qu’elle n’a rien de neuf.

Chez nous, la boucle ne sert presque jamais. C’est ce que j’ai mis le plus longtemps à comprendre.

Il n’y a pas de compilateur pour un texte

Qu’est-ce que le Loop Engineering ? Concevoir la boucle qui prompte les agents IA à votre place, au lieu de les prompter soi-même. Regardez n’importe quelle définition : la boucle découvre le travail, le délègue, vérifie le résultat, décide de continuer ou de s’arrêter. Tout tient dans « vérifie ».

Chez les développeurs, vérifier ne coûte rien. Les tests passent ou ne passent pas. Le build compile ou casse. Il existe un juge extérieur, déterministe, qu’aucun modèle ne peut charmer, et il rend son verdict en trois secondes de CI. La boucle avait sa condition d’arrêt écrite avant même que les agents existent. Voilà pourquoi le Loop Engineering explose chez les devs et à peu près nulle part ailleurs. Les autres métiers ne sont pas en retard. Ils n’ont simplement pas de juge.

Maintenant, dites-moi quel linter détecte qu’un paragraphe est techniquement juste et parfaitement creux. Il n’existe pas, il n’existera pas de sitôt, et c’est ce qui change tout : quand la vérification est chère et faillible, on ne peut pas se permettre de compter dessus. Il faut que le texte soit bon en sortant, pas après cinq passages au tribunal.

Onze agents, onze mandats

NOMO IA fonctionne avec onze agents qui se passent le relais. Recherche, rédaction, contrôle qualité, optimisation SEO/GEO, détection des répétitions, travail du ton, validation. Chacun reçoit un objectif précis et un jeu de règles, et chacun est évalué sur une grille qui correspond à son objectif, pas au résultat final.

C’est là que ça diverge de ce que raconte le mot « loop ». Le discours ambiant décrit un agent qui tourne sur lui-même jusqu’à ce qu’un test passe. Ici, il n’y a pas une boucle : il y a onze portes, et une porte ne s’ouvre que si le maillon précédent a livré ce qu’on lui avait demandé à lui. L’agent qui traque les répétitions n’a aucune opinion sur le SEO. Celui qui vérifie les sources se fiche du ton. Chacun a un mandat étroit, et c’est justement ce qui rend l’évaluation possible : personne n’a à répondre à « est-ce que c’est bon ? », question devant laquelle un LLM dira toujours oui. On demande à un agent de vérifier une chose, et on lui donne les moyens de dire non sur cette chose-là.

Quand un agent échoue, on relance. Trois fois maximum.

Ce que trois itérations révèlent

Trois, ça a toujours suffi. Pas une fois en plusieurs mois de production je n’ai vu un agent avoir besoin d’un quatrième tour pour rentrer dans le rang.

Longtemps j’ai pris ça pour une réussite d’ingénierie. C’est l’inverse. Si la boucle ne sert jamais, ce n’est pas que j’ai trouvé la bonne condition d’arrêt : c’est que le travail se fait ailleurs. Il se fait en amont, dans les règles qu’on impose à chaque agent avant qu’il écrive la première ligne. Bornez assez un mandat et l’agent converge en un ou deux tours. Les trois itérations ne sont pas une discipline durement acquise. C’est un filet de sécurité, et un filet qui ne se déclenche presque jamais.

Ce qui pose une question désagréable au Loop Engineering.

La boucle comme aveu

Le discours ambiant dit que la valeur s’est déplacée du prompt vers la boucle. Ce que mon expérience raconte, c’est à peu près le contraire.

Une boucle est ce qui rattrape un cadrage insuffisant. Elle est utile exactement dans la mesure où l’agent a été mal briefé, et elle devient spectaculaire quand il a été très mal briefé : plus la boucle a de choses à corriger, plus elle a l’air intelligente. Un agent qui reçoit un mandat étroit, des règles explicites et une grille alignée sur son objectif produit quelque chose de correct du premier coup, et la boucle qui l’entoure n’a rien à faire. Elle ne fait pas de démo. Elle ne fait pas de post viral non plus.

Ce n’est pas un argument contre les boucles. Là où la vérification est gratuite et le périmètre immense, comme dans le code, laisser tourner est parfaitement rationnel : le coût d’un tour raté est inférieur au coût de cadrer proprement. C’est un calcul, pas une révolution. Il tient tant que les tests sont verts et que les tokens sont bon marché.

Ailleurs, le calcul s’inverse. Ed Zitron résume la mécanique de fond du phénomène : ce discours revient à évangéliser la consommation autonome de tokens, ce que les vendeurs de modèles ont un intérêt évident à encourager. Uber aurait plafonné ses ingénieurs à 1 500 $ par mois et par outil d’IA après avoir consommé son budget annuel en quatre mois. Chez nous, un tour coûte quelques dizaines de centimes et je pourrais en faire vingt sans que ça se voie sur la facture. Je ne le fais pas parce que ça ne servirait à rien : ce qu’un quatrième tour corrigerait, une règle l’aurait évité.

Le travail invisible

Le principe de la boucle a cinquante ans. Les pipelines CI, les playbooks SOAR, le pattern ReAct : rien de neuf. Ce qui est nouveau, et ce n’est pas rien, c’est que le travailleur à l’intérieur de la boucle sait maintenant gérer l’ambiguïté. Le périmètre des tâches automatisables s’élargit réellement, jusqu’à un point précis : l’automatisation s’arrête là où la vérification bon marché s’arrête.

Pour le code, cette frontière est loin. Pour un texte censé convaincre un humain de vous faire confiance, elle est nettement plus proche qu’on ne le prétend sur LinkedIn. Et de ce côté-ci de la frontière, tout le travail est en amont : découper un objectif en onze mandats assez étroits pour qu’un agent puisse les tenir, écrire les règles, construire des grilles qui permettent de dire non sur quelque chose de précis. Ça prend des semaines, ça ne se voit pas, et personne n’en fait un carrousel.

La boucle, elle, se remarque. C’est peut-être pour ça qu’elle a un nom.

NOMO IA est une infrastructure éditoriale multi-agents : onze agents, onze grilles, et une boucle qui ne sert presque jamais.

Sources

FAQ

Le Loop Engineering fonctionne-t-il en dehors du développement logiciel ?

Partiellement. Une boucle agentique repose sur une condition d’arrêt, donc sur une vérification. Dans le code, ce juge existe déjà : les tests passent ou échouent, le build compile ou casse, et le verdict tombe en quelques secondes sans qu’aucun modèle puisse l’influencer. Pour un texte, ce juge n’existe pas. Aucun linter ne détecte qu’un paragraphe est techniquement exact et parfaitement creux. L’automatisation s’arrête là où s’arrête la vérification bon marché, et cette frontière est nettement plus proche pour un contenu éditorial que pour un dépôt de code.

Pourquoi NOMO IA plafonne-t-il ses agents à trois itérations ?

Parce qu’au-delà, ce n’est plus l’agent qui a échoué, c’est le mandat qui était mal écrit. En plusieurs mois de production, aucun des onze agents n’a eu besoin d’un quatrième tour. Le plafond n’est pas une contrainte de coût : un tour supplémentaire coûte quelques dizaines de centimes. C’est un signal. Un agent qui boucle signale une règle absente en amont, et c’est la règle qu’il faut corriger, pas le nombre de tours.

Faut-il investir dans la boucle ou dans le cadrage des agents ?

Cela dépend du coût de la vérification. Quand elle est gratuite et le périmètre immense, comme dans le code, laisser tourner la boucle est rationnel : un tour raté coûte moins cher qu’un cadrage soigné. Quand la vérification est chère et faillible, le calcul s’inverse et le travail se déplace en amont. Découper l’objectif en mandats étroits, écrire les règles, construire des grilles qui permettent de dire non sur un point précis. Une boucle est utile exactement dans la mesure où l’agent a été mal briefé.

NOMO IA met ces principes en pratique dans un système éditorial avec 13 agents IA spécialisés. Du cadrage à la publication, chaque étape est contrôlée.

Découvrir →

Loop Engineering : la boucle rattrape ce que le cadrage a raté