Pourquoi votre SaaS B2B a besoin d’un DPA dès le premier client
Vous venez de signer votre premier client entreprise. Vous avez un contrat, des CGV, peut-être des CGU. Vous pensez être couvert.
Pas tout à fait. Si votre SaaS traite des données personnelles pour le compte de ce client, et c’est le cas de la quasi-totalité des SaaS B2B, il manque un document à votre stack juridique : le Data Processing Agreement, ou DPA.
Ce n’est pas un document réservé aux grands comptes. Ce n’est pas une formalité qu’on règle « quand on scale ». C’est une obligation légale qui s’applique dès le premier euro facturé à un client professionnel, dès la première donnée traitée pour son compte.
Ce qu’est un DPA et ce qu’il n’est pas
Le DPA est le contrat qui encadre la relation entre un responsable de traitement et son sous-traitant au sens du RGPD. Il est imposé par l’article 28 du règlement, sans seuil de taille, sans exception pour les startups, sans délai de grâce.
Dans la relation SaaS B2B classique, la répartition est simple : votre client est responsable de traitement, c’est lui qui décide pourquoi et comment les données de ses utilisateurs, salariés ou prospects sont collectées. Vous êtes son sous-traitant, vous traitez ces données pour lui, selon ses instructions, dans le cadre du service que vous lui fournissez.
Cette relation crée des obligations précises pour les deux parties et le DPA les formalise.
Le DPA n’est pas une politique de confidentialité, ce n’est pas une clause dans vos CGV, et ce n’est pas un document qu’on peut remplacer par une déclaration de bonne intention. Un DPA absent ou mal rédigé expose les deux parties, votre client autant que vous.
Pourquoi le DPA concerne votre SaaS dès le premier client
La question n’est pas de savoir si votre client vous le demande mais de savoir si vous traitez des données personnelles pour son compte. Si la réponse est oui, et pour un SaaS B2B, elle l’est presque toujours, l’obligation existe indépendamment de toute demande.
Concrètement : un SaaS de gestion de projet qui héberge les données des équipes de son client, un outil d’emailing qui envoie des communications pour le compte d’un client, une solution RH qui centralise les données de salariés tiers, un CRM qui stocke les contacts commerciaux d’une entreprise cliente : tous ces cas créent une relation sous-traitant/responsable de traitement qui exige un DPA.
La taille du client ne change rien à l’obligation. Une PME de 10 personnes qui vous confie ses données clients est un responsable de traitement au même titre qu’un grand groupe. Et vous êtes leur sous-traitant au même titre, avec les mêmes obligations contractuelles.
Les trois situations où l’absence de DPA vous expose vraiment
Le client qui pose la question. Même une petite entreprise peut avoir un DSI, un conseil juridique, ou simplement un dirigeant qui a lu quelque chose sur le RGPD. « Vous avez un DPA ? ». Si la réponse est non, le deal peut capoter. Si la réponse est « c’est quoi ça », le deal capote systématiquement. Et de plus en plus de PME posent cette question, pas seulement les grands comptes.
La levée de fonds. La due diligence juridique d’un investisseur couvre systématiquement la conformité RGPD depuis plusieurs années. Un SaaS B2B sans DPA standardisé est un signal rouge qui ralentit ou bloque le processus. Pas parce que l’investisseur est pointilleux, parce qu’il évalue votre exposition au risque réglementaire et la solidité de votre relation client.
Un incident de sécurité. En cas de violation de données impliquant les données d’un client, l’absence de DPA aggrave considérablement la situation des deux parties. Sans DPA, il n’existe pas de cadre contractuel définissant les responsabilités, les obligations de notification, et les mesures de sécurité attendues. La CNIL peut sanctionner les deux : le client pour ne pas avoir encadré son sous-traitant, vous pour avoir traité des données sans cadre légal.
Ce que votre DPA doit couvrir
Un DPA conforme à l’article 28 RGPD n’est pas un document libre, son contenu est en grande partie imposé par le règlement et certains éléments sont non négociables.
L’objet et la durée du traitement. Qu’est-ce que vous traitez, pourquoi, et pendant combien de temps. Ces éléments doivent être précis et correspondre à votre produit réel, pas copiés d’un template générique.
La nature des traitements et les catégories de données. Quelles opérations effectuez-vous sur les données de votre client, et sur quels types de données : données courantes, données sensibles, données de mineurs ? Chaque catégorie implique des exigences différentes.
Les obligations et droits du responsable de traitement. Ce que votre client peut et ne peut pas vous demander de faire avec ses données.
Les sous-traitants ultérieurs. C’est le point le plus souvent négligé. Chaque outil tiers que vous utilisez pour faire tourner votre SaaS est un sous-traitant ultérieur que vous devez avoir encadré et déclaré. Sans cette liste tenue à jour, votre DPA est incomplet et votre client peut légitimement refuser de signer.
Les mesures de sécurité. Votre DPA doit les décrire ou y renvoyer précisément, pas renvoyer vaguement à « des mesures appropriées ».
L’assistance pour les droits des personnes. Vous devez être en mesure d’aider votre client à répondre aux demandes de ses utilisateurs : accès, rectification, effacement. Ça suppose que votre architecture le permette techniquement.
Ce que le DPA ne dit pas, c’est comment formuler tout cela de façon juridiquement solide, adaptée à votre stack et acceptable par vos clients. C’est là que la rédaction devient un vrai sujet.
Les erreurs les plus fréquentes dans les DPA de SaaS
Une clause DPA dans les CGV est insuffisante. Le DPA doit être un document distinct, signé ou accepté formellement, qui peut être mis à jour indépendamment de vos conditions générales.
Un DPA générique copié-collé. Un DPA qui ne mentionne pas vos sous-traitants réels, vos mesures de sécurité effectives, ou les types de données que vous traitez réellement n’a aucune valeur juridique. Un client ou un auditeur averti le verra immédiatement.
L’absence de liste des sous-traitants ultérieurs. C’est le point le plus souvent négligé. Vous utilisez AWS, Stripe, Intercom, Sentry : chacun est un sous-traitant ultérieur que vous devez avoir encadré et déclaré. Sans cette liste, votre DPA est incomplet au regard de l’article 28.3.d.
Un DPA figé. Votre stack technique évolue. Votre DPA doit évoluer avec elle, et prévoir un mécanisme de notification de vos clients en cas de changement de sous-traitant ultérieur.
Ce que cet article ne fait pas à votre place
Identifier les traitements spécifiques que votre SaaS effectue pour le compte de ses clients, rédiger les clauses adaptées à votre architecture technique, lister vos sous-traitants ultérieurs avec les garanties contractuelles associées : c’est une analyse qui dépend de votre produit, de vos clients, et de votre stack.
Un modèle de DPA conforme à l’article 28 du RGPD, adapté aux éditeurs SaaS B2B et personnalisable selon votre contexte, c’est exactement ce que Celestial Guardian peut vous aider à construire.
L’analyse, le cadrage juridique et les choix éditoriaux de cet article relèvent d’un travail humain. La rédaction a bénéficié d’une assistance par IA, intégralement relue, corrigée et validée par l’auteure.
Rédigé par Anne-Sophie | Fondatrice de Celestial Guardian & Juriste en droit du numérique
Certifiée CIPP/E (IAPP) et forte de 15 ans d’expérience au cœur d’écosystèmes fortement réglementés, j’aide les entreprises du numérique et les dirigeants tech à sécuriser leurs usages : ingénierie contractuelle, conformité RGPD & AI Act et gouvernance opérationnelle. Une approche de terrain pour transformer la contrainte juridique en levier stratégique.