PD-253 — Expression de Besoin : Export bulk avec métadonnées et preuves¶

Story : PD-253 Epic : PD-217 — LEGAL & COMPLIANCE Domaine : legal-compliance / backend Date : 2026-03-12 Statut : Draft v2

1. Contexte¶

ProbatioVault est un coffre-fort numérique probatoire. Les documents archivés sont accompagnés de preuves cryptographiques (hash, horodatage, signature, ancrage blockchain) qui garantissent leur intégrité et leur opposabilité juridique.

La norme NF Z42-013 (version 2020) impose en son §13.1 la réversibilité complète des archives : l'utilisateur doit pouvoir récupérer l'intégralité de son archive — documents, métadonnées et preuves d'intégrité — sans dépendre du fournisseur. C'est une obligation de portabilité, pas une fonctionnalité optionnelle.

Un audit normatif (PD-244) a identifié ce gap : aucun mécanisme d'export bulk n'existe aujourd'hui. L'utilisateur ne peut pas exercer son droit à la réversibilité.

Par ailleurs, la story PD-85 a livré un export ciblé (dossier plainte, petit volume, orienté justice). PD-253 partage l'ambition d'exporter des documents avec leurs preuves, mais à une échelle et dans un contexte radicalement différents : portabilité complète du coffre, volumes massifs, vérification offline.

2. Objectifs principaux¶

O-1 — L'utilisateur peut récupérer l'intégralité de son archive (documents, métadonnées, preuves) dans un format auto-porteur, vérifiable sans ProbatioVault.

O-2 — L'export couvre plusieurs granularités : - Global : tous les documents du coffre (obligatoire NF Z42-013 §13.1) - Par vault/dossier : sous-ensemble structurel (migration progressive) - Par période : sous-ensemble temporel (enquête, demande juridique) - Par sélection : liste explicite de document_ids (optionnel)

O-3 — Chaque document exporté est accompagné de son enveloppe probatoire complète (hash SHA3, Merkle proof, timestamp TSA RFC3161, signature serveur HSM, ancre blockchain), vérifiable indépendamment des autres documents du package.

O-4 — Le package d'export est lui-même une preuve : signé par le HSM, avec un hash global ancré blockchain. L'export n'est pas un simple dump — c'est un acte archivistique.

O-5 — L'export fonctionne à l'échelle réaliste d'un coffre utilisateur (hypothèse : 10 000 documents, 20-50 GB) sans bloquer l'utilisateur ni dégrader le service.

3. Non-objectifs (exclusions explicites)¶

NO-1 — Pas d'import/restauration. PD-253 couvre uniquement la sortie. La réversibilité implique que le format soit lisible par un tiers, pas que ProbatioVault sache le ré-ingérer.

