En bref
Le pattern Reflection permet à un agent IA d’évaluer son propre output et de le corriger de manière itérative, sans intervention humaine à chaque cycle. Dans sa version la plus robuste — le modèle Producer-Critic — deux rôles distincts sont attribués : un agent génère, un autre critique. Cette séparation élimine un biais structurel de l’auto-révision. La boucle n’est pas infinie : des critères d’arrêt explicites régulent le nombre d’itérations.
Le problème : pourquoi un agent ne peut pas bien se relire lui-même
Imaginez un écrivain qui termine son manuscrit. Quand il le relit immédiatement, il “voit” ce qu’il voulait écrire — pas nécessairement ce qu’il a écrit. C’est pourquoi les éditeurs existent : un regard extérieur, frais, qui découvre le texte sans avoir partagé le processus de création. Le pattern Producer-Critic transpose cette pratique millénaire à l’IA agentique.
Un LLM qui génère un texte, puis qu’on invite immédiatement à le corriger, souffre d’un biais connu : il tend à valider ce qu’il vient de produire. Ce n’est pas un dysfonctionnement — c’est une propriété du processus de génération. Le modèle qui a produit la réponse a déjà mobilisé certains chemins d’inférence ; relire avec le même modèle dans le même état de contexte reproduit souvent les mêmes angles morts.
Ce biais est analogue au phénomène de relecture chez les humains : un auteur relit son texte et voit ce qu’il voulait écrire, pas ce qu’il a réellement écrit.
La réflexion (Reflection), telle que formalisée dans la littérature sur les agents, s’attaque à ce problème. Elle introduit une boucle de feedback structurée : générer → évaluer → corriger → itérer si nécessaire.
Le modèle Producer-Critic
Le Producer-Critic est la forme la plus aboutie du pattern Reflection. Il repose sur une séparation explicite des rôles :
| Rôle | Fonction | Biais éliminé |
|---|---|---|
| Producteur (Producer) | Génère la réponse initiale selon la tâche | — |
| Critique (Critic) | Évalue l’output du producteur avec une perspective fraîche | Biais d’auto-complaisance |
Gulli (2025) formule ce principe : “The Critic agent approaches the output with a fresh perspective, dedicated entirely to finding errors and areas for improvement.”
Le critique n’est pas un vérificateur orthographique. Il évalue selon des critères structurés définis à l’avance : exactitude factuelle, cohérence interne, complétude, respect des instructions. Ces critères doivent être explicites — un critique générique (“est-ce correct ?”) est moins efficace qu’un critique avec une grille de contrôle formalisée.
En pratique, les deux rôles peuvent être tenus par le même modèle de base avec des prompts différents, ou par deux modèles distincts. La séparation est logique, pas nécessairement physique.
En clair : le critique n’est pas un correcteur orthographique — c’est un évaluateur muni d’une grille explicite (exactitude, cohérence, complétude, instructions respectées). Demander “est-ce correct ?” produit moins de valeur que demander “vérifie ces 5 critères précis sur l’output”.
La boucle de feedback : structure et mécanique
La boucle réflexive suit un cycle en quatre temps :
- Exécution — le producteur génère une première version
- Évaluation — le critique analyse l’output selon les critères définis
- Affinage — le producteur intègre la critique et produit une version révisée
- Décision d’itération — continuer ou arrêter selon le critère de qualité atteint
À chaque tour, l’historique conversationnel s’enrichit : tâche, output intermédiaire, critique. Gulli souligne que cette accumulation de contexte améliore la qualité des itérations successives — l’agent évalue son output non seulement en isolation, mais en tenant compte des cycles précédents.
Critères d’arrêt : le problème des boucles infinies
Sans condition d’arrêt explicite, une boucle réflexive peut tourner indéfiniment. Chaque itération consomme des tokens, de la latence et du budget d’inférence. Deux mécanismes complémentaires régulent cela :
Critère de satisfaction : un signal explicite indique que la qualité cible est atteinte. En code, cela peut prendre la forme d’un token spécial (CODE_IS_PERFECT) que le critique émet quand aucune correction n’est nécessaire. Pour du texte, une note seuil sur les critères définis.
Nombre maximum d’itérations : un garde-fou indépendant de la qualité. Même si le critique continue d’identifier des imperfections, le processus s’arrête au bout de N cycles. Ce plafond prévient les boucles de sur-raffinement où chaque itération produit des gains marginaux décroissants à coût croissant.
Les deux mécanismes doivent coexister. Un critère de satisfaction seul peut être compromis si le critique est mal calibré ; un plafond seul ignore la qualité réelle.
En clair : sans plafond explicite (typiquement 3-5 itérations), une boucle Producer-Critic peut “polir” un output indéfiniment, chaque itération apportant 0,1 point de qualité pour 100 % de coût supplémentaire. Le pattern n’est rentable que si l’amélioration marginale dépasse le coût marginal — la décroissance est rapide après 3 cycles.
Self-reflection vs. Producer-Critic : quand utiliser quoi
Il existe une variante plus légère : la self-reflection, où un agent unique évalue sa propre sortie via une seconde invocation LLM avec un prompt de critique. C’est moins coûteux en infrastructure qu’un système à deux agents distincts.
| Approche | Avantage | Limite |
|---|---|---|
| Self-reflection | Simple, moins de tokens, 1 seul modèle | Biais d’auto-révision partiellement présent |
| Producer-Critic | Perspective réellement fraîche, biais réduit | Coût double en appels LLM, orchestration plus complexe |
La self-reflection convient aux cas où la qualité initiale est déjà élevée et où l’on cherche un affinage de surface (formulation, format). Le Producer-Critic est préférable quand la tâche est à fort enjeu, quand les erreurs sont difficiles à détecter en contexte proche, ou quand le domaine exige une évaluation selon des critères spécialisés (juridique, médical, technique).
Couplage avec la mémoire
L’efficacité de la réflexion dépend de la capacité de l’agent à tenir compte des cycles précédents. Un agent sans mémoire de session recommence chaque itération depuis zéro : il peut reproduire les mêmes erreurs qu’il vient de corriger.
Gulli note que “la conservation de l’historique conversationnel fournit un contexte crucial pour la phase d’évaluation, permettant à l’agent d’évaluer son output non pas en isolation, mais dans le cadre des interactions précédentes.”
En pratique, cela implique que la fenêtre de contexte croît à chaque itération. Sur des boucles longues ou des tâches complexes, cette expansion peut atteindre les limites du modèle ou dégrader la qualité de l’évaluation (l’agent critique “se noie” dans l’historique). C’est une contrainte opérationnelle directe.
Applications concrètes
Génération de code : le producteur génère une fonction, le critique vérifie la logique, les cas limites et la conformité aux spécifications. Plusieurs itérations peuvent corriger des bugs non détectés au premier passage.
Rédaction structurée : le producteur génère un rapport, le critique vérifie la cohérence argumentaire, la complétude et l’absence de contradictions.
Extraction d’information : le producteur extrait des données d’un document, le critique vérifie la couverture et l’exactitude en relisant le document source.
Gestion d’exceptions : couplée à la détection d’erreurs, la réflexion permet à un agent de diagnostiquer une défaillance et de générer une stratégie de récupération.
Forces et limites
Ce que le pattern apporte :
- Amélioration mesurable de la qualité sur les tâches complexes
- Détection d’erreurs que l’évaluation directe manque
- Adaptable : fonctionne avec un modèle unique ou des modèles spécialisés
- Composable avec d’autres patterns (planification, gestion d’exceptions)
Ce que le pattern ne résout pas :
- Le critique lui-même peut avoir des angles morts ou être mal calibré
- Chaque itération ajoute de la latence et du coût — le gain marginal décroît
- La fenêtre de contexte croissante peut dégrader la cohérence sur les longues boucles
- Si les critères d’évaluation sont mal définis, le critique optimise pour les mauvaises métriques
- La sur-correction existe : un critique trop sévère peut dégrader une réponse initialement correcte
Ce qu’il faut retenir
- La réflexion introduit une boucle d’auto-évaluation itérative : générer, critiquer, affiner.
- Le modèle Producer-Critic sépare génération et évaluation pour réduire le biais d’auto-révision ; la perspective fraîche du critique est sa valeur principale.
- Des critères d’évaluation explicites et structurés sont nécessaires — un critique sans grille de contrôle est peu fiable.
- Les critères d’arrêt (signal de qualité + plafond d’itérations) sont obligatoires pour éviter les boucles infinies et la sur-optimisation à coût croissant.
- Le coût du pattern est réel : latence accrue, tokens supplémentaires, fenêtre de contexte qui croît. À peser contre le gain de qualité attendu.