Design Pattern Reflection – Réflexion

Reflection (Réflexion) est un pattern agentique où un agent génère d’abord une réponse, puis s’auto-évalue de manière critique pour produire une version améliorée. Ce cycle d’auto-amélioration permet d’obtenir des résultats de meilleure qualité sans intervention externe. Idéal pour des tâches créatives, techniques ou critiques nécessitant plusieurs itérations pour atteindre l’excellence.
Voir la table des matières complète
1. Le Concept en Une Phrase
⚙️ Principe
Un agent unique effectue 3 phases séquentielles : il génère une première réponse, l’analyse objectivement pour identifier ses lacunes, puis produit une version corrigée intégrant son feedback.
L’agent devient son propre correcteur.
🎯 Bénéfice
Qualité accrue sans complexité multi-agents. Réduit les erreurs de logique, améliore la cohérence et la profondeur des réponses. Coût = 2-3x une génération simple, mais résultat souvent 10x meilleur.
Mieux vaut une itération réfléchie que 5 tentatives aléatoires.
2. Quand Utiliser vs NE PAS Utiliser
✅ Cas d’Usage Idéaux
| Situation | Pourquoi Reflection ? | Gain Typique |
|---|---|---|
| Génération de code complexe | Détection automatique de bugs, edge cases, optimisations | -60% d’erreurs, +40% de qualité |
| Rédaction de contenu long | Cohérence narrative, ton uniforme, arguments solides | +75% de satisfaction utilisateur |
| Analyses critiques | Évite les biais initiaux, approfondit le raisonnement | +50% de profondeur analytique |
| Traductions nuancées | Capture des subtilités culturelles, idiomes, contexte | +30% de précision vs traduction directe |
| Résolution de problèmes mathématiques | Vérification automatique des étapes, cohérence logique | -70% d’erreurs de calcul |
❌ Quand NE PAS Utiliser
| Situation | Problème | Alternative |
|---|---|---|
| Réponses factuelles simples | Overhead x3 pour un gain négligeable | Génération directe |
| Latence critique (< 500ms) | Le cycle complet prend 2-5 secondes minimum | Modèle léger optimisé |
| Tâches subjectives sans critères clairs | L’agent ne sait pas quoi améliorer | Feedback humain ou Evaluator externe |
| Budgets serrés (tokens limités) | Consomme 2-3x plus de tokens qu’une passe simple | Optimisation du prompt initial |
- La tâche bénéficie-t-elle d’une révision critique ? (code, texte, analyse)
- Avez-vous 2-5 secondes de latence disponibles ?
- Les critères de qualité sont-ils objectifs et explicites ?
Si NON à au moins 1 → Envisagez une approche plus simple.
3. Trois Exemples Concrets
📦 Exemple 1 : Génération de Documentation API (SaaS)
Contexte : Une plateforme SaaS génère automatiquement la documentation de ses endpoints API à partir du code source.
Types de requêtes :
- « Documente l’endpoint POST /api/v2/subscriptions avec exemples »
- « Génère les descriptions des erreurs pour le module authentification »
- « Crée un guide de démarrage rapide pour l’API webhooks »
Architecture Reflection :
Gains mesurés :
- Qualité : +85% de complétude (checklist interne validée)
- Temps : 4s vs 20min manuelles (génération + révision humaine)
- Cohérence : 100% des docs suivent le même format
💬 Exemple 2 : Réponses Support Client Complexes
Contexte : Une entreprise SaaS gère des tickets techniques nécessitant des réponses détaillées et empathiques.
Types de requêtes :
- « Client frustré par un bug récurrent sur l’export Excel »
- « Demande de remboursement suite à une panne de 3 heures »
- « Question technique sur l’intégration Zapier avec rate limits »
Architecture Reflection :
Gains mesurés :
- Satisfaction : +42% (NPS passé de 6,5 à 9,2)
- Temps agent : -60% (3 min vs 8 min par ticket)
- Réouvertures : -35% (moins d’allers-retours)
🛡️ Exemple 3 : Analyse de Sécurité Code (DevSecOps)
Contexte : Une plateforme CI/CD analyse automatiquement les Pull Requests pour détecter des vulnérabilités de sécurité.
Types de requêtes :
- « Analyse ce diff SQL pour injections potentielles »
- « Vérifie les failles XSS dans ces templates React »
- « Détecte les secrets hardcodés dans ce commit »
Architecture Reflection :
Gains mesurés :
- Détection : +45% de failles réelles vs analyse simple
- Faux positifs : -60% (réduction du bruit)
- Incidents évités : 12 vulnérabilités bloquées avant production (sur 1 mois)
4. Prompt Prêt à l’Emploi
💡 Prompt Prêt à l’Emploi : Cycle de Réflexion Complet
Contexte :
Ce template illustre le mécanisme complet du pattern Reflection : génération → auto-critique → amélioration. L’agent joue successivement 3 rôles distincts pour s’auto-corriger.
Étape 1 – Génération Initiale :
Tu es un expert en [DOMAINE].
**Tâche :**
[TACHE_COMPLETE]
**Contraintes :**
- [CONTRAINTE_1]
- [CONTRAINTE_2]
- [CONTRAINTE_3]
**Instructions :**
Génère une première version de [LIVRABLE] en respectant les contraintes ci-dessus.
Sois exhaustif et précis.
**Format de sortie :**
[FORMAT_ATTENDU]Étape 2 – Auto-Critique Structurée :
Tu es maintenant un critique exigeant en [DOMAINE].
**Production à évaluer :**
[REPONSE_ETAPE_1]
**Critères d'évaluation :**
1. **Complétude** : Tous les aspects de la tâche sont-ils couverts ?
2. **Précision** : Y a-t-il des erreurs factuelles, logiques ou techniques ?
3. **Clarté** : Le résultat est-il compréhensible et bien structuré ?
4. **Respect des contraintes** : Toutes les contraintes sont-elles respectées ?
5. **Qualité globale** : Qu'est-ce qui pourrait être amélioré ?
**Instructions :**
Analyse objectivement la production selon ces 5 critères.
Pour chaque critère, donne :
- Un score sur 10
- Les points faibles identifiés
- Des suggestions précises d'amélioration
**Format de sortie (JSON) :**
{
"completude": {"score": 8, "failles": ["...", "..."], "suggestions": ["..."]},
"precision": {"score": 7, "failles": ["..."], "suggestions": ["..."]},
"clarte": {...},
"contraintes": {...},
"qualite_globale": {...},
"score_total": 7.2,
"verdict": "AMELIORATION_NECESSAIRE | ACCEPTABLE | EXCELLENT"
}Étape 3 – Amélioration Ciblée :
Tu es de retour en tant qu'expert en [DOMAINE].
**Production initiale :**
[REPONSE_ETAPE_1]
**Feedback critique :**
[FEEDBACK_ETAPE_2]
**Instructions :**
Génère une VERSION AMÉLIORÉE qui corrige TOUS les points faibles identifiés dans le feedback.
Pour chaque suggestion du critique, intègre explicitement la correction.
**Améliorations à intégrer prioritairement :**
- [POINT_FAIBLE_1] → [CORRECTION_1]
- [POINT_FAIBLE_2] → [CORRECTION_2]
- [POINT_FAIBLE_3] → [CORRECTION_3]
**Format de sortie :**
[FORMAT_ATTENDU]
---
**Changelog :** Liste brièvement les modifications effectuées par rapport à la version 1.Flux complet (pseudo-code) :
// Étape 1 : Génération initiale
const version1 = await appelLLM(promptGeneration);
// Étape 2 : Auto-critique
const critique = await appelLLM(promptCritique, {
REPONSE_ETAPE_1: version1
});
// Étape 3 : Amélioration (si nécessaire)
if (critique.score_total < SEUIL_QUALITE) {
const version2 = await appelLLM(promptAmelioration, {
REPONSE_ETAPE_1: version1,
FEEDBACK_ETAPE_2: critique
});
return version2;
}
return version1; // Si déjà excellentFlux visuel :
Variables à personnaliser :
[DOMAINE]: Domaine d'expertise (ex: "rédaction technique", "architecture logicielle", "analyse de données")[TACHE_COMPLETE]: Description détaillée de la tâche[CONTRAINTE_1/2/3]: Contraintes spécifiques (longueur, format, ton, etc.)[FORMAT_ATTENDU]: Format de sortie souhaité (Markdown, JSON, code, etc.)[LIVRABLE]: Type de production attendue (article, code, rapport, etc.)SEUIL_QUALITE: Score minimum acceptable (ex: 8.0/10)
Résultat attendu :
Une production de haute qualité ayant passé au moins un cycle de révision critique. Temps total ≈ 3x une génération simple, mais qualité nettement supérieure (réduction des erreurs, meilleure cohérence, profondeur accrue).
💡 Variante avancée - Boucle itérative :
let version = await appelLLM(promptGeneration);
let iteration = 0;
const MAX_ITERATIONS = 3;
while (iteration < MAX_ITERATIONS) {
const critique = await appelLLM(promptCritique, { REPONSE: version });
if (critique.score_total >= SEUIL_QUALITE) {
break; // Qualité atteinte
}
version = await appelLLM(promptAmelioration, {
REPONSE: version,
FEEDBACK: critique
});
iteration++;
}
return version;5. Patterns & Anti-Patterns
✅ Patterns Efficaces
🎯 Critères Objectifs Explicites
Définir des critères mesurables dans le prompt de critique : longueur, présence d'exemples, respect d'un format, absence d'erreurs logiques.
Exemple : "Le code doit avoir des tests unitaires, gérer les erreurs, et respecter PEP-8"
🔄 Limitation des Itérations
Fixer un maximum de cycles (2-3) pour éviter les boucles infinies ou les améliorations marginales coûteuses.
Exemple : Si score < 7 après 3 cycles → escalader vers révision humaine
📊 Scores Pondérés Multi-Critères
Évaluer selon plusieurs dimensions (précision, clarté, ton) avec des poids différents selon le contexte.
Exemple : Précision × 0.5 + Clarté × 0.3 + Ton × 0.2 = Score global
💾 Conservation de l'Historique
Logger chaque version + critique pour déboguer les régressions ou comprendre l'évolution qualitative.
Exemple : Stocker {v1, critique1, v2, critique2} pour analyse post-mortem
❌ Anti-Patterns à Éviter
| Anti-Pattern | Conséquence | Solution |
|---|---|---|
| Critères vagues "Améliore la qualité générale" | L'agent ne sait pas quoi améliorer concrètement, tournage en rond | Spécifier : "Ajoute 3 exemples concrets, corrige les fautes, réduis à 500 mots" |
| Boucle infinie non contrôlée Pas de limite d'itérations | Coûts explosifs (50+ appels), latence ingérable (1 min+) | Limite stricte : 3 cycles max OU score seuil atteint |
| Sur-critique systématique L'agent trouve toujours des défauts | Version 5 parfois pire que version 2, dégradation progressive | Seuil d'acceptation : si score ≥ 8.5 → stop même si améliorable |
| Réutilisation aveugle du contexte Prompt trop long au fil des itérations | Coût tokens x10, risque de dépassement de limite de contexte | Ne garder que : version actuelle + dernier feedback (pas tout l'historique) |
| Ignorer le coût du pattern Utiliser Reflection sur TOUTES les tâches | Budget API x3, latence moyenne x2.5, frustration utilisateur | Réserver aux tâches critiques (code, contenu long, analyses) |
6. Propriétés Essentielles
🎯 Critères Mesurables
La phase de critique doit évaluer selon des critères objectifs et quantifiables (checklist, scores numériques).
Sans objectivité, l'agent ne peut pas s'améliorer de façon systématique.
🔄 Séparation des Rôles
Le prompt doit explicitement séparer les phases : "Tu es générateur" → "Tu es critique" → "Tu es améliorateur".
Le changement de perspective force une analyse objective.
⚡ Condition d'Arrêt Claire
Définir quand arrêter : seuil de qualité atteint OU nombre max d'itérations OU temps limite.
Sans arrêt, le pattern devient un gouffre de ressources.
📝 Feedback Actionnable
La critique doit donner des suggestions précises, pas juste des constats ("Manque exemples" → "Ajoute 3 exemples de cas réels").
Un feedback vague produit une amélioration vague.
🎭 Prompt de Critique Adversaire
Le prompt de critique doit adopter un ton exigeant, cherchant activement les failles (pas complaisant).
Un critique trop gentil ne détecte pas les vrais problèmes.
💰 Justification du Coût
Le gain qualitatif doit valoir le coût x2-3 en tokens/latence. Mesurer avant/après sur des métriques business.
Reflection n'est pas gratuit, il doit prouver sa valeur.
7. Métriques de Succès
| Métrique | Cible | Alerte si | Signification |
|---|---|---|---|
| Score Qualité Moyen | ≥ 8.5/10 | < 7.0/10 | Mesure l'amélioration effective post-réflexion. Si bas → critères inadaptés ou tâche trop complexe |
| Taux d'Amélioration | +30% qualité V2 vs V1 | < +10% | % d'amélioration entre version initiale et finale. Si faible → Reflection inutile ici |
| Cycles Moyens par Tâche | 1.8 cycles | > 2.5 cycles | Nombre moyen d'itérations avant d'atteindre le seuil. Si élevé → seuil trop strict ou prompt initial faible |
| Coût Token Moyen | 2.2x vs génération simple | > 3.5x | Overhead en tokens. Si trop élevé → limiter les itérations ou optimiser les prompts |
| Latence Totale (P95) | < 5s | > 8s | Temps du cycle complet. Si trop long → paralléliser ou réduire les itérations |
| Taux d'Acceptation Humaine | > 85% | < 70% | % de productions validées sans modification humaine. Indicateur final de qualité réelle |
- Revoir les critères d'évaluation (trop laxistes ?)
- Améliorer le prompt de génération initiale (pour qu'il soit déjà bon)
- Réserver Reflection aux tâches vraiment complexes uniquement
- Envisager un pattern différent (Evaluator-Optimizer avec agents séparés)
8. Récapitulatif
- Auto-amélioration itérative : Un seul agent génère, critique, puis améliore sa propre production. Qualité x2-10 vs génération directe.
- Coût maîtrisé : 2-3 cycles max avec critères objectifs. Overhead = 2-3x tokens, mais ROI élevé sur tâches critiques.
- Métriques essentielles : Taux d'amélioration (+30%), score qualité (≥8.5), latence (<5s), acceptation humaine (>85%).
✅ Quand Utiliser
- Génération de code, contenu long, analyses
- Qualité prioritaire sur la vitesse
- Critères d'évaluation clairs et objectifs
- Budget permet overhead x2-3
- Tâches où révision humaine serait systématique
❌ Quand NE PAS Utiliser
- Réponses factuelles simples (FAQ, recherche)
- Latence critique (<500ms)
- Tâches subjectives sans critères clairs
- Volumes massifs avec budget serré
- Contexte où première version suffit largement



