RGPD éditeurs SaaS : privacy by design, DPA, article 28

En décembre 2025, la CNIL a sanctionné coup sur coup deux éditeurs de logiciels. Ni l’un ni l’autre n’était responsable de traitement.

Mobius Solutions, d’abord : 1 million d’euros. L’entreprise éditait la solution technique utilisée par Deezer pour ses campagnes publicitaires personnalisées, sans décider ni des finalités ni des données collectées. Il lui a été reproché d’avoir conservé une copie des données de plus de 46 millions d’utilisateurs après la fin du contrat, de les avoir exploitées pour améliorer ses propres services sans instruction de son client, et de n’avoir tenu aucun registre en qualité de sous-traitant. Trois manquements purement contractuels et documentaires.

11 jours plus tard, Nexpublica France écopait de 1,7 million d’euros. Même position dans la chaîne : éditeur d’un progiciel de gestion de la relation usagers dans l’action sociale, utilisé notamment par des MDPH. Le reproche, lui, était technique. Des vulnérabilités relevant de principes élémentaires de sécurité, identifiées par ses propres audits, n’ont été corrigées qu’après les fuites. La CNIL a retenu comme circonstance aggravante que la société est un professionnel du logiciel.

2 manquements de nature opposée, une même logique : dans aucun des deux cas l’autorité n’a fait porter la responsabilité sur le client donneur d’ordre, pourtant responsable de traitement. Elle a sanctionné directement l’éditeur, au titre des obligations que l’article 28 du RGPD fait peser sur le sous-traitant.

Le message est désormais sans ambiguïté. L’éditeur SaaS n’est pas un fournisseur neutre qui livre un outil et se lave les mains de ce qui s’y passe. C’est un acteur de la chaîne de traitement, directement sanctionnable. Beaucoup de dirigeants d’éditeurs l’ignorent, persuadés que la conformité incombe uniquement à leurs clients. Structurer cette conformité relève souvent d’un accompagnement par un DPO externe, surtout quand l’organisme n’a pas de compétences relatives à la protection des données en interne.

L’essentiel Un éditeur SaaS est presque toujours sous-traitant au sens de l’article 28 du RGPD : il traite des données pour le compte de ses clients, qui restent responsables de traitement. Cette qualification lui impose des obligations propres, directement sanctionnées par la CNIL, autour de 3 piliers : le privacy by design and security dans le produit (article 25), un DPA solide avec chaque client (article 28), et l’encadrement de l’hébergement et des sous-traitants ultérieurs. Bien menée, cette conformité devient un argument commercial face aux clients qui doivent eux-mêmes auditer leurs prestataires.

Cet article s’adresse aux éditeurs qui veulent comprendre ce que l’article 28 exige d’eux, concrètement.

Éditeur SaaS : responsable de traitement ou sous-traitant ?

La distinction commande tout le reste, et elle se tranche sur un critère : qui décide de la finalité du traitement ?

Le client, celui qui utilise le logiciel pour gérer par exemple : sa paie, sa relation commerciale ou ses dossiers patients, détermine pourquoi les données sont traitées. Il est responsable de traitement. L’éditeur fournit l’outil qui exécute ces traitements pour le compte du client, sur instruction, sans décider des finalités. Cette position fait de lui un sous-traitant au sens de l’article 28 du RGPD.

Un basculement guette pourtant. Dès qu’un éditeur réutilise les données de ses clients pour son propre compte, entraînement d’un modèle, statistiques revendues, amélioration produit non prévue au contrat, il détermine une finalité nouvelle. Il devient responsable de traitement pour cette réutilisation, avec toutes les obligations qui s’y attachent. Une clause contractuelle mal rédigée suffit à franchir cette frontière sans s’en apercevoir.

Cette qualification de sous-traitant emporte des obligations propres, sanctionnées directement, indépendamment de celles du client. 3 piliers les structurent.

Pilier 1 : le privacy by design, dès le code

L’article 25 du RGPD impose d’intégrer la protection des données dès la conception du logiciel, pas de la greffer après coup. Pour un éditeur, ce principe descend jusque dans l’architecture du produit.

Le volet « par défaut » est celui que la CNIL sanctionne le plus, parce qu’il se constate facilement. Quelques exemples violent frontalement l’article 25(2) :

une case pré-cochée pour une newsletter,
un paramètre de partage activé sans action de l’utilisateur,
incapacité de suppression de profils pour des collaborateurs ne faisant plus partie de l’organisation,
Une stratégie de mot de passe faible et non conforme aux recommandations de la CNIL et de l’ANSSI,
une géolocalisation ouverte par défaut,
etc.

