Expression de Besoin — PD-44¶

Implémenter validation Object Lock WORM¶

EPIC : PD-198 — Storage

1. Contexte¶

ProbatioVault repose sur un modèle probatoire intégrant un stockage WORM (Write Once Read Many) afin de garantir l'immutabilité des documents et journaux associés, conformément aux référentiels :

• NF Z42-013
• ISO 14641
• eIDAS
• Exigences internes d'auditabilité décrites dans l'architecture technique

L'architecture actuelle prévoit l'utilisation d'Object Storage compatible S3 avec Object Lock activé (OVH / AWS Glacier) dans une logique de conservation probatoire longue durée.

Toutefois, l'activation effective et le maintien opérationnel du mode WORM doivent être vérifiables, contrôlables et auditables à tout moment.

2. Problématique¶

Le simple fait de configurer Object Lock au moment du provisioning ne garantit pas :

• que le bucket est réellement en mode Object Lock actif,
• que la politique de rétention est effectivement appliquée,
• que le mode est bien en COMPLIANCE et non en GOVERNANCE,
• qu'aucune modification accidentelle ou administrative n'a désactivé la protection,
• que les objets uploadés héritent bien d'une rétention conforme.

Or, toute faiblesse à ce niveau :

• compromet la valeur probatoire des documents,
• fragilise la conformité NF Z42-013 / ISO 14641,
• expose ProbatioVault à un risque juridique majeur,
• détruit la promesse fondatrice d'immutabilité.

3. Objectif du besoin¶

Garantir que :

1. Le stockage configuré comme WORM est effectivement verrouillé.
2. La période de rétention définie est bien appliquée aux objets.
3. Le mode d'application (Governance / Compliance) correspond au niveau d'exigence probatoire attendu.
4. Toute anomalie soit détectable immédiatement.
5. L'état WORM soit vérifiable dans le cadre d'un audit externe.

4. Résultats attendus¶

Le système doit permettre :

A. Vérification d'activation Object Lock¶

• Confirmation que le bucket est créé avec Object Lock activé.
• Confirmation que la configuration n'est pas désactivable.
• Vérification régulière (automatisée) de cet état.

B. Vérification du mode de rétention¶

• Identification explicite du mode :
• Governance
• Compliance
• Capacité à détecter un changement de mode.

C. Vérification de la période de rétention¶

• Contrôle de la durée configurée (ex. 10, 30, 50 ans).
• Détection d'une réduction anormale.
• Contrôle que les objets héritent bien de cette rétention.

D. Détection d'écart¶

Le système doit identifier :

• Absence d'Object Lock.
• Objet sans rétention.
• Objet avec rétention inférieure au minimum légal.
• Bucket en mode Governance alors que Compliance est requis.
• Modification administrative suspecte.

E. Auditabilité¶

• Capacité à produire une preuve formelle de l'état WORM.
• Possibilité d'intégrer cette preuve dans la chaîne probatoire globale (Preuve Composite).
• Traçabilité des contrôles effectués.

5. Contraintes explicites¶

• Aucune altération des objets existants.
• Aucune opération pouvant fragiliser la conformité WORM.
• Aucun mécanisme reposant sur la confiance humaine seule.
• Aucune dépendance non maîtrisée à un fournisseur cloud.

6. Tensions à préserver¶

Ce besoin crée plusieurs tensions qu'il ne faut pas résoudre prématurément :

Ces tensions doivent être explicitement assumées, pas implicitement contournées.

7. Risques redoutés (intention humaine)¶

Ce que ProbatioVault veut éviter absolument :

• Qu'un administrateur désactive Object Lock sans que personne ne s'en aperçoive.
• Qu'un bucket soit recréé sans verrouillage.
• Qu'un objet soit uploadé sans rétention.
• Qu'un audit révèle une faille WORM.
• Qu'un tribunal invalide la valeur probatoire d'un document.

8. Résultats inacceptables¶

• Document supprimable avant échéance.
• Rétention raccourcie.
• Passage silencieux en mode Governance.
• Absence de preuve d'état WORM.
• Impossibilité de démontrer la configuration à un auditeur.

9. Périmètre¶

Inclus :

• Buckets primaires OVH
• Buckets Glacier AWS
• Objets uploadés via API
• Jobs asynchrones de réplication
• Contrôle périodique

Exclus :

• Architecture blockchain
• Signature HSM
• Gestion des clés utilisateurs

Résumé stratégique¶

PD-44 est un besoin de garantie d'immutabilité vérifiable.

Il ne s'agit pas simplement de "configurer Object Lock", mais de :

S'assurer en permanence que la promesse WORM est réelle, mesurable, auditée et juridiquement opposable.

Ce besoin est structurel pour :

• La conformité NF Z42-013
• L'architecture multi-cloud
• La validité de la Preuve Composite Ancrée