Chapitre 2 — Architecture du SAE ProbatioVault¶

2.1 Architecture logique¶

L'architecture logique du SAE ProbatioVault repose sur une separation stricte des responsabilites entre quatre couches fonctionnelles : presentation, traitement metier, stockage persistant et services cryptographiques. Cette organisation garantit que chaque composant peut evoluer independamment tout en preservant les proprietes probatoires du systeme.

2.1.1 Couche presentation — Application mobile (React Native / Expo)¶

L'application mobile constitue le point d'entree utilisateur du SAE. Developpee en TypeScript strict avec le framework Expo / React Native, elle est deployee sur iOS et Android. Elle assure les fonctions suivantes dans le perimetre du SAE :

• Chiffrement client-side : avant toute transmission reseau, le document est chiffre localement par l'application au moyen de l'algorithme AES-256-GCM. La cle de chiffrement du document (K_doc) est derivee de la cle maitre utilisateur (K_master_user) via HKDF-SHA3-256, avec le document_id comme sel. Le serveur ne recoit jamais le document en clair (principe Zero-Knowledge).
• Gestion du keystore local : la cle maitre utilisateur est conservee dans le Secure Store du terminal (Secure Enclave sur iOS, Android Keystore sur Android), protegee par une cle de chiffrement (K_encryption) derivee du mot de passe utilisateur via Argon2id (64 MiB, t=3, p=4).
• Calcul d'empreintes : le hash SHA3-256 du document chiffre est calcule localement et transmis au backend pour enregistrement dans la base de metadonnees.
• Gestion d'etat : la couche etat applicatif repose sur Zustand, assurant une gestion reactive et previsible des donnees en memoire.

2.1.2 Couche traitement metier — Backend NestJS¶

Le backend constitue le coeur du traitement metier du SAE. Il orchestre les flux documentaires (ingestion, consultation, certification, destruction) et applique les regles metier sans jamais acceder aux documents en clair.

Stack technique :

Modules fonctionnels SAE :

2.1.3 Couche stockage persistant¶

Le stockage se decompose en trois sous-systemes complementaires :

• PostgreSQL : base de donnees relationnelle hebergeant les metadonnees documentaires (empreintes, dates, proprietaires), les enveloppes de cles chiffrees (key_envelopes), les preuves composites (hash + signature + horodatage) et les journaux d'audit structures. Le mecanisme Row-Level Security (RLS) assure l'isolation des donnees entre utilisateurs au niveau du SGBD.
• Redis : cache en memoire pour les sessions, les tokens JWT et l'acceleration des lectures frequentes de metadonnees. Redis sert egalement de broker pour les files BullMQ (jobs de replication et de batch cryptographique).
• Stockage objet S3 : couche de persistence des documents chiffres, repartie sur deux fournisseurs cloud (OVH pour l'acces actif, AWS pour l'archivage conforme). Le detail de cette architecture est developpe au chapitre 4.

2.1.4 Couche services cryptographiques¶

Les operations cryptographiques sensibles sont deleguees a un module HSM (Hardware Security Module) AWS CloudHSM certifie FIPS 140-2 Level 3, accessible via l'interface PKCS#11 :

• Signature probatoire : les empreintes documentaires sont signees avec une cle RSA-PSS 4096 bits dont la cle privee ne quitte jamais le HSM (propriete non-exportable).
• Key wrapping : les cles de chiffrement utilisateur sont encapsulees via AES-KWP (NIST SP 800-38F) avant stockage dans la base de donnees.
• Horodatage qualifie : apres signature HSM, un jeton d'horodatage RFC 3161 est obtenu aupres d'une autorite de confiance (TSA) conforme eIDAS, completant la preuve composite.

Diagramme : Architecture C4 niveau conteneurs¶

Le diagramme suivant presente les composants principaux du SAE ProbatioVault et leurs interactions a l'echelle des conteneurs (niveau 2 du modele C4).

