Loop Engineering, la boucle qui prompte l’agent

Le mot a une date de naissance, ce qui est assez rare pour être noté.

Le 7 juin 2026, Peter Steinberger, le développeur derrière le projet d’agent OpenClaw, publie un message qui atteint environ 6,5 millions de vues en une semaine. Sa thèse, la compétence qui compte n’est plus de bien prompter un agent, c’est de concevoir la boucle qui le fait tourner.

Le lendemain, 8 juin 2026, Addy Osmani, ingénieur chez Google, publie l’essai qui donne son nom à la pratique et surtout son anatomie. Un déclenchement automatique, des compétences écrites une fois pour toutes, des connexions vers vos outils, des agents secondaires à qui déléguer, et une mémoire gardée en dehors de la conversation.

En toile de fond, une phrase de Boris Cherny, créateur de Claude Code chez Anthropic, résume le déplacement. Son travail ne consiste plus à prompter l’IA, il consiste à écrire les boucles qui la promptent à sa place.

Voilà pour l’origine. Reste à savoir ce que ça change concrètement, et surtout pour qui.

La confusion la plus répandue consiste à croire que chaque couche remplace la précédente. C’est faux. Elles s’empilent.

• Le prompt. La formulation de la demande, dont nous avons détaillé les blocs dans écrire un bon prompt. Un prompt parfait n’invente pas une information que le modèle n’a pas.
• Le contexte. Tout ce qu’on donne à voir au modèle, documents, historique, données. Il travaille bien tant que la tâche reste courte.
• Le harnais. L’environnement autour du modèle, ses outils, ses limites, ses accès. Nous l’avons détaillé dans le harnais, ce qui sépare une IA d’un agent.
• La boucle. Le cycle qui fait tourner tout ça sans vous, jusqu’à ce que l’objectif soit atteint.

La raison d’être de la 4e couche est simple à comprendre. Les 3 premières supposent toutes qu’un humain tape quelque chose. La boucle enlève cet humain de la chaîne.

⚠ Conséquence pratique, une boucle n’améliore pas un mauvais prompt. Elle le répète plus souvent.

Les descriptions varient d’un auteur à l’autre, mais 5 éléments reviennent partout.

• Le déclencheur. Une heure fixe, un événement, un fichier déposé, un message reçu.
• L’objectif. Vérifiable, et de préférence chiffré. Pas un objectif du genre que ce soit satisfaisant, mais un critère qu’on peut contrôler.
• Les actions. Les outils que l’agent a le droit d’utiliser, et ceux qu’il n’a pas.
• La vérification. Comment l’agent contrôle son propre travail avant de le rendre.
• La mémoire. Ce qui évite de refaire ce qui a déjà été fait, et de répéter la même sortie 3 jours de suite.

Le gabarit ci-dessous marche tel quel dans une conversation ordinaire, sans outil particulier. C’est le meilleur point d’entrée pour comprendre le mécanisme.

GABARIT DE BOUCLE, a coller dans une conversation

  OBJECTIF
    Redige une accroche pour <SUJET>.

  CRITERES DE VALIDATION, tous obligatoires
    1. moins de 8 mots
    2. cree de la curiosite sans promettre plus que le contenu
    3. aucun superlatif
    4. aucun point d'exclamation

  BOUCLE A EXECUTER
    1. produis une premiere version
    2. evalue-la toi-meme, critere par critere,
       en ecrivant respecte ou non respecte et pourquoi
    3. corrige ce qui ne passe pas
    4. recommence tant que les 4 criteres ne sont pas tous
       respectes

  ARRET
    Quand les 4 criteres passent, OU au bout de 6 passages.
    Si 6 passages ne suffisent pas, rends la meilleure
    version et explique ce qui bloque.

  SORTIE
    La version finale, plus le tableau d'evaluation.

⚠ Le bloc ARRET est le seul que tout le monde oublie, et c’est celui qui coûte de l’argent. Sans lui, rien ne dit à l’agent quand s’arrêter.

