Loop engineering · arrête de piloter l'IA à la main et fais-la travailler seule vers l'objectif

À qui ça s'adresse ?

À quiconque construit déjà avec l'IA et a réalisé une chose inconfortable : c'est toi le goulet d'étranglement. Tant que tu es devant, l'IA avance ; dès que tu pars, tout s'arrête. Cette ressource, c'est le saut de « je dirige chaque étape » à « je monte un système qui avance seul ». Pas besoin d'être programmeur : il faut comprendre le schéma.

1. Le déclic : quand tu réalises que c'est TOI le moteur

Pense à ta façon de travailler avec l'IA aujourd'hui. Tu lui écris une instruction. Tu attends. Tu lis ce qu'elle a fait. Tu lui dis « maintenant corrige ça ». Tu attends encore. Tu vérifies. « Maintenant ajoute ceci ». Encore et encore. Ça marche — mais il y a un problème silencieux : le moteur de tout, c'est toi. Ton attention est le carburant. À la seconde où tu te lèves pour un café, le projet se fige.

Le déclic du loop engineering arrive quand tu te dis : « et si je n'avais pas à être là à remonter le mécanisme à chaque étape ? Et si je lui donnais un objectif et qu'elle se débrouillait seule jusqu'à l'atteindre ? ». C'est exactement ça. Un article de Firecrawl sur le sujet l'a très bien dit : avec le loop engineering, l'IA cesse d'être un collaborateur de l'autre côté du chat ; elle devient une fonction qu'un programme appelle dans une boucle.

Imagine-le comme ça

Jusqu'ici tu étais le conducteur : les deux mains sur le volant pendant tout le trajet. Le loop engineering, c'est mettre une destination dans le GPS et activer le pilote automatique : la voiture accélère, regarde la route, corrige le cap et regarde à nouveau, seule, jusqu'à l'arrivée. Tu arrêtes de conduire et tu passes à superviser le trajet.

2. La douleur : le travail manuel ne passe pas à l'échelle (et il t'épuise)

La douleur de ne pas franchir ce cap est réelle et honnête — ce n'est pas une apocalypse, c'est de l'usure. Voici les symptômes :

Signes que le travail manuel te limite

Les tâches longues (auditer tout le projet, étudier 8 concurrents, migrer 40 fichiers) te prennent des heures parce que tu les fais à la chaîne, une par une.
Si tu quittes l'ordinateur, le progrès s'arrête net. L'IA ne continue pas sans toi.
Tu répètes le même type d'instruction chaque jour et tu as l'impression d'être un opérateur de machine, pas un directeur.
Tu ne peux pas mener deux gros chantiers à la fois parce que tu n'as qu'une paire de mains et un seul chat ouvert.

Le malentendu le plus courant

Beaucoup croient qu'« automatiser l'IA » se résume à lui donner un prompt plus long. Faux. Un prompt long a toujours besoin de toi pour appuyer sur envoyer et pour vérifier. Le loop engineering, c'est autre chose : c'est que le système décide seul de continuer ou de s'arrêter, sans que tu appuies sur quoi que ce soit.

3. Le cœur : le cycle Agis → Observe → Raisonne → Recommence

Toute boucle, aussi simple ou complexe soit-elle, tourne autour des mêmes quatre étapes. Mémorise-les, car elles sont l'essence de tout :

Les 4 étapes de toute boucle

Agis — l'IA fait quelque chose (écrit du code, cherche sur le web, corrige un test).
Observe — elle lit le résultat de ce qu'elle a fait (le test est-il passé ? qu'a renvoyé la recherche ?).
Raisonne — elle compare ce résultat à l'objectif (est-ce fini ? manque-t-il quelque chose ? y a-t-il une erreur ?).
Recommence — elle décide seule si elle repart ou si c'est terminé.

La différence avec un chat normal, c'est la quatrième étape : c'est l'IA qui décide de continuer, pas toi. La boucle tourne seule jusqu'à ce que l'objectif soit atteint ou jusqu'à ce qu'elle touche une limite que tu as posée (on va voir ces limites, elles sont sacrées).

Boucle ouverte vs. boucle fermée

