RGPD et SaaS: ce qu'un dirigeant doit vraiment savoir

« On verra la conformité RGPD quand on aura des vrais clients » est une phrase qu’on entend souvent, et une erreur de calendrier coûteuse. Le règlement s’applique dès la première donnée personnelle collectée, pas au-delà d’un seuil de croissance. La bonne nouvelle : la conformité d’un SaaS naissant tient dans un nombre restreint de réflexes concrets, à condition de les poser dès le cadrage du projet plutôt que de les rattraper après coup.

Ce sujet mérite d’être traité avec la même rigueur que le budget ou le cahier des charges d’un SaaS, pour une raison simple : sur le marché B2B français et européen, un client professionnel qui envisage de vous confier ses données vérifie de plus en plus systématiquement votre conformité avant de signer, parfois via un questionnaire dédié. Ne pas être prêt à y répondre coûte des contrats, bien avant qu’une amende n’entre en jeu.

Le RGPD s’applique-t-il à mon SaaS ?

Oui, sans exception liée à la taille. Le Règlement général sur la protection des données s’applique dès qu’un traitement de données personnelles a lieu : dès qu’un nom, un email, une adresse IP ou toute autre donnée qui permet d’identifier une personne est collecté, stocké ou utilisé par votre logiciel. Il n’existe aucun seuil minimal d’utilisateurs, de chiffre d’affaires ou d’ancienneté qui exempterait une startup de ces obligations (comment intégrer le RGPD à votre startup, CNIL).

Suis-je responsable de traitement ou sous-traitant, et pourquoi ça change tout ?

Cette distinction structure toutes les obligations qui suivent. Le responsable de traitement est celui qui détermine les finalités et les moyens d’un traitement, l’objectif poursuivi et la façon de l’atteindre. Le sous-traitant, lui, traite des données personnelles pour le compte d’un responsable de traitement, sur ses instructions (CNIL, définition). Un éditeur de SaaS B2B occupe le plus souvent les deux rôles à la fois : sous-traitant pour les données que ses clients professionnels déposent dans l’outil (leurs propres clients, leurs employés, leurs contacts), responsable de traitement pour les données qu’il collecte lui-même à des fins commerciales (prospects, utilisateurs de son propre site, facturation).

Cette double casquette a une conséquence pratique directe : si vous êtes sous-traitant, vous devez tenir un registre des activités de traitement effectuées pour le compte de chacun de vos clients, et ce statut doit être encadré par un contrat spécifique, qu’on appelle généralement une clause ou un accord de traitement des données. Si vous faites vous-même appel à des sous-traitants, un hébergeur cloud, un service d’emailing, un outil d’analyse, la même logique s’applique dans l’autre sens : chaque sous-traitant doit être encadré par un contrat qui garantit la protection des données que vous lui confiez.

Ai-je besoin d’un délégué à la protection des données ?

Pas systématiquement, mais la question mérite d’être tranchée tôt. La désignation d’un délégué à la protection des données (DPO) est obligatoire dans deux cas précis : si votre activité de base implique un suivi régulier et systématique des personnes à grande échelle, ou si vous traitez à grande échelle des données dites sensibles, comme les données de santé ou biométriques. En dehors de ces deux cas, la CNIL encourage sa désignation sans l’imposer (CNIL, comment intégrer le RGPD à votre startup).

Pour un SaaS de PME dans sa première année, avec un volume d’utilisateurs modeste et aucune donnée sensible au sens du règlement, le DPO n’est généralement pas une obligation légale. Il reste néanmoins une bonne pratique, sous une forme légère : un DPO externe, mutualisé entre plusieurs petites structures, coûte une fraction de ce qu’imaginent la plupart des dirigeants, et évite l’écueil le plus fréquent, celui de confier ce rôle au dirigeant lui-même, ce que le règlement interdit précisément pour éviter les conflits d’intérêts.

Le DPO, qu’il soit interne ou externe, doit remplir trois conditions cumulatives : disposer de connaissances spécifiques en protection des données, bénéficier des moyens matériels et organisationnels pour exercer réellement sa mission, et ne pas cumuler cette fonction avec un rôle qui la mettrait en conflit d’intérêts. Dans une petite équipe où personne ne coche ces trois cases, l’option externe et mutualisée n’est pas un pis-aller : c’est souvent la solution la plus solide, parce qu’elle apporte une expertise que l’entreprise n’a pas encore les moyens de recruter à temps plein.

Quels sont les réflexes concrets pour la conformité d’un SaaS naissant ?

Cinq actions couvrent l’essentiel, dans l’ordre où elles se posent naturellement au fil d’un projet :

