La plupart des équipes abordent le RGPD comme un exercice juridique : une politique de confidentialité, un bandeau cookies, un DPA signé rangé dans un tiroir. Cette approche cède la première fois qu’une demande d’effacement doit atteindre un entrepôt de données, ou qu’un auditeur mandaté par un client grand compte demande où se trouve exactement une sauvegarde. Le règlement impose des exigences concrètes sur la circulation des données dans vos systèmes : ce qui entre dans un pipeline, combien de temps cela persiste, qui peut le lire, et votre capacité à le prouver.
Ce guide traduit les principales obligations en décisions d’architecture. Il s’adresse aux décideurs techniques d’entreprises B2B qui traitent des données personnelles à grande échelle — fiches CRM, événements utilisateurs, historiques de transactions — et qui veulent des pipelines capables de passer un audit, plutôt que des politiques qui le promettent.
Quatre obligations inscrites dans l’architecture
L’essentiel du texte du RGPD ne concerne pas les ingénieurs. Quatre obligations font exception, car elles contraignent directement les schémas et la topologie.
- Propagation de la base légale. Chaque enregistrement de données personnelles a été collecté sur un fondement juridique précis — consentement, contrat, intérêt légitime. Cette base doit accompagner la donnée, ou pouvoir en être déduite, afin que les systèmes en aval réagissent quand elle change. Si un consentement est retiré dans le CRM, l’entrepôt et chaque table dérivée doivent en être informés.
- Minimisation des données. Un pipeline doit transporter les champs qu’exige la finalité du traitement et écarter le reste dès l’ingestion. Copier des enregistrements sources complets parce que le stockage coûte peu multiplie votre surface de conformité à chaque table.
- Durées de conservation. Chaque jeu de données doit avoir une durée de conservation définie et un traitement automatisé qui l’applique. Une conservation gérée par des scripts ponctuels, ou pas du tout, figure parmi les constats d’audit les plus fréquents.
- Droit à l’effacement. Quand une personne concernée le demande, vous devez supprimer ses données personnelles de chaque système qui les détient, sous un mois. C’est un problème de systèmes distribués, et la plus difficile des quatre obligations à traiter a posteriori.
Résidence des données dans l’UE : fixer les régions, puis vérifier les marges
Les trois grands fournisseurs cloud opèrent des régions européennes — Francfort, Paris, Amsterdam ou Dublin, entre autres — et y ancrer le stockage primaire est simple. Le risque se loge en périphérie : réplication des sauvegardes entre régions, copies de reprise d’activité, agrégation de logs ou suivi d’erreurs confiés à un SaaS hébergé aux États-Unis, outillage de support qui exporte des données de production. Une promesse de résidence ne vaut que ce que vaut son composant le moins rigoureux.
Tout transfert hors de l’EEE exige un mécanisme juridique valide : une décision d’adéquation, ou des clauses contractuelles types appuyées par une analyse d’impact de transfert. Pour la plupart des plateformes B2B, la position la plus simple à défendre consiste à conserver les données personnelles dans des régions de l’UE de bout en bout : stockages primaires, répliques, sauvegardes et pile d’observabilité. Une infrastructure cloud RGPD de bout en bout retire une catégorie entière de questions de chaque revue de sécurité que vos clients mèneront sur vous.
Chiffrement : une pratique standard, appliquée jusqu’au bout
Le chiffrement en transit signifie TLS 1.2 au minimum sur chaque segment, y compris le trafic de service à service au sein de votre propre réseau — c’est sur le trafic interne qu’il fait le plus souvent défaut. Le chiffrement au repos est activé par défaut sur le stockage cloud managé, mais avec des clés gérées par le fournisseur. Des clés gérées par le client via le KMS du cloud apportent la rotation, la séparation par environnement et la possibilité de révoquer un accès — précisément ce que les questionnaires de sécurité des grands comptes attendent de plus en plus.
Pour les champs les plus sensibles, ajoutez un chiffrement au niveau du champ dans la couche applicative. Il rend aussi possible le crypto-shredding : détruisez la clé d’une personne concernée, et ses données deviennent illisibles dans chaque copie que cette clé protégeait — y compris les sauvegardes et archives que vous ne pouvez pas réécrire en pratique. Pour les stockages immuables ou en append-only, c’est souvent le seul mécanisme d’effacement praticable.
Sous-traitants et DPA : la couche contractuelle sous le pipeline
Tout tiers qui manipule des données personnelles pour votre compte est un sous-traitant ou un sous-traitant ultérieur, et requiert un accord de traitement des données (DPA) au titre de l’article 28. Dans un pipeline classique, la liste est plus longue qu’on ne le pense : le fournisseur cloud, le service ETL ou de streaming managé, l’éditeur de l’entrepôt de données, les outils de monitoring et de suivi d’erreurs — les stack traces et les lignes de log contiennent des données personnelles plus souvent qu’on ne le croit — et toute API d’enrichissement.
Tenez à jour un registre des sous-traitants qui relie chaque prestataire au composant du pipeline qu’il sert, aux catégories de données qu’il voit et à la région où il s’exécute. Faites de la signature du DPA une condition d’intégration de tout nouvel outil au pipeline. Vos clients grands comptes en France, en Allemagne et aux Pays-Bas demanderont ce registre pendant la phase d’achats ; le produire en un jour plutôt qu’en un mois est un signal de crédibilité.
Pattern : les zones de pseudonymisation
Scindez le pipeline en deux zones. Une zone identifiée détient les identifiants directs — noms, adresses e-mail, numéros de téléphone — dans un petit nombre de stockages à l’accès étroitement contrôlé. Une zone pseudonymisée, où se déroulent l’analytique, le reporting et le machine learning, transporte des jetons stables à la place des identifiants, avec un coffre qui relie les jetons aux identités pour les rares flux qui en ont besoin.
Le bénéfice tient à la réduction du rayon d’impact : l’essentiel de votre infrastructure, et l’essentiel des accès de votre équipe, ne touche jamais un identifiant direct, et une compromission de la zone analytique expose beaucoup moins. Soyez précis sur les limites : des données pseudonymisées restent des données personnelles au sens du RGPD. Le pattern réduit le risque et le périmètre d’audit ; il n’exonère de rien.
Pattern : propagation des effacements et pistes d’audit
Traitez l’effacement comme un événement, pas comme un script. Une demande d’effacement entre par un point unique, est validée, puis publiée comme événement de suppression sur votre bus interne. Chaque système détenant des données personnelles — bases opérationnelles, entrepôt, index de recherche, caches, SaaS en aval via API — s’y abonne, exécute sa propre suppression et signale son achèvement. Un coordinateur suit la diffusion et ne clôt la demande que lorsque chaque consommateur a confirmé — ce qui vous donne une réponse défendable à la question de savoir comment vous prouvez que l’effacement a eu lieu partout.
Les sauvegardes exigent une politique explicite et documentée : soit l’effacement est réappliqué automatiquement à la restauration d’une sauvegarde, soit la durée de rétention des sauvegardes est assez courte pour que l’expiration fasse le travail. En parallèle, tenez un journal d’audit en append-only de l’activité de traitement — changements de consentement, confirmations d’effacement, exécutions des purges de conservation, accès à la zone identifiée. Le principe de responsabilité posé à l’article 5, paragraphe 2, impose de pouvoir démontrer la conformité ; ce journal est cette démonstration.
Par où commencer
Commencez par une cartographie des données : quels systèmes détiennent des données personnelles, quels champs, sur quelle base, pour combien de temps. Travaillez ensuite les couches par ordre de levier : socle de résidence et de chiffrement d’abord, automatisation de la conservation ensuite, propagation des effacements après, zones de pseudonymisation là où la sensibilité le justifie. Une mise en conformité a posteriori se mesure en mois sur une pile B2B classique ; intégrer ces propriétés à un pipeline neuf coûte une fraction de ce temps.
Nous concevons et exploitons des pipelines de données conformes au RGPD dans le cadre de notre offre Infrastructure cloud & données, avec résidence des données dans l’UE et DPA gérés en standard. Si vous souhaitez un second regard sur votre architecture actuelle, un audit est aussi le point de départ que nous choisirions.