Pipeline conforme RGPD : anonymiser les DCP avant le stockage
Mis à jour pour 2026
Vous avez étiqueté vos colonnes DCP dans dbt. Vous avez configuré le masquage dynamique dans Snowflake. Vous vous sentez conforme au RGPD.
Vos données sources atterrissent quand même dans l'entrepôt sans masquage. Le masquage s'applique au moment de la requête. Le contenu non masqué se trouve dans votre schéma brut. Toute personne ayant accès à ce schéma peut le lire. Vos modèles dbt ont tourné avant que les politiques de masquage existent. Les anciennes tables ingérées n'ont jamais été masquées.
L'écart entre « nous avons des politiques de masquage » et « notre pipeline est sécurisé » est là où les violations RGPD surviennent.
Consultez notre présentation de la conformité pour voir comment anonym.legal soutient les obligations RGPD.
Comment les pipelines ELT exposent les DCP
Le modèle Extract-Load-Transform (ELT) est désormais la norme. Il charge d'abord les données sources dans l'entrepôt. Les transformations viennent ensuite. Les étapes ressemblent à ceci :
- Extraction : Les systèmes sources exportent tous les champs. Salesforce CRM, paiements Stripe, support Intercom — tout est extrait.
- Chargement : Les données sources atterrissent dans le schéma d'ingestion de l'entrepôt. Snowflake, BigQuery, Redshift fonctionnent tous de la même façon. Chaque champ DCP est inclus.
- Transformation : Les modèles dbt nettoient et joignent les données pour l'analytique.
La couche d'ingestion contient des informations personnelles complètes. Noms, adresses e-mail, numéros de téléphone, détails de paiement, contenu des tickets de support. Dans de nombreuses équipes, ingénieurs et analystes ont accès au schéma brut. Ils peuvent interroger ces tables à tout moment.
Le masquage par tags dans Snowflake aide au moment des requêtes — mais uniquement pour les modèles en aval correctement configurés. Il ne masque pas les anciennes tables ingérées. Il ne bloque pas les requêtes directes sur le schéma. Chaque modèle et tableau de bord doit être étiqueté. Cette charge augmente à mesure que le schéma grandit.
Anonymiser avant le chargement
Anonymiser les DCP au niveau du pipeline supprime le risque de la couche d'ingestion. Faites-le avant que le contenu n'arrive dans l'entrepôt.
Approche ETL (anonymisation pré-chargement) :
- Extraire depuis les systèmes sources
- Faire passer par une étape d'anonymisation
- Charger les sorties propres dans l'entrepôt
L'entrepôt ne reçoit jamais de DCP non masqués. Le schéma d'ingestion ne contient que du contenu propre. Les modèles en aval, tableaux de bord et requêtes directes travaillent tous avec des sorties propres.
Vous avez deux voies principales.
Option 1 — Intégration API :
Pour les systèmes avec webhooks ou exports en streaming, acheminez les entrées d'abord via l'API anonym.legal. Les tickets de support quittant Intercom passent par l'API avant l'entrepôt. Les exports Stripe font de même.
POST /api/anonymize
{
"text": "Le client Jean Dupont (jean@example.com) a signalé...",
"entities": ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER"],
"method": "replace"
}
Option 2 — Prétraitement par lots :
Pour les exports de fichiers CSV/JSON quotidiens ou hebdomadaires, faites passer les fichiers par un traitement par lots avant le chargement.
Structure DAG Airflow :
extract_task >> anonymize_batch_task >> load_to_warehouse_task
La tâche d'anonymisation envoie les fichiers et récupère les versions propres. La tâche de chargement gère le reste.
Consultez notre page pratiques de sécurité pour les détails sur les sous-traitants et les flux de données.
Ce que font et ne font pas les tags de colonnes dbt
dbt vous permet de taguer les colonnes DCP :
models:
- name: stg_customers
columns:
- name: email
tags: ['pii', 'email']
- name: full_name
tags: ['pii', 'personal_data']
Les tags permettent :
- La documentation des emplacements des DCP
- Le déclenchement des politiques de masquage en aval (nécessite une configuration au niveau de l'entrepôt)
- Le suivi de lignage avec des outils comme Secoda
Les tags ne permettent pas :
- Le masquage des tables ingérées dans le schéma brut
- Le blocage des requêtes directes sur les tables
- L'anonymisation au moment du chargement
- Le masquage rétroactif des anciennes données
Les tags de colonnes dbt sont un outil de gouvernance. Ils montrent où se trouvent les DCP. Ils n'appliquent pas les « mesures techniques appropriées » que l'article 32 du RGPD exige.
La lacune du masquage dynamique Snowflake
Le masquage dynamique de Snowflake masque le contenu des colonnes aux utilisateurs au moment des requêtes. C'est un contrôle puissant pour les cas d'usage en production. Mais il a des limites claires.
Limites principales :
- Chaque nouvelle colonne nécessite une politique explicite
- Les changements de schéma peuvent laisser de nouvelles colonnes non masquées jusqu'à la mise à jour des politiques
- Les rôles SYSADMIN et ACCOUNTADMIN peuvent généralement contourner le masquage
- Les imports tournent souvent avec des privilèges élevés qui sautent le masquage
- Les anciennes données chargées avant la mise en place des politiques sont stockées en clair — les politiques s'appliquent à la lecture, pas à l'écriture
Le masquage au moment des requêtes ne suffit pas. Les données doivent être propres avant d'être stockées.
Documentation de conformité
Le principe de responsabilité du RGPD exige des preuves. Les mots ne suffisent pas. Pour les équipes d'ingénierie, cela signifie des enregistrements écrits.
Registre des activités de traitement (RAT) : Documentez que les informations clients sont anonymisées avant le chargement dans l'entrepôt analytique. L'étape d'anonymisation est une activité de traitement au sens du RGPD.
Notes sur les mesures techniques : Notez quels types d'entités votre pipeline cible. Notez la méthode d'anonymisation utilisée. Les journaux de traitement par lots vous le fournissent automatiquement.
Lignage des données : Secoda ou le lignage intégré de dbt peut montrer que les tables sources traversent une étape d'anonymisation avant d'atteindre les modèles analytiques. C'est votre piste d'audit.
Registre des fournisseurs : Le service d'anonymisation est un sous-traitant. Leur DPA et politique de confidentialité doivent figurer dans votre registre des fournisseurs.
Étapes d'implémentation
Pour un pipeline dbt et Snowflake :
Étape 1 : Auditer la couche brute
Trouvez quelles tables contiennent des informations personnelles. Interrogez vos tags de colonnes dbt ou votre catalogue pour les tables taguées DCP.
Étape 2 : Définir le périmètre d'anonymisation
Pour chaque table source, décidez quelles colonnes contiennent des DCP. Puis décidez lesquelles nécessitent une anonymisation et lesquelles une pseudonymisation. Corps du ticket de support : anonymiser. Identifiant de commande : pseudonymiser pour conserver les clés de jointure. Horodatage : conserver pour l'analyse des séries temporelles.
Étape 3 : Choisir une voie d'implémentation
Petite équipe avec exports par lots : traitement de fichiers par lots avant chargement. Équipe d'ingénierie disponible : intégration API dans Airflow ou Prefect.
Étape 4 : Tester et valider
Exécutez l'anonymisation sur un échantillon avant la mise en production. Vérifiez que les modèles dbt fonctionnent toujours. Certains modèles font des jointures sur l'e-mail. Ceux-là ont besoin de valeurs de remplacement cohérentes. La pseudonymisation conserve les clés de jointure. La suppression les brise.
Étape 5 : Traiter les anciennes tables
Le contenu chargé avant la mise en place de l'anonymisation nécessite un traitement rétroactif. Exporter, anonymiser, recharger. C'est une opération unique par table.
Conclusion
Le masquage par tags vous montre où se trouvent les DCP. Il n'empêche pas les utilisateurs ayant accès au schéma de les lire. Pour une vraie conformité RGPD, les DCP doivent être propres avant d'atteindre l'entrepôt. Cela rend la couche d'ingestion aussi sûre que la couche de production.
C'est plus difficile que le tagging de colonnes. Mais c'est ce que « mesures techniques appropriées » signifie réellement.