PD-251 — Plan d'implémentation Review (v1)¶

Gate : 5 — AMBIGUITY Reviewer : Claude (orchestrateur) Documents analysés : PD-251-specification.md, PD-251-tests.md (v2), PD-251-plan.md, PD-251-code-contracts.yaml Date : 2026-02-25

Axe 1 — Conformité stricte à la spécification¶

CONF-01 — CA-251-06 mapping : gel effectif vs restauration réussie¶

• Type : Non-conformité Spec
• Référence : Plan §7, CA-251-06 vs Spec CA-251-06
• Description : Dans le mapping CA→Mécanismes (section 7 du plan), CA-251-06 est associé à restoration.service avec description "RESTORED + CORRUPTED_ARCHIVED + ArchiveVersionLink". C'est correct pour la spec CA-251-06. Cependant, le plan attribue aussi CA-251-06 à TASK-4 (forensic/restore) et les tests TC-251-08/TC-251-09, ce qui est correct. Pas d'écart réel.
• Impact : Aucun — vérification positive.
• Gravité : Néant (pas d'écart)

CONF-02 — scopeMode : valeurs non contraintes¶

• Type : Non-conformité Spec
• Référence : Spec §3.6 vs Plan §4.1 migration
• Description : La spec mentionne "politiques de scope (complet, partitionné, rotatif)" mais ne définit pas formellement les valeurs possibles comme enum. Le plan définit scope_mode VARCHAR(20) avec commentaire 'FULL' | 'PARTITIONED' | 'ROTATIVE'. C'est une interprétation raisonnable mais non contractualisée dans la spec.
• Impact : Risque mineur d'incohérence entre implémentation et futures évolutions.
• Gravité : MINEUR

CONF-03 — Formule priorityScore (résolution AMB-02)¶

• Type : Conformité vérifiée
• Référence : Plan §3.1 vs Spec §3.5
• Description : Le plan définit une formule linéaire pondérée w_legal*0.40 + w_age*0.25 + w_crit*0.35. La spec ne contractualise aucune formule mais exige un score 0.00-1.00 basé sur 3 critères (statut juridique, âge, criticité). La résolution est conforme et auditable (poids loggés). La contrainte w_legal + w_age + w_crit = 1.0 garantit le range [0,1].
• Impact : Aucun — résolution acceptable de l'écart AMB-02.
• Gravité : Néant

Axe 2 — Couverture des invariants¶

COV-01 — INV-251-06 : mécanisme de blocage cross-module¶

• Type : Couverture manquante (partielle)
• Référence : INV-251-06 vs Plan §2.2 + TASK-7
• Description : INV-251-06 exige le blocage lecture/export pour archives SUSPECT. Le plan crée un ArchiveAccessGuard dans TASK-7 et mentionne "Intégrer le guard sur les routes de download/export du module documents". Cependant, le plan ne détaille pas QUELLES routes exactes du module documents doivent être protégées, ni comment le guard accède à integrity_state qui est dans vault_integrity tandis que les routes sont dans le module documents.
• Impact : L'implémenteur devra deviner les routes à protéger et le mécanisme de jointure inter-schéma.
• Gravité : MAJEUR

COV-02 — INV-251-15 : réconciliation Merkle non détaillée¶

• Type : Couverture manquante (partielle)
• Référence : INV-251-15 vs Plan TASK-8
• Description : La spec exige "Agrégation / rattrapage Merkle : Async post-commit, réconciliation obligatoire". Le plan mentionne un reconciliation.processor dans TASK-8 mais ne détaille pas comment la réconciliation Merkle fonctionne : quels événements sont rattrapés, comment détecter un écart post-crash, quel mécanisme de comparaison Merkle est utilisé.
• Impact : L'implémenteur manque d'information pour implémenter la réconciliation Merkle.
• Gravité : MAJEUR

Tous les 17 INV sont présents dans le plan et mappés à au moins un mécanisme. Les 2 écarts ci-dessus sont des manques de détail, pas des omissions.

Axe 3 — Cohérence Plan ↔ Tests¶

TEST-01 — TC-251-16 : crash pré/post-commit — mécanisme d'injection¶

• Type : Test irréalisable (partiel)
• Référence : TC-251-16 vs Plan TASK-8
• Description : TC-251-16 exige l'injection contrôlée de crash pré/post-commit. Le plan mentionne la réconciliation mais ne détaille pas le mécanisme d'injection de crash pour les tests (hook de test, mock de transaction, kill process). Sans ce mécanisme, le test n'est pas réalisable en automatisation.
• Impact : TC-251-16 nécessite un mécanisme d'injection de fautes non documenté.
• Gravité : MINEUR (le mécanisme est standard en NestJS/TypeORM — queryRunner.rollbackTransaction() mock)

TEST-02 — TC-251-22 : métriques Prometheus — dépendance prom-client¶

• Type : Hypothèse implicite
• Référence : TC-251-22 vs Plan TASK-7, §9.4
• Description : Le plan mentionne prom-client dans les dépendances npm potentielles mais ajoute "(vérifier existant)". Si prom-client n'est pas installé, le test TC-251-22 et toute la fonctionnalité Prometheus sont bloqués. L'hypothèse 4 du plan suppose que prom-client est déjà installé sans vérification.
• Impact : Blocage potentiel si la dépendance est absente.
• Gravité : MINEUR

Tous les 22 TC et 6 NR sont réalisables avec les mécanismes décrits. Les observables sont définis dans la colonne "Observable" de la section 6.

Axe 4 — Absence d'hypothèses implicites¶

HYP-01 — Table archives : existence et structure¶

• Type : Hypothèse implicite
• Référence : Plan §11 Hypothèse 1, §4.1 migration
• Description : Le plan suppose qu'une table archives existe dans vault_secure avec un UUID comme PK. L'hypothèse est listée explicitement (Hypothèse 1) mais la migration commentée (ALTER TABLE vault_secure.archives ADD COLUMN IF NOT EXISTS integrity_state...) n'est pas vérifiée. Si la table n'existe pas ou a une structure différente, la migration échoue.
• Impact : Risque de blocage en implémentation si la table archives n'existe pas.
• Gravité : MINEUR (hypothèse documentée, mais non vérifiée)

HYP-02 — Redis lock pour concurrence runs¶

• Type : Hypothèse implicite
• Référence : Plan §12 point 6
• Description : Le plan mentionne "lock Redis distribué (integrity:run:lock)" pour éviter les runs concurrents, mais ne précise ni le mécanisme (Redlock, simple SETNX), ni le TTL du lock, ni le comportement si le lock est déjà acquis (attente, rejet, retry).
• Impact : L'implémenteur doit choisir le mécanisme de lock sans guidage.
• Gravité : MINEUR

Axe 5 — Risques sécurité / conformité¶

SEC-01 — PENDING_SIGNATURE : fenêtre sans signature HSM¶

• Type : Risque sécu/conformité
• Référence : Plan §3.3 (HYP-01 résolution) vs INV-251-07
• Description : Le plan propose que si le HSM est indisponible, les snapshots soient créés avec statut PENDING_SIGNATURE et signés ultérieurement par réconciliation. Cependant, INV-251-07 exige "aucune restauration sans snapshot forensique complet signé HSM". Le plan crée une fenêtre temporelle où un snapshot existe sans signature, ce qui pourrait permettre une restauration non autorisée si le guard ne vérifie pas le signature_status.
• Impact : Si le guard de transition vérifie uniquement l'existence du snapshot (pas sa signature), une restauration pourrait démarrer avec un snapshot non signé.
• Gravité : MAJEUR

SEC-02 — Rate limiting opsRateLimit : scope d'application¶

• Type : Risque sécu/conformité
• Référence : Spec §9 point 6 vs Plan §10.1
• Description : La spec définit opsRateLimit à 60 op/min pour les "opérations de vérification/restauration". Le plan l'applique uniquement sur POST /integrity/runs. Les opérations de restauration manuelle, de re-vérification unitaire et de déclenchement de réconciliation ne sont pas rate-limitées.
• Impact : Un acteur avec accès ops pourrait déclencher des restaurations ou réconciliations en rafale.
• Gravité : MINEUR (endpoints ops-only, pas public)

Axe 6 — Code Contracts¶

CC-01 — Complétude : module integrity-foundation et integrity-orchestrator overlap¶

• Type : Code Contract — Frontière
• Référence : integrity-foundation files vs integrity-orchestrator files
• Description : integrity-foundation inclut src/modules/integrity/integrity.module.ts et integrity-orchestrator inclut src/modules/integrity/services/integrity-config-validator.service.ts. Le config validator est logiquement lié à la config (foundation) mais attribué à l'orchestrator. Pas de chevauchement strict de fichiers mais une ambiguïté d'ownership.
• Impact : Deux agents pourraient revendiquer le config validator.
• Gravité : MINEUR

CC-02 — Complétude : 7 code contracts pour 8 tâches¶

• Type : Code Contract — Complétude
• Référence : TASK-8 (Réconciliation + Tests)
• Description : TASK-8 n'a pas de code contract dédié. Le reconciliation.processor est listé dans integrity-orchestrator (processors/**) mais les tests d'intégration et de non-régression n'ont pas de contract.
• Impact : Faible — les tests ne nécessitent pas de contract (pas de code de production).
• Gravité : MINEUR

CC-03 — Invariants : tous les INV de la spec sont couverts¶

• Type : Vérification positive
• Description : Les 17 INV sont répartis dans les 7 code contracts. Aucun INV manquant.
• Gravité : Néant

Axe 7 — Contraintes techniques documentées¶

CT-01 — Dépendances inter-PD : toutes documentées¶

• Type : Vérification positive
• Description : Section 9.1 liste 7 dépendances avec statut DONE pour chacune. Conforme.
• Gravité : Néant

CT-02 — Framework de test : Jest explicite¶

• Type : Vérification positive
• Description : Section 9.2 précise Jest avec ts-jest, tests d'intégration avec PostgreSQL réel, variables CI documentées.
• Gravité : Néant

CT-03 — Compatibilité ESM/CJS : json-canonicalize identifié¶

• Type : Contrainte technique documentée
• Description : Section 9.3 identifie json-canonicalize comme potentiellement ESM-only et propose import() dynamique ou wrapper CJS.
• Gravité : Néant

Synthèse¶

Aucun bloquant. 3 points majeurs : 1. COV-01 : Guard cross-module — routes à protéger non détaillées et jointure inter-schéma 2. COV-02 : Réconciliation Merkle — mécanisme non détaillé 3. SEC-01 : Fenêtre PENDING_SIGNATURE — risque de restauration sans signature HSM