PD-277 — 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é :

• Gate 8 GO en v1 (9.125/10) — première fois en une seule itération pour la gate de clôture. Les corrections sécurité effectuées en étape 7 (S-01, S-02) ont permis d'arriver propre à la gate.
• Implémentation rapide (25 min) — la décomposition en 8 tâches sur 3 niveaux de parallélisation a été efficace. Les 174 tests passent du premier coup.
• Shadow evaluation utile — la confrontation ChatGPT vs qwen3.5 en étape 1 (delta -2.0 en faveur de ChatGPT) a validé le choix de l'agent production.
• Correction sécurité proactive en étape 7 — les vulnérabilités S-01 (regex flag i) et S-02 (TOCTOU includes()) détectées par la review sécurité ChatGPT ont été corrigées avant Gate 8, évitant une itération supplémentaire.
• Learnings injectés pertinents — les 3 learnings (PD-63 crypto.randomUUID, PD-41 fail-closed crypto, PD-238 timingSafeEqual) ont directement influencé l'implémentation sans friction.

4. Points difficiles¶

Obstacles rencontrés (sans justification) :

• Gate 5 à 3 itérations — le plan v1 avait 6 écarts MAJEUR (DDL DEFAULT non contractualisé, couverture PKI incomplète, fail-closed ReKeys hérités non démontré, condition status=ACTIVE non spécifiée, frontière code contract violée, module repository non couvert). La v2 a corrigé mais coherence est restée à 7.75 (sous le seuil 8.0). La v3 a atteint 8.0 par convergence.
• Sonar Phase 1.5 indisponible — le token Vault a retourné null, rendant l'exécution Sonar locale impossible. La procédure BLOQUANTE a été contournée de fait, reportant la vérification au pipeline CI/CD.
• Résultat audit Prolog 23/24 vs objectif 24/24 — l'ambiguïté sur la nature du check HSM FIPS (bloquant vs non bloquant, pré-existant vs nouveau) a généré une divergence documentaire (DIV-02) qui a nécessité une analyse en Gate 8.
• Gate 3 v1 — 3 constats bloquants — le format nonce n'était pas contractualisé (longueur, encodage, normalisation), les faits Prolog canoniques étaient absents de la spec, et 4 tests d'invariants n'avaient pas de scénarios GIVEN/WHEN/THEN. Correction en v2 (+1.25 delta).

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

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

• H-277-T01 (LegalReKey pré-existants) — découverte à l'étape 3 (Gate 3 v1). La spec v1 ne traitait pas le cas des enregistrements existants lors de l'ajout de colonnes NOT NULL. Nécessité d'introduire DEFAULT '' pour les certificats, contractualisé dans le plan.
• H-277-T02 (Extension TspVerificationResult) — découverte à l'étape 4. Le résultat TSP devait être enrichi avec les certificateId pour permettre le binding PKI. L'interface existante supportait les champs optionnels sans casser la rétrocompatibilité.
• Nonce fourni par l'appelant vs généré serveur — divergence identifiée en Gate 3 v2. La spec impose crypto.randomUUID() côté serveur, mais les tests valident des nonces fournis en entrée (cas d'erreur). Résolu en clarifiant que le nonce est généré serveur et transmis dans la requête.

6. Invariants complexes¶

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

• INV-277-02 (nonce-unique) — TC-NEG-02. La concurrence réelle (Promise.all) sur le même nonce exigeait une transaction SERIALIZABLE avec opérateur JSONB @> atomique côté DB. La première implémentation utilisait includes() applicatif (vulnérable TOCTOU), corrigée en commit f2e2cc6.
• INV-277-04 (pki-binding-mandatory) — TC-ERR-04/05/06, TC-NEG-05. La validation des certificats (non expirés, non révoqués, compatibles mandat) nécessitait l'extension du stub TSP avec support de configuration de test pour certificats invalides.
• INV-277-05 (binding-immutability) — TC-ERR-08, TC-NEG-04. L'immuabilité des certificats post-création a été implémentée au niveau applicatif (repository guard) plutôt que par trigger DB, cohérent avec le pattern de PD-81.

7. Dette technique¶

Compromis acceptés et non bloquants :

• Sonar non exécuté (DIV-03) — impact: moyen. Dérogation de fait sur la Phase 1.5 BLOQUANTE. Reporté au pipeline CI/CD post-merge. Si Sonar FAILED → corrections nécessaires avant REX.
• Stubs TSP sans story destination précise (ZO-04) — impact: faible. TspVerifierStub et consultDocument TODO référencent "PD-XXX" au lieu d'un numéro concret. La story TSP réelle sera déterminée lors de la planification d'intégration TSP.
• DEFAULT '' transitoire (DIV-01) — impact: faible. Certificats vides sur ReKeys pré-existants protégés par fail-closed dans reEncryptWithNonce(). Backfill non planifié (story séparée).
• TC-ERR-07 couvert implicitement (T-01) — impact: faible. Le test d'injection de défaillance de persistance n'est pas explicitement isolé, couvert par le rollback SERIALIZABLE.
• 10/29 TC en tests unitaires (DIV-04) — impact: faible. La répartition unitaire/intégration/CI est légitimée par le plan, mais la spec et les tests ne distinguent pas les niveaux.

