Protocole formel de migration probatoire vérifiable¶

Référence : PD-254 Version : 1.0.0 Date : 2026-03-13 Normes : NF Z42-013:2020 §12.1, ISO 14641 Statut : VALIDÉ

1. Objet¶

Ce protocole définit les étapes contractuelles, auditables et reproductibles pour toute migration probatoire de stockage. Il garantit l'intégrité cryptographique, la lisibilité post-migration, la traçabilité complète et la conformité NF Z42-013:2020 §12.1.

Le protocole couvre la vérification et la preuve de conformité de migration. L'exécution technique de migration de données n'est pas couverte.

2. Types de migration couverts¶

2.1 Migration de support¶

Transfert d'objets probatoires d'un type de support physique vers un autre (ex: HDD → SSD, bande magnétique → stockage objet cloud) sans changement de provider ni de région.

Prérequis spécifiques :

• Compatibilité des modes de verrouillage WORM entre supports source et cible
• Validation que le support cible supporte Object Lock (si applicable)

2.2 Migration de provider¶

Transfert d'objets probatoires d'un fournisseur cloud vers un autre (ex: OVH → AWS, AWS → Scaleway) avec potentiellement un changement d'API et de format d'adressage.

Prérequis spécifiques :

• Mapping des politiques de rétention WORM entre providers
• Validation des endpoints blockchain accessibles depuis le nouveau provider
• Compatibilité des formats de clé S3 (s3_object_key)

2.3 Migration de région¶

Transfert d'objets probatoires d'une région géographique vers une autre au sein du même provider (ex: eu-west-3 → eu-central-1) pour des raisons de souveraineté, latence ou résilience.

Prérequis spécifiques :

• Conformité RGPD de la région cible
• Disponibilité du registre d'ancrage blockchain depuis la région cible
• Latence réseau acceptable pour les vérifications HSM

3. Machine d'états formelle¶

3.1 États formels (10)¶

3.2 Table des transitions¶

DRAFT ──────────────────► PRECHECK_RUNNING           ✓ AUTORISÉE
DRAFT ──────────────────► (tout autre)               ✗ INTERDITE

PRECHECK_RUNNING ───────► PRECHECK_PASSED            ✓ AUTORISÉE (tous contrôles OK)
PRECHECK_RUNNING ───────► PRECHECK_FAILED            ✓ AUTORISÉE (≥1 contrôle KO)
PRECHECK_RUNNING ───────► DRAFT                      ✗ INTERDITE

PRECHECK_PASSED ────────► CUTOVER_AUTHORIZED         ✓ AUTORISÉE (si TTL precheck non expiré)
PRECHECK_PASSED ────────► PRECHECK_RUNNING           ✓ AUTORISÉE (revalidation)
PRECHECK_PASSED ────────► DRAFT                      ✓ AUTORISÉE (si TTL expiré → PRECHECK_EXPIRED)

PRECHECK_FAILED ────────► PRECHECK_RUNNING           ✓ AUTORISÉE (correction puis relance)
PRECHECK_FAILED ────────► CUTOVER_AUTHORIZED         ✗ INTERDITE

CUTOVER_AUTHORIZED ─────► POSTCHECK_RUNNING          ✓ AUTORISÉE
CUTOVER_AUTHORIZED ─────► PRECHECK_PASSED            ✓ AUTORISÉE (retour avant exécution)
CUTOVER_AUTHORIZED ─────► ROLLED_BACK                ✓ AUTORISÉE (annulation)

POSTCHECK_RUNNING ──────► VERIFIED                   ✓ AUTORISÉE (tous contrôles OK)
POSTCHECK_RUNNING ──────► ROLLED_BACK                ✓ AUTORISÉE (échec postcheck)
POSTCHECK_RUNNING ──────► RECONCILIATION_FAILED      ✓ AUTORISÉE (timeout/retries épuisés)

VERIFIED ───────────────► ATTESTED                   ✓ AUTORISÉE (attestation signée dans SLA)
VERIFIED ───────────────► ROLLED_BACK                ✓ AUTORISÉE (attestation impossible)

ATTESTED ───────────────► (toute transition)         ✗ INTERDITE (terminal)
ROLLED_BACK ────────────► (toute transition)         ✗ INTERDITE (terminal)
RECONCILIATION_FAILED ──► (toute transition)         ✗ INTERDITE (terminal)

3.3 Codes d'erreur métier (distincts des états)¶

Règle : les codes métier ne sont PAS des états de la machine d'états. Ils ne provoquent aucune transition sauf les cas explicites ci-dessus.

4. Procédure opérationnelle¶

4.1 Flux F1 — Préparation¶

