+150 XP

Les lois sur la protection des données qui régissent réellement vos contrats SaaS

Un responsable achats d'une société de logistique de taille moyenne valide un nouveau vendor SaaS pour l'optimisation des tournées. Le vendor est basé en Irlande, les données incluent l'historique de localisation des chauffeurs, et la base clients s'étend de la Californie à Sao Paulo et Berlin. Personne n'a demandé la revue du Data Processing Agreement (DPA). Six mois plus tard, une demande d'accès d'une personne concernée arrive, et le service juridique découvre que le DPA ne comporte ni liste de sous-traitants ultérieurs, ni clause de notification de violation, ni mécanisme de transfert licite. Ce n'est pas un cas d'école. C'est le mode de défaillance le plus fréquent dans les achats SaaS, et il survient parce que la plupart des acheteurs non juristes n'apprennent jamais ce que ces lois exigent concrètement à l'intérieur d'un contrat.

Cette leçon parcourt les trois régimes réglementaires qui façonnent presque tous les DPA SaaS que vous rencontrerez : le RGPD (Europe), le CCPA/CPRA (Californie) et la LGPD (Brésil). Vous verrez quelles clauses chacun impose dans un accord, afin de repérer une lacune avant qu'elle ne devienne un risque.

Pourquoi le droit de la protection des données vit dans vos contrats, et pas seulement dans votre classeur de conformité

Les réglementations sur la protection des données ne se contentent pas de dire aux entreprises « protégez les données ». Elles imposent des mécanismes contractuels précis entre l'entreprise qui collecte les données (le responsable de traitement, ou dans le langage du CCPA, la « business ») et le vendor SaaS qui les traite pour son compte (le sous-traitant, ou « service provider »).

Ce mécanisme, c'est le DPA : un avenant contractuel qui accompagne le master service agreement (MSA) et définit comment le vendor peut utiliser, stocker et partager les données personnelles. Si votre vendor SaaS est incapable de produire un DPA, ou en produit un standard qui ignore la loi applicable à vos clients, c'est votre premier signal d'alerte.

RGPD : le modèle dont toutes les autres lois se sont inspirées

Le Règlement général sur la protection des données (RGPD), applicable depuis 2018 dans l'Espace économique européen, est contrôlé par les autorités nationales de protection des données (DPAs) de chaque État membre (par exemple la CNIL en France, le Garante en Italie), coordonnées par le Comité européen de la protection des données (EDPB).

Le RGPD exige que tout contrat entre un responsable de traitement et un sous-traitant comporte au minimum (article 28) :

  • L'objet et la durée du traitement : quelles données, pour combien de temps.
  • L'autorisation des sous-traitants ultérieurs : le vendor doit divulguer (ou obtenir le consentement pour) tout prestataire en aval qu'il utilise, comme AWS pour l'hébergement ou Twilio pour les notifications.
  • Le soutien aux droits des personnes concernées : le vendor doit aider le responsable de traitement à répondre aux demandes d'accès, de suppression et de portabilité dans les délais légaux (généralement un mois).
  • La notification des violations : le vendor doit informer le responsable de traitement « dans les meilleurs délais » après avoir pris connaissance d'une violation, puisque le responsable dispose de son propre délai de 72 heures pour notifier la DPA compétente.
  • Le mécanisme de transfert international : si les données quittent l'EEE, le contrat a besoin d'une base légale telle que les clauses contractuelles types (SCCs), le modèle approuvé par la Commission européenne pour les transferts transfrontaliers.

Les amendes RGPD peuvent atteindre 4 % du chiffre d'affaires annuel mondial ou 20 millions d'euros, le montant le plus élevé étant retenu. En 2025, le cumul des amendes RGPD dans l'UE est estimé (selon le GDPR Enforcement Tracker, une base de données publique gratuite) à bien plus de 5 milliards d'euros depuis 2018, Meta, Amazon et Google figurant parmi les sanctions individuelles les plus lourdes.

Indice pratique : si le DPA d'un vendor SaaS ne fait aucune référence aux SCCs alors que le vendor héberge les données aux États-Unis, il y a une lacune de mécanisme de transfert. Depuis l'arrêt *Schrems II* de 2020 qui a invalidé le cadre Privacy Shield, les SCCs (ou le plus récent EU-US Data Privacy Framework, adopté en 2023) constituent la principale voie licite.

CCPA/CPRA : l'approche californienne du contrat sous un autre nom

Le California Consumer Privacy Act (CCPA), élargi ensuite par le California Privacy Rights Act (CPRA) entré en vigueur en 2023, est appliqué par la California Privacy Protection Agency (CPPA), le premier régulateur américain exclusivement dédié à la protection des données.

Le CCPA/CPRA n'utilise pas le vocabulaire « responsable de traitement / sous-traitant ». À la place : la « business » collecte les données, et tout vendor SaaS est un « service provider » (ou, s'il utilise les données à ses propres fins, un « third party », ce qui déclenche des règles plus strictes).

Les contrats avec les service providers doivent inclure :

  • Une restriction limitant l'usage des données par le vendor uniquement à la finalité prévue au contrat, et non à l'amélioration de son propre produit ou au ciblage publicitaire, sauf divulgation distincte.
  • Une interdiction pour le vendor de vendre ou partager les données personnelles au sens de la loi (la définition du « sharing » dans le CPRA couvre désormais explicitement la publicité comportementale multicontexte).
  • Des droits d'audit permettant à la business de vérifier la conformité du vendor.
  • L'obligation pour le vendor d'informer la business s'il n'est plus en mesure de respecter ses obligations.

