Apache Superset est un outil de Business Intelligence puissant, mais sa mise en conformité avec le Règlement général sur la protection des données (RGPD) dépend entièrement de la façon dont vous l'hébergez et le configurez. Cet article passe en revue les exigences RGPD applicables à une instance Superset, les mesures techniques et organisationnelles à mettre en place, et la documentation à produire pour démontrer votre conformité.
1. Pourquoi Apache Superset est concerné par le RGPD
Le RGPD encadre tout traitement de données à caractère personnel concernant des personnes situées dans l'Union européenne. Or, dès qu'un dashboard Superset affiche un identifiant client, un e-mail, une adresse IP, un numéro de commande ou tout autre attribut permettant d'identifier directement ou indirectement une personne, vous traitez des données personnelles au sens de l'article 4 du règlement.
Si vous voulez éviter la friction réglementaire et technique liée à un déploiement sur-mesure, TVL Managed Superset déploie une instance hébergée en France (OVHcloud, Roubaix), avec contrat de sous-traitance RGPD prêt à signer, en moins de 3 minutes.
Le rôle de votre organisation dans cette chaîne est crucial. Vous êtes responsable de traitement au sens de l'article 4(7) lorsque vous décidez des finalités et des moyens du traitement (par exemple, analyser le comportement client). Si vous utilisez un service managé pour héberger Superset, l'éditeur du service est généralement sous-traitant au sens de l'article 28 — un contrat de sous-traitance écrit (DPA, Data Processing Agreement) est alors obligatoire.
2. Cartographier les données personnelles dans Superset
Avant toute chose, identifiez précisément quelles données personnelles transitent par votre instance Superset. Trois catégories doivent être distinguées.
2.1 Données utilisateurs Superset
Les comptes Superset eux-mêmes contiennent des données personnelles : nom, prénom, e-mail, mot de passe haché, dernière date de connexion, rôles, journaux d'activité. Ces informations sont stockées dans la base de métadonnées (Postgres ou MySQL) et dans Redis pour les sessions.
2.2 Données métier exposées dans les dashboards
Les datasets connectés à Superset peuvent contenir des données personnelles : clients, prospects, employés, utilisateurs finaux d'une application. Même si Superset ne stocke pas ces données (il interroge la source à la volée), il y accède et les affiche, ce qui constitue un traitement.
2.3 Données techniques
Logs applicatifs, logs d'accès Nginx, événements d'audit Superset, traces de performance. Une simple adresse IP est considérée comme une donnée personnelle par la CNIL et la CJUE depuis l'arrêt Breyer (2016).
3. Choisir la bonne base légale pour chaque traitement
L'article 6 du RGPD impose qu'à chaque traitement corresponde une base légale parmi six possibilités. Dans le contexte Superset, les bases les plus courantes sont :
- Intérêt légitime (art. 6.1.f) : analyse interne pour piloter l'activité, à condition de réaliser un test de mise en balance ;
- Exécution d'un contrat (art. 6.1.b) : analyse d'usage d'un produit B2B pour fournir des fonctionnalités contractuelles ;
- Obligation légale (art. 6.1.c) : reporting financier, lutte anti-fraude, conservation comptable ;
- Consentement (art. 6.1.a) : analyse marketing fine, profilage à des fins publicitaires.
Documentez la base légale de chaque dashboard contenant des données personnelles dans votre registre des traitements (article 30 RGPD).
4. Mesures techniques de mise en conformité
4.1 Hébergement dans l'Union européenne
Depuis l'arrêt Schrems II (juillet 2020), les transferts vers les États-Unis sont strictement encadrés. Pour éviter les complications, hébergez Superset dans l'UE chez un fournisseur soumis au droit européen. OVHcloud, Scaleway, Hetzner, Outscale sont des choix solides et certifiés. TVL Managed Superset repose entièrement sur l'infrastructure OVHcloud à Roubaix.
4.2 Chiffrement en transit et au repos
Toute communication avec Superset doit utiliser TLS 1.2 minimum (1.3 recommandé). Côté stockage, chiffrez les volumes des bases Postgres/Redis et activez le chiffrement at-rest proposé par votre hébergeur. Les sauvegardes doivent l'être également.
4.3 Authentification forte et SSO
Activez le SSO via OIDC ou SAML pour bénéficier des politiques d'authentification de votre IdP (MFA, expiration de session, audit). Voir notre guide SSO OIDC sur Apache Superset. Désactivez la création libre de comptes locaux en production.
4.4 Row Level Security (RLS)
La Row Level Security de Superset permet de filtrer dynamiquement les lignes affichées selon le rôle de l'utilisateur connecté. C'est le mécanisme central pour appliquer le principe de minimisation exigé à l'article 5.1.c du RGPD : un commercial ne doit voir que ses propres clients, un manager que son équipe.
4.5 Pseudonymisation et anonymisation
Lorsque l'analyse n'a pas besoin de l'identité, pseudonymisez les datasets : remplacez les e-mails par un hash, les noms par un identifiant interne. La pseudonymisation reste un traitement RGPD mais réduit fortement le risque en cas de fuite. L'anonymisation complète (irréversible, k-anonymat) sort du périmètre RGPD.
4.6 Journalisation et traces d'audit
Apache Superset propose un audit log nativement : chaque requête SQL, chaque modification de dashboard, chaque connexion est tracée. Centralisez ces logs dans un backend séparé (Loki, Elasticsearch, OpenObserve) avec une politique de conservation alignée sur votre registre des traitements (généralement 6 à 12 mois).
4.7 Sauvegardes et restauration
Le RGPD impose à l'article 32 la capacité à restaurer la disponibilité et l'accès aux données personnelles dans des délais appropriés en cas d'incident. Mettez en place des sauvegardes automatiques quotidiennes de la base de métadonnées Superset, testées régulièrement. Cette configuration est appliquée par défaut sur TVL Managed Superset, qui réalise un snapshot quotidien des Postgres et Redis OVHcloud managés.
5. Mesures organisationnelles
5.1 Registre des traitements (article 30)
Tenez à jour un registre listant chaque dashboard ou catégorie de dashboards traitant des données personnelles, avec : finalité, base légale, catégories de données, catégories de personnes concernées, destinataires, durée de conservation, mesures de sécurité.
5.2 Analyse d'impact (DPIA / AIPD)
Si votre instance Superset traite des données à grande échelle, des données sensibles (santé, opinions politiques) ou met en œuvre du profilage, vous devez réaliser une analyse d'impact relative à la protection des données (article 35). La CNIL met à disposition un outil gratuit, PIA, pour structurer cette analyse.
5.3 Contrat de sous-traitance (DPA)
Signez un contrat de sous-traitance écrit avec votre hébergeur Superset, conforme à l'article 28 RGPD. Il doit lister les sous-sous-traitants éventuels (par ex. l'hébergeur d'infrastructure) et autoriser un audit annuel.
5.4 Politique de gestion des droits
Préparez une procédure interne pour répondre aux demandes d'accès, de rectification, d'effacement et de portabilité (articles 15 à 20). Pour Superset, cela suppose de pouvoir identifier rapidement, dans la base de métadonnées et les datasets connectés, toutes les données associées à un identifiant utilisateur.
6. Tableau récapitulatif des contrôles par exigence RGPD
| Exigence RGPD | Article | Contrôle Superset |
|---|---|---|
| Licéité du traitement | Art. 6 | Documenter la base légale par dashboard |
| Minimisation | Art. 5.1.c | RLS, datasets virtuels filtrés, pseudonymisation |
| Sécurité | Art. 32 | TLS, chiffrement at-rest, MFA, audit log |
| Notification de violation | Art. 33-34 | Alerting Prometheus, runbook incident sous 72 h |
| Sous-traitance | Art. 28 | DPA signé avec l'hébergeur |
| Transferts hors UE | Art. 44+ | Hébergeur UE, sous-sous-traitants UE |
| Registre des traitements | Art. 30 | Inventaire des dashboards à risque |
| Droits des personnes | Art. 15-22 | Procédure documentée, requêtes SQL types |
7. Erreurs fréquentes à éviter
- Donner accès à toute la production à tous les utilisateurs Superset : la majorité des fuites internes vient d'un défaut de RLS.
- Stocker des exports non chiffrés sur des laptops : encadrez les exports CSV et Excel par une politique d'usage.
- Utiliser un hébergeur hors UE sans clauses contractuelles types ni évaluation des transferts (TIA).
- Conserver indéfiniment les logs d'audit : fixez une durée de conservation et purgez automatiquement.
- Oublier les anciens comptes : un script de désactivation des comptes inactifs depuis 90 jours est indispensable.
8. Documenter sa conformité dans la durée
Le RGPD repose sur le principe d'accountability (article 5.2) : vous devez non seulement être conforme, mais pouvoir le démontrer. Conservez les preuves suivantes :
- registre des traitements à jour (versionné dans Git ou un GRC) ;
- analyse d'impact (DPIA) et mises à jour ;
- DPA signé avec l'hébergeur et avenants ;
- politique de sécurité du système d'information (PSSI) qui couvre Superset ;
- preuves de tests de restauration de sauvegarde ;
- journal des incidents et des notifications CNIL éventuelles ;
- preuves de formation des administrateurs Superset.
9. Conclusion
Mettre Apache Superset en conformité RGPD est un projet réaliste, mais qui touche à la fois à la technique (chiffrement, RLS, hébergement UE), au juridique (DPA, registre, DPIA) et à l'organisation (procédures, formation). La plupart des contrôles peuvent être automatisés et industrialisés sur une plateforme bien architecturée.
Vous voulez les bénéfices d'Apache Superset sans la friction d'installation, de maintenance et de mise en conformité RGPD ? Déployez votre instance en 3 clics avec TVL Managed Superset, hébergé en Europe (OVHcloud, Roubaix, France), avec contrat de sous-traitance RGPD prêt à signer.
Pour aller plus loin, consultez notre guide de hardening Superset et notre comparatif managé vs auto-hébergé.