Architecture RGPD "By Design" : La Doctrine Mesh Box

Par Olivier Girodin, CEO & Lead Architect chez Mesh Box

Dans l'ingénierie logicielle moderne, la conformité n'est pas une case à cocher par le département légal, c'est une contrainte d'architecture fondamentale. Chez Mesh Box, nous considérons que le respect du RGPD doit être codé dans l'ADN de l'application, conformément au principe de "Privacy by Design".

Le Fondement Juridique

Tout architecte logiciel opérant en Europe doit intégrer l'exigence de l'Article 25 du Règlement (UE) 2016/679 (RGPD) :

« [...] le responsable du traitement met en œuvre, tant au moment de la détermination des moyens du traitement qu'au moment du traitement lui-même, des mesures techniques et organisationnelles appropriées, telles que la pseudonymisation, qui sont destinées à mettre en œuvre les principes de protection des données, par exemple la minimisation des données, de façon effective et à assortir le traitement des garanties nécessaires [...] » Source officielle : Règlement (UE) 2016/679 sur EUR-Lex

Notre interprétation technique : Le législateur demande explicitement des "mesures techniques". Cela signifie que l'architecture logicielle doit proactivement empêcher les fuites et gérer le cycle de vie de la donnée, sans intervention humaine.

Voici les 5 patterns architecturaux que nous implémentons systématiquement dans nos stacks Node.js / TypeScript / Angular.

1. Logging : La Stratégie "Zero-Leak"

Les logs sont souvent le vecteur de fuite de données le plus sous-estimé (ELK, Datadog). Il est inacceptable qu'un développeur puisse lire un email ou un mot de passe dans un dump d'erreur.

• Le Pattern : Sérialisation sélective et redondance au niveau du transport.
• L'Implémentation Node.js :
  • Nous privilégions Pino pour sa performance, couplé impérativement avec
    pino-redact
    .
  • Cette approche permet de définir des chemins d'objets (ex:
    ['req.headers.authorization', 'user.email', 'billing.iban']
    ) qui sont censurés ou hachés avant même que le log ne quitte le processus Node.js.
  • Best Practice : Utiliser un hachage déterministe (HMAC) pour l'obfuscation. Cela permet aux équipes Ops de corréler des erreurs pour un même utilisateur sans jamais connaître son identité.

2. Droit à l'oubli : Le Pattern "Crypto-Shredding"

Dans une architecture distribuée ou micro-services, la suppression en cascade est risquée. De plus, modifier des backups immuables (S3 Glacier) pour supprimer un utilisateur est techniquement impossible.

• Le Pattern : Supprimer la clé plutôt que la donnée.
• L'Implémentation :
  • Chaque utilisateur possède une clé de chiffrement unique (DEK - Data Encryption Key) stockée dans un KMS ou un Vault sécurisé.
  • Toutes les données sensibles (PII) de cet utilisateur sont chiffrées avec sa DEK avant d'être écrites en base ou dans les logs.
  • Pour exécuter un droit à l'oubli (Article 17), nous ne supprimons pas les données éparpillées : nous détruisons simplement la DEK. Les données deviennent mathématiquement irrécupérables, rendant les backups conformes "by design".

3. Sécurité Angular : Abandonner le LocalStorage

Le stockage de JWT (JSON Web Tokens) ou de PII dans le

expose l'application aux failles XSS. N'importe quel script tiers malveillant injecté peut exfiltrer ces données.

• Le Pattern : Authentification via Cookies HttpOnly (BFF - Backend For Frontend).
• L'Implémentation :
  • Le front-end Angular ne doit jamais manipuler le token d'accès brut.
  • Le Backend (NestJS/Express) émet un cookie avec les flags stricts :
    HttpOnly
    (invisible pour le JS),
    Secure
    (HTTPS uniquement) et
    SameSite=Strict
    .
  • Cela neutralise la majorité des vecteurs d'attaque XSS ciblant le vol de session.

4. Chiffrement "At Rest" : Application-Level Encryption

Le chiffrement du disque (TDE) protège contre le vol physique du serveur, mais pas contre une injection SQL ou un admin DB curieux.

• Le Pattern : Chiffrement de colonne transparent via l'ORM.
• L'Implémentation :
  • Avec TypeORM ou Prisma, nous injectons des middlewares de chiffrement (comme
    prisma-field-encryption
    ou des ValueTransformers TypeORM custom).
  • Les champs comme email ou phone sont chiffrés/déchiffrés à la volée par le code applicatif (Node.js) utilisant AES-256-GCM. La base de données ne voit jamais la donnée en clair.

5. Consentement : Immutable Audit Log

Le consentement n'est pas un booléen (true/false). C'est un contrat juridique versionné qui doit être auditable.

• Le Pattern : Event Sourcing (Append-Only).
• L'Implémentation :
  • Nous ne faisons jamais d'
    UPDATE
    sur les préférences utilisateur. Chaque changement de consentement est un
    INSERT
    dans une table
    ConsentLedger
    .
  • Ce log contient : l'ID utilisateur, le type de consentement, le timestamp, le hash de l'IP, et surtout l'ID de la version des CGU acceptée à cet instant précis.
  • Cela permet de reconstruire l'historique complet en cas de contrôle CNIL.

Chez Mesh Box, nous transformons les contraintes légales en leviers de qualité architecturale.