saasb2bcgvdpaslargpd

SaaS B2B : CGV, DPA, SLA — comprendre les trois documents indispensables

Tout éditeur SaaS B2B sérieux signe avec ses clients un triptyque : CGV pour la relation commerciale, DPA pour le traitement des données, SLA pour le niveau de service. Pourquoi trois documents, ce qu'ils doivent contenir, et comment éviter les pièges en 2026.

12 min de lecture

Vous éditez un SaaS B2B. Votre premier client sérieux vous envoie un mail : « Pouvez-vous nous transmettre vos CGV, votre DPA et votre SLA ? ». Trois acronymes, trois documents, et souvent une seule réaction : la panique. Beaucoup de fondateurs SaaS répondent en envoyant un PDF unique de quarante pages, ou pire, des CGV génériques recyclées d'un site e-commerce. Mauvaise idée. Ces trois documents ont des objets juridiques distincts, des durées de vie différentes, et des interlocuteurs séparés côté client (le service achats, le DPO, la DSI). Voici comment construire le triptyque qui vous évitera de perdre vos prochains deals — et de finir en contentieux.

Pourquoi trois documents plutôt qu'un seul méga-contrat

La tentation est forte de tout regrouper dans un document unique signé en une seule fois. C'est plus simple à éditer, plus rassurant pour le commercial, plus rapide à boucler. Et pourtant, les éditeurs SaaS matures séparent toujours les trois textes. Pour trois raisons.

D'abord, la modularité de négociation. Un grand compte va relire votre DPA avec un DPO, votre SLA avec une DSI, vos CGV avec un service achats. Trois interlocuteurs, trois rythmes, trois cycles de validation. Si tout est dans un même document, chaque modification d'une clause technique du SLA vous oblige à rouvrir l'ensemble — y compris les clauses commerciales déjà actées.

Ensuite, les durées de vie diffèrent. Vos CGV évoluent peu (peut-être une fois par an). Votre DPA est appelé à changer dès qu'un sous-traitant ultérieur est ajouté ou qu'une décision d'adéquation européenne tombe. Votre SLA peut bouger à chaque évolution de votre architecture technique. Trois documents = trois cycles de mise à jour.

Enfin, la lisibilité juridique. Le DPA répond à l'article 28 du RGPD avec un vocabulaire précis (responsable de traitement, sous-traitant, instructions documentées). Le SLA est technique. Les CGV sont commerciales. Mélanger ces trois registres dans un même document mène inévitablement à des incohérences — par exemple une clause de responsabilité globale qui contredit les crédits de service du SLA.

L'ordre de signature compte