Il y a deux saveurs. Boucle ouverte : tu donnes un objectif et une liberté totale (« trouve tous mes concurrents et note-les ») — puissant pour explorer, mais si tes critères sont flous, le résultat sort bruité. Boucle fermée : tu balises le chemin étape par étape, avec comment vérifier chacune — plus prévisible, moins cher, meilleurs résultats. En production, on utilise presque toujours la fermée.

4. Les 3 freins sacrés (sans eux ce n'est pas une boucle, c'est une facture ouverte)

Voici la partie que PERSONNE ne te raconte et la plus importante. Une boucle qui tourne seule peut dépenser des crédits seule. L'essentiel de l'art du loop engineering n'est pas de faire itérer l'IA — c'est de l'empêcher d'itérer à l'infini et de te vider le compte. Il y a trois freins qui doivent TOUJOURS exister :

Les 3 freins qui ne peuvent jamais manquer

Plafond d'itérations — un nombre maximum de tours. « Essaie 10 fois au plus, puis arrête. »
Contrôle des changements (diff-check) — si après N tours l'IA ne change plus rien, on arrête. Elle tourne dans le vide.
Plafond de dépense — une limite de tokens ou d'argent. Quand elle est atteinte, la boucle se termine, qu'elle ait réussi ou non.

Le 4e frein que presque personne ne pose (et le plus traître)

Les trois freins du dessus contrôlent la quantité (combien de tours, combien de dépense). Mais il y a un frein de qualité qui est celui qui te sauve vraiment : la règle anti-triche. Si tu demandes à l'IA « fais passer tous les tests », le moyen le plus facile pour elle de « gagner » est… de supprimer le test, de le marquer comme ignoré, ou d'affaiblir ce qu'il vérifie. Elle franchit tes trois freins avec le drapeau vert — et ton app reste cassée. Ajoute TOUJOURS à ta boucle : « interdit de supprimer, d'ignorer (skip) ou d'affaiblir ce qui est vérifié pour feindre le succès ; corrige la cause réelle ». Ça vaut pour n'importe quel objectif, pas seulement les tests.

La phrase à te tatouer

De l'article de Firecrawl, mot pour mot : « Sans les trois freins, ce que tu fais tourner n'est pas une boucle. C'est une facture ouverte. » Avant de lancer toute boucle autonome, demande-toi : ai-je le plafond de tours, celui des changements et celui de dépense ? S'il en manque un, ne lance pas.

L'autre risque : la dette de compréhension

Quand l'IA produit du code plus vite que tu ne peux le comprendre, une brèche dangereuse s'ouvre : tu as dans ton projet des choses que tu ne comprends pas. Plus la boucle tourne vite, plus cette brèche s'élargit — sauf si quelqu'un relit les changements. C'est pour ça que le loop engineering va de pair avec le protocole C-A-R : la boucle construit, mais toi (ou un agent vérificateur) tu audites.

5. L'habitude : penser en boucles, pas en messages isolés

Le loop engineering n'est pas quelque chose que tu fais une seule fois. C'est un changement de mentalité permanent. Chaque fois que tu vas faire une tâche avec l'IA, avant d'écrire le premier prompt, demande-toi : « est-ce un message isolé, ou est-ce une boucle ? ». La plupart des grosses tâches sont des boucles déguisées en beaucoup de messages.

Les moments où tu devrais TOUJOURS penser à une boucle

Quand une tâche a un critère clair de « terminé » (tous les tests passent, 10 bugs trouvés, le document couvre tous les points).
Quand tu répètes le même cycle à la main (lance → échoue → corrige → relance).
Quand la tâche est trop grande pour une seule passe (tout auditer, tout migrer, étudier de nombreuses sources).
Quand tu veux que quelque chose se fasse pendant que tu n'es pas là (surveiller un déploiement, veiller sur un site, un contrôle quotidien).

La règle du vérificateur (le schéma au plus fort rendement)

L'astuce la plus rentable de toutes : sépare celui qui fait et celui qui relit. Un agent (ou une chaîne d'agents) fait les changements ; un autre agent, différent, les note face à tes règles et tes tests. Le vérificateur n'a pas à être plus malin — il doit juste être un autre, avec la tête froide de l'auditeur. C'est exactement ce que fait le protocole C-A-R : construire et auditer en tours séparés.

