La boucle agentique en pratique
Le cycle observe-décide-agit d'un agent IA : rôle du feedback et différence entre boucle implicite et explicite (Closed-Loop Prompting).
Le cycle observe-décide-agit
Les 3 acteurs de la boucle
La boucle agentique met en jeu trois acteurs distincts :
| Acteur | Rôle |
|---|---|
| Le LLM | Décide quoi faire à chaque tour. Il ne fait rien lui-même. |
| Le runtime | Exécute les actions demandées par le LLM (lire un fichier, lancer un build, écrire du code). |
| L’utilisateur | Donne l’intention initiale et, selon le mode, valide les actions intermédiaires. |
À chaque tour : le modèle reçoit le contexte disponible (instructions, historique, résultats d’outils), décide d’une action (appeler un outil ou répondre), le runtime exécute cette action, puis le résultat est renvoyé au modèle pour le tour suivant.
Point clé : La boucle s’arrête quand le modèle répond sans appeler d’outil, ou quand une limite est atteinte (nombre de tours, budget de tokens).
Le feedback : moteur de la boucle
Pourquoi le feedback est déterminant
Ce qui rend la boucle utile, c’est le feedback. Chaque résultat d’outil (sortie console, message d’erreur, résultat de test) est réinjecté dans le contexte du tour suivant. L’agent peut donc se corriger sans intervention humaine.
Exemples de feedback exploitable :
- Build échoué : le message d’erreur du compilateur indique la ligne et le type attendu vs obtenu.
- Test rouge : l’assertion échouée montre l’écart entre attendu et obtenu.
- Linter : les warnings pointent les violations de style ou les erreurs courantes.
Point clé : Plus le feedback est structuré et lisible, mieux l’agent se corrige. Un message cryptique comme « Erreur. » sans détail ni numéro de ligne ne donne rien d’actionnable. Un système de types fort (C#, TypeScript) fournit un feedback précis et automatique — c’est un des 12 Leverage Points (LP6 Types).
Piège courant : Un agent sans feedback structuré finit par deviner. C’est le meilleur moyen d’obtenir du code qui compile mais qui ne fait pas ce qu’on veut (drift silencieux).
Boucle implicite vs boucle explicite
Boucle implicite
Par défaut, la boucle est implicite : l’agent décide seul s’il doit relancer un build ou passer à autre chose. Aucune garantie de vérification.
Exemple — prompt : « Implémente la méthode CalculatePrice. »
L’agent écrit le code, peut-être lance un build, peut-être pas.
Boucle explicite (Closed-Loop Prompting)
On rend la boucle explicite en précisant dans le prompt les étapes de vérification et de correction.
Exemple — prompt : « Implémente la méthode CalculatePrice, puis lance dotnet test. Si des tests échouent, corrige et relance. Répète jusqu’à ce que tous les tests passent, ou après 3 tentatives maximum. »
Point clé : La boucle explicite est un pattern de prompting, pas une feature d’outil. Elle fonctionne dans tout agent qui a accès à un outil de vérification (build, test, lint). C’est le principe du Closed-Loop Prompting : on inscrit la logique de vérification et de correction directement dans le prompt.
Quand la boucle déraille
Trois modes d’échec principaux
| Mode d’échec | Symptôme | Cause probable |
|---|---|---|
| Boucle infinie | L’agent retente la même correction sans fin | Feedback ambigu ou erreur non reproductible (test flakey) |
| Arrêt prématuré | L’agent répond sans avoir vérifié son travail | Pas de consigne de vérification dans le prompt |
| Drift silencieux | Le code compile et les tests passent, mais le résultat ne correspond pas à l’intention | Les tests ne couvrent pas le cas demandé |
Piège courant : Quand l’agent tourne en boucle sans progresser, le problème est rarement le modèle. C’est presque toujours un problème de contexte (information manquante) ou de prompt (consigne ambiguë). Diagnostic : prompt et contexte d’abord, modèle en dernier.
Bonnes pratiques pour piloter la boucle
- Donner une condition d’arrêt claire : « Termine quand tous les tests passent » ou « Arrête après 3 tentatives et liste les erreurs restantes. »
- Inclure une étape de vérification : build, test, ou lint dans le prompt.
- Limiter le nombre de tours : un budget max évite les boucles infinies et le gaspillage de tokens.
- Fournir du feedback structuré : si un outil custom renvoie des erreurs, formater le message pour qu’il soit actionnable.
Point clé : La qualité du résultat dépend autant de la boucle (feedback, vérification, limites) que du modèle lui-même. La clause d’arrêt après N tentatives est un des principes du ZTE (Zero Trust Execution) : échec explicite plutôt que boucle infinie.
Remonte relire la fiche memo ci-dessus en pretant attention aux points rates, puis clique sur « Recommencer » pour retenter.