Un workflow n8n commence souvent petit : un déclencheur, trois nœuds, un résultat. Six mois plus tard, il compte quarante nœuds, trois branches imbriquées, et personne n'ose y toucher de peur de casser ce qui marche. Le même bloc « chercher le client dans le CRM » est recopié dans cinq workflows, avec cinq petites différences.
n8n propose un mécanisme pour sortir de cette impasse : les sous-workflows, c'est-à-dire un workflow qui en appelle un autre. Cet article explique comment cela fonctionne, quand découper, et quelles règles poser pour qu'un ensemble d'automatisations reste maintenable. Les faits sur n8n viennent de sa documentation officielle citée en fin d'article ; les recommandations d'organisation sont notre analyse, à adapter à votre contexte.
Le principe : un workflow qui en appelle un autre
Un sous-workflow se construit avec deux nœuds, selon la documentation :
- dans le workflow appelant (le « parent »), le nœud Execute Sub-workflow ;
- dans le workflow appelé, un déclencheur Execute Sub-workflow Trigger. Dans l'éditeur, on le retrouve sous le nom « When Executed by Another Workflow » ; d'anciennes versions de la documentation parlent d'Execute Workflow Trigger.
Les données passent du nœud du parent vers le déclencheur du sous-workflow. À la fin, le dernier nœud du sous-workflow renvoie son résultat au nœud du parent, qui peut alors poursuivre.
Vous pouvez aussi extraire des nœuds existants vers un nouveau sous-workflow depuis le menu contextuel de l'éditeur, ce qui évite de tout reconstruire à la main quand on découpe un workflow qui a grossi.
Pourquoi découper : trois bénéfices concrets
La documentation de n8n présente les sous-workflows comme un moyen de bâtir des workflows modulaires, et note qu'ils peuvent aider face aux problèmes de mémoire des workflows volumineux. Du côté de l'exploitation, trois bénéfices nous semblent les plus utiles pour une PME.
- Ne corriger qu'à un seul endroit. Une règle métier (formater un numéro de téléphone, normaliser une adresse, créer ou retrouver un contact) vit dans un seul sous-workflow. Quand la règle change, vous modifiez un workflow et non cinq.
- Lire plus vite. Un workflow parent de dix nœuds, dont certains sont des appels à des sous-workflows bien nommés, se comprend en une minute. Quarante nœuds à plat, non.
- Tester par morceaux. Un sous-workflow a des entrées définies et une sortie ; on peut le vérifier seul, avec des données d'exemple, sans déclencher tout le scénario.
Un point de coût mérite d'être signalé : selon la documentation, les exécutions de sous-workflows ne comptent pas dans la limite mensuelle d'exécutions ni dans le nombre de workflows actifs de votre offre. Vérifiez néanmoins les conditions de votre propre offre, qui peuvent évoluer.
Définir les entrées : le vrai sujet
Le déclencheur du sous-workflow propose trois modes pour décrire ce qu'il attend :
- Define using fields below : vous nommez chaque entrée et son type. Le nœud d'appel récupère automatiquement ces champs, ce qui évite les fautes de frappe côté parent.
- Define using JSON example : vous fournissez un exemple d'objet JSON qui montre les éléments attendus et leur type.
- Accept all data : le sous-workflow accepte n'importe quoi. Aucune entrée n'est exigée, donc rien n'apparaît dans le nœud d'appel, et c'est au sous-workflow de gérer les valeurs manquantes ou incohérentes.
Notre recommandation : évitez « Accept all data » en production. C'est pratique pour un essai, mais cela transforme le sous-workflow en boîte noire dont on ne sait plus ce qu'il attend. Un contrat d'entrée explicite joue le rôle d'une signature de fonction : il documente et il protège.
Deux comportements à connaître, d'après la documentation :
- si le parent retire une entrée, le sous-workflow reçoit la valeur
nullpour cet élément ; - l'option Attempt to convert types tente de convertir les données vers le type demandé par le sous-workflow. Pratique, mais elle peut masquer une donnée mal formée plutôt que la signaler.
Les réglages du nœud d'appel
Le nœud Execute Sub-workflow offre plusieurs choix qui changent le comportement de l'ensemble.
La source du sous-workflow. On peut le charger depuis la base (par son identifiant, visible dans l'URL du workflow après /workflow/), depuis un fichier local, depuis un JSON collé dans le nœud ou depuis une URL. Pour une équipe, la voie « Database » est la plus simple à maintenir.
Le mode d'exécution. « Run once with all items » envoie tous les éléments dans une seule exécution du sous-workflow. « Run once for each item » l'exécute une fois par élément, à tour de rôle. Le choix dépend de ce que fait le sous-workflow : un traitement de lot gagne à recevoir tous les éléments ; une action unitaire (créer une fiche, envoyer un message) se prête mieux à l'exécution élément par élément.
L'attente de la fin. L'option Wait for Sub-Workflow Completion, lorsqu'elle est activée, fait attendre le parent jusqu'à la fin du sous-workflow avant de continuer. Désactivée, le parent poursuit sans attendre. Si le parent a besoin du résultat, l'attente est nécessaire ; sinon, ne pas attendre évite de bloquer le scénario principal, au prix d'un suivi plus délicat.
Les pièges à connaître
La documentation signale une contrainte importante : si le sous-workflow contient des erreurs, le parent ne peut pas le déclencher. Un sous-workflow cassé n'est donc pas un problème local : il peut immobiliser tous les workflows qui l'appellent. Plus un sous-workflow est partagé, plus il mérite un soin particulier avant modification.
Il y a aussi un réglage dans les paramètres du sous-workflow, This workflow can be called by, qui contrôle qui peut l'appeler. Prenez le temps de le configurer plutôt que de laisser un morceau de logique accessible depuis n'importe où.
Côté diagnostic, n8n relie les deux exécutions : le nœud du parent affiche un lien View sub-execution, et l'exécution du sous-workflow renvoie vers le parent. En cas d'incident, vous suivez ainsi la chaîne dans les deux sens. Pour être prévenu d'un échec, le dispositif d'alerte décrit dans notre article sur la gestion des erreurs avec l'Error Trigger reste indispensable.
Pour construire un sous-workflow avec de vraies données, la documentation indique qu'il faut pouvoir charger les données d'exécutions précédentes (disponible sur n8n Cloud et sur les offres Community enregistrées). On active l'enregistrement des exécutions réussies du sous-workflow, on lance le parent, on charge les données, puis on les épingle dans le déclencheur.
Des règles de départ pour une PME
Voici le dispositif que nous recommandons comme point de départ. Il découle des mécanismes ci-dessus ; les seuils sont à ajuster.
- Découpez quand un bloc est répété. Dès qu'une même séquence apparaît dans deux workflows, extrayez-la. Avant, inutile de compliquer.
- Un sous-workflow, une responsabilité. « Retrouver ou créer un contact » est un bon sous-workflow ; « tout le traitement des commandes » n'en est pas un.
- Entrées explicites. Utilisez les champs ou l'exemple JSON, pas « Accept all data ».
- Un nom qui dit ce que ça fait. Préfixez par exemple les sous-workflows partagés pour les distinguer des workflows de production.
- Un propriétaire par sous-workflow partagé. Une personne qui valide les changements, car l'impact dépasse un seul scénario.
- Un test avant chaque modification. Vérifiez le sous-workflow seul, avec des données d'exemple, puis un parcours complet.
- Un workflow d'erreur commun relié aux workflows parents, pour que l'échec d'un sous-workflow soit vu.
Si certains de vos sous-workflows sont destinés à servir d'outils à un agent IA, la même discipline d'entrées explicites s'applique : voir notre article sur les workflows comme outils d'un agent IA.
Ce que les sous-workflows ne règlent pas
Découper n'est pas une fin en soi. Trop de sous-workflows imbriqués rendent le suivi plus difficile qu'un grand workflow bien ordonné : on saute d'une exécution à l'autre pour comprendre un seul incident. Les sous-workflows ne remplacent pas non plus un bon choix d'outil ; si vous hésitez encore, notre comparatif n8n, Make et Zapier pour une PME pose les critères de choix. Enfin, ils ne protègent pas l'entrée de vos automatisations, sujet traité dans notre article sur la sécurisation d'un webhook n8n.
Questions fréquentes
Comment appeler un workflow depuis un autre dans n8n ?
Dans le workflow à appeler, ajoutez le déclencheur Execute Sub-workflow Trigger et définissez ses entrées. Dans le workflow parent, ajoutez le nœud Execute Sub-workflow, choisissez le workflow cible (par exemple par son identifiant) et renseignez les entrées demandées.
Où trouver l'identifiant d'un workflow n8n ?
Selon la documentation, l'identifiant est la chaîne alphanumérique à la fin de l'URL du workflow, après /workflow/.
Pourquoi mon sous-workflow n'est-il pas déclenché par le parent ?
La documentation précise que, si le sous-workflow contient des erreurs, le parent ne peut pas le déclencher. Vérifiez aussi le réglage « This workflow can be called by » dans les paramètres du sous-workflow.
Faut-il attendre la fin du sous-workflow ?
Cela dépend de l'option Wait for Sub-Workflow Completion. Activée, le parent attend et peut utiliser le résultat. Désactivée, il continue sans attendre. Choisissez selon que la suite du scénario dépend ou non de la réponse.
Mettre de l'ordre dans vos automatisations
Vos workflows n8n se sont accumulés et vous hésitez à les modifier ? Décrivez-nous votre situation : nous identifions les blocs répétés, proposons un découpage adapté à votre équipe et mettons en place les règles de maintenance. Nos offres détaillent les formats d'accompagnement, et vous pouvez nous contacter directement.
Sources
- n8n, Sub-workflows, documentation consultée le 17 octobre 2026.
- n8n, Execute Sub-workflow, documentation consultée le 17 octobre 2026.
- n8n, Execute Sub-workflow Trigger, documentation consultée le 17 octobre 2026.