Utilisateurs, rôles et permissions dans n8n self-hosted : travailler à plusieurs sans se marcher dessus

Tant que vous êtes seul sur votre instance n8n, la question des permissions ne se pose pas : vous êtes owner, tout vous appartient, tout va bien. Le jour où un collègue rejoint l'aventure, les problèmes concrets arrivent vite — qui a modifié ce workflow de facturation hier soir ? Pourquoi ce stagiaire a-t-il accès à la clé API du CRM de production ? Comment donner à l'équipe marketing l'usage de la connexion Slack sans lui donner le token ? n8n self-hosted embarque un système d'utilisateurs, de rôles et de partage qui répond à ces questions, avec toutefois des limites honnêtes à connaître : une partie des fonctions avancées est réservée aux plans payants. Voici comment structurer une instance multi-utilisateurs proprement, en sachant exactement où passe cette frontière.

Le compte owner : le premier utilisateur de l'instance

À la première ouverture d'une instance fraîchement installée (voir notre guide d'installation Docker), n8n vous demande de créer le premier compte : c'est le compte owner. Il est unique — une instance n'a qu'un seul owner — et il détient les droits les plus étendus : gestion des utilisateurs, accès aux paramètres de l'instance, visibilité sur les ressources.

Deux conséquences pratiques. D'abord, ce compte ne devrait pas être le compte de travail quotidien de qui que ce soit : réservez-le à l'administration, protégez-le avec un mot de passe fort et l'authentification à deux facteurs, et travaillez au quotidien avec un compte membre nominatif. Ensuite, notez précieusement à qui appartient ce compte et comment le récupérer : un owner dont personne ne connaît plus les identifiants, c'est une intervention en base de données ou en ligne de commande pour reprendre la main.

Inviter des membres : SMTP ou lien à copier

L'invitation d'utilisateurs se fait depuis les paramètres de l'instance, section utilisateurs. Deux cas de figure :

• SMTP configuré : n8n envoie automatiquement un email d'invitation contenant le lien d'activation. La configuration passe par des variables d'environnement (N8N_SMTP_HOST, N8N_SMTP_PORT, N8N_SMTP_USER, N8N_SMTP_PASS, entre autres) à définir dans votre docker-compose.yml ou l'environnement du conteneur.
• Pas de SMTP : l'invitation fonctionne quand même. n8n crée le compte en attente et vous affiche un lien d'invitation à copier, que vous transmettez vous-même au nouvel arrivant. Le lien lui permet de définir son mot de passe et d'activer son compte.

Pour une petite équipe, le lien copié suffit largement. Le SMTP devient intéressant à partir du moment où les invitations sont fréquentes, ou pour activer la réinitialisation de mot de passe par email — sans SMTP, un mot de passe oublié se règle côté administrateur.

Les rôles globaux : owner, admin, member

n8n distingue trois niveaux de rôle au niveau de l'instance :

• Owner — le propriétaire unique de l'instance, tous les droits.
• Admin — des capacités de gestion étendues (gestion des utilisateurs, visibilité large sur les ressources) sans être le propriétaire. La disponibilité de ce rôle et le détail de ses permissions dépendent de votre plan n8n.
• Member — le rôle par défaut de tout invité : il crée ses propres workflows et credentials, et n'accède aux ressources des autres que si on les lui partage explicitement.

Ce découpage suit le modèle classique du contrôle d'accès par rôles (RBAC), formalisé par Sandhu, Coyne, Feinstein et Youman dans « Role-Based Access Control Models » (IEEE Computer, 1996 — voir sur Google Scholar) : plutôt que d'attribuer des permissions une à une à chaque individu, on attribue des rôles porteurs de permissions, ce qui rend l'administration prévisible et auditable. C'est exactement la philosophie que reprennent les rôles globaux et les rôles par projet de n8n.

Un point d'honnêteté important : sur le plan Community self-hosted, ne comptez avec certitude que sur le duo owner/member et le partage explicite de ressources. Le rôle admin, le RBAC fin, le SSO/SAML et l'annuaire LDAP relèvent des plans payants — vérifiez dans votre propre interface ce qui est activé pour votre licence avant de concevoir votre organisation autour d'une fonctionnalité que vous n'avez pas.

Partager workflows et credentials entre utilisateurs

Par défaut, chaque membre ne voit que ce qu'il a créé. Le partage se fait ressource par ressource, et c'est là que le modèle de n8n devient réellement utile.

Partage de workflows. Le créateur d'un workflow peut le partager avec d'autres utilisateurs, qui peuvent alors le consulter et, selon les droits accordés, le modifier. C'est le mécanisme de base pour la maintenance à plusieurs : le workflow de facturation n'appartient plus à « la personne partie en vacances » mais à l'équipe qui en a l'usage.

