Réaliser un audit de confidentialité et d'accès sur votre data stack

Dans une société SaaS de taille moyenne, un customer success rep peut, en trois clics dans l'outil de BIBITechnologies et processus qui transforment des données brutes en insights actionnables via du reporting, des dashboards et de l'analyse, pour que les équipes décident sur des faits plutôt qu'à l'intuition.Voir la définition complète → (business intelligence), afficher l'email, l'adresse de facturation et l'historique des tickets support de n'importe quel utilisateur : sans filtre, sans log, sans validation. Personne n'a conçu cela délibérément. Ça s'est simplement accumulé : un dashboard construit pour une équipe a été partagé, un rôle censé être temporaire n'a jamais expiré, une synchronisation reverse-ETLreverse-ETLPratique consistant à renvoyer les données de l'entrepôt central vers les outils métier (CRM, plateformes publicitaires, support) pour que les équipes puissent agir.Voir la définition complète → (extract, transform, loadextract, transform, loadL'ETL (Extract, Transform, Load) est un processus d'intégration de données qui extrait les données de sources multiples, les remet en forme dans un format cohérent et les écrit dans un système cible.Voir la définition complète →) a poussé des champs du warehouse vers un outil commercial sans que personne ne vérifie ce que « select all columns » contenait réellement.

C'est l'état normal de la plupart des data stacks en 2026. La solution n'est pas un vaste chantier de conformité. C'est un audit récurrent, piloté par une checklist, que vous pouvez mener en un après-midi.

Pourquoi c'est un problème de gouvernance, pas seulement un problème IT

La data governancedata governanceLa data governance est l'ensemble des politiques, rôles et processus qui garantissent que les données sont exactes, sécurisées, bien définies et utilisées de façon responsable dans toute l'organisation.Voir la définition complète →, c'est l'ensemble des règles, rôles et processus qui déterminent qui peut accéder, modifier ou déplacer des données, et comment vous en apportez la preuve. En SaaS, le risque concret n'a rien d'abstrait : c'est un agent support qui voit les données de paiement d'un autre client, ou un growth analyst qui exporte des PII (personally identifiable information : noms, emails, adresses IP) dans un tableur qui finit sur un portable personnel.

Les régulateurs s'y intéressent parce que la loi le leur impose. Sous le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → européen (General Data Protection Regulation), les entreprises doivent appliquer la « protection des données dès la conception et par défaut » (article 25) et s'exposent à des amendes allant jusqu'à 4 % du chiffre d'affaires annuel mondial ou 20 millions d'euros, le montant le plus élevé étant retenu, en cas d'infraction grave (texte du RGPD). Aux États-Unis, il n'existe pas de loi fédérale unique sur la vie privée, mais des lois d'État comme le CCPA/CPRA (California Consumer Privacy Act, amendé par le California Privacy Rights Act) confèrent un pouvoir de sanction à la California Privacy Protection Agency, et des règles sectorielles comme HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (Health Insurance Portability and Accountability Act) s'appliquent si votre produit SaaS touche à des données de santé.

Les auditeurs et les clients grands comptes réclament désormais systématiquement des rapports SOC 2 (System and Organization Controls 2, un framework d'audit américain de l'AICPA) avant de signer. Le contrôle d'accès est l'un des premiers points testés par un auditeur SOC 2.

Les trois couches où les PII fuient réellement

La plupart des sociétés SaaS stockent les données clients dans un data warehousedata warehouseUn référentiel central qui consolide les données de nombreux systèmes sources dans un stockage structuré et optimisé pour les requêtes, conçu pour l'analytique, le reporting et la business intelligence.Voir la définition complète → (une base centralisée optimisée pour l'analytics : Snowflake, BigQuery, Redshift). De là, les données circulent dans deux directions :

1. Vers les outils de BI (Looker, Tableau, Power BI, Metabase) pour les dashboards et le reporting.
2. Vers l'extérieur via le reverse ETL (des outils comme Census ou Hightouch qui renvoient les données du warehouse vers des outils opérationnels comme Salesforce, HubSpot ou Intercom).

Chaque couche exige son propre audit, car les permissions ne se transmettent pas automatiquement de l'une à l'autre. Une colonne masquée dans le warehouse peut quand même fuiter si l'outil de BI met en cache un ancien extract, ou si une synchronisation reverse-ETL a été configurée avant l'existence de la règle de masquage.

La checklist : couche warehouse

À exécuter chaque trimestre, ou après tout mouvement d'effectif dans les équipes data.

• Listez chaque rôle/utilisateur disposant d'un accès en requête. Dans Snowflake ou BigQuery, extrayez directement les grants :

-- Snowflake example: who can query the customers table?
SHOW GRANTS ON TABLE analytics.core.customers;

• **Repérez les rôles avec SELECT * sur les tables de PII brutes.** Toute personne extérieure au data engineering ou à un rôle nommément désigné pour la protection des données ne devrait pas avoir un accès illimité aux colonnes brutes email, phone, ssn, ip_address.
• Vérifiez le masquage au niveau colonne. Les warehouses modernes prennent en charge le dynamic data masking, qui affiche j***@***.com au lieu d'un email réel pour les rôles non privilégiés. Confirmez qu'il est réellement appliqué aux tables de production, et pas seulement au staging.
• Passez en revue les service accounts. Ce sont les identifiants non humains utilisés par les pipelines. Ils disposent souvent d'un accès plus large que n'importe quel salarié et sont rarement revus. Le service account d'un outil marketing n'a pas à disposer d'un accès en écriture sur les tables de facturation.
• Confirmez que les query logs sont conservés et interrogeables. Vous devez pouvoir répondre à « qui a requêté les données du client X, et quand » sur au moins 90 jours, idéalement 12 mois, pour répondre à un régulateur ou à une demande d'accès d'une personne concernée (DSAR, un droit imposé par le RGPD de savoir quelles données une entreprise détient sur vous).