Google a été condamné à 50 millions d’euros en 2019, notamment pour des paramètres publicitaires pré-cochés à la création de compte. La règle pour un éditeur tient en une phrase : l’état par défaut du logiciel doit être le plus protecteur possible, à charge pour l’utilisateur d’élargir volontairement le traitement.

Le volet « dès la conception » se joue en amont, dans les choix techniques. 3 réflexes structurent une architecture conforme :

Minimisation : ne collecter que les champs strictement nécessaires à la fonction, résister au « on stocke tout, on verra plus tard ».
Sécurité : chiffrement des données au repos et en transit, cloisonnement entre les données de clients différents, gestion fine des habilitations.
Conservation : des mécanismes de purge automatique paramétrables par traitement, sujet que nous approfondissons dans notre article sur les durées de conservation des données personnelles.

Ce dernier point vaut avertissement. Quand la CNIL a sanctionné Discord de 800 000 euros en novembre 2022, l’un des manquements retenus visait la conservation de millions de comptes inactifs depuis plus de trois ans, sans politique de purge. La rétention des données ne peut pas rester un réglage manuel laissé à la bonne volonté de chaque client, elle doit être outillée dans le produit et fortement conseillée au client.

Un éditeur ne peut pas non plus se défausser sur ses clients. La sanction de Dedalus Biologie, en avril 2022, l’a rappelé sèchement : cet éditeur de logiciels de laboratoire a été condamné à 1,5 million d’euros pour des manquements aux articles 28, 29 et 32, notamment l’absence des mentions obligatoires dans ses contrats et des failles de sécurité connues mais non corrigées. L’éditeur qui conçoit le logiciel porte une responsabilité directe, il ne peut pas la renvoyer intégralement à l’utilisateur.

Le réflexe Pour chaque nouvelle fonctionnalité, posez la question en amont : quelles données sont réellement nécessaires, quel est leur cycle de vie, quel est l’état par défaut le plus protecteur ? La CNIL met à disposition un guide RGPD du développeur en 16 fiches, référence utile pour outiller ces choix côté technique.

Pilier 2 : le DPA, votre contrat de sous-traitance

Le DPA, ou data processing agreement, est le contrat écrit qu’impose l’article 28 entre le responsable de traitement et son sous-traitant, avant tout traitement. Pour un éditeur, c’est une des pièces qui encadre juridiquement la relation avec chaque client.

L’article 28 fixe entre autres huit obligations que ce contrat relatif à l’encadrement des rôles et responsabilités des acteurs doit contenir. Les voici, traduites côté éditeur.

Obligation (article 28.3)	Ce que l’éditeur s’engage à faire
Instructions documentées	Ne traiter les données que sur instruction écrite du client, jamais pour son propre compte
Confidentialité	Garantir que seules les personnes habilitées à traiter les données peuvent y accéder et qu’elles sont tenues au secret professionnel
Sécurité (article 32)	Mettre en œuvre des mesures techniques et organisationnelles adaptées au risque
Sous-traitance ultérieure	N’ajouter un sous-traitant qu’après en avoir informé le client et en avoir, le cas échéant, obtenu l’autorisation
Exercice des droits	Aider le client à répondre aux demandes des personnes concernées
Sécurité et notifications	Assister le client sur les violations et analyses d’impact
Sort des données	Supprimer ou renvoyer les données en fin de contrat
Auditabilité	Fournir les preuves de conformité et permettre les audits

La clause d’audit mérite qu’on s’y arrête, car elle est souvent mal anticipée. Vos clients ont le droit de vérifier votre conformité. Personne n’a envie de subir cinquante audits sur site par an, et la parade que les éditeurs matures adoptent tient en un document : un rapport de certification reconnu, SOC 2 Type II ou ISO 27001, qui vaut preuve de sécurité et évite les audits individuels. Un éditeur qui présente spontanément ce rapport à ses prospects transforme une contrainte contractuelle en signal de sérieux. Toutefois les certifications à elles seules ne suffisent pas. Les mesures annoncées doivent réellement être implémentées, maintenues et démontrables.

Attention au DPA générique, copié d’un modèle sans adaptation. Les autorités regardent la cohérence entre ce que le contrat annonce et les traitements mis en place. Un DPA qui promet un chiffrement absent, ou muet sur la localisation des données, se retourne contre l’éditeur le jour d’un contrôle. Le contrat doit refléter les pratiques techniques réelles, pas les décorer.

2 des 8 obligations concentrent le risque, et l’affaire Mobius le montre bien. Ce sous-traitant de Deezer a conservé une copie des données de 46 millions d’utilisateurs après la fin du contrat, et les a utilisées pour améliorer ses propres services sans instruction du client. La sanction d’un million d’euros repose précisément sur le manquement à l’obligation de suppression en fin de contrat (article 28.3.g) et sur l’utilisation des données hors instruction (article 29). Pour un éditeur, la leçon est double : purger effectivement les données d’un client parti, et ne jamais détourner des données confiées vers un usage non prévu au contrat, même avec de bonnes intentions produit.

