Le modèle de registre RGPD de la CNIL a été téléchargé plus de 500 000 fois. Sur les 40+ registres que j'ai vérifiés en audit cette année, pas un seul ne correspondait à ce que le code faisait réellement.
Pas un seul.
Le modèle n'est pas mauvais — les colonnes sont les bonnes. Le problème, c'est qu'il demande ce que vous pensez faire avec les données de vos utilisateurs. Pas ce que votre application fait vraiment.
Ce qu'est un registre des traitements (et ce que vous avez probablement à la place)
Le registre des traitements, c'est le document qui liste tout ce que votre entreprise fait avec les données personnelles. Pour chaque traitement : quelles données, pourquoi, combien de temps, qui y accède, où elles sont stockées. L'article 30 du RGPD le rend obligatoire.
Et contrairement à ce qu'on lit sur certains blogs juridiques, l'exemption pour les entreprises de moins de 250 salariés est quasi inapplicable — dès que vous avez une app avec des utilisateurs qui se connectent, vous êtes concerné.
Ce que les guides ne vous disent pas : le registre n'est pas un document qu'on range dans un tiroir. C'est le premier document que la CNIL demande en cas de contrôle. C'est aussi ce qu'un grand compte exige avant de signer un contrat B2B. Et c'est différent de votre politique de confidentialité — celle-ci est le texte public que vos utilisateurs lisent. Le registre, c'est votre inventaire interne, censé être le reflet exact de ce que fait votre produit.
Si votre registre a été rempli en réunion sans que personne n'ouvre le code, vous avez une déclaration d'intention, pas un registre. C'est la première obligation RGPD, et c'est celle que je vois le plus souvent bâclée.
Le modèle CNIL : bon squelette, mauvais remplissage
Je n'ai rien contre le modèle de la CNIL. La structure est claire. Les colonnes sont pertinentes. Si vous partez de zéro, téléchargez-le.
Le problème, c'est ce qui se passe après.
En général, quelqu'un — le fondateur, un DPO externe, parfois un stagiaire — ouvre le fichier Excel et le remplit de mémoire. "On collecte le nom, l'email, le numéro de téléphone." "On garde les données 3 ans." "Elles sont stockées en France."
Un de mes clients avait un registre impeccable. 12 pages, bien structuré, rempli par un DPO externe facturé 4 000€. En auditant son code, j'ai trouvé 7 traitements qui ne figuraient nulle part. Le formulaire de contact envoyait les données à un outil analytics tiers non déclaré. Le système de logs stockait les adresses IP pendant 2 ans au lieu des 12 mois déclarés. Trois services faisaient transiter les données par les États-Unis — le registre déclarait "France uniquement".
4 000€ pour un document fictif.
Les 5 décalages que je retrouve entre le registre et le code
Sur chaque audit, je compare le registre avec ce que le code fait réellement. Les mêmes décalages reviennent à chaque fois.
Des traitements entiers qui manquent. C'est le plus fréquent. Le registre liste 8 traitements, le code en exécute 11. Les oubliés classiques : le tracking analytics (Segment, Mixpanel), les backups automatiques vers un bucket S3 dans une région non déclarée, un système de scoring interne qui croise des données entre plusieurs tables. Sur mes audits, le décalage moyen est de 3 à 5 traitements non déclarés.
Les durées de conservation : de la pure fiction. Le registre dit "12 mois". Le code n'a aucun mécanisme de suppression. Les données sont là depuis le premier jour de la prod. En 3 ans d'audits, je n'ai vu qu'une seule startup avec un vrai cron job de purge qui correspondait à ce que son registre déclarait. Une seule.
Ensuite, il y a les sous-traitants non déclarés. Le registre liste Stripe et AWS. Le code utilise aussi Cloudflare (qui voit passer toutes les requêtes), SendGrid pour les emails, Sentry pour le monitoring — et Sentry capture des données utilisateur dans les logs d'erreur, ce que personne ne réalise. Sans parler des outils installés "pour tester" qui tournent encore en prod 8 mois plus tard.
La localisation des données. "Stockées en France" est la réponse par défaut de 9 registres sur 10. En pratique : la base est peut-être en France, mais le CDN est mondial, les emails transitent par les US, les logs d'erreur sont chez un provider américain, et les backups sont dans une région AWS que personne n'a vérifiée.
Le dernier décalage est plus subtil : les bases légales sont mal attribuées. Le registre coche "consentement" pour tout. En réalité, certains traitements relèvent du contrat, d'autres de l'intérêt légitime. Et pour ceux qui nécessitent vraiment un consentement, le code n'a aucun mécanisme qui vérifie si l'utilisateur a dit oui avant d'envoyer les données au tiers.
Un registre faux est pire que pas de registre
C'est contre-intuitif, mais un registre qui ne correspond pas à la réalité peut aggraver votre situation.
La CNIL ne vérifie pas seulement que le registre existe. Elle vérifie qu'il colle à ce que votre application fait. Un registre inexact, ça prouve que vous connaissez vos obligations mais que vous les avez bâclées. C'est de la négligence documentée — exactement ce qui fait monter les sanctions.
J'ai vu ça jouer aussi côté business. Une startup SaaS RH discutait avec un groupe du CAC 40 pour un contrat à 120K€/an. Le prospect demande le registre. Le fondateur envoie son Excel. Le DSI du grand compte fait une démo du produit et pose une question :
"Vous déclarez stocker les données en France, mais votre CDN Cloudflare fait transiter les requêtes par les US. C'est dans votre registre ?"
Ce n'était pas dans le registre. Deal terminé en 48 heures.
Un investisseur pendant sa due diligence technique posera exactement les mêmes questions. Et il aura quelqu'un de technique pour vérifier.
Votre app a ces failles ?
Registre, politique de confidentialité et rapport de conformité issus de votre code.
Obtenir ma conformité RGPDPourquoi Excel ne tient pas la route dans la durée
Admettons que votre registre Excel soit parfaitement exact aujourd'hui. Dans combien de temps sera-t-il obsolète ?
Un client m'a montré son registre. Dernière mise à jour : 14 mois. Depuis, son équipe avait livré 6 sprints. Ajout du paiement en ligne. Chat en direct intégré. Connexion à HubSpot. Migration de l'hébergement. Rien de tout ça dans le registre.
Plus votre produit avance vite, plus le registre déclaratif prend du retard. Et personne ne met à jour un fichier Excel après chaque sprint. Ce n'est dans le workflow de personne — ni du product manager, ni du dev, ni du fondateur. Le registre est obsolète dès la première feature livrée après sa rédaction.
C'est structurel, pas un problème de discipline. Un document statique ne peut pas suivre un produit qui bouge.
Registre déclaratif vs registre technique : la comparaison
| # | Critère | Registre Excel (déclaratif) | Registre issu du code |
|---|---|---|---|
| 1 | Source des informations | Mémoire, réunions, suppositions | Analyse du code et des configurations |
| 2 | Fiabilité | Dépend de qui l'a rempli | Reflète ce que l'app fait réellement |
| 3 | Mise à jour | Manuelle — rarement faite | Liée aux évolutions du produit |
| 4 | Traitements oubliés | Fréquent (3 à 5 en moyenne) | Détectés par l'analyse |
| 5 | Tenue en contrôle CNIL | Risqué si incohérent | Cohérent par construction |
| 6 | Utilité en due diligence / B2B | Faible — vérifiable | Défendable techniquement |
| 7 | Coût | Gratuit (mais potentiellement très cher) | 1 500–3 000€ audit inclus |
La ligne "coût" mérite qu'on s'y arrête. Oui, le modèle Excel est gratuit. Mais un registre faux qui fait capoter un deal à 6 chiffres ou qui aggrave une sanction CNIL, ça coûte combien ? Un registre issu d'un audit technique coûte entre 1 500 et 3 000€. C'est un document défendable devant la CNIL comme devant un prospect B2B.
Ce que change un registre issu du code
Un registre issu du code, ça veut dire qu'un auditeur technique a ouvert votre application et a listé ce qu'elle fait réellement avec les données personnelles. Pas ce que quelqu'un a déclaré en réunion.
Concrètement, on analyse les endpoints API qui reçoivent des données utilisateur, les tables de base de données et leurs champs, les intégrations tierces et ce qu'elles reçoivent, les mécanismes de rétention et de purge (ou leur absence), les logs et ce qu'ils capturent.
Un de mes clients s'est fait contrôler par la CNIL après une plainte d'un utilisateur. Il avait fait cet exercice — son registre reflétait exactement ce que le code faisait. La CNIL a vérifié, constaté la cohérence. Dossier classé en 3 semaines. Le registre lui avait coûté 2 000€. Le contrôle classé rapidement lui a évité 6 mois de procédure et une amende potentielle.
Le registre RGPD n'est pas un exercice administratif. C'est un outil de pilotage qui doit coller à votre produit. Si personne n'a regardé votre code pour le produire, il ne reflète pas la réalité — et c'est exactement ce que la CNIL ou un prospect vérifiera.
Le point de départ : un audit RGPD technique qui analyse ce que votre application fait réellement avec les données. C'est la seule façon d'avoir un registre qui tient — face à la CNIL, face à un prospect, face à un investisseur.