Je suis Adrien CHAUMARAT, développeur Symfony depuis 2014, basé dans les Ardennes. Sur la quasi-totalité de mes projets de SaaS sur mesure ou de logiciel métier sur mesure, la question RGPD arrive dans les trois premières semaines de cadrage. Et elle arrive presque toujours dans le désordre : un client demande où sont stockées les données avant de savoir lesquelles il collecte, un autre s'alarme du Cloud Act sans avoir lu son contrat fournisseur, un troisième signe un sous-traitant outre-Atlantique en ignorant qu'il doit le tracer dans son registre. Cet article remet de l'ordre. Vous y trouverez les exigences réelles du RGPD pour un SaaS hébergé en France, le cadre du Cloud Act américain, les transferts internationaux, le contenu d'un DPA et le registre des traitements à tenir. C'est un guide opérationnel destiné aux dirigeants de TPE, PME et éditeurs SaaS B2B.
Pourquoi un SaaS hébergé en France simplifie le RGPD
Le Règlement général sur la protection des données encadre tout traitement de données personnelles concernant des personnes situées dans l'Union européenne, indépendamment de la localisation du responsable de traitement. Concrètement, vous êtes soumis au RGPD dès que votre SaaS collecte des données de clients français, même si vous l'hébergez ailleurs. La question n'est pas « suis-je concerné », elle est « comment je documente ma conformité ».
Héberger en France ne supprime pas l'obligation de conformité, mais simplifie radicalement deux dossiers : les transferts internationaux de données (qui disparaissent quand l'hébergement et les sous-traitants restent français) et l'exposition au Cloud Act américain (à laquelle un prestataire 100 % français n'est pas soumis). Ces deux dossiers représentent à eux seuls la moitié des questions que pose un audit RGPD. La CNIL rappelle dans sa doctrine sur les transferts que la localisation des données reste l'un des leviers les plus efficaces de maîtrise.
Ce que la souveraineté change concrètement
Un SaaS hébergé chez OVH, Scaleway ou en auto-hébergement Proxmox sur un datacenter français n'est soumis qu'au droit français et européen. Aucune autorité étrangère ne peut exiger l'accès aux données sans passer par une coopération judiciaire validée par la justice française. À l'inverse, un SaaS hébergé sur un cloud américain est soumis au Cloud Act, peu importe la localisation physique du serveur (cf. section suivante). La distinction n'est pas symbolique : elle conditionne le niveau de garantie que vous donnez à vos propres clients quand ils vous demandent des engagements de confidentialité.
C'est aussi un argument commercial concret en B2B. Sur mes projets éditeurs SaaS B2B, l'argument « 100 % France, RGPD natif » a fait gagner des contrats face à des acteurs internationaux qui n'arrivaient pas à donner des engagements équivalents.
Le Cloud Act américain : ce qu'il oblige vraiment
Le Cloud Act (Clarifying Lawful Overseas Use of Data Act) est une loi américaine de 2018 qui autorise les autorités américaines à exiger d'une entreprise soumise au droit américain la communication de données qu'elle détient, peu importe où ces données sont stockées physiquement. Si votre prestataire d'hébergement est une société américaine ou une filiale de société américaine, le Cloud Act s'applique même si vos données sont stockées sur un serveur situé à Paris, Francfort ou Dublin.
Concrètement, ça veut dire qu'un acteur comme AWS, Microsoft Azure ou Google Cloud, même opérant en région UE, reste juridiquement exposé. C'est cette extraterritorialité qui pose problème vis-à-vis du RGPD : un transfert de données vers un pays tiers non couvert par une décision d'adéquation est, par défaut, interdit ou conditionné à des garanties strictes. La CNIL maintient une page de référence sur les transferts vers les États-Unis que je recommande de garder en marque-page.
Le cadre EU-US Data Privacy Framework et ses limites
Depuis juillet 2023, la Commission européenne a adopté le Data Privacy Framework qui établit une décision d'adéquation entre l'UE et les États-Unis. En pratique, cela autorise les transferts vers les entreprises américaines certifiées, sous conditions. Mais l'historique des deux accords précédents (Safe Harbor en 2015, Privacy Shield en 2020) montre que ces décisions d'adéquation peuvent être invalidées par la Cour de justice de l'UE. Bâtir sa stack sur un cadre potentiellement instable est un risque opérationnel à intégrer dans votre plan de continuité.
Mon parti-pris : sur les projets que je conçois, j'évite par défaut tout prestataire soumis au Cloud Act, sauf si le client a explicitement validé le risque et documenté la base légale. Le coût marginal d'un hébergement souverain français est marginal aujourd'hui, comparé au risque juridique et réputationnel. Pour creuser le sujet, mon article Hébergement web en France : pourquoi c'est le bon choix détaille les arguments commerciaux et techniques.
Les responsabilités RGPD dans un SaaS : qui fait quoi
Le RGPD distingue deux rôles principaux : le responsable de traitement (qui détermine la finalité et les moyens du traitement) et le sous-traitant (qui traite les données pour le compte du responsable). Pour un éditeur SaaS B2B, la situation typique est la suivante : votre client final est responsable de traitement vis-à-vis de ses propres données utilisateurs, et vous êtes sous-traitant en tant qu'éditeur SaaS qui héberge et traite ces données. Cette distinction conditionne la rédaction de tous vos contrats clients.
Le sous-traitant a des obligations spécifiques décrites à l'article 28 du RGPD : agir uniquement sur instruction documentée du responsable, garantir la confidentialité, prendre des mesures de sécurité appropriées, ne pas recruter de sous-traitant ultérieur sans autorisation, aider le responsable à répondre aux demandes d'exercice de droits, notifier toute violation, supprimer ou restituer les données en fin de contrat. Ces obligations doivent être inscrites dans un contrat écrit : c'est le DPA (Data Processing Agreement), parfois appelé en France « contrat de sous-traitance RGPD » ou « accord de traitement des données ».
Le DPA : ce qu'il doit contenir au minimum
Un DPA conforme à l'article 28 du RGPD doit obligatoirement préciser huit points : l'objet et la durée du traitement, la nature et la finalité, les types de données et catégories de personnes concernées, les obligations et droits du responsable, les engagements du sous-traitant (confidentialité, sécurité, sous-traitants ultérieurs, droits des personnes, notification des violations, restitution ou suppression en fin de contrat), les conditions des audits et inspections, les conditions de sortie. La CNIL propose un guide officiel pour rédiger un contrat de sous-traitance que je recommande pour démarrer.
Le registre des traitements : votre carnet de bord conformité
Le registre des traitements est l'obligation la plus négligée du RGPD, et pourtant la plus simple à mettre en place. Il s'agit d'un document interne qui liste tous les traitements de données personnelles que vous opérez, avec pour chacun : la finalité, les catégories de données traitées, les catégories de personnes concernées, les destinataires (internes et sous-traitants), les transferts hors UE le cas échéant, les durées de conservation, et les mesures techniques et organisationnelles de sécurité. Le registre doit être tenu à jour et présentable à la CNIL en cas de contrôle.
Pour un éditeur SaaS B2B, le registre se construit en deux temps : d'abord les traitements internes (gestion RH, prospection commerciale, comptabilité, support client), puis les traitements liés au SaaS lui-même (création de comptes, journaux d'activité, mesures d'audience, sauvegardes). La CNIL met à disposition un modèle de registre des traitements gratuit au format tableur, calibré pour les TPE et PME.
Le réflexe à intégrer dans votre processus produit
Mon conseil opérationnel : chaque nouvelle fonctionnalité de votre SaaS qui touche aux données personnelles doit ajouter une ligne au registre. Concrètement, j'intègre cette étape dans le ticket de spécification fonctionnelle : pas de spec sans ligne registre proposée. Cette discipline évite le rattrapage panique à la veille d'un audit ou d'une certification. Pour aller plus loin sur la checklist RGPD complète pour un SaaS, mon article dédié liste 32 points à cocher en revue trimestrielle.
Les transferts hors UE : règles et alternatives
Un transfert hors UE désigne toute communication de données personnelles à une entité située en dehors de l'Espace économique européen. Le RGPD interdit par défaut ces transferts, sauf si l'une des garanties suivantes est respectée : décision d'adéquation pour le pays destinataire, clauses contractuelles types (CCT) approuvées par la Commission, règles d'entreprise contraignantes (BCR), ou cas dérogatoires limités.
Les décisions d'adéquation actuelles couvrent une quinzaine de pays (Royaume-Uni, Suisse, Japon, Canada secteur commercial, Argentine, etc.) et, depuis juillet 2023, les États-Unis via le Data Privacy Framework. Pour les autres destinations, ce sont les CCT qui s'utilisent en pratique. Mais attention : signer des CCT ne suffit pas. Depuis l'arrêt Schrems II de 2020, la CJUE exige une analyse complémentaire dite Transfer Impact Assessment qui évalue le niveau réel de protection dans le pays destinataire. C'est un exercice lourd que la documentation officielle du Comité européen de la protection des données encadre.
La stratégie simple : éviter le transfert quand c'est possible
Plutôt que d'investir dans des analyses Schrems II coûteuses, la stratégie la plus rentable consiste souvent à choisir des prestataires français dès la conception du SaaS. Hébergement français, services tiers localisés en France quand c'est possible (envoi d'emails, paiement, monitoring), équipe technique localisée en France : cette discipline réduit fortement la question du transfert. Sur mes projets, j'utilise par défaut Scaleway ou OVH côté infrastructure, et je documente les éventuelles dépendances hors France avant de proposer un acteur extraeuropéen.
Les droits des personnes à implémenter dans votre SaaS
Le RGPD ouvre aux personnes concernées sept droits qu'un SaaS doit savoir honorer : accès, rectification, effacement (droit à l'oubli), limitation du traitement, portabilité, opposition, et droit de ne pas faire l'objet d'une décision automatisée. En pratique, pour un éditeur SaaS B2B, ces droits s'exercent généralement via votre client final qui est responsable de traitement, mais vous devez avoir les fonctionnalités techniques pour les supporter à sa demande.
| Droit | Article | Implémentation typique |
|---|---|---|
| Accès | Article 15 | Export structuré des données d'un utilisateur (JSON ou CSV) |
| Rectification | Article 16 | Édition possible des données depuis le profil utilisateur |
| Effacement (oubli) | Article 17 | Suppression du compte avec anonymisation des données dépendantes |
| Limitation | Article 18 | Gel temporaire d'un compte sans suppression |
| Portabilité | Article 20 | Export complet dans un format réutilisable par un autre prestataire |
| Opposition | Article 21 | Désactivation des traitements non essentiels (analytics, prospection) |
| Décision automatisée | Article 22 | Possibilité de demander une intervention humaine sur une décision |
Concrètement, sur mes projets de SaaS sur mesure, j'implémente systématiquement les droits 15, 16, 17, 18 et 20 dès la version 1. Les droits 21 et 22 dépendent du modèle métier : un SaaS sans IA ni profilage commercial automatisé n'a souvent pas besoin du 22, et le 21 se limite à un opt-out de cookies non essentiels. Voir aussi mon article sur l'OWASP Top 10 pour éditeurs SaaS en 2026 qui complète la dimension sécurité technique de la conformité.
Les obligations de sécurité RGPD pour un SaaS
L'article 32 du RGPD impose des mesures techniques et organisationnelles appropriées au risque. Le mot « appropriées » laisse de la marge d'interprétation, mais la CNIL et l'ANSSI ont publié des recommandations qui définissent un socle commun. Pour un SaaS B2B, le socle minimum comprend : chiffrement TLS en transit, chiffrement au repos pour les données sensibles, sauvegardes régulières testées, journalisation des accès, gestion des identités et authentification forte (idéalement 2FA), procédure de notification de violation sous 72 heures, plan de continuité d'activité.
Pour les éditeurs SaaS B2B qui visent des clients soumis à des contraintes sectorielles renforcées (santé, finance, secteur public), ces exigences se durcissent : hébergement HDS pour les données de santé, certification SecNumCloud pour les contrats publics les plus exigeants, conformité NIS2 à partir de 2026 pour les entités essentielles et importantes. La directive NIS2 est un sujet à part entière que je traite dans mon article sur NIS2 pour les éditeurs SaaS PME en France.
Notifier une violation : 72 heures, pas un jour de plus
En cas de violation de données (intrusion, fuite, perte, accès non autorisé), le responsable de traitement doit notifier la CNIL dans un délai maximal de 72 heures après en avoir pris connaissance. Si la violation présente un risque élevé pour les droits et libertés des personnes, celles-ci doivent aussi être informées sans retard. Pour un éditeur SaaS, cela suppose une procédure interne documentée : qui détecte, qui qualifie, qui notifie, qui rédige les communications. La CNIL met à disposition un téléservice de notification avec un modèle qui guide la déclaration.
Cas vécu : audit RGPD chez un éditeur SaaS télécom
Sur un projet d'éditeur SaaS de facturation télécom que j'accompagne, le porteur a anticipé l'audit RGPD à six mois avant le premier client B2B grand compte. La grande entreprise prospectée exigeait un dossier conformité complet avant de signer : DPA, registre des traitements, politique de confidentialité, procédure de notification, liste des sous-traitants. Le projet partait d'une base saine (hébergement Scaleway, équipe française, RGPD intégré dès la conception), mais le formalisme manquait.
Nous avons consacré trois semaines à structurer le dossier : rédaction du DPA, complétude du registre, audit des sous-traitants ultérieurs (envoi d'emails transactionnels, monitoring, paiement), formalisation de la procédure de notification, mise à jour de la politique de confidentialité côté tenant client. Le contrat avec le grand compte a été signé deux semaines après la remise du dossier. Le coût total de la mise en conformité formelle a été marginal au regard du chiffre d'affaires que le contrat a apporté.
La leçon : la conformité RGPD pour un SaaS est un actif commercial. Vos clients B2B la demandent, votre absence de réponse les fait fuir, votre maîtrise du sujet rassure et différencie. Ce n'est pas une contrainte, c'est un argument de vente, et c'est une raison de plus pour le construire dès le départ, pas en rattrapage.
Modèle de DPA et registre : ressources téléchargeables
Pour faciliter la prise en main, ARDNTECH met à disposition deux ressources opérationnelles que les porteurs de projet peuvent réutiliser sans contrepartie. Ces modèles ne remplacent pas un conseil juridique sur mesure, mais ils donnent une base saine pour démarrer.
Téléchargez le modèle DPA ARDNTECH
Le modèle de DPA est calibré pour un éditeur SaaS B2B ou une PME utilisatrice de logiciel métier sur mesure hébergé en France. Il reprend les huit points obligatoires de l'article 28, propose des formulations adaptées à un sous-traitant SaaS et inclut une annexe sous-traitants ultérieurs, une annexe mesures techniques et organisationnelles, ainsi qu'une annexe transferts hors UE. Télécharger le modèle gratuit (DOCX).
En complément du modèle ARDNTECH, deux sources de référence sont utiles : le guide CNIL pour les sous-traitants qui propose un modèle générique complet, et les clauses contractuelles types de la Commission européenne pour les cas de transferts hors UE. Le registre des traitements peut être démarré sur le modèle CNIL gratuit cité plus haut.
De la conformité formelle à la conformité opérationnelle
Un dossier RGPD complet ne fait pas un SaaS conforme. La conformité est une pratique continue qui se nourrit de discipline opérationnelle : chaque nouvelle fonctionnalité passe au registre, chaque nouveau sous-traitant fait l'objet d'un avenant DPA, chaque revue trimestrielle vérifie les durées de conservation, chaque audit interne teste la procédure de notification. Ce que j'observe chez mes clients, c'est que les structures qui réussissent leur RGPD sont celles qui l'intègrent dans leur cycle produit, pas celles qui l'externalisent à un cabinet une fois par an.
Sur mes projets, j'intègre systématiquement quatre rituels : revue mensuelle du registre, audit semestriel des sous-traitants, exercice annuel de notification de violation, contrôle annuel des durées de conservation. Ces rituels prennent une demi-journée par trimestre et évitent 90 % des dérives constatées en audit externe. Ils s'inscrivent naturellement dans la maintenance long terme d'un SaaS que je propose en contrat sur trois à cinq ans.
Échange initial gratuit de 30 minutes pour cadrer votre RGPD SaaS
Si vous préparez un projet de SaaS sur mesure (ou de logiciel métier sur mesure) hébergé en France et que vous souhaitez intégrer la conformité RGPD dès la conception, je propose un échange initial gratuit de 30 minutes pour identifier vos zones à traiter en priorité. Comme tous mes accompagnements, le périmètre est défini sur devis personnalisé. Mon guide de l'hébergement souverain français détaille les choix infrastructure compatibles, mon guide du développement de logiciel métier sur mesure couvre la méthodologie projet, et le formulaire de contact permet de réserver un créneau.