👉 Notez qu’il n’est jamais nécessaire d’écrire le mot boucle. C’est le fait de demander une auto-évaluation répétée contre des critères qui produit le comportement.

Voilà le point que les démonstrations passent sous silence. La majorité des tâches n’ont pas besoin d’une boucle.

4 conditions doivent se cumuler. Si une seule manque, vous paierez des jetons pour un résultat que vous devrez vérifier vous-même de toute façon.

LE TEST EN 4 QUESTIONS, avant d'ecrire la moindre boucle

  1. LA TACHE REVIENT-ELLE ?
     Tous les jours, toutes les semaines, a chaque
     nouveau dossier. Une tache unique ne justifie
     jamais le temps de conception d'une boucle.

  2. SAIT-ON DIRE OUI OU NON ?
     De facon binaire, sans discussion. Le test passe
     ou ne passe pas. Le fichier fait moins de 500 Ko
     ou non. Si la reponse est ca depend, arretez-vous.

  3. LA TACHE VA-T-ELLE DE BOUT EN BOUT SANS VOUS ?
     Si a un moment il faut que vous tapiez une
     information que vous seul avez, ce n'est pas une
     boucle, c'est un enchainement d'etapes.

  4. Y A-T-IL UN JUGEMENT HUMAIN A LA FIN ?
     Si oui, la boucle ne vous fera pas gagner de
     temps. Vous relirez tout, comme avant.

⚠ Le test de la question 2, en pratique. Lancez la tache
  15 a 20 fois. Si vous n'etes pas capable de dire, sans
  hesiter, lesquelles sont bonnes, c'est qu'il y a du
  jugement humain dedans.

Notre lecture, et elle est plus sobre que le discours ambiant. Une boucle vaut le coup quand son objectif se contrôle par une donnée, un temps de chargement, un score, un nombre. Dès que le critère devient un avis, la boucle itère dans le vide.

Une boucle mal bornée ne casse rien. Elle consomme, silencieusement.

L’image qui circule chez les praticiens est juste, une boucle sans condition d’arrêt, c’est une voiture laissée phares allumés. Rien ne se voit sur le moment.

Des retours d’usage font état de boucles parties pour plus de 12 heures sur un objectif inatteignable, pour un résultat inexploitable. Le problème n’était pas la machine, c’était la définition de terminé.

Posez donc toujours 2 limites, jamais une seule.

python3 <<'PY'
# Ce que coute une boucle, AVANT de la lancer.
# Chiffres a remplacer par ceux de votre fournisseur.

JETONS_PAR_PASSAGE = 12000     # entree + sortie, un passage
PRIX_PAR_MILLION   = 6.0       # en euros
PASSAGES_MAX       = 8
PAR_JOUR           = 1

cout_passage = JETONS_PAR_PASSAGE / 1_000_000 * PRIX_PAR_MILLION
pire_jour    = cout_passage * PASSAGES_MAX * PAR_JOUR

print(f"  Cout d'un passage        : {cout_passage:.3f} EUR")
print(f"  Pire cas sur une journee : {pire_jour:.2f} EUR")
print(f"  Pire cas sur un mois     : {pire_jour * 30:.2f} EUR")
print()
print("  ➜ Si ce dernier chiffre vous surprend, c'est que la")
print("    boucle n'a pas de plafond de passages. Ajoutez-en un.")
PY

Le chiffre du bas est celui qu’il faut regarder. Il ne dit pas si la boucle est utile, il dit ce qu’elle coûte le jour où elle part en vrille.

Ici, nous avons vérifié plutôt que recopier, parce que 2 sources récentes affirment l’inverse l’une de l’autre.

L’une annonce que la boucle continue de tourner une fois l’ordinateur éteint. L’autre l’a testée et mesure le contraire. La mesure gagne.

