Aller au contenu

PD-250 — Expression de besoin — Job destruction définitive et bordereau

1. Contexte

ProbatioVault conserve des documents à valeur probatoire selon les normes ISO 14641-11.4 et NF Z42-013-9.2, avec une protection WORM (Write-Once-Read-Many) au niveau base de données et stockage objet.

Deux lacunes ont été identifiées lors de l'analyse de conformité (PD-244) : - GAP-FINAL-006 (ISO 14641-11.4) : La destruction définitive des documents après expiration de la rétention n'est pas automatisée. Le passage SEALED → EXPIRED est implémenté, mais la destruction effective (suppression physique + trace) est manuelle et non formalisée. - GAP-FINAL-014 (NF Z42-013-9.2) : Aucun bordereau de destruction n'est généré. La norme exige un document attestant de la destruction, listant les éléments détruits, daté et signé.

L'infrastructure existante comprend : - Un service de purge (DocumentPurgeService) avec des transitions SEALED → EXPIRED - Des jobs planifiés d'expiration (2h) et d'auto-purge (3h) via BullMQ - Une protection WORM au niveau triggers PostgreSQL - Un service de destruction cryptographique (LegalDestructionService, PD-81) pour les scellés judiciaires - Un stockage objet S3 (OVH) avec Object Lock COMPLIANCE prévu

2. Objectifs principaux

OBJ-01 : Automatiser la destruction définitive des documents dont la rétention est expirée, en supprimant à la fois la référence en base de données et l'objet physique sur le stockage S3.

OBJ-02 : Générer un bordereau de destruction au format PDF/A, signé électroniquement et horodaté RFC 3161, attestant de la destruction avec valeur probatoire.

OBJ-03 : Produire un bordereau par batch (un run du job = un bordereau consolidé) tout en traçant chaque destruction unitaire dans l'audit log avec une référence vers le bordereau.

OBJ-04 : Intégrer les documents dont le scellé judiciaire (legal_lock) est expiré dans le processus de destruction automatique, fusionnant les deux flux de destruction (rétention expirée + legal lock expiré).

OBJ-05 : Conserver les bordereaux de destruction de manière permanente (sans limite de durée), conformément aux exigences ISO 14641-11.4 et NF Z42-013-9.2.

OBJ-06 : Assurer la conformité RGPD en ne conservant aucune donnée au-delà de la durée strictement nécessaire, tout en maintenant la trace de destruction indéfiniment.

3. Non-objectifs (exclusions explicites)

  • NON-01 : La modification des durées de rétention légales (bulletins 50 ans, factures 10 ans, etc.) n'est pas dans le périmètre. Les règles existantes restent inchangées.
  • NON-02 : La restauration de documents détruits n'est pas un objectif. La destruction est irréversible.
  • NON-03 : La destruction manuelle par l'utilisateur (déjà implémentée dans DocumentPurgeService pour les documents EXPIRED) n'est pas modifiée.
  • NON-04 : La migration des bordereaux de destructions passées (avant mise en service) n'est pas dans le périmètre.

4. Contraintes

Juridiques et réglementaires

  • ISO 14641-11.4 : Exige une procédure formalisée de destruction avec traçabilité complète.
  • NF Z42-013-9.2 : Exige un bordereau de destruction signé et daté, conservé comme preuve.
  • RGPD : Interdiction de conserver des données personnelles au-delà de la finalité. La destruction doit être effective, pas seulement logique.
  • eIDAS : La signature électronique du bordereau doit avoir une valeur probatoire reconnue (horodatage RFC 3161).

Techniques

  • La protection WORM PostgreSQL (triggers SECURITY DEFINER) empêche la modification/suppression de documents SEALED. Le processus de destruction ne doit intervenir qu'APRES expiration confirmée du statut WORM.
  • L'Object Lock COMPLIANCE sur S3 est irréversible. La suppression physique ne peut intervenir qu'après expiration de la période de rétention S3.
  • BullMQ v5 : les API getRepeatableJobs() et removeRepeatableByKey() sont deprecated — utiliser getJobSchedulers().

Organisationnelles

  • La fréquence du job de destruction est configurable (défaut : quotidien).
  • Le job doit être idempotent (un même document ne peut être détruit deux fois).
  • Le bordereau est un artefact de conformité — il doit survivre à la destruction des données qu'il documente.

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

  • INACCEPTABLE-01 : Un document est supprimé physiquement (S3 + base) sans qu'un bordereau de destruction ait été généré et signé au préalable.
  • INACCEPTABLE-02 : Un document sous scellé judiciaire actif (legal_lock non expiré) est détruit par le job automatique.
  • INACCEPTABLE-03 : Un document dont la rétention WORM n'est pas encore expirée est ciblé par la destruction.
  • INACCEPTABLE-04 : Le bordereau de destruction est lui-même détruit ou altéré.
  • INACCEPTABLE-05 : Une panne partielle (S3 injoignable, TSA timeout) entraîne une destruction partielle sans trace ni possibilité de reprise.
  • INACCEPTABLE-06 : La destruction d'un batch échoue silencieusement, sans alerte ni audit log.
  • INACCEPTABLE-07 : Les données personnelles contenues dans les métadonnées chiffrées persistent après destruction (violation RGPD).

6. Tensions et conflits non résolus

  • TENSION-01 : La RGPD exige la suppression effective des données. L'ISO 14641 exige une trace permanente de ce qui a été détruit. Le bordereau doit contenir suffisamment d'information pour attester de la destruction sans reproduire les données personnelles détruites. Quelle granularité d'information dans le bordereau ? (ID document, hash, type, dates — mais pas le contenu ni les métadonnées personnelles.)

  • TENSION-02 : L'Object Lock S3 COMPLIANCE est irréversible. Si la rétention S3 est plus longue que la rétention en base, le document peut être marqué "détruit" en base mais encore présent physiquement sur S3. Le processus de destruction doit-il attendre la convergence des deux expirations ou procéder en deux temps ?

  • TENSION-03 : La fusion des flux "rétention expirée" et "legal lock expiré" (OBJ-04) unifie deux processus avec des garanties différentes. La destruction cryptographique (zeroization) de PD-81 est-elle requise aussi pour la destruction post-rétention standard, ou seule la suppression physique suffit ?

7. Décisions PO (questions résolues)

  • Q-01 : Auto-référentiel. Le bordereau est stocké dans ProbatioVault comme document SEALED avec rétention indéfinie. Le système conserve la preuve de ses propres destructions.
  • Q-02 : Oui, préavis configurable. Notification aux propriétaires N jours avant destruction automatique (défaut configurable).
  • Q-03 : Oui, batch size configurable. Plafond de documents par run paramétrable (défaut à définir en spécification) pour éviter surcharge en cas de backlog massif.
  • Q-04 : Retry puis fail-closed. 3 tentatives de signature TSA, puis arrêt complet si échec persistant. Aucune destruction sans bordereau signé. Conforme au learning PD-39 (fail-closed obligatoire).
  • Q-05 : Endpoint dédié. Les bordereaux sont consultables via une API dédiée avec filtres (date, batch), accessible aux administrateurs.

8. Questions ouvertes résiduelles

  • TENSION-01 reste ouverte : granularité exacte des informations dans le bordereau (quels champs du document détruit sont listés sans violer la RGPD ?). À résoudre en spécification.
  • TENSION-02 reste ouverte : stratégie de convergence rétention base vs S3 Object Lock. À résoudre en spécification.
  • TENSION-03 reste ouverte : nécessité de zeroization pour la destruction post-rétention standard. À résoudre en spécification.