Plusieurs clients sur une même instance n8n : projets, droits et les limites de la séparation

Les Projects n8n regroupent les workflows et les identifiants (credentials) et permettent de séparer organisationnellement plusieurs clients ou équipes sur la même instance, mais il s'agit d'une fonctionnalité de contrôle d'accès sur une instance partagée, et non d'une véritable séparation multi-locataire comme des serveurs distincts. Pour une simple séparation interne, cela suffit souvent, mais généralement pas pour des exigences strictes de séparation des données entre clients payants. À jour au : août 2026.

Que font concrètement les Projects ?

Selon la documentation n8n, les Projects regroupent les workflows et les identifiants dans un espace dédié et sont disponibles sur tous les plans payants, mais pas dans l'édition Community. Un même utilisateur peut avoir des rôles différents dans plusieurs projets, ce qui permet par exemple à un membre d'équipe d'être Editor dans le projet client A et Viewer dans le projet client B. Plus de détails dans la documentation n8n sur le travail avec les Projects.

Quels rôles existent au sein d'un projet ?

Au sein d'un projet, trois rôles sont disponibles : Admin, Editor et Viewer, avec des droits clairement hiérarchisés. En plus de tous les workflows, identifiants et exécutions, le Project Admin gère également les membres et les paramètres du projet ; l'Editor peut consulter, créer, modifier et supprimer des workflows, des identifiants et des exécutions, mais ne peut pas gérer les membres ; et le Viewer dispose uniquement d'un accès en lecture, sans possibilité d'exécuter manuellement des workflows. Selon n8n, le rôle Editor est disponible sur Pro Cloud et Self-hosted Enterprise, tandis que le rôle Viewer n'est disponible que sur les niveaux Enterprise de Cloud et Self-hosted, comme le décrit la documentation n8n sur les rôles disponibles.

Où s'arrête la séparation sur le plan technique ?

Les Projects séparent l'accès, pas l'infrastructure sous-jacente : tous les projets d'une instance s'exécutent sur la même installation n8n, la même base de données et les mêmes ressources serveur. Une erreur, un plantage ou une file d'attente surchargée dans un projet client peut donc affecter les exécutions de tous les autres projets sur la même instance, même si les clients ne peuvent pas voir les workflows et identifiants des autres. Selon la documentation, déplacer des ressources supprime également tous les partages existants, ce qui est facilement négligé lors de la restructuration des projets clients.

Quand une instance partagée ne suffit-elle plus ?

Une instance partagée avec Projects suffit généralement tant qu'il s'agit d'une vue d'ensemble organisationnelle au sein de sa propre équipe, et non de garanties strictes envers des clients payants. Dès qu'un client exige des garanties de ressources dédiées, une version propre, des temps d'arrêt indépendants des autres clients ou une séparation contractuelle des données, une instance dédiée par client est la solution la plus fiable. Cette question est étroitement liée à la question de la licence, comme décrit dans l'article Hébergement pour les clients et la licence n8n.

Recommandation pratique pour les agences et les équipes internes

Pour une séparation interne entre équipes ou services au sein d'une entreprise, les Projects sont généralement le choix le plus pragmatique, car ils ne nécessitent pas d'infrastructure supplémentaire. Pour les agences qui exploitent n8n pour plusieurs clients externes, il est en revanche recommandé, dans la plupart des cas, d'utiliser une instance dédiée par client, ou au moins par groupe de clients avec un profil de risque similaire. Nous vous accompagnons dans cette décision et dans la mise en place de la structure adaptée dans le cadre de nos services n8n.

Questions fréquentes sur la séparation des clients dans n8n

Les Projects n8n sont-ils aussi disponibles dans l'édition Community ?

Non, selon la documentation n8n, le RBAC avec Projects est disponible sur tous les plans, sauf l'édition Community. Une installation autohébergée pure sans plan payant ne dispose donc pas de cette possibilité de séparation.

Un utilisateur peut-il avoir des rôles différents dans différents projets ?

Oui, selon n8n, un utilisateur peut avoir des rôles différents selon les projets, par exemple Editor dans l'un et Viewer dans l'autre. Cela permet un contrôle plus fin qu'un rôle global unique pour toute l'instance.

Que se passe-t-il avec les partages existants lorsque je déplace un workflow vers un autre projet ?

Selon la documentation n8n, déplacer un workflow ou un identifiant vers un autre projet supprime tous les partages existants. Le projet cible peut alors avoir besoin d'un nouvel accès aux identifiants requis, sinon le workflow déplacé risque de ne plus fonctionner correctement.

Ai-je nécessairement besoin d'une instance n8n dédiée pour chaque client ?

Pas nécessairement : pour une simple séparation interne ou des clients à faible profil de risque, les Projects peuvent suffire. Dès qu'il s'agit de garanties contractuelles, de résilience indépendante ou d'une séparation stricte des données entre clients, une instance dédiée par client est le choix le plus sûr.