Anonymiser les données personnelles avant de les envoyer à un LLM avec n8n (RGPD)

Vos workflows n8n envoient déjà des données clients à un LLM : un email complet part vers OpenAI pour être classé et priorisé, un ticket support part vers Anthropic pour être scoré, un dossier de réclamation part se faire résumer. Dans chacun de ces cas, le nom du client, son email, parfois son numéro de téléphone ou son adresse voyagent vers un tiers — alors que le modèle n'a souvent besoin que du contenu du message pour faire son travail. C'est exactement le type de traitement que l'article 5.1.c du RGPD vise avec le principe de minimisation des données : ne collecter et ne transmettre que ce qui est adéquat, pertinent et limité à ce qui est nécessaire.

Ce guide montre comment construire, dans n8n, une couche d'anonymisation ou de pseudonymisation entre vos données et l'appel au LLM — sans casser la logique métier qui a souvent besoin de la vraie donnée après coup.

Pourquoi le DPA du fournisseur ne suffit pas à lui seul

Signer un accord de sous-traitance (Data Processing Addendum) avec OpenAI ou Anthropic couvre le cadre contractuel du transfert : base légale, engagements de sécurité, sort des données en cas de résiliation. Mais un DPA ne dispense pas de la minimisation en amont. Deux raisons concrètes d'agir avant l'envoi plutôt que de se reposer uniquement sur le contrat du fournisseur :

1. La preuve de conformité vous incombe. En cas de contrôle, démontrer que vos workflows n'exposent que le strict nécessaire est plus solide qu'un DPA signé mais jamais appliqué dans le code des automatisations.
2. Le risque de mémorisation par le modèle n'est pas nul. Des chercheurs de Google et d'autres institutions, Carlini et al. (2021), ont démontré qu'il est possible d'extraire des séquences de données d'entraînement mémorisées par de grands modèles de langage, y compris des informations personnelles (voir l'étude sur Google Scholar). Ce résultat concerne l'entraînement, pas l'inférence via API — mais il illustre pourquoi limiter l'exposition des données personnelles reste une bonne pratique même face à un fournisseur sérieux : moins une donnée circule, moins elle a de surfaces où fuiter.

Deux stratégies, pour deux besoins différents

Tout ne se traite pas de la même façon selon que vous avez besoin, ou non, de récupérer la vraie donnée après l'appel IA.

Masquage irréversible : quand la donnée réelle ne ressert pas

Pour un usage strictement analytique — statistiques agrégées, détection de tendances dans des retours clients, rapport de synthèse anonyme — remplacer les identifiants par un texte générique suffit et simplifie tout : pas de table à gérer, pas de risque de fuite dans l'autre sens. C'est exactement ce que fait le node Guardrails de n8n avec son opération Sanitize Text : sans appel à un LLM, par simple correspondance de motifs, il détecte et remplace emails, numéros de téléphone, numéros de carte bancaire et autres PII standards par des jetons génériques ([EMAIL_ADDRESS], [PHONE_NUMBER]…).

Pseudonymisation réversible : quand il faut répondre au bon client

Le cas le plus fréquent en PME est différent : vous voulez que l'IA classe, résume ou priorise un ticket sans voir l'identité du client — mais votre workflow a ensuite besoin de savoir à qui répondre. C'est là qu'intervient la pseudonymisation réversible : chaque identifiant est remplacé par un jeton opaque avant l'appel LLM, et une table de correspondance chiffrée permet de revenir à la valeur réelle une fois la réponse du modèle obtenue.

Construire la pseudonymisation réversible dans n8n

La table de correspondance dans Supabase

Créez une table dédiée, séparée des données métier, accessible uniquement au workflow qui en a besoin :

create table pseudonymization_tokens (
  token text primary key,
  original_value text not null,
  field_type text not null,
  created_at timestamptz default now()
);

create index idx_pseudo_created on pseudonymization_tokens (created_at);

Isoler cette table (schéma dédié, permissions restreintes) évite qu'un accès aux données métier suffise à lever l'anonymisation — le principe même de la pseudonymisation selon le RGPD, qui la distingue de l'anonymisation complète tant que la table de correspondance existe quelque part.

Le node Code qui remplace et enregistre

En amont de l'appel au LLM, un node Code détecte les identifiants (regex ou, pour aller plus loin, le node Guardrails en mode détection seule), génère un jeton unique pour chacun avec le node Crypto (un hash tronqué suffit, l'important est l'unicité, pas la réversibilité mathématique — la vraie valeur vit dans Supabase), puis insère la paire jeton/valeur dans la table avant de continuer le workflow avec le texte pseudonymisé.

