Tous les patterns vus jusqu’ici sont des workflows : vous décidez la route, le modèle remplit les étapes. La boucle d’agent inverse tout. Vous donnez un objectif, des outils, et le modèle décide lui-même quoi faire, le fait, regarde le résultat, et décide à nouveau — jusqu’à ce que le travail soit fini. C’est ce qui anime les agents de code comme celui de Copilot ou Claude Code.
L’analogie
Le GPS, pas l’itinéraire imprimé. Un workflow, c’est la feuille de route imprimée : parfaite tant que la réalité colle au plan. Un agent, c’est le GPS : il regarde où il est vraiment après chaque virage et recalcule. Mauvaise sortie ? Pas de panique — il observe et recalcule l’itinéraire.
Le principe
flowchart TB
GOAL([objectif]) --> T["LLM : réfléchit & choisit la prochaine action"]
T -->|appel d'outil| X[exécute l'outil]
X --> O[observe le résultat]
O --> T
T -->|fini| OUT([réponse finale])
- À chaque tour, le modèle voit l’historique complet des actions et résultats, et choisit le coup suivant — un appel d’outil ou une réponse finale.
- L’environnement répond : tests qui échouent, messages d’erreur, contenus de fichiers. C’est cet ancrage qui garde la boucle honnête (voir grounding).
- Le harness impose le cadre : outils disponibles, permissions, conditions d’arrêt, budget.
Un exemple concret
« Répare le test qui échoue dans ce dépôt » :
1. réfléchit → « voyons ce qui échoue » → lance : npm test
2. observe → « TypeError dans cart.js:42 »
3. réfléchit → « lisons ce fichier » → lit : cart.js
4. observe → trouve un prix null possible
5. réfléchit → « corrige + vérifie » → édite, puis npm test
6. observe → tout au vert → répond : « réparé, voici le diff »
Personne n’a scénarisé ces six étapes — un autre bug aurait produit un autre chemin. C’est exactement l’idée.
Quand l’utiliser
- Le chemin est imprévisible : il dépend de ce que chaque étape révèle (débogage, recherche, changements multi-fichiers).
- L’environnement fournit un retour vérifiable auquel la boucle peut réagir — tests, compilateurs, API.
- La tâche justifie le coût : chaque tour renvoie tout l’historique en tokens d’entrée.
Quand l’éviter
- Les étapes sont connues d’avance → un workflow est moins cher, plus rapide et plus prévisible.
- Aucun bon signal de retour n’existe : un agent qui ne peut pas se vérifier est une marche aléatoire très sûre d’elle.
Le piège classique
La boucle emballée. Un agent coincé à réessayer la même mauvaise idée peut brûler des tokens pendant des heures. Fixez toujours des budgets et des conditions d’arrêt (tours max, coût max, timeouts) — et pour tout ce qui est irréversible, ajoutez un humain dans la boucle.