Indice pratique : les conditions standard de nombreux vendors SaaS stipulent « nous pouvons utiliser des données agrégées pour améliorer nos services ». Sous le CPRA, si cette agrégation touche des données personnelles sans être correctement dé-identifiée selon le standard légal, la clause entre en conflit avec les restrictions applicables aux service providers. C'est l'un des points de redline les plus fréquents dans les contrats SaaS de l'ère 2026.

Contrairement au RGPD, le CCPA/CPRA ouvre aussi aux résidents californiens un droit d'action privé pour certaines violations de données : les consommateurs, et pas seulement le régulateur, peuvent poursuivre. Cela renforce l'enjeu des clauses de sécurité de votre DPA (standards de chiffrement, délais de réponse aux incidents).

LGPD : la loi brésilienne inspirée du RGPD, avec ses propres moyens de pression

La Lei Geral de Proteção de Dados (LGPD), en vigueur depuis 2020, est appliquée par l'Autoridade Nacional de Proteção de Dados (ANPD) brésilienne. Elle reprend de près la structure du RGPD (responsable de traitement / sous-traitant, bases légales, droits des personnes concernées) mais avec des exigences propres au Brésil :

  • Les accords de traitement doivent préciser la base légale invoquée (la LGPD compte dix bases légales, proches mais non identiques aux six du RGPD).
  • L'ANPD peut infliger des amendes allant jusqu'à 2 % du chiffre d'affaires brésilien d'une entreprise, plafonnées à environ 50 millions de R$ (environ 10 millions USD, estimation dépendante du taux de change) par violation.
  • Les règles de transfert international sont encore en construction ; l'ANPD a publié ses orientations sur les clauses contractuelles types plus récemment que l'UE, de sorte que les modèles de DPA de nombreux vendors ignorent totalement le vocabulaire de transfert propre à la LGPD.

Indice pratique : un DPA qui traite le RGPD et le CCPA en détail mais se contente d'une ligne générique du type « nous respectons également le droit brésilien applicable » signale que le vendor n'a pas réellement construit de mécanique spécifique à la LGPD. Si vous avez des clients brésiliens ou traitez des données de salariés brésiliens, cette lacune compte.

Vérification des acquis

1. Dans le scénario de la société de logistique, pourquoi l'absence de liste de sous-traitants ultérieurs, de clause de notification de violation et de mécanisme de transfert dans le DPA est-elle devenue un risque réel plutôt qu'une simple lacune administrative ?

2. Un responsable achats examine le DPA d'un vendor SaaS et constate qu'il s'agit d'un modèle générique, prêt-à-porter. Que doit-il en conclure ?

3. Pourquoi la distinction entre « responsable de traitement » et « sous-traitant » (ou « business » et « service provider » sous le CCPA) importe-t-elle lors de l'examen d'un contrat SaaS ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses concernant ce qu'un DPA correctement construit doit traiter au vu du scénario décrit dans la leçon.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses expliquant pourquoi un acheteur non juriste (comme un responsable achats) doit comprendre les exigences du droit de la protection des données avant de signer un contrat SaaS.

Sélectionnez toutes les réponses correctes.

Lire un DPA en acheteur, pas en juriste

Pas besoin d'un diplôme de droit pour repérer les grandes lacunes. Appliquez cette checklist à tout DPA de vendor SaaS :

  1. Nomme-t-il explicitement les lois applicables (RGPD, CCPA/CPRA, LGPD), ou reste-t-il vague (« lois applicables en matière de protection des données ») ? Un langage vague signale souvent une conformité non éprouvée.
  2. Y a-t-il une liste de sous-traitants ultérieurs, et le vendor s'engage-t-il à vous prévenir avant d'en ajouter de nouveaux ? (Vérifiez si des entreprises comme Snowflake, Stripe ou Twilio apparaissent comme sous-traitants intégrés : c'est normal, mais cela doit être divulgué.)
  3. Quel est le délai de notification des violations ? La pression du RGPD pousse les vendors vers 24 à 72 heures ; toute formulation vague (« rapidement ») doit être signalée.
  4. Existe-t-il un mécanisme de transfert transfrontalier si l'infrastructure du vendor se situe hors de la juridiction de vos clients ?
  5. Les droits d'audit sont-ils réels ou symboliques ? Certains DPA n'autorisent l'audit qu'à travers la certification tierce du vendor (comme SOC 2 ou ISO 27001) plutôt qu'une inspection directe. C'est courant et souvent acceptable, mais vous devez savoir quel modèle vous obtenez.

Une référence publique utile pour comparer la rédaction des clauses est le centre de ressources de l'IAPP (International Association of Privacy Professionals), qui publie gratuitement des explications sur la structure des DPA et les mécanismes de transfert transfrontalier.

Points clés

  • Le RGPD, le CCPA/CPRA et la LGPD n'imposent pas seulement des amendes : ils dictent des clauses précises (divulgation des sous-traitants ultérieurs, délais de notification des violations, mécanismes de transfert, restrictions d'usage) qui doivent figurer dans les DPA SaaS.
  • L'article 28 du RGPD est le modèle autour duquel la plupart des DPA mondiaux sont construits ; cherchez des SCCs ou un mécanisme de transfert équivalent dès que les données quittent l'EEE.
  • Le CCPA/CPRA reformule la relation en business / service provider et interdit spécifiquement aux vendors d'utiliser les données clients à leurs propres fins ou de les « partager » à des fins de publicité comportementale.
  • La LGPD reprend la structure du RGPD mais dispose de ses propres bases légales et d'un cadre de transfert plus récent, moins mature ; une formule générique du type « nous respectons le droit brésilien » est un signal d'alerte.
  • Les DPA non conformes se repèrent généralement par l'absence, pas par l'erreur : liste de sous-traitants manquante, délais de violation vagues et absence de mécanisme de transfert nommé sont les trois indices les plus rapides.