PD-246 — Politique de conservation 50 ans — archivage WORM long terme (Code du travail)¶

Epic : LEGAL & COMPLIANCE (PD-217) Sprint : 10 Priorité : Medium Projet : infra

1. Contexte et motivation¶

1.1 GAP-4 — Obligation légale non couverte¶

Le document Architecture Executive (doc 43) stipule explicitement :

"Obligation légale : conservation 50 ans (Code du travail)"

Le cross-référencement des documents corporate (41, 42, 43) avec les spécifications techniques révèle qu'aucune story existante ne couvre la mise en place de cette politique de rétention à long terme au niveau infrastructure et cryptographique.

Les stories existantes traitent la production de preuves : - PD-38 — SHA3-256 (empreinte des documents) - PD-39 — TSA RFC 3161 (horodatage probatoire) - PD-40 — HSM rotation (rotation des clés de signature) - PD-52 — Ethereum ancrage (ancrage blockchain)

Mais aucune ne traite leur préservation probatoire sur un horizon de 50 ans.

1.2 Base légale¶

2. Objectif¶

Définir et implémenter la politique de conservation WORM long terme garantissant l'accès, l'intégrité et l'opposabilité juridique des documents ProbatioVault sur un horizon de 50 ans, conformément au Code du travail et aux normes ISO 14641 / NF Z42-013.

3. Périmètre¶

3.1 Inclus¶

• Politique de rétention S3 WORM (Object Lock) — retention 50 ans non modifiable, mode COMPLIANCE
• Long Term Validation (LTV) des signatures HSM et jetons TSA (renouvellement avant expiration)
• Plan de renouvellement cryptographique sur 50 ans (gestion de la déprécation algorithmique)
• Re-ancrage blockchain périodique des preuves (re-timestamping sur Ethereum L2)
• Audit périodique d'intégrité WORM (checksum automatisé, fréquence : annuelle minimum)
• Procédure de migration en cas de déprécation d'algorithme (SHA3-256, ECDSA P-384)
• SLA de disponibilité des archives sur 50 ans (multi-région, multi-provider)
• Documentation de la chaîne de custody pour usage probatoire

3.2 Exclus¶

• Production des preuves initiales (PD-38, PD-39, PD-52)
• Rotation HSM opérationnelle (PD-40)
• Format des preuves (PD-245)
• Droits RGPD d'effacement (conflit avec conservation 50 ans — traité séparément)

4. Composants techniques¶

4.1 S3 WORM Object Lock — Configuration COMPLIANCE¶

resource "aws_s3_bucket_object_lock_configuration" "worm_50_ans" {
  bucket = aws_s3_bucket.probatiovault_archives.id

  rule {
    default_retention {
      mode  = "COMPLIANCE"
      years = 50
    }
  }
}

Caractéristiques : - Mode COMPLIANCE : aucun utilisateur, y compris root AWS, ne peut supprimer l'objet pendant la période de rétention - Mode GOVERNANCE exclu : des privilèges spéciaux permettraient de contourner la rétention - Multi-région : réplication S3 Cross-Region (eu-west-3 Paris + eu-central-1 Frankfurt minimum)

4.2 Long Term Validation (LTV)¶

La LTV garantit la validité des preuves cryptographiques après expiration des certificats d'origine.

Principe : Avant qu'un certificat TSA ou HSM expire, les informations de validation (état de révocation OCSP/CRL, chaîne de certification complète) sont archivées avec la preuve, permettant une vérification ultérieure sans dépendance au service de révocation d'origine.

Processus automatisé : 1. Scanner les jetons TSA dont le certificat expire dans < 12 mois 2. Collecter et archiver la chaîne de certification complète (OCSP stappling) 3. Produire un jeton TSA de re-cachetage (re-timestamping) sur l'archive LTV 4. Mettre à jour le registre des preuves

4.3 Plan de renouvellement cryptographique¶

Règle : Tout changement d'algorithme DOIT être accompagné d'une procédure de re-scellement des preuves existantes avec le nouvel algorithme, garantissant la continuité de la chaîne de preuve.

4.4 Re-ancrage blockchain périodique¶