graph TB
    subgraph Clients["Clients mobiles"]
        APP["Application React Native<br/>Chiffrement AES-256-GCM<br/>Keystore local"]
    end

    subgraph Backend["Backend NestJS"]
        API["API REST /api/v1<br/>Auth OIDC + RLS"]
        CRYPTO["Module Crypto<br/>PKCS#11 / Key Wrapping"]
        STORAGE["Module Storage<br/>Interface S3 unifiee"]
        AUDIT["Module Audit<br/>Journalisation append-only"]
        REPL["Worker Replication<br/>BullMQ async"]
    end

    subgraph Persistance["Stockage persistant"]
        PG["PostgreSQL 15<br/>Metadonnees + RLS"]
        REDIS["Redis<br/>Cache + BullMQ"]
        OVH["OVH S3 HOT<br/>Gravelines, France"]
        AWS["AWS S3 / Glacier<br/>Paris, France"]
    end

    HSM["AWS CloudHSM<br/>PKCS#11 / FIPS 140-2 L3"]

    APP -->|"HTTPS / TLS 1.3"| API
    API --> CRYPTO
    API --> STORAGE
    API --> AUDIT
    CRYPTO --> HSM
    STORAGE --> OVH
    REPL --> OVH
    REPL --> AWS
    AUDIT --> AWS
    API --> PG
    REPL --> REDIS
    API --> REDIS

Legende : Les fleches representent les flux de donnees entre composants. Toutes les communications externes transitent par TLS 1.3. Le HSM est accessible uniquement depuis le module Crypto du backend. Les documents chiffres circulent du client vers OVH S3 (acces actif), puis sont repliques de maniere asynchrone vers AWS Glacier (archivage conforme). Les journaux d'audit sont ecrits directement dans AWS S3 en mode append-only avec Object Lock COMPLIANCE.

2.2 Architecture physique¶

L'infrastructure physique du SAE ProbatioVault repose sur une strategie multi-cloud combinant OVH Cloud (souverainete et performance) et AWS (conformite WORM et resilience geographique). Cette repartition est motivee par trois contraintes cumulatives :

1. OVH ne supporte pas S3 Object Lock natif : l'immutabilite WORM hardware-backed exigee par les normes NF Z42-013 et ISO 14641 impose AWS S3 Object Lock en mode COMPLIANCE.
2. AWS Glacier present une latence de restauration de 12 a 48 heures : l'acces quotidien aux documents necessite un stockage actif a faible latence, assure par OVH S3 (acces inferieur a 100 ms).
3. La resilience geographique requiert une replication cross-region : la conformite RGPD et la protection contre la perte de donnees imposent une copie dans un second centre de donnees europeen (AWS Frankfurt).

2.2.1 Zone OVH Cloud — Stockage actif (HOT)¶

Le stockage actif est heberge dans le centre de donnees OVH de Gravelines (region GRA), en France. Il constitue le point d'ecriture principal et le point de lecture par defaut pour les documents utilisateurs.

2.2.2 Zone AWS Paris — Archivage conforme (COLD)¶

L'archivage conforme est heberge dans la region AWS eu-west-3 (Paris), en France. Il assure l'immutabilite WORM des documents et des journaux d'audit via S3 Object Lock en mode COMPLIANCE.

2.2.3 Zone AWS Frankfurt — Resilience geographique (CRR)¶

La replication cross-region (CRR) est configuree depuis le bucket documents-cold de Paris vers le bucket archives-frankfurt dans la region AWS eu-central-1 (Frankfurt), en Allemagne.

La CRR assure qu'en cas de perte de la region Paris, les archives restent accessibles depuis Frankfurt avec les memes garanties d'immutabilite. Les delete markers ne sont pas repliques pour empecher toute propagation de tentative de suppression.

Diagramme : Deploiement multi-cloud¶

Le diagramme suivant presente la repartition physique des composants du SAE entre les trois zones d'hebergement, ainsi que les flux de replication.

graph TB
    subgraph OVH_GRA["OVH Cloud — Gravelines, France"]
        VPS["VPS Backend NestJS<br/>UFW + Fail2ban"]
        S3_HOT["S3 documents-hot<br/>Acces &lt; 100 ms<br/>Versioning active"]
        S3_BKP["S3 backups<br/>PostgreSQL dump 30j"]
        PG_DB["PostgreSQL 15<br/>Metadonnees + RLS"]
        REDIS_C["Redis<br/>Cache + BullMQ"]
    end

    subgraph AWS_PARIS["AWS — Paris eu-west-3"]
        S3_COLD["S3 documents-cold<br/>Object Lock COMPLIANCE 50 ans<br/>Glacier Deep Archive J+1"]
        S3_AUDIT["S3 audit-logs<br/>Object Lock COMPLIANCE 50 ans<br/>Append-only"]
        HSM_P["CloudHSM<br/>FIPS 140-2 L3"]
    end

    subgraph AWS_FRANKFURT["AWS — Frankfurt eu-central-1"]
        S3_CRR["S3 archives-frankfurt<br/>DEEP_ARCHIVE<br/>Object Lock COMPLIANCE"]
    end

    VPS -->|"Lecture/Ecriture"| S3_HOT
    VPS -->|"Replication async<br/>BullMQ worker"| S3_COLD
    VPS -->|"Append-only"| S3_AUDIT
    VPS --> PG_DB
    VPS --> REDIS_C
    VPS -->|"PKCS#11"| HSM_P
    S3_COLD -->|"CRR 15 min SLA"| S3_CRR

