Rétrospective — PD-244¶

Résumé story¶

• Story : PD-244 — Audit conformité ISO 14641 et NF Z42-013
• Domaine : legal-compliance
• Date : 2026-02-20
• Gates : G3 GO (v2) | G5 GO (v2) | G8 RESERVE acceptée (v1)
• Type : Story documentaire (première du domaine legal-compliance)

Learnings de cette story¶

Depuis les gates¶

Depuis le REX¶

1. Multi-agents révèle les ambiguïtés — Les 3 agents (Claude, ChatGPT, Gemini) produisent des scores divergents (91.67% vs 58.82% sur ISO 14641), révélant les zones d'interprétation normative

2. Réconciliation explicite obligatoire — Règles consensus (3/3) / majorité (⅔) / arbitrage (1/1/1) à définir AVANT production multi-agents

3. Anti-citation = instruction + exemple — Le contrôle anti-citation nécessite instruction explicite + exemple de reformulation dans chaque prompt agent

4. RESERVE acceptée pragmatique — Pour audit interne sans certification externe, accepter une réserve avec justification tracée est valide

5. Workflow adaptable — L'étape 6 s'adapte aux stories sans code (matrices au lieu de modules TypeScript)

Patterns récurrents (cross-story)¶

Tags à haute fréquence (≥ 5 stories)¶

Pattern bloquant détecté¶

#spec-incomplete + #auth = NON_CONFORME G3

4 stories auth ont eu G3 NON_CONFORME avec tag #spec-incomplete :

• PD-32 (user-settings)
• PD-238 (MFA)
• PD-239 (password-change)
• PD-240 (account-deletion)

→ Les specs auth manquent systématiquement de précision sur : rate-limiting, session invalidation, error codes.

Axes fragiles (score moyen < 7.5)¶

Recommandations¶

Priorité haute (≥ 5 stories ou NON_CONFORME récurrent)¶

• AUTH-001 : Ajouter checklist obligatoire dans prompt spec (1-Spécification.md) pour domaine auth :
• Rate-limiting défini (valeurs, fenêtre, scope) ?
• Session invalidation bornée (délai max) ?
• Codes erreur exhaustifs avec mapping HTTP ?

• Format payloads explicite (noms champs) ?

• TEST-001 : Documenter les dépendances ESM-only connues (p-queue, file-type, eventemitter3) dans un fichier docs/esm-dependencies.md pour anticiper les problèmes Jest

Priorité normale¶

• MULTI-AGENT-001 : Créer template templates/prompts/6-multi-agents-reconciliation.md avec règles consensus/majorité/arbitrage (capitaliser PD-244)

• DOCUMENTARY-001 : Adapter les critères Gate 8 pour stories documentaires : security = intégrité documentaire, pas vulnérabilités code

• MOBILE-001 : Documenter patterns Zustand persist (merger état, pas écraser) dans CLAUDE.md section mobile-ios

Signal CLAUDE.md¶

Section suggérée : "Checklist spec domaine auth"¶

### ⚠️ RÈGLE TRANSVERSALE : Checklist spec domaine auth-identity

**OBLIGATOIRE pour toute spec dans le domaine `auth-identity`.**

Avant Gate 3, vérifier que la spec contient :

| Élément | Critère d'acceptation |
|---------|----------------------|
| Rate-limiting | Valeurs numériques (ex: 5 req/15min/IP) |
| Session invalidation | Délai max borné (ex: < 30s) |
| Codes erreur | Liste exhaustive avec mapping HTTP |
| Payloads | Noms des champs (pas juste "credentials") |
| Keycloak delegation | Observability explicite (métriques, alertes) |

**Source** : Pattern récurrent PD-32, PD-238, PD-239, PD-240 (tous NON_CONFORME G3 v1).

Section suggérée : "Stories documentaires"¶

### ⚠️ RÈGLE TRANSVERSALE : Stories documentaires (type audit)

Pour les stories produisant des documents (matrices, audits) au lieu de code :

1. **Étape 6** : Production matrices/documents au lieu de modules TypeScript
2. **Gate 8 critère security** :
   - Anti-citation (reformulation) > vulnérabilités code
   - Preuves vérifiables (chemins internes) > tests unitaires
   - Intégrité documentaire > coverage
3. **Multi-agents** : Documenter règles réconciliation AVANT production

**Source** : PD-244 (première story legal-compliance).

Rétrospective produite conformément au skill /gov-retrospective