Tenir à jour son registre des traitements RGPD (article 30) avec n8n

Un registre des traitements RGPD tenu dans un tableur partagé suit toujours le même sort : à jour le jour de sa création, obsolète six mois plus tard. Un nouvel outil SaaS est branché sur le CRM, un stagiaire configure une intégration Zapier pour tester une idée, un formulaire de recrutement collecte des CV pendant trois mois puis disparaît des radars — et personne ne pense à ouvrir le tableur pour ajouter une ligne. Une étude de Freitas et Mira da Silva, menée auprès de dix PME industrielles et publiée en 2018 dans le Journal of Information Systems Engineering & Management, constatait déjà ce schéma : aucune des entreprises interrogées n'évaluait régulièrement sa conformité au règlement, la difficulté ne venant pas d'un manque de compréhension du texte mais de l'absence de processus répété dans le temps (étude sur Google Scholar). Ce guide montre comment n8n peut transformer le registre d'un document qu'on oublie en un processus qui se met à jour tout seul.

Ce que le registre couvre — et ce qu'il ne couvre pas

Il ne faut pas confondre trois obligations RGPD proches mais distinctes, souvent mélangées par erreur :

• Le registre des traitements (article 30) : l'inventaire de tous les traitements de données personnelles menés par l'entreprise — c'est le sujet de cet article.
• La piste d'audit (article 5.2, accountability) : la trace de ce que vos automatisations ont effectivement fait, couverte dans notre guide sur la piste d'audit RGPD avec n8n et Supabase.
• Le traitement des demandes RGPD (articles 15, 17, 20) : la réponse à une personne qui exerce ses droits d'accès, d'effacement ou de portabilité, détaillée dans notre guide sur le traitement des demandes RGPD avec n8n.

Le registre est la couche la plus en amont des trois : sans inventaire à jour des traitements existants, impossible de savoir sur quelles sources chercher lors d'une demande d'accès, ni quelles actions journaliser dans une piste d'audit.

Qui est réellement concerné

L'article 30.5 du RGPD exempte en théorie les organisations de moins de 250 salariés de tenir un registre. En pratique, cette exemption est beaucoup plus étroite qu'elle n'y paraît : elle ne s'applique que si tous les traitements sont occasionnels, sans risque particulier pour les personnes et sans données sensibles (santé, origine, opinions…) ni données pénales. Un CRM, une newsletter envoyée chaque mois ou un suivi RH classique — la situation de la quasi-totalité des PME et TPE — suffisent à faire tomber l'exemption. La CNIL considère alors le registre comme attendu, au moins sous une forme simplifiée.

Les huit champs que chaque fiche doit contenir

Une fiche de traitement conforme à l'article 30 répond systématiquement aux mêmes questions :

