Variables n8n : rangez chaque valeur selon sa durée de vie, jamais une clé d'API dedans

Dans n8n, l’outil qui enchaîne vos logiciels sans programmer, une variable est une valeur que vous nommez une fois pour la réutiliser ailleurs : l’adresse mail du service compta, le taux de TVA, la date du dernier devis traité. Les variables n8n au sens strict s’écrivent $vars et ne sont proposées que sur les formules Cloud Pro et Enterprise, et auto-hébergées Business et Enterprise. Mais une même valeur peut vivre à cinq endroits, et chacun a sa durée de vie, sa portée et ses limites :

1. le nœud Edit Fields (aussi appelé Set), pour poser une valeur sur les données qui traversent le workflow ;
2. les variables $vars, partagées par vos workflows, en lecture seule ;
3. les variables d’environnement $env, quand vous hébergez n8n vous-même ;
4. les données statiques du workflow, une fonction que n8n dit expérimentale ;
5. les tables de données (Data tables), pour garder des lignes d’une exécution à l’autre.

La règle : on range une valeur selon le temps qu’elle doit vivre et selon qui doit pouvoir la lire, jamais selon ce qui est le plus rapide à taper. Et une clé d’API (le code qui ouvre votre logiciel de facturation à n8n) ne va dans aucune de ces cinq cases : elle va dans les identifiants, que n8n appelle credentials.

Mal ranger se paie plus tard : un workflow qui casse le jour où quelqu’un change une adresse, ou une clé d’API écrite dans un workflow. Les limites citées ici ont été lues dans la documentation officielle de n8n le 09/10/2026. Si vous découvrez l’outil, commencez par le tutoriel n8n pour PME ou par monter un premier workflow n8n, puis revenez ici pour ranger vos valeurs.

Variables n8n : quels sont les endroits où ranger une valeur dans un workflow ?

Une valeur se range dans n8n à l’un de cinq endroits : un champ du nœud Edit Fields (posé sur les données en cours), une variable $vars (partagée et en lecture seule), une variable d’environnement $env (réglage du serveur auto-hébergé), les données statiques (expérimentales) ou une table de données (lignes et colonnes conservées). La page Data tables de n8n compare elle-même tables et variables : les tables gèrent des données en lignes et colonnes, les variables sont « optimisées pour des valeurs courtes ». Une instance, dans ce qui suit, c’est votre installation de n8n, en ligne ou sur votre serveur.

Pour les variables, la page dédiée le précise : « pendant l’exécution du workflow, n8n remplace les variables par leur valeur ».

Le nœud Edit Fields : à quoi sert-il pour poser une valeur dans un workflow ?

Le nœud Edit Fields (Set) sert à « définir des données du workflow » : il peut « créer de nouvelles données comme écraser des données existantes ». C’est l’endroit le plus simple pour poser une valeur dont le workflow a besoin maintenant : le numéro de la facture en cours de relance, le montant dû, un libellé fixe. Pour retrouver une valeur à l’exécution suivante, la documentation de n8n renvoie vers d’autres outils : « pour conserver des données entre les exécutions, envisagez les tables de données ».

La documentation du nœud Edit Fields le juge « essentiel dans les workflows qui attendent des données de nœuds précédents, par exemple pour insérer des valeurs dans Google Sheets ou dans une base de données ». Ce qu’il faut savoir pour s’en servir :

• Deux modes. Manual Mapping (cartographie manuelle) se remplit à la souris, en glissant les valeurs depuis la colonne INPUT. JSON Output (sortie JSON) se remplit en écrivant du JSON, que n8n ajoute aux données d’entrée.
• Valeur fixe ou expression. Une valeur glissée crée par défaut une expression qui va chercher la donnée. Basculez sur Fixed pour une valeur qui ne change pas, comme compta@votre-entreprise.fr.
• Keep Only Set Fields (ne garder que les champs posés) écarte toutes les données d’entrée que vous n’avez pas reprises. Pratique pour envoyer à votre logiciel une fiche client propre.
• Include in Output (inclure en sortie) choisit les données d’entrée qui restent dans la sortie du nœud.
• Support Dot Notation (notation à points) est actif par défaut.

Pour toute valeur qui change à chaque exécution, le numéro du devis, l’adresse du client, la date d’échéance, je conseille Edit Fields. Si votre formule ne propose pas $vars, un nœud Edit Fields placé juste après le déclencheur et nommé « Réglages » fait l’affaire : il pose en une fois l’adresse compta et le délai avant relance. Sa limite : si cinq workflows ont besoin de la même adresse, elle est écrite cinq fois, et il faudra la changer cinq fois.

Les variables $vars de n8n : à quoi servent-elles et quelles formules les proposent ?

