ProbatioVault est un coffre-fort numérique souverain conçu pour garantir : - la confidentialité totale des documents utilisateurs ("zero-knowledge"),\

leur intégrité probatoire (WORM / hash immuable / blockchain),\
et leur résilience dans le temps grâce à une triple redondance

OVH + AWS Paris + AWS Francfort.

Le système vise à offrir à la fois un usage B2C (coffre individuel) et B2B (archivage légal d'entreprise), tout en restant entièrement souverain et auditable.

Principes fondateurs¶

Le design de ProbatioVault repose sur cinq piliers techniques et éthiques indissociables. Ces principes guident l'ensemble des décisions d'architecture, de développement et d'exploitation de la plateforme.

🏛️ Souveraineté¶

OVH Cloud constitue le socle principal de l'infrastructure.\ Ce choix répond à une double exigence :

Souveraineté technologique : hébergement en France, sous juridiction européenne (RGPD, CNIL), sans exposition aux lois extraterritoriales comme le Cloud Act américain.
Souveraineté opérationnelle : contrôle complet des environnements (accès, monitoring, gestion des clés, sauvegardes).

L'intégration éventuelle de fournisseurs externes (AWS, etc.) se limite à des usages probatoires non exploitables (stockage immuable WORM chiffré).\ Aucune donnée lisible n'est jamais transférée hors du territoire européen.

🔒 Confidentialité¶

La confidentialité repose sur un modèle Zero-Knowledge :\ aucune donnée en clair n'est visible, ni stockée, ni manipulée par le serveur.\ Toutes les opérations sensibles (chiffrement, dérivation de clés, signature) sont effectuées côté client, avant tout envoi vers le backend.

Le backend et les services cloud ne voient que des objets chiffrés et des métadonnées neutres (hash, timestamp, identifiant aléatoire).\ Cette approche garantit que même une compromission serveur ou cloud ne permettrait pas d'accéder au contenu des documents.

⚖️ Conformité¶

ProbatioVault respecte les référentiels français et européens les plus stricts :

WORM (Write Once Read Many) : aucune modification possible après écriture.
RGPD : droits d'accès, d'effacement, et de portabilité assurée par conception.
Normes probatoires : ISO 14641 et NF Z42-013 (gestion des archives numériques).

Chaque opération (upload, suppression, signature) est tracée et horodatée de manière probatoire, permettant la production d'un dossier d'audit complet en cas de contrôle ou de litige.

⚙️ Performance¶

L'architecture est conçue pour être stateless et distribuée.\ Chaque composant (API, worker, base de données, stockage) peut être mis à l'échelle indépendamment, sans dépendances fortes.\ Cette approche garantit :

une montée en charge linéaire,
une résilience accrue (restarts sans perte d'état),
et une maintenance simplifiée (déploiements continus sans interruption).

Les traitements intensifs (export WORM, recalculs de hash, rotation de clés) sont externalisés vers des workers asynchrones pour préserver la réactivité de l'API.

🧾 Auditabilité¶

Chaque action effectuée dans ProbatioVault est journalisée dans un registre append-only (non modifiable, horodaté, signé).\ Ce registre assure la traçabilité complète des opérations, depuis l'import d'un fichier jusqu'à sa purge définitive.\ Chaque événement est signé par un identifiant cryptographique unique et horodaté selon une source de temps certifiée (NTP sécurisé ou blockchain d'ancrage).

Cette approche rend possible un audit externe ou judiciaire à tout moment, sans dépendre du bon vouloir de la plateforme.\ L'auditabilité est ainsi une fonctionnalité native, pas une contrainte ajoutée a posteriori.

💡 Bonnes pratiques :

La robustesse prime sur la sophistication.\ Chaque brique doit être testable, documentée et remplaçable sans impact global.\ Un système bien conçu doit pouvoir survivre à la panne ou au remplacement de l'un de ses composants sans compromettre la sécurité ou l'intégrité des preuves.

Architecture globale¶

Vue d'ensemble¶

L'architecture de ProbatioVault repose sur une infrastructure bi-cloud souveraine, associant OVH Cloud et AWS Glacier,\ avec une option de triple redondance pour garantir une conservation probatoire inaltérable et pérenne sur plusieurs décennies.

Ce modèle offre à la fois :

la performance et la souveraineté grâce à OVH (cœur opérationnel et stockage actif),
la durabilité probatoire via AWS Glacier Deep Archive (stockage WORM, multi-AZ, conforme ISO 14641 / NF Z42-013),
et, en option, une redondance souveraine ultime via OVH Cold Archive (copie inaltérable hors ligne, support bande).

Clients (Mobile, PWA, Desktop)
        │
        ▼
[API NestJS sur OVH Cloud]
        │
  ┌─────┼──────────────────────────────┐
  │     │                              │
  ▼     ▼                              ▼
PostgreSQL (OVH)     OVH Object Storage (S3)     Redis (queues)
       │                        │
       └────────Backup async────┘
                    │
                    ▼
          AWS Glacier (Deep Archive - Paris)
                    │
                    ▼
       Réplication (CRR) → AWS Francfort
                    │
                    ▼
          OVH Cold Archive (optionnel)

🔍 Lecture du schéma

Les clients (mobile, PWA, desktop) communiquent uniquement avec l'API NestJS hébergée sur OVH Cloud France.\ Toutes les opérations sensibles (chiffrement, dérivation de clés, signature) sont effectuées côté client avant envoi.
Le backend NestJS stocke les métadonnées dans PostgreSQL (OVH Database as a Service),\ et les documents chiffrés dans OVH Object Storage (compatible S3).\ Les traitements lourds (export, rehash, WORM) sont délégués à des workers Redis/BullMQ.
Une tâche asynchrone (BullMQ) transfère régulièrement les objets chiffrés vers AWS Glacier Deep Archive (région Paris).\ Ce stockage bénéficie par défaut d'une redondance intra-régionale (multi-AZ),\ garantissant la disponibilité même en cas de panne d'un datacenter complet.
Les objets stockés à Paris sont ensuite répliqués automatiquement vers Francfort (CRR),\ créant une redondance géographique probatoire (multi-région européenne) :\ même une perte totale d'AWS Paris n'empêcherait pas la récupération des archives.
En option, un export périodique vers OVH Cold Archive est effectué.\ Ce service repose sur des supports bande en environnement isolé ("air gap"),\ offrant une conservation souveraine longue durée (50 à 100 ans), conforme aux exigences d'archivage légal.

🌐 Logique de redondance¶

Niveau Couche Fournisseur Localisation Objectif

1 Actif OVH Object France Stockage principal et Storage opérationnel

2 WORM AWS Glacier Deep Paris Conservation probatoire probatoire Archive immuable

3 Réplication AWS Glacier Deep Francfort Résilience géographique CRR Archive (multi-région UE)

4 Cold Archive OVH Cold Archive France (offline) Garantie souveraine et archivage longue durée

Chaque couche est indépendante, chiffrée applicativement et horodatée,\ ce qui permet à ProbatioVault de restaurer à tout moment un fichier même en cas de perte d'un fournisseur complet.

💡 Concept général¶

OVH assure la performance, la souveraineté et la maîtrise opérationnelle.
AWS Glacier garantit la durabilité probatoire et la conformité légale internationale.
OVH Cold Archive complète le dispositif en offrant une souveraineté totale et une conservation hors ligne pour les archives à très long terme (> 50 ans).

Ce modèle bi-cloud à redondance triple combine efficacité technique, sécurité juridique, et pérennité historique --- trois piliers essentiels pour un coffre-fort numérique à vocation probatoire.

Stack technique et justification des choix¶

Composant Technologie Justification

Backend NestJS (TypeScript) Modulaire, robuste, scalable, DI native.

Base de données PostgreSQL (OVH JSONB, contraintes fortes, Managed) audit natif.

File asynchrone Redis + BullMQ File de jobs fiable et performante.

Stockage actif OVH Object Storage (S3 Souverain, performant, compatible) Object Lock natif.

Archivage légal AWS Glacier Deep Conservation probatoire Archive (Paris + WORM. Francfort)

Archivage OVH Cold Archive Double garantie souveraine souverain à long terme.

CI/CD GitLab + Docker + Sécurité et traçabilité du Sonar + OVH Runner pipeline.

Monitoring Prometheus + Grafana + Observabilité complète et Loki souveraine

💡 Conseil :

Séparer api, workers et monitoring pour éviter les blocages mutuels (CPU/I/O).

Gestion des données et chiffrement¶

Typologie des données¶

Type de données Exemples **Sensibilité Niveau de *Lieu et mode *Protection concrets risque** de traitement** appliquée**

Métadonnées Hash de Faible Faible (aucune Serveur OVH Stockage clair ou fichier, donnée (PostgreSQL + hashé (aucun contenu empreinte personnelle) logs) exploitable) SHA3-256, date d'import, taille du document

Structurelles Informations de Moyenne Moyen (liées à Serveur OVH Chiffrement au repos compte, quotas, un utilisateur, (base + cache (TDE) et en transit plan sans contenu Redis) (TLS), accès d'abonnement, sensible) restreint identifiants de session

Contenu Titre du Élevée Fort (risque de Côté client Chiffrement sensible document, fuite (avant upload) applicatif mots-clés, d'information AES-256-GCM / annotations, métier) ChaCha20-Poly1305, commentaires clé dérivée (HKDF) internes

Fichiers / pièces Documents, Critique Très fort Côté client Chiffrement complet jointes images, PDF, (risque (avant avant transfert archives juridique et stockage) + (AES-256-GCM), personnel) Cloud chiffré stockage WORM

Données Hash d'ancrage Élevée Fort (preuve Serveur + Hash SHA3-256, probatoires blockchain, juridique) ancrage externe signature journaux cryptographique, d'audit, horodatage certifié horodatages (RFC 3161)

💡 Points clés à retenir

Le chiffrement applicatif est toujours effectué côté client :\ aucune donnée lisible n'est jamais manipulée par le backend.
Les métadonnées sont volontairement neutres\ (hash, taille, date) pour permettre des fonctions de recherche et d'intégrité sans fuite d'information.
Les contenus sensibles et probatoires sont chiffrés dès leur création,\ et protégés par une clé unique dérivée de celle de l'utilisateur (K_doc = HKDF(K_encryption, doc_id)).
La base de données PostgreSQL bénéficie d'un chiffrement au repos (TDE)\ et d'une politique RLS (Row Level Security) empêchant tout accès croisé.

⚠️ Conseil d'implémentation :

Chaque champ introduit dans le modèle de données doit être catégorisé dès la conception selon cette grille,\ afin de déterminer automatiquement le mode de chiffrement, le périmètre d'accès et la durée de conservation.

Clés et dérivations¶

Le modèle de chiffrement de ProbatioVault repose sur une hiérarchie de clés dérivées depuis le mot de passe utilisateur, afin d'assurer :

une isolation stricte entre utilisateurs,
une séparation cryptographique entre documents,
et une rotation sélective des clés sans réécrire les fichiers WORM existants.

Cette architecture garantit que la compromission d'une clé unique n'expose jamais plus qu'un seul document.

🔑 Structure de la chaîne de clés¶

+----------------------------------------------------------------------+ | 💡 Principe fondamental : | | | | Chaque document est chiffré avec une clé unique (K_doc), elle-même | | chiffrée ("enveloppée") par une clé de niveau supérieur (K_master). | | Cette hiérarchie rend possible la rotation des clés maîtres sans | | toucher aux fichiers WORM. | | | | Remarque : Le HSM Cloud OVH (FIPS 140-2 L3) conserve uniquement | | des enveloppes (Master, Device, Recovery) de K_master_user et signe | | des jetons d'autorisation probatoires. | | | | Il ne détient jamais directement les clés de chiffrement des | | documents. | +======================================================================+

🧮 Processus cryptographique détaillé¶

Création du compte :
- Le mot de passe est traité localement avec Argon2id (t=3, m=64 MiB, p=4, ad=\"ProbatioVault_Encryption_v1\").
- La clé obtenue, K_encryption, ne sert qu'à chiffrer la clé maître K_master_user.
- K_master_user est générée aléatoirement (256 bits) et chiffrée localement :

Enc_K_encryption(K_master_user)

Seul le vérifieur SRP-6a (Zero-Knowledge Password Proof) est enregistré côté serveur ;

aucun hash du mot de passe n'est transmis ni stocké.

Création d'un document :
- Dériver K_doc via HKDF-SHA3-256 (Extract+Expand) avec :

IKM = K_master_user, salt = doc_id, info = \"ProbatioVault::Kdoc::v1\", L = 32.

Générer K_share (256 bits aléatoire) ; chiffrer le fichier :

doc.enc = AES-256-GCM(K_share, ...)

Encapsuler K_share sous K_doc :

K_share.enc = Enc_K(K_doc, K_share)

Encapsuler K_doc sous K_device (optionnel) :

K_doc.enc = Enc_K(K_device, K_doc)

Rotation de clés (modèle WORM) :
- Des jobs BullMQ planifiés assurent la rotation automatique des clés :
- Rotation annuelle des clés maîtres serveur (K_master).
- Rotation à la demande des clés utilisateurs (ex. changement de mot de passe).
- Lors d'une rotation :
- Le fichier chiffré (Document.enc) n'est jamais modifié (WORM immuable).
- Seule l'enveloppe (la clé K_doc chiffrée sous K_master) est réencapsulée avec la nouvelle clé maître.
- Une nouvelle version d'enveloppe est alors créée et horodatée :\ Ancienne : K_doc → K_master(v1)\ Nouvelle : K_doc → K_master(v2)
- Le document reste parfaitement lisible, mais sous une clé d'accès renouvelée.
- L'opération est tracée et signée dans les journaux probatoires.
Stockage et persistance :
Aucune clé n'est jamais persistée côté client : elles résident en mémoire volatile ou dans le Secure Enclave / Keystore.
Côté serveur, les enveloppes (K_doc ↔ K_master) sont stockées dans un serveur HSM dédié (isolé VPC privé 10.0.2.0/24), conforme FIPS 140-2 Level 3 et PKCS#11.
La communication Backend ↔ HSM utilise mutual TLS (mTLS) avec validation de certificats X.509. Ce serveur HSM est physiquement séparé de l\'API Backend et du stockage S3 pour garantir une défense en profondeur.

+----------------------------------------------------------------------+ | En production, le HSM Cloud OVH est utilisé pour toutes les | | opérations cryptographiques sensibles : | | | | - Signature des enveloppes de clés | | | | - Génération de clés maîtres serveur (K_master) | | | | - Signature des journaux probatoires | | | | - Horodatage et ancrage blockchain | +======================================================================+

Les métadonnées PostgreSQL référencent uniquement les identifiants des enveloppes

stockées dans le HSM, jamais les clés en clair.

Les journaux cryptographiques contiennent uniquement des hashes SHA3-256 et des identifiants anonymes,
jamais de clé brute ni de texte déchiffré.

+----------------------------------------------------------------------+ | ⚠️ Attention --- bonnes pratiques d'implémentation : | | | | Toutes les opérations cryptographiques doivent être centralisées | | dans un module dédié (crypto.service.ts) afin : | | | | - de garantir la cohérence des primitives (même algo, même IV | | policy), | | | | - de simplifier les tests unitaires, | | | | - et d'éviter toute fuite accidentelle de données en clair. | | | | Les fonctions doivent être pures et idempotentes, sans effets de | | bord (pas de logs, pas d'accès réseau). | +======================================================================+

Explication : Le rôle de la clé d'accès¶

La clé d'accès (enveloppe cryptographique) est la couche intermédiaire entre le document et le serveur :

Document.enc -- chiffré avec --> K_doc

K_doc -- chiffré avec --> K_master

Lors d'une rotation, le fichier WORM Document.enc reste inchangé, mais l'enveloppe est réencryptée avec la nouvelle clé maître.

Ainsi :

le document original reste scellé,
la sécurité des accès est modernisée,
et la traçabilité de chaque rotation est prouvable.

+----------------------------------------------------------------------+ | ⚖️ Ce mécanisme est pleinement conforme au modèle WORM : | | | | Aucune réécriture du fichier original, mais une rotation des clés | | d'accès qui garantit la pérennité cryptographique sans altérer la | | preuve. | +======================================================================+

💡 Recommandations complémentaires¶

Utiliser SHA3-256 pour toute empreinte probatoire (hash de fichiers, journaux, blockchain).
Effectuer une rotation annuelle des clés maîtres serveur, avec archivage signé des anciennes versions.
Interdire tout log, export ou exception contenant du texte déchiffré.
Effectuer une revue cryptographique annuelle (analyse d'entropie, audit interne ou ANSSI/CNIL).
Tester régulièrement la restauration multi-versions (K_master v1 → v2 → v3)

💬 En résumé :¶

Ce modèle garantit que :

aucune compromission d'une clé unique (ni utilisateur, ni document, ni serveur)\ ne permette de déchiffrer plus qu'un seul objet ;
la rotation des clés se fait sans altérer les fichiers WORM,\ grâce à la réencapsulation des enveloppes cryptographiques ;
et la continuité probatoire est assurée, même sur plusieurs décennies,\ tout en restant conforme aux normes NF Z42-013 et ISO 14641.

🔄 Transfert et héritage cryptographique¶

Le mécanisme de transfert et d'héritage cryptographique est conçu pour les cas où un document ou un ensemble d'archives chiffrées doivent être transmis définitivement à un nouveau propriétaire --- par exemple, lors d'une cession de véhicule, d'une succession numérique ou d'un transfert de dossier entre entités.

Ce processus permet de transférer la propriété sans jamais modifier les objets WORM d'origine,\ tout en garantissant la continuité probatoire (hash, horodatage, ancrage blockchain)\ et la confidentialité intégrale des données.

⚙️ Principe général¶

Lors d'un transfert :

Les documents existants restent figés dans le stockage WORM.
Le système re-chiffre localement leur contenu avec une nouvelle clé de chiffrement, propre au nouveau propriétaire.
De nouveaux objets WORM sont créés, chacun lié cryptographiquement à la version précédente.
La relation de provenance entre les deux versions est inscrite et ancrée sur la blockchain.
Les anciennes clés d'accès et enveloppes sont révoquées.

Cette approche assure une rupture cryptographique totale entre l'ancien et le nouveau détenteur, tout en maintenant une chaîne de preuve juridiquement inattaquable.

🔐 Détails cryptographiques¶

Élément Version d'origine Nouvelle version (post-transfert)

Clé document K_doc K_doc\'

Clé K_encryption_Origin K_encryption_NewOwner utilisateur

Clé maître K_master(vX) K_master(vX+1) (rotation serveur annuelle)

Contenu Document_v1.enc = Document_v2.enc = chiffré Enc(fichier, K_doc) Enc(fichier, K_doc\')

Empreinte hash_v1 = hash_v2 = blockchain SHA3-256(Document_v1.enc) SHA3-256(Document_v2.enc)

Preuve de lien --- `hash_provenance = SHA3-256(hash_v1

Transaction tx_01 : anchor(hash_v1) tx_02 : blockchain anchor(hash_provenance)

Chaque version est indépendante, immuable et vérifiable.\ La chaîne hash_v1 → hash_v2 → ... constitue la preuve d'héritage cryptographique.

🧩 Étapes du processus¶

Préparation du transfert
- Le propriétaire actuel sélectionne les objets à céder (ex. dossier véhicule).
- Le nouveau propriétaire crée son compte et sa paire de clés (PubKey_New, PrivKey_New).
- Un "espace de cession" temporaire est ouvert avec accès en lecture seule.
Re-chiffrement local
- Chaque fichier est déchiffré localement avec K_doc.
- Le contenu est immédiatement re-chiffré avec une nouvelle clé K_doc\'.
- Une nouvelle empreinte SHA3-256 est calculée.
Création du nouvel objet WORM
- Le fichier Document_v2.enc est uploadé sur OVH Object Storage avec un nouvel Object Lock COMPLIANCE.
- La base de données consigne le lien de provenance (hash_v1 → hash_v2).
Ancrage blockchain
- hash_provenance est inscrit sur la blockchain via transaction certifiée.
- Le tx_id est stocké dans la table d'audit append-only.
Révocation et clôture
- Les anciennes enveloppes d'accès sont supprimées.
- Les nouvelles clés (K_doc\', K_encryption_NewOwner) deviennent la référence.
- Un acte de transfert signé et horodaté (PDF) est joint au dossier.

🧾 Journalisation probatoire¶

Chaque transfert est enregistré dans le journal d'audit sécurisé :

Champ Description

doc_id Identifiant unique du document transféré

previous_hash Empreinte SHA3-256 de la version d'origine

new_hash Empreinte SHA3-256 de la version transférée

hash_provenance Chaînage cryptographique (SHA3-256(previous + new))

origin_owner / new_owner Identifiants chiffrés des parties

blockchain_tx Transaction d'ancrage

timestamp Horodatage certifié

signature_server Signature numérique du backend (append-only)

Ce registre permet de reconstruire la lignée complète d'un document,\ depuis sa création jusqu'à ses transmissions successives.

⚖️ Compatibilité avec le modèle WORM¶

Le transfert respecte intégralement les contraintes du modèle Write Once, Read Many :

Les fichiers originaux restent figés dans le stockage.
Les nouvelles versions sont créées avec un nouvel identifiant immuable.
Le lien entre les deux est purement cryptographique et probatoire.
Aucune réécriture ni suppression n'intervient sur les objets WORM existants.

On ne modifie jamais un document d'origine :\ on crée une nouvelle preuve scellée, liée à la précédente.

💬 Illustration simplifiée¶

Version 1 (propriétaire initial) Version 2 (nouveau propriétaire)

──────────────────────────────┐ ┌──────────────────────────────

Document_v1.enc (WORM) │ │ Document_v2.enc (WORM)

hash_v1 = SHA3-256(content_v1) │ │ hash_v2 = SHA3-256(content_v2)

│ │

Blockchain tx_01 = │ │ Blockchain tx_02 =

anchor(h1) │ │ anchor(SHA3-256(h1+h2))

│────────►│

Chaînage : h1 → h2 → h3 ... │ │

──────────────────────────────┘ └──────────────────────────────

✅ Bénéfices¶

Critère Détail

Confidentialité Le nouveau propriétaire reçoit des clés totalement absolue distinctes (K_doc\', K_encryption_New).

Séparation Les versions appartiennent à des identités juridique forte cryptographiques différentes.

Force probatoire Chaque transfert génère un nouvel ancrage chaîné sur élevée la blockchain.

Conformité WORM Aucune réécriture ni altération de l'objet original.

Auditabilité Journal append-only complet avec liens blockchain.

Pérennité Re-chiffrement possible à chaque changement technique d'algorithme ou de propriétaire

💡 Bonnes pratiques¶

Utiliser AES-256-GCM ou ChaCha20-Poly1305 pour les opérations de re-chiffrement.
Calculer toutes les empreintes avec SHA3-256 ou SHA-3-512.
Ancrer systématiquement la preuve de lien (hash_provenance) plutôt que le hash brut.
Archiver les anciennes clés maîtres (K_master(vX)) dans le Cold Archive OVH en lecture seule.
Purger les enveloppes d'accès obsolètes après validation blockchain.
Tester régulièrement la restauration multi-version pour garantir la continuité probatoire.

+----------------------------------------------------------------------+ | 💬 En résumé : | | | | Le mécanisme de transfert et d'héritage de ProbatioVault crée une | | nouvelle version chiffrée et ancrée du document, sans jamais altérer | | l'original. | | Il garantit une continuité juridique et cryptographique | | parfaite, assurant que chaque propriétaire successif dispose | | d'une preuve de possession autonome, tout en préservant | | la lignée probatoire complète du document. | +======================================================================+

Partage temporaire et révocation « zéro-confiance »¶

Le mécanisme de partage « zéro-confiance » permet à un utilisateur d'accorder un accès temporaire à un tiers (par exemple, un avocat) sans jamais lui transmettre de clé durable.\ Cette approche repose sur le principe de Proxy Re-Encryption (PRE) : le serveur agit comme un proxy aveugle capable de re-chiffrer un document pour un autre destinataire, sans jamais accéder aux clés en clair.

Le HSM n'exécute pas le re-chiffrement : il signe et autorise l'opération via un jeton d'autorisation (auth_token) vérifié par le proxy PRE (Umbral). Le proxy reste stateless ; aucune clé (K_doc, K_share, rk) n'est visible hors du terminal.

⚙️ Principe général¶

Lorsqu'un utilisateur (propriétaire O) souhaite partager un document avec un destinataire R :

Le client O récupère la clé publique de chiffrement de R (PK_enc(R)), certifiée par sa clé d'identité (PK_id(R)).
O génère localement une clé de re-chiffrement rk(O→R) dérivée de sa propre clé privée SK_enc(O) et de PK_enc(R), assortie d'une politique d'accès (scope, durée, droits).
Cette clé de re-chiffrement est transmise au proxy sécurisé (hébergé sur OVH) qui peut, sur demande authentifiée, transformer une enveloppe de clé destinée à O en une enveloppe utilisable par R, sans jamais connaître la clé réelle du document.
R décrypte localement le flux obtenu à l'aide de sa clé privée SK_enc(R) et visualise le document chiffré.\ Aucun secret n'est jamais exposé au serveur ou au proxy.

🔐 Révocation et rotation¶

Le propriétaire peut à tout moment révoquer l'accès en supprimant la clé rk(O→R) du proxy ou en effectuant une rotation d'époque cryptographique (K_epoch → K_epoch\').

Une fois la révocation effective :

toute nouvelle tentative d'accès échoue (ACCESS_REVOKED),
le destinataire ne dispose d'aucune clé locale exploitable,
la traçabilité de la révocation est inscrite dans le journal probatoire (audit append-only).

⚠️ Si le tiers a exporté le contenu en clair durant la période d'accès, la révocation ne peut pas annuler cette copie.\ Le mode « visualisation seule » (stream chiffré, watermark dynamique) est donc activé par défaut pour les partages sensibles.

🧩 Structure cryptographique¶

Niveau Élément Rôle Stockage

1️⃣ K_encryption Clé maître utilisateur dérivée Client (seulement en (Argon2id + HKDF) mémoire)

2️⃣ K_doc Clé unique par document Enveloppe chiffrée en (AES-256-GCM) base

3️⃣ rk(O→R) Clé de re-chiffrement proxy Proxy OVH (vault (scope + TTL) secure)

4️⃣ K_epoch Clé d'époque pour rotation Serveur (métadonnées automatique neutres)

Toutes les transformations s'effectuent sur des chiffrés ; aucun composant serveur n'a accès aux clés brutes.\ Le modèle est zéro-connaissance et zéro-persistance : rien n'est stocké hors des terminaux autorisés.

🧾 Journalisation probatoire¶

Chaque création, accès ou révocation de partage génère une entrée signée dans access_audit :

Champ Description

policy_id Identifiant de la délégation

actor_user_id Émetteur ou destinataire

action CREATE / ACCESS / REVOKE

doc_id Document concerné

timestamp Horodatage certifié (RFC 3161)

signature_proxy Signature Ed25519 du proxy

Le haché global de ce journal est ancré périodiquement sur blockchain publique, garantissant la preuve d'intégrité temporelle de tous les partages et révocations.

⚖️ Compatibilité WORM et conformité¶

Le partage « zéro-confiance » respecte pleinement le modèle WORM :

aucun objet chiffré n'est réécrit ; seules les enveloppes de clés évoluent,
la révocation ne modifie pas les fichiers WORM existants,
les journaux probatoires assurent la continuité de preuve entre états successifs.

Ce modèle répond aux exigences de NF Z42-013, ISO 14641, et du RGPD (droit de limitation et retrait du consentement d'accès).

+----------------------------------------------------------------------+ | 💡 Bonnes pratiques : | | | | - Limiter la durée d'un partage à 7 jours par défaut (renouvelable). | | | | - Utiliser un affichage « view-only » : stream AES-GCM avec | | watermark dynamique. | | | | - Activer la rotation automatique des K_epoch toutes les 24 h pour | | les espaces multi-partagés. | | | | - Signer électroniquement les invitations de partage (double | | consentement : propriétaire + destinataire). | | | | - Ancrer le hash des politiques de partage (policy_hash = | | SHA3-256(scope + TTL + rights)) dans le journal d'audit. | +======================================================================+

💬 En résumé¶

Le partage temporaire « zéro-confiance » de ProbatioVault permet une collaboration contrôlée, traçable et révocable :\ le tiers accède au contenu sans jamais détenir la clé, le serveur ne voit ni données ni secrets, et chaque action reste vérifiable et probatoire dans le temps.

💼 Cas RH : transfert probatoire, fusion logique et contrôle d'intégrité¶

Les mécanismes précédents (transfert et partage « zéro-confiance ») définissent la base cryptographique de ProbatioVault : chaque document reste chiffré de bout en bout, chaque accès est traçable, et chaque preuve est ancrée de manière immuable.\ Le présent chapitre illustre leur mise en œuvre concrète dans un contexte métier sensible : la gestion RH et la distribution des bulletins de paie.\ Ce cas d'usage démontre comment ProbatioVault garantit simultanément :

la confidentialité intégrale des données salariales ;
la preuve de remise légale et la traçabilité probatoire sur plusieurs décennies ;
et la séparation stricte entre contenu et preuve, assurant la conformité RGPD et ISO 14641/NF Z42-013.

⚙️ Principe général¶

Dans le cadre d'une utilisation RH, l'entreprise doit remettre à chaque salarié des documents à valeur probatoire (bulletin de paie, contrat, attestation, relevé de droits...), tout en respectant :

la confidentialité absolue (aucun accès post-remise),
la preuve d'émission et d'intégrité sur la durée légale (jusqu'à 50 ans),
la non-conservation de données personnelles au-delà du nécessaire.

Le modèle zéro-confiance de ProbatioVault répond à cette exigence en séparant :

Élément Description Maîtrise

Document Fichier individuel chiffré côté Propriété du salarié (contenu client chiffré)

Preuve Hash SHA3-256 + ancrage Propriété de probatoire blockchain + acte de remise signé l'entreprise

Clés de K_docEntreprise (avant transfert) Rotation automatique, chiffrement → K_docSalarié (après transfert) sans exposition serveur

🔐 Déroulement du transfert probatoire¶

Dépôt initial par l'entreprise\ Le document est chiffré localement via K_docEntreprise (AES-256-GCM).\ Un hash hash_docEntreprise = SHA3-256(Document.enc) est calculé et ancré dans le journal probatoire.
Transfert vers le salarié\ Le proxy PRE (Proxy Re-Encryption) re-chiffre l'enveloppe de clé pour le salarié :\ K_docEntreprise → K_docSalarié.\ Aucune donnée n'est déchiffrée côté serveur.
Acte de remise probatoire\ Un document PDF signé (transfer_proof.pdf) est généré, incluant :
- l'identifiant du document,
- les identités cryptographiques des parties,
- le hash SHA3-256,
- la date/heure et la signature Ed25519.
Archivage probatoire\ L'entreprise conserve :
- le hash du document,
- l'acte signé,
- la transaction tx_id d'ancrage blockchain.\ Le fichier lui-même est supprimé ou rendu inaccessible (WORM expiré).
Réception par le salarié\ Le salarié déchiffre le document via K_docSalarié et l'ajoute à son coffre personnel.\ L'entreprise ne dispose plus d'aucune clé de lecture.

🧾 Journalisation probatoire¶

Chaque opération est inscrite dans le journal vault_secure.audit_log et ancrée périodiquement.\ Exemple de ligne d'audit :

Champ Valeur

action TRANSFER_DOCUENT

doc_id 8f62-ba13-...

hash_doc ae69c1...9b4a

from_user_id Entreprise

to_user_id Salarié

tx_id 0x47b9f4...

timestamp 2025-03-25T10:32:14Z

signature sig(Ed25519, K_master)

Ces journaux sont stockés en append-only, signés et horodatés (RFC 3161), puis exportés mensuellement vers AWS Glacier (WORM 50 ans).

⚖️ Gestion du contrôle et des contestations¶

En cas de contrôle URSSAF, d'audit externe ou de litige prud'homal :

L'entreprise ne demande pas aux salariés leurs documents.
Elle produit :
- le hash probatoire du document,
- la preuve de remise signée (transfer_proof.pdf),
- et, si applicable, l'ancrage blockchain du lot mensuel (MerkleRoot des fiches de paie).

Vérification d'intégrité

SHA3-256(document fourni) == hash_docEntreprise

➡️ Si égalité : le document n'a subi aucune altération depuis l'émission.\ ➡️ Sinon : le document présenté n'est pas celui officiellement remis.

Aucune clé privée ni copie lisible n'est requise : la preuve seule suffit.

🧮 Structure probatoire conservée par l'entreprise¶

Élément Type Détenteur Durée de conservation

hash_docEntreprise SHA3-256 Entreprise 50 ans (empreinte)

transfer_proof.pdf Acte signé Entreprise & 50 ans salarié

tx_id Transaction Publique Illimitée blockchain

journal_probatoire Append-only signé Entreprise 50 ans

document.enc Fichier chiffré Salarié Durée contractuelle ou à vie

💡 Bonnes pratiques RH¶

Utiliser un transfert probatoire définitif pour chaque remise individuelle.
Grouper les fiches mensuelles dans un lot horodaté (ancrage Merkle root).
Supprimer les clés de déchiffrement (K_docEntreprise) après chaque transfert validé.
Conserver uniquement le hash et la preuve signée.
Prévoir une rotation annuelle des clés maîtres et un audit externe de conformité (NF Z42-013 / ISO 14641).

💬 En résumé¶

Aspect Solution ProbatioVault

Confidentialité Le contenu n'est accessible qu'au salarié (zéro-clé côté entreprise).

Preuve légale Hash + signature + horodatage + ancrage blockchain.

Conformité RGPD L'entreprise ne conserve aucune donnée personnelle, seulement la preuve.

Durée légale Conservation WORM 50 ans (preuve d'émission, pas contenu).

Litige / contrôle Vérification d'intégrité via hash, sans lecture du fichier

+----------------------------------------------------------------------+ | 💡 En pratique : | | | | L'entreprise conserve la capacité de prouver qu'un document a | | été émis et qu'il n'a jamais été modifié, sans pour autant pouvoir | | le relire, garantissant ainsi à la fois la conformité juridique et | | la confidentialité des données personnelles. | +======================================================================+

🔗 Fusion logique entre coffre professionnel et personnel¶

⚙️ Objectif¶

Permettre à un salarié disposant d'un coffre personnel ProbatioVault de fusionner logiquement son espace personnel et son espace professionnel,\ de sorte qu'il puisse accéder à tous ses documents RH depuis un seul coffre,\ sans que l'entreprise ne connaisse jamais son adresse personnelle ni sa clé de chiffrement.

🧩 Principe de fonctionnement¶

Élément Description

Adresse Les bulletins de paie sont toujours envoyés par d'émission l'entreprise à l'adresse professionnelle (prenom.nom@entreprise.fr).

Coffre Héberge les documents RH chiffrés sous K_docEntreprise, entreprise sans connaissance de l'adresse personnelle du salarié.

Coffre Le salarié active, s'il le souhaite, une **fusion salarié logique avec son coffre personnel, sans communication (fusionné)** d'adresse privée à l'entreprise.

Proxy Relie les identités cryptographiques aveugle (PK_id_salarié_pro ↔ PK_id_salarié_perso) sans exposer les clés ni les adresses

🔐 Mécanisme de fusion logique¶

Lien cryptographique interne (link_id = Enc(PK_proxy, PK_id_pro + PK_id_perso)) créé après authentification eIDAS/FranceConnect+.
Re-chiffrement automatique des nouveaux bulletins du coffre pro vers le coffre personnel (K_docEntreprise → K_docSalarié) via le proxy PRE.
Accès unifié pour le salarié à tous ses documents, pro et personnels.
Persistance d'accès : la liaison link_id reste active même après désactivation de l'adresse professionnelle.

⚖️ Garanties de conformité¶

Exigence Réponse ProbatioVault

Confidentialité L'entreprise ne connaît pas l'adresse personnelle ni la clé du salarié.

Continuité Le salarié conserve la lecture après son départ. d'accès

Traçabilité Journalisation de chaque synchronisation (SYNC_DOC_PRO→PERSO).

Preuve d'émission L'entreprise conserve le hash et la signature probatoire.

RGPD Double consentement explicite ; pas de transfert de donnée personnelle

💡 Bonnes pratiques¶

Activer la fusion logique à la première connexion, avec consentement explicite.
Mentionner : "Vos bulletins sont émis à votre adresse professionnelle et synchronisés avec votre coffre personnel ProbatioVault."
Prévoir une option de désactivation temporaire en cas de contentieux.
Journaliser les synchronisations automatiques (sig_proxy, tx_id).

💬 En résumé¶

Acteur Données visibles Clés connues Accès

Entreprise Email pro, hash du K_docEntreprise Lecture jusqu'à document transfert

Proxy PRE link_id, métadonnées Aucune Re-chiffrement (aveugle) signées automatisé

Salarié Documents pro + K_docSalarié Lecture complète (fusionné) perso

ProbatioVault Aucune donnée en Zéro-clé Ne peut ni lire (hébergeur) clair ni exporter

+----------------------------------------------------------------------+ | 💬 En synthèse : | | | | Le salarié bénéficie d'un coffre unique et souverain, l'entreprise | | conserve la preuve légale d'émission et ProbatioVault assure la | | synchronisation cryptographique sans jamais connaître les adresses | | ni les clés. | +======================================================================+

👩‍💻 Cas mineurs : supervision parentale, transfert encadré et accès judiciaire¶

Ce cas d'usage décrit la manière dont ProbatioVault protège les mineurs dans le cadre de situations à dimension juridique ou probatoire :\ constitution de preuves numériques (harcèlement, cyberviolence, atteinte à la vie privée), dépôt de créations, gestion d'identité ou transfert de documents sensibles.

L'architecture permet au mineur de constituer et signer ses preuves sous sa propre identité numérique, tout en assurant :

la confidentialité intégrale des contenus ;
la possibilité d'un accompagnement parental ou éducatif sans perte de contrôle cryptographique ;
et, le cas échéant, un accès judiciaire strictement encadré et auditable.

L'objectif est de fournir un cadre technique et éthique de protection du mineur, conciliant autonomie, assistance et conformité légale, dans le respect du modèle zéro-connaissance.

⚙️ Contexte et objectifs¶

Ce cas d'usage illustre la capacité de ProbatioVault à protéger un mineur victime de harcèlement numérique, tout en respectant le cadre juridique du Code civil, du Code pénal et du RGPD.

L'objectif est triple :

garantir la confidentialité des preuves collectées (captures, messages, images) ;
permettre un transfert encadré vers les parents ou une autorité compétente, sans trahir le modèle zéro-confiance ;
assurer la traçabilité probatoire complète de chaque action (création, partage, transfert, réquisition).

🔐 Création et paternité probatoire du mineur¶

Lorsqu'un mineur crée un dossier probatoire :

chaque élément scellé est signé avec sa clé d'identité :\ sig_mineur = Sign(SK_id_mineur, hash_doc || timestamp) ;
le hash (hash_doc) et la signature sont ancrés sur blockchain ;
le coffre conserve localement un proof_record (empreinte, date, signature).

Même en cas de transfert ultérieur, le mineur garde la preuve qu'il est l'auteur du dépôt initial : il peut produire son proof_record et démontrer que tous les ajouts ultérieurs proviennent d'autres identités (sig_parent, sig_autorité, etc.).

🧩 Transfert encadré vers les parents¶

Si le dossier doit être remis au représentant légal (parents ou tuteurs) :

Le proxy PRE re-chiffre l'enveloppe de clé (K_doc_mineur → K_doc_parent) sans jamais voir le contenu.
Un acte de transfert bilatéral est généré et signé :
- sig_mineur : consentement du mineur ;
- sig_parent : réception ;
- sig_proxy : certification du service.
Le mineur conserve une trace inviolable du transfert : hash, identités des signataires, date, identifiant blockchain (tx_id).

Le parent devient alors propriétaire technique du dossier, mais le mineur garde la paternité probatoire de sa création.

+----------------------------------------------------------------------+ | 🧩 Proxy aveugle et enclave sécurisée : | | | | Le mécanisme de re-chiffrement (PRE) est opéré par un proxy | | cryptographique aveugle, hébergé dans une enclave sécurisée (HSM | | certifié SecNumCloud). | | Ce service ne dispose d'aucune clé de déchiffrement et ne | | manipule que des chiffrés et métadonnées signées. | | Son binaire est scellé et audité, garantissant qu'aucun employé, | | administrateur ou prestataire ne peut lire ni exporter le contenu | | des dossiers. | +======================================================================+

⚖️ Cas d'obstruction parentale et réquisition judiciaire¶

Si les parents refusent de coopérer (blocage d'accès ou dissimulation),\ ProbatioVault applique le mécanisme Legal PRE :

Étape Description Garanties

1️⃣ L'autorité compétente (parquet, DCPJ, Pharos) émet Authentification un mandat judiciaire signé juridique électroniquement (eIDAS qualifié).

2️⃣ Le proxy valide la requête et exécute Zéro-connaissance un re-chiffrement préservée éphémère rk(proxy→autorité) dans une enclave sécurisée (HSM certifié).

3️⃣ Le contenu re-chiffré est transmis à l'autorité, Traçabilité lecture seule. probatoire

4️⃣ L'opération est journalisée et ancrée (mandat, Vérifiabilité identités, horodatage, signatures). indépendante

Le Legal PRE n'est pas une "clé d'urgence" :\ aucune clé persistante n'existe, aucun employé ne peut déclencher le processus.\ Il s'agit d'une dérivation cryptographique temporaire, activée uniquement sous double signature :

celle du mandat judiciaire ;
celle du DPO ou représentant légal de ProbatioVault.

Une fois la session terminée, la clé disparaît (mémoire volatile), ne laissant qu'une trace signée dans le journal append-only.

🧠 Enjeux juridiques et conformité¶

Référence Application ProbatioVault

Code civil 371-1 L'autorité parentale s'exerce dans l'intérêt de / 388-1 l'enfant ; le mineur conserve un droit à l'information et au transfert encadré de ses données.

Code civil 375 et Fondent la possibilité d'un accès judiciaire direct suivants ou d'une limitation de l'autorité parentale en cas de danger ou d'obstruction.

Code pénal Les preuves de harcèlement sont recevables dès lors 222-33-2-2 que leur intégrité et leur horodatage sont garantis.

Code de procédure Permettent à l'autorité judiciaire de pénale 60-1 et réquisitionner les éléments probatoires numériques 77-1-1 sans consentement parental, sous mandat signé.

RGPD art. 8 et Consentement parental encadré ; droit du mineur à 12 l'information et à la transparence.

eIDAS 2.0 Signatures et horodatages qualifiés ; mandats électroniques vérifiables

📜 Registre d'accès probatoire¶

Le mineur peut consulter à tout moment la liste des détenteurs actifs ou passés de son dossier :

Identité Type d'accès Date **Expiration Statut Signature d'attribution**

PK_id_mineur Propriétaire 2025-03-21 2025-05-10 ⛔ Clos sig_mineur initial

PK_id_parent Transfert 2025-05-11 -- ✅ Actif sig_proxy complet

PK_id_autorité Réquisition 2025-07-10 2025-07-24 ✅ Terminé sig_autorité judiciaire

Ces informations proviennent du journal append-only, vérifiable hors-ligne.\ Aucune clé privée n'est exposée ; seules les identités publiques et signatures sont visibles.

💬 En résumé¶

Aspect Garantie ProbatioVault

Confidentialité Zéro-connaissance : aucune lecture côté serveur ni employé

Traçabilité Journal append-only + signatures + ancrage blockchain

Transparence Consultation du registre d'accès vérifiable mineur

Réquisition Activation temporaire Legal PRE sous double judiciaire signature

Valeur légale Intégrité, antériorité et origine prouvées (NF Z42-013, ISO 14641)

Ce modèle de traitement encadré positionne ProbatioVault comme un tiers technique de confiance, conforme aux référentiels CNIL et ANSSI (SecNumCloud, ISO 14641, NF Z42-013) pour la conservation probatoire et la protection des données à caractère personnel.

+----------------------------------------------------------------------+ | 💡 En synthèse : | | | | ProbatioVault permet à un mineur de constituer et prouver un dossier | | de harcèlement sans dépendre d'un tiers de confiance. | | En cas de transfert, il conserve la preuve de paternité ; | | en cas d'obstruction, les autorités peuvent accéder légalement via | | un processus audité et éphémère, garantissant à la fois | | la protection de la victime et la préservation du modèle | | zéro-confiance. | +======================================================================+

⚙️ Cas B2B2C : propriété partagée et factures à double détention¶

Ce cas d'usage illustre l'application du modèle probatoire partagé de ProbatioVault : un même document peut être détenu et prouvé simultanément par plusieurs acteurs indépendants, sans duplication ni perte de confidentialité.

L'objectif est de permettre la co-détention sécurisée d'un document unique (ex. facture d'entretien, certificat, rapport d'expertise) par le professionnel émetteur et le client destinataire, chacun disposant de sa propre clé d'accès chiffrée et de preuves probatoires équivalentes.

Exemple d'usage : garagistes / clients particuliers -- documents à valeur probatoire commune.

🧭 Contexte et enjeux¶

Ce cas illustre la capacité de ProbatioVault à gérer des documents à valeur probatoire partagée entre deux acteurs indépendants :\ le professionnel émetteur (ex. garagiste, réparateur, expert automobile) et le client destinataire (propriétaire du véhicule).

Une facture d'entretien automobile, par exemple, est un document à double légitimité :

le garagiste doit la conserver pour des raisons comptables et de garantie ;
le client doit pouvoir la présenter pour prouver la régularité de l'entretien, la garantie constructeur ou la traçabilité historique du véhicule.

ProbatioVault doit donc permettre une co-détention probatoire : un seul document scellé, deux détenteurs légitimes, sans duplication, sans brèche de confidentialité, et avec des preuves équivalentes.

🔐 Mécanisme de double propriété --- Shared Proof Envelope¶

Le système repose sur la création d'une enveloppe probatoire unique, chiffrée une seule fois, mais associée à deux clés de lecture indépendantes.

Émission par le professionnel\ Le garagiste chiffre la facture avec sa clé de document :\ Enc(K_docGarage, facture.pdf)\ → Génération de hash_doc + signature sig_garage + ancrage blockchain.
Délégation PRE double\ Le proxy PRE crée deux "wraps" :
- wrap_garage = Enc(PK_garage, K_docGarage)
- wrap_client = Enc(PK_client, K_docGarage)\ Ces deux enveloppes donnent un accès égal au même document chiffré, sans duplication de fichier.
Journalisation probatoire\ Un enregistrement unique décrit la co-propriété :

shared_ownership_record = {

doc_id,

hash_doc,

owners: [

{ id: PK_garage, role: \"emitter\" },

{ id: PK_client, role: \"recipient\" }

],

sig_garage,

sig_proxy,

ts_issued,

tx_id_blockchain

}

Accès symétrique\ Le garage et le client disposent chacun de leur propre "wrap", leur permettant de lire le document avec leur clé privée respective.\ La facture conserve un seul hash probatoire commun, garantissant son unicité et son intégrité.

📱 Livraison locale sans contact --- Tap-to-Claim NFC¶

Pour simplifier la remise du document au client, ProbatioVault introduit un protocole de transfert local inspiré d'AirDrop, fondé sur NFC (avec QR/BLE en secours).

🔸 Étape 1 --- Invitation du garage¶

Le garage émet un Jeton de Délégation Éphémère (claim_token) signé et chiffré, valable 2 minutes :

claim_token = {

doc_id,

scope: \"DELIVERY_ONLY\",

ttl: 120s,

nonce_g,

pk_proxy,

policy_hash,

sig_garage

}

Ce token est diffusé en NDEF (NFC) ou QR Code (fallback).

🔸 Étape 2 --- Réception côté client¶

Le client approche son téléphone (tap NFC ou scan QR).\ L'app ProbatioVault lit le claim_token, s'authentifie, et envoie sa clé publique PK_client au proxy.

🔸 Étape 3 --- Re-chiffrement PRE éphémère¶

Le proxy valide la signature et la fenêtre de validité, puis exécute :\ ReEncrypt(wrap_garage → wrap_client) dans une enclave sécurisée.\ Le document reste chiffré ; seule la clé de lecture est adaptée au client.

🔸 Étape 4 --- Journalisation¶

Chaque transfert est enregistré sous forme d'événement :\ DELIVER_IN_PERSON, contenant doc_id, holder=PK_client, ts, sig_proxy.\ Les deux coffres (garage et client) disposent alors de la même preuve probatoire, liée au même hash.

🔸 🔁 Fallbacks¶

QR dynamique : même jeton encodé avec TTL = 120 s.
BLE : appairage éphémère ECDH + SAS 4 chiffres pour validation mutuelle.

🧱 Sécurité et conformité¶

Risque Mesure

Vol du token Jeton signé, TTL court (2 min), usage unique, vérification de proximité (NFC/BLE).

Homme-du-milieu PRE en enclave + canal TLS + SAS de confirmation.

Fuite d'email Aucune donnée personnelle échangée (identités = clés personnel publiques).

Réutilisation Token marqué "consommé" après usage (one-time). frauduleuse

Non-répudiation DELIVER_IN_PERSON signé et ancré blockchain

⚖️ Références légales¶

Référence Application ProbatioVault

Code de commerce art. Obligation du professionnel de conserver ses L123-22 factures 10 ans.

Code civil art. 1366 La preuve électronique vaut original si intégrité et origine sont garanties.

Code de la consommation Le client doit recevoir une copie durable de art. L111-1 la facture.

RGPD art. 5 et 6 Données minimisées, finalité double (émission + remise)

💬 En résumé¶

Aspect Garage Client

Droit de lecture ✅ ✅

Droit d'écriture ✅ (émission) ❌

Droit de ❌ (WORM) ❌ suppression

Preuve ✅ (hash commun) ✅ (hash d'intégrité identique)

Données visibles Données facture + PK_client Données facture + PK_garage

Journalisation shared_ownership_record + DELIVER_IN_PERSON Même empreinte probatoire

+----------------------------------------------------------------------+ | 💡 En synthèse : | | | | ProbatioVault gère les documents à double propriété via | | une enveloppe probatoire unique, | | permettant au professionnel et au client de disposer d'un original | | commun, juridiquement opposable et techniquement inviolable. | | La remise instantanée Tap-to-Claim combine simplicité d'usage | | (NFC), confidentialité totale et traçabilité probatoire | | complète, | | faisant de ProbatioVault un registre de confiance | | universel entre acteurs professionnels et particuliers. | +======================================================================+

Gestion des métadonnées et ancrage périodique¶

Les métadonnées associées à chaque document ProbatioVault (titre, description, tags, annotations, etc.) sont modifiables par l'utilisateur sans altérer la preuve probatoire du fichier.\ Elles sont chiffrées applicativement (AES-256-GCM via K_doc) et stockées dans la colonne encrypted_metadata de la table vault_secure.documents.

Chaque modification génère un événement append-only inscrit dans un journal des métadonnées (metadata_log), contenant :

Champ Description

document_id Référence du document concerné

timestamp Horodatage certifié

author_id Identifiant utilisateur

changes Détail des champs modifiés (JSON chiffré)

previous_hash Hash du bloc précédent

current_hash Hash du bloc courant (SHA3-256)

Ce chaînage cryptographique interne constitue une mini-blockchain locale garantissant la non-altération du journal.

⏱ Ancrage périodique¶

À intervalles réguliers (quotidien ou hebdomadaire), un worker calcule le hash cumulatif du journal de chaque document (metadata_history_hash = SHA3-256(last_block_hash)).

Ce hash est ensuite :

enregistré dans la table vault_secure.documents,
inclus dans le lot d'ancrage blockchain périodique, au même titre que les hashes d'intégrité des fichiers.

Ce mécanisme assure une intégrité probatoire continue :

les documents eux-mêmes restent immuables (WORM),
les métadonnées peuvent évoluer librement,
l'ensemble des versions successives est tracable et vérifiable a posteriori.

🌐 Traçabilité et ancrage blockchain¶

Les opérations probatoires de ProbatioVault (création, transfert, révocation, rotation de clés, intégrité de journaux) font l'objet d'un ancrage périodique sur une blockchain publique à horodatage certifié.\ L'objectif n'est pas de stocker les documents eux-mêmes, mais de sceller cryptographiquement leurs empreintes (hashes) dans un registre distribué immuable, garantissant leur preuve d'antériorité et d'intégrité temporelle.

Choix du réseau¶

ProbatioVault adopte une approche multi-chaîne modulaire, privilégiant :

Ethereum (mainnet ou L2 Arbitrum/Optimism) pour la compatibilité et la pérennité publique (preuve universelle, gas modéré via batching) ;
Tezos pour les cas d'usage souverains européens (faible empreinte carbone, coûts stables, gouvernance on-chain) ;
et un registre interne append-only ("Proof Ledger") hébergé sur OVH, utilisé comme relais local avant agrégation publique.

Chaque cycle d'ancrage se déroule en deux temps :

Journal interne append-only (PostgreSQL + hash chaîné SHA3-256) mis à jour en continu.
Ancrage agrégé (Merkle Root batché) sur la blockchain sélectionnée, toutes les 24 h ou 7 j selon le plan utilisateur.

Stratégie de frais et de gouvernance¶

Les transactions d'ancrage sont groupées par lot de 1 000 -- 10 000 hashes, réduisant les coûts unitaires à \< 0,01 € par document.
Les frais (gas fees) sont prépayés par ProbatioVault via un compte d'émission contrôlé et audité, sans jamais exposer de clé privée de production.
Les hashes Merkle Roots et ID de transaction (tx_id) sont stockés dans la table anchorage_audit_log, signés par le backend (clé Ed25519) et inclus dans le rapport probatoire trimestriel.

Preuve d'ancrage agrégée¶

Chaque lot produit un Merkle Root unique (root_hash = MerkleTree(hash_1, ..., hash_n)) ancré sur la blockchain.\ La preuve d'appartenance d'un document donné est vérifiable à tout moment via un chemin de Merkle (Merkle Path)inclus dans le journal local.\ Cette méthode permet une preuve compacte, universellement vérifiable et économiquement soutenable, tout en maintenant une souveraineté totale sur le calcul et la confidentialité.

+----------------------------------------------------------------------+ | 💡 En pratique : | | | | Un utilisateur peut prouver la présence d'un document dans un | | ancrage public sans divulguer ni son contenu, ni les autres | | empreintes du lot. | +======================================================================+

⚖️ Conformité et bénéfices¶

Conforme aux exigences NF Z42-013 et ISO 14641 sur la traçabilité des métadonnées.
Permet la modifiabilité contrôlée sans perte de valeur juridique.
L'ancrage périodique du journal renforce la preuve d'intégrité temporelle.
Compatible avec le mode de transfert/héritage cryptographique (§ 4.3).

Infrastructure HSM Cloud OVH¶

L'infrastructure HSM constitue le cœur de la sécurité cryptographique de ProbatioVault.

Elle est hébergée sur un VPC privé (10.0.2.0/24), isolé du Backend et du stockage S3.

Caractéristiques

Certification : FIPS 140-2 Level 3, conforme PKCS#11 et eIDAS
Communication : mutual TLS (mTLS) avec certificats X.509
Fonctionnalités :
Signature des enveloppes de clés (`Master`, `Device`, `Recovery`)
Signature probatoire des journaux d'audit (`audit_signatures`)
Horodatage qualifié RFC 3161 (TSA)
Ancrage Merkle blockchain (Ethereum L2 / Tezos)
Sécurité :
Aucun accès Internet (air-gap logique)
Journalisation append-only signée par le HSM
Réplication chiffrée entre 3 nœuds (Roubaix, Gravelines, Strasbourg)

Base de données PostgreSQL¶

Schéma simplifié¶

CREATE SCHEMA vault_secure;

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  password_hash TEXT NOT NULL,
  plan TEXT,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE vault_secure.documents (
  id UUID PRIMARY KEY,
  user_id INT REFERENCES users(id),
  encrypted_metadata BYTEA NOT NULL,
  keyword_deterministic BYTEA[],
  file_hash CHAR(64) NOT NULL,
  ovh_path TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

🔒 Sécurité et gouvernance des données¶

La base PostgreSQL utilisée par ProbatioVault est le point de confiance central du système :\ elle contient les métadonnées chiffrées, les enveloppes de clés et les journaux d'audit probatoires.\ Son architecture de sécurité repose sur quatre couches complémentaires :

🔐 Isolation logique stricte (Row-Level Security)¶

La Row-Level Security (RLS) est activée sur toutes les tables du schéma vault_secure.\ Chaque requête est automatiquement filtrée par PostgreSQL selon l'identité de l'utilisateur authentifié.

Exemple :

ALTER TABLE vault_secure.documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY user_isolation ON vault_secure.documents

USING (user_id = current_setting(\'app.current_user_id\')::INT);

Ainsi :

un utilisateur ne peut accéder qu'à ses propres documents,
les administrateurs techniques n'ont aucun accès direct au contenu des lignes,
et le RLS fonctionne même en cas de faille applicative (protection côté SGBD, pas côté API seulement).

💡 Cette approche garantit une séparation cryptographique ET logique des espaces utilisateurs.

🧱 Cloisonnement du schéma vault_secure¶

Le schéma vault_secure est isolé du schéma public :

Aucun objet n'est exposé dans public.
Les rôles applicatifs n'ont pas les privilèges CREATE ou ALTER.
Les requêtes d'accès passent exclusivement par des vues et fonctions contrôlées.

Exemple :

REVOKE ALL ON SCHEMA public FROM PUBLIC;

GRANT USAGE ON SCHEMA vault_secure TO app_backend;

REVOKE CREATE ON SCHEMA vault_secure FROM app_backend;

Ce cloisonnement empêche :

la création de tables ou vues non auditées,
les requêtes directes via des outils d'administration,
et toute injection SQL visant des métadonnées confidentielles.

📜 Journalisation probatoire (append-only)¶

Tous les événements critiques (création, lecture, suppression, rotation de clé, export)\ sont enregistrés dans une table d'audit append-only, immuable par conception.

Exemple :

CREATE TABLE audit_log (

id BIGSERIAL PRIMARY KEY,

user_id INT,

action TEXT,

target UUID,

timestamp TIMESTAMPTZ DEFAULT NOW(),

hash CHAR(64) NOT NULL,

signature BYTEA NOT NULL

);

Caractéristiques :

aucune opération UPDATE ni DELETE n'est autorisée,
chaque ligne est signée numériquement (hash SHA3-256 + signature serveur),
l'ordre temporel est certifié via une horloge NTP sécurisée,
et des hashs chaînés (chaîne de blocs internes) garantissent la non-altération :

hash = SHA3-256(prev_hash || new_entry_data)

Ce journal sert de preuve légale d'intégrité en cas d'audit judiciaire ou de contentieux.

⚖️ Conforme aux exigences NF Z42-013 et ISO 14641 sur la traçabilité probatoire.

🧰 Accès et authentification¶

Composant Type d'accès Mode **Notes d'authentification**

API NestJS Lecture/écriture JWT + rôle PostgreSQL Accès via pool applicatif sécurisé (app_backend)

Jobs BullMQ Lecture seule sur Token Droits limités métadonnées, spécifique app_worker écriture sur audit

Ops (DBA) Supervision Bastion SSH + MFA Accès restreinte journalisé

Analytique Lecture différée Vue matérialisée hors Données non (optionnel) anonymisée RLS sensibles uniquement

Aucun accès root direct à vault_secure n'est autorisé.\ Toutes les connexions passent par un proxy d'authentification avec rotation de certificats TLS et jetons courts.

💾 Chiffrement et durcissement¶

TDE (Transparent Data Encryption) activé pour le cluster PostgreSQL OVH.
TLS 1.3 pour toutes les connexions (API ↔ DB).
Séparation physique entre serveurs applicatifs et base.
Journal WAL chiffré avant toute réplication.
Rotation automatique des credentials (Vault → PostgreSQL).

Les sauvegardes automatiques (snapshots) sont :

chiffrées via le même jeu de clés TDE,
stockées sur OVH Object Storage avec Object Lock activé,
vérifiées mensuellement via un test de restauration automatisé.

🧩 Surveillance et alertes¶

Requêtes suspectes (ex : scans séquentiels anormaux) détectées via pgAudit + Prometheus.
Alertes automatiques en cas d'échec d'authentification répété.
Comptes inactifs suspendus après 90 jours.
Vérification quotidienne du hash du schéma (pg_dump --schema-only | SHA3-256sum) pour détecter toute altération non prévue.

🧭 Résumé des garanties¶

Garantie Mécanisme Objectif

Isolation des RLS + séparation schéma Confidentialité utilisateurs horizontale

Non-altération des Table append-only signée Intégrité probatoire journaux

Chiffrement au repos TDE PostgreSQL + Object Confidentialité Lock structurelle

Accès contrôlé Rôles restreints + MFA Sécurité opérationnelle

Auditabilité Logs signés + chaînage Conformité NF complète Z42-013

💬 En résumé :¶

La base PostgreSQL n'est pas un simple stockage relationnel, c'est une composante probatoire à part entière.\ Chaque opération est journalisée, signée et traçable, garantissant une intégrité totale des métadonnées et des clés d'accès sur toute la durée de vie du coffre-fort numérique.

Stockage et cycle de vie¶

Le stockage ProbatioVault repose sur un modèle hiérarchisé et redondant, garantissant à la fois la disponibilité immédiate, la conservation probatoire à long terme et la résilience multi-cloud. Chaque document suit un cycle de vie automatisé dès son dépôt, orchestré via des politiques de rétention et de réplication définies dans Terraform.

Upload chiffré depuis le client¶

Le fichier est chiffré localement (AES-256-GCM) avec une clé dérivée du secret utilisateur (HKDF + Argon2).
Le transfert s'effectue en HTTPS/TLS 1.3 vers le backend ProbatioVault, sans jamais exposer de donnée en clair côté serveur.
Seuls les blocs chiffrés et les métadonnées scellées sont stockés côté serveur.

Sauvegarde primaire --- OVH Object Storage (WORM)¶

Premier niveau de stockage actif, localisé dans le datacenter principal (ex. OVH Gravelines).
Activation du mode WORM (Write-Once-Read-Many) : toute écriture est définitive, aucune suppression ni modification possible avant l'expiration du délai légal.
Ce niveau assure la lecture rapide et la preuve d'intégrité cryptographique (hash SHA3-256 + ancrage blockchain périodique).

Export asynchrone --- AWS Glacier (Paris)¶

Un processus asynchrone (Lambda / SQS) exporte périodiquement les objets vers AWS Glacier Instant Retrieval (région Paris).
Objectif : garantir une seconde copie immuable hébergée sur un autre fournisseur cloud.
Les métadonnées de synchronisation (ARN, timestamp, checksum) sont journalisées dans la table vault_secure.documents_backup.

Réplication inter-région --- AWS Glacier (Francfort)¶

Une règle de Cross-Region Replication (CRR) assure la redondance hors territoire français.
Cette copie sert de plan de continuité (PRA) et permet la restauration en cas de sinistre majeur affectant la région primaire.
Les accès restent bloqués au compte ProbatioVault via un bucket policy verrouillé (pas de lecture directe par les clients).

Archivage froid optionnel --- OVH Cold Archive¶

Pour les documents à durée de conservation exceptionnelle (brevets, droits d'auteur, archives notariales...), une exportation additionnelle vers OVH Cold Archive est disponible.
Ce niveau utilise un stockage sur bandes magnétiques à très longue durée de vie, destiné à la préservation séculaire (> 100 ans).
L'accès nécessite une restauration manuelle avec un délai de 12 à 24 heures.

Purge automatique à échéance légale¶

Les durées de conservation sont définies dans la table de configuration retention_policies.
Un job planifié (Terraform + Lambda scheduler) exécute les suppressions logiques et physiques selon la réglementation applicable (RGPD, Code du commerce, Code du travail).
Les purges sont tracées et inscrites dans le journal probatoire d'audit.

Type de *OVH *AWS Paris *AWS *Cold **Durée totale document actif** (Glacier)** Francfort Archive de (CRR)** (OVH)** conservation**

Paie 10 ans 50 ans 50 ans -- 50 ans

Factures 3 ans 10 ans 10 ans -- 10 ans

Identité 2 ans 10 ans 10 ans -- 10 ans

Brevets / IP 20 ans 50 ans 50 ans 100 ans 100 ans

+----------------------------------------------------------------------+ | 💡 Conseil : | | | | Centraliser la gestion des Lifecycle Policies (OVH + AWS) dans les | | manifestes Terraform : | | | | - automatisation complète des transitions de stockage (actif → | | Glacier → Cold Archive), | | | | - suppression automatique à échéance, | | | | - traçabilité et conformité probatoire renforcées. | +======================================================================+

Confidentialité et recherche¶

ProbatioVault repose sur une approche « zéro confiance » : aucune donnée exploitable n'est jamais visible côté serveur, et toute opération de recherche respecte la confidentialité totale des contenus.\ Trois niveaux sont définis selon le contexte d'usage et le périmètre fonctionnel, avec montée en gamme progressive.

Niveau 1 --- Recherche locale (par défaut)¶

Les métadonnées et index sont stockés et chiffrés localement sur le terminal de l'utilisateur.
Les recherches s'effectuent en mémoire sur des données décryptées à la volée, via SQLite (mobile) ou IndexedDB (PWA).
Aucun transfert de données sensibles ni de clés de chiffrement n'a lieu vers le backend.
Ce mode garantit une confidentialité absolue, parfaitement adaptée aux utilisateurs individuels et aux petits comptes B2C.

Niveau 2 --- Recherche neutre (B2B)¶

Permet un index mutualisé minimal entre les membres d'une même organisation, sans contenu textuel.
Les champs indexés sont strictement non sensibles : type de document, taille, date, propriétaire, statut, empreinte de fichier.
L'index reste pseudonymisé ; les filtres et tris sont possibles sans lecture du contenu ni des métadonnées chiffrées.
Les résultats sont réconciliés localement par le client après déchiffrement des métadonnées.
Ce mode offre un bon compromis entre confidentialité et collaboration dans un cadre professionnel (TPE, PME, études, etc.).

Niveau 3 --- (Prévu) Recherche fédérée entreprise¶

Fonctionnalité en conception pour les futurs déploiements "Enterprise / Privé".
Objectif : permettre une recherche globale sur métadonnées chiffrées entre espaces de travail, via un index pseudonymisé et des tokens de recherche.
Le moteur resterait hébergé par ProbatioVault, mais isolé dans un espace de calcul dédié (VPC client).
Les clés de déchiffrement resteraient sous contrôle exclusif du client, conformément au modèle "zéro confiance étendu".
Ce niveau n'est pas activé dans la version 1.0 ; il ne modifie pas le modèle d'hébergement SaaS actuel et sera introduit ultérieurement sous forme d'option premium.

+----------------------------------------------------------------------+ | ⚙️ Recommandation technique : | | | | Au-delà de 10 000 fichiers dans l'espace local, activer : | | | | - la compression LZ4 pour limiter la taille des index, | | | | - la pagination locale pour maintenir un temps de réponse | | inférieur à 150 ms, | | | | - et la purge incrémentale des index inactifs pour réduire | | l'empreinte mémoire. | +======================================================================+

Redondance probatoire (AWS + OVH)¶

La redondance probatoire constitue un pilier fondamental du modèle ProbatioVault : elle garantit la pérennité, la traçabilité et la valeur juridique des documents archivés, indépendamment de toute défaillance technique, fournisseur ou juridiction.\ Cette approche s'appuie sur une architecture multi-niveaux de conservation, répartie entre OVHcloud (France) et AWS (UE), avec ancrage cryptographique périodique et supervision automatisée.

Architecture multi-niveaux¶

Chaque niveau de redondance répond à un objectif précis (résilience, durée, exigence probatoire).\ Les durées de rétention, classes de stockage et politiques de réplication sont orchestrées via Terraform et AWS CLI, avec suivi dans le journal probatoire d'audit.

Niveau Objectif Redondance Usage typique

1 Résilience AWS Glacier Paris Sauvegarde des coffres standard (multi-AZ) utilisateurs, cycle de vie \< 10 ans

2 Haute résilience Glacier Paris + CRR Archives légales, données RH, Francfort contrats à long terme

3 Ultra-résilience Glacier Francfort Données probatoires à très probatoire (CRR) + OVH Cold longue durée (> 50 ans), Archive brevets, documents notariés

Principe de fonctionnement :

Les objets chiffrés sont d'abord stockés dans OVH Object Storage (WORM).
Une sauvegarde asynchrone est ensuite effectuée vers AWS Glacier (Paris).
Les données critiques (niveaux 2 et 3) sont répliquées inter-région vers AWS Francfort (CRR), garantissant leur survie même en cas de sinistre majeur sur le territoire français.
Pour les durées de conservation supérieures à 50 ans, une troisième copie sur bande (OVH Cold Archive) est créée, assurant une résilience temporelle et géographique maximale.

Exemple CRR (AWS CLI)¶

Exemple de configuration de Cross-Region Replication (CRR) entre Paris (région eu-west-3) et Francfort (eu-central-1), avec stockage en classe DEEP_ARCHIVE :

aws s3api put-bucket-replication --bucket probatiovault-archives \

--replication-configuration \'{

\"Role\": \"arn:aws:iam::123456789012:role/s3-replication-role\",

\"Rules\": [{

\"Status\": \"Enabled\",

\"Priority\": 1,

\"DeleteMarkerReplication\": { \"Status\": \"Disabled\" },

\"Filter\": {},

\"Destination\": {

\"Bucket\": \"arn:aws:s3:::probatiovault-backup-eucentral1\",

\"StorageClass\": \"DEEP_ARCHIVE\"

}

}]

}\'

+----------------------------------------------------------------------+ | 🔒 Bonnes pratiques : | | | | - Activer Object Lock en mode COMPLIANCE dans les deux régions : | | empêche toute suppression anticipée. | | | | - Conserver un journal des ARN, versions et hash SHA3-256 de | | chaque objet répliqué (vérifiable via s3api head-object). | | | | - Surveiller la réplication via CloudWatch Metrics (latence, | | backlog, statut des objets) et Prometheus pour la supervision | | multi-cloud. | | | | - Tester périodiquement la restauration depuis chaque site de | | réplication pour garantir la validité des chaînes de confiance. | | | | - Ancrer périodiquement le hash global de l'état de réplication | | (Merkle Root) dans la blockchain probatoire publique. | +======================================================================+

Gouvernance et audit probatoire¶

Chaque action de réplication, suppression, ou restauration est journalisée dans la table replication_audit_log(horodatage, compte, ARN, hash, signature).
Les journaux sont signés numériquement et stockés à part dans OVH Object Storage (WORM) pour garantir leur valeur probatoire.
Un rapport de conformité trimestriel (JSON + PDF) peut être généré automatiquement à destination du DPO ou de l'auditeur externe.

+----------------------------------------------------------------------+ | 💡 Conseil d'implémentation : | | | | Centraliser la configuration multi-niveaux dans un | | module Terraform probatiovault_replication.tf, incluant : | | | | - les policies s3:ObjectLock, | | | | - les règles Lifecycle (transition → Glacier → Cold Archive), | | | | - et les EventBridge Rules pour la supervision automatisée. | +======================================================================+

Sécurité et conformité¶

La sécurité est au cœur de la conception ProbatioVault.\ Le système repose sur un modèle de confiance nulle (Zero-Trust), un chiffrement de bout en bout et une conformité active vis-à-vis des référentiels européens de protection des données et de conservation probatoire.

Les mesures se répartissent en cinq piliers : authentification, chiffrement, intégrité, supervision et conformité.

Authentification et contrôle d'accès¶

ProbatioVault utilise Keycloak 24.x comme Identity Provider (OIDC) et PKI interne. Keycloak gère l'émission et la révocation des certificats X.509 utilisés pour la signature probatoire. Les clés privées associées sont stockées dans le HSM Cloud OVH via un connecteur PKCS#11. Les fédérations d'identité (Google, Apple, Microsoft, FranceConnect+) convergent vers ce realm unique.

Le système d'authentification de ProbatioVault repose sur un modèle fédéré, multi-facteur et probatoire, combinant :

des fournisseurs d'identité externes (OAuth2 / OIDC) ;
un fournisseur interne sécurisé pour les comptes natifs ;
et un contrôle d'accès hiérarchisé et journalisé.

Cette approche garantit une expérience fluide pour les utilisateurs grand public, tout en assurant aux clients B2B et institutionnels un niveau d'identité légalement vérifiable conforme aux exigences eIDAS et NF Z42-013.

Fournisseurs d'identité (OAuth2 / OIDC)¶

ProbatioVault prend en charge plusieurs modes d'authentification fédérée :

Type Fournisseur Niveau de **Usage principal garantie**

OAuth2 Apple ID, Google Bas à moyen Connexion rapide (B2C, social Sign-In, Facebook mobile, PWA) Login

OIDC France Identité, Élevé (identité Archivage légal, étatique FranceConnect + légale signature probatoire certifiée)

SSO Microsoft Entra ID, Élevé Offres B2B / entreprise Okta, Auth0 Enterprise administrations

Compte Email + mot de passe Moyen Utilisateurs natif (ProbatioVault) souhaitant un compte souverain

Toutes les authentifications convergent vers un Identity Provider interne (IdP) exposant une API OpenID Connect unifiée.\ Celui-ci délivre un JWT signé reconnu par les autres services (API NestJS, PostgreSQL, workers BullMQ).

Chaque identité est matérialisée dans la table users_identity :

Champ Description

user_id Identifiant maître interne ProbatioVault

auth_provider Source d'identité (apple, google, facebook, france_identite, email, microsoft)

auth_sub Identifiant externe (claim OIDC sub)

email_verified Statut de validation du mail

identity_level Niveau : basic, verified, qualified

last_login_at Horodatage probatoire de la dernière connexion

Ces informations sont auditées dans auth_audit_log (horodatage, IP, device fingerprint, provider, résultat).

Niveaux d'identité¶

Niveau Définition Exemple de fournisseur

Basic Auth simple : email, Apple, Apple ID, Google Sign-In Google

Verified Identité légale vérifiée France Identité, FranceConnect +

Qualified Identité substantielle / LuxTrust, CertEurope, EUDI élevée (eIDAS) Wallet

Les fonctions à valeur juridique (signature, horodatage, blockchain) exigent un compte verified ou qualified.

Authentification multi-facteur (MFA)¶

MFA obligatoire sur tous les comptes administrateurs et utilisateurs premium.
Compatibilité TOTP (Authenticator, 1Password) et clés FIDO2 (YubiKey, Passkey).
Validation obligatoire lors de l'ajout ou de la suppression d'un terminal.
Le facteur secondaire est chiffré et lié à user_id, non au device.

Sécurité des secrets¶

Argon2id pour le hachage des secrets internes (salt aléatoire, mémoire élevée, itérations adaptatives).
Aucun mot de passe stocké en clair ; seul un hash de vérification est conservé.
Tokens JWT éphémères (valide 15 min) + refresh token rotatif durant 24 h.
Les tokens sont signés via une clé Ed25519 gérée dans le Vault OVH.

Gestion des rôles et privilèges¶

Quatre rôles applicatifs sont définis :

Rôle Portée Droits

OWNER Compte racine Gestion complète, audit, transfert de coffres

EDITOR Utilisateur Lecture/écriture sur les métier fichiers autorisés

VIEWER Lecture seule Consultation sans modification

AUDITOR Lecture Accès aux journaux et hashs probatoire signés

Chaque rôle est traduit en rôle PostgreSQL avec politiques RLS et vues restreintes.

Gestion des sessions et révocation¶

Expiration automatique des sessions après 24 h d'inactivité.
Révocation centralisée : suppression immédiate des tokens en cas de perte ou compromission du terminal.
Synchronisation asynchrone vers tous les clients connectés (mobile, PWA, desktop).
Historique des sessions conservé 14 jours dans auth_audit_log.

Audit probatoire des accès¶

Chaque connexion, succès ou échec, fait l'objet d'un enregistrement append-only :

CREATE TABLE auth_audit_log (

id BIGSERIAL PRIMARY KEY,

user_id UUID,

provider TEXT,

ip INET,

device_fingerprint TEXT,

timestamp TIMESTAMPTZ DEFAULT NOW(),

status TEXT,

signature BYTEA NOT NULL

);

Les entrées sont chaînées par hash SHA3-256 et signées numériquement, garantissant la valeur probatoire de chaque authentification.

+----------------------------------------------------------------------+ | 💬 En résumé : | | | | Le modèle d'authentification de ProbatioVault combine fournisseurs | | OIDC modernes, chiffrement fort et traçabilité probatoire. | | Il offre une identité fluide pour le B2C, certifiée pour le B2B, et | | interopérable avec les futurs wallets européens (EUDI), tout en | | garantissant un contrôle total sur les données et les preuves | | d'accès. | +======================================================================+

Chiffrement et protection des données¶

Chiffrement client-side systématique (AES-256-GCM) avant tout envoi vers le cloud.
Dérivation des clés via HKDF + Argon2 à partir du mot de passe utilisateur ; aucune clé n'est stockée en clair côté serveur.
Double niveau de chiffrement :
métadonnées chiffrées via une clé dérivée,
contenu fichier chiffré avec clé unique par document (rotation automatique possible).
Les clés maître de session sont éphémères et détruites après usage.
Stockage chiffré au repos (OVH Object Storage WORM + AWS Glacier).
CSP stricte (Content-Security-Policy) : aucune inclusion de script externe, pas de CDN, pas de tracking tiers.

Intégrité et traçabilité probatoire¶

Chaque document est haché en SHA3-256 lors de l'upload, puis re-vérifié mensuellement (hash re-check).
Les résultats des vérifications sont consignés dans le journal probatoire d'intégrité, dont le hash global est ancré sur blockchain publique à intervalles réguliers.
Système d'horodatage certifié (RFC 3161) appliqué à chaque dépôt.
Détection d'altération via contrôle de hash et signature numérique (Ed25519).
Tests d'intégrité automatisés exécutés mensuellement via pipeline GitLab CI/CD.

Supervision, audit et durcissement¶

Analyse statique et sécurité du code :
pipeline GitLab intégrant SonarQube, npm audit, eslint-security, et vérification OWASP Dependency Check ;
audits exécutés de manière hebdomadaire.
Monitoring multi-cloud (OVH + AWS) supervisé via Prometheus, CloudWatch et Grafana.
Alertes en temps réel sur anomalies de réplication, hash non conforme ou activité suspecte.
Journal d'audit immuable : chaque événement critique est signé et stocké dans un bucket WORM.
Tests de restauration et revue de conformité effectués trimestriellement.
Accès administratif protégé par VPN chiffré WireGuard et bastion SSH dédié.

Conformité réglementaire et référentiels¶

ProbatioVault est conçu pour répondre aux principales exigences de conformité applicables aux coffres-forts numériques souverains :

Référentiel Exigences couvertes Statut

ISO 14641 / NF Archivage électronique à Conforme (phase 1) Z42-013 valeur probatoire, traçabilité, intégrité, auditabilité

RGPD (UE Minimisation, droit à Conforme, DPO désigné 2016/679) l'effacement, portabilité, sécurité des traitements

eIDAS / signature Horodatage qualifié et Compatible via électronique empreinte numérique prestataire tiers (horodatage qualifié en option)

CNIL / ANSSI Chiffrement fort, Conformité alignée recommandations cloisonnement, logs signés

AWS & OVH ISO 27001, ISO 27018, HDS, Hébergeurs conformes et certifications SOC 2 audités

Les journaux de traitement sont intégrés dans un registre RGPD automatisé, mis à jour à chaque création, modification ou suppression de donnée personnelle.

Un rapport de conformité annuel (généré automatiquement en JSON + PDF) regroupe :

le résumé des traitements de données,
les résultats d'audit de sécurité,
et la preuve d'ancrage blockchain pour l'intégrité.

+----------------------------------------------------------------------+ | 💡 Bonnes pratiques d'exploitation : | | | | - Vérifier la validité du MFA à chaque cycle de connexion. | | | | - Isoler les environnements de test et production dans des VPC | | distincts. | | | | - Mettre à jour les dépendances de sécurité dès publication (npm | | audit fix --force sous validation manuelle). | | | | - Effectuer un audit de code indépendant au moins une fois par | | an (interne ou prestataire certifié). | +======================================================================+

CI/CD et monitoring¶

L'intégration continue (CI) et le déploiement continu (CD) constituent la chaîne de confiance opérationnelle de ProbatioVault.\ Chaque livraison, qu'elle concerne le code, les dépendances ou l'infrastructure, est testée, auditée et tracée automatiquement.\ La supervision (monitoring) est intégrée dès la conception pour garantir la résilience, la traçabilité et la conformité probatoire de l'ensemble de la plateforme.

Chaîne CI/CD GitLab¶

Le pipeline GitLab CI repose sur une architecture en quatre étapes séquentielles, orchestrées par des runners isolés dans des environnements dédiés OVH Public Cloud.

Étape Objectif principal Outils / tâches clés

Lint & Analyse Qualité et sécurité du ESLint, TypeScript, Prettier, statique code SonarQube scanner

Tests unitaires Validation fonctionnelle Jest, React Testing Library, et et non-régression Supertest (API), mocks isolés d'intégration

Build & Construction et Docker multistage (base Packaging durcissement des images Alpine), build Expo / React Native, contrôle SBOM

Déploiement & Déploiement automatisé Terraform, Ansible, Helm, vérification vers OVH (staging → healthcheck post-deploy production)

Pipeline type (GitLab CI YAML) :

stages:

- lint

- test

- build

- deploy

lint:

image: node:20

script:

- npm ci

- npm run lint

- sonar-scanner

allow_failure: false

test:

image: node:20

script:

- npm run test:ci -- --coverage

coverage: \'/All files[^|]*\|[^|]*\s+([\d.]+)/\'

build:

image: docker:cli

services:

- docker:dind

script:

- docker build -t probatiovault-api:\$CI_COMMIT_SHA .

- docker push registry.ovh.net/probatiovault/api:\$CI_COMMIT_SHA

deploy:

stage: deploy

script:

- terraform apply -auto-approve

environment:

name: production

+----------------------------------------------------------------------+ | 🔒 Bonnes pratiques CI/CD : | | | | - Vérification du hash SBOM (Software Bill of Materials) à | | chaque build (attestation provenance). | | | | - Signature numérique des images Docker (cosign sign). | | | | - Validation manuelle obligatoire avant passage en production | | (seulement pour les jobs deploy). | | | | - Rétention automatique des artefacts (logs, rapports, hash) pour 24 | | mois. | | | | - Génération automatique du rapport PDF d'audit interne après | | chaque livraison (lint, tests, couverture, vulnérabilités). | +======================================================================+

Sécurité de la supply chain logicielle¶

Verrouillage des dépendances (package-lock.json, npm ci uniquement).
Audit hebdomadaire (npm audit, trivy fs ., grype).
Contrôle des dépendances open source via OWASP Dependency-Check et SonarQube Security Hotspots.
Interdiction des dépendances non signées ou sans score de réputation.
Signatures des images Docker et vérification via cosign verify avant déploiement.

Supervision et observabilité¶

L'observabilité ProbatioVault repose sur la stack Prometheus / Grafana / Loki, commune aux environnements de développement et de production.

Prometheus

Collecte des métriques d'infrastructure et applicatives :
latence API,
occupation des files BullMQ,
taille et taux de croissance des buckets S3/OVH,
latence de réplication CRR.
Exporters déployés sur chaque pod Kubernetes (Node, Redis, PostgreSQL).
Règles d'alerte configurées dans Alertmanager (latence > 200 ms, réplication bloquée, backlog BullMQ > 500).

Grafana

Dashboards différenciés :
Dev → couverture des tests, temps de build, taille bundle.
Ops → charge CPU/mémoire, débit S3, latence, intégrité réplication, disponibilité WORM.
Intégration directe avec Prometheus et Loki pour la corrélation temporelle (troubleshooting unifié).
Export automatique des rapports hebdomadaires en PDF pour suivi interne.

Loki

Collecte centralisée des logs applicatifs et système en JSON structuré.
Corrélation possible par ID de transaction, utilisateur ou document.
Rétention configurable (7 à 90 jours selon criticité).
Tous les logs critiques sont signés et archivés en WORM pour audit probatoire.

Observabilité probatoire et audit¶

Chaque pipeline CI/CD génère un rapport d'audit interne :
Lint + couverture + vulnérabilités,
hash Docker, checksum artefacts,
signature de build (cosign),
empreinte Merkle globale du commit livré.
Ce rapport est converti en PDF signé, horodaté et archivé dans un bucket WORM (valeur probatoire).
Les hash de build (SHA3-256 + Git commit) sont ancrés mensuellement sur blockchain publique pour garantir la traçabilité logicielle.

+----------------------------------------------------------------------+ | 💡 Conseil opérationnel : | | | | Automatiser la revue de conformité mensuelle via GitLab | | Scheduled Pipelines : | | | | - exécution complète des tests de non-régression, | | | | - génération du rapport d'audit probatoire, | | | | - mise à jour du registre RGPD, | | | | - et ancrage blockchain du hash global des rapports. | +======================================================================+

Clients : mobile, PWA et desktop¶

ProbatioVault adopte une approche multi-plateforme unifiée reposant sur un même socle technologique (React + TypeScript), garantissant une expérience cohérente tout en respectant les contraintes de sécurité propres à chaque environnement.

Chaque client exécute localement le chiffrement, la vérification d'intégrité et la gestion des clés dérivées, sans jamais exposer de données en clair à un serveur.

Architecture commune¶

Code base unique : React Native + Expo (mobile) et React + Vite (PWA / Tauri).
Moteur de chiffrement local : implémentation WebCrypto / SubtleCrypto (AES-256-GCM + HKDF + Argon2id).
Stockage local chiffré :
mobile → SecureStore / Keychain / Keystore (au niveau OS),
web → IndexedDB chiffré (clé dérivée, AES-GCM),
desktop → stockage natif chiffré via HSM ou TPM.
Cache intelligent : synchronisation asynchrone, mode hors-ligne complet, suppression sécurisée des blocs expirés.
Sandbox d'exécution : aucune donnée accessible hors du container applicatif (isolation stricte RN / ServiceWorker / Tauri).

Clients mobiles¶

Plateforme Technologie Caractéristiques principales

iOS / React Native + - Chiffrement natif via **KeyStore / Secure Android Expo Enclave\ - **Synchronisation hors-ligne avec re-chiffrement automatique\ - Biométrie (FaceID / TouchID) pour le déverrouillage local\ - Upload différé si connexion interrompue\ - Notifications d'intégrité (hash check local)\ - Code signé et vérifié via Expo EAS Build

+----------------------------------------------------------------------+ | 💡 Particularité mobile : | | | | Les clés sont générées et stockées dans la zone sécurisée du | | SoC ; aucune exportation n'est possible. | +======================================================================+

Client Web (PWA)¶

Fonctionne entièrement dans le navigateur, sans extension ni plugin.
Données chiffrées stockées dans IndexedDB, accessibles uniquement depuis l'origine HTTPS certifiée.
Service Worker gère le mode hors-ligne : lecture, ajout, suppression et synchronisation différée des fichiers chiffrés.
Authentification MFA intégrée (WebAuthn + TOTP).
Compatible desktop et mobile (Chrome, Safari, Edge, Firefox).
Peut être installée comme application autonome (manifest + cache PWA).
CSP, HSTS et Subresource Integrity activées par défaut :
aucune inclusion de script externe,
politique script-src \'self\',
frame-ancestors \'none\'.

+----------------------------------------------------------------------+ | ⚠️ Risque critique : | | | | la PWA doit toujours être servie via HTTPS avec un certificat | | valide et HSTS permanent ; toute livraison non sécurisée invalide la | | garantie de confidentialité. | +======================================================================+

Client desktop¶

Technologie Sécurité locale Cas d'usage principal

Electron / - Chiffrement natif Archivage notarial, cabinets Tauri via HSM, TPM ou clé d'expertise, serveurs YubiKey d'entreprise - Signature eIDAS qualifiée possible\ - Offline total (aucun accès
réseau requis)\ - Intégration de modules locaux : OCR, signature, compression

Ce client agit comme un poste de travail sécurisé pour opérations probatoires : signature qualifiée, vérification blockchain, export scellé.
Les clés eIDAS ou HSM peuvent être utilisées pour sceller les preuves ou signer des lots d'archives.
Un mode "air-gapped" (hors connexion) permet de manipuler les données sensibles dans un environnement totalement isolé, avant synchronisation contrôlée.

Synchronisation et cohérence¶

Chaque client implémente le même protocole de synchronisation chiffrée (basé sur BullMQ / WebSocket / REST).
Conflits résolus côté client selon la règle "dernier hash valide horodaté".
Les événements de synchronisation (upload, suppression, mise à jour) sont signés et intégrés au journal d'audit local.
Un diff incrémental permet de limiter les transferts (compression LZ4 + checksum).

+----------------------------------------------------------------------+ | 💡 Conseils de déploiement : | | | | - Maintenir des builds signés et vérifiés sur tous les stores (Apple | | / Play Store / auto-update desktop). | | | | - Utiliser des Service Workers versionnés pour éviter le cache | | obsolète. | | | | - Activer Integrity Metadata pour chaque ressource (JS / CSS / | | manifest). | | | | - Prévoir un "mode urgence" : effacement sécurisé du cache et | | des clés locales en cas de compromission ou de perte d'accès. | +======================================================================+

Analyse locale et IA confidentielle¶

Objectif¶

Le module d'analyse locale par IA embarquée permet à l'utilisateur d'obtenir une synthèse automatique de ses documents sans jamais exposer leur contenu à un serveur ou à un service externe.\ L'ensemble du traitement est effectué en local sur le terminal, via un modèle ONNX quantisé exécuté par le moteur d'inférence natif.\ Cette approche inaugure la brique « IA confidentielle » de ProbatioVault, en cohérence avec les principes fondateurs de souveraineté et de zéro-connaissance.

Principe de fonctionnement¶

Lorsqu'un utilisateur souhaite résumer un document ou un dossier complet, l'application :

déchiffre localement le contenu en mémoire volatile ;
segmente le texte en phrases ;
vectorise chaque phrase à l'aide d'un modèle embarqué (MiniLM-multilingual-int8.onnx) ;
calcule la pertinence sémantique des phrases via un algorithme de similarité (MMR + TextRank sémantique) ;
restitue les 3 à 6 phrases les plus représentatives dans l'ordre d'origine.

Aucune donnée n'est transmise ni stockée sur le backend.\ L'ensemble du pipeline s'exécute off-line, dans le même espace sandboxé que les fonctions de chiffrement locales.

Architecture technique¶

Composant Rôle principal

onnxruntime-react-native Moteur d'inférence local (CPU, Metal, NNAPI).

MiniLM-multilingual-int8.onnx Modèle multilingue embarqué (~10 Mo).

wordpiece.ts Tokenizer local (WordPiece / BERT).

embedder.ts Chargement du modèle et génération des embeddings.

rank.ts Sélection des phrases clés (MMR + heuristiques).

summarizeDocuments.ts Point d'entrée unifié pour l'analyse d'un ou plusieurs documents

Flux fonctionnel simplifié :

[ Document chiffré ]

↓ (déchiffrement local)

[ Texte brut ]

↓ (tokenisation + embeddings)

[ Analyse sémantique locale ]

↓

[ Résumé confidentiel affiché à l'utilisateur ]

Performance et empreinte¶

Élément Valeur moyenne

Taille du modèle 10 à 15 Mo (int8 quantisé)

Vocabulaire embarqué 0,8 Mo

RAM utilisée 60 à 120 Mo

Temps de résumé (document de 1 à 3 secondes 5--10 pages)

Mode offline Oui

Langues supportées Français, anglais, espagnol, allemand, italien, etc

Le moteur sélectionne automatiquement le backend optimal (CPU, Metal ou NNAPI).\ Les traitements sont stateless : aucune donnée persistée après exécution.

Confidentialité et sécurité¶

Zéro transfert réseau : tout le pipeline est exécuté localement.
Données éphémères : les textes déchiffrés ne sont jamais écrits sur disque.
Modèle signé : le fichier ONNX est livré avec son hash SHA3-256 et vérifié à l'exécution.
Journal probatoire : le hash du modèle et la version du module d'analyse sont ajoutés au journal local et ancrés périodiquement.
Fallback : en cas d'indisponibilité du modèle, l'application bascule sur un mode léger (résumé TF-IDF/TextRank) ; la confidentialité reste identique.

Intégration applicative¶

Le module est intégré dans la couche mobile (React Native / Expo) via un hook dédié :\ useLocalSummarize().

Il s'interface avec useDocumentStore pour accéder au contenu déchiffré et produire la synthèse.\ Les sorties sont restituées à l'utilisateur sous forme de texte ou de bloc Markdown, avec option d'enregistrement dans les métadonnées chiffrées du document.

Aucune dépendance réseau, aucun appel API.\ Le code est isolé dans src/ai/ et ne possède aucune permission d'accès externe.

Fonctionnalités prévues¶

Étape Description Version cible

Phase 1 Implémentation ONNX embarqué (résumé extractif v 0.9 beta sémantique)

Phase 2 Synthèse multi-documents (fusion de résumés) v 1.0

Phase 3 Reformulation naturelle (DistilT5 ONNX quantisé) v 1.1

Phase 4 Extension facultative vers enclave TEE (analyse v 2.0 avancée attestée)

Chaque évolution conservera la même garantie de traitement local chiffré ou attesté.

Conformité et auditabilité¶

Le module s'inscrit dans le cadre de conformité NF Z42-013 et ISO 14641 :

traçabilité du modèle utilisé (hash, version, date d'exécution) ;
conservation append-only des journaux d'analyse locale ;
ancrage blockchain périodique du hash global du journal IA ;
conformité RGPD : absence de transfert, suppression immédiate des données après traitement.

Cette approche garantit une analyse assistée juridiquement neutre, auditable et souveraine.

Bénéfices utilisateur¶

Critère Détail

Confidentialité Aucun envoi réseau, déchiffrement et traitement local absolue uniquement.

Lisibilité des Résumés clairs, multilingues et cohérents, adaptés aux résultats documents juridiques ou administratifs.

Utilisation Analyse possible sans connexion Internet. hors-ligne

Cohérence Hash du modèle et du résultat intégrés dans le journal probatoire local.

Expérience fluide Résumé rapide (1--3 s) même pour des dossiers volumineux

💬 En résumé :\ L'IA embarquée de ProbatioVault prolonge le modèle Zero-Knowledge jusqu'au traitement du contenu :\ les documents restent sur l'appareil, les calculs s'effectuent en local, et le résultat bénéficie de la même valeur probatoire que les autres opérations du coffre-fort souverain.

Risques & mitigation¶

Les risques identifiés couvrent les aspects techniques, opérationnels, sécuritaires et réglementaires du système ProbatioVault.\ Chaque risque est associé à une probabilité, un impact potentiel, et une mesure de mitigation concrète déjà intégrée au design.

Catégorie Risque identifié Impact Mitigation / contre-mesure

Infrastructure Panne OVH Élevé Redondance vers **AWS Paris principale (Glacier multi-AZ) ; bascule (Gravelines)** automatique via Terraform + monitoring Prometheus ; plan PRA testé semestriellement.

                   **Panne régionale AWS Moyen        **Cross-Region Replication
                   (Paris)**                          (CRR)** vers **AWS Francfort**,
                                                      supervision CloudWatch +
                                                      Grafana.

                   **Panne simultanée    Faible /     Conservation **Cold Archive
                   OVH + AWS UE**        Critique     OVH** (air-gap sur bande) ;
                                                      restauration manuelle validée
                                                      tous les 6 mois.

Stockage / coûts Explosion des coûts Moyen Politique **Lifecycle Glacier ou Cold Terraform (transitions Archive** automatiques → suppression à échéance) + alertes mensuelles de suivi coûts AWS Budgets.

Sécurité / *Compromission Moyen Chiffrement *côté client chiffrement terminal client** (AES-256-GCM)** ; aucune clé stockée en clair ; biométrie et Secure Enclave / Keystore.

                   **Mauvaise rotation   Fort         Cron supervisé BullMQ + audit
                   de clé (maître ou                  des rotations ; clés
                   utilisateur)**                     versionnées (HKDF + Argon2id) ;
                                                      vérification automatique
                                                      d'intégrité post-rotation.

                   **Fuite de clé        Fort         Clé stockée dans Vault OVH HSM
                   serveur (K_master)**               ; rotation annuelle +
                                                      journalisation probatoire +
                                                      révocation automatique des
                                                      enveloppes liées.

                   **Faible entropie     Moyen        Argon2id + MFA obligatoire ;
                   mots de passe                      politiques de complexité et
                   utilisateurs**                     détection de fuites connues
                                                      (HaveIBeenPwned API en local).

Logiciel / dette *Accumulation de Moyen *Audit trimestriel SonarQube + technique dette technique ou npm audit + OWASP Dependency vulnérabilités non Check** ; politique CI/CD avec corrigées** seuils bloquants ; backlog technique priorisé.

                   **Erreur humaine en   Faible /     Étapes GitLab sécurisées
                   déploiement ou        Critique     (séparation
                   CI/CD**                            lint/test/build/deploy) ;
                                                      déploiement signé et validation
                                                      manuelle avant production.

Conformité / **Violation RGPD Fort Minimation des données stockées juridique (données personnelles ; pseudonymisation systématique ou métadonnées)** ; registre RGPD automatisé + DPO désigné ; audit annuel.

                   **Non-conformité NF   Fort         Audit de conformité interne
                   Z42-013 / ISO 14641**              annuel ; contrôle tiers
                                                      certifié avant mise en
                                                      production ; documentation
                                                      traçable dans les journaux
                                                      probatoires.

Disponibilité / **Saturation files Moyen Monitoring Prometheus + performance Redis / BullMQ** Alertmanager ; purge automatique > 500 jobs ; re-scaling horizontal API et workers.

                   **Dégradation des     Moyen        Compression LZ4 des index
                   temps de réponse PWA               locaux, pagination et purge
                   ou mobile**                        incrémentale ; seuil \< 150 ms
                                                      garanti par tests E2E.

Fiabilité **Perte ou corruption Fort Journal append-only signé et opérationnelle du journal chaîné SHA3-256 + ancrage probatoire** blockchain hebdomadaire ; restauration multi-version testée.

                   **Ancrage blockchain  Faible       Re-tentative automatique +
                   non confirmé / échec               backup sur registre interne OVH
                   transaction**                      (Proof Ledger) ; alerte
                                                      monitoring si écart \> 24 h.

IA locale / **Fuite de contenu IA Faible Traitement 100 % local (ONNX confidentialité (confidentialité)** offline) ; modèle signé et vérifié SHA3-256 ; suppression mémoire immédiate.

Facteurs humains Erreur utilisateur Moyen Mode "zéro-confiance" : clés (ou partage éphémères, expiration 7 jours, irréfléchi) revocation immédiate + watermark dynamique.

Évolutivité Obsolescence Moyen / Long Surveillance technologique technologique (crypto terme continue ; rotation algorithmes ou stockage) AES → ChaCha20 → post-quantique dès standardisation NIST

+----------------------------------------------------------------------+ | 💬 En résumé : | | | | Le dispositif de mitigation de ProbatioVault repose sur | | la redondance multi-cloud, le chiffrement applicatif, | | la journalisation probatoire et une supervision | | automatisée. | | Chaque risque majeur dispose d'un plan de continuité ou de | | correction immédiate, assurant la résilience technique, | | juridique et probatoire de la plateforme. | +======================================================================+

Recommandations globales¶

Les recommandations suivantes visent à assurer la pérennité opérationnelle, la conformité probatoire et la sécurité de l'écosystème ProbatioVault sur le long terme.\ Elles regroupent les bonnes pratiques issues des audits internes, des revues de code et des principes de souveraineté applicative.

🧱 Environnements et gouvernance¶

Séparer strictement les environnements development, staging et production.\ Chaque environnement doit posséder ses propres credentials, clés de chiffrement et espaces de stockage isolés (buckets, DB, VPC).\ ➜ Objectif : éviter toute contamination de données réelles dans les environnements de test.
Versionner la configuration d'infrastructure (Terraform, Ansible, Helm) sous contrôle Git, avec revue manuelle obligatoire avant déploiement en production.
Centraliser la gouvernance des clés dans le Vault OVH : rotation annuelle automatique, accès restreint, et archivage scellé des anciennes versions.

🧩 Code, documentation et qualité logicielle¶

Documenter exhaustivement tous les modules NestJS :
core, auth, crypto, backup, jobs, audit.\ Chaque module doit disposer d'un README, d'un diagramme d'interaction et d'une couverture de tests > 85 %.
Interdire tout SELECT direct sur le schéma vault_secure.\ Toutes les lectures doivent passer par des vues et fonctions contrôlées (RLS activé + audit).\ ➜ Objectif : éviter toute fuite accidentelle de métadonnées confidentielles.
Établir un audit trimestriel de sécurité :
exécution des pipelines SonarQube et OWASP Dependency Check,
vérification des droits PostgreSQL,
validation des configurations Object Lock et WORM.

💰 Supervision et coûts¶

Mettre en place un tableau de bord de coûts multi-cloud (AWS + OVH) via Prometheus + Grafana ou AWS Budgets.\ Suivre mensuellement les classes de stockage (actif, Glacier, Cold Archive) et les volumes S3/OVH.\ ➜ Objectif : garantir la viabilité économique du modèle de redondance à long terme.
Automatiser les alertes de surcoût (écart > 10 % par rapport à la moyenne mobile mensuelle) et tracer les actions correctives dans le journal d'exploitation.

🧾 Conformité et traçabilité probatoire¶

Tester la restauration WORM tous les six mois** : récupération d'un échantillon de fichiers depuis OVH, AWS Paris et Francfort, vérification des hash et signatures.\ ➜ Objectif : démontrer la continuité probatoire et la validité des chaînes de confiance.
Conserver un registre de conformité (RGPD + NF Z42-013 + ISO 14641) mis à jour à chaque livraison majeure, incluant :
les audits de sécurité réalisés,
les preuves d'ancrage blockchain,
les rapports CI/CD signés et archivés.
Réaliser un audit cryptographique annuel (interne ou tiers ANSSI/CNIL) : contrôle de l'entropie, rotation des clés, politique de logs, et intégrité des modules de chiffrement.

+----------------------------------------------------------------------+ | 💬 En résumé : | | | | ProbatioVault doit maintenir dans le temps une séparation stricte | | des environnements, une documentation complète du code, | | une supervision financière proactive et une traçabilité | | probatoire vérifiable. | | Ces bonnes pratiques garantissent la résilience, la conformité | | réglementaire et la fiabilité opérationnelledu coffre-fort | | numérique souverain. | +======================================================================+

✅ Conclusion¶

ProbatioVault incarne une approche souveraine, sécurisée et probatoire du stockage numérique, conçue pour répondre aux exigences les plus élevées en matière de confidentialité, de conformité et de durabilité.

Son architecture repose sur quatre fondements techniques et éthiques indissociables :

🔒 Chiffrement applicatif intégral : toutes les données sont chiffrées côté client, selon un modèle zéro-connaissance garantissant qu'aucun serveur ni fournisseur ne peut accéder aux contenus.
🧱 Redondance bi-cloud souveraine : OVH Cloud assure la performance et la maîtrise opérationnelle, tandis qu'AWS Glacier assure la conservation probatoire à long terme via réplication inter-région (Paris → Francfort), complétée en option par un archivage froid sur bande OVH.
⚖️ Conformité active : chaque action est journalisée, signée et horodatée conformément aux normes NF Z42-013, ISO 14641 et RGPD, assurant une traçabilité juridiquement opposable.
🧾 Auditabilité permanente : la chaîne CI/CD, les journaux append-only et les ancrages blockchain publics garantissent une vérification indépendante et automatisée de la conformité du système.

Au-delà de sa robustesse technique, ProbatioVault établit un nouveau standard européen de confiance numérique, conciliant :

la souveraineté des données,
la valeur probatoire certifiable,
et la résilience sur plusieurs décennies, indépendamment des fournisseurs cloud.

En combinant architecture modulaire, chiffrement dérivé, redondance multi-niveaux et preuve cryptographique publique, ProbatioVault se positionne comme un coffre-fort numérique de référence, capable de préserver et de prouver l'intégrité des documents essentiels --- qu'ils relèvent du patrimoine individuel, professionnel ou institutionnel.

+----------------------------------------------------------------------+ | 💬 En résumé : | | | | ProbatioVault ne se contente pas de stocker les données : il en | | garantit la mémoire, la preuve et la souveraineté. | | Sa conception établit une passerelle durable entre la sécurité | | technique et la confiance juridique, fondement même du futur | | archivage numérique en Europe. | +======================================================================+

📎 Annexes¶

Exemple Object Lock AWS¶

aws s3api put-object-retention --bucket probatiovault-archives --key 1234abcd.enc --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2075-01-01T00:00:00Z"}'

Exemple manifest PWA¶

{
  "name": "ProbatioVault",
  "short_name": "Vault",
  "display": "standalone",
  "theme_color": "#001F3F",
  "background_color": "#FFFFFF",
  "start_url": "/",
  "icons": [
    {"src": "/icons/icon-192.png", "sizes": "192x192"},
    {"src": "/icons/icon-512.png", "sizes": "512x512"}
  ]
}

Pseudo-code export WORM¶

await s3.send(new PutObjectCommand({
  Bucket: "pv-archives",
  Key: `${fileHash}.enc`,
  Body: encryptedBuffer,
  ObjectLockMode: "COMPLIANCE",
  ObjectLockRetainUntilDate: new Date(retainUntil),
  StorageClass: "DEEP_ARCHIVE"
}));

Politique Terraform Glacier CRR¶

resource "aws_s3_bucket_replication_configuration" "probatiovault" {
  role = aws_iam_role.replication.arn
  bucket = aws_s3_bucket.vault.id

  rule {
    id     = "replicate-euwest3-to-eucentral1"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.vault_replica.arn
      storage_class = "DEEP_ARCHIVE"
    }
  }
}