PD-251 — Specification Review (v1)¶

Gate : 3 — CONFORMITY_CHECK Reviewer : Claude (orchestrateur) Documents analysés : PD-251-specification.md, PD-251-tests.md Date : 2026-02-25

Axe 1 — Ambiguïtés¶

AMB-01 — Définition du terme "archive sélectionnée" vs "archive du scope"¶

• Type : Ambiguïté
• Référence : Spec §3.1 + §3.6
• Description : La spec utilise alternativement "archive sélectionnée" (§3.1) et ne définit pas explicitement la politique de sélection au sein du scope de rotation. Le scopeRotationWindow (§3.6) détermine la fenêtre temporelle, mais le mécanisme de partitionnement (comment les archives sont réparties entre les runs) n'est pas contractualisé.
• Impact : Deux implémentations pourraient partitionner différemment et produire des résultats non comparables.
• Gravité : Mineur

AMB-02 — Sémantique de priorityScore : calculé ou assigné ?¶

• Type : Ambiguïté
• Référence : Spec §3.5
• Description : Le champ priorityScore (0.00–1.00) est décrit comme "calculé à chaque run" à partir de 3 critères (statut juridique, âge, criticité contractuelle), mais la formule de calcul ou les poids des critères ne sont pas spécifiés. Le paramètre est défini avec un défaut de 0.50 ce qui laisse penser qu'il pourrait être statique.
• Impact : L'implémenteur devra choisir arbitrairement une formule, rendant le calcul non-contractuel et non-auditable.
• Gravité : Majeur

AMB-03 — Unités SLA détection : mixité minutes/heures¶

• Type : Ambiguïté terminologique
• Référence : Spec §3.4.1
• Description : Haute criticité en minutes (défaut 60), basse criticité en heures (défaut 24). La colonne "Défaut" utilise les mêmes chiffres (60, 24) mais avec des unités différentes, ce qui est une source d'erreur d'implémentation. La note "Unités : minutes pour haute criticité, heures pour basse criticité" est présente mais pourrait ne pas être lue.
• Impact : Risque de confusion d'unité dans l'implémentation (60h au lieu de 60min ou 24min au lieu de 24h).
• Gravité : Mineur (la note existe, mais le risque est réel)

Axe 2 — Contradictions¶

CTR-01 — CA-251-04 vs CA-251-06 : référence croisée des CA¶

• Type : Contradiction
• Référence : Spec CA-251-04 + CA-251-06
• Description : CA-251-04 dit "archive passe en SUSPECT et accès public/export sont bloqués" sur mismatch confirmé. CA-251-06 dit "restauration réussie produit RESTORED + CORRUPTED_ARCHIVED + lien cryptographique". Cependant, la transition SUSPECT → RESTORE_PENDING exige un snapshot HSM (INV-251-07), qui n'est pas mentionné dans le parcours direct CA-251-04 → CA-251-06. Pas une contradiction au sens strict, mais un gap dans la couverture CA : aucun CA ne couvre explicitement la Phase 2 (snapshot forensique) comme étape obligatoire du parcours complet.
• Impact : Un implémenteur pourrait passer de SUSPECT directement à RESTORE_PENDING sans Phase 2 et rester conforme aux CA (bien que violant INV-251-07).
• Gravité : Majeur

