PD-81 — Dossier de Conformité Gate 5 v2 (AMBIGUITY)¶

Date : 2026-02-23 Version : v2 Itération : 2 Plan évalué : PD-81-plan.md v1.2.0

1. Synthèse des corrections v1 → v2¶

Le plan v1.2.0 adresse les 11 écarts identifiés en v1, dont 3 BLOQUANTS (tous résolus) et 5 MAJEURS (tous corrigés). Les corrections sont substantielles, tracées par des marqueurs [CORRECTION v2], et cohérentes entre le plan et les code-contracts.

Bilan v2 : - Écarts v1 corrigés : 10/11 pleinement, 1 partiellement (R-ANCHOR) - Divergences résiduelles : 1 MAJEURE, 2 MINEURES - Zones d'ombre : 4 (non bloquantes pour l'implémentation) - Nouveaux BLOQUANTS : 0

2. Résolution des écarts BLOQUANTS v1¶

BLQ-01 — ERR-81-11 : Chemin explicite pour tentatives write/delete → RÉSOLU¶

Correction : Ajout du LegalWriteBlockGuard (plan §3.6) qui intercepte PUT/PATCH/DELETE sur /legal-pre/**, émet événement ACCESS_DENIED_WRITE_ATTEMPT, et retourne 403.
Vérification : Guard ajouté dans l'arborescence, le module NestJS, les code-contracts (module 10), le mapping tests (E11 → legal-write-block.guard.spec.ts), et le mapping INV-81-06.
Statut : CONFORME

BLQ-02 — TSP stub posé comme "suffisant" → RÉSOLU¶

Correction : Plan §1 H-01 reformulé comme "dette technique tracée" avec mention AC-81-01-PARTIAL et obligation de story de dépendance TSP réel.
Vérification : La formulation reconnaît explicitement que la conformité eIDAS complète nécessite le TSP réel. Le stub est un choix d'implémentation incrémentale, pas une suffisance.
Statut : CONFORME (dette technique documentée)

BLQ-03 — `GenerateLegalReKeyInput` avec `ownerSecretKey`/`ownerSigningKey` hors spec §9.2 → RÉSOLU¶

Correction : Plan §3.3 — champs retirés, signature strictement conforme à generateLegalReKey(alicePublicKey, bobPublicKey, contextId, legalConstraints).
Vérification : Commentaire explicite indiquant la conformité avec §9.2 et que les secrets sont gérés en interne par PD-41.
Statut : CONFORME

3. Résolution des écarts MAJEURS v1¶

MAJ-01 — AC-81-14 : `getLegalAuditProof` restriction `ownerUserId` → RÉSOLU¶

Correction : Ajout de la vérification via ILegalIdentityResolver.resolveInternalValidator(requesterId, 'audit_delegate').
Statut : CONFORME

MAJ-02 — Role `admin` dans guard non rattaché à spec → RÉSOLU¶

Correction : admin retiré, seuls dpo, legal_officer, vault_owner autorisés.
Statut : CONFORME

MAJ-03 — `bobPublicKey` contrôle non formalisé bloquant → RÉSOLU¶

Correction : Plan §1 H-04 reformulé + §3.5.3 étapes 4a/4b ajoutées (vérification TSP + rapprochement IAM, fail-closed ERR_BOB_IDENTITY_UNVERIFIED).
Statut : CONFORME

MAJ-04 — Champs snippet monitoring non alignés → RÉSOLU¶

Correction : eventAt, anchoringBatchRef, event.eventId corrigés.
Statut : CONFORME

MAJ-05 — Code-contracts : invariants internes vs contractuels → RÉSOLU¶

Correction : Préfixe CONTRAINTE INGENIERIE (non INV-81-*) ajouté.
Statut : CONFORME

4. Divergences résiduelles¶

D-01 — Scénario R-ANCHOR : traçabilité dans le référentiel de tests (MAJEURE)¶

Constat : Le mécanisme de monitoring ancrage 24h est décrit et testé dans l'implémentation (legal-anchoring-monitor.scheduler.spec.ts), mais n'a pas de scénario dans le cahier de tests contractuels PD-81-tests.md.
Impact : INV-81-08 mentionne "délai max 24h" mais aucun scénario du référentiel QA contractuel ne le valide.
Mitigation : Le plan v1.2.0 documente que le test est d'implémentation interne. Le mécanisme lui-même est complet (scheduler 6h, seuil 18h, ancrage forcé). La couverture fonctionnelle de INV-81-08 est assurée par E13, E14 (fail-closed HSM/TSA).
Criticité : MAJEURE — traçabilité QA, pas un défaut de design.

D-02 — `LegalWriteBlockGuard` scope `/legal-pre/**` vs documents WORM (MINEURE)¶

Constat : Le guard intercepte toutes les méthodes PUT/PATCH/DELETE sur /legal-pre/** alors que la spec parle de "tentative de modification/suppression document".
Impact : Protection défense-en-profondeur plus large que strictement requis, mais acceptable.
Criticité : MINEURE

D-03 — Résolution `alicePublicKey`/`bobPublicKey` dans `activateLegalAccess` (MINEURE)¶

Constat : Le chemin de résolution de ces clés depuis le legalCaseId n'est pas explicite dans la séquence d'orchestration.
Impact : Information implicitement disponible (mandat contient bobPublicKey, coffre fournit alicePublicKey).
Criticité : MINEURE

5. Zones d'ombre¶

ID	Description	Bloquant impl. ?
ZO-01	Story de dépendance TSP réel non référencée (pas de PD-XXX)	Non
ZO-02	Résolution `alicePublicKey` dans flux `activateLegalAccess`	Non
ZO-03	Politique de rétention preuves composites et journaux (spec §2.3 point 6)	Non
ZO-04	Ambiguïté fenêtre 5s revocation vs consultations en cours	Non

6. Scores proposés¶

Axe	Score v1	Score v2 proposé	Justification
feasibility	8	8	Inchangé — le plan reste réalisable, les stubs sont documentés
coverage	9	9	Inchangé — couverture INV/AC/ERR complète
risk_mitigation	6	8	Les deux risques majeurs v1 (ECT-07 isolation, ECT-08 ancrage) sont désormais adressés : custom repository avec filtre systématique + monitoring scheduler 6h. La divergence D-01 (traçabilité QA R-ANCHOR) est réelle mais le mécanisme technique est complet.
coherence	8	9	Alignement des champs, retrait du rôle admin, signature conforme §9.2, contrôle bobPublicKey formalisé — la cohérence interne est nettement améliorée

Moyenne proposée : (8 + 9 + 8 + 9) / 4 = 8.50/10

7. Recommandation¶

Verdict recommandé : GO (tous les scores >= 8, moyenne 8.50)

Les 3 BLOQUANTS v1 sont résolus. Les 5 MAJEURS v1 sont corrigés. La divergence résiduelle D-01 (MAJEURE) concerne la traçabilité QA contractuelle du monitoring ancrage, pas un défaut de design technique. Elle peut être adressée par un scénario additionnel dans le cahier de tests lors de l'étape 6 (implémentation) sans bloquer le plan.