Loop engineering : ne plus prompter l’IA, concevoir sa boucle

Quand je travaille avec Claude Code, le moment le plus coûteux n’est pas toujours celui où l’IA écrit du code. C’est celui où je dois lui expliquer, une fois de plus, ce qu’elle doit faire ensuite : relancer les tests, regarder l’erreur, corriger le fichier, vérifier que rien d’autre n’est cassé.

Pendant longtemps, j’ai traité chaque étape comme un nouveau prompt. Puis j’ai commencé à regarder le problème autrement : si je connais l’objectif, les outils disponibles et la façon de vérifier le résultat, pourquoi est-ce que je dois encore rédiger chaque instruction à la main ?

Le problème : l’IA attend toujours le prochain prompt

Le workflow classique ressemble à ceci :

Moi → Claude → résultat → moi → nouveau prompt → Claude...

Je demande de chercher les bugs. Claude trouve un problème. Je lui demande de le corriger. Il modifie le code. Je lui demande de relancer les tests. Un test échoue. Je lui demande de regarder pourquoi. Et ainsi de suite.

Ce fonctionnement marche, mais il fait de l’humain le moteur de chaque transition. L’IA sait produire une action ; elle ne sait pas nécessairement quelle action vient après, ni à quel moment elle peut considérer le travail comme terminé.

Le problème n’est donc pas seulement la qualité du prompt. C’est l’absence de processus entre deux prompts.

Prompt engineering vs loop engineering

Le prompt engineering cherche à formuler la meilleure demande possible. Le loop engineering cherche à définir le système qui va générer les demandes suivantes selon les résultats obtenus.

Prompt engineering :
Toi → Claude → résultat → toi → nouveau prompt

Loop engineering :
Toi → objectif + règles + validations
                 ↓
       Claude → action → test → correction
           ↑                       ↓
           └────── nouvel essai ───┘

La différence est importante. Dans le premier modèle, tu pilotes Claude étape par étape. Dans le second, tu conçois une boucle qui sait quoi vérifier et comment réagir lorsque la vérification échoue.

La boucle minimale

Une boucle d’ingénierie n’a pas besoin d’être compliquée. Elle doit simplement répondre à cinq questions :

1. Quel est l’objectif ? Une condition de réussite observable.
2. Quelles actions sont autorisées ? Les outils, les fichiers et les commandes disponibles.
3. Comment vérifier le résultat ? Tests, lint, build, navigateur, capture d’écran ou revue.
4. Que faire en cas d’échec ? Lire l’erreur, choisir une cause, modifier le minimum, puis recommencer.
5. Quand s’arrêter ? Succès, limite d’itérations ou décision humaine nécessaire.

Cela donne la boucle générale utilisée par les agents :

Rassembler le contexte
        ↓
Effectuer une action
        ↓
Vérifier le résultat
        ↓
Réessayer ou terminer

La partie la plus souvent oubliée est la vérification. Sans elle, on n’a pas une boucle : on a une suite d’actions générées par une IA qui espère avoir raison.

Un exemple concret : fiabiliser une application vibe-codée

Supposons que je veuille terminer une application générée rapidement avec Lovable, Cursor ou Claude Code. Je pourrais écrire :

Cherche les bugs.
Corrige le formulaire.
Relance les tests.
Corrige le nouveau problème.

C’est compréhensible, mais ce n’est pas encore un workflow autonome. Je préfère définir un contrat de boucle :

Objectif :
Tous les tests passent et aucune erreur ESLint ne subsiste.

À chaque cycle :
1. Lire les erreurs actuelles.
2. Sélectionner une seule cause racine.
3. Modifier le minimum de code nécessaire.
4. Exécuter les tests concernés.
5. Vérifier qu’aucune régression n’a été introduite.
6. Consigner le changement dans PROGRESS.md.
7. Recommencer si une validation échoue.

Arrêt :
- les tests et le lint réussissent ;
- après 15 cycles ;
- ou lorsqu’une décision fonctionnelle humaine est nécessaire.

La consigne ne dit pas seulement quoi coder. Elle décrit le comportement attendu de l’agent pendant toute la durée du travail.

Ce que cela change pour le développeur

Le développeur ne disparaît pas de la boucle. Son rôle se déplace.

• Il définit l’objectif au lieu de dicter chaque geste.
• Il choisit les critères d’acceptation au lieu de se contenter d’un résultat plausible.
• Il fournit les outils qui permettent à l’IA de vérifier son travail.
• Il fixe les limites et les décisions qui restent humaines.
• Il conserve une mémoire du travail pour la prochaine session.

On se rapproche d’un mélange entre CI/CD, tests automatisés, gestion de projet et supervision d’agent. Le bon livrable n’est plus seulement du code : c’est du code accompagné de preuves qu’il répond à la condition de réussite.

La boucle ne remplace pas le jugement

Une boucle peut vérifier qu’un test passe. Elle ne peut pas décider seule si le test mesure le bon comportement. Elle peut réduire le nombre d’erreurs ESLint. Elle ne sait pas si la fonctionnalité reste compréhensible pour un utilisateur.

En une phrase

Le prompt engineering consiste à bien demander une tâche. Le loop engineering consiste à construire un système qui poursuit, vérifie et corrige cette tâche jusqu’à un résultat démontrable.

Dans la documentation actuelle de Claude Code, ce principe apparaît notamment avec /goal, qui maintient une session active jusqu’à ce qu’une condition de réussite soit satisfaite. C’est une commande, mais surtout une nouvelle manière de penser le travail avec l’IA.