Les variables personnalisées de n8n, appelées dans une expression par $vars.nom_de_la_variable, rangent une valeur courte que vos workflows peuvent lire : l’adresse du service compta, le taux de TVA, l’adresse web de votre CRM. Ce sont, dit la documentation, des « variables en lecture seule » pour « stocker et réutiliser des valeurs » ; on ne les change que dans l’interface. Elles sont réservées aux formules Cloud Pro et Enterprise, et aux formules auto-hébergées Business et Enterprise.

D’après la page « Define custom variables » de n8n, voici les règles à connaître avant de vous en servir :

• Qui les crée. « Seuls les propriétaires et les administrateurs de l’instance peuvent créer des variables. »
• Taille. La clé (le nom) fait 50 caractères au plus, la valeur 1 000 caractères au plus. Seuls les lettres, les chiffres et le tiret bas sont acceptés.
• Toujours du texte. « Toutes les variables sont des chaînes de caractères » : un taux de TVA rangé sous la forme « 20 » est un texte, pensez-y avant de calculer avec.
• Portée. Une variable est globale (toute l’instance, tous les projets) ou rattachée à un projet, ce second cas étant disponible depuis n8n 1.118.0. Si les deux portent le même nom, la variable du projet l’emporte dans les workflows de ce projet.
• Valeur vide. « Si la variable n’a pas de valeur, n8n la traite comme indéfinie. Les workflows n’échouent pas automatiquement dans ce cas. » Votre relance peut donc partir avec un champ vide sans aucune alerte : ajoutez un contrôle avant l’envoi.
• Lecture seule. Pour une donnée à définir et à lire pendant l’exécution, la même page renvoie vers les données statiques.

Pour en créer une : ouvrez l’onglet Variables, depuis la page de vue d’ensemble (Overview) ou depuis un projet, sélectionnez Add Variable, saisissez la clé et la valeur, choisissez la portée (Global ou Project ; la documentation précise que ce choix n’est « disponible qu’en créant depuis la page de vue d’ensemble », depuis un projet la portée est ce projet), puis Save.

Mon conseil : $vars pour les valeurs partagées par plusieurs workflows, stables, que vous voulez pouvoir changer à un seul endroit. Jamais une clé d’API : ce sont des réglages, et n8n recommande les identifiants pour les données sensibles. Si votre formule ne les propose pas, voyez d’abord ce que coûte n8n selon la formule avant de changer d’offre.

Comment définir des variables d’environnement dans n8n auto-hébergé ?

Une variable d’environnement est un réglage donné au serveur qui fait tourner n8n, pas au workflow : « vous pouvez modifier les réglages de n8n avec des variables d’environnement ». Elle se règle quand vous hébergez n8n vous-même : avec la commande export dans le terminal pour une installation npm, l’option -e de docker run, ou le bloc environment du fichier docker-compose.yaml (npm et Docker sont deux façons d’installer n8n sur un serveur). Dans un workflow, on la lit avec $env, si l’instance l’autorise.

La page de configuration de base de n8n donne les trois méthodes. Avec Docker Compose, cela ressemble à ceci :

n8n:
  environment:
    - EMAIL_COMPTA=compta@votre-entreprise.fr

Trois points à transmettre à la personne qui administre votre serveur :

1. Les secrets du serveur peuvent passer par un fichier. En ajoutant _FILE au nom d’une variable, n8n lit la valeur dans un fichier séparé, ce qui permet d’utiliser les secrets Docker ou Kubernetes. La documentation juge ce suffixe « plus utile pour les données sensibles, comme les identifiants et la configuration de la base de données ».
2. Le fichier .env a changé de lecteur. Les notes des changements incompatibles de n8n 2.0 indiquent que « n8n charge sa configuration d’environnement depuis un fichier .env » et que la mise à jour de la bibliothèque qui le lit peut changer la façon dont il est interprété. Exemple donné : « si vos valeurs contiennent des accents graves, entourez-les de guillemets simples ou doubles ».
3. L’accès à $env peut être fermé. La même page 2.0 annonce que « n8n bloquera par défaut l’accès aux variables d’environnement depuis le nœud Code » et que « la valeur par défaut de N8N_BLOCK_ENV_ACCESS_IN_NODE est désormais true ». Pour le rouvrir dans le nœud Code, elle indique de poser N8N_BLOCK_ENV_ACCESS_IN_NODE=false.

Précaution sur ce dernier point : le 09/10/2026, la page de référence des variables de sécurité affiche encore false comme valeur par défaut de ce réglage, et le décrit ainsi : « autoriser les utilisateurs à accéder aux variables d’environnement dans les expressions et le nœud Code (false) ou non (true) ». Les deux pages officielles ne donnent pas la même valeur par défaut : vérifiez le réglage sur votre propre instance avant de bâtir un workflow sur $env. La liste des variables intégrées de n8n décrit $env comme l’objet qui « contient les variables d’environnement de configuration de l’instance n8n ».