La checklist : couche outil de BI

• Cartographiez les dashboards vers les tables sous-jacentes. Un dashboard destiné à l'équipe marketing ne devrait pas joindre discrètement une table support contenant le texte brut des réclamations et les noms des clients.
• Vérifiez les paramètres de sécurité au niveau ligne et colonne. Les PDT de Looker (persistent derived tables) et les access filters, ou la row-level security de Tableau, doivent restreindre ce que chaque lecteur voit, pas seulement ce qu'il peut modifier.
• Auditez les permissions « explore » ou de requête ad hoc. La plupart des outils de BI permettent aux power users de contourner les dashboards curatés et de requêter directement le modèle sous-jacent. C'est là que se cache généralement le sur-permissionnement.
• Vérifiez les droits d'export et de téléchargement. Un utilisateur peut-il exporter la liste complète des clients en CSV ? Si oui, qui, et est-ce loggé ?
• Passez en revue les liens embarqués/partagés. Beaucoup d'outils de BI permettent de générer un lien public ou semi-public vers un dashboard. Cherchez ceux qui exposent des PII et n'ont jamais été révoqués.

La checklist : couche reverse ETL

Le reverse ETL est plus récent et moins scruté, ce qui en fait la couche la plus à risque en 2026.

• Listez chaque sync active et sa destination (CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète →, plateforme publicitaire, outil support, email marketing).
• Vérifiez le mapping au niveau champ. Une sync conçue pour envoyer le « tier client » vers un outil marketing ne doit pas transporter aussi les « notes support historiques » parce que quelqu'un a sélectionné toute la table au lieu de colonnes précises.
• Contrôlez les accès côté destination. Une fois les PII arrivées dans HubSpot ou dans l'outil d'audiences d'une plateforme publicitaire, le masquage appliqué au warehouse ne s'applique plus. Si vous synchronisez des emails hachés pour construire une audience publicitaire (un schéma courant en retargeting), confirmez que le hachage a bien lieu avant la sync, et non après.
• Vérifiez la fréquence des syncs et l'obsolescence des données. Si un client exerce son droit à l'effacement RGPD (« droit à l'oubli », article 17) et que vous le supprimez du warehouse, la sync suivante propage-t-elle cette suppression en aval, ou des PII périmées subsistent-elles indéfiniment dans un outil marketing ?

Pour un modèle de checklist opérationnel, le guide OWASP sur la protection des données est rédigé pour des ingénieurs sécurité, mais ses principes de contrôle d'accès se transposent directement aux audits de data stack.

Un mini-exemple chiffré : mesurer votre exposition

Admettons que votre warehouse compte 40 comptes salariés et 15 service accounts disposant d'une forme ou d'une autre d'accès en requête. Vous passez les grants en revue et vous trouvez :

• 6 comptes humains ont un SELECT * illimité sur une table customers brute (il devrait y en avoir 2 : le lead data eng et l'analyste désigné par le DPO).
• 3 service accounts alimentant des outils reverse-ETL ont accès à des colonnes au-delà de ce que leur sync utilise réellement.

Cela fait 9 comptes sur-permissionnés sur 55, soit environ 16 % de l'ensemble des accès accordés. Ce pourcentage est exactement le type de métrique qu'un board ou un auditeur SOC 2 veut voir suivi trimestre après trimestre, idéalement en tendance vers zéro. Le chiffre absolu compte moins que votre capacité à le produire sur demande et à montrer qu'il diminue.

Qui en est responsable, organisationnellement

La gouvernance échoue quand elle n'est explicitement le travail de personne. En pratique :

• Un Data Protection Officer (DPO) est juridiquement obligatoire sous le RGPD pour les entreprises réalisant un traitement à grande échelle de données sensibles ; les sociétés SaaS plus petites confient souvent ce rôle à temps partiel à un responsable juridique ou ops.
• Le data engineering gère les grants et les règles de masquage au niveau warehouse.
• Les leads analytics/BI gèrent les permissions au niveau dashboard.
• Le RevOps ou le growth ops gère les syncs reverse-ETL, et dispose souvent de la formation sécurité la plus faible des trois, raison pour laquelle la responsabilité de la checklist doit être explicitement attribuée sur cette couche, et non supposée.

À retenir

• Auditez les trois couches séparément : grants du warehouse, permissions de l'outil de BI, mappings des syncs reverse-ETL. Les accès ne restent pas automatiquement cohérents d'une couche à l'autre.
• Les service accounts et les modes de requête ad hoc « explore » sont les deux sources de sur-permissionnement les plus souvent négligées.
• Le RGPD (UE) et le CCPA/CPRA (Californie) créent une exposition réelle aux sanctions ; les rapports SOC 2 sont le passage obligé commercial de fait pour les deals SaaS grands comptes, et les deux reposent sur un contrôle d'accès démontrable.
• Suivez une métrique simple chaque trimestre : les comptes sur-permissionnés en pourcentage du total des accès accordés, et montrez qu'elle baisse.
• Le reverse ETL est la couche la plus récente et la moins auditée en 2026 : le masquage appliqué dans le warehouse ne suit pas les données une fois qu'elles arrivent dans un CRM ou une plateforme publicitaire.