PD-254 — Protocole migration probatoire¶

1. Contexte¶

ProbatioVault dispose d'une infrastructure de stockage résiliente (S3 WORM Object Lock, réplication Paris-Frankfurt, Glacier, SHA-3 hashing, arbres Merkle, signature HSM). Cependant, le protocole formel de migration probatoire n'est pas documenté.

Le gap GAP-FINAL-018 (audit PD-244) identifie cette lacune au regard de la norme NF Z42-013:2020 § 12.1 : "Toute migration doit préserver l'intégrité, la lisibilité et les chaînes de preuve associées."

L'évaluation tri-agents PD-244 a produit un consensus PARTIEL :

Claude : CONFORME (processus de migration avec vérification d'intégrité pré/post existant)
ChatGPT : PARTIEL (architecture robuste mais protocole formel incomplet)
Gemini : NON_IMPLEMENTE (aucune stratégie, processus ou outil de migration contrôlée)

Arbitrage : Le protocole est non formalisé. La capacité technique existe ; la documentation et l'outillage manquent.

2. Problème¶

Sans protocole formalisé :

Une migration de support (changement bucket S3, changement provider cloud) pourrait corrompre des preuves sans détection
Les chaînes de preuve (hash SHA-3 → Merkle → ancrage blockchain) pourraient être brisées
Aucune procédure de rollback n'est documentée en cas d'échec
La conformité NF Z42-013 § 12.1 n'est pas démontrable lors d'un audit

3. Besoin¶

En tant que TechLead / DevOps, je veux un protocole de migration probatoire formalisé, outillé et intégré au pipeline CI/CD, afin de garantir que toute migration future préserve l'intégrité des archives et satisfasse NF Z42-013 § 12.1.

4. Périmètre¶

4.1 Inclus¶

Document protocole (Markdown) :
Procédure step-by-step couvrant 3 types de migration :

Type Exemple

Support S3 bucket A → S3 bucket B

Provider OVH → Scaleway

Région Paris → Frankfurt
Vérification d'intégrité pré-migration (inventaire + checksums)
Vérification d'intégrité post-migration (comparaison + validation chaînes de preuve)
Vérification de lisibilité post-migration (sample aléatoire : déchiffrement, lecture, validation MIME)
Checklist rollback en cas d'échec
Matrice de responsabilité (RACI)
Critères Go/No-Go de bascule
Snapshot manifest pré-migration :
Génération d'un manifest.json (golden dataset) contenant pour chaque objet : doc_id, sha3, merkle_root, s3_object_key, size, timestamp
Sert de référence pour comparaison post-migration
Global Root Hash : root = SHA3(all_merkle_roots_sorted) — vérifie N millions d'objets en 1 hash
Script de vérification d'intégrité (Python) :
Inventaire des objets source (S3 + PostgreSQL)
Calcul SHA-3 de chaque objet et comparaison avec les hash stockés en DB
Vérification des arbres Merkle (racines cohérentes)
Vérification des ancrages blockchain (non altérés)
Vérification de lisibilité : sample aléatoire (decrypt test + MIME validation)
Comparaison Global Root Hash pré/post
Rapport différentiel pré/post migration (JSON)
Mode dry-run (--dry-run) : scanne, calcule, vérifie, ne migre rien
Code de retour exploitable par CI
Attestation de migration :
Génération d'une migration_attestation.json signée HSM contenant : migration_id, date, source_storage, target_storage, object_count, hash_global_before, hash_global_after, merkle_root_before, merkle_root_after, readability_sample_count, readability_sample_pass_rate, signature_hsm
Constitue une preuve probatoire de migration archivée au même titre qu'un document
Intégration CI/CD :
Job GitLab CI dédié (exécutable manuellement ou déclenché par tag)
Quality Gate bloquant si intégrité compromise
Notification DevOps en cas d'écart

4.2 Exclu¶

Migration effective de données (hors scope — le protocole documente comment migrer, pas quand)
Changement de format des preuves (couvert par PD-245)
Migration de schéma DB (couvert par les migrations TypeORM existantes)

5. Contraintes¶

Contrainte	Source	Impact
Intégrité SHA-3 préservée	NF Z42-013 § 12.1	Tout hash modifié = migration KO
Chaînes de preuve intactes	NF Z42-013 § 12.1	Merkle root doit rester identique
Ancrages blockchain vérifiés	ISO 14641	Tx hash doit correspondre au registre
WORM Object Lock respecté	PD-44	Aucune suppression avant expiration retention
Script reproductible	DevOps	Exécutable sans intervention manuelle
Rollback documenté	Best practice	Retour arrière possible sous 4h
Global Root Hash invariant	Architecture	`SHA3(sorted(merkle_roots))` identique avant/après = OK
Attestation signée HSM	NF Z42-013	Preuve probatoire de migration archivée
Lisibilité vérifiée	NF Z42-013 § 12.1	Sample aléatoire déchiffré + MIME validé

6. Acteurs¶

Acteur	Rôle
TechLead	Rédaction et validation protocole
DevOps	Validation script + intégration CI
PO	Validation métier (conformité NF Z42-013)

7. Risques¶

Risque	Probabilité	Impact	Mitigation
Script incomplet (ne couvre pas tous les types de preuves)	Moyenne	Fort	Inventaire exhaustif des types de preuves existants
Faux positif intégrité (hash mismatch sur objet valide)	Faible	Moyen	Mode dry-run + rapport détaillé avant blocage
Rollback impossible (WORM empêche suppression des copies)	Faible	Fort	Rollback = bascule DNS/config, pas suppression

8. Learnings injectés¶

Story	Learning	Application PD-254
PD-264	Contractualiser les migrations DDL dans la spec	Distinguer migration schéma (exclu) vs migration données (inclus)
PD-278	Attestation dédiée + audit synchrone NF Z42-013	Attestation de migration signée HSM (migration_attestation.json)
PD-282	ALTER TYPE ADD VALUE PostgreSQL	Hors scope (migration schéma exclu)
PD-98	Préfixe version pour migration sans casser compatibilité	Versionner le protocole lui-même

Type	Exemple
Support	S3 bucket A → S3 bucket B
Provider	OVH → Scaleway
Région	Paris → Frankfurt