Les 4 documents RGPD obligatoires pour votre application

La semaine dernière, un fondateur de SaaS m'a dit : « On est conforme RGPD, on a mis une politique de confidentialité sur le site. » Il lui manquait 3 documents sur 4.

C'est un classique. En 15 ans d'audits techniques, j'ai vu des dizaines de dirigeants convaincus d'être en règle avec un seul document — souvent bâclé, en plus. Le RGPD ne demande pas « un document ». Il en exige quatre. Et chacun a un rôle précis, une audience différente, un contenu distinct.

Le registre RGPD, la politique de confidentialité, le bandeau cookies, les mentions légales. Voici ce que chacun contient, pourquoi il existe, et surtout — qui devrait le produire.

Le registre RGPD : le document que personne n'a

Le registre des traitements, c'est la fondation de votre conformité RGPD. Tout le reste en découle. Et c'est le document que je retrouve le moins chez mes clients.

Son rôle : lister chaque traitement de données personnelles réalisé par votre application. Quelles données vous collectez, pourquoi, pendant combien de temps, qui y accède, et sur quelle base légale.

Concrètement, pour chaque traitement, le registre doit indiquer les catégories de données (email, nom, adresse IP, géolocalisation…), la finalité du traitement, sa base légale (consentement, exécution d'un contrat, intérêt légitime), les durées de conservation, les destinataires — y compris vos sous-traitants — et les éventuels transferts hors Union européenne.

Un CEO me disait le mois dernier : « On ne traite pas beaucoup de données. » Après audit technique de son code, j'ai identifié 47 traitements. Quarante-sept. Emails, adresses IP, données de géolocalisation via le SDK mobile, cookies analytics, pixels de tracking, données de paiement transmises à Stripe, contacts synchronisés dans HubSpot, conversations Intercom, abonnés Mailchimp. Lui en avait déclaré 5 de mémoire.

C'est le problème fondamental du registre : un juriste ne peut lister que ce que vous lui déclarez. Et vous ne savez pas tout ce que votre propre application fait. Les intégrations tierces, les SDK embarqués, les cookies déposés par vos outils marketing — seul un audit du code source révèle la réalité. Sur mes 30 derniers audits, l'écart moyen entre les traitements déclarés et les traitements réels est de 1 à 8.

Et non, l'exception « moins de 250 salariés » ne vous dispense pas. Elle concerne les traitements purement occasionnels. Si vous avez une application avec des comptes utilisateurs, votre traitement est régulier par nature.

La politique de confidentialité : celle que tout le monde a, mal

La politique de confidentialité (ou privacy policy), c'est le document public. Celui que vos utilisateurs consultent pour savoir ce que vous faites de leurs données. Contrairement au registre qui est interne, celle-ci doit être accessible à tous.

Tout le monde en a une. Le problème : la plupart sont fausses.

Pourquoi ? Parce qu'elles ne sont pas construites à partir du registre des traitements. Elles sont copiées depuis un template trouvé sur internet, remplies à la va-vite, puis oubliées pendant deux ans. Le résultat : un document qui mentionne des traitements qui n'existent pas et passe sous silence ceux qui existent vraiment.

Votre politique de confidentialité devrait être le miroir de votre registre. Si le registre dit que vous utilisez Google Analytics avec une conservation de 14 mois, la privacy policy doit le mentionner. Si vous transmettez des données à un sous-traitant américain, elle doit expliquer sur quelles garanties repose ce transfert (clauses contractuelles types, décision d'adéquation, ou autre mécanisme).

Son contenu obligatoire : l'identité du responsable de traitement, les données collectées et leurs finalités, les bases légales, les durées de conservation, les droits des utilisateurs (accès, rectification, suppression, portabilité, opposition), la procédure concrète pour exercer ces droits, et la liste des sous-traitants impliqués.

Un test rapide que je recommande à mes clients : ouvrez votre privacy policy dans un onglet, et la liste de vos outils SaaS dans un autre. Vous utilisez Hotjar pour le heatmapping ? C'est mentionné ? Vous envoyez des notifications push via Firebase ? C'est écrit ? Chaque outil absent de votre politique de confidentialité est une non-conformité.

Le bandeau cookies : le plus visible, le plus mal fait

Le bandeau cookies est techniquement une obligation issue de la directive ePrivacy, pas du RGPD lui-même. En pratique, la CNIL les contrôle ensemble. Et c'est le premier truc qu'elle regarde, parce qu'il suffit de visiter votre site pour l'évaluer — pas besoin d'accéder à votre code.

J'ai audité une startup fintech qui avait copié-collé le bandeau cookies d'un concurrent plus établi. Le bandeau listait Adobe Analytics et Salesforce — qu'ils n'utilisaient pas. Il omettait Hotjar, Intercom et un pixel Meta — qu'ils utilisaient tous les jours. Un bandeau cookies mensonger, c'est pire que pas de bandeau du tout. Ça démontre que vous n'avez même pas vérifié ce que votre propre site dépose dans le navigateur de vos visiteurs.

Ce que doit faire un bandeau conforme :

• Offrir un vrai choix. « Refuser » doit être aussi visible et accessible que « Accepter ». Le bouton grisé en taille 8 au fond du bandeau, c'est fini.
• Lister les cookies par catégorie : strictement nécessaires, analytics, marketing, réseaux sociaux.
• Bloquer les cookies non essentiels avant le consentement. C'est le point que 80 % des sites ratent. Le bandeau s'affiche, mais Google Analytics, le pixel Facebook et Hotjar tournent déjà en arrière-plan.
• Permettre à l'utilisateur de revenir sur son choix à tout moment.

La CNIL a prononcé des mises en demeure et des amendes sur ce sujet précis tout au long de 2024 et 2025 — y compris contre des entreprises de taille moyenne qui pensaient passer entre les mailles du filet.

Si vous n'utilisez aucun cookie non essentiel (ni analytics, ni tracking, ni publicité), vous n'avez pas besoin de bandeau. C'est rare, mais ça existe.

Les mentions légales : le document le plus simple, le plus oublié

Les mentions légales sont imposées par la LCEN (loi pour la confiance dans l'économie numérique), pas par le RGPD. Mais la CNIL vérifie leur présence systématiquement lors d'un contrôle.

J'ai audité une app mobile avec 50 000 utilisateurs actifs. Pas de mentions légales. Nulle part — ni dans l'app, ni sur le site associé. Le fondateur ne savait même pas que c'était obligatoire pour une application mobile.

Le contenu tient en quelques lignes : raison sociale, forme juridique et capital, adresse du siège, numéro RCS et SIRET, nom du directeur de la publication, coordonnées de l'hébergeur, et un moyen de contact. C'est un document d'identité de votre entreprise. Pas de rédaction complexe, pas d'analyse juridique. Dix minutes de travail.

Le piège, c'est l'oubli pur et simple — surtout sur les applications mobiles. Sur un site web, on y pense vaguement parce qu'on voit un lien « mentions légales » en footer chez les autres. Sur une app mobile, rien ne vous y fait penser.

Pourquoi ces 4 documents ne fonctionnent pas en silos

Ce que peu de dirigeants réalisent : ces documents forment une chaîne. Le registre des traitements est la fondation. La politique de confidentialité en est la traduction publique. Le bandeau cookies gère le consentement pour une partie des traitements du registre. Les mentions légales identifient le responsable nommé dans les trois autres.

Si vous rédigez votre privacy policy sans avoir fait le registre d'abord, vous décrivez une réalité inventée. Si votre bandeau cookies ne correspond pas aux cookies réellement déposés, le consentement recueilli ne vaut rien. Tout se tient.

C'est pour ça que je commence systématiquement un audit de conformité RGPD par l'analyse du code source. Le code ne ment pas. Il montre les données collectées, les services tiers appelés, les cookies déposés. Le registre se construit à partir de cette réalité, et les trois autres documents en découlent naturellement.

Checklist : vos 4 documents RGPD sont-ils en règle ?

Pour chaque document, trois vérifications. Soyez honnête.

Registre des traitements

• Il existe dans un document formel (pas juste « dans ma tête »)
• Il a été mis à jour dans les 12 derniers mois
• Il a été construit à partir d'une analyse technique, pas uniquement de déclarations

Politique de confidentialité

• Elle est accessible depuis votre site et votre application
• Elle correspond au contenu réel de votre registre
• Elle mentionne tous vos sous-traitants et outils tiers actuels

Bandeau cookies

• Il offre un vrai choix (refuser est aussi simple qu'accepter)
• Les cookies non essentiels sont effectivement bloqués avant consentement
• Les catégories listées correspondent aux cookies réellement déposés

Mentions légales

• Elles sont présentes et accessibles
• Les informations sont à jour (adresse, hébergeur, dirigeant)
• Elles sont aussi présentes sur votre app mobile, pas seulement sur le site web

Votre score sur 12 : en dessous de 9, il y a du travail. En dessous de 6, vous êtes exposé en cas de contrôle CNIL.

Si vous ne savez pas par où commencer, le registre des traitements est la première brique. Tout le reste en découle. Et si vous voulez un registre qui reflète la réalité de votre code plutôt qu'une version approximative, c'est exactement ce que notre audit RGPD produit.