Droit de la vie privée pour les éditeurs SaaS : RGPD, CCPA et au-delà

Un client écrit à votre support : « Envoyez-moi toutes les données que vous détenez sur moi, et supprimez mon compte. » Le support transfère à l'engineering. Il faut maintenant retrouver les données de cette personne dans Stripe (paiements), Salesforce (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 →), Segment (event tracking) et un warehouse Snowflake qui alimente vos dashboards analytics. C'est une Data Subject Access Request (DSAR), et 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 → vous laisse 30 jours pour répondre. La plupart des sociétés SaaS mid-market découvrent, à cet instant, que personne ne sait vraiment où se trouvent toutes les données personnelles.

Cette leçon explique pourquoi cela arrive et comment y remédier avant que la demande n'arrive.

Le paysage réglementaire, en bref

Le RGPD (Règlement général sur la protection des données) est la loi européenne sur la protection des données, en vigueur depuis 2018, appliquée par les autorités nationales de protection des données (DPA) coordonnées de façon souple par le Comité européen de la protection des données. Il s'applique à toute entreprise traitant des données personnelles de personnes situées dans l'UE, où que l'entreprise soit établie.

Le CCPA (California Consumer Privacy Act), modifié et élargi par le CPRA (California Privacy Rights Act, effectif en 2023), accorde des droits similaires aux résidents californiens. Il est appliqué par la California Privacy Protection Agency (CPPA). D'autres États américains (Virginie, Colorado, Connecticut, Utah, et une liste qui s'allonge en 2026) ont adopté leurs propres lois, similaires mais pas identiques.

Point clé pour les équipes techniques : ces lois ne sont pas les mêmes, mais elles se ressemblent. Toutes donnent aux individus des droits sur leurs données. Toutes exigent que vous sachiez ce que vous détenez et où.

Les droits qui génèrent réellement du travail d'engineering

• Droit d'accès : fournir à la personne une copie de ses données (RGPD art. 15, « right to know » du CCPA).
• Droit à l'effacement : supprimer sur demande (RGPD art. 17, « droit à l'oubli », « right to delete » du CCPA).
• Droit de rectification : corriger les données inexactes.
• Droit à la portabilité : exporter les données dans un format exploitable.
• Droit d'opposition à la vente/au partage (spécifique au CCPA) : pertinent si vous partagez des données avec des ad networks ou des data brokers.

Chacun de ces droits est un workflow technique, pas seulement une politique juridique. C'est la partie que les équipes non techniques sous-estiment.

Là où ça coince : la réalité multi-tenant

La plupart des produits SaaS sont multi-tenant : une seule base de code, souvent un seul schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → de base de données, sert de nombreuses organisations clientes, avec des lignes taguées par un tenant_id ou un account_id. C'est efficace côté engineering mais cela complique le travail sur la vie privée de deux façons.

D'abord, les données personnelles s'éparpillent dans des systèmes qui ne partagent pas d'identifiant commun. L'email d'un utilisateur peut être la clé dans Salesforce, un customer_id dans Stripe, un user_id anonyme dans Segment qui n'est identifié que plus tard, et une valeur hashée dans votre warehouse pour l'analytics. Répondre à « que savons-nous de cette personne » suppose de résoudre l'identité dans ces quatre systèmes.

Ensuite, la suppression n'est pas une simple suppression. Stripe conserve les enregistrements de transactions pour des raisons fiscales et comptables (aux États-Unis, une rétention de 7 ans est une pratique courante ; dans l'UE, les codes fiscaux nationaux imposent souvent des durées similaires). Vous ne pouvez pas supprimer une facture payée simplement parce que quelqu'un dépose une demande d'effacement RGPD. Le RGPD lui-même prévoit ce conflit : l'article 17(3) autorise la conservation lorsqu'elle est requise par la loi. Donc « tout supprimer » signifie en réalité « supprimer ou anonymiser ce que vous avez le droit de supprimer, documenter le reste ».

Le déroulé réel de la demande

