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

💡 Essence du Pattern : Un seul agent génère, critique sa propre production, puis s’améliore de manière itérative jusqu’à atteindre un niveau de qualité satisfaisant.
[Requête Utilisateur] ↓ GÉNÉRATION (Version 1) ↓ AUTO-CRITIQUE ← Le même agent analyse (Feedback) ses propres failles ↓ AMÉLIORATION (Version 2+) ↓ [Résultat Final]

⚙️ 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

SituationPourquoi Reflection ?Gain Typique
Génération de code complexeDétection automatique de bugs, edge cases, optimisations-60% d’erreurs, +40% de qualité
Rédaction de contenu longCohé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éesCapture des subtilités culturelles, idiomes, contexte+30% de précision vs traduction directe
Résolution de problèmes mathématiquesVérification automatique des étapes, cohérence logique-70% d’erreurs de calcul

❌ Quand NE PAS Utiliser

SituationProblèmeAlternative
Réponses factuelles simplesOverhead x3 pour un gain négligeableGénération directe
Latence critique (< 500ms)Le cycle complet prend 2-5 secondes minimumModèle léger optimisé
Tâches subjectives sans critères clairsL’agent ne sait pas quoi améliorerFeedback humain ou Evaluator externe
Budgets serrés (tokens limités)Consomme 2-3x plus de tokens qu’une passe simpleOptimisation du prompt initial
🧪 Test Simple : Posez-vous ces questions :
  • 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 OUI aux 3 questions → Reflection est adapté.
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 :

[Code Source API] ↓ Phase 1 : GÉNÉRATION → Documentation brute générée ↓ Phase 2 : AUTO-CRITIQUE → « Manque exemples cURL » → « Codes erreur incomplets » → « Pas de note sur rate limiting » ↓ Phase 3 : AMÉLIORATION → Documentation enrichie avec – Exemples multi-langages – Table complète des erreurs – Section rate limits + quotas ↓ [Documentation Finale]

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 :

[Ticket Client] ↓ Phase 1 : GÉNÉRATION → Email de réponse initial ↓ Phase 2 : AUTO-CRITIQUE → « Ton trop technique, manque d’empathie » → « Solution pas assez détaillée (étapes) » → « Oublie de mentionner le geste commercial » ↓ Phase 3 : AMÉLIORATION → Réécriture avec : – Ton empathique dès le début – Guide pas-à-pas avec screenshots – Offre de crédit ou extension d’essai ↓ [Email Optimisé]

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 :

[Diff Code] ↓ Phase 1 : GÉNÉRATION → Rapport de sécurité initial (3 failles identifiées) ↓ Phase 2 : AUTO-CRITIQUE → « Ai-je vérifié TOUS les vecteurs d’attaque ? » → « Les faux positifs sont-ils justifiés ? » → « Manque analyse du contexte (sanitization amont) » ↓ Phase 3 : AMÉLIORATION → Rapport affiné : – 5 failles (2 nouvelles détectées) – 1 faux positif retiré (sanitization OK) – Suggestions de fix avec exemples ↓ [Rapport Sécurité Fiable]

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à excellent
Flux visuel :
[Requête] ↓ ┌────────────────┐ │ GÉNÉRATION │ ← Prompt Étape 1 │ (Version 1) │ └────────┬───────┘ ↓ ┌────────────────┐ │ AUTO-CRITIQUE │ ← Prompt Étape 2 │ (Feedback) │ + Version 1 └────────┬───────┘ ↓ Score ≥ seuil ? ↓ NON ↓ OUI ┌─────────┐ │ │AMÉLIORER│ │ │(V2/V3) │ ← Prompt Étape 3 └────┬────┘ │ └───────────┘ ↓ [Résultat Final]
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-PatternConséquenceSolution
Critères vagues
"Améliore la qualité générale"
L'agent ne sait pas quoi améliorer concrètement, tournage en rondSpé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 progressiveSeuil 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 contexteNe 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 utilisateurRé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étriqueCibleAlerte siSignification
Score Qualité Moyen≥ 8.5/10< 7.0/10Mesure 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âche1.8 cycles> 2.5 cyclesNombre moyen d'itérations avant d'atteindre le seuil. Si élevé → seuil trop strict ou prompt initial faible
Coût Token Moyen2.2x vs génération simple> 3.5xOverhead en tokens. Si trop élevé → limiter les itérations ou optimiser les prompts
Latence Totale (P95)< 5s> 8sTemps 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
⚠️ Alerte Critique : Si le Taux d'Amélioration < +15% après 3 mois d'utilisation, cela signifie que le pattern Reflection n'apporte pas de valeur suffisante pour justifier son coût. Actions possibles :
  • 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

🎯 En 3 Points Clés :
  1. 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.
  2. Coût maîtrisé : 2-3 cycles max avec critères objectifs. Overhead = 2-3x tokens, mais ROI élevé sur tâches critiques.
  3. 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
⚠️ Erreur Fréquente : Utiliser Reflection sur TOUTES les générations "par défaut". Cela triple les coûts sans bénéfice réel sur les tâches simples. Règle d'or : Activez Reflection uniquement si vous pouvez mesurer un gain qualité >+25% qui justifie l'overhead. Pour 80% des cas, une génération optimisée directe suffit.
https://youtu.be/42NqqtS35qM

Publications similaires