Gérer les identifiants en toute sécurité : chiffrement, partage, External Secrets

Les identifiants sont le véritable cœur de chaque automatisation n8n : sans clé API, jeton OAuth2 ou mot de passe de base de données, aucun collaborateur numérique ne peut communiquer avec des systèmes externes. C'est précisément pourquoi il vaut la peine d'examiner de près comment n8n protège réellement ces identifiants, qui dans l'équipe peut les utiliser sans les voir, et comment garder des valeurs sensibles entièrement hors de n8n en les faisant gérer par un magasin de secrets externe. État : juillet 2026.

Cet article distingue clairement trois niveaux : le modèle de chiffrement en arrière-plan, les droits de partage pour les équipes et l'intégration de magasins de secrets externes pour les configurations Enterprise. À la fin, vous garderez le contrôle sur le niveau qui convient à votre configuration.

Comment n8n chiffre les identifiants

n8n stocke systématiquement toutes les données d'accès chiffrées dans la base de données, jamais en clair. Selon le guide n8n sur la définition de sa propre clé de chiffrement, n8n génère automatiquement une clé aléatoire au premier démarrage et la stocke dans le dossier `~/.n8n`. n8n utilise cette clé pour chiffrer chaque identifiant avant de l'écrire dans la base de données. Si vous souhaitez garder vous-même le contrôle de cette clé, par exemple pour la gérer de manière centralisée ou créer une sauvegarde indépendante du système de fichiers, définissez la variable d'environnement suivante avant le démarrage :

```

export N8N_ENCRYPTION_KEY=<une longue chaîne aléatoire>

```

Important en équipe et en production : si n8n fonctionne en mode file d'attente (queue) avec plusieurs workers, toutes les instances doivent utiliser exactement la même valeur pour `N8N_ENCRYPTION_KEY`. Sinon, les workers ne peuvent pas déchiffrer les données d'accès chiffrées par le processus principal, et les workflows échouent précisément à l'endroit où un identifiant est nécessaire.

Modèle à deux couches avec rotation des clés

Pour les instances auto-hébergées, n8n propose en plus une rotation du chiffrement. Selon la documentation sur la rotation des clés de chiffrement, n8n fonctionne alors avec deux niveaux :

• Instance Encryption Key (`N8N_ENCRYPTION_KEY`) : la clé maîtresse permanente qui ne change jamais.
• Data Encryption Key : la clé proprement dite, qui chiffre les identifiants et d'autres données sensibles et qui peut être renouvelée sans toucher à la clé maîtresse.

Les données déjà chiffrées restent lisibles après une rotation ; n8n les rechiffre automatiquement avec la nouvelle Data Encryption Key lors des prochaines opérations d'écriture. La fonctionnalité s'active via la variable d'environnement `N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true` sur toutes les instances, après quoi la rotation peut être déclenchée sous Settings > Data Encryption Keys dans l'interface ou via l'API (`POST /encryption/keys`). Un point à bien intégrer au préalable : une fois la fonctionnalité active et de nouvelles données écrites dans le nouveau format, la rotation ne peut plus être annulée et il n'existe aucun outil automatisé pour reconvertir les données. Une sauvegarde complète de la base de données avant l'activation n'est donc pas une option, mais une obligation.

Partager les identifiants en équipe sans les divulguer

Dès que plusieurs personnes travaillent sur les mêmes workflows, la question se pose de savoir qui est autorisé à voir et à utiliser quelles données d'accès. n8n distingue ici délibérément l'utilisation d'un identifiant de la visibilité de ses valeurs. Selon la documentation sur le partage des workflows, la règle est la suivante : quiconque partage un workflow partage automatiquement aussi l'accès à tous les identifiants utilisés à l'intérieur, même si ceux-ci n'ont pas été explicitement partagés individuellement. Cela garantit que les workflows partagés restent réellement exécutables pour toutes les personnes concernées.

Concernant les rôles, n8n distingue deux niveaux :

