Purger automatiquement les données personnelles en fin de conservation avec n8n (RGPD)

Le registre des traitements RGPD d'une entreprise mentionne presque toujours une durée de conservation en face de chaque catégorie de données : « prospects — 3 ans », « CV non retenus — 2 ans », « logs de connexion — 1 an ». Le problème n'est pas de connaître ces durées, c'est de les appliquer. Un champ « durée de conservation » dans un tableur ou une table Supabase reste une intention tant que personne ne va effectivement supprimer les lignes concernées, et personne ne le fait jamais spontanément — une base grossit, elle ne s'auto-purge pas. C'est exactement le mécanisme que l'article 5.1.e du RGPD, le principe de limitation de la conservation, exige pourtant : ne garder les données identifiables que le temps strictement nécessaire à leur finalité. Une équipe de Garg, Goldwasser et Vasudevan, dans un article présenté à Eurocrypt 2020, a formalisé à quel point une suppression réellement effective est plus exigeante qu'un simple DELETE : elle doit éliminer aussi les effets dérivés de la donnée (copies, index, structures construites à partir d'elle), sans quoi la trace subsiste ailleurs dans le système (étude sur Google Scholar). Ce guide construit un workflow n8n qui transforme la durée de conservation d'une ligne de registre en purge réellement exécutée.

Ce que la purge automatique couvre — et ce qu'elle ne couvre pas

Trois automatisations RGPD voisines répondent à des déclencheurs différents, à ne pas confondre :

• Le registre des traitements documente quelles données existent et pour combien de temps — voir notre guide sur le registre des traitements RGPD avec n8n.
• Le traitement des demandes RGPD répond à une personne qui exerce son droit à l'effacement à un instant donné — voir notre guide sur les demandes RGPD avec n8n.
• La purge automatique, sujet de cet article, ne dépend d'aucune demande : elle s'exécute systématiquement, sur toute donnée ayant dépassé sa durée de conservation déclarée, que quelqu'un la réclame ou non.

Cette purge n'a rien à voir non plus avec la suppression de doublons : un doublon est une erreur de saisie, une donnée périmée est une donnée légitime qui a simplement dépassé sa date de péremption légale.

Pourquoi la purge manuelle ne tient jamais dans la durée

Un tri manuel des données périmées demande de croiser trois choses à chaque fois : la catégorie de la donnée, sa date de création ou de dernière activité, et la règle de conservation applicable. Fait à la main, ce croisement prend du temps, personne ne le priorise face à des tâches plus visibles, et il finit par ne plus être fait du tout — jusqu'au jour d'un contrôle où l'entreprise découvre qu'elle conserve encore des CV de candidats refusés depuis six ans. La seule façon de tenir la durée de conservation dans le temps est de la sortir de la mémoire humaine et de la coder dans un déclencheur planifié.

Étape 1 — Une table de politiques de rétention

Plutôt que de coder les durées en dur dans le workflow, une table Supabase centralise les règles, modifiable sans toucher au code :

create table politiques_conservation (
  id uuid primary key default gen_random_uuid(),
  categorie text unique not null,
  table_cible text not null,
  colonne_date text not null,
  duree_mois integer not null,
  action text not null default 'suppression',
  base_legale text,
  actif boolean default true
);

insert into politiques_conservation
  (categorie, table_cible, colonne_date, duree_mois, action, base_legale)
values
  ('prospects_inactifs', 'crm_contacts', 'derniere_interaction', 36, 'suppression', 'intérêt légitime — prospection'),
  ('candidatures_refusees', 'candidats', 'date_refus', 24, 'suppression', 'consentement — recrutement'),
  ('tickets_support_clos', 'tickets', 'date_cloture', 60, 'anonymisation', 'obligation légale — garantie'),
  ('logs_connexion', 'audit_connexions', 'created_at', 12, 'suppression', 'intérêt légitime — sécurité');

Ces durées (3 ans pour la prospection, 2 ans pour une candidature non retenue…) reprennent des repères courants recommandés par la CNIL, mais chaque entreprise doit valider les siennes avec ses propres bases légales — ce n'est pas un conseil juridique universel, c'est la structure qui accueille votre décision.

Étape 2 — Détecter les lignes en fin de vie

Un workflow planifié une fois par semaine (Schedule Trigger) lit politiques_conservation, puis pour chaque politique active construit dynamiquement une requête sur la table_cible :

select id from crm_contacts
where derniere_interaction < now() - interval '36 months';