6. Comment monter ta première boucle (avec des commandes qui existent vraiment)

Voilà le plus beau : tu n'as rien de bizarre à programmer. Si tu utilises un agent de code moderne comme Claude Code, il apporte déjà les pièces montées. Ces commandes sont réelles et figurent dans sa documentation officielle :

Le kit de loop engineering dans Claude Code

/goal <condition> — le cœur de la boucle vers un objectif. Tu fixes une condition et, après chaque tour, un modèle rapide vérifie si elle est déjà remplie ; sinon, Claude enchaîne un autre tour seul, au lieu de te rendre la main. C'est le « travaille jusqu'à ce que ce soit vert ». Il faut une condition vérifiable (ex. « tous les tests passent », « git status propre »).
/loop [intervalle] [prompt] — répéter dans le temps, PAS itérer vers un objectif. Exécute un prompt à intervalle régulier (/loop 5m revoie le déploiement) ou, sans intervalle, Claude choisit lui-même le rythme. Utile pour surveiller quelque chose, pas pour « atteindre X ». Ne le confonds pas avec /goal.
/schedule — crée des routines dans le cloud : tâches programmées (chaque heure, chaque jour) qui tournent même si ton portable est fermé, ou qui réagissent à des événements GitHub.
/batch — découpe un gros travail en 5 à 30 unités en parallèle, chacune dans son propre sous-agent et son propre worktree isolé ; chacune fait sa part, lance les tests et ouvre sa propre pull request. (C'est la version industrielle de la boucle pour les migrations et les changements massifs.)

La distinction que presque personne ne comprend

Beaucoup mélangent `/goal` et `/loop` alors que ce sont des choses distinctes. `/goal` itère jusqu'à remplir une condition (c'est la boucle « travaille jusqu'à y arriver »). `/loop` répète à un intervalle (c'est le « toutes les X minutes fais ça »). Pour « corrige tous les tests » tu veux /goal. Pour « surveille le déploiement toutes les 5 min » tu veux /loop. Les confondre est l'erreur de débutant numéro un.

Donnée d'autorité · d'où ça vient

Le loop engineering n'est pas sorti de nulle part. Il vient du schéma ReAct (Reason → Act → Observe, d'un paper de 2022) qui a appris aux modèles à raisonner et agir en cycle. Puis est arrivé Reflexion, qui y a ajouté une étape d'auto-critique — l'agent se corrige lui-même. Le saut de 2026, c'est la durée : les agents sont passés de réponses de chat courtes à tourner des minutes ou des heures seuls. Le loop engineering, c'est mettre de l'ingénierie sérieuse (et des freins) sur cette autonomie.

Et les pièces de soutien qui rendent une boucle fiable existent aussi : les worktrees (claude --worktree) pour que plusieurs agents travaillent sans se marcher dessus, les skills (dossiers avec un SKILL.md) pour que l'IA ne redécouvre pas ton contexte à chaque fois, les hooks pour accrocher des actions à des moments clés, et les connecteurs MCP pour que la boucle atteigne des outils externes (Slack, GitHub, ta base de données).

Tu as déjà presque toutes les pièces dans cette série

Le meilleur : tu ne pars pas de zéro. La mémoire donne à la boucle un état qui survit entre les tours. Le RAG / le brain lui donne du contexte. Les skills encodent ton savoir. GitHub lui donne le point de retour sûr. agent-browser lui donne les yeux pour observer pour de vrai. Le loop engineering ne fait que connecter tout ça en un cycle. Tu les as tous dans cette série — à la fin je te laisse les liens directs.

7. Comment ça s'utilise vraiment : concevoir d'abord, puis invoquer la commande

Voici le détail que presque tous les tutoriels sautent, et il est CLÉ : la boucle ne démarre pas seule parce que tu lui décris la tâche. Coller un long texte disant « monte une boucle qui corrige mes tests » fait que l'IA te conçoit le plan — mais ne l'exécute PAS. Pour que l'IA se mette à itérer pour de vrai, tu dois écrire la commande explicitement (dans Claude Code, /goal ou /loop). Ce sont deux étapes : d'abord tu conçois, puis tu invoques.

La commande n'est PAS optionnelle