Ce que fait réellement la commande, dans la version testée. Elle programme une tâche récurrente à intervalle régulier, toutes les heures par exemple, et elle vit dans votre session. Elle attend que vous soyez inactif pour se déclencher, et elle consomme votre contexte au passage.

LES 5 LIMITES MESUREES, a connaitre avant de compter dessus

  1. TERMINAL FERME, TOUT EST PERDU
     Les taches programmees ne survivent pas a la fin
     de session.

  2. 3 JOURS MAXIMUM
     Au-dela, la tache disparait. Une verification
     hebdomadaire ne tient donc pas.

  3. AUCUN RATTRAPAGE
     Une occurrence ratee est perdue, elle ne se
     rejoue pas.

  4. VOTRE CONTEXTE SE REMPLIT PLUS VITE
     Chaque passage ecrit dans la meme session. Plus
     le contexte se charge, plus la qualite baisse.

  5. AUCUN PARALLELISME
     Ce n'est pas un sous-agent. Rien ne tourne
     pendant que vous travaillez.

➜ La formule qui resume : c'est un GUETTEUR, pas un
  OUVRIER. Parfait pour surveiller un deploiement en
  cours ou attendre une relecture. Inadapte a une
  tache recurrente qui doit tenir des semaines.

Pour de la vraie récurrence, il faut un service qui tourne ailleurs que dans votre session. Une tâche planifiée côté serveur, ou l’outil de bureau qui, lui, garde ses tâches au redémarrage.

👉 Et un mécanisme qu’aucune de ces 2 sources ne mentionne, alors qu’il est livré officiellement. Un greffon signé Anthropic, c’est-à-dire un module qui s’ajoute à l’outil, implémente la boucle la plus simple qui soit. Renvoyer le même prompt à l’agent tant qu’il n’a pas fini.

# Le greffon officiel, verifie sur notre propre machine.
# ⚠ La 1re commande se tape DANS l'outil, pas dans un
#   terminal. Seule la derniere ligne est du shell.
# Il relance le MEME prompt a chaque fois que l'agent
# tente de s'arreter, jusqu'a la promesse ou la limite.

/ralph-loop Corrige les tests qui echouent \
  --max-iterations 20 \
  --completion-promise 'TOUS LES TESTS PASSENT'

# Suivre l'iteration en cours, depuis un autre terminal
grep '^iteration:' .claude/ralph-loop.local.md

⚠ La règle la plus intéressante de ce greffon est une règle de méfiance. L’agent n’a le droit d’annoncer la phrase de fin que si elle est vraie. Il lui est explicitement interdit de la prononcer pour sortir de la boucle quand il bloque. Autrement dit, les concepteurs ont prévu que l’agent essaie de tricher pour s’échapper. C’est le meilleur résumé de ce qu’est vraiment une condition d’arrêt.

Le terme a ses critiques, et elles méritent d’être entendues. Certains y voient surtout une façon de faire consommer plus de jetons pour produire davantage de contenu médiocre.

La réponse honnête est qu’on manque encore de recul. Les démonstrations publiques sont impressionnantes et rarement mesurées.

3 choses qu’une boucle ne fera pas à votre place.

• Elle ne remplace pas une définition de terminé. C’est vous qui décidez à quoi ressemble un résultat correct. La boucle applique ce critère, elle ne l’invente pas.
• Elle ne rattrape pas un objectif subjectif. Face à un critère du genre jusqu’à ce que ce soit bien, l’agent tourne et s’arrête au hasard.
• Elle ne transforme pas un usage en méthode. Un développeur qui construit des agents toute la journée gagne à travailler ainsi. Cela ne dit rien de ce que ça donnera dans une PME de 12 personnes.

Notre position. Commencez par la boucle la plus petite qui apporte quelque chose, une auto-vérification contre 3 ou 4 critères écrits, dans une conversation ordinaire. C’est gratuit, ça marche partout, et ça donne déjà l’essentiel du gain. Le reste vient quand une tâche prouve qu’elle revient et qu’elle se mesure.