SaaS : 7 points de conformité RGPD à vérifier

Le mois dernier, un fondateur de SaaS m'appelle. Il venait de perdre un contrat de 45 000 euros par an. Pas un problème de produit — son prospect enterprise avait validé la démo, le pricing passait, l'équipe était convaincue. Mais au moment de signer, le service achats a envoyé un questionnaire RGPD. Le fondateur n'avait pas de DPA. Il ne savait même pas ce que c'était.

Le deal est tombé. Deux mois de cycle de vente, effacés en un email.

Ce n'est pas un cas isolé. Depuis que j'audite des startups et des SaaS sur leur conformité RGPD, je vois le même scénario : le produit est bon, la traction est là, mais la vente B2B cale sur la conformité. Les clients enterprise ont des checklists. Si vous ne cochez pas les bonnes cases, ils passent au concurrent qui les coche.

Voici les 7 points qu'ils vérifient systématiquement.

Pourquoi vos clients enterprise vérifient votre conformité RGPD avant de signer

Il y a trois ans, la conformité RGPD dans un cycle de vente B2B, c'était une formalité. Un formulaire envoyé par le service juridique, que personne ne lisait vraiment. Vous cochiez quelques cases, vous envoyiez votre politique de confidentialité, ça passait.

C'est terminé.

Les grands comptes ont des DPO. Ils ont des processus d'évaluation des sous-traitants formalisés. Et surtout, ils ont des responsabilités : si votre SaaS traite les données de leurs employés ou de leurs clients, ils sont co-responsables en cas de fuite. La CNIL ne fait pas de distinction — si votre SaaS perd des données, votre client enterprise prend aussi.

Un fondateur m'a raconté qu'un prospect CAC 40 avait demandé son registre des traitements avant même le premier call technique. Pas après la démo. Pas pendant la négociation. Avant. Le DPO du prospect voulait savoir exactement quelles données le SaaS collectait, où elles étaient stockées, et qui y avait accès. Le fondateur a envoyé un fichier Excel à moitié rempli. Il n'a jamais eu de nouvelles.

La conformité RGPD pour un SaaS, ce n'est plus une question juridique. C'est un prérequis commercial.

Les 7 points de conformité RGPD que vos clients vont vérifier

1. Le DPA — l'accord que personne ne prépare

Le DPA, c'est le Data Processing Agreement — en français, l'accord de traitement des données. C'est le contrat qui encadre la relation entre votre client (le responsable de traitement) et votre SaaS (le sous-traitant).

Sans DPA, pas de relation contractuelle RGPD. Et sans relation contractuelle RGPD, pas de signature chez un client sérieux.

Votre client attend un document prêt à signer qui précise quelles données vous traitez, pourquoi, combien de temps vous les gardez, quelles mesures de sécurité vous appliquez, et ce qui se passe en cas de violation de données.

Le problème que je vois dans 9 cas sur 10 : le SaaS n'a pas de DPA du tout, ou il en a un copié d'un template américain qui ne couvre pas les spécificités du RGPD européen. Un DPA qui mentionne le Privacy Shield en 2026, j'en vois encore.

2. Le registre des traitements — la cartographie de vos données

Le registre des traitements est le document que la CNIL demande en premier lors d'un contrôle. C'est aussi le premier document que les DPO de vos prospects demandent.

Il doit lister chaque traitement de données personnelles : quelles données, pour quelle finalité, quelle base légale, quelle durée de conservation, quels destinataires.

Le piège classique : remplir le registre de manière déclarative. Écrire "nous collectons l'email pour la gestion du compte" alors que votre code envoie la géolocalisation, l'adresse IP et l'historique de navigation à quatre services tiers. C'est ce que je retrouve systématiquement en audit — un décalage entre ce que le registre déclare et ce que le code fait vraiment.

Un registre qui correspond à la réalité de votre code, c'est ce qui fait la différence entre un document qui rassure et un document qui vous expose.

3. La politique de confidentialité — votre vitrine publique

Votre politique de confidentialité est publique. N'importe qui peut la lire — et les DPO de vos prospects la lisent.

Ils cherchent la cohérence. Si votre politique dit "nous ne partageons pas vos données avec des tiers" et que votre page charge Google Analytics, Hotjar et Intercom, vous avez un problème de crédibilité. Un DPO repère ça en 30 secondes en ouvrant les outils développeur de son navigateur.

Je ne compte plus les politiques de confidentialité copiées d'un template qui ne reflètent pas du tout ce que l'application fait. C'est le point le plus visible — et le plus facile à vérifier pour un prospect.

4. La liste des sous-traitants

Votre SaaS utilise des services tiers : hébergement, emails transactionnels, analytics, support client, paiement. Chacun de ces services qui manipule des données personnelles est un sous-traitant au sens du RGPD.

Vos clients enterprise veulent la liste complète. Pas juste "AWS" et "Stripe". Ils veulent savoir quel service fait quoi, où les données sont hébergées, et si un transfert hors UE existe — et sur quelle base juridique.

Pourquoi cette exigence ? Parce que si l'un de vos sous-traitants subit une fuite, ce sont les données de votre client qui partent dans la nature. Et c'est votre client qui devra notifier ses propres utilisateurs.

