Registre des traitements RGPD : modèle gratuit et exemple rempli pour un e-commerce

Quand la CNIL contrôle une entreprise, elle ne commence presque jamais par lire votre politique de confidentialité. Elle demande votre registre des traitements. Ce document interne, prévu par l'article 30 du RGPD, est la colonne vertébrale de votre conformité : il recense tous les usages que vous faites des données personnelles, de la commande client jusqu'aux statistiques de visites. Sans registre, impossible de prouver que vous savez ce que vous faites des données — et donc impossible de prouver votre conformité.

Bonne nouvelle : tenir un registre n'a rien de sorcier. Il ne s'agit pas d'un document juridique compliqué, mais d'un tableau structuré que vous pouvez maintenir dans Excel, Notion, Airtable ou même un Google Sheet. L'essentiel, c'est qu'il existe, qu'il soit à jour, et qu'il couvre tous vos traitements. Cet article vous donne la méthode, le contenu attendu, et un exemple complet pour un e-commerce type.

Pourquoi le registre est-il obligatoire ?

L'article 30 du Règlement général sur la protection des données impose à tout responsable de traitement, et à son sous-traitant, de tenir un registre des activités de traitement effectuées sous sa responsabilité. Le texte est très clair : le registre doit se présenter par écrit (y compris sous forme électronique) et être mis à la disposition de l'autorité de contrôle — la CNIL en France — sur simple demande.

Le registre joue trois rôles :

• Outil de pilotage interne : il vous oblige à recenser exhaustivement les données que vous collectez. Beaucoup d'entreprises découvrent à cette occasion des traitements oubliés (un outil de chat, un formulaire newsletter, un export vers un CRM…).
• Preuve de conformité : le RGPD repose sur le principe d'« accountability ». Vous devez non seulement être conforme, mais aussi pouvoir le démontrer. Le registre est cette démonstration.
• Base de toute documentation publique : votre politique de confidentialité et vos clauses contractuelles découlent directement du registre.

Le cas (rare) de la dispense

L'article 30, paragraphe 5, prévoit une dispense pour les entreprises de moins de 250 salariés. Mais cette dispense est conditionnée à trois critères cumulatifs : le traitement doit être occasionnel, il ne doit pas porter sur des données sensibles, et il ne doit pas comporter de risque pour les droits et libertés des personnes.

En pratique, dès que vous gérez des clients récurrents, une paie, un fichier de prospects ou des données de santé, vous sortez du cadre de la dispense. La CNIL le reconnaît elle-même : l'exemption ne s'applique qu'à des « cas très particuliers ». Pour un e-commerce, une agence, un SaaS ou même un blog avec une newsletter, le registre est obligatoire.

Registre du responsable de traitement vs registre du sous-traitant

Une confusion fréquente : il existe deux registres distincts.

• Le registre du responsable de traitement (article 30.1) recense les traitements que vous décidez de mettre en œuvre, pour vos propres finalités. Exemple : la gestion des commandes de votre boutique en ligne.
• Le registre du sous-traitant (article 30.2) recense les traitements que vous effectuez pour le compte d'un client. Exemple : si vous êtes une agence web qui héberge le formulaire de contact d'un client, vous êtes sous-traitant et vous devez documenter, par client, les catégories de traitements réalisés.

Beaucoup d'entreprises sont les deux à la fois. Une agence marketing est responsable de traitement pour ses propres clients (CRM, paie), et sous-traitante pour ses missions clients (envoi d'emailings, gestion d'audience). Dans ce cas, deux registres parallèles sont à tenir.

Le contenu attendu d'une fiche de traitement

Pour chaque traitement inscrit au registre, l'article 30 et les recommandations CNIL exigent les rubriques suivantes :

