Chapitre 6 -- Cycle de vie des documents¶

6.1 Ingestion et scellement¶

Principes fondamentaux¶

Le SAE ProbatioVault gere le cycle de vie complet des documents archivees, depuis leur depot initial jusqu'a leur eventuelle destruction controlee. Le processus d'ingestion garantit que chaque document acquiert une valeur probatoire des son scellement, conformement a la norme NF Z42-013 et a la norme ISO 14641.

L'ingestion repose sur un principe de chiffrement cote client exclusif : le document est chiffre par l'application cliente (AES-256-GCM) avant tout transfert reseau. Le serveur ne manipule jamais le contenu en clair, ce qui garantit la confidentialite de bout en bout.

Phase d'acquisition (statut PENDING)¶

Lorsqu'un utilisateur depose un document, le flux suivant est execute :

1. Chiffrement client-side : L'application cliente genere une cle symetrique AES-256-GCM et chiffre le document localement. Les metadonnees (nom, type MIME, taille, tags) sont egalement chiffrees avant envoi.

2. Transfert et stockage : Le fichier chiffre est envoye au backend, qui le stocke sur OVH Object Storage (compatible S3). Le chemin de stockage suit le format {user_id}/{document_id}/{version}.enc.

3. Calcul d'empreinte serveur : Le hash SHA3-256 est calcule cote serveur a partir du fichier chiffre deja depose sur S3. Cette regle est fondamentale : le hash n'est jamais fourni par le client, ce qui empeche toute falsification de l'empreinte (garantie probatoire).

4. Creation de l'enregistrement : Le document est cree en base (schema vault_secure, table documents) avec le statut PENDING. La contrainte d'unicite sur (user_id, file_hash) empeche les doublons.

Pendant la phase d'acquisition (environ 60 minutes), le document reste modifiable ou supprimable par son proprietaire. Cette fenetre corrective permet de corriger une erreur de depot avant le scellement.

Recherche sur donnees chiffrees¶

Pour permettre la recherche sans dechiffrer les metadonnees, ProbatioVault utilise des mots-cles hashes par HMAC-SHA256. La cle de recherche est derivee de la cle maitre utilisateur. Chaque mot-cle stocke correspond a un hash tronque a 22 caracteres (132 bits de securite), indexe via un index GIN pour des performances de recherche elevees.

Processus de scellement (transition PENDING vers SEALED)¶

Une fois la fenetre corrective expiree, le document est eligible au scellement automatique. Le service DocumentSealingService orchestre la transition :

1. Activation Object Lock WORM : Le backend active le mode COMPLIANCE de l'Object Lock S3, rendant le fichier chiffre physiquement immuable pendant la duree de retention.

2. Horodatage TSA (RFC 3161) : Un jeton d'horodatage est obtenu aupres d'une autorite de confiance, certifiant la date exacte du scellement.

3. Ancrage Merkle : Le hash du document est integre dans un lot Merkle. Le service BatchSealService construit l'arbre, calcule la racine (SHA-256, conforme RFC 6962), signe le payload via HSM (ECDSA_SHA384) et associe une attestation d'horloge NTS.

4. Ancrage blockchain (optionnel) : Le hash racine du lot Merkle peut etre ancre sur une blockchain publique, ajoutant un point de confiance supplementaire.

5. Mise a jour en base : Le statut passe a SEALED, avec enregistrement des timestamps sealed_at et retention_until.

L'ensemble de ces operations constitue la PV-Envelope (enveloppe probatoire ProbatioVault), qui confere au document une valeur probatoire legale.

Durees de retention legales¶

La duree de retention est determinee par le type de document, en conformite avec le droit francais :

Diagramme : Flux d'ingestion et de scellement¶

sequenceDiagram
    participant C as Client
    participant B as Backend
    participant S3 as OVH S3
    participant TSA as Autorite TSA
    participant HSM as HSM

    C->>C: Chiffrement AES-256-GCM
    C->>B: Upload fichier chiffre
    B->>S3: Stockage fichier .enc
    B->>S3: Lecture stream SHA3-256
    B->>B: Enregistrement PENDING
    Note over B: Fenetre corrective ~60 min
    B->>S3: Activation Object Lock WORM
    B->>TSA: Demande horodatage RFC 3161
    TSA-->>B: Jeton TSA
    B->>HSM: Signature Merkle batch
    HSM-->>B: Signature ECDSA_SHA384
    B->>B: Statut SEALED + retention_until

