Par David Joseph Atias, avocat au Barreau de Paris · LinkedIn · Juillet 2026
Le DPA fournisseur SaaS arrive souvent en pièce jointe, présenté comme une simple formalité « à signer ». C’est une erreur. Cet accord de sous-traitance, exigé par l’article 28 du RGPD, engage la responsabilité du client face à la CNIL et aux personnes concernées. Or, le DPA standard de l’éditeur est rédigé pour protéger l’éditeur, pas le client. Transferts hors UE flous, responsabilité plafonnée, audit impossible, notification tardive : les déséquilibres sont nombreux. Cet article identifie les 7 clauses à renégocier en priorité, leur cadre juridique et les pièges à éviter pour signer un DPA réellement protecteur.
SOMMAIRE
- Pourquoi le DPA fournisseur SaaS est stratégique en 2026
- Le cadre juridique applicable
- Les 7 clauses à renégocier
- Tableau de synthèse des clauses
- Les 5 pièges à éviter
- Pourquoi faire appel à Atias Avocats
- FAQ — Questions fréquentes
1. Pourquoi le DPA fournisseur SaaS est stratégique en 2026
Le DPA fournisseur SaaS est devenu un document à enjeu majeur. Chaque outil SaaS qui traite des données personnelles en exige un. Trois dynamiques renforcent son importance en 2026.
1.1 La multiplication des sous-traitants SaaS
Une entreprise moyenne utilise entre 80 et 130 outils SaaS. Chacun traite potentiellement des données personnelles : clients, salariés, prospects. Chacun est donc un sous-traitant au sens du RGPD, qui exige un DPA. Cette multiplication crée un risque systémique : un seul maillon faible, un seul DPA déséquilibré, suffit à exposer l’entreprise. Le DPA n’est plus un document isolé, mais un élément d’une chaîne à sécuriser.
1.2 L’irruption de l’IA dans les outils SaaS
En 2026, les éditeurs SaaS ajoutent massivement des fonctionnalités d’IA. Ces fonctions traitent souvent les données du client pour entraîner ou alimenter des modèles. Cela soulève des questions inédites : les données servent-elles à entraîner l’IA de l’éditeur ? Le DPA l’autorise-t-il ? L’AI Act (Règlement UE 2024/1689) s’applique-t-il ? Le DPA doit désormais encadrer ces usages. Pour aller plus loin, consultez nos services en matière de protection des données personnelles.
2. Le cadre juridique applicable
Le DPA repose sur un socle juridique précis. Quatre fondements principaux déterminent son contenu obligatoire et sa portée.
2.1 L’obligation de l’article 28 du RGPD
L’article 28 du Règlement UE 2016/679 (RGPD) impose un contrat écrit entre le responsable de traitement et son sous-traitant. Ce contrat, le DPA, doit prévoir un contenu minimal : objet, durée, nature et finalité du traitement, type de données, obligations des parties. L’article 28 paragraphe 3 liste les mentions impératives. Un DPA qui n’en respecte pas le contenu est non conforme, ce qui engage la responsabilité du client responsable de traitement.
2.2 La sécurité et la notification (articles 32 à 34)
L’article 32 du RGPD impose des mesures techniques et organisationnelles de sécurité adaptées au risque. L’article 33 oblige à notifier une violation à la CNIL sous 72 heures. Le sous-traitant doit, lui, alerter le responsable de traitement « dans les meilleurs délais » (article 33 paragraphe 2). Le DPA doit donc préciser un délai d’alerte court et chiffré, faute de quoi le client ne pourra pas respecter son propre délai de 72 heures.
2.3 Les transferts hors UE (Schrems II)
Beaucoup d’éditeurs SaaS hébergent ou accèdent aux données depuis hors de l’Union européenne. L’arrêt Schrems II de la CJUE (C-311/18, 2020) impose, pour ces transferts, des clauses contractuelles types (décision UE 2021/914) et une analyse d’impact des transferts (Transfer Impact Assessment). Le DPA doit identifier précisément les pays de transfert et les garanties associées. Une clause vague sur ce point est un risque majeur.
3. Les 7 clauses à renégocier
Sept clauses concentrent l’essentiel du risque dans un DPA standard d’éditeur. Les renégocier en priorité protège efficacement le client responsable de traitement.
3.1 La sous-traitance ultérieure
La première clause encadre les sous-traitants de l’éditeur. Beaucoup de DPA autorisent une sous-traitance ultérieure libre, avec une simple information du client. Or, le client doit pouvoir s’opposer à un nouveau sous-traitant. La clause doit prévoir une autorisation préalable ou, a minima, un droit d’opposition effectif assorti d’un préavis. Il faut aussi exiger la liste à jour des sous-traitants et la répercussion des obligations du DPA sur eux.
3.2 Les transferts hors UE
La deuxième clause concerne les transferts internationaux. Le DPA standard reste souvent vague : « le sous-traitant peut transférer les données ». C’est insuffisant. La clause doit identifier les pays concernés, les garanties mobilisées (clauses contractuelles types), et l’existence d’une analyse d’impact des transferts. Après Schrems II, un transfert mal encadré expose directement le client. C’est l’un des points les plus sensibles de l’accord.
3.3 Les mesures de sécurité
La troisième clause porte sur la sécurité (article 32 du RGPD). Beaucoup de DPA renvoient à une annexe vague ou à une politique « susceptible d’évoluer ». Le client doit exiger des mesures précises et contraignantes : chiffrement, contrôle d’accès, journalisation, certifications (ISO 27001, SOC 2, HDS pour la santé). La clause doit interdire toute dégradation unilatérale du niveau de sécurité pendant la durée du contrat.
3.4 La notification des violations
La quatrième clause fixe le délai d’alerte. Le DPA standard prévoit souvent une notification « dans un délai raisonnable », ce qui est inexploitable. Le client doit imposer un délai court et chiffré, par exemple 24 à 48 heures, pour pouvoir respecter son propre délai de 72 heures envers la CNIL (article 33 du RGPD). La clause doit aussi préciser le contenu de l’alerte et l’assistance de l’éditeur à la gestion de l’incident.
3.5 Le droit d’audit
La cinquième clause organise le contrôle. L’article 28 du RGPD donne au client un droit d’audit. Or, beaucoup de DPA le réduisent à la simple remise d’un rapport de certification, sans audit réel. Le client doit conserver un droit d’audit effectif : audit sur site ou sur pièces, à intervalles raisonnables, ou via un tiers indépendant. La clause ne doit pas vider ce droit de sa substance, sous couvert de confidentialité.
3.6 La réversibilité des données
La sixième clause organise la fin du contrat. Le DPA doit prévoir la restitution des données dans un format exploitable, puis leur suppression certifiée chez l’éditeur et ses sous-traitants. Beaucoup de DPA restent flous sur le format, le délai et la preuve de suppression. Le client doit exiger des engagements précis. Cette clause s’articule avec la clause de réversibilité du contrat SaaS principal, à ne pas confondre avec elle.
3.7 La responsabilité
La septième clause est la plus disputée. Les éditeurs limitent souvent fortement leur responsabilité, parfois à quelques mois d’abonnement. Or, une violation de données peut coûter bien davantage. Le client doit négocier un plafond proportionné au risque, distinct du plafond du contrat commercial, et exclure de tout plafond les manquements graves au RGPD. Une clause limitative abusive peut d’ailleurs être contestée au titre de l’article 1170 du Code civil.
4. Tableau de synthèse des clauses
Le tableau ci-dessous synthétise les 7 clauses à renégocier dans un DPA standard, le risque du DPA standard et le niveau de criticité.
| Clause | Risque du DPA standard | Criticité |
|---|---|---|
| 1. Sous-traitance ultérieure | Recours libre, simple information | 🟠 Élevée |
| 2. Transferts hors UE | Clause vague post-Schrems II | 🔴 Critique |
| 3. Mesures de sécurité | Annexe vague, évolutive | 🔴 Critique |
| 4. Notification des violations | Délai « raisonnable » inexploitable | 🔴 Critique |
| 5. Droit d’audit | Réduit à un rapport | 🟠 Élevée |
| 6. Réversibilité des données | Format et suppression flous | 🟠 Élevée |
| 7. Responsabilité | Plafond abusivement bas | 🔴 Critique |
5. Les 5 pièges à éviter
Au-delà des clauses, plusieurs pièges récurrents fragilisent la position du client. Les identifier permet de signer un DPA réellement protecteur.
5.1 Signer le DPA standard sans le lire
Le premier piège est le réflexe de signature automatique. Le DPA arrive en pièce jointe, présenté comme une formalité, et il est signé sans analyse. Or, il engage la responsabilité du client face à la CNIL. Chaque DPA doit être relu avant signature. Même non négociable, son analyse permet d’évaluer le risque et de documenter une décision éclairée. La signature à l’aveugle est le risque le plus fréquent.
5.2 Croire que « non négociable » signifie « à accepter »
Le deuxième piège est la résignation. Quand l’éditeur affirme que son DPA n’est pas négociable, beaucoup de clients renoncent. Pourtant, certaines clauses sont presque toujours amendables, surtout pour un contrat à enjeu. Et si rien n’est négociable, le choix d’un autre fournisseur reste possible. Le DPA fait partie du critère de sélection. Ne pas négocier doit rester un choix conscient, et non une soumission par défaut.
5.3 Ignorer l’entraînement de l’IA sur ses données
Le troisième piège, spécifique à 2026, concerne l’IA. De nombreux éditeurs utilisent les données de leurs clients pour entraîner leurs modèles d’IA. Si le DPA l’autorise implicitement, le client perd le contrôle de ses données. La clause doit interdire ou strictement encadrer cet usage, et l’articuler avec l’AI Act (Règlement UE 2024/1689). C’est un point de vigilance nouveau et essentiel de tout accord de sous-traitance en 2026.
5.4 Négliger la cohérence avec le contrat principal
Le quatrième piège est l’incohérence contractuelle. Le DPA et le contrat SaaS principal doivent s’articuler sans contradiction. Un plafond de responsabilité dans le contrat principal peut neutraliser celui du DPA. Une clause de réversibilité dans l’un peut contredire l’autre. Il faut lire les deux documents ensemble et vérifier leur cohérence, notamment sur la responsabilité, la durée et le sort des données.
5.5 Oublier de tenir à jour le registre et les DPA
Le cinquième piège est l’absence de suivi. Signer un bon DPA ne suffit pas : il faut le tenir à jour. Les sous-traitants changent, les versions évoluent, les fonctions IA s’ajoutent. Le registre des traitements (article 30 du RGPD) doit refléter la réalité. Un DPA fournisseur SaaS signé puis oublié devient vite obsolète. Une revue périodique du parc de DPA est indispensable pour rester conforme dans la durée.
6. Pourquoi faire appel à Atias Avocats
Renégocier un DPA fournisseur SaaS exige une combinaison rare de compétences : maîtrise du RGPD et de l’article 28 (contenu obligatoire de l’accord de sous-traitance), connaissance des transferts internationaux (arrêt Schrems II, clauses contractuelles types, analyse d’impact des transferts), pratique de la négociation contractuelle face aux éditeurs, et compréhension des enjeux de l’AI Act lorsque l’outil intègre de l’IA. Cette pluridisciplinarité est précisément la valeur ajoutée d’un cabinet spécialisé en protection des données et contrats IT.
Atias Avocats accompagne DPO, DSI, directions juridiques, directions achats, fondateurs et grands groupes sur l’ensemble du sujet : revue d’un DPA standard avec note de recommandations, renégociation complète face à l’éditeur, rédaction d’un DPA sur mesure à imposer à ses propres sous-traitants, audit du parc de DPA et de la chaîne de sous-traitance, mise en conformité Schrems II et AI Act, défense en cas de contrôle CNIL. Pour aller plus loin, consultez nos services en matière de protection des données personnelles.
Conclusion
Le DPA fournisseur SaaS n’est jamais une simple formalité. C’est un contrat qui engage la responsabilité du client responsable de traitement, dans un document rédigé par et pour l’éditeur. Les sept clauses présentées ici — sous-traitance ultérieure, transferts hors UE, sécurité, notification, audit, réversibilité, responsabilité — combinées à la vigilance sur les cinq pièges classiques, offrent un référentiel directement utilisable par DPO, DSI et directions juridiques pour rééquilibrer la relation.
L’investissement requis pour sécuriser ce document est sans commune mesure avec le coût d’un contrôle CNIL ou d’une violation de données mal couverte. À l’heure des contrôles renforcés et de l’IA générative, signer un DPA sans le relire est un risque que peu d’entreprises peuvent se permettre. Le réflexe à adopter est clair : ne jamais signer à l’aveugle, identifier les 7 clauses à risque, négocier ce qui peut l’être, vérifier la cohérence avec le contrat principal, et tenir le tout à jour. C’est précisément cette rigueur qui transforme un DPA subi en protection réelle.
FAQ — Questions fréquentes
Qu’est-ce qu’un DPA fournisseur SaaS ?
Un DPA fournisseur SaaS (Data Processing Agreement, ou accord de sous-traitance) est le contrat exigé par l’article 28 du RGPD lorsqu’un éditeur SaaS traite des données personnelles pour le compte de son client. Le client est responsable de traitement, l’éditeur est sous-traitant. Le DPA encadre les conditions du traitement : finalités, durée, mesures de sécurité, sous-traitance ultérieure, transferts hors UE, notification des violations, sort des données en fin de contrat. En pratique, l’éditeur impose presque toujours son propre DPA standard, rédigé pour le protéger lui. Or, ce document engage la responsabilité du client en cas de manquement. Le DPA fournisseur SaaS n’est donc jamais à signer sans relecture : plusieurs clauses méritent une renégociation pour rééquilibrer la protection au profit du client responsable de traitement.
Le DPA standard d’un éditeur est-il négociable ?
Oui, même si les éditeurs présentent souvent leur DPA comme non négociable. La marge de manœuvre dépend du rapport de force, mais elle existe presque toujours. Pour un grand compte ou un contrat à fort enjeu, la renégociation est attendue et obtenue. Pour une PME face à un éditeur dominant, certaines clauses restent figées, mais d’autres peuvent être amendées : encadrement des transferts hors UE, délai de notification des violations, droit d’audit, sort des données. Même quand le DPA fournisseur SaaS n’est pas modifiable, son analyse reste indispensable : elle permet d’évaluer le risque résiduel, de documenter la décision et, le cas échéant, de choisir un autre fournisseur. Ne pas négocier est un choix, mais il doit être éclairé.
Quelles sont les clauses les plus risquées d’un DPA SaaS ?
Sept clauses concentrent l’essentiel du risque pour le client. La sous-traitance ultérieure (l’éditeur peut-il recourir librement à d’autres sous-traitants ?). Les transferts hors UE (vers quels pays, sous quelles garanties après l’arrêt Schrems II ?). Les mesures de sécurité (sont-elles précises et contraignantes, conformes à l’article 32 du RGPD ?). La notification des violations (sous quel délai l’éditeur prévient-il le client ?). Le droit d’audit (le client peut-il vérifier la conformité ?). La réversibilité (récupération et suppression des données en fin de contrat). La responsabilité (l’éditeur limite-t-il abusivement la sienne ?). Ces sept clauses sont le cœur de la renégociation d’un DPA fournisseur SaaS, car elles déterminent l’exposition réelle du client responsable de traitement.
Qui est responsable en cas de fuite de données chez l’éditeur ?
Les deux parties peuvent être responsables, mais à des titres différents. Le client, en tant que responsable de traitement, reste responsable vis-à-vis des personnes concernées et de la CNIL : il a choisi le sous-traitant et doit s’assurer de ses garanties (article 28 du RGPD). L’éditeur, sous-traitant, est responsable s’il a manqué à ses obligations propres ou agi hors instructions (article 82 du RGPD). En pratique, beaucoup de DPA limitent fortement la responsabilité de l’éditeur, laissant le client supporter le risque. C’est pourquoi la clause de responsabilité du DPA fournisseur SaaS doit être renégociée.
Contact : david@atiasavocats.com | LinkedIn: David Joseph Atias | https://www.atiasavocats.com | 42 rue de la Clef, 75005 Paris
Atias Avocats — RGPD, DPA, Sous-traitance, Contrats SaaS