Pour une PME, $env sert à régler le serveur lui-même, et à rien d’autre. Une adresse de service ou un délai de relance que l’équipe doit pouvoir changer n’a rien à faire là : il faudrait toucher à la configuration du serveur, donc passer par la personne qui l’administre. Et pour les données sensibles, la page 2.0 est claire : « utilisez les identifiants ou d’autres méthodes sûres plutôt que des variables d’environnement ».

Données statiques ou tables de données : où garder une valeur d’une exécution à l’autre ?

Je recommande les tables de données pour toute mémoire entre deux exécutions : clients déjà relancés, dernier numéro de devis traité, correspondance entre un code produit et son libellé. La documentation de n8n dit la même chose : « pour conserver des données entre les exécutions, envisagez les tables de données. Elles fonctionnent pendant les tests et ne demandent pas de nœud Code. » Les données statiques restent une fonction expérimentale, réservée au JavaScript et aux petites données.

Les données statiques. La page consacrée à $getWorkflowStaticData en fixe le cadre :

• on y accède par $getWorkflowStaticData('global') pour tout le workflow, ou $getWorkflowStaticData('node') pour un seul nœud ; « vous ne pouvez utiliser les données statiques que dans le nœud Code JavaScript. Le nœud Code Python ne les propose pas » ;
• « les données statiques sont une fonction expérimentale » ;
• « les données statiques ne sont pas disponibles pendant les tests » : le workflow doit être publié et appelé par un déclencheur ou un webhook (une adresse web qui le lance) pour qu’elles soient enregistrées ;
• « ces données doivent rester petites », et « cette fonction peut se comporter de façon peu fiable quand les exécutions sont très fréquentes ».

Les tables de données. La page Data tables de n8n les décrit comme « adaptées à un stockage de données léger à modéré » :

• usages cités : garder des données entre les workflows d’un même projet, poser des marqueurs pour éviter qu’un traitement tourne deux fois, tenir des tables de correspondance ;
• trois accès : le nœud Data Table, l’API de n8n ou l’onglet Data tables ; import et export en CSV possibles ;
• par défaut, une table créée dans un projet est accessible à tous les membres de ce projet, et les administrateurs voient celles de tout le monde ;
• par défaut, l’ensemble des tables d’une instance est limité à 200 Mio, une limite réglable en auto-hébergement avec N8N_DATA_TABLES_MAX_SIZE_BYTES ;
• une alerte apparaît à 80 % ; au-delà de la limite, les ajouts manuels sont bloqués et les workflows tombent en erreur quand ils tentent d’ajouter ou de modifier une ligne ;
• un nœud Code ne peut pas lire une table directement, et une expression non plus : on lit d’abord la ligne avec un nœud Data Table, puis on reprend sa sortie.

La page ne précise pas quelles formules incluent les tables : vérifiez sur votre compte.

Je ne conseille pas les données statiques à une PME qui démarre : expérimentales, absentes pendant les tests, réservées au JavaScript. Et une table n’est pas votre logiciel de gestion : la vraie liste des factures reste dans votre logiciel de facturation, la table ne garde que la trace de ce que le workflow a déjà fait.

Variables n8n : laquelle choisir selon votre cas ?

Choisissez avec trois questions : combien de temps la valeur doit vivre, combien de workflows la lisent, et s’agit-il d’un secret. Une valeur d’une seule exécution va dans Edit Fields, une valeur partagée et stable dans $vars, un réglage de serveur dans $env, une mémoire entre exécutions dans une table de données, et une clé d’API dans les identifiants. Dans le doute, demandez-vous qui devra changer la valeur demain, et où cette personne ira la chercher.

Où ne pas mettre une clé d’API

Ni dans un champ Edit Fields, ni dans $vars, ni dans une table, ni écrite en dur dans un nœud Code. Dans un nœud, elle est écrite dans le workflow ; dans une table, elle est accessible par défaut à tous les membres du projet. La page 2.0 de n8n recommande les identifiants pour les données sensibles, et la page sur le partage des identifiants précise que « les utilisateurs qui se servent d’un identifiant partagé ne pourront ni voir ni modifier le détail de cet identifiant » (partage proposé sur toutes les formules Cloud, et en auto-hébergé sur Business et Enterprise). La première règle à poser dans un workflow : un secret va dans les identifiants, jamais dans un champ.

Un scénario imaginé pour fixer les idées

Prenons une PME qui relance chaque matin ses factures impayées (scénario imaginé, pour illustrer le rangement) :