Les preuves ancrées sur Ethereum L2 (via PD-52) DOIVENT faire l'objet d'un re-ancrage périodique pour maintenir leur opposabilité dans le temps.

Fréquence recommandée : tous les 5 ans (configurable selon évolution réglementaire).

Processus : 1. Récupérer le Merkle root des preuves de la période 2. Calculer un hash agrégé des archives WORM 3. Soumettre une nouvelle transaction Ethereum L2 avec ce hash 4. Archiver la preuve de re-ancrage avec les archives existantes

4.5 Audit d'intégrité WORM¶

Objectif : Détecter toute corruption silencieuse des archives (bit rot, défaillance matérielle).

Processus automatisé (annuel minimum) :

1. Lister tous les objets S3 avec leur checksum (MD5 + SHA-256)
2. Comparer avec les checksums archivés au moment du dépôt
3. Alerter sur tout écart (PagerDuty + Jira ticket automatique)
4. Rapport d'intégrité archivé et signé TSA

4bis. Diagrammes Mermaid¶

4bis.1 Diagramme d'états — Cycle de vie d'une preuve archivée (50 ans)¶

Une preuve archivée traverse plusieurs états au cours de sa conservation longue durée. Les transitions sont déclenchées par les processus automatisés (LTV, re-ancrage, audit, migration).

stateDiagram-v2
    [*] --> ARCHIVED : Dépôt WORM S3 COMPLIANCE
    ARCHIVED --> LTV_PENDING : Certificat TSA expire < 12 mois
    LTV_PENDING --> LTV_RENEWED : Re-cachetage TSA réussi [INV-246-02]
    LTV_RENEWED --> ARCHIVED : Registre mis à jour
    ARCHIVED --> REANCHOR_PENDING : Cycle 5 ans atteint
    REANCHOR_PENDING --> REANCHORED : Tx Ethereum L2 confirmée
    REANCHORED --> ARCHIVED : Preuve re-ancrage archivée
    ARCHIVED --> AUDIT_OK : Audit intégrité annuel — checksums valides [INV-246-03]
    AUDIT_OK --> ARCHIVED : Rapport signé TSA archivé
    ARCHIVED --> CORRUPTED : Audit intégrité — checksum divergent
    CORRUPTED --> INCIDENT : Alerte PagerDuty + ticket Jira
    ARCHIVED --> MIGRATION_PENDING : Algorithme déclaré déprécié
    MIGRATION_PENDING --> MIGRATED : Re-scellement nouvel algo [INV-246-04]
    MIGRATED --> ARCHIVED : Chaîne de preuve vérifiée

    note right of ARCHIVED
        État nominal — objet WORM
        non supprimable [INV-246-01, INV-246-05]
    end note

    note right of CORRUPTED
        État terminal anomalie
        Procédure incident obligatoire
    end note

4bis.2 Diagramme de séquence — Processus LTV (renouvellement avant expiration)¶

Le processus LTV implique le scheduler, le service LTV, le TSA, le HSM, le stockage S3 WORM et le registre de preuves. Ce flux garantit INV-246-02 (LTV avant expiration) et INV-246-01 (conservation WORM).

sequenceDiagram
    participant Scheduler as LTV Scheduler
    participant LTV as LTV Service
    participant S3 as S3 WORM (COMPLIANCE)
    participant TSA as TSA RFC 3161
    participant HSM as HSM PKCS#11
    participant Registry as Registre Preuves

    Scheduler->>LTV: Déclenchement périodique (cron)
    LTV->>Registry: Scanner jetons TSA expirant < 12 mois
    Registry-->>LTV: Liste jetons à renouveler

    loop Pour chaque jeton expirant
        LTV->>TSA: Récupérer chaîne certification complète (OCSP stapling)
        TSA-->>LTV: Chaîne + état révocation
        LTV->>S3: Archiver informations LTV avec preuve originale [INV-246-01]
        S3-->>LTV: Confirmation Object Lock COMPLIANCE
        LTV->>HSM: Signer archive LTV (ECDSA P-384)
        HSM-->>LTV: Signature
        LTV->>TSA: Produire jeton re-cachetage [INV-246-02]
        TSA-->>LTV: Nouveau jeton TSA
        LTV->>S3: Archiver jeton re-cachetage [INV-246-05]
        LTV->>Registry: Mettre à jour registre
    end

    LTV-->>Scheduler: Rapport LTV (nb renouvelés, erreurs)