Un point qui surprend toujours les fondateurs : les SDK et scripts côté client comptent aussi. Si vous intégrez un chat support, un outil d'analytics ou un pixel de tracking, ce sont des sous-traitants. Beaucoup de SaaS en ont 8 ou 10 sans même le réaliser — parce que c'est le développeur qui les a ajoutés, pas le fondateur.

5. Les mesures de sécurité techniques

Les clients enterprise ne vont pas auditer votre code. Enfin, certains le font — j'en ai vu. Mais la plupart vont poser des questions précises :

• Chiffrement des données au repos et en transit ?
• Authentification à deux facteurs disponible ?
• Politique de gestion des accès internes ?
• Sauvegardes et plan de reprise ?

Ce qu'ils attendent, c'est une fiche de sécurité synthétique — une à deux pages, factuelle, qui répond à ces points sans jargon inutile.

Si vous répondez "oui, c'est sécurisé" sans détails, le DPO va tiquer. Si vous répondez "données chiffrées en AES-256 au repos, TLS 1.3 en transit, MFA proposé, sauvegardes quotidiennes avec rétention 30 jours" — vous passez au niveau suivant de l'évaluation.

6. La gestion du consentement

Le bandeau cookies, c'est la partie visible. Pour un client enterprise, la question va plus loin : comment gérez-vous le consentement de leurs utilisateurs ?

Si votre SaaS est B2B2C — votre client utilise votre produit pour ses propres clients — le sujet devient critique. Qui recueille le consentement ? Sous quelle forme ? Comment le retirer ?

Ce que je vois souvent : un bandeau cookies installé vite fait, qui ne couvre pas tous les trackers. Ou pire — un consentement recueilli côté front mais jamais vérifié côté back. Le tracker se charge quand même, consentement ou pas. Un client enterprise qui fait sa due diligence RGPD repérera l'incohérence.

7. La procédure de suppression des données

"Si on résilie, est-ce que vous supprimez nos données ?" C'est la question que tout client enterprise pose. Et "oui bien sûr" ne suffit pas.

Il vous faut une procédure documentée : quel délai après résiliation, quelles données sont supprimées, lesquelles sont conservées (et pourquoi — obligations comptables par exemple), et comment le client peut vérifier que c'est fait.

Le point technique qui coince souvent : les sauvegardes. Vous supprimez les données de la base de production, mais elles restent dans vos backups pendant 90 jours. C'est normal — mais il faut le dire explicitement. Un DPO qui découvre que "supprimé" ne veut pas vraiment dire "supprimé partout immédiatement" perdra confiance.

Checklist RGPD SaaS — les 7 indispensables

Pour chaque point, ce que votre client attend et votre niveau de priorité si vous partez de zéro.

1. DPA signable — Document prêt, adapté à votre activité, conforme RGPD. Priorité maximale : sans ça, pas de deal B2B.

2. Registre des traitements — Liste complète, alignée avec ce que votre code fait réellement. Priorité haute : c'est le socle de tout le reste.

3. Politique de confidentialité — À jour, cohérente avec votre stack technique. Priorité haute : public, vérifiable en 30 secondes.

4. Liste des sous-traitants — Exhaustive, avec localisation et finalité. Priorité haute : le point qui bloque le plus les services achats.

5. Fiche de sécurité — Synthèse factuelle de vos mesures techniques. Priorité moyenne : important mais moins urgent que les documents contractuels.

6. Gestion du consentement — Conforme et vérifiable techniquement. Priorité moyenne : critique si vous êtes B2B2C.

7. Procédure de suppression — Documentée, avec délais clairs et périmètre. Priorité moyenne : demandé systématiquement, rarement bloquant avant signature.

Par où commencer si vous partez de zéro

Vous regardez cette liste et vous vous dites que c'est beaucoup. C'est moins compliqué qu'il n'y paraît — à condition de commencer dans le bon ordre.

Le DPA d'abord. C'est le document qui bloque les deals. Si vous ne devez faire qu'une chose cette semaine, c'est préparer un DPA solide.

Ensuite, le registre des traitements. Mais un vrai — pas un Excel déclaratif. Un registre qui reflète ce que votre application fait réellement. C'est là qu'un audit technique RGPD prend tout son sens : au lieu de deviner quelles données vous collectez, on analyse votre code et on produit un registre qui correspond à la réalité.

La politique de confidentialité vient après, parce qu'elle découle directement du registre. Si votre registre est juste, votre politique sera juste. Pour une approche complète, j'ai détaillé les étapes de mise en conformité RGPD dans le bon ordre.

Le reste — fiche de sécurité, gestion du consentement, procédure de suppression — se construit progressivement. L'essentiel, c'est de ne pas attendre qu'un prospect vous le demande pour commencer. Quand le questionnaire RGPD arrive, vous avez rarement plus d'une semaine pour répondre.

Le fondateur qui avait perdu son deal de 45 000 euros ? Il m'a rappelé deux mois plus tard. On a mis sa conformité RGPD en ordre — DPA, registre issu du code, politique de confidentialité alignée. Le deal suivant, il l'a signé. Le DPO du client lui a dit que c'était le dossier RGPD le plus propre qu'il avait vu chez un SaaS de cette taille.

La conformité RGPD, ça peut aussi devenir un avantage concurrentiel.