• Nom du traitement : un intitulé court et parlant (« Gestion des commandes », « Newsletter », « Vidéosurveillance des locaux »).
• Finalité(s) : l'objectif poursuivi. Soyez précis : « gérer la relation client » est trop vague, préférez « traiter les commandes, livrer les produits, gérer le service après-vente ».
• Base légale : exécution contractuelle, obligation légale, consentement, intérêt légitime, mission d'intérêt public ou sauvegarde des intérêts vitaux. C'est l'un des six fondements de l'article 6 du RGPD.
• Catégories de personnes concernées : clients, prospects, salariés, candidats, visiteurs du site…
• Catégories de données : identité, coordonnées, données de connexion, données de paiement, données de localisation… Mentionnez explicitement les données sensibles (santé, opinions, biométrie) si elles existent — leur traitement obéit à des règles renforcées (article 9).
• Destinataires : qui accède aux données ? Vos services internes, vos sous-traitants (hébergeur, prestataire d'emailing, comptable…), des organismes publics (URSSAF, impôts…).
• Transferts hors UE : précisez le pays et le mécanisme de garantie (décision d'adéquation, clauses contractuelles types, certification Data Privacy Framework pour les États-Unis).
• Durée de conservation : indiquez les durées en base active, puis en archivage intermédiaire. Exemple : « clients : 3 ans après la dernière commande en base active, 10 ans pour les factures en archivage légal ».
• Mesures de sécurité : chiffrement TLS, contrôle des accès, sauvegardes, journalisation, sensibilisation des équipes…

Quel format choisir ?

L'article 30 impose un format écrit, électronique ou papier. Aucun outil spécifique n'est requis. Vous pouvez utiliser :

• Le modèle officiel de la CNIL au format tableur (.ods), conçu pour les TPE-PME et téléchargeable gratuitement.
• Un tableur Excel ou Google Sheets que vous structurez selon les rubriques ci-dessus.
• Une base Notion ou Airtable avec une fiche par traitement.
• Un outil dédié (Dastra, Leto, Witik, Dataventure…) qui automatise la mise à jour et la génération de documents.

Le critère décisif n'est pas le support, mais la discipline de mise à jour. Un registre Notion bien tenu vaut mieux qu'une solution premium oubliée dans un coin du Drive.

Exemple rempli : un e-commerce français type

Pour rendre tout cela concret, voici à quoi ressemble le registre d'un e-commerce moyen, qui vend des produits physiques en France et utilise les outils classiques du marché. Cinq traitements typiques.

1. Gestion des commandes et comptes clients

• Finalité : créer et gérer le compte client, traiter les commandes, assurer la livraison et le service après-vente.
• Base légale : exécution du contrat de vente (article 6.1.b).
• Personnes concernées : clients ayant passé commande, titulaires d'un compte sur le site.
• Données : identité (nom, prénom), coordonnées (e-mail, téléphone, adresse postale), données de commande, historique d'achats, identifiant de compte, mot de passe haché.
• Destinataires : service client interne, prestataire d'hébergement (OVH), solution e-commerce (Shopify), transporteur (Colissimo, Chronopost), prestataire de paiement (Stripe).
• Transferts hors UE : Shopify et Stripe — clauses contractuelles types et certification Data Privacy Framework.
• Durée de conservation : 3 ans à compter de la dernière commande pour les données actives, puis archivage intermédiaire pendant 10 ans pour les factures (obligation comptable).
• Mesures de sécurité : HTTPS, hachage des mots de passe, authentification à double facteur pour l'admin, sauvegardes quotidiennes chiffrées.

2. Newsletter et prospection commerciale

• Finalité : envoyer des informations commerciales et des offres promotionnelles aux abonnés.
• Base légale : consentement (article 6.1.a) pour les prospects, intérêt légitime ou « soft opt-in » pour les clients existants sur des produits analogues.
• Personnes concernées : visiteurs du site ayant coché la case d'abonnement, clients ayant accepté de recevoir des communications.
• Données : adresse e-mail, prénom, centre d'intérêt déclaré, statistiques d'ouverture et de clic.
• Destinataires : équipe marketing interne, prestataire d'emailing (Brevo, Mailchimp).
• Transferts hors UE : Mailchimp si utilisé — Data Privacy Framework.
• Durée de conservation : 3 ans à compter du dernier contact actif (clic, ouverture).
• Mesures de sécurité : accès à l'outil restreint, double opt-in à l'inscription, lien de désabonnement dans chaque message.

3. Comptabilité et facturation

• Finalité : émettre les factures, tenir la comptabilité, déclarer la TVA et l'impôt sur les sociétés.
• Base légale : obligation légale (article 6.1.c — Code de commerce et Code général des impôts).
• Personnes concernées : clients particuliers et professionnels, fournisseurs.
• Données : identité, raison sociale, numéro SIRET, adresse de facturation, numéro de TVA, montants, mode de paiement.
• Destinataires : expert-comptable, commissaire aux comptes, administration fiscale en cas de contrôle.
• Transferts hors UE : aucun.
• Durée de conservation : 10 ans à compter de la clôture de l'exercice (article L.123-22 du Code de commerce).
• Mesures de sécurité : logiciel comptable hébergé en France, accès limité au dirigeant et à l'expert-comptable.

4. Mesure d'audience et amélioration du site

• Finalité : analyser la fréquentation du site, mesurer la performance des pages, optimiser l'expérience utilisateur.
• Base légale : consentement (article 6.1.a) si l'outil n'est pas exempté par la CNIL ; intérêt légitime si l'outil est configuré en mode exempté (Matomo anonymisé, par exemple).
• Personnes concernées : visiteurs du site.
• Données : adresse IP (tronquée si exemptée), pages visitées, durée de la session, type d'appareil et de navigateur, source du trafic.
• Destinataires : équipe marketing interne, prestataire analytics (Matomo, Plausible, Google Analytics 4).
• Transferts hors UE : Google Analytics 4 — Data Privacy Framework et configuration spécifique requise.
• Durée de conservation : 13 mois pour les traceurs (recommandation CNIL), 25 mois pour les données statistiques agrégées.
• Mesures de sécurité : bandeau de consentement conforme, anonymisation des IP, accès restreint au tableau de bord analytics.

5. Support client (chat, tickets, FAQ)

• Finalité : répondre aux questions des visiteurs et clients, traiter les réclamations.
• Base légale : intérêt légitime (article 6.1.f) pour les prospects, exécution du contrat (article 6.1.b) pour les clients.
• Personnes concernées : visiteurs ayant ouvert un chat ou envoyé un ticket, clients ayant contacté le service après-vente.
• Données : identité, e-mail, contenu de l'échange, références de commande éventuelles.
• Destinataires : service client interne, prestataire de chat (Crisp, Intercom, Zendesk).
• Transferts hors UE : Intercom et Zendesk — Data Privacy Framework.
• Durée de conservation : 3 ans à compter de la clôture du ticket.
• Mesures de sécurité : authentification des agents, journalisation des accès, suppression automatique des conversations anciennes.

Le registre, jumeau privé de la politique de confidentialité

Un point souvent mal compris : le registre et la politique de confidentialité sont les deux faces d'une même réalité.

• Le registre est un document interne, exhaustif et technique. Il documente la mécanique de vos traitements pour vous-même et pour la CNIL.
• La politique de confidentialité est la version publique, vulgarisée et synthétique, destinée aux personnes concernées. Elle reprend les informations du registre dans un langage compréhensible et y ajoute les modalités d'exercice des droits.

Concrètement, lorsque vous ajoutez un traitement au registre, vous devez mettre à jour la politique de confidentialité dans la foulée. Et inversement, toute mention dans la politique doit avoir son équivalent dans le registre. C'est exactement pour cela que notre générateur produit une politique de confidentialité alignée sur les traitements que vous déclarez — la cohérence entre les deux est l'un des premiers points vérifiés en contrôle. Pour aller plus loin sur le cadre général du RGPD côté site web, consultez notre guide RGPD pour un site web français.

Tenir le registre à jour : la vraie difficulté

Le registre n'est pas un document à rédiger une fois pour toutes. Il doit refléter la réalité de vos traitements. À chaque évènement de la vie de l'entreprise, posez-vous la question : « Faut-il modifier le registre ? »

• Vous changez de prestataire d'emailing ? Mise à jour de la fiche « Newsletter ».
• Vous ajoutez un chat sur le site ? Création d'une nouvelle fiche « Support client ».
• Vous lancez un programme de fidélité ? Création d'une fiche « Fidélisation ».
• Vous changez de transporteur ? Mise à jour de la fiche « Commandes ».
• Vous installez une caméra dans vos locaux ? Création d'une fiche « Vidéosurveillance ».

Une bonne pratique consiste à réviser intégralement le registre une fois par an, idéalement au moment du bilan comptable, et à dater chaque mise à jour dans une colonne dédiée.

Le registre et les sous-traitants : clauses DPA

Vos sous-traitants (hébergeur, prestataire d'emailing, CRM, analytics…) doivent eux aussi tenir leur propre registre. Lorsque vous signez un contrat de sous-traitance RGPD (DPA — Data Processing Agreement), vous leur demandez généralement de pouvoir consulter, sur demande, leur registre les concernant. Cela permet de cartographier la chaîne complète des traitements et de répondre à une demande de la CNIL en quelques heures plutôt qu'en plusieurs jours.

Si vos sous-traitants envoient des données hors UE, ne négligez pas la documentation des garanties : voyez notre article dédié aux transferts de données hors UE et au Data Privacy Framework. Et si vous utilisez la prospection par e-mail, le sujet du consentement et du soft opt-in est traité dans notre guide newsletter, opt-in et prospection RGPD.

Que se passe-t-il en cas de contrôle CNIL ?

Lors d'un contrôle sur place ou sur pièces, le registre est presque toujours le premier document demandé. La CNIL l'examine pour identifier les traitements, repérer les éventuels manquements (absence de base légale, durée de conservation excessive, transfert non encadré…) et orienter la suite du contrôle.

Une entreprise qui ne peut pas produire son registre se met dans une situation très inconfortable : elle reconnaît implicitement ne pas maîtriser ses traitements. À l'inverse, un registre clair et à jour démontre une démarche structurée, ce qui pèse favorablement dans l'appréciation de la CNIL. Pour mesurer ce que coûte un contrôle qui tourne mal, consultez notre dossier sanctions CNIL en cas de site non conforme.

Enfin, gardez en tête que le registre, comme l'ensemble de votre documentation de conformité, est cohérent avec les autres obligations légales de votre site, à commencer par les mentions légales 2026.

Pour aller plus loin

• Article 30 du RGPD — texte intégral sur EUR-Lex
• Le registre des activités de traitement — page de la CNIL
• Modèle de registre RGPD de la CNIL — version téléchargeable

Le registre des traitements est moins un exercice juridique qu'une discipline d'inventaire. Une fois la première version posée, sa mise à jour devient une habitude trimestrielle. Et il vous protège : en cas de contrôle, c'est le document qui parle pour vous. Si votre politique de confidentialité ne reflète pas encore votre registre, c'est le bon moment pour la mettre à niveau.