1. la clé du logiciel de facturation est un identifiant ;
2. l’adresse du service compta, mise en copie de chaque relance, est une variable $vars, ou un nœud « Réglages » si la formule n’en propose pas ;
3. pour chaque facture, un nœud Edit Fields pose le numéro, le montant et l’adresse du client ;
4. une table de données « relances envoyées » est consultée avant l’envoi et complétée juste après, pour ne jamais relancer deux fois la même facture le même jour ;
5. l’envoi lui-même est un sous-workflow, que le workflow des devis peut aussi appeler.

Comment passer des variables à un sous-workflow n8n ?

Pour passer des valeurs à un sous-workflow, celui-ci commence par le nœud Execute Sub-workflow Trigger, où vous déclarez les champs qu’il attend. Le workflow appelant utilise le nœud Execute Sub-workflow, désigne le sous-workflow et remplit ces champs. Le dernier nœud du sous-workflow renvoie ses données à l’appelant. Les $vars, elles, n’ont pas besoin d’être passées : chaque workflow les lit directement, selon leur portée.

Un sous-workflow est un workflow appelé par un autre, comme une brique qu’on réutilise. La page Sub-workflows de n8n décrit trois façons de déclarer ce qu’il reçoit, dans le réglage Input data mode (mode des données d’entrée) :

• Define using fields below (définir avec les champs ci-dessous) : vous listez chaque champ et son type, et « le nœud Execute Sub-workflow ou le nœud Call n8n Workflow Tool du workflow appelant récupère automatiquement les champs définis ici ». C’est celui que je recommande : le sous-workflow annonce ce qu’il attend, et l’appelant n’a plus qu’à remplir les champs affichés.
• Define using JSON example (définir avec un exemple JSON) : vous collez un exemple des données attendues.
• Accept all data (tout accepter) : aucune entrée obligatoire, et « ce sous-workflow doit gérer seul les incohérences et les valeurs manquantes ». À réserver aux cas où l’appelant change souvent de forme.

Côté appelant, la documentation du nœud Execute Sub-workflow propose quatre sources pour désigner le sous-workflow (Database, Local File, Parameter, URL), deux modes (Run once with all items, une seule exécution pour tous les éléments, ou Run once for each item, une exécution par élément) et l’option Wait for Sub-Workflow Completion, qui décide si le workflow principal attend la fin du sous-workflow avant de passer à l’étape suivante.

Trois limites à garder en tête :

• « s’il y a des erreurs dans le sous-workflow, le workflow parent ne peut pas le déclencher » ;
• d’après la page Sub-workflows, les exécutions de sous-workflows ne comptent pas dans les limites mensuelles d’exécutions ni de workflows actifs de votre formule ;
• depuis n8n 2.0, le nœud Start n’est plus pris en charge : d’après les notes des changements incompatibles de n8n 2.0, un ancien sous-workflow qui démarrait par lui doit être repris avec le nœud déclencheur des sous-workflows (nommé Execute Workflow Trigger dans ces notes, Execute Sub-workflow Trigger ailleurs dans la documentation), puis activé.

Pour la relance de factures, le sous-workflow « Envoyer une relance » déclarerait quatre champs : numéro de facture, adresse du client, montant, date d’échéance. Le workflow des factures et celui des devis l’appellent avec leurs propres valeurs, et un changement de modèle de mail se fait à un seul endroit.

Si vos workflows actuels mélangent adresses écrites en dur, clés copiées dans des nœuds et listes tenues à la main, c’est ce rangement que je reprends quand je construis des automatisations n8n pour une PME, avec une documentation claire de chaque automatisation et la formation de votre référent interne. Le coût dépend du nombre de workflows et des outils à connecter ; le premier pas est un appel de quinze minutes pour repérer les premières tâches à confier à n8n. Si vous préférez construire vous-même, la formation IA agentique comprend un atelier n8n : construire, brancher l’IA, mettre en production.

Sources

• n8n, « Define custom variables », page des variables personnalisées, lue le 09/10/2026.
• n8n, « Edit Fields (Set) », page du nœud Edit Fields, lue le 09/10/2026.
• n8n, « Basic configuration », configuration de base, lue le 09/10/2026.
• n8n, « v2.0 Breaking changes », changements incompatibles de n8n 2.0, lue le 09/10/2026.
• n8n, « Security », variables d’environnement de sécurité, lue le 09/10/2026.
• n8n, « n8n metadata », variables intégrées ($env, $vars), lue le 09/10/2026.
• n8n, « getWorkflowStaticData », données statiques du workflow, lue le 09/10/2026.
• n8n, « Data tables », tables de données, lue le 09/10/2026.
• n8n, « Share credentials securely », partage des identifiants, lue le 09/10/2026.
• n8n, « Break workflows into smaller parts », sous-workflows, lue le 09/10/2026.
• n8n, « Execute Sub-workflow », page du nœud Execute Sub-workflow, lue le 09/10/2026.