Le mois dernier, un fondateur m'a envoyé son registre des traitements. Trois lignes. "Gestion des comptes", "Paiement", "Newsletter". Son app collecte des données dans douze endroits différents.
Ce n'est pas un cas isolé. Sur les 30+ audits RGPD que j'ai réalisés ces deux dernières années, pas un seul registre reçu ne reflétait ce que l'application faisait réellement. Le problème n'est pas la mauvaise volonté. C'est que personne ne montre à quoi ressemble un registre correctement rempli. La CNIL fournit un template. Il est vide. Et entre un tableau vide et un registre complet, il y a un gouffre.
Voici un exemple concret, annoté, basé sur un cas réel anonymisé : un SaaS B2C avec quelques milliers d'utilisateurs.
Ce qu'est un registre des traitements (en 30 secondes)
Le registre des traitements, c'est le document qui liste tout ce que votre application fait avec des données personnelles. Chaque "traitement" = une action sur des données : les collecter, les stocker, les transmettre, les analyser.
Pour chaque traitement, vous devez indiquer : quelles données, pourquoi, combien de temps, qui y accède, et sur quelle base légale. C'est l'article 30 du RGPD. C'est le premier document que la CNIL demande en cas de contrôle. C'est aussi ce qu'un grand compte exigera avant de signer avec vous.
Si vous n'êtes pas au clair sur les 6 obligations RGPD, commencez par là. Le registre est l'obligation numéro 1.
Ce que le registre n'est pas : un document juridique de 50 pages. C'est un tableau. Structuré, précis, mais un tableau.
Le contexte de cet exemple
L'entreprise : un SaaS B2C de planification de repas. App web + mobile, ~4 000 utilisateurs, équipe de 8 personnes. Hébergement AWS (Irlande). Paiement via Stripe. Emailing via Brevo. Analytics via Plausible.
J'ai anonymisé les noms, mais les données, les durées et les bases légales sont celles d'un vrai registre produit après audit du code source. C'est important : ce registre a été construit en analysant ce que l'app fait techniquement, pas en demandant au fondateur ce qu'il pense qu'elle fait.
L'exemple complet : 7 traitements, ligne par ligne
| # | Traitement | Finalité | Données collectées | Personnes concernées | Base légale | Destinataires | Durée de conservation |
|---|---|---|---|---|---|---|---|
| 1 | Gestion des comptes | Créer et gérer les comptes utilisateurs | Nom, prénom, email, mot de passe (hashé), date d'inscription | Utilisateurs de l'app | Exécution du contrat | Équipe interne (support, tech) | Durée du compte + 3 ans après suppression |
| 2 | Facturation | Traiter les paiements et satisfaire les obligations comptables | Nom, adresse de facturation, historique de paiement | Utilisateurs payants | Obligation légale (Code de commerce) | Stripe (sous-traitant), comptable externe | 10 ans (obligation comptable) |
| 3 | Personnalisation du service | Adapter les recommandations de recettes | Préférences alimentaires, allergies déclarées, historique d'utilisation | Utilisateurs de l'app | Exécution du contrat | Équipe interne | Durée du compte |
| 4 | Newsletter marketing | Envoyer des emails promotionnels et des conseils | Email, prénom | Utilisateurs ayant donné leur consentement | Consentement | Brevo (sous-traitant emailing) | Jusqu'au retrait du consentement |
| 5 | Support client | Répondre aux demandes d'assistance | Nom, email, contenu des échanges | Utilisateurs ayant contacté le support | Intérêt légitime | Équipe support, outil de ticketing (Crisp) | 2 ans après clôture du ticket |
| 6 | Mesure d'audience | Comprendre l'usage de l'app pour l'améliorer | Pages visitées, durée de session, type d'appareil, pays (sans IP) | Visiteurs du site et utilisateurs | Intérêt légitime | Plausible (hébergé UE, sans cookies) | 24 mois |
| 7 | Logs techniques et sécurité | Détecter les intrusions et résoudre les bugs | Adresse IP, user-agent, timestamps, actions effectuées | Tous les visiteurs et utilisateurs | Intérêt légitime (sécurité du système) | Équipe technique, AWS CloudWatch | 12 mois |
Ce que chaque colonne veut dire (et où ça coince)
La finalité : pourquoi vous collectez ces données
C'est la raison d'être du traitement. "Gérer les comptes", "Facturer", "Envoyer la newsletter". Ça paraît simple, mais c'est là que la triche commence. J'ai vu des registres avec une finalité unique — "Fonctionnement du service" — pour couvrir 8 traitements différents. La CNIL ne marche pas. Une finalité = un traitement. Si vous envoyez des emails marketing et des emails transactionnels, ce sont deux traitements distincts.
La base légale : ce qui vous autorise à traiter ces données
C'est le champ qui stresse le plus. Il y a 6 bases légales dans le RGPD, mais en pratique, vous n'en utilisez que 3 ou 4 :
- Exécution du contrat — pour tout ce qui est nécessaire au service que l'utilisateur a acheté. Pas besoin de consentement pour stocker le nom de quelqu'un qui a créé un compte.
- Consentement — pour tout ce qui n'est pas strictement nécessaire. Newsletter, cookies marketing, partage avec des partenaires.
- Obligation légale — pour ce que la loi vous impose. Garder les factures 10 ans, c'est le Code de commerce, pas le RGPD.
- Intérêt légitime — pour les traitements qui servent votre intérêt business sans porter atteinte aux droits des personnes. Support client, analytics, sécurité.
L'erreur classique : mettre "consentement" partout. Si vous mettez "consentement" comme base légale pour la gestion des comptes, ça veut dire que l'utilisateur peut retirer son consentement à tout moment — et vous devez supprimer son compte immédiatement. Ce n'est pas ce que vous voulez. La bonne base légale ici, c'est l'exécution du contrat.
La durée de conservation : le champ que tout le monde bâcle
Sur les registres que je reçois, la colonne durée de conservation contient soit "indéfini", soit rien du tout. Les deux sont des erreurs.
Le RGPD dit : vous ne gardez les données que le temps nécessaire à la finalité. Concrètement :
- Comptes actifs : durée du compte + un délai après suppression (3 ans est un standard raisonnable, le temps de gérer d'éventuels litiges)
- Factures : 10 ans, c'est la loi
- Logs de sécurité : 12 mois est le standard ANSSI
- Analytics : la CNIL recommande 25 mois maximum
- Newsletter : jusqu'au désabonnement, puis suppression
"Indéfini" n'est jamais une réponse acceptable. Si vous ne savez pas combien de temps garder une donnée, c'est que vous n'avez pas réfléchi à pourquoi vous la collectez.
Les destinataires : qui accède aux données
Pas juste votre équipe. Vos sous-traitants aussi. Stripe voit les données de paiement. Brevo voit les emails. AWS héberge tout. Chacun doit être listé, et vous devez avoir un DPA (Data Processing Agreement) signé avec chacun d'eux.
Le piège que je trouve dans presque chaque audit : des outils ajoutés par un développeur — un tracker analytics, un outil de monitoring, un pixel marketing — dont le fondateur n'a même pas connaissance. Ces outils sont des destinataires. Ils doivent figurer dans le registre.
Votre app a ces failles ?
Registre, politique de confidentialité et rapport de conformité issus de votre code.
Obtenir ma conformité RGPDLes 4 erreurs que je retrouve systématiquement
1. Le registre déclaratif. Le fondateur (ou pire, un stagiaire) remplit le registre en se basant sur ce qu'il croit que l'app fait. Sans regarder le code. Résultat : 4 traitements déclarés alors que l'app en effectue 11. Les pixels Facebook, le tracking Hotjar ajouté "pour tester", les logs qui stockent des données personnelles — tout ça est invisible dans un registre déclaratif.
2. Les durées de conservation absentes. "On supprime quand on y pense." Ce n'est pas une politique de conservation. Chez un client, j'ai trouvé des données d'utilisateurs supprimés depuis 4 ans toujours présentes en base. Personne ne s'en était rendu compte.
3. Le copier-coller d'un autre registre. Un fondateur m'a montré un registre avec un traitement "Gestion de la paie des salariés". Son app est un outil de gestion de photos. Il n'a pas de salariés, juste deux associés. Il avait copié un modèle trouvé en ligne sans l'adapter. La CNIL n'est pas dupe.
4. La base légale "consentement" partout. Par excès de prudence, certains mettent "consentement" sur chaque ligne. C'est contre-productif : ça vous impose de pouvoir gérer le retrait du consentement pour chaque traitement, y compris ceux qui sont nécessaires au fonctionnement du service. Ça crée plus de problèmes que ça n'en résout.
Comment vérifier si votre registre est fiable
Votre registre ne vaut quelque chose que s'il correspond à ce que votre application fait réellement. Pas à ce que vous pensez qu'elle fait.
Cinq questions pour tester votre registre :
- Avez-vous vérifié dans le code quels trackers, pixels et SDK tiers sont présents ? Pas juste demandé à l'équipe — vérifié.
- Chaque durée de conservation a-t-elle un mécanisme technique pour la respecter ? Un champ "12 mois" dans le registre sans script de purge automatique, c'est un vœu pieux.
- Votre registre mentionne-t-il les logs ? Les logs techniques contiennent des adresses IP et des données de session. C'est un traitement. 90% des registres que je reçois les oublient.
- Avez-vous listé tous vos sous-traitants ? Pas juste les gros (AWS, Stripe). Aussi l'outil de chat en ligne, le service de monitoring, le formulaire de contact.
- Votre registre a-t-il été mis à jour depuis que vous avez ajouté une fonctionnalité ? Un registre qui date de 6 mois et une app qui évolue chaque semaine, ça ne colle pas.
Si vous répondez "non" à 2 de ces questions, votre registre n'est pas fiable. Il existe sur le papier, mais il ne vous protège pas.
Le registre est un point de départ, pas une fin
Un registre rempli correctement, c'est la fondation de votre conformité RGPD. Sans ça, votre politique de confidentialité est fausse (elle est censée s'appuyer sur le registre), vos réponses aux demandes d'accès sont incomplètes, et votre capacité à réagir en cas de fuite est compromise.
Mais un registre seul ne suffit pas. Il doit être vivant — mis à jour à chaque nouvelle fonctionnalité, chaque nouveau sous-traitant, chaque changement de durée de conservation. Et surtout, il doit refléter la réalité technique de votre application.
C'est pour ça que les registres les plus solides que je produis viennent d'un audit technique du code. Je lis le code source, je repère chaque point de collecte, chaque transmission à un tiers, chaque stockage — et je construis le registre à partir de là. Pas l'inverse.
Si vous n'avez pas de registre, commencez avec l'exemple ci-dessus. Adaptez-le à votre contexte. Mais ne vous arrêtez pas à la déclaration : vérifiez que ce que vous écrivez correspond à ce que votre app fait vraiment.