const email = $input.first().json.email;
const token = `TOK_${require('crypto').createHash('sha256').update(email + Date.now()).digest('hex').slice(0, 12)}`;
return [{ json: { ...$input.first().json, email: token, _originalEmail: email } }];

Le node Supabase (opération Insert) qui suit persiste la correspondance ; le champ _originalEmail sert uniquement à ce node d'insertion et ne doit jamais repartir vers le LLM.

Le workflow complet, étape par étape

1. Trigger (Webhook, IMAP, formulaire) : réception de la donnée brute.
2. Node Code — anonymisation : détection des PII, génération de jetons, texte nettoyé transmis en sortie.
3. Node Supabase — Insert : écriture de la correspondance jeton → valeur réelle.
4. AI Agent ou HTTP Request : appel au LLM avec uniquement le texte pseudonymisé — classement, résumé, scoring.
5. Node Supabase — Select : relecture de la correspondance à partir des jetons présents dans la réponse.
6. Node Code — dépseudonymisation : réinjection des vraies valeurs dans le résultat final avant l'action de sortie (email envoyé, entrée CRM, notification Slack).

Ce schéma s'intègre directement dans un pipeline de tri d'emails par IA ou de scoring de tickets support : seules les étapes 2 et 5-6 s'ajoutent au workflow existant, le cœur du traitement IA ne change pas.

Le piège des identifiants indirects

Masquer les champs évidents (nom, email, téléphone) ne suffit pas toujours. Une étude désormais classique de Latanya Sweeney, publiée en 2000, a montré qu'aux États-Unis, la seule combinaison du code postal, de la date de naissance et du sexe permettait de ré-identifier de façon unique environ 87 % de la population (voir l'étude sur Google Scholar). Autrement dit : ce ne sont pas les champs qui portent un nom explicite (« email », « téléphone ») qui posent le plus de risque à long terme, mais les combinaisons de détails contextuels dans du texte libre — une ville, une profession, une date de rendez-vous, un montant précis. Pour un ticket support ou une réclamation détaillée, un masquage regex sur les seuls champs structurés ne couvre pas ce risque ; il faut soit passer le texte libre par le Guardrails PII en mode détection élargie, soit accepter que certains champs de texte libre restent hors périmètre d'automatisation et passent par une relecture humaine avant tout traitement IA sensible.

Et avec un LLM auto-hébergé ?

Faire tourner le modèle en local avec Ollama supprime le risque de transfert vers un tiers : les données ne quittent jamais votre infrastructure. Cela ne rend pas pour autant la pseudonymisation inutile — elle réduit aussi l'exposition dans vos propres logs d'exécution n8n, dans les journaux applicatifs, ou face à un prestataire qui administre le serveur. C'est une défense en profondeur, pas une case à cocher qui ne compterait que pour les fournisseurs externes.

Pièges fréquents

• Ne pseudonymiser que les champs structurés en laissant le texte libre intact : c'est souvent là que se cachent les identifiants indirects.
• Stocker la table de correspondance dans la même base que les données métier, sans séparation de permissions : cela annule une bonne partie de l'intérêt de la pseudonymisation.
• Oublier de purger la table de jetons : définissez une durée de rétention cohérente avec le besoin réel (le temps du traitement, rarement plus), au même titre que pour votre registre des traitements.
• Faire confiance au DPA du fournisseur IA comme seule mesure : c'est une brique contractuelle, pas un substitut à la minimisation technique.
• Sur-ingénierie pour un cas à faible risque : un digest interne agrégé n'a pas besoin du même niveau de pseudonymisation qu'un dossier RH ou de santé — adaptez l'effort au risque réel du traitement.

En résumé

Envoyer des données personnelles brutes à un LLM tiers, même sous DPA, dépasse souvent ce que la minimisation RGPD exige. Un masquage irréversible via le node Guardrails suffit pour les usages purement analytiques ; une pseudonymisation réversible avec table de correspondance Supabase couvre les cas où le workflow a besoin de revenir à l'identité réelle après l'appel IA. Les deux se construisent avec les nodes déjà présents dans n8n — Code, Crypto, Supabase — sans service tiers supplémentaire. Le Pack Conformité & Audit (149 €) fournit une piste d'audit Supabase prête à l'emploi qui s'articule naturellement avec ce type de table de correspondance ; pour un premier cas d'usage concret à sécuriser, le Pack Inbox IA (79 €) reste le terrain d'entraînement le plus rapide à rentabiliser.