Legende : Le client chiffre le document localement, le transfert au backend qui le stocke sur S3. Le hash est calcule cote serveur. Apres la fenetre corrective, le scellement probatoire est effectue (Object Lock, TSA, Merkle+HSM). Le document acquiert alors sa valeur probatoire.

6.2 Consultation et verification¶

Acces a un document scelle¶

La consultation d'un document scelle suit un processus de verification d'integrite systematique, garantissant que le contenu restitue est identique au contenu depose.

Le flux de consultation s'articule en quatre etapes :

1. Requete authentifiee : L'utilisateur demande l'acces a un document. Le systeme de Row Level Security (RLS) garantit que seul le proprietaire (ou un role autorise) peut acceder a l'enregistrement. Le contexte utilisateur est injecte via SET LOCAL app.current_user_id dans chaque transaction.

2. Recuperation depuis S3 : Le backend recupere le fichier chiffre depuis OVH Object Storage via son chemin ovh_path.

3. Verification d'integrite : Avant toute restitution, le systeme recalcule le hash SHA3-256 du fichier chiffre recupere et le compare au hash stocke en base (file_hash, 32 octets). Si les hash divergent, l'acces est refuse et une alerte est declenchee.

4. Dechiffrement client-side : Le fichier chiffre est transmis au client, qui le dechiffre localement avec sa cle AES-256-GCM. Le serveur ne manipule jamais le contenu en clair.

Verification de la preuve Merkle¶

A tout moment, l'integrite probatoire d'un document peut etre verifiee independamment par reconstitution de la preuve d'inclusion Merkle :

• Le systeme recupere la preuve d'inclusion (chemin d'audit depuis la feuille jusqu'a la racine).
• Il recalcule la racine de l'arbre a partir du hash du document et des noeuds intermediaires.
• Il compare la racine calculee a la racine signee et horodatee.

Si la racine recalculee correspond a la racine signee, l'integrite du document est prouvee mathematiquement : toute modification du contenu, meme d'un seul octet, aurait modifie le hash racine.

Verification du scellement¶

Le service BatchSealService permet de verifier la validite du scellement d'un lot :

