PD-254 — Specification Review (Gate 3 — CONFORMITY_CHECK)¶

Auditeur : Claude (orchestrateur) Date : 2026-03-13 Documents analysés : PD-254-specification.md, PD-254-tests.md Itération : v1

Constats¶

C-01 — Machine d'états incomplète : 5 statuts référencés hors §5.2¶

Type : Contradiction Référence : §5.2 (états) vs §5.1, §5.4, §5.10, §6 (ERR-01, ERR-06, ERR-08) Description : La section §5.2 liste 10 états (DRAFT, PRECHECK_RUNNING, PRECHECK_PASSED, PRECHECK_FAILED, CUTOVER_AUTHORIZED, POSTCHECK_RUNNING, VERIFIED, ATTESTED, ROLLED_BACK, RECONCILIATION_FAILED). Or, 5 statuts additionnels sont référencés dans d'autres sections sans apparaître dans la machine d'états :

• INVALID_INPUT (§5.1, comportement si migration_id invalide)
• INVALID_MANIFEST (ERR-01)
• CONCURRENT_EXECUTION_DENIED (§5.10)
• ATTESTATION_FAILED (§5.4, ERR-08)
• PRECHECK_EXPIRED (§5.4, SLA precheck)

Aucune transition entrante/sortante n'est définie pour ces 5 statuts. Il est impossible de déterminer s'ils sont des états de la machine, des codes d'erreur métier, ou des statuts transitoires.

Impact : L'invariant INV-254-10 exige que « toute transition d'état soit explicitement autorisée ou interdite ». Ces 5 statuts violent cet invariant. Les tests (TC-NEG-01, TC-ERR-01, TC-ERR-06, TC-ERR-08) les traitent comme des états observables sans pouvoir les ancrer dans la matrice de transitions. Gravité : Bloquant

C-02 — Ordre de tri du Global Root Hash non défini¶

Type : Ambiguïté Référence : §3 (définitions), INV-254-03 Description : Le GRH est défini comme SHA3-256(concatenation triée des merkle_root). Le critère de tri n'est pas spécifié : tri lexicographique sur la chaîne hex ? Tri par doc_id ? Tri par timestamp ? Tri par s3_object_key ?

Le choix de tri affecte directement la valeur du hash. Deux implémentations utilisant des ordres différents produiront des GRH différents sur le même dataset.

Impact : INV-254-03 (hash_global_before == hash_global_after) et INV-254-09 (reproductibilité) sont non vérifiables sans convention de tri explicite. Toute implémentation tierce divergerait. Gravité : Bloquant

C-03 — « Lisibilité » non définie opérationnellement¶

Type : Ambiguïté Référence : INV-254-05, CA-07, §5.6 flux F2, §5.7 flux F3 Description : Le terme « lisibilité » est utilisé 12 fois dans la spécification, avec un seuil contractuel (readability_pass_threshold) et un échantillonnage (readability_sample_count). Cependant, aucune définition opérationnelle n'est fournie : que signifie « un objet est lisible » ? Ouverture du fichier sans erreur I/O ? Parsing du format (PDF, image) ? Rendu visuel correct ? Extraction de texte ?

Sans critère objectif de lisibilité, le pass_rate ne peut pas être calculé de manière déterministe.

Impact : INV-254-05, INV-254-09 (reproductibilité), CA-07 et TC-INV-05 sont non vérifiables. Deux opérateurs pourraient produire des pass_rate différents sur le même échantillon. Gravité : Bloquant

C-04 — Dry-run postcheck : simulation sans données post-migration¶

Type : Ambiguïté Référence : §5.9 flux F5 Description : Le flux F5 prescrit « Exécuter F1, F2 et simulation F3 sans aucune opération de migration ». Or, F3 (postcheck) compare le dataset cible post-migration au manifest pré-migration. En mode dry-run, aucune migration n'a lieu : le dataset « cible » n'existe pas ou est identique à la source.

La spécification ne précise pas ce que « simulation F3 » signifie concrètement : comparaison source/source (tautologique) ? Vérification structurelle sans comparaison ? Vérification d'accessibilité cible vide ?

Impact : CA-08 et TC-NOM-05 testent un comportement dont la sémantique n'est pas définie. Le verdict GO/NO_GO du dry-run est non interprétable. Gravité : Majeur

