Traiter les demandes RGPD (accès, effacement, portabilité) avec n8n

Un client écrit pour demander l'accès à ses données, ou pire, leur suppression complète. Le réflexe classique : ouvrir un ticket, chercher manuellement dans le CRM, la base de production, les logs, la boîte mail partagée, puis répondre à la main avant que le délai légal n'expire. Cela fonctionne pour la première demande. Cela craque à la dixième, surtout quand personne n'a de vue d'ensemble sur les endroits où dort réellement une donnée personnelle. Une étude de Rupp, Syrmoudis et Grossklags publiée en 2022 dans Proceedings on Privacy Enhancing Technologies a testé la demande d'effacement sur 90 services en ligne : 27 % restaient non conformes, avec des données supposément supprimées encore accessibles ailleurs sur le service (étude sur Google Scholar). Le problème n'est pas la mauvaise volonté : c'est l'absence de processus reproductible. C'est exactement ce qu'un workflow n8n peut fournir.

Ce que le RGPD exige concrètement

Trois droits reviennent le plus souvent dans les demandes reçues par une PME :

• Article 15 — droit d'accès : fournir une copie de toutes les données personnelles détenues sur la personne, dans un délai d'un mois.
• Article 17 — droit à l'effacement (« droit à l'oubli ») : supprimer les données, sauf obligation légale de conservation contraire (facturation, par exemple).
• Article 20 — droit à la portabilité : fournir les données dans un format structuré, couramment utilisé et lisible par machine (JSON ou CSV, typiquement).

Le délai légal est d'un mois à compter de la réception, extensible de deux mois supplémentaires pour les demandes complexes — à condition d'en informer la personne dans le mois initial. Passé ce délai sans réponse ni justification, l'entreprise est en tort, indépendamment de la qualité de la réponse finalement apportée.

Pourquoi le traitement manuel ne tient pas à l'échelle

Le problème n'est pas propre aux grandes entreprises. Une étude de Mangini, Tal et Moldovan publiée en 2020 lors de la conférence ACM ARES confirme que les organisations interrogées peinent particulièrement avec l'exécution d'audits système et l'application concrète du droit à l'effacement — pas avec la compréhension du texte de loi lui-même, mais avec sa mise en œuvre opérationnelle répétée (étude sur Google Scholar). Chercher manuellement dans cinq outils différents, sans oublier un système, en respectant un délai, est précisément le genre de tâche répétitive et rigide qu'un workflow automatise mieux qu'un humain pressé.

Étape 1 — Réceptionner et vérifier l'identité

Un Form Trigger hébergé directement sur votre instance n8n capte la demande avec les champs indispensables : type de droit exercé (accès, effacement, portabilité), e-mail associé au compte, et une case de confirmation. Le workflow envoie ensuite un lien de confirmation à cette adresse — la vérification d'identité minimale exigée avant tout traitement, pour éviter qu'un tiers mal intentionné ne déclenche l'effacement du compte de quelqu'un d'autre. Pour une demande atypique (adresse inconnue, données sensibles), mieux vaut router vers une étape d'approbation humaine avec le node Wait et Slack plutôt que de tout automatiser en aveugle.

Étape 2 — Agréger les données personnelles sur toutes les sources

C'est le cœur technique du problème : la donnée d'un client vit rarement à un seul endroit. Elle est répartie entre la base de production (souvent Supabase ou Postgres), le CRM, la boîte mail partagée, l'outil de facturation. Plutôt qu'un workflow monolithique, découpez la collecte en sub-workflows — un par source de données — appelés en parallèle par un workflow orchestrateur qui reçoit la demande validée. Chaque sub-workflow interroge sa source, normalise le résultat (même structure de sortie : source, enregistrements, timestamp), puis renvoie l'ensemble au workflow parent. Cette architecture a un avantage direct pour la conformité : ajouter une nouvelle source de données à l'avenir (un nouvel outil SaaS, par exemple) revient à ajouter un sub-workflow, sans toucher au reste du pipeline — donc sans risque d'oublier une source lors d'une demande future.

Étape 3 — Répondre au droit d'accès et à la portabilité

Une fois l'agrégation terminée, un node Code assemble les résultats des sub-workflows en un objet JSON unique, lisible par machine — ce qui satisfait de facto l'exigence de portabilité de l'article 20. Pour une lecture humaine, le même contenu peut être converti en CSV ou en tableau Excel structuré via les techniques décrites dans notre guide pour extraire et générer des fichiers Excel/CSV avec n8n. Le fichier est ensuite transmis par e-mail ou par lien de téléchargement à durée limitée, jamais par pièce jointe non protégée si le volume de données est sensible.

Étape 4 — Traiter l'effacement sans casser la production

L'effacement est l'étape la plus risquée du pipeline : supprimer trop, ou dans le mauvais ordre, casse des relations en base (clés étrangères, historique de commandes légalement conservé pour la facturation). Deux principes réduisent ce risque :

• Anonymiser plutôt que supprimer quand la loi l'exige : une facture doit rester dans les livres comptables, mais le nom du client peut être remplacé par un identifiant anonyme. Le sub-workflow d'effacement doit distinguer explicitement les champs à supprimer des champs à anonymiser, table par table.
• Ordonner les suppressions par dépendances : effacer d'abord les données sans contrainte de clé étrangère, puis remonter vers les tables référencées, exactement comme on découperait des étapes séquentielles dans un Error Workflow bien conçu — avec le même souci d'échouer proprement plutôt que de laisser une suppression partielle non détectée.

Une exécution d'effacement qui échoue à mi-parcours doit être visible immédiatement, pas découverte trois mois plus tard lors d'un contrôle.

Étape 5 — Respecter le délai et journaliser la demande

Un trigger cron quotidien, sur le même principe que celui utilisé pour relancer des dossiers incomplets, vérifie chaque matin les demandes RGPD encore ouvertes et alerte l'équipe (Slack, e-mail) dès qu'une échéance approche à J-5. Chaque demande — reçue, traitée, ou en attente — doit être journalisée dans une table append-only, sur le modèle exact décrit dans notre guide de piste d'audit RGPD avec Supabase : qui a demandé quoi, quand, ce qui a été trouvé, ce qui a été supprimé ou anonymisé, et par quelle exécution de workflow. En cas de contrôle, cette trace prouve la conformité bien mieux qu'un souvenir approximatif.

Pièges fréquents

• Oublier une source de données : sans architecture en sub-workflows, une nouvelle intégration SaaS est facilement oubliée lors de la prochaine demande d'accès ou d'effacement.
• Supprimer sans distinguer les obligations légales de conservation : effacer une facture obligatoire au lieu de l'anonymiser expose à un autre type de non-conformité, comptable cette fois.
• Aucune vérification d'identité : traiter une demande d'effacement reçue par e-mail sans confirmation ouvre la porte à un détournement malveillant du service.
• Silence après le délai d'un mois : même une réponse partielle avec justification de retard vaut mieux qu'une absence totale de réponse.

Pour aller plus loin

Ce pipeline — réception, vérification, agrégation multi-source, effacement en cascade, journalisation — est exactement ce qu'assemble le Pack Conformité & Audit (149 €), aux côtés des workflows de relance de dossiers incomplets et de rapport de synthèse d'audit. Si votre conformité RGPD repose aujourd'hui sur un tableur et de la bonne volonté, c'est le point de départ le plus direct pour la remplacer par un processus qui tient la charge, demande après demande.