Le nom de la table et de la colonne venant de la configuration plutôt que du code, ce même sub-workflow générique s'applique à toutes les politiques sans duplication — sur le même principe de paramétrage que dans notre guide sur les sub-workflows n8n. Chaque ligne trouvée est ajoutée à une file d'attente purge_candidats plutôt que supprimée immédiatement.

Étape 3 — Suppression ou anonymisation, selon le cas

L'action déclarée dans la politique détermine la suite :

• Suppression : un DELETE ciblé sur l'identifiant, dans une transaction qui échoue proprement si une contrainte de clé étrangère bloque l'opération plutôt que de la forcer en cascade sans contrôle.
• Anonymisation : les colonnes identifiantes (nom, email, téléphone) sont remplacées par des valeurs génériques ou un hash irréversible, en conservant les colonnes non identifiantes utiles aux statistiques — la même logique de masquage que celle détaillée dans notre guide sur l'anonymisation des données avant un appel LLM, appliquée ici en base plutôt qu'en flux.

Étape 4 — Ce qu'une suppression en base ne couvre pas

Un DELETE sur la table principale est nécessaire mais rarement suffisant. Une donnée personnelle laisse des copies ailleurs : sauvegardes automatiques Postgres (voir notre guide sur la sauvegarde et restauration PostgreSQL), fragments indexés dans une base vectorielle si le contact a été ingéré pour un chatbot RAG, ou simplement les payloads d'exécution conservés par n8n lui-même. La purge ne peut pas courir après chaque sauvegarde chiffrée, mais elle doit au minimum documenter ce périmètre : la politique de rétention des sauvegardes elle-même doit être alignée sur la durée de conservation la plus longue qu'elle contient, et tout embedding lié à un contact supprimé doit être retiré de l'index — un sujet couvert dans notre guide sur la mise à jour d'un index RAG.

Étape 5 — Ne jamais purger en volume sans validation humaine

Une politique de rétention mal configurée (une mauvaise colonne de date, une durée en jours au lieu de mois) peut transformer une purge routinière en incident majeur. Le workflow ne doit jamais exécuter une suppression en masse sans garde-fou : au-delà d'un seuil (par exemple 50 lignes en une exécution), il bascule vers une étape d'approbation humaine avant de continuer, sur le même modèle que notre guide sur l'approbation humaine avec Wait et Slack. En dessous du seuil, la purge s'exécute directement — la routine n'a pas besoin d'un humain dans la boucle à chaque passage.

Étape 6 — Journaliser la purge elle-même

Paradoxalement, l'action qui consiste à supprimer une trace doit elle-même en laisser une : quelle politique a déclenché la purge, combien de lignes ont été traitées, à quelle date, avec quel identifiant de workflow. Cette journalisation alimente la même table append-only que celle décrite dans notre guide sur la piste d'audit RGPD avec n8n et Supabase — c'est la seule façon de répondre à un contrôleur qui demanderait : « prouvez que vous avez bien supprimé ces CV après deux ans » sans pouvoir montrer les CV eux-mêmes, puisqu'ils n'existent plus.

Ce que cette automatisation ne remplace pas

Ce workflow applique des règles déjà validées humainement dans le registre des traitements ; il ne décide pas lui-même des durées de conservation ni des bases légales, et il ne dispense pas de vérifier que les sauvegardes et systèmes tiers suivent le même rythme. Son rôle est de fermer l'écart entre une politique écrite et une politique réellement appliquée — l'écart où se logent la quasi-totalité des manquements constatés lors des contrôles.

En résumé

Une durée de conservation notée dans un registre ne protège personne tant qu'aucun mécanisme ne l'applique sur les données réelles. Une table de politiques centralisée, une détection planifiée des données en fin de vie, une action de suppression ou d'anonymisation selon le cas, un seuil d'approbation humaine pour les purges en volume, et une journalisation de l'opération elle-même : ces cinq briques suffisent à transformer l'article 5.1.e d'une ligne de texte juridique en un processus qui tourne sans intervention. Les workflows du Pack Conformité & Audit (149 €) appliquent la même discipline de traçabilité horodatée à vos questionnaires et audits ; combinés à ceux du Pack Assistant RAG (119 €) pour la partie base vectorielle, ou au Bundle FlowKit complet (269 €) pour couvrir l'ensemble, ils donnent une base solide pour que la conservation des données reste ce qu'elle doit être : une durée, pas une éternité par défaut.