Un éditeur SaaS B2B découvre souvent le RGPD par la porte commerciale : un prospect grand compte envoie un questionnaire sécurité de 200 lignes, demande le DPA, la liste des sous-traitants ultérieurs et la localisation des données, et le cycle de vente s'arrête tant que le dossier n'est pas complet. Le règlement ne s'applique pas qu'à vos clients : dès que votre logiciel héberge ou traite des données personnelles pour leur compte, il vous impose des obligations propres, et une responsabilité directe devant la CNIL. Ce guide reprend, article par article, ce qu'un éditeur doit tenir à jour, et ce que ses clients lui demanderont de prouver.
Pourquoi le RGPD concerne directement l'éditeur SaaS
Un logiciel en mode SaaS (Software as a Service) n'est pas installé sur les serveurs du client : il tourne sur l'infrastructure de l'éditeur, ou de son hébergeur, et le client y accède par internet. Les données saisies ou importées par le client, celles de ses salariés dans un SIRH, de ses clients et prospects dans un CRM, de ses patients dans un logiciel médical, sont donc stockées et traitées chez l'éditeur.
Le RGPD s'applique à ce traitement, et pas seulement au client. Depuis 2018, le sous-traitant a ses propres obligations (articles 28, 30, 32 et 33 notamment), il peut être sanctionné par l'autorité de contrôle (article 83) et voir sa responsabilité engagée par une personne lésée lorsqu'il n'a pas respecté les obligations qui lui incombent ou a agi en dehors des instructions du client (article 82). La CNIL l'a rappelé en sanctionnant un éditeur de logiciel de laboratoire, Dedalus Biologie, de 1,5 million d'euros en avril 2022, après la fuite des données d'environ 500 000 patients : l'éditeur était sous-traitant, et c'est lui qui a été sanctionné.
Le RGPD est aussi devenu un argument de vente. Pour un client DPO, choisir un SaaS revient à ajouter un sous-traitant à son registre, et il doit pouvoir démontrer qu'il l'a choisi parce qu'il présente des garanties suffisantes (article 28.1). L'éditeur qui fournit ces garanties sans délai raccourcit son cycle de vente.
Éditeur SaaS : sous-traitant, responsable de traitement ou responsable conjoint ?
Tout le reste découle de cette qualification : le contrat à signer, l'information des personnes, le registre à tenir. Elle se fait finalité par finalité, jamais pour le logiciel en bloc. Les lignes directrices 07/2020 de l'EDPB sur les notions de responsable du traitement et de sous-traitant posent la méthode, et la CNIL l'a appliquée au cloud dans sa publication du 28 mai 2026, « Quelles qualifications pour les acteurs de l'informatique en nuage (cloud) ? », que nous avons analysée à sa sortie.
Le cas général : le client est responsable, l'éditeur est sous-traitant
Le client détermine les finalités et les moyens essentiels du traitement : il choisit le prestataire, paramètre l'outil, décide des données qu'il y verse. L'éditeur traite ces données sur ses instructions. La CNIL précise que le fait que le fournisseur décide de la plupart des moyens techniques ne suffit pas à en faire un responsable de traitement. Dans un CRM, les données des clients et prospects de l'entreprise utilisatrice relèvent de ce cas : l'éditeur est sous-traitant.
Quand l'éditeur devient responsable de ses propres traitements
L'éditeur reste responsable de traitement pour ce qu'il fait pour son propre compte : la gestion des comptes et des identifiants de connexion des utilisateurs, la facturation, la prospection, le support quand il en fixe seul les règles, et la sécurité « du » nuage (journaux d'accès, télémétrie, protection de son infrastructure). La CNIL ajoute un cas fréquent : l'amélioration du service décidée à l'initiative du fournisseur, pour ses propres besoins, sur des données générées par plusieurs clients et sans que ceux-ci puissent donner d'instructions. L'éditeur est alors responsable de ce traitement, ce qui suppose une base légale, une information des personnes et une ligne dans son propre registre.
C'est le point à surveiller avec les fonctionnalités d'IA : réutiliser les données des clients pour entraîner ou affiner un modèle n'est pas une instruction du client. L'article 28.10 est sans ambiguïté : un sous-traitant qui détermine lui-même les finalités et les moyens d'un traitement est considéré comme responsable de ce traitement.
La responsabilité conjointe, plus rare qu'on ne le croit
Elle suppose que l'éditeur et le client décident ensemble des objectifs et des caractéristiques essentielles d'un traitement qui profite aux deux. L'exemple de la CNIL : une entreprise et un éditeur SaaS de gestion de tickets qui adaptent ensemble la priorisation des demandes pour un secteur, en choisissant ensemble les données et les critères. Dans ce cas, l'article 26 impose un accord de responsabilité conjointe qui répartit les obligations, notamment l'information des personnes et la réponse à leurs demandes, et dont les grandes lignes sont mises à leur disposition.
Le DPA : le contrat de l'article 28, clause par clause
Pour chaque traitement réalisé comme sous-traitant, l'éditeur doit signer avec son client un contrat de sous-traitance, le Data Processing Agreement (DPA). L'article 28.3 en fixe le contenu minimal : l'objet, la durée, la nature et la finalité du traitement, le type de données et les catégories de personnes concernées, puis les engagements du sous-traitant :
- ne traiter les données que sur instruction documentée du client, y compris pour les transferts hors de l'Union, et l'alerter si une instruction lui paraît contraire au RGPD ;
- soumettre les personnes autorisées à traiter les données à une obligation de confidentialité ;
- mettre en œuvre les mesures de sécurité de l'article 32 ;
- ne recourir à un sous-traitant ultérieur qu'avec l'autorisation écrite du client, et lui imposer les mêmes obligations ;
- aider le client à répondre aux demandes d'exercice des droits et à respecter ses obligations de sécurité, de notification des violations et d'analyse d'impact ;
- supprimer ou restituer les données à la fin du contrat, au choix du client ;
- mettre à disposition les informations nécessaires pour démontrer la conformité, et permettre des audits, y compris des inspections.
Les clauses qui se négocient le plus avec les grands comptes sont connues : le droit d'audit sur site, le délai de notification des violations, le plafond de responsabilité, le sort des données en fin de contrat. Nous les avons détaillées dans les 12 clauses pièges d'un DPA. Un éditeur gagne du temps en publiant un DPA standard, aligné sur l'article 28, plutôt qu'en signant le modèle de chaque client.
Ce que vos clients grands comptes vont vous demander
Un DPO qui référence un nouveau SaaS doit documenter son choix. Côté éditeur, cela se traduit par un dossier de preuves, demandé avant la signature puis à chaque renouvellement.
La liste des sous-traitants ultérieurs, tenue à jour
Hébergeur, outil de support, service d'envoi d'e-mails, prestataire de supervision : chacun traite des données du client. L'article 28.2 impose l'autorisation écrite préalable du client, spécifique ou générale. En cas d'autorisation générale, l'éditeur doit informer le client de tout ajout ou remplacement, pour lui laisser la possibilité de s'y opposer. En pratique : une page publique des sous-traitants ultérieurs, avec leur pays et leur rôle, et une procédure de notification avant tout changement. L'article 28.4 précise que l'éditeur reste pleinement responsable devant son client des manquements de ses propres sous-traitants.
Le questionnaire sécurité, et les preuves qui l'accompagnent
Il reprend les mesures de l'article 32 : chiffrement, gestion des accès, journalisation, sauvegardes, tests de restauration, gestion des vulnérabilités, cloisonnement des données entre clients. La CNIL distingue utilement deux niveaux : la sécurité « du » nuage, qui relève du fournisseur, et la sécurité « dans » le nuage, que le client configure (droits d'accès de ses utilisateurs, chiffrement de ses données). Un questionnaire bien rempli dit clairement qui fait quoi. Notre guide sur comment remplir un questionnaire sécurité et RGPD détaille la méthode. Une certification (ISO 27001, rapport SOC 2) n'en dispense pas, mais répond à une partie des questions.
La procédure de notification des violations
L'article 33.2 oblige le sous-traitant à notifier toute violation de données au client « dans les meilleurs délais après en avoir pris connaissance ». C'est le client qui notifie la CNIL dans les 72 heures : chaque heure perdue chez l'éditeur est prise sur son délai. Les grands comptes demandent donc un délai contractuel court, souvent 24 ou 48 heures, et le contenu minimal de l'alerte.
Le registre des activités de traitement côté sous-traitant
L'article 30.2 impose au sous-traitant un registre distinct de celui du responsable : le nom et les coordonnées de chaque client pour le compte duquel il agit, les catégories de traitements effectués, les transferts hors Union et une description générale des mesures de sécurité. L'exemption des organismes de moins de 250 salariés (article 30.5) ne joue presque jamais pour un éditeur SaaS : elle tombe dès que le traitement n'est pas occasionnel, ce qui est le principe même d'un logiciel en service continu. Les traitements dont l'éditeur est responsable, eux, vont dans son registre des traitements de responsable.
Le DPO, quand il est obligatoire
L'article 37 s'applique aussi aux sous-traitants : un DPO est obligatoire lorsque les activités de base consistent en un suivi régulier et systématique de personnes à grande échelle, ou en un traitement à grande échelle de données sensibles. Un éditeur de logiciel médical ou de suivi d'activité y est souvent soumis, et ses clients demanderont ses coordonnées.
Hébergement et transferts hors UE : DPF, CCT, Cloud Act
La localisation des données est la première question d'un DPO, et la réponse ne se limite pas au pays du datacenter : elle porte sur toute la chaîne de sous-traitants, support et supervision compris.
- Hébergement dans l'Union : aucun transfert à encadrer, à condition qu'aucun sous-traitant ultérieur n'accède aux données depuis un pays tiers.
- Transfert vers les États-Unis : la décision d'adéquation du 10 juillet 2023 couvre les entreprises américaines certifiées au Data Privacy Framework. Le Tribunal de l'Union a rejeté le recours en annulation de Philippe Latombe le 3 septembre 2025 (affaire T-553/23), mais le cadre reste exposé à un nouveau contentieux. Vérifier la certification de chaque prestataire sur la liste officielle du DPF.
- Autres pays tiers, ou prestataire non certifié : clauses contractuelles types de la Commission (décision d'exécution 2021/914 du 4 juin 2021) et analyse d'impact du transfert, selon les recommandations 01/2020 de l'EDPB.
Reste la question du Cloud Act : une loi américaine de 2018 qui permet aux autorités des États-Unis d'exiger d'un fournisseur soumis à leur juridiction des données qu'il contrôle, même stockées en Europe. Un hébergement européen chez un fournisseur américain ne règle donc pas tout, et les clients publics ou sensibles le savent. Pour les données de santé, l'hébergement doit en outre être certifié HDS (article L.1111-8 du Code de la santé publique).
Privacy by design : des fonctionnalités qui aident vos clients à être conformes
L'article 25 vise le responsable de traitement, mais c'est l'éditeur qui conçoit l'outil, et ses clients ne peuvent être conformes que si le logiciel le permet. Le privacy by design se traduit en fonctionnalités concrètes :
- des champs limités et typés plutôt que des zones de texte libre, où finissent des données sensibles que personne n'a voulu collecter ;
- des durées de conservation paramétrables, avec purge automatique ;
- l'export des données d'une personne et leur suppression ciblée, pour répondre aux demandes d'accès, d'effacement et de portabilité ;
- une gestion fine des rôles et des droits d'accès, et des journaux consultables par le client ;
- un cloisonnement strict entre clients dans une architecture multi-tenant.
Chacune de ces fonctionnalités répond par avance à une ligne du questionnaire sécurité.
Organiser la conformité d'un éditeur SaaS sans y passer ses semaines
Le travail est le même pour tous les éditeurs : qualifier chaque traitement, tenir deux registres, maintenir la liste des sous-traitants ultérieurs, répondre aux questionnaires et aux audits, notifier vite en cas d'incident. Ce qui change, c'est le temps qu'on y passe. Le guide RGPD du sous-traitant B2B reprend ces obligations pour tout prestataire, et notre livre blanc SaaS et RGPD les déroule pas à pas pour un éditeur.
Leto tient les registres et la cartographie des sous-traitants dans un même logiciel RGPD, et Hari, notre IA, prépare les réponses aux questionnaires sécurité à partir de ce qui est déjà documenté. Pour voir comment, demandez une démo.
Questions fréquemment posées
Un éditeur SaaS est-il sous-traitant ou responsable de traitement ?
Les deux, selon la finalité. Pour les données que le client verse dans le logiciel et traite selon ses propres objectifs, l'éditeur est en principe sous-traitant (article 28). Pour ses traitements propres, comptes utilisateurs, facturation, sécurité de son infrastructure, amélioration du service décidée seul sur les données de plusieurs clients, il est responsable de traitement. La CNIL a détaillé cette grille dans sa publication du 28 mai 2026 sur les acteurs du cloud.
Que doit contenir au minimum le DPA d'un éditeur SaaS ?
Les mentions de l'article 28.3 du RGPD : objet, durée, nature et finalité du traitement, types de données et catégories de personnes, traitement sur instruction documentée, confidentialité, mesures de sécurité de l'article 32, conditions de recours aux sous-traitants ultérieurs, assistance au client pour les droits des personnes et les violations, suppression ou restitution des données en fin de contrat, et droit d'audit.
Un éditeur SaaS de moins de 250 salariés doit-il tenir un registre ?
Presque toujours. L'exemption de l'article 30.5 ne s'applique pas lorsque le traitement n'est pas occasionnel, ce qui est le cas d'un logiciel utilisé en continu, ni lorsqu'il porte sur des données sensibles. Comme sous-traitant, l'éditeur tient le registre de l'article 30.2, qui liste notamment ses clients, les catégories de traitements, les transferts hors Union et ses mesures de sécurité.
Dans quel délai un éditeur SaaS doit-il signaler une violation de données à son client ?
L'article 33.2 impose une notification « dans les meilleurs délais » après en avoir pris connaissance, sans fixer de nombre d'heures. Le client, responsable de traitement, doit notifier la CNIL dans les 72 heures : le DPA fixe donc souvent un délai contractuel plus court, de 24 à 48 heures, et le contenu attendu de l'alerte.
Peut-on héberger les données de ses clients chez un fournisseur américain ?
Oui, à condition d'encadrer le transfert : certification du fournisseur au Data Privacy Framework (décision d'adéquation du 10 juillet 2023), ou clauses contractuelles types et analyse d'impact du transfert. Il faut aussi informer les clients, qui peuvent s'y opposer, et tenir compte du Cloud Act, qui permet aux autorités américaines de demander des données même stockées en Europe.
L'éditeur peut-il utiliser les données de ses clients pour entraîner son IA ?
Pas en tant que sous-traitant : ce n'est pas une instruction du client. S'il décide seul de cette réutilisation, il devient responsable de ce traitement (article 28.10) et doit disposer d'une base légale, informer les personnes et l'inscrire dans son registre. La voie la plus sûre reste de le prévoir explicitement dans le contrat, ou de s'en abstenir sur les données des clients.
