PD-82 — Retour d'Expérience (REX)¶

Date : 2026-02-17 Story : PD-82 - Implémenter validation double (parent + autorité) Domaine : crypto Complexité : HIGH

1. Résumé de la story¶

Objectif : Implémenter un mécanisme de validation 2-of-2 multisig pour l'activation du PRE (Proxy Re-Encryption) sur les coffres mineurs. Le parent ET une autorité judiciaire doivent tous deux valider avant que la délégation cryptographique ne soit activée.

Livrables : - Module NestJS DualValidationModule complet - State machine pour les transitions d'état - Service de vérification de signature X.509/eIDAS - Client TSA RFC 3161 (stub) - Controller REST avec guards d'accès - 106 tests unitaires

2. Métriques du workflow¶

3. Points forts¶

3.1 Architecture State Machine¶

L'utilisation d'une state machine explicite pour les transitions d'état s'est révélée très efficace : - Transitions déterministes et testables - Invariants vérifiables formellement - Code lisible et maintenable

Pattern réutilisable : Ce pattern de state machine avec TransitionResult { newState, isActivation, isTerminal } peut être réutilisé pour d'autres workflows à états (PD-41 PRE activation, PD-31 audit states).

3.2 Séparation des responsabilités¶

La séparation claire entre : - DualValidationStateMachineService (transitions pures) - DualValidationService (orchestration business) - SignatureVerificationService (crypto) - TsaClientService (horodatage)

A facilité les tests unitaires et la maintenance.

3.3 Conformité eIDAS¶

L'intégration des niveaux eIDAS (substantial/high) dans le modèle de données permet une traçabilité juridique complète, conforme aux exigences ProbatioVault.

4. Difficultés rencontrées¶

4.1 TypeScript Strict Mode¶

Problème : Les DTOs avec class-validator décorateurs nécessitent une initialisation, incompatible avec le strict mode TypeScript.

Solution : Utilisation du modificateur ! (definite assignment assertion) sur les propriétés des DTOs.

Recommandation : Documenter ce pattern dans les conventions TypeScript du projet.

4.2 ESLint security/detect-object-injection¶

Problème : Accès aux objets par clé dynamique (obj[key]) déclenchent des warnings de sécurité.

Solution : Remplacement par des switch statements explicites.

Impact : Code plus verbeux mais plus sûr.

4.3 Couverture branches globale¶

Problème : Le pipeline CI échouait car la couverture branches globale du projet était à 79.99% (seuil: 80%).

Solution appliquée : Ajout d'un test dans auth-audit.interceptor.spec.ts pour couvrir la branche ligne 155 (traitement des éléments non-string dans les arrays).

Résultat : Couverture branches globale : 80.02% ✅

4.4 SonarQube Elasticsearch (incident serveur)¶

Problème : Job SonarQube échouait avec "Unrecoverable indexing failures" - Elasticsearch bloqué en read-only.

Cause : Disque à 95% sur serveur SonarQube → flood-stage watermark ES activé.

Solution : Nettoyage Docker (images, volumes dangling) → disque à 56%.

Leçon : Surveiller l'espace disque des serveurs CI/CD.

5. Écarts par rapport au plan¶

Aucun écart majeur. Les stubs sont conformes aux interfaces définies et permettront une intégration future sans modification de l'architecture.

6. Learnings¶

6.1 Pour le workflow de gouvernance¶

1. Gate 8 scoring : Le scoring multi-critères (conformity, coverage, security, maintainability) donne une vue équilibrée de la qualité.

2. Tests précoces : Écrire les tests en parallèle de l'implémentation (pas après) accélère le cycle.

3. Stubs explicites : Documenter clairement les stubs avec TODOs et références aux stories de dépendance facilite le suivi.

6.2 Pour l'architecture¶

1. State machines : Préférer des state machines explicites aux conditions imbriquées pour les workflows complexes.

2. Transactions SERIALIZABLE : Pour les opérations critiques (validation 2-of-2), le niveau d'isolation SERIALIZABLE est nécessaire malgré le coût performance.

3. Validation eIDAS : Les niveaux substantial/high doivent être capturés au moment de la signature, pas inférés après.

7. Recommandations¶

7.1 Court terme (ce sprint)¶

• Créer story technique pour améliorer couverture branches globale → Résolu par ajout test auth-audit.interceptor
• Merger PD-82 après résolution du problème de coverage → Pipeline vert, mergé sur dev

7.2 Moyen terme (prochains sprints)¶

• Intégrer PD-41 PRE pour l'activation réelle
• Intégrer PD-31 audit log pour la traçabilité
• Implémenter client TSA réel avec freetsa.org ou service interne

7.3 Long terme¶

• Intégration HSM pour signature verification réelle
• Tests E2E avec certificats X.509 réels
• Audit de sécurité externe

8. Satisfaction¶

Score global : 8/10

Justification : - (+) Architecture propre et extensible - (+) Tests complets avec bonne couverture - (+) Conformité aux invariants et CA - (-) Blocage pipeline (externe à PD-82) - (-) Temps passé sur les corrections TypeScript strict mode

REX rédigé le 2026-02-17 Workflow de gouvernance ProbatioVault