• Verification de la signature HSM : La signature ECDSA_SHA384 du payload canonique est verifiee via le HSM.
• Verification de l'attestation d'horloge : L'attestation NTS associee au scellement est validee pour confirmer l'exactitude temporelle.
• Verification du payload : Le contenu canonique du scellement (identifiant du lot, racine Merkle, nombre d'elements, algorithme) est verifie pour sa coherence structurelle.

Statuts documentaires et acces¶

Le comportement du systeme depend du statut du document :

Des restrictions supplementaires s'appliquent :

• Suppression logique (deleted_at non null) : Le document n'est plus accessible ; l'endpoint retourne HTTP 410.
• Verrouillage juridique (legal_lock = true) : Le document est temporairement bloque ; l'endpoint retourne HTTP 423. Motifs possibles : litige en cours, audit externe, controle reglementaire.

6.3 Destruction controlee¶

Statut : DONE (PD-250 -- Job destruction definitive et bordereau)

Cadre normatif¶

La destruction de documents archives est un acte irreversible encadre par les normes ISO 14641 (article 11.4) et NF Z42-013 (article 9.2). ProbatioVault implemente un processus de destruction definitive automatisee qui garantit la tracabilite complete et la production de preuves permanentes.

Le principe fondamental est le fail-closed : aucune destruction physique n'est autorisee sans bordereau probatoire valide, signe et horodatage.

Conditions d'eligibilite¶

Un document ne devient eligible a la destruction que lorsque toutes les conditions suivantes sont simultanement remplies :

• La retention en base de donnees est expiree (retention_until < NOW()).
• La retention S3 Object Lock est expiree (mode COMPLIANCE termine).
• Le verrouillage juridique est absent ou expire (legal_lock = false ou legal_lock_until < NOW()).
• Le statut du document est EXPIRED (un document SEALED ou PENDING n'est jamais eligible).

Une tolerance d'horloge (clockSkewTolerance) est appliquee de maniere soustractive pour garantir qu'un document n'est considere eligible que si sa date d'expiration plus la tolerance est strictement inferieure a la date courante.

Processus de destruction par batch¶

Le processus est orchestre par un job BullMQ (file pv-jobs-destruction, concurrence 1) et suit un ordonnancement strict en deux temps :

Temps 1 -- Preparation probatoire (avant toute suppression)¶

1. Selection des documents eligibles dans la limite du batchSize configure.
2. Creation du batch (entite destruction_batches, schema vault_secure) avec statut PENDING puis transition vers RUNNING.
3. Generation du bordereau : Le systeme produit un bordereau consolide au format PDF/A contenant les champs autorises (identifiant batch, horodatage du run, identifiant technique de chaque document, type documentaire, hash probatoire, dates de scellement/expiration/destruction). Les donnees personnelles directes en sont exclues.
4. Signature HSM : Le bordereau PDF/A est signe electroniquement via HSM (ECDSA_SHA384, conforme eIDAS article 26).
5. Horodatage TSA : Un jeton TSA RFC 3161 est appose (eIDAS article 42). En cas d'echec persistant apres le nombre de tentatives configure, le batch echoue sans destruction.
6. Persistance du bordereau : Le bordereau signe et horodatage est stocke sur S3 avec les references de signature et de cle. Un batch produit exactement un bordereau consolide.

Temps 2 -- Execution sequentielle (apres validation du bordereau)¶

Pour chaque document du batch, de maniere sequentielle :

1. Re-verification d'eligibilite dans une transaction SERIALIZABLE.
2. Zeroisation cryptographique (uniquement pour les documents du flux legal_lock) : Effacement securise des cles de chiffrement associees. En cas d'echec de la zeroisation, le document est ignore (fail-closed).
3. Suppression S3 avec retry et backoff exponentiel.
4. Finalisation atomique en base : Dans une seule transaction, mise a jour du statut vers DESTROYED et insertion de l'entree d'audit liant documentId, batchId et bordereauId.

Garanties d'irreversibilite¶

Les transitions inverses sont formellement interdites. Un document DESTROYED ne peut jamais revenir a un statut anterieur. La machine a etats impose les transitions suivantes sans retour :

PENDING -> SEALED -> EXPIRED -> DESTROYED

Le bordereau de destruction est conserve indefiniment (retentionExpiry = null) et n'est jamais eligible a la destruction automatique. Il constitue la preuve permanente que la destruction a ete effectuee conformement aux regles.

Gestion des erreurs et reconciliation¶

En cas d'echec partiel (suppression S3 reussie mais finalisation en base echouee), un mecanisme de reconciliation est declenche pour resoudre les incoherences. Toute erreur unitaire est tracee dans l'audit et declanche une alerte operationnelle. Les batches partiellement echoues (PARTIAL_FAILED) peuvent etre reessayes via creation d'un nouveau batch referençant le batch parent.

Diagramme : Flux de destruction controlee¶

sequenceDiagram
    participant Job as Job BullMQ
    participant Elig as Eligibilite
    participant Bord as BordereauService
    participant HSM as HSM
    participant TSA as Autorite TSA
    participant S3 as OVH S3
    participant DB as PostgreSQL
    participant Audit as Audit Log

    Job->>Elig: Selection documents eligibles
    Elig-->>Job: Liste documents
    Job->>DB: Creation batch PENDING
    Job->>Bord: Generation bordereau PDF/A
    Bord->>HSM: Signature ECDSA_SHA384
    HSM-->>Bord: Signature
    Bord->>TSA: Horodatage RFC 3161
    TSA-->>Bord: Jeton TSA
    Bord->>S3: Stockage bordereau signe
    loop Pour chaque document
        Job->>Elig: Re-verification eligibilite
        Job->>S3: DeleteObject (avec retry)
        Job->>DB: UPDATE DESTROYED + INSERT audit
    end
    Job->>Audit: Publication resultat batch

Legende : Le job BullMQ orchestre le processus en deux temps. Le bordereau probatoire est genere, signe et horodatage avant toute suppression physique (fail-closed). Chaque document est ensuite detruit sequentiellement avec trace d'audit unitaire.

6.4 Verification d'integrite periodique¶

Statut : En cours (PD-251 -- Verification d'integrite periodique, Q1 2026)

Objectif¶

La verification d'integrite periodique automatisee est un mecanisme exige par les normes NF Z42-013 (article 11.1) et ISO 14641 (article 6.2). Son objectif est de detecter toute corruption ou alteration des documents archives, en verifiant l'ensemble de la chaine de preuve probatoire.

Ce composant est en cours de developpement (Q1 2026). Les sections suivantes decrivent l'architecture prevue telle que specifiee.

Perimetre de verification¶

Chaque execution de verification (run) controle, pour chaque archive selectionnee, les quatre maillons de la chaine de preuve :

Aucun document du perimetre ne peut etre considere comme verifie si l'un des quatre maillons n'a pas un resultat explicite.

Detection avec double verification¶

En cas de divergence de hash, le systeme applique un protocole de confirmation avant toute action :

1. Relecture immediate : Nouvelle connexion S3 et recalcul SHA3-256.
2. Verification alternative : Lecture via un endpoint different (HEAD + GET) et recalcul.

3. Confirmation : Si la divergence persiste apres le nombre maximal de tentatives configure (defaut : 3, intervalle

   200 ms), le document passe au statut SUSPECT.

Chaque tentative est journalisee avec horodatage, methode utilisee, hash calcule, resultat et cause d'echec eventuelle.

Reaction graduee¶

La reponse a une corruption confirmee suit quatre phases :

• Phase 1 -- Gel : Le document est place en statut SUSPECT, l'acces en lecture publique et l'export sont bloques. L'ecriture est limitee au mode append-only signe.
• Phase 2 -- Snapshot forensique : Capture du hash attendu, du hash observe, de la preuve Merkle, de l'etat TSA et blockchain. Le snapshot est signe par HSM.
• Phase 3 -- Restauration controlee : Tentative de restauration depuis la replique CRR Francfort. Si le hash post-restauration est coherent, le document passe a RESTORED et l'ancienne version est archivee comme CORRUPTED_ARCHIVED. Sinon, le statut CORRUPTED_CONFIRMED est applique.
• Phase 4 -- Rapport d'incident : Production d'un rapport JSON canonicalise (RFC 8785) signe par HSM et d'un PDF signe, avec tracabilite complete de l'incident.

SLA temporels prevus¶

Tout depassement de SLA declenche une alerte operationnelle et marque le run comme non conforme.

Etat d'avancement¶

Synthese du cycle de vie¶

Diagramme : Etats du cycle de vie documentaire¶

stateDiagram-v2
    [*] --> PENDING : Upload + chiffrement
    PENDING --> SEALED : Scellement probatoire
    PENDING --> Supprime : Suppression proprietaire
    SEALED --> EXPIRED : Retention expiree
    SEALED --> Consulte : Lecture + verification
    Consulte --> SEALED : Retour conservation
    SEALED --> SUSPECT : Corruption detectee
    SUSPECT --> RESTORED : Restauration CRR
    SUSPECT --> CORRUPTED : Echec restauration
    EXPIRED --> DESTROYED : Destruction controlee
    EXPIRED --> Supprime : Purge manuelle
    DESTROYED --> [*]
    Supprime --> [*]

Legende : Le document suit un cycle de vie lineaire principal (PENDING, SEALED, EXPIRED, DESTROYED) avec des etats intermediaires pour la consultation, la detection de corruption (SUSPECT, verification d'integrite periodique -- en cours PD-251) et la suppression. Les transitions inverses sont interdites sur l'axe principal. L'etat SUSPECT et ses transitions (RESTORED, CORRUPTED) relevent de PD-251, en cours de developpement Q1 2026.

Invariants contractuels couverts¶

References¶