C-05 — Fenêtre TOCTOU entre precheck et cutover (jusqu'à 720h)¶

Type : Hypothèse dangereuse Référence : §5.3 (precheck_ttl max = 720h), §5.4, H-05 Description : Le precheck_ttl autorise un délai de jusqu'à 720 heures (30 jours) entre la validation du precheck et l'autorisation de cutover. L'hypothèse H-05 reconnaît que le périmètre objets doit être « freeze pendant la campagne », mais aucun mécanisme de gel n'est spécifié.

Pendant cette fenêtre : de nouveaux objets peuvent être archivés, des ancrages blockchain peuvent être ajoutés, des rétentions WORM peuvent expirer. Le manifest pré-migration devient caduc sans mécanisme de détection.

Impact : INV-254-01 à INV-254-05 peuvent être satisfaits formellement (comparaison sur le périmètre du manifest) tout en masquant une perte d'objets archivés entre precheck et cutover. Gravité : Majeur

C-06 — Immutabilité du manifest non garantie¶

Type : Risque sécu/conformité Référence : §5.6 flux F2, §5.7 flux F3 Description : Le manifest est décrit comme « immuable » (§5.7 : « Charger manifest de référence immuable »). Aucun mécanisme d'immutabilité n'est spécifié : pas de signature du manifest, pas de stockage WORM du manifest, pas de hash du manifest lui-même dans un registre tiers.

Un manifest altéré (accidentellement ou malicieusement) entre precheck et postcheck rendrait toutes les comparaisons pre/post non fiables. L'attaquant pourrait aligner le manifest sur les données altérées.

Impact : INV-254-01 à INV-254-05 sont contournables si le manifest n'est pas protégé contre l'altération. La conformité NF Z42-013 §12.1 (non-altération de la chaîne de preuve) est compromise. Gravité : Bloquant

C-07 — INV-254-11 (envelope encryption) : applicabilité non démontrée¶

Type : Ambiguïté Référence : INV-254-11, §5.11, §5.12 Description : L'invariant INV-254-11 exige que « tout artefact crypto temporaire (DEK, fragment, clé de session, material de rekey) soit chiffré au repos ». Or, la spécification exclut explicitement la migration de données (§2), toute exigence d'atomicité multi-composant (§5.11), et toute migration DDL (§5.12).

Le protocole PD-254 est un protocole de vérification et d'attestation. Les seuls éléments cryptographiques manipulés sont : la clé HSM de signature (externe, gérée par le HSM) et les hash SHA-3/Merkle (non secrets). Aucun DEK, fragment, clé de session ou material de rekey n'est généré par le protocole tel que spécifié.

Impact : TC-INV-11 teste un invariant dont le périmètre d'application dans PD-254 est vide. Le test passera trivialement (aucun secret à trouver), donnant une fausse assurance de couverture. Gravité : Majeur

C-08 — « Artefacts logiques » : terme non défini (idempotence)¶

Type : Ambiguïté Référence : §5.10 (idempotence), INV-254-09, TC-INV-09 Description : L'exigence d'idempotence stipule que le replay « doit retourner le même verdict et les mêmes artefacts logiques ». Le terme « artefacts logiques » n'est pas défini. Les artefacts physiques (rapports JSON, attestation) contiendront nécessairement des timestamps différents entre deux exécutions. La frontière entre contenu « logique » (invariant entre exécutions) et contenu « physique » (variable) n'est pas établie.

Impact : TC-INV-09 et TC-NEG-07 ne peuvent pas définir un critère de comparaison objectif. Deux exécutions produisant des rapports structurellement identiques mais avec des timestamps/identifiants différents : PASS ou FAIL ? Gravité : Majeur

C-09 — Clearing conditionnel (3 cycles) sans test dédié¶

Type : Incohérence Spec↔Tests Référence : §5.10 (clearing conditionnel), section tests §5 Description : La spécification exige un « retour à statut opérationnel normal seulement après 3 cycles de réconciliation conformes consécutifs » avec un « compteur persisté par migration_id ». Aucun test ne couvre explicitement ce mécanisme : ni le compteur, ni la persistance, ni le seuil de 3 cycles, ni le refus de clearing à 1 ou 2 cycles conformes.

TC-NOM-07 couvre la réconciliation (reprise orphelin) mais pas le clearing conditionnel.

Impact : Le mécanisme de clearing est non vérifié. Un bug sur le compteur (clearing dès le premier cycle OK) passerait inaperçu. Gravité : Majeur

C-10 — TC-INV-06 introduit un événement non spécifié¶

Type : Incohérence Spec↔Tests Référence : TC-INV-06 vs ERR-09 (§6) Description : TC-INV-06 exige un « Événement sécurité WORM_VIOLATION_BLOCKED consigné ». La spécification (ERR-09) dit « Arrêt immédiate, incident sécurité » sans nommer l'événement. Le test introduit un identifiant d'événement (WORM_VIOLATION_BLOCKED) absent de la spécification.

Impact : L'implémentation ne sait pas quel nom d'événement utiliser. Le test risque d'échouer sur une question de nommage plutôt que de comportement. Gravité : Mineur

C-11 — « Initiateur » non défini pour le rate-limiting¶

Type : Ambiguïté Référence : §5.10 (rate-limiting) Description : Le rate-limiting est défini « par migration_id et par initiateur » avec « max 3 lancements/heure/initiateur ». Le terme « initiateur » n'est pas défini : utilisateur humain ? Service account ? Adresse IP ? Token d'API ?

Impact : Un acteur malveillant pourrait contourner le rate-limiting en utilisant plusieurs identités d'initiateur. Le test TC-NEG-06 suppose un initiateur unique sans préciser sa résolution. Gravité : Mineur

C-12 — Contradiction structurelle : transition retour documentée sous le mauvais état¶

Type : Ambiguïté Référence : §5.2, sous PRECHECK_PASSED Description : Sous la section PRECHECK_PASSED, une « transition retour explicite » est documentée : CUTOVER_AUTHORIZED -> PRECHECK_PASSED AUTORISEE. Cette transition est une transition DEPUIS CUTOVER_AUTHORIZED, mais elle est documentée sous PRECHECK_PASSED. La même transition est déjà listée correctement sous CUTOVER_AUTHORIZED.

De même, sous VERIFIED : ATTESTED -> VERIFIED INTERDITE est une transition DEPUIS ATTESTED, documentée sous VERIFIED.

Impact : Lisibilité dégradée. Risque d'interprétation divergente par une équipe tierce sur les transitions autorisées depuis chaque état. Gravité : Mineur

C-13 — protocol_version : hypothèse sans ancrage contractuel¶

Type : Incohérence Spec↔Tests Référence : H-06, §5.1 (modèle de données) Description : L'hypothèse H-06 stipule « Le protocole est versionné (ex: protocol_version) ». Ce champ n'apparaît pas dans le modèle de données contractuel (§5.1), ni dans le schéma du manifest, ni dans l'attestation. TC-NOM-01 mentionne « La version du protocole est lisible et horodatée » mais aucun champ du modèle ne porte cette information.

Impact : INV-254-09 (reproductibilité) exige des résultats identiques à « même version protocole », mais sans champ versionné dans les artefacts, la traçabilité de version est impossible. Gravité : Majeur

C-14 — TC-NOM-03 traverse implicitement le cutover (hors périmètre)¶

Type : Incohérence Spec↔Tests Référence : TC-NOM-03, §2 (hors périmètre) Description : TC-NOM-03 teste le flux nominal precheck → postcheck sur un « lot sans altération » et attend la transition POSTCHECK_RUNNING -> VERIFIED. Ce chemin traverse nécessairement PRECHECK_PASSED -> CUTOVER_AUTHORIZED -> POSTCHECK_RUNNING, ce qui implique une migration effective entre les deux phases de vérification. Or, la migration effective est explicitement hors périmètre (§2).

Le test suppose l'existence d'un dataset cible post-migration identique à la source, sans expliquer comment ce dataset est constitué dans le cadre du test.

Impact : Le scénario nominal n'est pas autoportant. Il dépend d'un pré-requis (données post-migration) que la story ne fournit pas. Gravité : Majeur

C-15 — Schéma du manifest et de l'attestation non définis¶

Type : Non testable Référence : CA-02, CA-09, §5.6, §5.8 Description : CA-02 exige « manifest.json valide contre schéma contractuel complet ». CA-09 exige « migration_attestation.json signé et archivé ». Les champs du manifest sont listés textuellement (§5.6) et les formats individuels sont définis (§5.1), mais aucun JSON Schema formel n'est fourni. De même, les « champs contractuels » de l'attestation (§5.8) ne sont pas énumérés.

Impact : TC-NOM-02 (« validation de schéma passe sans avertissement ») ne peut pas être exécuté sans schéma. TC-NOM-04 ne peut pas vérifier la complétude de l'attestation. Gravité : Majeur

Synthèse¶

Total : 13 constats (3 bloquants, 8 majeurs, 3 mineurs)

Aucune correction proposée. Aucune reformulation. Aucune implémentation.