Salut !
J’utilise actuellement Node-RED pour les automations et je réfléchis à une migration vers n8n. J’ai créé des Building Blocks personnalisés, par exemple avec l’API de node red - certains sont écrits en .js/.html et d’autres sont des sous-flux. Ils sont tous empaquetés dans un paquet npm. Je sais qu’on peut créer des nœuds personnalisés dans n8n en TypeScript, donc je ne pense pas que ce sera un problème pour les nœuds en JS/HTML, mais qu’en est-il des nœuds qui sont des sous-flux ? Y a-t-il une façon spécifique de les migrer vers les sous-workflows n8n ? Certains sont complexes, d’autres sont essentiellement des requêtes http, etc. Je me demande s’il y a une option similaire à celle de Node-RED pour les avoir tous dans un paquet npm, ou si je devrais avoir un paquet npm pour les nœuds migrés en TS et ensuite les nœuds qui sont des sous-flux seraient intégrés dans les instances n8n via le contrôle de source ? Plan n8n → Enterprise si on décide de migrer.
Et un autre sujet, tu penses qu’il y a un moyen de migrer rapidement les nœuds/workflows de node-red vers n8n sans le faire manuellement ?
Je t’apprécie vraiment ! Merci !
Salut @Michal_12312312, bienvenue dans la communauté n8n !
J’ai effectué quelques migrations de Node‑RED vers n8n et le mapping qui fonctionne le mieux en pratique est :
– nœuds JS/HTML personnalisés → nœuds n8n personnalisés (TypeScript, distribués sous forme de paquet npm)
– sous-flux → sous-workflows n8n, gérés comme des workflows normaux et versionnés via Git/contrôle de source plutôt que npm.
Pour les sous-flux : dans n8n, je créerais un workflow par « bloc de construction », je le démarrerais avec un Execute Sub-workflow Trigger, et je l’appellerais depuis d’autres flux avec Execute Sub-workflow. Cela vous donne presque la même réutilisabilité que vous avez dans Node‑RED, mais avec des contrats d’entrée/sortie plus clairs.
Il n’y a pas de convertisseur Node‑RED → n8n automatisé dont j’aie connaissance, donc l’approche la plus rapide que j’ai vue est :
-
portez la logique API de bas niveau dans 1 paquet de nœuds personnalisés,
-
reconstruisez vos sous-flux à forte valeur ajoutée en tant que sous-workflows,
-
puis réimplémentez les flux individuels en haut de ces nouveaux blocs de construction.
Si vous êtes ouvert à partager un petit exemple de sous-flux/nœud personnalisé, je serais ravi de vous montrer à quoi ressemblerait l’équivalent n8n 1:1 avant de vous engager dans l’ensemble de la migration.
Merci beaucoup ! @nguyenthieutoan En ce qui concerne les sous-workflows, j’envisageais également d’utiliser des déclencheurs webhook pour certains d’entre eux et d’exécuter par d’autres déclencheurs de workflow, en fonction de la fonctionnalité. Le bloc de construction de connexion utiliserait un webhook par exemple, la requête SQL utiliserait le déclenchement par un autre workflow. La vraie question est le versioning (les packages npm sont faciles bien sûr - je parle des BBs qui sont des subflows) et les mécanismes de distribution entre plusieurs instances n8n. En ce qui concerne les nœuds personnalisés, je suppose que nous aurions un repo privé sur GitHub (et un package rpm) avec tous les nœuds personnalisés dans un package je suppose et le pipeline CI/CD les intégrerait dans les images Docker d’n8n et pousserait ces images vers AWS ECR par exemple et ensuite nous utiliserions ArgoCD pour les distribuer entre les pods.
Avez-vous des suggestions sur à quoi cela ressemblerait en ce qui concerne ces nœuds node-red en tant que subworkflows ?
Merci ! Ça a beaucoup plus de sens pour moi maintenant, je vais définitivement considérer ces options
Bienvenue dans la communauté n8n @Michal_12312312
ce document va t’aider Sub-workflow conversion | n8n Docs
Tu devras ajuster manuellement les types d’entrée/sortie sur les nœuds Start et Return ; le support de l’IA est limité et des fonctions comme first( ) , last( ) et all( ) peuvent nécessiter une révision après la conversion.
Et je suppose qu’il est possible de connecter votre compte/instance n8n ? À un dépôt GitHub avec des sous-workflows et qu’il les extraira dans n8n ? C’est uniquement disponible sur le plan Enterprise et le type de compte administrateur, n’est-ce pas ? @nguyenthieutoan @tamy.santos
Et y a-t-il un moyen de ne pas utiliser ArgoCD par exemple ? Les sous-workflows ne pourraient-ils pas être empaquetés en tant que nœuds comme dans nodered ? Quel serait le meilleur moyen de les distribuer entre les instances (les sous-workflows qui sont déclenchés lorsqu’ils sont exécutés par un autre workflow) ?
Merci d’avance !
Michal, en grande partie oui, mais pas exactement « Réservé aux entreprises » : le contrôle de source d’n8n est une fonctionnalité Business/Enterprise et la connexion est configurée par le propriétaire/administrateur. Considère-le comme une synchronisation de workflows/environnements, pas comme un gestionnaire de packages pour les sous-workflows.
Pour la distribution, divise les éléments : les nœuds personnalisés pour le code que tu veux versionné et installé sur les instances ; les sous-workflows pour l’orchestration que les équipes peuvent modifier dans n8n. Le détail clé est la forme de l’instance : s’agit-il d’une seule instance n8n partagée avec des projets, ou d’instances distinctes client/équipe qui ont toutes besoin de maintenir les mêmes versions de bloc synchronisées ?
Nous n’avons pas encore pris cette décision. Très probablement, chaque développeur aurait sa propre instance sur laquelle il/elle développerait des flux.
Si chaque développeur dispose d’une instance distincte, le risque est une divergence de versions. Ne traitez pas les sous-workflows comme une bibliothèque partagée ; ils deviendront des copies locales dès que les gens commencent à les modifier.
Conservez le code réutilisable dans des nœuds personnalisés et rendez la promotion des workflows/sous-workflows explicite : instance de développement → export examiné/modification du contrôle de source → environnement intermédiaire/production partagé. Les flux approuvés finissent-ils par être intégrés dans une seule instance centrale, ou chaque développeur conserve-t-il sa propre copie ?
@oesterreicher-0417 pour répondre directement à ta question : oui, n8n peut se connecter à un dépôt GitHub, mais c’est la fonctionnalité Source Control (Business/Enterprise) et elle est conçue pour synchroniser les workflows entre environnements (dev → staging → prod), pas comme gestionnaire de paquets.
Pour distribuer des sous-workflows entre instances sans ArgoCD, l’approche la plus légère que j’ai utilisée consiste à exporter le JSON du sous-workflow via l’API n8n (GET /api/v1/workflows/{id}) et l’importer dans chaque instance cible avec un petit script ou un workflow n8n dédié qui appelle POST /api/v1/workflows sur chaque instance. Tu versionnes toujours le JSON dans Git, mais le « déploiement » n’est qu’un appel API au lieu d’un pipeline GitOps.
La contrainte clé que @olmrqs_ops a déjà signalée est juste : une fois que les gens éditent un sous-workflow localement, il diverge. Je bloquérais l’accès en lecture seule au sous-workflow partagé sur les instances dev si tu peux, ou au moins j’imposerais une convention de nommage comme [SHARED] - WorkflowName pour que l’équipe sache qu’il ne faut pas l’éditer sur place.