NO-2 — Pas de déchiffrement côté serveur. Les documents sont exportés chiffrés. Le déchiffrement est la responsabilité du client (cf. PD-283 pour l'assemblage côté app avec déchiffrement zero-knowledge).

NO-3 — Pas de streaming temps-réel. L'export est un processus asynchrone avec notification à complétion. L'utilisateur ne suit pas la progression document par document.

NO-4 — Pas de format propriétaire. Le format doit être lisible par des outils tiers sans code ProbatioVault.

NO-5 — Pas de gestion des droits d'accès inter-utilisateurs. L'export concerne le coffre d'un seul utilisateur. Les exports multi-tenant ou administrateur sont hors périmètre.

4. Contraintes¶

Juridiques et normatives¶

C-1 — NF Z42-013 §13.1 (version 2020) : réversibilité complète. L'extraction doit inclure documents, métadonnées et éléments d'intégrité. L'utilisateur ne doit pas dépendre du fournisseur pour vérifier ses archives après export.

C-2 — ISO 14641 : les preuves d'intégrité doivent rester vérifiables après extraction. L'enveloppe probatoire doit contenir suffisamment d'informations pour une vérification autonome.

C-3 — RGPD Art. 20 : droit à la portabilité. Le format doit être « structuré, couramment utilisé et lisible par machine ».

Organisationnelles¶

C-4 — Infrastructure partagée avec PD-85 : PD-253 réutilise le même moteur export (ExportEngine) que PD-85, via deux profils distincts — REVERSIBILITY_EXPORT (PD-253 : chiffré, BagIt, envelope complète) et LEGAL_EXPORT (PD-85 : déchiffré, ZIP, envelope partielle). Toute modification structurelle de l'infrastructure impacte les deux stories.

C-5 — Dépendances amont : les preuves (ProofEnvelope) sont produites par les stories crypto-proof (PD-282 pour le format seal eIDAS, PD-39 pour TSA, PD-37 pour HSM). PD-253 consomme ces preuves — il ne les produit pas. PD-253 est indépendant de PD-283 (assemblage côté app) : PD-283 consomme l'API /exports de PD-253 comme tout autre consommateur.

C-7 — Dual hash obligatoire dans la ProofEnvelope : chaque document exporté doit porter deux hash SHA3-256 — plaintext_hash (preuve du contenu, calculé côté client) et ciphertext_hash (intégrité de l'archive WORM, calculé côté serveur). Le Merkle tree utilise le ciphertext_hash (calculable par le serveur, stable, conforme WORM).

C-8 — Dual manifest BagIt obligatoire : manifest-sha256.txt (compatibilité outils BagIt standard) + manifest-sha3.txt (cohérence crypto ProbatioVault).

C-9 — Signature HSM du package (export.sig) optionnelle au moment de l'export. Un export sans signature HSM reste valide pour la réversibilité (niveau standard). La signature HSM augmente la force probatoire du package (niveau strong) mais ne conditionne pas l'exercice du droit à la réversibilité.

C-10 — Quota export pour prévenir les attaques par épuisement de stockage : max 1 export concurrent par utilisateur, taille maximale à définir en spec (hypothèse : 100 GB). Un nouvel export en cours d'un export actif est refusé ou mis en file d'attente.

C-11 — Documents avec ancre blockchain non finalisée (statut pending) : inclus dans l'export avec mention explicite blockchain_anchor.status: pending. La NF Z42-013 impose la réversibilité immédiate — l'export ne peut pas être bloqué par un batch d'ancrage en cours.

C-12 — Documents soft-deleted : inclus dans l'export avec marquage status: deleted, deleted_at: ... (le document reste dans le stockage WORM). Documents détruits par bordereau légal (PD-250) : non inclus dans le package principal, mais référencés dans un destruction-log.json avec hash de l'acte de destruction.

Temporelles¶

C-6 — Gap normatif identifié par l'audit PD-244. Tant que ce gap n'est pas comblé, le SAE n'est pas conforme NF Z42-013 sur la réversibilité. Pas de deadline externe identifiée, mais le gap est documenté et auditable.

5. Scénarios d'échec et résultats inacceptables¶

E-1 — Export incomplet silencieux : l'export termine avec un statut « succès » mais il manque des documents ou des preuves. L'utilisateur croit avoir récupéré l'intégralité de son archive — c'est faux. Inacceptable.

E-2 — Preuves non vérifiables : le package contient les preuves mais elles sont inutilisables hors ProbatioVault (format opaque, dépendances non incluses, chaîne de vérification incomplète). La réversibilité est formelle mais pas effective. Inacceptable.

E-3 — Corruption non détectée : le package est altéré (stockage, transfert) et l'utilisateur ne peut pas le détecter. L'intégrité du package doit être vérifiable indépendamment de son contenu.

E-4 — Export qui dégrade le service : le processus d'export consomme tellement de ressources qu'il impacte les opérations normales du coffre (archivage, consultation, preuve). L'export est un droit, pas une arme de déni de service.

E-5 — URL de téléchargement exploitable : l'URL signée est interceptée, partagée, ou reste valide indéfiniment. Un tiers non autorisé récupère l'intégralité du coffre.

E-6 — Fichiers temporaires résiduels : le processus d'assemblage laisse des fichiers non chiffrés ou des fragments sur le disque/stockage après complétion ou crash. Aucun résidu ne doit persister (cf. learning PD-283 : purgeStale() obligatoire au démarrage, pas seulement finally).

E-8 — Épuisement de stockage : un utilisateur déclenche plusieurs exports simultanément (ex. 10 × 50 GB = 500 GB sur le stockage staging). Sans quota, cela constitue une attaque par épuisement de ressources (stockage, CPU, bande passante). Résultat inacceptable : le service export devient un vecteur de déni de ressource. (Réponse : C-10.)

E-7 — Audit trail absent : l'export d'un coffre entier est un événement majeur. L'absence de trace d'audit (qui a exporté, quand, quel périmètre) rend impossible la détection d'exfiltration ou la conformité RGPD. L'audit doit être fail-closed (cf. learning PD-85 : anti-catch-absorb).

6. Tensions et conflits non résolus¶

T-1 — Exhaustivité vs. performance : l'objectif O-1 (intégralité du coffre) entre en tension avec l'objectif O-5 (pas de dégradation service). Un coffre de 50 GB avec 10 000 documents et leurs preuves représente un volume considérable à assembler, signer et stocker temporairement. La pression normative (réversibilité complète) interdit de paginer ou tronquer l'export. Non résolue — à traiter en spec.

T-2 / T-2b — RÉSOLUE : dual hash retenu dans la ProofEnvelope : plaintext_hash (preuve du contenu, calculé côté client, vérifiable uniquement par le possesseur de la clé) + ciphertext_hash (intégrité de l'archive WORM, calculé côté serveur, vérifiable par tous). Le Merkle tree utilise ciphertext_hash. Deux chaînes de vérification explicites et documentées dans le package.

T-3 — RÉSOLUE : même moteur export (ExportEngine), deux profils — REVERSIBILITY_EXPORT (PD-253 : chiffré, BagIt, envelope complète) et LEGAL_EXPORT (PD-85 : déchiffré, ZIP, envelope partielle). L'abstraction est explicite et contrainte par les profils, pas par des paramètres ad hoc. Risque résiduel : le profil commun peut dériver si les deux stories évoluent de façon non coordonnée.

T-4 — RÉSOLUE : signature HSM (export.sig) rendue optionnelle. La réversibilité ne dépend pas de la disponibilité du HSM. Deux niveaux : standard (package vérifiable sans signature) et strong (package signé HSM). L'ancrage blockchain du hash du package reste recommandé mais ne conditionne pas l'export.

T-5 — Sécurité du téléchargement vs. accessibilité : l'URL signée (E-5) doit être suffisamment éphémère pour limiter l'exposition, mais suffisamment durable pour que l'utilisateur ait le temps de télécharger 50 GB. La durée de validité est un curseur entre sécurité et praticabilité. Non résolue — valeur TTL à définir en spec.

T-6 — Indépendance des preuves vs. cohérence du package : chaque document a sa ProofEnvelope indépendante (O-3), mais le package a aussi une signature globale (O-4). Si un seul fichier est corrompu, le manifest global est invalide mais les ProofEnvelopes des autres documents restent valides. Non résolue — granularité de vérification à définir en spec.

7. Questions ouvertes¶

Q-1 — RÉSOLUE : dual manifest BagIt — manifest-sha256.txt (conformité RFC 8493, compatibilité outils tiers) + manifest-sha3.txt (cohérence crypto ProbatioVault). Profil BagIt spécifique ProbatioVault à documenter.

Q-2 — Le fichier export.sig (signature HSM du package) signe quoi exactement ? Le manifest global ? Le hash du TAR/ZIP compressé ? Le contenu concaténé des manifests ? Le choix impacte la possibilité de vérification partielle sans re-télécharger le package entier. À définir en spec.

Q-3 — Quelle est la durée de rétention du package assemblé sur le stockage staging (S3) ? Après téléchargement confirmé ? Après expiration de l'URL ? Le stockage temporaire de 50 GB par utilisateur a un coût non trivial et une surface d'exposition à limiter. À définir en spec.

Q-4 — Comportement exact quand un export est déjà en cours et qu'un nouveau est demandé (C-10 pose le quota max=1 concurrent) : refus immédiat avec 409 ? File d'attente ? Annulation de l'export existant à la demande ? À définir en spec.

Q-5 — Canal de notification (export prêt au téléchargement) : email ? push notification (PD-105) ? polling API GET /exports/{id} ? Ou combinaison ? À définir en spec selon architecture existante.

Q-6 — RÉSOLUE : documents avec ancrage blockchain en attente inclus dans l'export avec blockchain_anchor.status: pending. La réversibilité NF Z42-013 est immédiate — l'export ne peut pas être bloqué par un batch en cours.

Q-7 — RÉSOLUE : dual hash (cf. T-2/T-2b résolue et C-7). plaintext_hash pour la preuve de contenu, ciphertext_hash pour l'intégrité de l'archive.

Q-8 — RÉSOLUE : soft-deleted inclus avec marquage ; détruits par bordereau légal (PD-250) exclus du package mais référencés dans destruction-log.json.

Q-9 — RÉSOLUE : PD-253 indépendant de PD-283. PD-253 livre un package téléchargeable directement (documents chiffrés + preuves). PD-283 et tout autre consommateur peuvent appeler POST /exports indépendamment.

Document produit en étape 0 du workflow de gouvernance ProbatioVault. Aucune solution technique n'est prescrite. Les tensions et questions ouvertes sont intentionnellement non résolues — elles alimenteront la spécification (étape 1).