1. Créer une campagne avec migration_id (UUID v4), migration_type et protocol_version
2. Valider le format de tous les identifiants
3. Vérifier l'absence de campagne dupliquée (idempotence)
4. Acquérir le lock distribué migration:lock:{migration_id}
5. Vérifier le quota de l'initiateur (max 3 lancements/heure)
6. Vérifier les préconditions :
7. Accès lecture/écriture source
8. Accès lecture/écriture cible
9. Accès registre d'ancrage blockchain
10. Accès HSM (clés dédiées provisionnées)
11. Runbook de rollback présent et versionné
12. Transition DRAFT → PRECHECK_RUNNING

4.2 Flux F2 — Precheck et manifest de référence¶

1. Inventorier tous les objets source (doc_id, sha3, merkle_root, s3_object_key, size, timestamp, tx_hash)
2. Valider le format de chaque champ selon les contraintes contractuelles
3. Générer manifest.json en JSON canonique (RFC 8785 JCS)
4. Calculer manifest_hash = SHA3-256 du JSON canonique
5. Signer le manifest via HSM → manifest_signature
6. Stocker manifest_hash + manifest_signature dans un registre indépendant
7. Enregistrer source_object_count
8. Calculer le Global Root Hash (GRH) :
9. Extraire tous les merkle_root
10. Trier par ordre lexicographique croissant hex lowercase
11. Concaténer les chaînes triées
12. SHA3-256 de la concaténation
13. Exécuter les contrôles precheck :
14. Intégrité SHA3 objet par objet
15. Cohérence Merkle root objet par objet
16. Vérification ancrages blockchain (100% du lot)
17. Lisibilité sur échantillon (3 critères : I/O, MIME, décodage 1024 octets)
18. Produire le rapport precheck JSON
19. Transition selon résultat : PRECHECK_PASSED ou PRECHECK_FAILED

4.3 Flux F3 — Postcheck après migration¶

1. Vérifier que le TTL du precheck n'est pas expiré (défaut 72h, max 168h)
2. Charger le manifest de référence immuable
3. Revalidation du manifest :
4. Recalculer SHA3-256 du manifest et comparer avec manifest_hash stocké
5. Vérifier manifest_signature via HSM
6. Si divergence → campagne KO immédiate
7. Revalidation du nombre d'objets source :
8. Comparer le nombre actuel avec source_object_count enregistré
9. Si divergence → campagne KO, code MANIFEST_STALE
10. Inventorier le dataset cible post-migration
11. Calculer hash_global_after (même algorithme GRH)
12. Comparer pré/post :
13. SHA3 objet par objet
14. Merkle root objet par objet
15. GRH global
16. Ancrages blockchain
17. Lisibilité post-migration
18. Produire le rapport différentiel JSON
19. Transition : VERIFIED, ROLLED_BACK ou RECONCILIATION_FAILED

4.4 Flux F4 — Attestation probatoire¶

1. Générer migration_attestation.json conforme au schéma contractuel
2. Inclure protocol_version, manifest_hash, hash_global_before/after
3. Signer l'attestation via HSM
4. Archiver l'attestation en stockage probatoire WORM
5. Notifier DevOps/TechLead/PO du verdict
6. Transition VERIFIED → ATTESTED (terminal)

4.5 Flux F5 — Dry-run¶

1. Exécuter F1 et F2 normalement
2. Simuler F3 en comparant le dataset source avec lui-même (source/source)
3. Interdire toute transition vers exécution effective
4. Produire le rapport dry-run avec code retour CI explicite

5. Checklist pré-migration¶

6. Runbook de rollback¶

6.1 Déclenchement¶

Le rollback est déclenché si :

• Au moins un invariant est violé au postcheck
• L'attestation HSM ne peut pas être produite dans le SLA (défaut 15min)
• Décision opérationnelle avant exécution effective

6.2 Procédure¶

1. Arrêt immédiat de toute opération de migration en cours
2. Vérification de l'intégrité des données source (aucune suppression)
3. Basculement du routage vers la source originale
4. Notification de tous les stakeholders
5. Archivage des rapports d'échec (pas de purge — conservation des preuves)
6. Transition vers ROLLED_BACK (terminal)

6.3 Objectif temporel¶

• Cible : ≤ 4 heures (P95)
• Maximum : 8 heures

7. Mécanismes de protection¶

8. Références normatives¶

• NF Z42-013:2020 §12.1 — Exigences de migration de supports d'archivage électronique
• ISO 14641 — Archivage électronique — spécifications relatives à la conception et au fonctionnement d'un système d'informations pour la conservation d'informations électroniques
• PD-44 — WORM Object Lock (contraintes de rétention)
• PD-54 — Merkle Tree (arbres de preuves)
• PD-55 — Worker d'ancrage blockchain
• PD-36/37 — HSM PKCS#11 / Audit signature
• PD-245 — Format de preuve multi-chain (hors périmètre changement de format)

Document généré dans le cadre du protocole PD-254. Toute modification requiert une revue formelle et un incrément de version.