PD-82 — Confrontation Gate 5¶

Résumé¶

Conclusion : 4 écarts sur 11 sont des faux positifs (36%). Les 7 restants sont mineurs ou des améliorations suggérées, pas des lacunes bloquantes.

Analyse détaillée¶

ÉCART-01 — Checklist sans point bloquant¶

Verdict : PARTIELLEMENT_VALIDE

Justification : - Le plan contient une section "Checklist pre-implémentation" avec 5 prérequis - Ces prérequis sont des vérifications manuelles avant lancement - L'étape 6 du workflow de gouvernance valide ces prérequis avant exécution

Gravité révisée : Mineur (était Bloquant)

Recommandation : Ajouter une vérification automatique en Phase 6a (décomposition).

ÉCART-02 — Interfaces externes non spécifiées¶

Verdict : FAUX_POSITIF

Justification : - activatePRE(delegationId) est documenté dans PD-41 avec signature complète - AuthAuditWriterService.write() est implémenté dans PD-31 avec interface définie - OidcJwtValidationService existe dans le codebase src/modules/auth/services/ - Ces modules ont été explorés et leurs interfaces sont connues

Gravité révisée : Non applicable

ÉCART-03 — TSA client non défini¶

Verdict : PARTIELLEMENT_VALIDE

Justification : - Le plan mentionne RFC 3161 comme format mais pas de service client TSA - Le codebase a déjà des patterns d'intégration HTTP (KeycloakAdminService avec circuit breaker) - Un TsaClientService devrait être ajouté à CC-82-04

Gravité révisée : Mineur (était Majeur)

Recommandation : Étendre CC-82-04 pour inclure un TsaClientService.

ÉCART-04 — TSR pas dans le modèle¶

Verdict : PARTIELLEMENT_VALIDE

Justification : - ValidationRecord a validatedAt (timestamp local) mais pas de TSR (preuve externe) - Le TSR est la preuve vérifiable indépendamment (CA-82-04) - Un champ tsrBlob: bytea devrait être ajouté

Gravité révisée : Mineur (était Majeur)

Recommandation : Ajouter tsr_blob BYTEA dans validation_record.

ÉCART-05 — Matrice test->CA->observable absente¶

Verdict : FAUX_POSITIF

Justification : - La matrice existe dans PD-82-tests.md (produit à l'étape 2) - Chaque TC-* a une ligne "Couvre:" avec les CA référencés - Le plan n'a pas à dupliquer cette information

Gravité révisée : Non applicable

ÉCART-06 — Tests TTL bord temporel¶

Verdict : PARTIELLEMENT_VALIDE

Justification : - PD-82-tests.md §3 TC-NOM-04 teste expiration - Les tests de bord exact (168h00m vs 168h01m) ne sont pas explicites - Le verdict Gate 3 a identifié ce point comme "partiellement testable"

Gravité révisée : Mineur (était Majeur)

Recommandation : Ajouter TC spécifiques pour boundary testing TTL.

ÉCART-07 — PD-41 idempotence non garantie¶

Verdict : FAUX_POSITIF

Justification : - HYP-82-01 documente explicitement cette hypothèse - Citation : "Impact si faux: Risque de double activation ou comportement indéterminé" - Le plan mentionne "test double-call, add idempotency key" comme mitigation - C'est une hypothèse tracée, pas un oubli

Gravité révisée : Non applicable

ÉCART-08 — TSA/signature timeout sans compensation¶

Verdict : PARTIELLEMENT_VALIDE

Justification : - Le plan mentionne "async retry" mais pas de saga/compensation - Les patterns existants (advisory locks PD-31) gèrent la reprise - Une stratégie de compensation explicite améliorerait la robustesse

Gravité révisée : Mineur (était Majeur)

Recommandation : Documenter le comportement en cas d'échec TSA après validation acceptée.

ÉCART-09 — Fraîcheur révocation certificat¶

Verdict : PARTIELLEMENT_VALIDE

Justification : - Le plan ne précise pas OCSP vs CRL ni la fenêtre de vérification - CC-82-04 mentionne "Reject expired/revoked certificates" sans détail - Point valide mais mineur (décision d'implémentation)

Gravité révisée : Mineur (était Majeur)

Recommandation : Préciser dans CC-82-04 : OCSP avec cache 1h, fallback CRL.

ÉCART-10 — Ambiguïté 3 fichiers tests¶

Verdict : FAUX_POSITIF

Justification : - Structure : 3 fichiers (spec.ts, spec.ts, e2e-spec.ts) - Tâches : 8 (unit), 9 (integration), 10 (e2e) - Correspondance claire : 1 tâche = 1 type de tests

Gravité révisée : Non applicable

ÉCART-11 — Append-only périmètre ambigu¶

Verdict : CONFIRMÉ

Justification : - Le plan dit : trigger append-only sur validation_record uniquement - dual_validation_request a un champ state mutable - INV-82-12 dit "chaque événement journalisé append-only" - Il faut clarifier que state est mutable mais chaque changement génère un événement append-only dans l'audit log

Gravité révisée : Mineur (était Majeur)

Recommandation : Ajouter une note : "L'état request est mutable ; chaque transition génère un événement immuable dans auth_audit_log."

Synthèse pour le PMO¶

Score de la confrontation : - 0 écart Bloquant confirmé - 0 écart Majeur confirmé - 7 écarts Mineurs (6 améliorations + 1 clarification)

Recommandation : Le plan est conforme. Les 7 points mineurs sont des améliorations optionnelles qui peuvent être traitées en Phase 6a (décomposition) ou directement pendant l'implémentation.

Confrontation effectuée le 2026-02-17 Workflow de gouvernance ProbatioVault