PD-244 — Retour d'expérience (REX)¶

1. Résumé exécutif¶

2. Métriques de convergence¶

2.1 Temps et itérations¶

2.2 Scores de convergence par gate¶

2.3 Écarts par catégorie¶

3. Points fluides¶

Ce qui a bien fonctionné :

• Architecture multi-agents : La production parallèle par 3 agents (Claude, ChatGPT, Gemini) a permis une diversité cognitive réelle avec 3 perspectives différentes sur les normes
• Méthodologie de réconciliation : Les règles consensus (3/3) / majorité (⅔) / arbitrage (1/1/1) ont bien fonctionné pour résoudre les divergences
• Acceptabilité croisée : Chaque matrice évaluée par 2 autres agents a révélé les faiblesses (Gemini trop strict, Claude trop optimiste)
• OpenCode pour ChatGPT : L'intégration via stdin a parfaitement fonctionné pour les prompts longs
• Story documentaire : L'adaptation du workflow pour une story sans code a été naturelle (phase 6 = production matrices au lieu de code)

4. Points difficiles¶

Obstacles rencontrés (sans justification) :

• Accès aux normes sources : Les PDFs ISO 14641 et NF Z42-013 ne sont pas lisibles directement (poppler manquant) — contourné par connaissance des normes
• Divergence inter-agents : Écart de scoring jusqu'à 50% entre agents (Claude 91.67% vs Gemini 58.82% sur ISO 14641)
• Gate 3 NON_CONFORME : Première itération rejetée car version NF Z42-013:2009 au lieu de 2020
• Plan v3 nécessaire : Deux refactorings du plan pour intégrer l'architecture multi-agents (plan v1 mono-agent, plan v2 intermédiaire, plan v3 final)
• Gemini thinking_config : Erreur include_thoughts avec gemini-2.0-flash, fallback sur gemini-2.5-pro

5. Hypothèses révélées tardivement¶

Hypothèses non explicites découvertes en cours de workflow :

• INV-PD244-08 anti-citation — découverte à l'étape 6 : Le contrôle anti-citation nécessite une instruction explicite dans les prompts agents, pas seulement une règle documentée
• Scoring divergent — découverte à l'étape 6b : Les agents ont des interprétations différentes de CONFORME vs PARTIEL selon leur "personnalité" (conservateur vs optimiste)
• Arbitrage humain-in-the-loop — découverte à l'étape 6b : Les cas 1/1/1 (3 avis différents) nécessitent une escalade, pas un vote aléatoire

6. Invariants complexes¶

Invariants difficiles à implémenter ou sensibles aux régressions :

• INV-PD244-07 (formule score) — TC-SCORE : La formule ((CONFORME*100 + PARTIEL*50) / (total - HORS_PERIMETRE)) est mathématiquement simple mais l'application cohérente par 3 agents nécessite une instruction précise
• INV-PD244-08 (anti-citation) — TC-YAML-09 : Vérifier l'absence de copie verbatim est difficile automatiquement — relies sur reformulation manuelle

7. Dette technique¶

Compromis acceptés et non bloquants :

• Anti-citation non automatisé — impact: faible — Contrôle manuel des reformulations, pas de vérificateur automatique "10 mots identiques"
• Preuves internes majoritaires — impact: faible — Les preuves référencent des chemins internes non accessibles à un auditeur externe
• Scores réconciliés < 80% — impact: moyen — ISO 77.78% et NF 68.18% nécessitent les 11 stories planifiées sous PD-217 pour atteindre la certification

8. Risques résiduels¶

8bis. Matrice de délégation inter-PD¶

Stories dont cette implémentation dépend, et stories qui dépendent de cette implémentation :

8ter. Bugs de tests¶

Aucun bug de test rencontré (story documentaire sans code applicatif).

9. Patterns récurrents détectés¶

9.1 Patterns confirmés (déjà vus dans d'autres stories)¶

• Gate 3 souvent NON_CONFORME en v1 — pattern général : les specs initiales manquent de précision
• Plan nécessite plusieurs itérations — pattern général : la décomposition en tâches est souvent sous-estimée

9.2 Nouveaux patterns identifiés¶

• Multi-agents = diversité cognitive — Les 3 agents produisent des résultats significativement différents, ce qui révèle les zones d'ambiguïté normative
• Réconciliation nécessite règles explicites — Sans règles consensus/majorité/arbitrage, la réconciliation devient subjective
• Score security difficile à atteindre pour audit — Le critère security (anti-citation, sources) est le plus difficile à documenter formellement
• Story documentaire = phase 6 adaptable — Le workflow s'adapte bien aux stories sans code (matrices au lieu de modules)

10. Améliorations du workflow¶

10.1 Améliorations des prompts/templates¶

10.2 Améliorations des agents¶

10.3 Améliorations du processus¶

• Créer un template pour stories documentaires : Adapter les critères Gate 8 (security ≠ vulnérabilités code mais intégrité documentaire)
• Ajouter vérificateur anti-citation : Script Python/TS qui compare les reformulations aux textes normatifs originaux
• Archiver les matrices agents : Garder les 9 matrices individuelles pour auditabilité, pas seulement les réconciliées

11. Enseignements clés¶

5 enseignements génériques réutilisables :

1. Multi-agents révèle les ambiguïtés — Quand 3 agents produisent des scores différents, c'est que la norme ou la spec est ambiguë. Utiliser cette divergence comme signal.

2. Réconciliation explicite > vote implicite — Documenter les règles de réconciliation (consensus/majorité/arbitrage) avant de lancer les agents, pas après.

3. Anti-citation = instruction + exemple — Une règle documentée ne suffit pas. Il faut injecter l'instruction ET un exemple de reformulation dans chaque prompt agent.

4. RESERVE acceptée ≠ échec — Pour un audit interne sans certification immédiate, accepter une RESERVE avec justification est pragmatique.

5. Story documentaire = workflow adaptable — Le workflow en 10 étapes s'adapte aux stories sans code : la phase 6 produit des matrices/documents au lieu de modules TypeScript.

12. Métriques cumulatives¶

Réserves acceptées¶

Cette story se termine avec une réserve Gate 8 explicitement acceptée :

Décision humaine : Option B (accepter la réserve sans correction).

REX produit conformément au template templates/outputs/PD-XX-rex.md