1. Tenir un registre des traitements. Un tableau simple, tenu à jour, qui recense chaque catégorie de données collectées, la finalité de leur traitement, leur durée de conservation et les destinataires éventuels. Ce document est la colonne vertébrale de toute conformité : sans lui, impossible de répondre sérieusement à une demande d’un utilisateur ou de la CNIL.
2. Publier une politique de confidentialité claire. Compréhensible par un utilisateur non juriste, elle explique quelles données sont collectées, pourquoi, combien de temps, et comment exercer ses droits (accès, rectification, suppression, portabilité).
3. Encadrer chaque sous-traitant par contrat. Hébergeur, service d’emailing, outil d’analyse, prestataire de paiement : chacun doit être lié par des clauses qui garantissent la protection des données confiées, avec une attention particulière si l’un d’eux héberge des données hors de l’Union européenne. Un transfert vers un pays hors Union européenne, vers les États-Unis notamment, demande des garanties supplémentaires (clauses contractuelles types ou décision d’adéquation) : un point à vérifier avant de choisir un fournisseur cloud ou un outil tiers, pas après l’avoir intégré à votre produit.
4. Appliquer la minimisation des données dès la conception. Ne collecter que ce qui est réellement nécessaire au fonctionnement du produit, et prévoir une durée de conservation limitée plutôt que de tout garder indéfiniment par facilité. Ce principe, connu sous le nom de privacy by design, coûte infiniment moins cher à intégrer au cadrage qu’à retrofiter sur un produit déjà en production.
5. Sécuriser techniquement les données stockées. Chiffrement des données sensibles, contrôle des accès, sauvegardes testées : des mesures qui recoupent largement l’hygiène informatique de base, mais que le RGPD rend explicitement exigibles plutôt que simplement recommandées. Ce même socle de sécurité doit ensuite être maintenu dans la durée, pas posé une fois puis oublié, ce qui relève typiquement d’une tierce maintenance applicative suivie.

Prenons un cas type pour rendre ça concret. Un SaaS de gestion RH pour PME stocke les CV et données de contact de candidats pour le compte de ses clients recruteurs. Il est sous-traitant vis-à-vis de ces données : un contrat avec chaque client encadre cet usage, un registre recense la finalité (gestion des candidatures) et une durée de conservation limitée (généralement deux ans après le dernier contact, au-delà de laquelle les données doivent être supprimées ou anonymisées). Ce même SaaS collecte aussi les emails de ses propres prospects pour sa prospection commerciale : il est cette fois responsable de traitement, avec une base légale distincte et une politique de confidentialité qui couvre cet usage séparément. Les deux registres, bien que gérés par la même équipe, ne se confondent jamais. Si ce même SaaS ajoute plus tard une fonctionnalité de scoring automatique des candidatures, la question du DPO se repose immédiatement : un tri algorithmique systématique de données de candidats, à grande échelle, peut faire basculer l’entreprise dans le cas où la désignation devient obligatoire. C’est un bon exemple de pourquoi la conformité n’est jamais figée : chaque nouvelle fonctionnalité qui touche aux données mérite d’être repassée au filtre des mêmes questions.

Combien coûte la mise en conformité RGPD, et qui la finance ?

L’essentiel du travail est organisationnel, pas technique : rédiger un registre, formaliser une politique de confidentialité et négocier des clauses avec vos sous-traitants prend quelques jours de travail structuré, souvent avec l’aide d’un avocat spécialisé ou d’un DPO externe pour les points juridiques les plus sensibles. La partie technique, minimisation des données, chiffrement, gestion des durées de conservation, s’intègre naturellement dans le cadrage d’un SaaS bien conçu plutôt que de s’ajouter en surcoût après coup : c’est l’un des postes que nous couvrons systématiquement lors du cadrage d’un projet, au même titre que l’architecture ou le choix des intégrations, sans que cela modifie sensiblement les fourchettes de budget habituelles d’un MVP SaaS.

Le vrai surcoût apparaît quand la conformité est ignorée au départ et rattrapée en urgence sur un produit déjà en production, avec des milliers de lignes de données historiques à trier, des sous-traitants déjà en place sans contrat encadrant, et des utilisateurs à qui il faut expliquer un changement de politique de confidentialité après coup. Ce rattrapage coûte systématiquement plus cher, en temps comme en crédibilité, que l’intégration dès le départ.

Que risque-t-on en cas de non-conformité ?

Le risque financier est réel et gradué. La CNIL peut prononcer une amende administrative jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour un manquement standard, et jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial pour les manquements les plus graves, comme un défaut de sécurité ayant conduit à une fuite de données, le montant le plus élevé entre les deux étant retenu (CNIL, quelles sanctions peuvent être prononcées). Une procédure de sanction simplifiée existe également pour les manquements plus courants et moins graves, avec une amende plafonnée à 20 000 euros, traitée plus rapidement qu’une procédure classique.

Pour une jeune entreprise, le risque le plus immédiat n’est généralement pas l’amende maximale, réservée aux manquements les plus graves ou récidivants : c’est la perte de confiance d’un client B2B qui, lors de son propre audit de conformité, découvre que son fournisseur SaaS n’a ni registre, ni contrat de sous-traitance, ni politique de confidentialité à jour. Sur le marché B2B, cette absence de préparation ferme des portes bien avant qu’une amende ne soit jamais évoquée : un cycle de vente qui s’arrête net à la question « pouvez-vous nous envoyer votre registre des traitements ? » coûte souvent plus cher, sur une année, que le temps qu’il aurait fallu pour le préparer en amont.

Nos propres produits traitent des données personnelles chaque jour, à l’échelle de milliers d’utilisateurs : nous appliquons ces mêmes principes de minimisation et de sécurité avant de les proposer aux SaaS que nous développons pour nos clients. Si vous cadrez un projet SaaS et voulez intégrer la conformité dès le départ plutôt que de la rattraper plus tard, parlons-en : c’est un sujet qui se traite en une conversation, pas en un chantier séparé après la mise en production.