Booster les performances de vos workflows n8n en choisissant la bonne stratégie d’exécution
MAJ 10/12/2025
Cet article est obsolète compte tenu des dernières évolutions de l’API n8n et de la sortie de la version 2
Introduction
Par défaut, n8n exécute les workflows de manière séquentielle : les nœuds sont traités de gauche à droite, puis de haut en bas en cas de branches multiples. Chaque nœud traite les éléments (items) un par un, ce qui rend le temps d’exécution global proportionnel au nombre d’items à traiter. Cette méthode, simple et adaptée aux processus basiques, peut toutefois devenir inefficace ou limitante lorsque certaines opérations sont lentes comme des appels API avec une forte latence et surtout lorsqu’un retour d’information rapide est requis.
Dans ce contexte, il devient pertinent d’envisager une exécution parallèle ou dites "asynchrone" des items afin d’accélérer l’exécution globale du workflow.
Cet article explore trois stratégies d’exécution :
- L’exécution classique (séquentielle)
- L’exécution de sous-workflows sans attendre la fin
- L’exécution de sous-workflows avec suivi d’état (polling)
1 - Exécution classique : séquentielle et bloquante
C’est le mode d’exécution par défaut dans n8n. Chaque item est traité successivement, un à un, au sein de chaque nœud. Tant qu’un item n’a pas terminé son traitement, le suivant n’est pas pris en charge. En cas d’erreur sur un item, le workflow s’interrompt à l’étape concernée.
Pour illustrer ce fonctionnement, j'ai créé un workflow avec un nœud Wait introduisant un délai de 5 secondes + une loop. Une fois ce délai écoulé, une entrée est ajoutée dans une table SQL, simulant ainsi un traitement lent.
Avantages
- Comportement par défaut
- Plus simple à lire, à comprendre et à déboguer
Inconvénients
- Durée d’exécution proportionnelle au nombre d’items
- Aucune tolérance aux erreurs sans gestion explicite
Workflow principal :
Résultats
On observe un décalage de 5 secondes entre chaque sous-workflow, ce qui entraîne un cumul des temps d’attente. Les items sont donc exécutés de manière strictement séquentielle, dans l’ordre 1, 2, etc.
2 - Exécution de sous-workflows sans attendre la fin
n8n permet de déléguer l’exécution à des sous-workflows sans attendre leur fin. Pour cela, il suffit de désactiver l’option "Wait For Sub-Workflow Completion" dans le nœud concerné. Dans ce mode, chaque sous-workflow est déclenché presque simultanément, permettant ainsi une exécution parallèle des items en entrées.
La différence est visible dans l’ordre d’enregistrement dans la base SQL : contrairement à l’exécution séquentielle, les entrées arrivent dans un ordre aléatoire, reflet du traitement parallèle.
Avantages
- Le workflow principal n’est pas bloqué et peut se terminer immédiatement
- Permet de déléguer des tâches longues à d’autres workflows
Inconvénients
- Aucun contrôle sur la réussite ou l’échec des sous-workflows
- Pas de retour de données possible vers le workflow parent
- Risque de surcharge si trop de sous-workflows sont lancés simultanément
Workflow principal avec son nœud "Execute Workflow" :
Sous-workflow exécuté :
Résultats
Tous les sous-workflows se terminent quasiment simultanément mais dans un ordre non linéaire.
3 -Exécution de sous-workflow avec suivi d’état
Comment lancer plusieurs sous-workflows en parallèle tout en s’assurant qu’ils soient tous terminés avant de poursuivre d'autres actions ? La solution consiste à combiner l’exécution parallèle de sous-workflow via l’API de n8n et une boucle de contrôle dans le workflow principal attendant les callbacks des sous-workflows. Il faudrait évaluer la résilience lors d'une mise à l'échelle en prod.
J'ai pas mal tâtonné pour mettre en oeuvre cette solution. L'api de n8n ne remonte pas les workflows ayant un status "running" alors qu'ils sont bien visibles depuis l'interface n8n... J'ai également essayé de passer par la base de données directement mais j'ai rencontré le même problème. J'ai finalement trouvé un pattern répondant à ce besoin. J'ai adapté ce pattern pour mon test en ajoutant un identifiant unique généré automatiquement (UUIDv4). Je vous laisse décortiquer le workflow pour découvrir les détails.
Chaque sous-workflow est lancé via un appel HTTP à l’API interne de n8n, l'identifiant unique de type UUID que nous avons généré pour chaque items est assigné à chaque sous-workflow comme clé d'identification. Les sous-workflows, une fois terminés, envoient un callback vers le workflow principal. Celui-ci boucle tant que tous les sous-workflows n’ont pas envoyé leur callback pour indiquer la fin du traitement.
Avantages
- Permet une exécution parallèle avec suivi d’état
- Assure que toutes les tâches sont complètes avant de continuer
Inconvénients
- Mise en œuvre complexe scalable ?
- Maintenance plus délicate voir complexe
- Attention à la charge serveur si de nombreux sous-workflows sont lancés simultanément !
Workflow principal avec contrôle d'exécution des sous-workflow :
Sous-workflow lancé via l'api et son webhook :
Résultats
Tous les sous-workflows se terminent quasiment simultanément.
Résumé
n8n propose par défaut un mode d’exécution simple et séquentiel, parfaitement adapté à des cas d’usage basiques. Ce sera sans doute le mode le plus courant. Toutefois, pour des traitements plus conséquents ou des appels à des services externes lents, des alternatives existent pour paralléliser l'exécution des workflows.
Selon vos besoins en termes de performance, de fiabilité et de contrôle, vous pouvez opter pour une exécution non bloquante via des sous-workflows ou une approche plus avancée combinant parallélisme et suivi d'état.
Chaque méthode a ses avantages et ses limites. Il est donc essentiel d’évaluer vos objectifs techniques et opérationnels avant de choisir le modèle d’exécution le plus adapté à votre contexte.
Tous les workflows d'exemples sont disponibles sur mon github.