8. Risques résiduels¶

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

8ter. Bugs de tests¶

8quater. Corrections post-Gate 8¶

Aucune correction post-Gate 8 nécessaire à ce stade. Sonar reporté au pipeline CI/CD.

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

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

• Fail-closed obligatoire pour mécanismes de sécurité — aussi dans PD-238, PD-240, PD-250, PD-251. PD-277 ajoute le fail-closed sur les ReKeys hérités (certificats vides → rejet).
• timingSafeEqual / opérations atomiques DB pour comparaisons crypto — aussi dans PD-38, PD-238, PD-264, PD-251. PD-277 utilise l'opérateur JSONB @> (côté DB) pour éviter les timing attacks.
• Stubs inter-PD acceptés en Gate 8 si documentés avec story destination — aussi dans PD-63, PD-82, PD-250, PD-251. PD-277 : stubs avec "PD-XXX" (sans numéro précis) a été accepté MINEUR.
• Machine à états explicite : aucune transition nouvelle quand hors scope — aussi dans PD-82, PD-250, PD-264, PD-251. PD-277 : vérification INV-277-08 (StatusEnum identiques avant/après).
• Gate 3 v1 bloquée par format non contractualisé — aussi dans PD-32, PD-250, PD-264, PD-251. PD-277 : format nonce (UUID v4 lowercase ASCII) absent de la spec v1, ajouté en v2.
• Atomicité multi-composant : transaction SERIALIZABLE pour opérations crypto — aussi dans PD-55, PD-264, PD-250, PD-251. PD-277 : vérif nonce + insert nonce + reEncrypt dans une seule transaction.

9.2 Nouveaux patterns identifiés¶

• Résolution de certificats via stub avec extension interface optionnelle — TspVerificationResult étendu avec champs optionnels ownerCertificateId/recipientCertificateId sans casser l'interface existante. Pattern à surveiller pour les prochaines intégrations PKI.
• DEFAULT transitoire + fail-closed pour migration rétrocompatible — ajout de colonnes NOT NULL avec DEFAULT vide + rejet des enregistrements hérités au runtime. Pattern utile pour éviter les migrations en 2 étapes.
• Audit Prolog : extraction automatique des faits depuis @Column TypeORM — aucune modification de extract-facts.py requise, les décorateurs @Column suffisent pour générer les faits Prolog. À capitaliser pour toutes les stories crypto-proof.

10. Améliorations du workflow¶

10.1 Améliorations des prompts/templates¶

10.2 Améliorations des agents¶

10.3 Améliorations du processus¶

• Token Sonar en Vault — le token Sonar retourne null. Corriger la configuration Vault pour garantir la disponibilité de Sonar en Phase 1.5. Alternatives : Sonar en CI/CD pré-merge (GitLab MR pipeline).
• Stubs avec story destination obligatoire — les stubs "PD-XXX" sans numéro concret devraient être bloqués en Gate 8 si la story de destination n'est pas planifiée dans le backlog. Renforce la traçabilité (ZO-04).
• Distinction niveaux de test dans les templates de tests — ajouter une colonne "Niveau" (Unit/Integration/CI/Infra) dans la matrice de couverture dès l'étape 2 pour éviter l'ambiguïté DIV-04 en Gate 8.

11. Enseignements clés¶

1. Contractualiser le format des entrées dès la spec — l'absence de format nonce contractualisé a généré 3 constats bloquants en Gate 3 v1. Pour toute story crypto, le format (longueur, encodage, normalisation, casse) doit être défini dans la spécification, pas découvert à la gate.

2. Opérations atomiques DB-level pour les invariants de sécurité — l'utilisation d'opérateurs JSONB PostgreSQL (@>, ||) dans une transaction SERIALIZABLE est supérieure aux vérifications applicatives (includes(), indexOf()) pour les contrôles anti-rejeu. Ce pattern élimine les vulnérabilités TOCTOU.

3. DEFAULT transitoire + fail-closed = migration rétrocompatible sûre — l'ajout de colonnes NOT NULL avec DEFAULT vide, combiné à un rejet fail-closed des enregistrements hérités au runtime, est un pattern de migration sûr pour les systèmes en production avec données existantes.

4. Gate 8 GO en v1 possible quand les corrections sécurité sont faites en étape 7 — les 2 corrections sécurité (S-01, S-02) appliquées avant la gate de clôture ont permis un score élevé (9.125/10) sans itération. La review sécurité adversariale est le filtre le plus efficace.

5. L'extraction automatique de faits Prolog depuis les décorateurs TypeORM fonctionne sans modification — pour les stories crypto-proof, il suffit d'ajouter les @Column dans l'entité pour que extract-facts.py génère les faits Prolog correspondants. Aucune intervention manuelle sur l'extracteur n'est nécessaire.

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