PD-81 — Review Plan d'implémentation (Gate 5 Phase 1)¶

Type : Non-conformité Spec
Référence : Spec §2.1, §3 (TSP), INV-81-02, AC-81-01 / Plan §1 H-01
Description : Le plan pose comme hypothèse « TSP réel non disponible » avec stub ITspVerifier « suffisante avec TODO ». La spec contractuelle impose explicitement une vérification eIDAS via TSP réel au moment de l'instruction.
Impact : Rupture directe de conformité judiciaire et de non-répudiation ; invalide le caractère contractuel de la qualification de mandat.
Gravité : BLOQUANT

Type : Test irréalisable
Référence : Tests N1, E02, E03, E04, E05, E15 / Plan §1 H-01, §11
Description : Les scénarios dépendant de la vérification eIDAS réelle (signature, chaîne, CRL/OCSP, indisponibilité TSP) ne sont pas démontrables contractuellement avec un stub déclaré « suffisant ».
Impact : Impossibilité d'audit externe probant sur AC-81-01/02 et INV-81-02.
Gravité : BLOQUANT

Type : Test irréalisable
Référence : Tests L5, R7 / Spec §3 (destructionDeadline min 60s), §10 / Plan §3 (scheduler destruction 60s)
Description : Avec une cadence de destruction à 60s et un destructionDeadline contractuellement configurable à 60s minimum, la conformité stricte au délai maximal n'est pas démontrable en présence de jitter/latence d'ordonnancement.
Impact : Risque d'échec de preuve de respect des délais contractuels de destruction.
Gravité : MAJEUR

Type : Test irréalisable
Référence : Tests S4, R4-R7, L1-L5 / Plan §11 (mocking PostgreSQL, Redis) + §9 (trigger append-only)
Description : La stratégie d'intégration annoncée avec mocking PostgreSQL/Redis ne permet pas d'établir de manière opposable les comportements liés au trigger append-only DB, à la concurrence transactionnelle, et au rate-limiting effectif.
Impact : Couverture d'intégration non probante pour invariants de traçabilité, concurrence et anti-abus.
Gravité : MAJEUR

Type : Non-conformité Spec
Référence : Spec §3 (Source et vérification de bobPublicKey), INV-81-11 / Plan §1 H-04
Description : Le rapprochement IAM de bobPublicKey est basé sur un stub ILegalIdentityResolver (« adapter si IAM intégré »), alors que la spec impose une vérification effective contre une identité judiciaire autorisée.
Impact : Lien identité-clé non garanti contractuellement ; risque d'acceptation d'autorité non autorisée.
Gravité : MAJEUR

Type : Hypothèse implicite
Référence : Spec §10 (fenêtre révocation 5s), INV-81-10, INV-81-11 / Plan §8
Description : Le plan mentionne la concurrence SERIALIZABLE et un risque « concurrence 5s », mais ne documente pas explicitement la source de temps de référence et la règle d'observabilité contractuelle de « confirmation de révocation » servant de borne opposable.
Impact : Ambiguïté auditabilité sur le respect de la fenêtre contractuelle de 5 secondes.
Gravité : MAJEUR

Type : Risque sécu/conformité
Référence : INV-81-10, AC-81-13 / Plan §1 H-05, §8
Description : L'isolation Legal PRE repose sur un discriminant storageDomain='LEGAL' (pas de schéma séparé), ce qui introduit un risque de contournement par erreur de requête/filtrage applicatif.
Impact : Cloisonnement insuffisamment robuste au regard d'un audit tiers ; risque de mélange Legal PRE / PRE standard.
Gravité : MAJEUR

Type : Non-conformité Spec
Référence : Spec §10 (ancrage max 24h), INV-81-08 / Plan §1 H-07
Description : Le respect de la borne contractuelle 24h est supposé (« cadence existante respecte 24h ») et non porté comme contrainte d'exécution explicitement imposée par le plan.
Impact : Conformité probatoire dépendante d'un prérequis externe non garanti contractuellement.
Gravité : MAJEUR

Type : Code Contract — Cohérence
Référence : Interfaces publiques (Spec §9.1/§9.2)
Description : Le document fourni ne donne pas le détail des signatures d'interfaces par module ; la cohérence stricte entre interfaces contractuelles (orchestrateur PD-81 + extension PD-41) et code contracts n'est pas vérifiable.
Impact : Audit externe impossible sur l'alignement exact des frontières API/ports avec la spec contractuelle.
Gravité : MAJEUR

Type : Code Contract — Forbidden
Référence : Ensemble des modules (section forbidden)
Description : Les patterns interdits sont mentionnés mais non exposés dans le contenu fourni ; leur justification par la spec/sécurité ne peut pas être contrôlée.
Impact : Non-vérifiabilité de la politique de prévention des implémentations non conformes.
Gravité : MAJEUR

Type : Code Contract — Invariant
Référence : Mapping invariants modules ↔ INV-81-*
Description : Le détail des invariants module par module n'est pas présent ; il est impossible de vérifier qu'ils restent strictement un sous-ensemble des invariants contractuels (sans ajout/affaiblissement).
Impact : Risque de divergence silencieuse entre contrat et implémentation sans détectabilité documentaire.
Gravité : MAJEUR

Type : Contrainte technique non documentée
Référence : Plan global / Dépendances inter-PD
Description : Les dépendances inter-PD ne sont pas listées avec statut explicite DONE/TODO/STUB acceptable.
Impact : Traçabilité contractuelle incomplète des prérequis externes.
Gravité : MINEUR

Type : Contrainte technique non documentée
Référence : Plan §11
Description : Le framework de test (Jest ou Vitest) n'est pas explicitement nommé.
Impact : Ambiguïté de reproductibilité des suites de test.
Gravité : MINEUR

Type : Contrainte technique non documentée
Référence : Plan §11
Description : Compatibilité ESM/CJS non documentée (dépendances ESM-only non identifiées, runner non précisé).
Impact : Risque d'échec d'exécution tests/CI et non-reproductibilité de l'audit.
Gravité : MAJEUR

Type : Contrainte technique non documentée
Référence : Plan §11 (tests d'intégration)
Description : Variables CI nécessaires (DATABASE_URL, CI=true, etc.) non documentées.
Impact : Exécution d'intégration non déterministe selon environnement.
Gravité : MINEUR