Loop Engineering : les deux types de boucles qui font tourner vos agents IA en production

Le Prompt Engineering a eu son moment. Pendant des mois, la recette semblait simple : écrivez une instruction précise, obtenez un résultat correct. Mais en production, cette approche montre ses limites.

Un agent qui agit en silo, sans boucle de rétroaction, sans capacité à détecter ses propres erreurs et à les corriger, n'est pas un agent — c'est un script glorifié.

La vraie rupture technique de 2026 s'appelle le Loop Engineering : au lieu d'écrire des prompts vous-même, vous concevez des systèmes qui font le prompting pour vous. Vous définissez l'objectif final. L'agent trouve les étapes, se corrige, contourne les obstacles et boucle jusqu'à ce que le travail soit fait.

Le curseur se déplace : ce n'est plus la qualité de vos instructions qui compte, mais la qualité de l'architecture qui les orchestre.

Les deux familles de boucles

Toutes les boucles ne se ressemblent pas. En production, on distingue deux grandes catégories qui répondent à des problèmes fondamentalement différents.

Boucles déterministes

Certaines tâches ont un "fini" clair. Les tests passent. Le code compile. Le nombre atteint une valeur cible. Le succès est mesurable par une règle binaire : ça marche ou ça ne marche pas.

Dans une boucle déterministe, l'agent sait exactement à quoi ressemble "done". Il exécute une action, vérifie le résultat via un système externe (suite de tests, vérification de compilation, script de validation), détecte l'échec, corrige, et recommence. Le cycle s'arrête quand tous les contrôles passent.

La clé ici est la vérification externe. Ce n'est pas l'agent qui décide si son travail est bon — c'est un mécanisme impartial qui tranche. Tests unitaires, linting, validation de schéma, vérification de conformité. Plus la vérification est stricte, plus la boucle est fiable.

Boucles non-déterministes

Mais toutes les tâches ne se prêtent pas à une vérification automatique. Comment testez-vous objectivement si une interface utilisateur est "belle" ? Si un texte est "convaincant" ? Si une analyse stratégique est "pertinente" ?

Ces tâches requièrent du jugement humain. Ou plutôt : une approximation mécanique du jugement humain.

La solution qui émerge est l'architecture adversariale. Un agent constructeur produit le résultat. Un second agent — idéalement un modèle différent, avec des forces complémentaires — joue le rôle de vérificateur. Le vérificateur possède un "skill de détection de qualité" qui s'améliore avec le temps en intégrant les retours de chaque cycle.

Le constructeur propose. Le vérificateur oppose. Chaque itération affine le résultat. La boucle ne s'arrête pas quand une règle binaire est satisfaite, mais quand le vérificateur juge le seuil de qualité atteint.

Les 6 composants d'une boucle bien construite

Une boucle solide ne s'improvise pas. Voici les pièces qui doivent être explicitement conçues :

1. Gestion de contexte

Ce qui entre dans le contexte à chaque tour. Le piège classique : les prompts système initiaux se font enterrer par les sorties d'outils récentes au fil de la conversation. Sans nettoyage ou priorisation du contexte, l'agent finit par oublier sa mission initiale.

2. Feedback de qualité

Sorties de tests, captures d'écran, messages d'erreur, logs — quelle que soit sa forme, le feedback est ce que l'agent lit pour décider de son prochain mouvement. La qualité du feedback détermine la qualité de la correction.

3. Portes de vérification

Des points de contrôle qui traduisent le feedback en verdict clair. La vérification doit être binaire ou scalaire, jamais ambiguë. "Test passed: true/false" plutôt que "le résultat semble correct".

4. Condition d'arrêt

La règle explicite qui dit à la boucle de s'arrêter. C'est l'élément le plus souvent oublié. Sans condition d'arrêt explicite, l'agent s'arrête trop tôt (parce qu'il croit avoir fini) ou ne s'arrête jamais (parce qu'il trouve toujours quelque chose à améliorer). Cela s'écrit en début de session : "Tu t'arrêtes quand les tests passent" ou "Tu t'arrêtes après 5 itérations maximum".

5. Gestion d'erreur

Les appels d'outils échouent. Les APIs timeout. Les fichiers sont introuvables. Une boucle robuste spécifie ce qui se passe dans chaque cas : réessayer, escalader, ou abandonner proprement sans laisser un état cassé.

6. Gestion d'état

Le contexte d'une fenêtre ne peut pas tout contenir. Pour les tâches longues, l'état doit être persisté dans des fichiers externes — logs, fichiers de suivi, base de données légère — que l'agent lit et écrit à chaque cycle. Cela permet de reprendre une session interrompue sans tout réinitialiser.

Le pattern adversarial en pratique

L'architecture adversariale mérite qu'on s'y attarde. C'est probablement le pattern le plus sous-estimé du Loop Engineering.

Le principe : deux agents avec des personnalités complémentaires. L'un créatif, orienté production. L'autre analytique, orienté critique. Et surtout : des modèles différents, pour éviter que le vérificateur ne reproduise les mêmes angles morts que le constructeur.

Ce qui rend ce pattern puissant, c'est que le skill de détection du vérificateur n'est pas statique. Chaque cycle d'évaluation lui apprend quelque chose. S'il identifie une nouvelle catégorie d'erreur récurrente, il met à jour son référentiel de qualité. La boucle devient ainsi un système apprenant, pas un simple automate.

Le coût des boucles

Soyons directs : les boucles coûtent cher en tokens. Chaque itération consomme du contexte, des appels API, du temps d'exécution.

La règle est simple : plus de tokens disponibles = meilleurs résultats. Mais cela ne signifie pas qu'il faut boucler systématiquement. La question à se poser avant de concevoir une boucle est : "Est-ce que le gain en qualité justifie le coût supplémentaire ?"

Pour une tâche triviale, une boucle est un gaspillage. Pour une livraison client ou un déploiement critique, c'est un investissement indispensable.

Le Loop Engineering, c'est choisir ses batailles — et concevoir des systèmes qui gagnent celles qui comptent.