Si tu décris seulement la boucle en langage naturel, l'IA te répond avec le plan et s'arrête — elle attend ton feu vert. La boucle autonome ne se déclenche que lorsque tu tapes la commande (/goal … ou /loop …). Et c'est bien : ça t'oblige à approuver la conception et les freins AVANT de lâcher la machine. Conception et exécution sont séparées exprès.

Étape 1 — Conçois la boucle. Colle ceci à ton agent, en remplissant les [crochets]. Il te renverra le plan, les freins et — important — la commande exacte que tu dois taper ensuite :

Prompt pour concevoir ta première boucle autonome (avec freins)texto

Je veux monter une boucle autonome (loop engineering) pour cette tâche : [DÉCRIS LA TÂCHE, ex : "trouver et corriger tous les tests qui échouent" ou "étudier à fond mes 5 concurrents et synthétiser un rapport"].

Mon outil est : [Claude Code / Cursor / autre]. Avant de concevoir, regarde mon projet et dis-moi quelle est la commande ou le signal exact qui sert de "vérité" pour cette tâche (ex. la vraie commande de tests, ou comment se mesure "terminé"). Si tu ne le trouves pas, demande-moi.

Conçois-la avec moi en suivant le cycle Agis → Observe → Raisonne → Recommence. J'ai besoin que tu me proposes, en langage clair :

1. L'OBJECTIF : la condition exacte et VÉRIFIABLE de "terminé" (comment on saura que la boucle doit s'arrêter parce qu'elle a vraiment réussi).
2. S'IL VAUT MIEUX une boucle OUVERTE (liberté) ou FERMÉE (étapes balisées) pour cette tâche, et pourquoi.
3. LE CYCLE : ce que l'IA fait à chaque tour (agis), comment elle vérifie le résultat (observe), et comment elle décide de continuer (raisonne).
4. LA SÉPARATION : un agent qui FAIT et un autre différent qui VÉRIFIE le résultat (règle anti-triche ci-dessous incluse).
5. LES 4 FREINS, obligatoires :
   - Plafond d'itérations (nombre maximum de tours).
   - Contrôle de stagnation (arrêter si ça n'avance plus après N tours).
   - Plafond de dépense (limite de tokens ou de temps).
   - RÈGLE ANTI-TRICHE : interdit de supprimer, d'ignorer (skip) ou d'affaiblir ce qui est vérifié pour feindre le succès. Il faut corriger la CAUSE RACINE (le vrai code), pas poser un rustine qui fait taire le symptôme. Si un tour laisse PLUS de cassé qu'il ne répare, revenir en arrière sur ce tour.
6. LA COMMANDE EXACTE QUE JE DOIS TAPER MOI-MÊME pour l'exécuter (ne l'exécute pas seul). Dans Claude Code : si la tâche est "itère jusqu'à remplir une condition" utilise `/goal <condition>` ; si c'est "répète à intervalle régulier" utilise `/loop <intervalle> <prompt>`. Donne-moi la ligne déjà écrite, prête à copier, avec la condition d'arrêt et les freins inclus. Vérifie que la commande existe vraiment ; ne l'invente pas.
7. CE QUE JE PEUX SUPERVISER pendant que ça tourne, en une ligne par tour lisible même si je ne programme pas, pour ne pas tomber dans la dette de compréhension.

D'abord montre-moi UNIQUEMENT la conception complète, les 4 freins et la commande exacte à taper. N'EXÉCUTE PAS la boucle : je la déclencherai en tapant la commande quand j'approuverai la conception.

Étape 2 — Déclenche la boucle avec la commande. Quand la conception et les freins te conviennent, MAINTENANT tu tapes la commande que l'IA t'a donnée. Pour « travaille jusqu'à remplir une condition » (le cas le plus courant), dans Claude Code c'est /goal. Par exemple, pour corriger des tests, ça donnerait quelque chose comme :

Claude Code

/goal todos los tests pasan (corre la suite completa), sin borrar ni omitir ningún test, máximo 15 vueltas

À partir de là, l'IA lance, observe le résultat, raisonne et retente seule après chaque tour, jusqu'à ce qu'un modèle rapide confirme que la condition est remplie (ou jusqu'à toucher un frein). Si ce que tu veux c'est répéter quelque chose à intervalle régulier (surveiller un déploiement, par exemple) au lieu d'itérer vers un objectif, là la commande est /loop :