• Creator (la personne d'origine qui a créé le workflow) : peut consulter, exécuter, modifier, exporter, partager et supprimer le workflow.
• Editor (personnes disposant d'un accès partagé) : peut consulter, exécuter, modifier et exporter, mais ne peut ni partager ni supprimer.

Le principe du moindre privilège continue de s'appliquer de façon cohérente : si un identifiant utilisé dans le workflow n'a pas été partagé individuellement en plus, un Editor peut certes exécuter le workflow et modifier d'autres nœuds, mais ne peut pas modifier précisément le nœud contenant l'identifiant non partagé. Les valeurs d'un identifiant partagé, c'est-à-dire les clés API ou les mots de passe, restent fondamentalement invisibles pour les Editors. Ils peuvent utiliser l'identifiant, mais pas le lire. Une remarque pratique importante au passage : la propriété d'un workflow ne peut pas être simplement transférée, sauf lors de la suppression d'un compte utilisateur. Ainsi, si vous travaillez en équipe dès le départ, vous devriez si possible créer les workflows directement dans un projet partagé plutôt que dans l'espace de travail personnel, car l'ajout d'utilisateurs individuels via la fonction « Add users » ne fonctionne, selon la documentation, que pour les workflows de l'espace personnel. Pour les workflows au sein d'un projet, l'attribution des droits se fait à la place via l'appartenance au projet elle-même.

External Secrets : gérer les données d'accès en dehors de n8n

Pour les configurations Enterprise, n8n va encore plus loin et permet de ne pas stocker du tout les valeurs sensibles dans n8n lui-même, mais de les laisser dans un magasin de secrets externe. Selon la documentation sur les magasins de secrets externes, n8n prend en charge six fournisseurs à cet effet :

• 1Password (via le serveur Connect)
• AWS Secrets Manager
• Azure Key Vault
• GCP Secrets Manager
• HashiCorp Vault
• Infisical

Cette fonctionnalité est réservée aux plans Enterprise Self-hosted et Enterprise Cloud. Un coffre (vault) se configure sous Settings > External Secrets via « Add secrets vault » : vous y attribuez un nom unique au coffre, sélectionnez le fournisseur et saisissez les données d'accès nécessaires. Au sein d'un identifiant, vous accédez ensuite à la valeur externe via une expression, par exemple :

```

{{ $secrets.<vault-name>.<secret-name> }}

```

Pour 1Password, il existe une syntaxe étendue avec titre d'élément et nom de champ : `{{ $secrets.<vault-name>.<item-title>.<field-label> }}`. Il faut connaître une limitation technique : n8n ne prend en charge pour les secrets que des valeurs textuelles simples, pas d'objets JSON, et les expressions ne fonctionnent qu'à l'intérieur des champs d'identifiants, pas dans d'autres champs prenant en charge les expressions. En revanche, la variable d'environnement `N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL` permet de définir la fréquence à laquelle n8n vérifie les modifications dans le magasin externe, par défaut toutes les 300 secondes.

Quel modèle convient à quelle configuration

Pour les petites équipes, en pratique, un `N8N_ENCRYPTION_KEY` correctement défini, combiné à des structures de projet et de partage bien pensées, suffit souvent déjà : qui est autorisé à voir quel workflow détermine automatiquement aussi qui peut utiliser quel identifiant. Mais dès que plusieurs environnements, par exemple staging et production, ont besoin des mêmes accès API, ou qu'une exigence de conformité impose que les secrets soient centralisés dans un coffre et également renouvelés de manière centralisée, External Secrets devient un complément judicieux. Les deux niveaux ne s'excluent pas et peuvent être combinés : le chiffrement de la base de données protège ce que n8n stocke lui-même, tandis qu'External Secrets réduit en plus ce que n8n doit stocker durablement.

Toute personne qui met en place une instance n8n pour une équipe et souhaite planifier correctement dès le départ le chiffrement, la gestion des droits et, le cas échéant, les magasins de secrets externes, trouvera du soutien auprès des automatisations n8n de NordFlux, afin que les données d'accès sensibles se trouvent dès le début là où elles doivent être.

Questions fréquentes

Où n8n stocke-t-il la clé de chiffrement générée automatiquement ?

Par défaut, n8n stocke la clé générée aléatoirement lors du premier démarrage dans le dossier `~/.n8n` et l'utilise pour chiffrer les identifiants avant de les enregistrer dans la base de données. Quiconque souhaite définir la clé lui-même doit définir la variable d'environnement `N8N_ENCRYPTION_KEY` avant le premier démarrage.

Puis-je partager un identifiant sans que d'autres voient la clé API ?

Oui, c'est exactement le cas standard. Si un identifiant est partagé avec un utilisateur ou via un projet, cette personne peut utiliser l'identifiant dans ses propres workflows, mais les valeurs réelles, comme les clés API ou les mots de passe, restent masquées.

Que se passe-t-il si un identifiant utilisé dans le workflow n'a pas été partagé séparément ?

Si un workflow est partagé, la personne invitée peut néanmoins l'exécuter entièrement, car le partage de workflow inclut automatiquement l'utilisation de tous les identifiants qu'il contient. En revanche, le nœud concerné ne peut être modifié que si l'identifiant a également été partagé individuellement ; tous les autres nœuds du workflow restent inchangés.

External Secrets est-il disponible dans tous les plans n8n ?

Non. Selon la documentation, External Secrets n'est disponible que sur les plans Enterprise Self-hosted et Enterprise Cloud. Six fournisseurs sont actuellement pris en charge : 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault et Infisical.

La rotation de la clé de chiffrement peut-elle être annulée ?

Non. Une fois la rotation des clés activée et des données écrites par n8n dans le nouveau format, la fonctionnalité ne peut plus être désactivée, et il n'existe aucun outil automatisé pour revenir à l'ancien format. Une sauvegarde complète de la base de données avant l'activation est donc fortement recommandée.