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

Story : PD-252 — Politique des formats de préservation SAE Projet : ProbatioVault-doc Domaine : legal-compliance Date de clôture : 2026-03-11 Tracabilité : GAP-FINAL-004 (PD-244 audit ISO 14641)

1. Résumé exécutif¶

2. Métriques de convergence¶

2.1 Temps et itérations¶

Note : Toutes les étapes sauf Gate 3 se sont déroulées dans les temps estimés. Gate 3 a représenté ~30% du temps total du workflow.

2.2 Scores de convergence par gate¶

Progression Gate 3 itération par itération :

Événement critique : À v3 (6.75/10 < 7.0), le plafond 3 itérations a été atteint. Escalade PO déclenchée. La v4 a été produite avec corrections manuelles de l'orchestrateur, levant le blocage.

2.3 Écarts par catégorie¶

Observation : Zéro écart DIV — cohérence parfaite entre spec (après Gate 3) et implémentation. Phénomène attendu pour une story documentaire pure (pas de code à diverger).

3. Points fluides¶

• Implémentation rapide et précise : Une fois la spec stabilisée (v4), la rédaction des 2 livrables Markdown (C1 : 24KB, C2 : amendement ch08) s'est faite sans écart. La clarté de la spec au niveau des invariants a guidé l'agent de façon déterministe.
• Gate 8 GO en v1 : Malgré 4 itérations Gate 3, la Gate 8 a été franchie du premier coup avec 8.75/10. Aucun écart MAJEUR ni BLOQUANT.
• Couverture tests 100% : 31/31 tests passés (nominaux + erreurs + non-régression + adversariaux + mécanisme). Couverture totale des 12 CA et 9 INV.
• Escalade PO fonctionnelle : Le mécanisme d'escalade a correctement résolu le blocage Gate 3 v3 (plafond atteint). La décision PO a été prise avec les informations nécessaires.
• Distinction normativeReference vs citations documentaires : Le contrat §5.1 qui distingue les références structurées (regex) des citations documentaires (textuelles) a été correctement implémenté une fois spécifié clairement.

4. Points difficiles¶

• Gate 3 v1 : completeness 3.0/10 — Score le plus bas observé dans l'historique du projet pour ce critère. La spec v1 ne contenait pas de modèle de données contractuel (regex, enum, contraintes) malgré les learnings injectés.
• Dépassement plafond Gate 3 : Première occurrence dans le projet d'un dépassement du plafond 3 itérations à Gate 3 (précédent : IM-01 à Gate 8). Nécessite une procédure d'escalade claire.
• Confusion normativeReference / citation documentaire : La distinction entre références structurées (avec §section) et citations documentaires (sans section) a créé des rejets successifs à Gate 3 v1 et v2. Cette nuance n'est pas couverte par les templates existants.
• Dérogation Art. II (prompts > 30KB) : Gate 5 et Gate 8 ont requis une dérogation Article II car les prompts dépassaient 30KB, forçant OpenCode en mode agentic. Dérogation documentée dans les verdicts mais pattern récurrent non mitigé.
• Spec v1 mal calibrée pour story documentaire contractuelle : Le template spec (conçu pour stories backend/app) n'impose pas de section "contrats de données" ni de définitions formelles d'enums. La spec doc a requis l'invention de ces sections.

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

• H-06 (lien GAP-FINAL-004) — découverte à l'étape 3 (Gate v1) : La modalité exacte du lien tracable vers GAP-FINAL-004 (URL, identifiant d'audit, annexe) n'était pas spécifiée dans le besoin. Traitée comme NON TESTABLE (Q-252-05).
• Plafond Gate 3 dépassable par escalade — découverte à l'étape 3 v3 : Le CONSTITUTIONAL.md prévoit l'escalade PO en cas de blocage au plafond, mais la procédure n'est pas documentée dans les skills. Elle a été appliquée implicitement.
• Durées légales non validées juridiquement (H-03) — découverte à l'étape 1 : Les durées P10Y/P30Y/P5Y du besoin étaient présentées comme "validées" mais H-03 indique que la validation juridique externe reste à confirmer. Risque résiduel actif.

6. Invariants complexes¶