En pratique, on signe les trois documents simultanément, mais chacun est annexé séparément au contrat-cadre. Cela vous permet de modifier ultérieurement le DPA (ajout d'un sous-traitant, par exemple) sans rouvrir la négociation commerciale.

Les CGV SaaS B2B : la colonne commerciale

Vos CGV régissent la relation commerciale avec votre client. C'est la base du contrat. En B2B, l'article L.441-1 du Code de commerce impose de les communiquer à tout acheteur professionnel qui en fait la demande. En pratique, vous les fournissez systématiquement.

Les clauses qui ne souffrent aucune approximation

Vos CGV SaaS B2B doivent traiter, au minimum :

  • L'identité juridique des parties : raison sociale, SIREN, siège social, représentant. Si vous signez via un email professionnel, vérifiez que la signature engage bien la personne morale.
  • L'objet du contrat : décrire précisément le service. Évitez les formulations vagues comme « accès à la plateforme ». Renvoyez à une grille fonctionnelle annexée si nécessaire.
  • Le prix et les modalités de facturation : montant HT, TVA, périodicité (mensuel, annuel), modalités d'indexation. Si vous facturez à l'usage, expliquez la formule.
  • Les délais de paiement : par défaut 30 jours après émission de la facture, extensibles à 60 jours par accord écrit. Au-delà, vous êtes en zone grise au regard de l'article L.441-10 du Code de commerce.
  • Les pénalités de retard : taux d'intérêt (BCE + 10 points minimum) et indemnité forfaitaire de 40 euros par facture impayée. Ce n'est pas optionnel.
  • La durée et la résiliation : durée initiale, reconduction tacite, préavis (souvent 30 à 90 jours), motifs de résiliation pour faute.
  • La propriété intellectuelle : vous restez propriétaire de votre logiciel ; le client conserve la propriété de ses données.
  • Les limitations de responsabilité : plafond chiffré (généralement le montant des redevances payées sur les 12 derniers mois), exclusion des dommages indirects.
  • La force majeure : utile mais à manier avec mesure ; les juges écartent les clauses trop larges.
  • Le droit applicable et la juridiction compétente : tribunal de commerce du lieu du siège du vendeur, droit français.

Le piège du droit de rétractation

Contrairement au B2C, le droit de rétractation n'est pas dû par défaut en B2B. Mais attention : si votre client professionnel a moins de cinq salariés et signe en dehors de son activité principale, il bénéficie tout de même d'un droit de rétractation de 14 jours (article L.221-3 du Code de la consommation). Pour un SaaS purement professionnel, on l'exclut explicitement.

Pour une vue d'ensemble des différences entre CGV et CGU, notamment dans les modèles freemium, voyez notre article CGV ou CGU : quelle différence.

Le DPA : l'obligation que tout le monde sous-estime

Le DPA — Data Processing Agreement, ou « contrat de sous-traitance des données personnelles » — n'est pas une option. C'est une obligation légale dès lors que votre client vous confie des données personnelles, ce qui est le cas de 99 % des SaaS B2B. L'article 28 du RGPD est limpide : sans contrat écrit conforme, le traitement est illicite. Et la CNIL a confirmé en 2025 sa volonté de sanctionner directement les sous-traitants défaillants, indépendamment du responsable de traitement.

Votre rôle : sous-traitant au sens du RGPD

Premier réflexe à acquérir : dans la relation contractuelle avec votre client B2B, c'est lui le responsable de traitement, et vous êtes le sous-traitant. Lui décide pourquoi et comment les données sont traitées ; vous exécutez ses instructions documentées. C'est un renversement de perspective par rapport au RGPD que vous appliquez à vos propres données (prospects, employés), où vous êtes responsable de traitement.

Ce que la CNIL exige dans un DPA

Le contrat doit obligatoirement prévoir, selon l'article 28.3 du RGPD :

  • L'objet et la durée du traitement.
  • La nature et la finalité du traitement.
  • Le type de données personnelles concernées (identité, contact, données techniques, données de santé, etc.).
  • Les catégories de personnes concernées (clients, employés, prospects de votre client).
  • Les obligations et droits du responsable de traitement.
  • L'obligation de confidentialité de vos équipes et de vos sous-traitants.
  • Les mesures de sécurité techniques et organisationnelles (chiffrement au repos et en transit, contrôle d'accès, journalisation, sauvegardes).
  • Le recours à des sous-traitants ultérieurs : autorisation préalable, information du client en cas de changement.
  • L'assistance au responsable de traitement pour répondre aux droits des personnes (accès, effacement, portabilité) et aux notifications de violation.
  • La restitution ou destruction des données à la fin du contrat.
  • Le droit d'audit : le client peut auditer vos pratiques, directement ou via un tiers mandaté.

Les sous-traitants ultérieurs : Stripe, AWS, SendGrid…

Votre SaaS s'appuie inévitablement sur d'autres services : un hébergeur (AWS, OVH, Scaleway), un processeur de paiement (Stripe), un outil d'emailing transactionnel (SendGrid, Postmark), un outil d'analytics (Mixpanel, Amplitude). Chacun est un sous-traitant ultérieur au sens du RGPD. Vous devez :

  • Lister ces sous-traitants dans une annexe au DPA (souvent appelée « Liste des sous-traitants ultérieurs »).
  • Obtenir une autorisation générale ou spécifique de votre client.
  • Informer votre client de tout ajout ou remplacement, avec un délai raisonnable lui permettant de s'y opposer.
  • Vous assurer que chacun de ces sous-traitants applique des garanties équivalentes (en pratique : leur DPA doit être au moins aussi protecteur que le vôtre).

Le cas des transferts hors UE

Si l'un de vos sous-traitants est établi hors de l'Espace économique européen, vous devez encadrer le transfert. Trois mécanismes principaux :

  • Décision d'adéquation : la Commission européenne reconnaît que le pays offre un niveau de protection équivalent (Royaume-Uni, Japon, Corée du Sud…).
  • Data Privacy Framework (DPF) pour les transferts vers les États-Unis, depuis juillet 2023. Plus de 3 500 entreprises américaines sont certifiées, dont AWS, Stripe, Google, Microsoft, HubSpot, Salesforce.
  • Clauses contractuelles types (CCT) de la Commission européenne, adoptées par la décision d'exécution 2021/914 du 4 juin 2021. Approche modulaire (contrôleur-contrôleur, contrôleur-sous-traitant, sous-traitant-sous-traitant, sous-traitant-contrôleur) qui doit être annexée au DPA.

Pour un panorama complet, consultez notre article dédié aux transferts de données hors UE et au DPF en 2026.

DPF certifié ne dispense pas du DPA

Que votre prestataire américain soit certifié DPF ou non, vous devez de toute façon signer un DPA avec lui. Le DPF règle la base juridique du transfert ; le DPA encadre les obligations du sous-traitant. Ce sont deux choses distinctes.

Vous devez par ailleurs tenir un registre des traitements qui recense tous ces flux et sous-traitants.

Le SLA : l'engagement que vous tiendrez (vraiment)

Le SLA — Service Level Agreement — est un engagement contractuel sur la qualité du service rendu. C'est le document que votre client opérationnel relit avec attention, car c'est lui qui détermine si votre service tient la route au quotidien.

Les engagements de disponibilité

Le standard du marché SaaS B2B se situe entre 99,5 % et 99,95 % de disponibilité mensuelle. Pour fixer les idées :

  • 99 % : environ 7 h 18 min d'indisponibilité par mois — généralement inacceptable en B2B.
  • 99,5 % : 3 h 39 min par mois — acceptable pour des outils non critiques.
  • 99,9 % : 43 min 49 s par mois — standard du marché.
  • 99,95 % : 21 min 54 s par mois — engagement enterprise.
  • 99,99 % : 4 min 22 s par mois — exceptionnel, à ne promettre que si votre architecture le permet vraiment.

N'engagez pas un chiffre que votre architecture ne peut pas tenir. Une promesse de 99,99 % avec un seul datacenter et un point de panique unique vous mettra en défaut au premier incident.

Les crédits de service

L'engagement de disponibilité s'accompagne de pénalités, qu'on appelle généralement crédits de service. Ils sont calculés sur la base de la mensualité (ou son équivalent prorata). Exemple d'une grille classique :

  • Disponibilité comprise entre 99,5 % et 99,9 % : crédit de 10 % de la mensualité.
  • Disponibilité comprise entre 99 % et 99,5 % : crédit de 25 %.
  • Disponibilité inférieure à 99 % : crédit de 50 %, parfois 100 %.

Plafonnez ces crédits à un pourcentage maximum (souvent 25 % ou 50 % de la facture mensuelle), et précisez que le crédit de service est le seul et unique recours du client en cas de défaillance de disponibilité. Sans cette clause, votre client peut additionner le crédit ET réclamer des dommages-intérêts.

Les fenêtres de maintenance

Vos opérations de maintenance planifiée ne doivent pas compter dans le calcul de l'indisponibilité. Mentionnez-le explicitement : fenêtre standard (par exemple le dimanche entre 2 h et 6 h du matin), préavis minimum (48 h ou 7 jours), notification (email, page de statut).

Le support

Le SLA précise également :

  • Les horaires de support (5/7 9h-18h, 24/7, etc.).
  • Les canaux (email, chat, téléphone).
  • Les délais de réponse par criticité d'incident (P1 critique : 1 h, P2 majeur : 4 h, P3 mineur : 1 jour ouvré).
  • Les délais de résolution indicatifs (rarement contractualisés au sens strict, car non maîtrisables).

Les erreurs fréquentes qui coûtent cher

Erreur n°1 : ne pas avoir de DPA du tout

C'est la plus fréquente chez les SaaS jeunes. Un client B2B vous confie des données personnelles, vous lui répondez « on est conforme RGPD » sans signer de DPA. Vous êtes tous les deux dans l'illégalité. Et si le client est audité par la CNIL, vous serez sanctionné aussi — la CNIL ne traite plus les sous-traitants comme des seconds rôles. Voyez à ce sujet notre article sur les sanctions CNIL des sites non conformes.

Erreur n°2 : un DPA copié-collé qui contredit les CGV

Vous reprenez un DPA modèle, vous y collez des clauses sur la durée de conservation, et vous oubliez que vos CGV prévoient déjà une durée différente. Le juge tranchera en faveur de la clause la plus protectrice pour la personne concernée, et votre cohérence contractuelle est ruinée. Une relecture croisée s'impose.

Erreur n°3 : un SLA irréaliste

Promettre 99,99 % parce que c'est joli, alors que votre infra repose sur un seul VPS, c'est se condamner. Mieux vaut 99,5 % tenu que 99,99 % loupé tous les mois.

Erreur n°4 : un DPA flou sur les sous-traitants

Vous mentionnez « AWS et autres prestataires standards de l'industrie ». Cette formulation ne tient pas devant la CNIL. Listez précisément, mettez à jour, notifiez vos clients.

Erreur n°5 : aucune trace de l'acceptation

Vos trois documents doivent être acceptés explicitement. Une signature électronique (Yousign, DocuSign, signature interne) avec horodatage et trace de version est l'idéal. Un email d'acceptation peut suffire à condition de pouvoir produire le document accepté.

Le client enterprise qui vous pousse SON DPA

Votre premier gros client va probablement vous envoyer son propre DPA, son propre SLA, et parfois ses propres conditions générales d'achat. Trois réflexes utiles :

  • Ne signez pas sans lire. Les DPA enterprise contiennent souvent des clauses d'audit illimitées, des délais de notification de violation de 24 h (le RGPD exige 72 h vis-à-vis de la CNIL), des engagements de sécurité disproportionnés.
  • Négociez ce qui peut l'être. Le délai de notification, la portée du droit d'audit, les pénalités. Le client a souvent prévu une marge.
  • Acceptez ce qui est raisonnable. Refuser tout le DPA du client est mauvais signe. Acceptez sa structure, amendez les clauses problématiques. C'est plus efficace que de tenter d'imposer le vôtre.

Pour les fondamentaux RGPD que tout cela suppose, voyez notre guide RGPD pour site web français.

Construire son triptyque en pratique

Vous éditez un SaaS et vous n'avez aujourd'hui ni CGV propres, ni DPA, ni SLA ? Voici l'ordre logique :

  1. CGV d'abord : c'est la base commerciale, indispensable pour facturer.
  2. DPA ensuite : à dégainer dès le premier client qui en fait la demande, ou dès que vous traitez des données personnelles pour un client (donc immédiatement).
  3. SLA en troisième : commencez par un SLA réaliste, quitte à le durcir plus tard quand votre architecture aura mûri.

Les modèles gratuits trouvés en ligne valent ce qu'ils valent : utiles pour comprendre la structure, dangereux à signer en l'état. La CNIL publie un modèle officiel de clauses de sous-traitance qui vaut le détour, et la Commission européenne met à disposition les clauses contractuelles types officielles pour les transferts internationaux. Pour le détail des obligations du sous-traitant, le guide CNIL du sous-traitant reste la référence.

En conclusion

Le triptyque CGV-DPA-SLA n'est pas un luxe administratif : c'est le socle juridique de votre SaaS B2B. Les CGV protègent votre relation commerciale, le DPA vous met en conformité RGPD, le SLA verrouille vos engagements opérationnels. Trois documents, trois objets, trois cycles de vie. Tentez de tout fondre en un seul, et vous perdrez à la fois la lisibilité, la flexibilité, et probablement quelques deals avec des grands comptes qui exigent ce niveau de structuration.

Bonne nouvelle : une fois le pack rédigé proprement, il vous accompagnera pendant des années. Notre générateur produit des CGV SaaS B2B et un DPA articulés, prêts à être joints à votre SLA technique. Quelques minutes pour mettre votre conformité à jour, et un argument de plus pour signer votre prochain client enterprise.

Pack CGV + DPA pour votre SaaS

Générer mes CGV SaaS

Modèles prêts à générer

Créez le document conforme correspondant en quelques minutes.

Questions fréquentes

Un SaaS doit-il signer un DPA avec ses clients ?

Oui, le DPA (Data Processing Agreement) est une obligation légale dès lors que votre client vous confie des données personnelles, ce qui est le cas de 99 % des SaaS B2B. L'article 28 du RGPD est limpide : sans contrat écrit conforme, le traitement est illicite, et la CNIL peut sanctionner directement le sous-traitant défaillant, donc vous.

Quelle est la différence entre CGV, DPA et SLA pour un SaaS ?

Les CGV encadrent la relation commerciale (prix, durée, résiliation, responsabilité), le DPA encadre le traitement des données personnelles au titre de l'article 28 du RGPD, et le SLA encadre le niveau de service (disponibilité, support, pénalités). Ces trois documents sont indépendants mais articulés, négociés séparément avec des interlocuteurs distincts côté client : achats, DPO et DSI.

Quel taux de disponibilité prévoir dans un SLA SaaS B2B ?

Le standard du marché se situe entre 99,5 % et 99,95 % de disponibilité mensuelle, le 99,9 % (soit 43 minutes d'indisponibilité par mois) étant la référence courante. N'engagez pas un chiffre que votre architecture ne peut pas tenir : mieux vaut 99,5 % respecté que 99,99 % manqué tous les mois.

Un prestataire certifié DPF dispense-t-il de signer un DPA ?

Non, que votre prestataire américain soit certifié Data Privacy Framework ou non, vous devez de toute façon signer un DPA avec lui. Le DPF règle la base juridique du transfert hors UE, tandis que le DPA encadre les obligations du sous-traitant : ce sont deux choses distinctes.