4bis.3 Diagramme de séquence — Re-ancrage blockchain périodique (5 ans)¶

Le re-ancrage maintient l'opposabilité des preuves sur Ethereum L2 dans le temps, conformément à INV-246-04 (chaîne de preuve valide après migration).

sequenceDiagram
    participant Scheduler as Re-anchor Scheduler
    participant Audit as Integrity Audit Service
    participant S3 as S3 WORM (COMPLIANCE)
    participant Merkle as Merkle Service
    participant ETH as Ethereum L2 (PD-52)
    participant Registry as Registre Preuves

    Scheduler->>Audit: Déclenchement cycle 5 ans
    Audit->>S3: Calculer hash agrégé archives WORM [INV-246-03]
    S3-->>Audit: Checksums objets période
    Audit->>Merkle: Récupérer Merkle root preuves période
    Merkle-->>Audit: Merkle root
    Audit->>Audit: Construire payload (hash agrégé + Merkle root)
    Audit->>ETH: Soumettre transaction re-ancrage
    ETH-->>Audit: Tx hash + block confirmation
    Audit->>S3: Archiver preuve re-ancrage [INV-246-01, INV-246-05]
    Audit->>Registry: Enregistrer re-ancrage (tx hash, block, date)
    Audit-->>Scheduler: Rapport re-ancrage

5. Invariants¶

6. Critères d'acceptation¶

• CA-246-01 : Les buckets S3 sont configurés avec Object Lock en mode COMPLIANCE, retention 50 ans
• CA-246-02 : Un processus LTV renouvelle les preuves de signature avant expiration des certificats
• CA-246-03 : Un audit d'intégrité annuel automatisé vérifie les checksums WORM
• CA-246-04 : Un plan de migration cryptographique documenté couvre les scénarios de déprécation algo
• CA-246-05 : La politique de rétention est documentée et opposable (certification ISO 14641)

7. Scénarios de test¶

Scénario 1 — Configuration WORM non contournable¶

Given un bucket S3 configuré en mode COMPLIANCE avec rétention 50 ans When une tentative de suppression d'un objet est effectuée (y compris par root AWS) Then la suppression est refusée avec erreur ObjectLockConfigurationNotFoundError

Scénario 2 — Processus LTV déclenché avant expiration¶

Given un jeton TSA dont le certificat expire dans 11 mois When le processus LTV automatisé s'exécute Then un re-cachetage TSA est produit et archivé avec la preuve originale

Scénario 3 — Audit d'intégrité — checksum valide¶

Given une archive WORM déposée avec son checksum SHA-256 When l'audit annuel s'exécute Then le checksum calculé correspond au checksum archivé et aucune alerte n'est levée

Scénario 4 — Audit d'intégrité — corruption détectée¶

Given une archive WORM dont les bits ont été corrompus (simulation) When l'audit annuel s'exécute Then une alerte PagerDuty est levée et un ticket Jira est créé automatiquement

Scénario 5 — Migration cryptographique¶

Given l'algorithme SHA3-256 est déclaré déprécié When la procédure de migration est exécutée Then toutes les preuves existantes sont re-scellées avec le nouvel algorithme et la chaîne de preuve reste vérifiable

8. Fichiers impactés¶

9. Dépendances¶

10. Références normatives¶

• Code du travail art. R3243-5 — Conservation des bulletins de paie
• ISO 14641 — Systèmes d'archivage électronique à valeur probatoire
• NF Z42-013 — Archivage électronique — spécifications fonctionnelles
• eIDAS art. 42 — Cachets électroniques qualifiés (Règlement UE 910/2014)
• RFC 3161 — Time-Stamp Protocol (TSP) — renouvellement LTV
• AWS S3 Object Lock — Mode COMPLIANCE pour rétention immuable

Fin de la spécification PD-246.