Partage de credentials. C'est la fonctionnalité la plus précieuse du lot : partager une credential permet à un collègue de l'utiliser dans ses workflows sans jamais voir le secret. Il sélectionne « CRM production » dans la liste, ses appels fonctionnent, mais la clé API elle-même reste invisible et inexportable pour lui. Vous séparez ainsi l'usage d'une connexion de la connaissance de son secret — un pattern que nous détaillons dans notre article sur la sécurisation des credentials, et qui change tout le jour où quelqu'un quitte l'équipe : révoquer un accès ne signifie plus faire tourner toutes les clés qu'il a pu voir.

Projets : cloisonner les équipes sur une même instance

Au-delà du partage individuel, n8n propose la notion de projet : un conteneur qui regroupe workflows et credentials, avec des membres et des rôles par projet (administrateur du projet, éditeur, lecteur, selon les versions). L'équipe marketing travaille dans son projet, l'équipe finance dans le sien, et personne ne voit les ressources de l'autre — le cloisonnement se gère au niveau du conteneur plutôt que ressource par ressource.

C'est ici que la frontière des plans se fait le plus sentir : la possibilité de créer plusieurs projets, la granularité des rôles par projet et le RBAC avancé sont, pour l'essentiel, réservés aux plans payants de n8n. Si vous êtes sur le plan Community et que le cloisonnement entre équipes est un vrai besoin, deux alternatives pragmatiques existent : des instances séparées par équipe (le self-hosted rend cette option peu coûteuse, comme le montre notre analyse du coût réel du self-hosted), ou une séparation par environnement plutôt que par rôle, sujet du paragraphe suivant.

Bonnes pratiques pour une instance à plusieurs

Appliquer le principe du moindre privilège. Chaque utilisateur ne doit recevoir que les accès strictement nécessaires à sa tâche — un principe formulé dès 1975 par Saltzer et Schroeder dans « The Protection of Information in Computer Systems » (Proceedings of the IEEE — voir sur Google Scholar), et qui n'a pas pris une ride : moins un compte a de droits, moins sa compromission ou son erreur coûte cher. Concrètement : rôle member par défaut, partages explicites, et pas de credential de production partagée « pour dépanner ».

Une credential de service plutôt que des comptes personnels. Quand un workflow envoie des emails ou poste sur Slack, créez un compte de service dédié (« automation@votre-domaine ») et partagez cette credential unique, plutôt que de laisser chacun brancher son compte personnel. Le jour d'un départ, rien ne casse ; et les actions des workflows sont clairement identifiables comme telles dans les outils cibles.

Séparer dev et prod plutôt que multiplier les rôles. Vouloir tout régler par les permissions sur une instance unique mène vite à une usine à gaz. Une instance de développement où tout le monde expérimente librement, et une instance de production verrouillée où seuls un ou deux comptes déploient, règle 80 % du problème avec deux rôles et zéro RBAC avancé. Notre guide sur les environnements dev/prod détaille cette architecture.

Tracer qui modifie quoi. Les permissions disent qui peut agir ; encore faut-il savoir qui a agi. Versionner les workflows dans Git (voir notre article sur le versioning des workflows avec Git) donne un historique lisible des modifications, avec auteur et date, indépendamment de ce que votre plan n8n journalise nativement.

Pièges fréquents

• Travailler au quotidien avec le compte owner. Toute erreur de manipulation se fait alors avec les droits maximaux, et l'historique ne distingue plus l'administration de l'usage courant. Créez-vous un compte member nominatif dès le deuxième jour.
• Supposer qu'une fonctionnalité vue dans la documentation est incluse dans votre plan. Projets multiples, rôles avancés, SSO/SAML, LDAP : la documentation n8n décrit tout, votre licence n'active pas tout. Vérifiez dans votre propre interface avant de promettre un cloisonnement à votre équipe.
• Contourner le partage de credentials en copiant les clés. Si chacun recrée « sa » credential avec la même clé API collée depuis un canal Slack, vous perdez le bénéfice du secret masqué et la révocation devient impossible à suivre. Une credential, un propriétaire, des partages.
• Oublier de désactiver les comptes des partants. Un compte member orphelin conserve ses accès et ses partages. Intégrez la désactivation n8n dans votre checklist de départ, au même titre que la messagerie.
• Multiplier les rôles pour compenser une absence de séparation dev/prod. Si vous vous surprenez à inventer des conventions de nommage pour distinguer les workflows « à ne pas toucher », c'est le signe qu'il vous faut une deuxième instance, pas un rôle de plus.

Pour aller plus loin

La gestion des utilisateurs est l'une des différences structurantes entre auto-hébergement et cloud — notre comparatif self-hosted vs cloud vous aidera à situer votre besoin si vous hésitez encore. Et parce que les permissions ne disent que qui peut agir, pas ce que les workflows font réellement des données, le Pack Conformité & Audit (149 €) complète naturellement ce contrôle d'accès par une piste d'audit exploitable : journalisation des traitements, traçabilité des exécutions et conformité RGPD, dans la lignée de notre article sur la piste d'audit RGPD avec Supabase. Contrôler l'accès à l'instance, puis tracer ce qui s'y passe : les deux moitiés d'une même exigence.