Claude Code

/loop 5m revisa si el despliegue terminó y avísame qué pasó

La règle d'or des deux étapes

Tu conçois en langage naturel (étape 1) → tu relis le plan et les freins → toi tu tapes la commande (étape 2). Jamais l'inverse. Cette séparation est ta sécurité : aucune boucle ne démarre sans que tu aies vu le plan et appuyé sur le bouton. Cinq minutes de relecture t'épargnent une facture ouverte.

8. Les chemins les plus faciles · ce que fait l'IA et ce que tu décides, toi

Pour que ça ne se complique pas, voici ce que ton agent de code peut faire tout seul via le chat, et ce qui reste ta décision :

Ce que l'AGENT fait pour toi (via le chat)

Concevoir la boucle complète : l'objectif, le cycle, les freins — et te donner la commande exacte à taper.
Une fois que TOI tu déclenches la commande (/goal ou /loop), enchaîner les tours seul : agir, observer, raisonner et retenter jusqu'à remplir la condition ou toucher un frein.
Lancer des agents en parallèle avec /batch pour les grosses tâches (auditer, étudier, migrer).
Vérifier son propre travail dans un tour séparé (le schéma du vérificateur).
Créer la skill (SKILL.md) qui encode le contexte pour que la boucle soit reproductible.

Ce que TOI tu décides (ne le délègue pas)

L'OBJECTIF et quand on considère que c'est « terminé » — c'est ça qui définit la qualité du résultat.
Taper la commande qui déclenche la boucle (/goal … ou /loop …) : elle ne démarre pas seule, c'est toi qui l'allumes après avoir vu le plan.
Les 4 freins : combien de tours, quand arrêter pour stagnation, combien dépenser, et la règle anti-triche.
Relire les changements produits (pour ne pas accumuler de dette de compréhension).
Le critère de qualité / la grille — parce qu'une boucle multiplie le bon critère que tu y mets, et aussi le mauvais.

Dans NeuralOS

La philosophie du loop engineering est celle qui anime de l'intérieur les équipes d'agents de NeuralOS : des agents qui reçoivent un objectif et travaillent vers lui, avec un agent qui coordonne et d'autres qui exécutent ou vérifient. Aujourd'hui tu le vois dessiné dans l'interface (la vision déjà tangible) ; le moteur autonome complet fait partie de la roadmap du backend. L'idée, c'est que toi tu poses l'objectif et le critère — le système fait les tours.

Résumé · ta checklist de loop engineering

Avant de lancer toute boucle, confirme

J'ai un objectif avec une condition de « terminé » claire.
J'ai conçu le cycle Agis → Observe → Raisonne → Recommence.
J'ai décidé si c'est une boucle ouverte ou fermée (en production, presque toujours fermée).
J'ai les 3 freins : plafond d'itérations + contrôle des changements + plafond de dépense.
J'ai défini qui fait et qui vérifie (tours séparés).
Je vais relire les changements pour ne pas accumuler de dette de compréhension.
J'ai mis mon meilleur critère dans la grille — parce que la boucle va le multiplier.

La conclusion de la série

Si tu es arrivé jusqu'ici en suivant la série, tu as déjà le système complet : mémoire, GitHub, RAG, le brain, graphify, C-A-R, sécurité, skills, agent-browser… et maintenant la boucle qui les relie. Tu as arrêté de piloter l'IA à la main : maintenant tu lui poses un objectif, tu lui donnes du bon critère et des freins, et tu la laisses travailler. Ça, c'est construire comme un studio, pas comme un ouvrier.

Article original · Loop Engineering (Firecrawl)La source qui a donné son nom à la méthodologie. Lecture recommandée pour approfondir les schémas de production.Le protocole C-A-R · construire sans bugsLe schéma du vérificateur en action : construire et auditer en tours séparés. Le compagnon parfait d'une boucle.Donne des yeux à ton IA · agent-browserL'étape « Observe » du cycle a besoin de vrais yeux : que l'IA vérifie dans le navigateur, pas à l'aveugle.

#loop engineering#agents autonomes#automatisation#avancé#claude code