• INV-252-06 (unicité des définitions en §5.1) — TC-NOM-06 : Risque de copier-coller de regex dans §3-§6. Nécessite vigilance active à la rédaction. Correctement respecté en v1 de l'implémentation.
• INV-252-07 (modèle d'états avec transitions inverses interdites) — TC-NOM-07 : La complétude du tableau des transitions (toutes les transitions depuis COMPLETE/BITSTREAM/REJECTED = INTERDITES) a pris 3 itérations de spec pour être correctement contractualisée.
• INV-252-05 (5 validations d'ingestion avec SHA3-384 explicite) — TC-NOM-05 : La clause de non-conformité technique (validations PLANIFIÉ ≠ déclaration de conformité) était absente de la spec v1. Anomalie E-01 (casse IMPLANTÉ vs IMPLEMENTE) est restée MINEURE.

7. Dette technique¶

8. Risques résiduels¶

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

8ter. Bugs de tests¶

Aucun bug de test rencontré. PD-252 est une story documentaire pure. Tous les tests sont des revues documentaires structurées (checklist) — pas de tests unitaires/intégration.

8quater. Corrections post-Gate 8¶

Aucune correction post-Gate 8 requise. Les 2 écarts MINEURS (E-01, E-02) sont des dettes de forme, non bloquantes pour la conformité normative.

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

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

• Dérogation Art. II prompts > 30KB — aussi dans PD-283 (Gate 8), IM-01 (Gate 8) : Les stories avec beaucoup d'artefacts dépassent le seuil d'OpenCode/ChatGPT. Pattern structurel non résolu. Le claude -p comme reviewer principal est la dérogation acceptée.
• Gate 8 GO en v1 malgré Gate 3 difficile — aussi dans PD-278, PD-280 : La Gate 3 sert de filtre dur pour la spec. Une spec bien construite (même après 4 itérations) guide une implémentation propre. Le coût Gate 3 est un investissement.
• ECT domination en début de workflow — pattern systémique (21 stories) : La complétude et la testabilité sont les critères les plus difficiles à satisfaire à Gate 3. Le modèle de données contractuel (§5.1) est la zone la plus sensible.

9.2 Nouveaux patterns identifiés¶

• Spec v1 completeness 3.0 : seuil d'alarme : Une spec documentaire qui ne contractualise pas ses données (pas de regex, enum, contraintes) peut tomber à completeness 3.0/10. Le template spec doit exiger une section "contrats de données" pour TOUTE story avec des champs structurés (même doc).
• Documentation contractuelle ≠ documentation narrative : PD-252 a révélé deux catégories distinctes de stories doc :
• Narrative : descriptions de process, guides (→ Gate 3 facile, PD-281 : 8.938 en v1)
• Contractuelle : politiques avec regex/enum/états/matrices (→ Gate 3 difficile, PD-252 : 4.5 en v1) Le discriminant est la présence de modèles de données formels. Les stories contractuelles doivent être traitées comme des stories techniques niveau spec.
• Plafond Gate 3 atteint → escalade PO : Première occurrence à Gate 3 (vs. IM-01 qui l'a atteint à Gate 8). La procédure d'escalade a fonctionné implicitement mais n'est pas documentée dans les skills /gov-gate. À formaliser.

10. Améliorations du workflow¶

10.1 Améliorations des prompts/templates¶

10.2 Améliorations des agents¶

10.3 Améliorations du processus¶

• Formaliser la procédure d'escalade Gate plafond dans le skill /gov-gate : définir explicitement les actions possibles (escalade PO, corrections orchestrateur, abandon), les conditions de dérogation et le format de trace dans WORKFLOW-STATE.md.
• Seuil d'alarme Gate 3 completeness < 5.0 : Déclencher automatiquement une revue de la spec par l'orchestrateur avant de relancer la Gate (économise 1-2 itérations).
• Validation pré-soumission Gate 3 pour stories doc contractuelles : Vérifier la présence d'une section "contrats de données" (regex, enum, comportement si invalide) avant de soumettre à Gate 3. Similaire au /gov-check-plan pour Gate 5.
• Budget temps Gate 3 variable par type de story : L'estimation 1h pour Gate 3 est adaptée aux stories narratives. Les stories contractuelles (doc avec modèles de données) doivent être estimées à 2-4h de Gate 3 dès le départ.

11. Enseignements clés¶

1. Stories doc contractuelles = stories techniques — Les politiques avec regex/enum/états-transitions doivent être traitées comme des stories backend niveau spec. Le template et les estimations de Gate 3 doivent être adaptés. Indicateur : présence de données structurées dans le besoin.

2. Le plafond Gate 3 est franchissable par escalade — 4 itérations (dépassant le plafond de 3) ont permis de passer de NON_CONFORME 4.5 à RESERVE 7.875. L'escalade PO est le mécanisme correct. La v4 avec corrections manuelles de l'orchestrateur est une dérogation acceptable documentée.

3. Spec solide → implémentation zéro-divergence — PD-252 démontre qu'une spec bien construite (même à coût élevé : 4 itérations Gate 3) garantit une implémentation propre (31/31 tests PASS, Gate 8 GO v1). ROI : le temps investi en Gate 3 est rentabilisé en Gate 8.

4. Dérogation Art. II (prompts > 30KB) : pattern structurel — Récurrent dans les stories avec de nombreux artefacts. Solution palliative (claude -p comme reviewer) mais non définitive. Une stratégie de chunking ou de résumé des artefacts pour maintenir les prompts < 30KB serait à explorer.

5. Modèle de données = source unique de vérité — INV-252-06 (§5.1 source unique) est l'invariant le plus critique des stories contractuelles. Sa violation (copier-coller de regex) est invisible à la Gate 3 mais cause des incohérences lors des évolutions. À contractualiser systématiquement dans les stories avec données structurées.

12. Métriques cumulatives (auto-calculées)¶

Produit dans le cadre du workflow de gouvernance ProbatioVault — Étape 9 (REX) — PD-252 — 2026-03-11