Nous rappelons régulièrement à nos clients éditeurs qu’ils n’ont pas à accepter des finalités de traitement inexistantes parce que le client estime que cela évitera de mettre à jour le contrat lorsque le logiciel développé évoluera.

Pilier 3 : l’hébergement et les sous-traitants ultérieurs

Aucun éditeur SaaS ne fonctionne seul. Hébergeur cloud, service d’emailing, solution de paiement, outil d’analyse : chacun traite des données pour le compte de vos clients. Ce sont vos sous-traitants ultérieurs, et vous en répondez.

L’article 28 encadre strictement cette cascade. Vous ne pouvez recourir à un sous-traitant ultérieur qu’avec une information préalable et l’autorisation de vos clients. Vous devez également prévoir des mécanismes pour les informer de tout changement pour qu’ils puissent s’y opposer. Chaque maillon doit être lié par les mêmes obligations que celles que vous portez envers vos clients. Le DPA se propage en cascade : les garanties que vous donnez, vous devez les exiger de vos propres prestataires.

L’hébergement concentre le risque le plus visible. La localisation des serveurs détermine si un transfert hors Union européenne a lieu, avec les garanties supplémentaires que cela impose. Un éditeur qui héberge chez un fournisseur américain, même avec des serveurs en Europe, doit examiner la question de l’accès aux données par la maison mère et documenter les garanties applicables. C’est l’un des premiers points qu’un client averti vérifie avant de signer.

La sanction de Nexpublica, fin décembre 2025, a rappelé un principe que beaucoup ignoraient : l’obligation de sécurité de l’éditeur s’apprécie sévèrement, d’autant plus qu’il est un professionnel du logiciel. La CNIL a relevé des vulnérabilités connues, identifiées par des audits, mais laissées sans correction jusqu’à la fuite. Aux yeux de l’autorité, la chaîne de sous-traitance forme un tout, et son maillon le plus faible engage votre responsabilité. C’est la logique que nous détaillons côté donneur d’ordre dans notre article sur pourquoi auditer la conformité de vos sous-traitants, symétrie utile quand on est soi-même éditeur.

La conformité comme argument commercial

Voilà le renversement que les éditeurs les plus avisés ont compris. Dans un marché où la donnée inquiète, la conformité RGPD cesse d’être une case réglementaire pour devenir un différenciateur.

La mécanique est directe. Vos clients, responsables de traitement, sont eux-mêmes tenus d’auditer leurs sous-traitants. Un client qui choisit un logiciel de paie ou un CRM sait que son propre risque dépend du vôtre. Face à 2 solutions équivalentes, il retiendra celle qui présente le plus de garanties en matière de privacy by design and security et un encadrement qui lui permet de respecter des obligations légales. Votre conformité pèse dans sa décision, parfois même comme critère éliminatoire d’un appel d’offres.

Pour un éditeur, investir dans sa conformité revient donc à investir dans sa capacité de vente et son image de marque. Un calcul que les directions générales des éditeurs gagnent à s’approprier, au lieu de le reléguer au seul service juridique.

Les erreurs qui coûtent un contrat ou une amende

Les erreurs suivantes reviennent chez les éditeurs, et chacune coûte cher, en sanction comme en contrats perdus.

Croire que la conformité incombe au seul client. L’éditeur est sous-traitant, directement sanctionnable au titre de l’article 28. Dedalus, Mobius et Nexpublica en sont l’exemple.
Se défausser du privacy by design sur les utilisateurs. L’article 25 impose d’intégrer la protection dans le produit. Renvoyer cette charge aux clients ne protège pas l’éditeur. Par contre, le rappeler à votre client donnera une image qualitative de votre savoir-faire.
Proposer un DPA générique non aligné sur le produit. Un contrat qui promet des garanties absentes du logiciel se retourne en contrôle. Le DPA doit refléter les pratiques réelles.
Négliger la cascade de sous-traitance. Les sous-traitants ultérieurs doivent porter les mêmes obligations que vous. L’hébergeur défaillant engage votre responsabilité.
Ignorer la localisation des données. Un hébergement hors UE non documenté expose à un transfert illicite et ferme l’accès aux clients réglementés.

Structurer sa conformité d’éditeur, étape par étape

Mettre un éditeur SaaS en conformité ne se résume pas à faire signer un DPA. La démarche articule 4 chantiers :