CTR-02 — TC-251-04 couvre CA-251-03 mais vise la confirmation (pas l'annulation)¶

• Type : Incohérence Spec↔Tests
• Référence : Tests TC-251-04 (covers CA-251-03)
• Description : CA-251-03 décrit "mismatch transitoire → double vérification annule le faux positif". TC-251-04 teste le cas inverse (corruption confirmée). Couvrir CA-251-03 avec un scénario de corruption confirmée est incorrect — CA-251-03 est le cas où la double vérification invalide le soupçon.
• Impact : La matrice de couverture indique que TC-251-04 couvre CA-251-03, alors qu'il couvre plutôt CA-251-04.
• Gravité : Mineur (TC-251-03 couvre correctement CA-251-03)

Axe 3 — Règles non testables¶

NT-01 — INV-251-01 : "politique configurée" non bornée¶

• Type : Non testable (partiellement)
• Référence : Spec INV-251-01 + §3.6
• Description : "un run planifié DOIT exister et s'exécuter selon la politique configurée" — la politique elle-même (expression cron) n'est pas contractualisée dans la spec. On peut tester qu'un run s'exécute, mais pas qu'il respecte "la politique" si celle-ci est libre.
• Impact : Test TC-251-01 vérifie l'exécution mais pas la conformité à une politique spécifique.
• Gravité : Mineur

NT-02 — Garanties physiques HSM¶

• Type : Non testable
• Référence : Spec §9.1
• Description : Déjà identifié dans les tests. Les propriétés physiques du HSM (FIPS 140-2 Level 3) ne sont pas testables en test applicatif.
• Impact : Audit infrastructure séparé nécessaire.
• Gravité : Mineur (correctement identifié)

Axe 4 — Incohérences de testabilité (Spec ↔ Tests)¶

INC-01 — CA-251-05 : couverture par TC-251-08, pas TC-251-06¶

• Type : Incohérence Spec↔Tests
• Référence : Matrice de couverture CA, TC-251-06
• Description : La matrice de couverture attribue CA-251-05 ("restauration sans snapshot HSM → rejetée") à TC-251-06 (journal append-only signé). TC-251-08 est le scénario qui teste la précondition de snapshot HSM. La matrice indique bien TC-251-08 couvre INV-251-07 et CA-251-07, mais CA-251-05 est mappé sur TC-251-06 ce qui est incorrect.
• Impact : La couverture réelle de CA-251-05 est assurée par TC-251-08, pas TC-251-06.
• Gravité : Mineur (le test existe, le mapping est incorrect)

INC-02 — CA-251-15 : métriques Prometheus non testées spécifiquement¶

• Type : Incohérence Spec↔Tests
• Référence : Spec CA-251-15, matrice tests
• Description : CA-251-15 exige "métriques Prometheus exposent volumétrie run, taux corruption, durées run, compteurs par état". Aucun TC dédié ne vérifie explicitement l'exposition Prometheus. TC-251-12 et TC-251-14 sont mappés sur CA-251-15 mais testent l'alerting/notification, pas les métriques.
• Impact : Les métriques Prometheus pourraient être implémentées sans test de validation.
• Gravité : Majeur

INC-03 — CA-251-14 ("suppression refusée") : mapping test¶

• Type : Incohérence Spec↔Tests
• Référence : CA-251-14, tests
• Description : CA-251-14 spécifie "la suppression d'une archive corrompue est refusée". La matrice de couverture ne mappe aucun TC directement sur CA-251-14. TC-251-10 couvre INV-251-09 (non-suppression) mais ne vérifie pas explicitement une tentative de suppression qui serait rejetée.
• Impact : Pas de test dédié pour la tentative de suppression + rejet.
• Gravité : Majeur

Axe 5 — Hypothèses dangereuses¶

HYP-01 — Disponibilité HSM pendant un incident de masse¶

• Type : Hypothèse dangereuse
• Référence : Spec §3.3 Phase 2, §9 point 6
• Description : La spec exige une signature HSM pour chaque snapshot forensique et chaque rapport d'incident. En cas de corruption massive (attaque, panne stockage), des centaines de signatures HSM seraient nécessaires simultanément. Le opsRateLimit (60 op/min) borne les opérations mais pas spécifiquement les appels HSM. Le besoin (tension #3) mentionne un "batch de signatures" mais la spec ne contractualise aucun mécanisme de batch HSM.
• Impact : Saturation HSM possible lors d'un incident de masse, bloquant le workflow de réaction.
• Gravité : Majeur

HYP-02 — Ordre d'exécution des phases de réaction¶

• Type : Hypothèse dangereuse
• Référence : Spec §3.3
• Description : L'ordre des 4 phases (gel → snapshot → restauration → rapport) est décrit séquentiellement mais aucune contrainte d'ordonnancement n'est formalisée comme invariant. INV-251-07 impose snapshot AVANT restauration, mais aucun INV ne couvre gel AVANT snapshot.
• Impact : Un implémenteur pourrait tenter un snapshot AVANT le gel, ou paralléliser des phases qui doivent être séquentielles.
• Gravité : Mineur (la séquence est implicitement claire mais pas formalisée)

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

SEC-01 — Accès investigation sur archives SUSPECT¶

• Type : Risque sécurité
• Référence : Spec §3.3 Phase 1, TC-251-07
• Description : La spec bloque "lecture publique et export" pour les archives SUSPECT. TC-251-07 mentionne "les opérations d'investigation autorisées restent possibles". Cependant, la spec ne définit pas quelles opérations sont "d'investigation" ni qui y a accès. Cela crée un vecteur potentiel de contournement du gel.
• Impact : Un acteur malveillant pourrait exploiter le mode "investigation" pour accéder à une archive gelée.
• Gravité : Majeur

SEC-02 — Absence de rate limiting sur les API manuelles¶

• Type : Risque sécurité
• Référence : Spec §6.1, §9 point 6
• Description : Le opsRateLimit (60 op/min) est défini dans les contraintes de sécurité mais n'est pas décliné par endpoint API. POST /integrity/runs pourrait être abusé pour déclencher des runs en boucle. La spec ne précise pas si le rate limiting s'applique par utilisateur, par IP, ou globalement.
• Impact : DoS potentiel via déclenchement massif de runs manuels.
• Gravité : Mineur (l'endpoint est ops-only, pas public)

Synthèse¶

Aucun bloquant. 6 points majeurs identifiés portant principalement sur la couverture des tests (3 CA insuffisamment couverts), la formule de priorisation non contractualisée, le gap entre CA et le parcours complet du workflow d'incident, et deux points de sécurité (accès investigation, batch HSM).