Legende : Le VPS OVH communique avec les services AWS via HTTPS/TLS. La replication des documents d'OVH vers AWS Glacier est asynchrone, pilotee par un worker BullMQ. La CRR (Cross-Region Replication) de Paris vers Frankfurt est geree nativement par AWS avec un SLA de 15 minutes et preservation de l'Object Lock. Toutes les donnees restent dans l'Union europeenne (France et Allemagne).

2.3 Interfaces entre composants¶

Cette section detaille les protocoles, formats et regles de communication entre les composants du SAE. Chaque interface est documentee avec ses contraintes de securite et ses proprietes probatoires.

2.3.1 Interface Client — Backend (API REST)¶

Flux de donnees : les documents sont chiffres cote client (AES-256-GCM) avant transmission. Le backend recoit exclusivement des blobs chiffres accompagnes de metadonnees (empreinte SHA3-256, taille, type). Il ne possede aucune cle permettant de dechiffrer le contenu documentaire.

Pipeline de traitement d'une requete :

1. Middlewares (Helmet, CORS, compression)
2. Guard d'authentification (validation JWT via JWKS)
3. Intercepteurs (journalisation, transformation)
4. Validation du DTO (class-validator)
5. Controleur (routage)
6. Service (logique metier)
7. Repository (acces TypeORM / PostgreSQL)

2.3.2 Interface Backend — PostgreSQL¶

Regles RLS : a chaque requete HTTP authentifiee, le backend configure le parametre de session app.current_user_id via un intercepteur NestJS. Les politiques RLS de PostgreSQL filtrent automatiquement les lignes accessibles, assurant que chaque utilisateur n'accede qu'a ses propres documents.

Entites principales du schema SAE :

2.3.3 Interface Backend — Stockage S3 (OVH et AWS)¶

Flux d'ecriture : le backend ecrit le document chiffre dans le bucket OVH documents-hot. Un evenement declenche un job BullMQ dans la file replication. Le worker telecharge le document depuis OVH, le transfere vers le bucket AWS documents-cold avec les metadonnees Object Lock (mode COMPLIANCE, retention calculee selon le type de document), puis met a jour la table replication_status.

Flux de lecture : le backend interroge d'abord le cache Redis (TTL 1 heure pour les documents chiffres). En cas d'absence, il telecharge depuis OVH S3 HOT (latence inferieure a 100 ms). En dernier recours (purge manuelle d'OVH), une restauration depuis AWS Glacier est possible mais avec un delai de 12 a 48 heures.

2.3.4 Interface Backend — HSM (PKCS#11)¶

Flux de signature probatoire :

1. Le backend prepare les donnees a signer (empreinte SHA3-256 du document chiffre).
2. Le module Crypto invoque le HSM via PKCS#11 pour obtenir la signature RSA-PSS.
3. Le backend demande un jeton d'horodatage RFC 3161 aupres de la TSA.
4. La preuve composite (empreinte + signature + horodatage + identifiant de cle) est enregistree en base.

2.3.5 Interface Backend — Redis¶

2.3.6 Interface Backend — Services d'horodatage (TSA)¶

2.3.7 Synthese des flux de donnees¶

Le tableau suivant resume les principaux flux de donnees du SAE, leur direction, leur protocole et leur propriete de securite.

Invariants couverts par ce chapitre :

• INV-249-01 : Ce chapitre est le deuxieme des 10 chapitres contractuels du manuel SAE.
• INV-249-02 : Les composants SAE documentes sont le backend NestJS, l'application React Native, l'infrastructure OVH/AWS, le HSM CloudHSM, PostgreSQL et Redis.
• INV-249-03 : Deux diagrammes Mermaid maintenables accompagnent les composants decrits (architecture C4 et deploiement multi-cloud).
• INV-249-06 : Le contenu consolide et synthetise les informations issues de multiples sources (infra, backend, storage) avec references croisees, sans reproduction verbatim superieure a 30%.
• INV-249-07 : Le chapitre est exploitable sans acces au code source ; les regles, protocoles et configurations sont documentes de maniere autonome.