1. Identifier la personne. Faire correspondre l'email de la DSAR aux identifiants internes dans Stripe (objet customer), Salesforce (fiche contact), Segment (traits de l'utilisateur identifié) et les tables du warehouse (via un identity graph résolu, s'il existe).
2. Extraire les données. Stripe propose une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → pour exporter l'objet customer et les charges. Salesforce exporte le contact et l'historique d'activité. Le warehouse est la partie difficile : les données personnelles peuvent être dispersées dans des dizaines de tables issues d'années de pipelines ad hoc.
3. Appliquer les exceptions. Les données financières liées à des obligations fiscales restent. Tout ce dont la conservation n'est pas légalement requise part.
4. Répondre dans le délai. 30 jours sous RGPD (prolongeable une fois de 60 jours pour les demandes complexes). Le CCPA accorde 45 jours, prolongeables une fois de 45 jours.
5. Tout journaliser. Les régulateurs peuvent vous demander de prouver que vous avez un process, pas seulement que vous avez bien traité une demande.

Un test technique minimal : savez-vous seulement retrouver la personne ?

Un diagnostic simple avant qu'un régulateur ne vous le demande : lancez ce type de requête sur votre warehouse et mesurez le temps que cela prend, et le nombre de tables à parcourir.

-- exemple grossier : trouver toutes les tables référençant un utilisateur donné
-- (à exécuter sur les métadonnées du warehouse, ex. INFORMATION_SCHEMA de Snowflake)
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ILIKE ANY ('%email%', '%user_id%', '%customer_id%')
ORDER BY table_schema, table_name;

Si cela renvoie 60 tables réparties sur cinq schémas sans documentation de data lineagedata lineageLe data lineage cartographie les déplacements et transformations de la donnée à travers les systèmes, de l'origine à la consommation : d'où elle vient, ce qui l'a modifiée, et où elle va.Voir la définition complète →, voilà votre écart de gouvernance. Les équipes mûres résolvent cela avec un data catalogdata catalogUn inventaire centralisé des actifs de données d'une organisation, enrichi de métadonnées, qui aide chacun à trouver, comprendre et faire confiance aux données dont il a besoin.Voir la définition complète → (des outils comme Atlan, Collibra, ou l'open-source OpenMetadata) qui tague les colonnes contenant des données personnelles (PII, personally identifiable information) et suit le lineage de la source au dashboard.

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 → : l'infrastructure ennuyeuse qui vous sauve

La gouvernance est l'ensemble des politiques et contrôles déterminant qui peut accéder à quelles données, pour combien de temps, et pourquoi. Pour le SaaS en particulier, trois vérifications comptent avant tout :

Le data mapping. Un document vivant (pas un PDF ponctuel) listant chaque système qui touche à des données personnelles, ce qu'il détient, sa base légale de traitement (le RGPD en exige une : consentement, contrat, intérêt légitime, etc.) et la durée de conservation. L'Information Commissioner's Office britannique propose un guide gratuit et pratique : le guide de l'ICO sur le data mapping.

Des durées de conservation appliquées dans le code, pas dans des documents de politique. Si votre politique de confidentialité dit « nous supprimons les comptes inactifs après 2 ans » mais qu'aucun cron job ne le fait, vous avez un écart de conformité, et un écart découvrable en cas de litige.

Les audits d'accès. Passez régulièrement en revue qui, dans votre entreprise (pas seulement chez les sous-traitants externes), peut interroger les données clients brutes. Un support engineer avec un accès warehouse illimité aux PII de production est un constat fréquent en revue de sécurité et une véritable violation du principe de « minimisation des données » du RGPD (article 5(1)(c) : ne traiter que ce qui est nécessaire).

Les fournisseurs font partie de votre surface de conformité

Sous RGPD, Stripe et Salesforce sont vos sous-traitants ; vous êtes le responsable de traitement (l'entité qui décide pourquoi et comment les données sont traitées). Il vous faut un Data Processing Agreement (DPA) avec chaque fournisseur, standard dans leurs contrats entreprise. Mais le DPA ne vous absout pas : si Salesforce gère mal des données parce que vous l'avez mal configuré (par exemple en rendant un rapport public), vous restez responsable devant le régulateur.

C'est pourquoi « nous utilisons des fournisseurs conformes » n'équivaut pas à « nous sommes conformes ». Un schéma d'application observé en 2023 chez les DPA européennes : plusieurs entreprises ont été sanctionnées non parce que leur fournisseur cloud était peu sûr, mais à cause de leur propre mauvaise configuration (buckets S3 publics, règles de partage Salesforce trop permissives).

Les amendes sont réelles et significatives. Les sanctions maximales du RGPD atteignent 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu (c'est un plafond légal, pas une amende typique ; les amendes réelles varient beaucoup selon le cas et la gravité, d'après les données d'application du Comité européen de la protection des données). Les amendes CCPA/CPRA sont plus faibles par violation (environ 2 500 $ par violation non intentionnelle, 7 500 $ par violation intentionnelle, montants fixés par la loi californienne et sujets à ajustement périodique) mais se multiplient vite à l'échelle des données consommateurs, puisque chaque individu concerné peut compter comme une violation distincte.

La checklist d'audit pratique

Pour un responsable data ou produit qui évalue la maturité privacy d'un SaaS, passez en revue :

• Pouvez-vous produire un data map complet montrant où résident les données personnelles, en une journée et non en une semaine ?
• Avez-vous un workflow DSAR documenté et testé, avec un owner et un SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète → ?
• Les durées de conservation sont-elles appliquées par des jobs automatisés, et pas seulement par un texte de politique ?
• Avez-vous des DPA signés avec chaque sous-traitant qui touche à des données personnelles (paiement, CRM, analytics, email, outils de support) ?
• L'accès warehouse aux PII brutes est-il restreint par rôle et journalisé ?
• Avez-vous une base légale documentée pour chaque catégorie de traitement ?

Points clés

• Une DSAR est un problème de systèmes avant d'être un problème juridique : vous devez résoudre l'identité entre des systèmes de paiement, CRM, event et warehouse qui partagent rarement une clé commune.
• « Supprimer » n'est pas absolu. Les obligations légales de conservation (fiscales, comptables) peuvent primer sur les demandes d'effacement ; documentez les exceptions plutôt que de tout supprimer ou de ne rien supprimer.
• Le RGPD et le CCPA/CPRA diffèrent dans leurs mécanismes (délais, structures d'amendes, autorités) mais tous deux exigent que vous sachiez quelles données vous détenez et pourquoi, ce qui relève fondamentalement de la data governance.
• Les contrats fournisseurs (DPA avec Stripe, Salesforce, etc.) gèrent le risque juridique mais ne l'éliminent pas ; une mauvaise configuration de votre côté est une cause fréquente et bien réelle de sanction.
• Construisez tôt l'infrastructure ennuyeuse : un data map maintenu, des jobs de rétention automatisés et des audits d'accès coûtent moins cher que de les reconstituer sous le délai d'un régulateur.