Registre des traitements : ce que la CNIL demande en premier

J'ai audité plus de 40 startups ces dernières années. Celles qui avaient un registre des traitements ? La majorité. Celles dont le registre correspondait à ce que leur code faisait vraiment ? Moins de 20%.

Le registre des traitements, c'est LE document de la conformité RGPD. Celui que la CNIL demande en premier lors d'un contrôle. Celui que les grands comptes exigent avant de signer. Et c'est aussi le document le plus mal compris — et le plus mal rempli.

C'est quoi, un registre des traitements ?

L'article 30 du RGPD dit : vous devez documenter l'ensemble de vos traitements de données personnelles. En clair, c'est l'inventaire de tout ce que votre entreprise fait avec les données de vos utilisateurs. Quelles données vous collectez. Pourquoi. Combien de temps vous les gardez. Qui y a accès.

Pensez-y comme un inventaire de stock, mais pour les données. Un commerçant sait ce qu'il a en rayon et en réserve. Le registre, c'est la même chose pour vos données personnelles.

Pour chaque traitement, il faut documenter :

• Les données collectées : nom, email, téléphone, adresse IP, géolocalisation, données de paiement…
• La finalité : pourquoi vous collectez ces données (fournir le service, envoyer des newsletters, mesurer l'audience…)
• La base légale : contrat, consentement, intérêt légitime…
• La durée de conservation : combien de temps vous gardez ces données
• Les destinataires : qui y a accès en interne, quels prestataires les traitent
• Les mesures de sécurité : comment vous protégez ces données

Ce n'est pas un document de 200 pages. Pour une startup, c'est 3 à 10 pages. Le problème n'est pas la longueur — c'est l'exactitude.

Et oui, c'est obligatoire. Officiellement pour les entreprises de plus de 250 salariés, mais en pratique, dès que vous traitez des données personnelles de façon régulière — donc dès que vous avez une app ou un site avec des utilisateurs — vous êtes concerné. La CNIL le dit elle-même : le registre est "un outil de pilotage" recommandé pour tous. Le jour où on vous le demande, il est trop tard pour se poser la question.

Pourquoi la CNIL le demande en premier

Quand la CNIL contrôle une entreprise, le premier document demandé — littéralement — c'est le registre des traitements. Pas la politique de confidentialité. Pas les CGU. Le registre.

Un de mes clients, une fintech, s'est fait contrôler après la plainte d'un utilisateur. Le questionnaire CNIL est arrivé par recommandé. Première ligne : "Veuillez nous transmettre votre registre des traitements." Ils n'en avaient pas. Le ton du contrôle était donné.

Pourquoi le registre d'abord ? Parce que c'est le seul document qui donne une vue complète de ce que vous faites avec les données. La politique de confidentialité, c'est ce que vous dites à vos utilisateurs — un document public, souvent rédigé par un avocat, souvent générique. Le registre, c'est ce que vous savez, vous, en interne. C'est votre outil de pilotage. Si le registre est absent ou vide, la CNIL sait que la conformité est de façade.

Et ce n'est pas que la CNIL. Les grands comptes l'exigent aussi.

Un client à moi développait un outil RH en SaaS. Un groupe du CAC 40 était prêt à signer — 120K€ par an. Le service achats a demandé le registre des traitements. Mon client n'en avait pas. Le deal est tombé en 48 heures. L'outil était bon. Le produit était solide. Mais sans registre, le service achats ne pouvait pas valider le prestataire. C'est aussi bête que ça.

Le registre, c'est votre carte d'identité RGPD. Sans lui, personne ne vous fait confiance.

Le vrai problème : la majorité des registres sont faux

J'utilise le mot "faux" à dessein. Pas "incomplets". Pas "perfectibles". Faux.

Le scénario classique : un fondateur télécharge le modèle CNIL (gratuit, 2 pages). Il le remplit en 20 minutes. "Données collectées : nom, email, mot de passe. Finalité : fournir le service. Durée de conservation : indéterminée." Voilà. Il coche la case mentalement et passe à autre chose.

Sauf que son application fait bien plus que ça.

J'ai audité une app e-commerce l'an dernier. Le registre déclarait 4 traitements. En analysant le code, j'en ai trouvé 11. Google Analytics envoyait des données comportementales à Google sans consentement explicite. Un SDK marketing stockait des adresses IP et des identifiants publicitaires. Le formulaire de contact conservait les messages indéfiniment dans une base séparée. Un système de logs enregistrait les adresses IP de chaque visiteur avec un historique de 2 ans.

Le fondateur ne savait pas que la moitié de ces traitements existaient. Ce n'est pas lui qui les avait mis en place — c'étaient des dépendances installées par son développeur. Une ligne dans un fichier de configuration, un package installé en 30 secondes, et vous avez un nouveau traitement de données que personne ne documente.

C'est là que le registre "déclaratif" touche ses limites. Vous déclarez ce que vous pensez faire. Votre code fait autre chose.

Registre déclaratif vs registre issu du code

Il y a deux façons de produire un registre des traitements. La différence entre les deux, c'est la différence entre un inventaire fait de mémoire et un inventaire fait en allant compter dans l'entrepôt.

Le registre déclaratif : un humain — le fondateur, un DPO, un avocat — remplit un formulaire en se basant sur sa compréhension de l'application. Il liste les traitements qu'il connaît. C'est rapide, c'est pas cher, et c'est presque toujours incomplet.

Le problème n'est pas la bonne volonté. C'est que personne ne peut lister de tête tous les traitements d'une application moderne. Il y a les traitements évidents (inscription, paiement, newsletter). Et il y a tous les autres : les cookies tiers, les trackers, les outils d'analytics, les logs serveur, les données transmises aux prestataires via des API, les données mises en cache.

Le registre issu de l'analyse du code : un auditeur technique passe dans votre codebase et identifie chaque point où une donnée personnelle est collectée, stockée, transmise ou supprimée. Le registre reflète ce que l'application fait réellement.

Ce que l'analyse du code révèle systématiquement :

• Des trackers et SDK tiers qui collectent des données sans que le fondateur le sache
• Des durées de conservation infinies — les données ne sont jamais supprimées
• Des données personnelles dans les logs serveur (IPs, emails, parfois des mots de passe en clair)
• Des transferts hors UE non documentés : hébergement US, CDN, outils SaaS américains
• Des données collectées "au cas où" sans aucune finalité définie

Un registre déclaratif, c'est mieux que rien. Mais en cas de contrôle CNIL, un registre qui ne correspond pas à la réalité technique de votre application, ça montre que vous n'avez pas fait le travail. Et la CNIL voit la différence.

Template : registre des traitements simplifié

Voici un modèle annoté. Pour chaque traitement de données dans votre application, remplissez une ligne :

Une startup classique a entre 5 et 15 traitements. Si vous en listez 2 ou 3, il en manque.

Les traitements qu'on oublie le plus souvent :

• Analytics : Google Analytics, Mixpanel, Hotjar — chacun est un traitement distinct
• Emails transactionnels : SendGrid, Mailchimp — ils traitent les adresses email de vos utilisateurs
• Logs serveur : votre hébergeur conserve des IPs, des URLs visitées, des user-agents
• Support client : Intercom, Zendesk, un simple formulaire — les messages contiennent des données personnelles
• Paiements : Stripe, PayPal — données financières et d'identité

Comment produire un registre qui tient la route

Le template CNIL est un bon point de départ pour structurer le document. Mais le remplir sans analyse technique, c'est faire un inventaire sans regarder dans l'entrepôt.

Trois options, selon votre budget et votre situation :

Option 1 — Le faire soi-même (gratuit, risqué). Téléchargez le modèle CNIL. Listez tous les formulaires de votre app, tous les outils tiers, toutes les bases de données. Demandez à votre développeur de lister les SDK et dépendances qui touchent aux données utilisateurs. Vous raterez les traitements invisibles, mais c'est un début.

Option 2 — Le faire faire par un DPO ou un avocat (1000-3000€). Ils connaissent le cadre juridique sur le bout des doigts. Mais ils ne lisent pas le code. Le registre sera juridiquement propre, techniquement incomplet. C'est le profil de 80% des registres que je vois.

Option 3 — Un audit technique RGPD avec analyse du code. Un auditeur analyse votre codebase, identifie tous les traitements réels, et produit un registre qui reflète votre application telle qu'elle est. C'est la seule méthode qui garantit un registre exhaustif.

Et surtout : un registre n'est pas un PDF qu'on range dans un dossier. Chaque nouvelle fonctionnalité, chaque nouvel outil, chaque mise à jour peut créer un nouveau traitement. Un registre non maintenu est périmé en quelques mois. Si vous ajoutez Intercom pour le support, c'est un nouveau traitement. Si vous migrez vers un hébergeur américain, vos transferts hors UE changent. Le registre doit vivre avec votre produit.

Ce que la CNIL attend vraiment

Un point que personne ne mentionne : la CNIL ne demande pas un registre parfait. Elle demande un registre honnête.

Un registre qui liste 8 traitements avec des durées de conservation précises et des mesures de sécurité documentées, c'est crédible — même s'il en manque un ou deux. Un registre qui liste 2 traitements vagues avec "durée : indéterminée" partout, ça dit à la CNIL que vous n'avez pas fait l'effort. La nuance compte.

Vous n'avez pas besoin d'un document juridique de 50 pages rédigé par un cabinet. Vous avez besoin d'un document sincère qui montre que vous savez ce que votre application fait avec les données de vos utilisateurs.

Si ce n'est pas le cas — si vous ne savez pas vraiment ce que votre code fait avec les données personnelles — c'est le bon moment pour le découvrir. Le registre des traitements fait partie des 6 obligations RGPD fondamentales, et c'est celle par laquelle tout commence. Un audit RGPD technique analyse votre code, identifie les traitements réels, et produit un registre sur lequel vous pouvez vous appuyer — que ce soit face à la CNIL, face à un grand compte, ou face à un investisseur en due diligence.

Le registre des traitements n'est pas un exercice administratif. C'est la preuve que vous maîtrisez votre propre produit.