Une maîtrise par les équipes techniques et développeurs des concepts de privacy by design and security est une des clés de la réussite de vos projets.Intégrer le privacy by design dans la roadmap produit, pas en correctif.
Bien comprendre le besoin du client et savoir lui expliquer qu’il ne respecte pas ses obligations légales en vous demandant d’être laxiste sur certaines obligations pour son confort.
Construire un DPA aligné sur les pratiques techniques réelles et les exigences/instructions exprimées par le client.
Documenter concrètement le développement et ne pas vous dire que le code se documente tout seul. ‘
Choisissez soigneusement vos sous-traitants qui deviendront les sous-traitants ultérieurs de vos clients et dont la responsabilité vous incombe.

Si votre solution n’a jamais fait l’objet d’un cadrage RGPD, un diagnostic de conformité identifie les écarts et les hiérarchise selon le risque, juridique comme commercial. Quand l’enjeu dépasse les ressources internes, en particulier pour un éditeur qui vise des marchés réglementés, notre accompagnement par un DPO externe construit ce cadre et le maintient au rythme du produit. L’entrée en application complète de l’AI Act, le 2 août 2026, ne fera qu’alourdir ces exigences pour les éditeurs qui embarquent de l’IA. Autant prendre l’avance maintenant.

Questions fréquentes

Un éditeur SaaS doit-il désigner un DPO ?

Pas systématiquement, mais souvent dans les faits. L’article 37 du RGPD rend le DPO obligatoire quand l’activité implique un suivi régulier et systématique des personnes à grande échelle, ou le traitement à grande échelle de données sensibles. Un éditeur dont la solution traite des volumes importants de données, ou des données de santé, bancaires ou judiciaires pour le compte de ses clients, entre généralement dans ce cadre. Nous détaillons les critères dans notre article sur les cas où vous serez obligé de nommer un DPO. Même hors obligation légale, s’appuyer sur un DPO structure la conformité et rassure les clients.

Combien de temps faut-il pour mettre un éditeur SaaS en conformité ?

Il n’y pas de bonne réponse à cette question. Le chantier dépendra souvent de l’existant et/ou du cahier des charges futur. Un éditeur qui part de zéro doit cartographier ses traitements, revoir son architecture pour intégrer le privacy by design, refondre ses DPA, et documenter sa chaîne de sous-traitance. Les chantiers techniques, purge automatique et cloisonnement notamment, s’inscrivent dans la roadmap produit et suivent le rythme d’un cycle de développement. La partie contractuelle avance plus vite, mais elle doit rester alignée sur les pratiques réelles, sous peine de créer un écart dangereux entre le DPA et le logiciel.

Un rapport SOC 2 suffit-il à prouver la conformité RGPD d’un éditeur ?

Non, il y contribue sans la garantir. Un rapport SOC 2 Type II ou une certification ISO 27001 démontre la solidité des mesures de sécurité, ce qui couvre une partie de l’article 32. Mais la conformité au RGPD dépasse la sécurité : bases légales, information des personnes, encadrement des sous-traitants ultérieurs, durées de conservation. Une certification est un élément probatoire solide, pas un quitus global. La CNIL rappelle qu’une certification couvre le produit, sans dispenser des obligations liées à son exploitation.

L’AI Act change-t-il quelque chose pour les éditeurs SaaS ?

Oui, pour ceux qui intègrent de l’intelligence artificielle. Le règlement européen sur l’IA ajoute des obligations selon le niveau de risque du système, en plus du RGPD. Un éditeur dont le logiciel embarque des fonctions d’IA traitant des données personnelles cumule les deux régimes : le RGPD sur les données, l’AI Act sur le système d’IA. Documentation, transparence et gestion des risques deviennent des exigences croisées. Les éditeurs qui anticipent cette double conformité prennent une avance difficile à rattraper.

À propos de cet article

Cet article a été rédigé par les consultants de Nouvel Horizon Conseil, cabinet spécialisé en protection des données et conformité RGPD. Nos missions incluent l’audit de conformité des sous-traitants, la rédaction et la revue de DPA, et l’accompagnement d’éditeurs de logiciels dans l’intégration du privacy by design à leur roadmap produit. Nous intervenons aussi bien côté responsable de traitement, pour auditer une chaîne de prestataires, que côté éditeur, pour préparer une solution SaaS aux exigences de clients réglementés.

Les sanctions citées proviennent des délibérations publiées par la CNIL : Mobius Solutions (SAN-2025-014, 11 décembre 2025), Nexpublica France (SAN-2025-015, 22 décembre 2025), Dedalus Biologie (SAN-2022-009, 15 avril 2022), Discord (SAN-2022-020, 10 novembre 2022) et Google (SAN-2019-001, 21 janvier 2019). Les obligations décrites renvoient aux articles 25, 28, 29, 30, 32 et 37 du RGPD.

Contenu à jour au regard de la réglementation applicable en juillet 2026. Cet article a une vocation informative et ne constitue pas un conseil juridique individualisé. Pour une analyse adaptée à votre solution, contactez-nous.