1. Finalité — pourquoi ce traitement existe (« gestion de la newsletter commerciale »).
2. Base légale — consentement, contrat, intérêt légitime, obligation légale…
3. Catégories de personnes concernées — clients, prospects, salariés, candidats…
4. Catégories de données — identité, coordonnées, données de connexion, données sensibles le cas échéant.
5. Destinataires — services internes, sous-traitants (l'outil SaaS lui-même en fait partie).
6. Transferts hors UE — le cas échéant, avec la garantie appliquée (clauses contractuelles types, décision d'adéquation).
7. Durée de conservation — combien de temps la donnée est gardée, et ce qui déclenche sa suppression.
8. Mesures de sécurité — chiffrement, contrôle d'accès, sauvegardes.

Ces huit champs sont exactement les colonnes de la table Supabase que ce workflow va remplir.

Pourquoi un tableur statique ne suit pas le rythme de n8n

Une instance n8n active accumule les intégrations plus vite qu'un registre tenu à la main ne peut suivre : chaque nouveau credential (un CRM, un outil d'emailing, une API de scoring de leads) est potentiellement un nouveau traitement de données personnelles au sens du RGPD. C'est précisément là qu'une instance d'automatisation change la donne par rapport à une entreprise qui n'a que quelques outils SaaS classiques — le rythme de création de nouveaux traitements suit celui des workflows, pas celui des revues de conformité trimestrielles.

L'idée : au lieu d'espérer que quelqu'un pense à mettre à jour le registre à chaque nouveau workflow, on le fait détecter automatiquement les candidats à documenter, via l'API REST de n8n.

Étape 1 — Détecter les nouveaux traitements candidats

Un workflow planifié (une fois par semaine suffit largement) interroge GET /api/v1/workflows?active=true avec un credential Header Auth dédié, comme décrit dans notre guide de l'API REST de n8n. Pour chaque workflow actif, il compare son identifiant à la table registre_traitements : tout workflow actif absent du registre devient une ligne au statut à documenter.

Un filtre simple limite le bruit : ne remonter que les workflows dont les nodes utilisent des types de credentials pertinents pour des données personnelles (email, CRM, formulaire, base de données client) plutôt que des workflows purement techniques (surveillance d'API, génération d'images). Ce tri grossier élimine l'essentiel des faux positifs sans prétendre à une classification parfaite.

Étape 2 — Un brouillon de fiche généré par IA, jamais publié sans relecture

Pour chaque nouveau candidat, un node LLM reçoit le nom du workflow, sa description et la liste de ses nodes, et rédige un premier brouillon des champs finalité, catégories de données probables et destinataires — sur le même principe que le rapport de synthèse d'audit du Pack Conformité & Audit. Ce brouillon accélère la rédaction mais ne doit jamais passer en statut « validé » automatiquement : la base légale et la durée de conservation sont des choix qui engagent juridiquement l'entreprise, pas des inférences statistiques. Le workflow poste le brouillon dans un canal Slack dédié pour validation humaine, sur le modèle de l'approbation humaine avec Wait et Slack.

Étape 3 — Le schéma Supabase

create table registre_traitements (
  id uuid primary key default gen_random_uuid(),
  workflow_id text unique,
  nom_traitement text not null,
  finalite text,
  base_legale text,
  personnes_concernees text,
  categories_donnees text,
  destinataires text,
  transfert_hors_ue text,
  duree_conservation text,
  mesures_securite text,
  statut text default 'a_documenter',
  derniere_revue date,
  created_at timestamptz default now()
);

La colonne workflow_id, unique, relie chaque fiche à son workflow n8n d'origine — c'est ce qui permet à l'étape de détection de savoir ce qui est déjà couvert sans dupliquer les lignes.

Étape 4 — Relancer les revues périodiques

Un registre exact le jour de sa création se périme lui aussi : une finalité change, un sous-traitant est remplacé, une durée de conservation n'est plus respectée. Un second workflow, déclenché par un Schedule Trigger mensuel, sélectionne les fiches dont derniere_revue dépasse douze mois et envoie un rappel groupé — le même patron que celui utilisé pour le suivi des échéances de contrats. La revue humaine reste volontairement manuelle : seule sa relance est automatisée.

Étape 5 — Exporter pour un contrôle

En cas de contrôle CNIL, il faut pouvoir produire le registre sous une forme lisible en quelques minutes. Un node Supabase suivi d'une conversion vers CSV — sur le même principe que notre guide sur la génération de fichiers Excel et CSV avec n8n — couvre la majorité des demandes. Pour un rendu plus formel, la même donnée peut alimenter un template HTML converti en PDF, comme détaillé dans notre guide sur la génération de PDF avec n8n.

Sécuriser l'accès

Le registre contient, par construction, une cartographie précise de toutes les données personnelles manipulées par l'entreprise — une cible de choix en cas de fuite. La clé API n8n utilisée pour la détection et le credential Supabase du registre doivent suivre les mêmes règles d'hygiène que n'importe quel secret d'administration : stockage en variable d'environnement, accès restreint, rotation en cas de doute, comme détaillé dans notre guide sur la sécurisation des credentials n8n.

Ce que cette automatisation ne remplace pas

Ce workflow détecte des candidats à documenter et accélère la rédaction du brouillon ; il ne remplace ni un DPO, ni une analyse d'impact (AIPD) pour les traitements à risque élevé, ni le jugement humain sur la base légale applicable. Son rôle est plus modeste et plus utile au quotidien : garantir que le registre reflète la réalité de l'instance n8n plutôt que la photographie du jour où quelqu'un a eu le temps de le remplir.

En résumé

Le registre des traitements n'est pas un document qu'on rédige une fois puis qu'on range : c'est un inventaire censé suivre le rythme réel de l'activité, et sur une instance n8n qui grossit, ce rythme dépasse vite celui d'une mise à jour manuelle trimestrielle. Détecter les nouveaux traitements via l'API n8n, préparer un brouillon par IA toujours soumis à validation humaine, et relancer les revues périodiques : ces trois automatismes suffisent à garder un registre qui tient la route face à un contrôle. Les workflows du Pack Conformité & Audit (149 €) appliquent le même principe de traçabilité horodatée à vos questionnaires et audits — la piste d'audit et le registre se complètent pour couvrir l'ensemble de vos obligations d'accountability.