PD-81 — Confrontation Gate 5 (Phase 2)¶

ECT-01 : Nuancé
Justification : L'écart est réel — la spec §2.1 impose un "TSP réel" et le plan pose H-01 avec stub.
Cependant, le plan ne l'ignore pas : H-01 trace explicitement un TODO pour l'intégration réelle,
V-03 documente que "le stub ne vérifie rien réellement" avec TODO tracé explicite, et l'interface
ITspVerifier est conçue pour "garantir la substitution future". Le plan reconnaît donc la lacune
et la borne volontairement. Ce n'est pas un oubli mais un choix d'implémentation incrémentale
avec traçabilité. L'écart est réel mais consciemment mitigé.

ECT-02 : Nuancé
Justification : Les scénarios eIDAS ne sont effectivement pas démontrables cryptographiquement
avec un stub. Toutefois, le code contract Module 14 interdit explicitement tout "test qui dépend
d'un service externe réel (HSM, TSP, TSA)" et Module 3 impose INV-81-02 "Aucun mandat accepté
sans vérification TSP complète" — ce qui s'applique au stub via l'interface. Le plan §11 prévoit
des tests d'intégration avec "mocks HSM/TSP/TSA" et une DB réelle. Les scénarios N1, E02-E05,
E15 sont testables au niveau contractuel (appel effectif à ITspVerifier, vérification des rejets),
même si la preuve cryptographique eIDAS réelle reste hors périmètre du stub. L'écart est réel
sur la démonstration eIDAS complète, mais partiellement couvert par la stratégie de test déclarée.

ECT-03 : Injustifié
Justification : La review confond destructionDeadline (délai configuré avant destruction) et
cadence du scheduler. La spec §7.3 fixe destructionDeadline par défaut à 3600s (1 heure),
configurable [60..86400]. Le plan §3.7 confirme : scheduler destruction à 60s de cadence,
avec "La destruction intervient au plus tard 60s après l'entrée dans l'état terminal, bien
en dessous du deadline par défaut de 1h." Le scénario critique (deadline=60s + cadence=60s)
est un cas limite configurable, pas le cas par défaut. La conformité est démontrable.

ECT-04 : Nuancé
Justification : Le plan §11 prévoit explicitement "PostgreSQL : Base de test dédiée" et
"Redis : Instance de test" dans la stratégie d'intégration. Les tests d'intégration utilisent
donc une DB et un Redis réels, pas des mocks. Cependant, le trigger append-only et l'isolation
SERIALIZABLE ne sont pas explicitement validés par un test nommé dans le plan. L'écart est
partiellement justifié sur le manque de tests dédiés à ces mécanismes spécifiques, mais la
review est inexacte en affirmant que tout repose sur des mocks.

ECT-05 : Nuancé
Justification : La spec §2.3 liste explicitement "Source de vérité de l'identité juridique
interne" comme information manquante à préciser. Le plan H-04 pose un stub précisément
parce que cette information n'est pas encore disponible — conformément à la spec. L'écart
est réel mais la spec elle-même identifie ce point comme non résolu.

ECT-06 : Injustifié
Justification : Le plan §8.5 documente explicitement le mécanisme : "la révocation pose
status=REVOKED dans une transaction SERIALIZABLE ; les consultations concurrentes voient
REVOKED immédiatement après commit." La source de temps est la transaction elle-même
(commit = confirmation), et l'observabilité est l'isolation SERIALIZABLE. Le point est couvert.

ECT-07 : Raison
Justification : Ni le plan ni les code contracts ne documentent de mécanisme empêchant une
requête qui omettrait le filtre storageDomain (guard, middleware, intercepteur, default scope,
ou row-level security). L'invariant INV-81-10 déclare la valeur mais pas le mécanisme de
protection contre l'oubli du discriminant. Le risque de contournement par erreur de requête
est réel et non adressé.

ECT-08 : Raison
Justification : Le plan H-07 affirme "Le délai max 24h est respecté par la cadence de batch
existante" sans documenter ni la cadence effective du batch existant, ni un mécanisme de
garantie (monitoring, alerte, fallback) en cas de dépassement. L'écart est réel.

ECT-09 : Injustifié
Justification : Le code contract détaille les interfaces par module. La review affirme que le
"détail des signatures d'interfaces par module" n'est "pas fourni" — c'est un problème de
périmètre de la review (prompt résumé vs documents complets), pas un écart du plan.

ECT-10 : Injustifié
Justification : Les code contracts exposent explicitement les patterns interdits par module
avec exemples détaillés. La review affirme qu'ils sont "mentionnés mais non exposés" —
les extraits fournis contredisent directement cette affirmation.

ECT-11 : Nuancé
Justification : Les code contracts listent des invariants par module mais les extraits de la
review ne couvraient que certains modules. Le fichier YAML complet contient les 17 modules
avec leurs invariants. L'écart est lié à l'incomplétude des extraits dans le prompt review.

ECT-12 : Raison
Justification : Aucune section du plan ne liste explicitement les dépendances inter-PD avec
un statut DONE/TODO/BLOCKED. L'écart est réel.

ECT-13 : Raison
Justification : Le plan ne nomme jamais explicitement le framework de test (Jest, Vitest).
L'écart est réel, même si mineur.

ECT-14 : Nuancé
Justification : Le plan ne documente pas explicitement le choix ESM vs CJS. Cependant, le
contexte NestJS impose une configuration TypeScript/CJS connue. La criticité "MAJEUR" est
discutable.

ECT-15 : Raison
Justification : Les variables d'environnement requises ne sont pas documentées. L'écart est
réel, même si mineur.