Le pattern Reflexion : des agents qui apprennent de leurs erreurs

Le pattern Reflexion est une architecture d'agent dans laquelle un agent LLM réfléchit systématiquement à ses propres tentatives passées et s'améliore ainsi. Au lieu d'une réponse unique, l'agent enchaîne plusieurs tentatives : un Actor produit une solution, un Evaluator l'évalue, et un modèle de Self-Reflection rédige une critique verbale à partir de l'évaluation et de l'historique. Cette critique est stockée dans une mémoire tampon et oriente la tentative suivante. Point remarquable : aucun poids du modèle n'est modifié. L'amélioration est purement verbale.

La méthode remonte à l'article de Shinn, Cassano, Berman, Gopinath, Narasimhan et Yao : Reflexion: Language Agents with Verbal Reinforcement Learning (arXiv:2303.11366, mars 2023, NeurIPS 2023). Ce fut la première démonstration largement citée que l'analyse d'erreurs verbalisée par un LLM lui-même constitue un signal d'apprentissage plus fort pour l'amélioration en contexte qu'une simple récompense numérique.

L'essentiel en trois phrases

• Ce que c'est : une boucle Actor, Evaluator et Self-Reflection avec mémoire épisodique. L'agent apprend de ses erreurs en contexte sur plusieurs tentatives, sans fine-tuning.
• Quand c'est rentable : pour les tâches itératives avec un signal de vérification clair et automatisable, comme la génération de code avec tests unitaires. Le taux de réussite y progresse de façon mesurable.
• Où est la limite : coûts élevés (de l'ordre de 10 à 30 fois un appel CoT), exécution strictement séquentielle, et inutilisable sans Evaluator fiable. Ce n'est pas un substitut à un véritable entraînement.

Comment fonctionne la boucle Reflexion

Le pattern se compose de trois éléments qui interagissent en boucle :

1. Actor : produit la solution ou le cheminement qui y mène. C'est généralement lui-même un agent ReAct ou Chain-of-Thought.
2. Evaluator : évalue la tentative. L'évaluation peut être binaire (réussi/échoué), scalaire ou assurée par une suite de tests externe.
3. Modèle de Self-Reflection : transforme l'évaluation et l'historique en feedback verbal : un paragraphe de critique en langage naturel. Ce texte est stocké dans une mémoire tampon épisodique.

À la tentative suivante, le texte de réflexion est placé en tête du contexte de l'Actor. La « mise à jour de la politique » est donc purement verbale : aucun poids ne change. La mémoire reste volontairement petite, on conserve généralement une à trois réflexions.

Le déroulement en bref :

```
Tentative_k: Actor → Evaluator → Self-Reflect → [ajouter à la mémoire]
Tentative_k+1: l'Actor voit la mémoire → nouvelle tentative
... jusqu'au succès ou au nombre max. de tentatives
```

L'avantage conceptuel par rapport à l'apprentissage par renforcement classique : le RL standard a besoin de nombreux échantillons et d'un fine-tuning coûteux pour apprendre du feedback. Reflexion apprend en contexte en quelques tentatives, ce qui est moins cher et plus rapide à mettre en place de plusieurs ordres de grandeur.

Quand le pattern Reflexion augmente le taux de réussite

Le bénéfice dépend entièrement de la qualité du signal de l'Evaluator. L'exemple le mieux documenté est la génération de code, parce qu'il y existe un oracle automatique : les tests unitaires.

La configuration idéale pour Reflexion est donc clairement définie : la tâche est itérative, une tentative ratée peut être relancée à faible coût, et il existe un signal de vérification automatisable. C'est le cas de la génération de code et de la correction de bugs, des tâches aux résultats intermédiaires vérifiables et des environnements textuels de recherche et d'action comme ALFWorld. Dans la matrice de décision de la recherche sous-jacente, la combinaison « Reflexion + ReAct » figure explicitement pour les agents de génération de code et de correction de bugs, avec la mention : nécessite des tests unitaires comme oracle.

Les limites : coûts, raisonnements fallacieux et pas de véritable apprentissage

Reflexion ne fonctionne pas tout seul. Ses principales faiblesses, toutes attestées par l'article et par la pratique :

• Le cas MBPP (section 4.3 de l'article) : sur MBPP, Reflexion est passé sous la référence GPT-4, parce que les tests unitaires qu'il avait générés lui-même affichaient un taux élevé de faux positifs. L'agent déclarait la tentative réussie trop tôt. C'est la mise en garde canonique contre l'hypothèse selon laquelle « Reflexion améliore toujours les performances ».
• Réflexions confabulées : si le modèle diagnostique mal la raison de son échec, la tentative suivante hérite de la mauvaise correction. L'autocritique peut donc aussi égarer l'agent.
• Reward hacking : l'agent peut apprendre à duper l'Evaluator au lieu de résoudre la tâche réelle.
• Réflexions vagues sans oracle : en écriture créative ou en recherche ouverte, il manque un signal de vérification clair. Les réflexions se réduisent alors à des platitudes générales.
• Coûts et latence : par tentative, environ une exécution ReAct complète plus un appel à l'Evaluator et un autre à la Self-Reflection, multiplié par K tentatives. Les tentatives sont forcément séquentielles, car chacune a besoin de la réflexion précédente. Les cas d'usage en temps réel sont généralement exclus.

Le point conceptuel fondamental pour les décideurs : Reflexion n'est pas un véritable apprentissage. Aucun poids ne change, ce qui a été « appris » vit dans la fenêtre de contexte de l'épisode en cours. Un savoir durable n'apparaît que si l'on persiste les réflexions en externe.

Comparaison des coûts

Les valeurs suivantes sont indicatives (ordres de grandeur), synthétisées à partir des données de l'article et de retours de terrain. Elles ne remplacent pas une mesure sur ta propre charge de travail.

Reflexion se situe donc délibérément dans le haut de la fourchette de coûts. Si tu l'utilises sans plafond strict d'itérations, tu risques de voir la boucle faire exploser les coûts.

Exemple pratique : un agent de code qui se corrige lui-même

Un scénario concret, tiré du domaine d'application documenté. Une agence doit construire un agent qui, à partir d'une description de fonction, livre du code Python exécutable. Le pseudocode de la boucle Reflexion :

```text
tentative = 0
réflexions = []
tant que tentative < MAX_TENTATIVES (p. ex. 3):
code = Actor.générer(tâche, contexte=réflexions) # Actor
résultat = Evaluator.exécuter_tests_unitaires(code) # Evaluator = oracle de tests
si résultat.tous_réussis:
renvoyer code # arrêt en cas de succès
critique = SelfReflect.analyser(code, résultat.erreurs) # critique verbale
réflexions.append(critique) # limiter la mémoire à 1–3 entrées
tentative += 1
```

Dans la logique du résultat HumanEval : un premier jet échoue à deux tests sur dix. La Self-Reflection note en substance « cas limite de la liste vide non traité, off-by-one dans la boucle ». La deuxième tentative lit cette note, corrige les deux points et réussit tous les tests. C'est précisément ce schéma qui porte l'amélioration sur HumanEval d'environ 80 % à 91 % pass@1.

Deux leçons de production non négociables tirées de la recherche :

• Plafonne toujours les itérations. Dans CrewAI via max_reasoning_attempts, dans LangGraph via une condition revision_number ≤ N. Sinon, la boucle peut s'emballer.
• Utilise un signal de vérité terrain externe quand c'est possible : tests unitaires, évaluateur RAG, correspondance regex. L'autoévaluation seule n'est pas fiable ; le cas MBPP est là pour le rappeler.

Si tu as des types de tâches récurrents, tu peux en outre stocker les réflexions dans une base vectorielle, indexées par type de tâche. Il en résulte une bibliothèque de compétences émergente qui agit au-delà des épisodes individuels, ce qui fait le lien avec les approches de type skill library comme Agent Workflow Memory (arXiv:2409.07429).

Place dans l'écosystème des frameworks (situation en 2026)

• LangGraph : tutoriel officiel avec trois variantes : Basic Reflection (paire générateur-réflecteur), Reflexion (Draft-Responder → exécution d'outils → boucle Revisor avec mémoire de réflexion explicite) et LATS (Reflexion plus recherche arborescente). Un pattern de production solide consiste à utiliser une sortie structurée qui regroupe answer, reflection (ce qui manque, ce qui est superflu) et les search_queries de suivi.
• CrewAI : à deux niveaux. Au niveau de l'agent via Agent(reasoning=True, max_reasoning_attempts=N), au niveau de la crew via un Critic Agent dédié dans le Hierarchical Process.
• AutoGen : documenté comme design pattern « Reflection » avec un agent Coder et un agent Reviewer qui itèrent jusqu'à convergence ou jusqu'à max_iterations. Remarque : AutoGen est officiellement en mode maintenance ; Microsoft oriente les nouveaux projets vers Microsoft Agent Framework, le successeur commun d'AutoGen et de Semantic Kernel.
• n8n : pas de nœud Reflexion natif. Réalisable sous forme de boucle de workflow : agent générateur → agent critique → nœud IF sur le verdict → retour au générateur ou fin. Adapté aux tâches par lots et de back-office, pas au chat à faible latence.

Pour les agences et le B2B

Pour les agences marketing en Europe, Reflexion est le bon outil pour des tâches par lots bien délimitées, vérifiables et exigeantes en qualité : génération automatisée de code ou de configurations, enrichissement de données avec des règles de validation claires, contenus structurés avec un schéma strict. La règle empirique : ne l'utilise que si tu peux définir un signal de vérification automatisable et si la latence ne se voit pas dans l'échange avec le client. Pour les chatbots en temps réel, un pattern ReAct réactif est le meilleur choix. Chez Blck Alpaca, nous intégrons précisément cette décision d'architecture dans l'estimation des coûts : d'abord mesurer quels modes de défaillance apparaissent, puis passer de manière ciblée d'un ReAct simple à Reflexion, avec un plafond strict d'itérations et un oracle externe. L'agent reste ainsi fiable et le budget de tokens prévisible.