PD-81-REVIEW-STEP5-V2

  Type : Non-conformité Spec
Référence : Spec §9.1 getLegalAuditProof (post-condition) / AC-81-14 / Plan §3.5.7 getLegalAuditProof + §6 (AC-81-14)
Description : Le plan restreint l’autorisation à requesterId === ownerUserId uniquement, alors que la spec exige ownerUserId ou un role explicitement délégué dans IAM.
Impact : Le contrat fonctionnel d’accès audit est restreint par rapport à la spec canonique; non-conformité contractuelle sur un point d’habilitation.
Gravité : MAJEUR

Type : Risque sécu/conformité
Référence : Spec §5 N2 / Spec §9.1-§9.2 (roles explicitement cadrés) / Plan §3.6 legal-pre-access.guard.ts
Description : Le plan autorise le role admin dans LegalPreAccessGuard sans rattachement explicite dans la spec contractuelle Legal PRE.
Impact : Extension implicite du périmètre d’accès; augmentation de surface d’exposition sur opérations légales probatoires.
Gravité : MAJEUR

Type : Test irréalisable
Référence : Tests E11 (ERR-81-11) / Spec §6 ERR-81-11 / Plan §3.5.3 validateConsultationAccess + §3.8 Controller + §7 ERR-81-11
Description : Le plan justifie ERR-81-11 principalement par l’absence d’endpoint d’écriture/suppression; ce design ne décrit pas de chemin explicite garantissant l’émission d’un événement de violation lors d’une tentative write/delete, attendu par le référentiel de tests.
Impact : Le scénario E11 ne dispose pas d’un point d’observabilité explicite conforme (refus strict + journalisation probatoire de la tentative).
Gravité : BLOQUANT

Type : Non-conformité Spec
Référence : Spec §2.1 (TSP reel obligatoire) / AC-81-01 / Plan §1 H-01 + §2 (providers tsp-verifier.stub.ts)
Description : Le plan acte qu’un stub TSP est “suffisant pour l’implémentation” avec TODO d’intégration ultérieure, alors que la conformité contractuelle impose une vérification eIDAS via TSP réel.
Impact : Affaiblissement explicite d’une exigence contractuelle centrale; risque de rejet en audit tiers.
Gravité : BLOQUANT

Type : Hypothèse implicite
Référence : Spec §9.2 generateLegalReKey (source + vérification bobPublicKey via TSP puis IAM) / Plan §1 H-04 + §3.5.3 generateLegalReKey
Description : Le mécanisme de contrôle bobPublicKey (double vérification TSP + IAM) est posé en hypothèse/stub mais n’est pas formalisé comme contrôle bloquant explicite dans la séquence de génération ReKey.
Impact : Dépendance de sécurité critique non garantie par le design opérationnel décrit; risque d’acceptation d’identité judiciaire non démontrée.
Gravité : MAJEUR

Type : Couverture manquante
Référence : Plan §5 (INV-81-08 “Test R-ANCHOR”) / Document tests PD-81-tests.md
Description : Le plan référence un scénario R-ANCHOR pour valider le monitoring d’ancrage 24h, mais ce scénario n’existe pas dans le cahier de tests fourni.
Impact : Le mécanisme ECT-08 n’a pas de traçabilité de validation explicite dans la base de tests contractuelle.
Gravité : MAJEUR

Type : Hypothèse implicite
Référence : Plan §8.6 LegalAnchoringMonitorScheduler (snippet) / Plan §3.4 legal-access-event.entity.ts
Description : Le snippet de monitoring utilise des champs non alignés avec l’entité décrite (createdAt vs eventAt, anchoringBatchId vs anchoringBatchRef, event.id vs event.eventId).
Impact : Incohérence de design interne; fiabilité de la détection 18h/24h non démontrable sur la base du plan seul.
Gravité : MAJEUR

Type : Non-conformité Spec
Référence : Spec §9.2 signature contractuelle generateLegalReKey(alicePublicKey, bobPublicKey, contextId, legalConstraints) / Plan §3.3 GenerateLegalReKeyInput
Description : Le plan ajoute ownerSecretKey et ownerSigningKey dans l’interface d’entrée, éléments non prévus par l’interface contractuelle.
Impact : Introduction d’un comportement non spécifié et exposition potentielle de secrets dans les frontières de service.
Gravité : BLOQUANT

Type : Code Contract — Invariant
Référence : PD-81-code-contracts.yaml (plusieurs modules, ex. module 14: “Couverture >= 85% sur chaque fichier service”, module 17: métriques/monitoring) / Règle axe 6 “invariants code contract sous-ensemble de la spec”
Description : Plusieurs invariants des code contracts ne sont pas un sous-ensemble des invariants contractuels de la spec PD-81 (ils ajoutent des exigences process/qualité internes non présentes dans INV-81-*).
Impact : Dilution du référentiel contractuel; ambiguïté d’audit entre obligations métier/juridiques et contraintes internes d’ingénierie.
Gravité : MAJEUR

Type : Code Contract — Cohérence
Référence : PD-81-code-contracts.yaml module 5 / Plan §11.6 (dépendance PD-41 mentionnée PreService.reDecrypt())
Description : Incohérence d’interface entre le plan et les contracts sur l’API PRE appelée (le reste du plan parle de reEncrypt, la dépendance inter-PD cite reDecrypt).
Impact : Contrat d’intégration PD-41 ambigu; risque de divergence d’implémentation inter-modules.
Gravité : MINEUR

Type : Contrainte technique non documentée
Référence : Plan §11.5 / §11.6
Description : Aucune absence identifiée sur les 4 éléments requis (dépendances inter-PD, framework de test explicite, compatibilité ESM/CJS, variables CI).
Impact : N/A
Gravité : MINEUR