En bref
Un workflow n8n peut envoyer à un modèle de langage un nom, une adresse e-mail ou un IBAN et s'afficher en vert dans l'historique. Aucune alerte ne sonne, la donnée est déjà partie. Trois parades existent : limiter les champs transmis, passer le texte dans le nœud Guardrails de n8n, ou détecter et masquer les identifiants avec un node dédié, comme celui de Miravig. Aucune ne dispense d'un test sur ses propres données.[1][2][3]
Dans l'article précédent, le workflow s'arrêtait sur une erreur et quelqu'un finissait par la lire. Ici, l'exécution va jusqu'au bout. Chaque nœud passe au vert, le CRM se remplit, et un IBAN est parti chez un fournisseur d'IA.
Reprenons le scénario de l'article 5. Un workflow reçoit les e-mails de clients, demande à un LLM d'en extraire le nom et le montant réclamé, puis alimente un CRM. Voici un message fictif, qui servira d'exemple jusqu'au bout :
Bonjour, je suis Claire Fontaine. Ma facture de 1 200 euros est en double. Merci de me rembourser sur FR76 3000 6000 0112 3456 7890 189. Vous pouvez me répondre à [email protected].
Pour lire un nom et un montant, le modèle n'a besoin ni de l'adresse ni de l'IBAN. Il les reçoit quand même, parce que le montage le plus simple consiste à insérer le corps du message dans le prompt par une expression, sans aucun tri.
La donnée reste aussi dans n8n. Sa documentation décrit des réglages de conservation des exécutions (« Save successful production executions », « Save failed production executions », « Save manual executions ») et parle, à propos de la dissimulation des données, de « the input and output data of each node ».[2] Selon la configuration de l'instance, le contenu d'un prompt peut donc rester lisible dans l'historique. La page consultée ne donne pas les valeurs par défaut, et il vaut mieux ouvrir les réglages de sa propre instance que de s'en remettre à une supposition.
Une panne de format et un envoi de données sensibles ne laissent pas les mêmes traces :
| Critère | Panne de format (article 5) | Envoi de données sensibles |
|---|---|---|
| Message d'erreur | Oui, Unexpected token | Aucun |
| Statut de l'exécution | En échec | Réussi |
| Détection | Immédiate, par n8n | Aucune sans contrôle volontaire |
| Qui s'en aperçoit | Celui qui lit les alertes | Personne, jusqu'à un incident |
| Conséquence | Un traitement interrompu | Une donnée déjà transmise |
Le déclenchement automatique rend le problème plus discret encore. Un workflow lancé à chaque e-mail reçu traite des dizaines de messages par jour sans relecture. Un seul contient un IBAN, et rien ne le distingue des autres dans la liste des exécutions.
Le coût commence au moment où la donnée quitte le poste de travail, ce que détaille l'article sur le copier-coller dans une IA. Ce qui arrive ensuite dépend du fournisseur et de l'offre utilisée : conservation, entraînement, accès humain, tout cela varie, comme le montre la comparaison entre ChatGPT, Claude et Gemini. Reste la question de la responsabilité en cas de fuite, abordée dans l'article sur le RGPD, l'AI Act et NIS2.
Un workflow ajoute une particularité. Dans une interface de chat, l'utilisateur choisit ce qu'il colle. Dans un workflow, la configuration en décide une fois pour toutes, et la décision se répète à chaque exécution.
| Parade | Principe | Ce qu'elle couvre | Limite |
|---|---|---|---|
| Limiter les champs | Ne transmettre que ce que le modèle doit lire | Les données qui n'entrent jamais dans le prompt | Inopérante quand la donnée se trouve dans le texte libre |
| Nœud Guardrails de n8n | Détecter puis remplacer des éléments d'un texte | PII, clés secrètes, URL, expressions régulières | La documentation ne décrit aucune restauration de la valeur d'origine |
| Node Miravig | Masquer avant l'appel, restaurer après | Identifiants nationaux, données identifiantes, glossaire métier | Instance auto-hébergée, masquage réservé à l'abonnement |
C'est la parade la moins chère, donc la première à appliquer. Le nœud Edit Fields (Set) de n8n propose l'option « Keep Only Set Fields » : les données qui ne figurent pas dans les champs définis sont écartées.[3] Placé avant l'appel au modèle, il garantit que le prompt ne contient que ce qu'on y a mis volontairement.
La méthode atteint sa limite quand le texte libre est justement ce que le modèle doit analyser. Dans notre exemple, l'e-mail du client est la matière première, et l'IBAN s'y trouve déjà.
n8n fournit un nœud Guardrails. Son opération « Sanitize Text » applique un sous-ensemble de contrôles (URL, expressions régulières, clés secrètes, PII) et remplace ce qu'elle détecte par des marqueurs.[1] C'est une solution native, sans composant à installer, qui convient à un nettoyage général.
Reste un point ouvert. Pour les PII, la documentation cite en exemple CREDIT_CARD, EMAIL_ADDRESS, PHONE_NUMBER et US_SSN, sans publier de liste complète et sans évoquer d'identifiant national européen.[1] Elle ne décrit pas non plus de moyen de retrouver la valeur d'origine après l'appel au modèle. Qu'un IBAN ou un numéro de sécurité sociale français soit reconnu, la page ne le dit pas, et seul un essai sur des exemples réels le tranchera.
Précision d'usage : ce node est celui de Miravig, qui édite ce blog. Il se place de part et d'autre de l'appel au modèle :
Déclencheur → [vos données] → Miravig (Mask) → [nœud LLM] → Miravig (Unmask) → [suite du workflow]
L'opération Mask analyse le texte avant l'appel, l'opération Unmask restaure ensuite les valeurs du glossaire métier dans la réponse. La détection est gratuite et illimitée. Le masquage automatique et le glossaire demandent un abonnement actif.[4]
Sur l'e-mail de Claire Fontaine, deux mécanismes jouent. L'adresse e-mail et l'IBAN appartiennent aux catégories natives : ils sont remplacés par un jeton générique, [EMAIL_HIDDEN] ou [IBAN_HIDDEN], que rien ne restaure jamais, puisque le modèle n'a aucune raison de les connaître. Le nom, lui, peut figurer dans le glossaire métier, où l'on déclare ses propres termes sensibles. Il devient alors un jeton numéroté, [TERME_G1], que l'opération Unmask sait remettre en place. Le modèle lit ceci :
Le nom, l'IBAN et l'adresse partent chez le fournisseur.
Le modèle extrait le montant, sans voir l'IBAN ni l'adresse.
Il extrait le montant et un nom de substitution, sans avoir vu l'IBAN ni l'adresse. Au retour, Unmask remplace [TERME_G1] par le vrai nom.
Le paramètre « Behavior on Detection » décide de la suite quand une donnée est repérée. Il offre trois comportements : laisser passer en annotant le résultat, ce qui est la valeur par défaut, arrêter le workflow, ou aiguiller les éléments signalés vers une seconde sortie.[4] Pour un IBAN, l'arrêt me paraît le choix le plus sûr, mais c'est un avis, pas une règle.
Le glossaire doit être collé à l'identique dans Mask et dans Unmask. Il n'existe aucune synchronisation entre les deux, un choix délibéré pour que le glossaire reste sur l'instance. Si les deux versions divergent, Unmask le signale dans sa sortie.[4]
Certains nœuds LLM, Basic LLM Chain en tête, reconstruisent leur sortie à partir de la seule réponse du modèle. L'empreinte de contrôle du glossaire peut alors manquer à l'arrivée. Le node l'indique et restaure quand même à partir du glossaire collé dans Unmask. Pour garder la vérification, on ajoute un nœud Edit Fields après le LLM.[4]
La précision varie selon les pays. La plupart des identifiants nationaux sont validés par un vrai calcul de somme de contrôle. Pour quelques-uns, le SSN américain par exemple, aucune formule fiable n'est publique, et la confiance reste plafonnée au niveau « medium ».[4]
L'installation, enfin, se fait sur une instance n8n auto-hébergée. n8n a approuvé le node comme node vérifié, et son arrivée dans le catalogue n8n Cloud suit le calendrier des mises à jour de n8n.[4]
Aucun de ces outils ne remplace le tri en amont. La donnée qu'un modèle n'a pas besoin de lire n'a rien à faire dans son prompt.
Un premier inventaire suffit : lister les workflows qui appellent un LLM et, pour chacun, relever ce qui entre dans le prompt. Les champs superflus disparaissent avec Edit Fields. Pour les textes libres, un essai comparatif de Guardrails et d'un node dédié sur quelques dizaines d'e-mails réels, anonymisés au préalable, montrera ce que chaque outil laisse passer. Il reste à choisir le comportement à la détection, puis à relire les réglages de conservation des exécutions de l'instance.[2]
Oui. Rien n'interrompt l'exécution quand le texte transmis contient un nom, une adresse ou un IBAN, et le statut reste « réussi ».
Cela dépend des données à couvrir. Il remplace les éléments détectés par des marqueurs, mais sa documentation ne liste pas tous les types de PII reconnus. Un essai sur vos exemples tranchera.
Les catégories natives, comme l'e-mail, l'IBAN ou les identifiants nationaux, sont remplacées par un jeton qui n'est jamais restauré. Le glossaire remplace vos propres termes par des jetons numérotés que Unmask peut remettre en place dans la réponse.
L'absence d'entraînement ne dit rien de la conservation ni de l'accès, comme l'explique l'article sur ChatGPT, Claude et Gemini. Limiter les champs reste le premier réflexe.
Non. L'analyse et le masquage s'exécutent dans l'instance n8n. Seule la vérification de la clé de licence contacte le serveur de Miravig.
Un workflow peut réussir toutes ses exécutions et transmettre des données personnelles à un modèle : l'absence d'erreur ne dit rien du contenu envoyé. Le tri des champs vient en premier. Le nœud Guardrails offre un nettoyage général dont la couverture des identifiants européens reste à vérifier. Un node dédié ajoute la détection des identifiants nationaux et la restauration par glossaire, avec ses contraintes propres. Seul un essai sur des données représentatives de votre activité permet de mesurer ce que chaque outil laisse réellement passer.
[2] n8n, réglages de workflow et conservation des exécutions
[3] n8n, nœud Edit Fields (Set)
[4] Miravig, mode d'emploi du node n8n
Masquer les données sensibles avant l'appel au modèle : le node Miravig pour n8n détecte et masque les données identifiantes dans un workflow, avant l'envoi au LLM. Voir le mode d'emploi →