Ordre d'exécution et fusion : pourquoi les branches ne s'exécutent pas comme on le pense

Lorsque tu construis dans n8n un workflow qui se divise en plusieurs branches après un nœud If ou Switch, tu supposes probablement que ces branches s'exécutent simultanément et se retrouvent simplement au nœud Merge. C'est précisément cette hypothèse qui cause régulièrement de la confusion, car n8n n'exécute pas les branches en parallèle au sens de simultanément, mais selon un ordre fixe et traçable. Quiconque ne connaît pas cet ordre s'étonne d'exécutions qui semblent se produire dans le mauvais ordre, d'appels API qui se dépassent mutuellement, ou d'un nœud Merge qui semble rester bloqué indéfiniment.

La bonne nouvelle : la logique sous-jacente est clairement documentée et peut être prédite de manière fiable avec quelques règles de base. Dans cet article, nous examinons comment n8n détermine l'ordre d'exécution, ce qui a changé avec la version 1.0, et ce que le nœud Merge attend vraiment une fois que tu as compris sa logique. Tu gardes ainsi le contrôle de tes workflows, même s'ils deviennent plus complexes à chaque branche supplémentaire.

Deux logiques d'exécution : v0 (héritée) et v1.0+

Selon la documentation officielle sur l'Execution Order, n8n distingue deux modes d'exécution fondamentalement différents, selon le moment où un workflow a été créé :

• v0 (héritée) : Dans les workflows créés avant la version 1.0, l'ancienne logique s'applique par défaut. n8n exécute d'abord le premier nœud de chaque branche, puis le deuxième nœud de chaque branche, et ainsi de suite. Les branches s'exécutent donc couche par couche côte à côte, et non complètement l'une après l'autre.
• v1.0 et plus récent : Depuis la version 1.0, n8n traite une branche complètement avant que la suivante ne commence. Une branche s'exécute donc entièrement, y compris tous les nœuds qu'elle contient, avant que n8n ne passe à la branche suivante.

Cette différence est à l'origine de la plupart des malentendus. Quiconque travaille avec un workflow plus ancien ou reprend un modèle d'un ancien tutoriel constate un comportement différent de celui d'une personne qui construit un workflow nouvellement créé dans une version actuelle de n8n. Selon la documentation, les deux modes peuvent être ajustés via les paramètres du workflow si tu as spécifiquement besoin de l'autre comportement.

Comment n8n détermine l'ordre des branches

Pour les workflows à partir de la version 1.0, une règle fixe et traçable s'applique : n8n se base sur la position des nœuds sur le canevas. Les branches sont traitées de haut en bas. Si deux branches se trouvent à la même hauteur, c'est la position horizontale qui décide, la branche de gauche étant exécutée en premier.

Concrètement, cela signifie que si tu disposes deux ou trois branches parallèles après un nœud Switch dans ton workflow, c'est uniquement la disposition visuelle sur le canevas qui détermine quelle branche passe en premier, et non l'ordre dans lequel tu as tracé les connexions, ni un quelconque identifiant interne. C'est particulièrement important lorsque des branches individuelles ont des effets de bord, par exemple des accès en écriture à la même table, des mises à jour du même enregistrement CRM ou des appels à la même API soumise à une limitation de débit. Si une branche s'exécute avant l'autre, le résultat de la seconde branche peut dépendre de la première, même si ce n'était pas prévu dans la conception du workflow.

Le nœud Merge : ce qu'il attend vraiment

Le nœud Merge combine les données de plusieurs sources en un seul flux. En mode Append, une règle simple mais souvent négligée s'applique : le nœud attend que toutes les entrées connectées aient été exécutées avant de continuer lui-même. Ce n'est que lorsque chaque entrée a fourni des données, ou explicitement aucune donnée, que le nœud Merge produit une sortie.

Cela explique deux observations fréquentes de la pratique :

• Un nœud Merge qui semble bloqué attend en réalité le plus souvent une branche qui n'est pas encore terminée ou qui ne s'exécute jamais en raison d'une condition.
• En cas de flux de données de longueurs inégales, la règle suivante s'applique : les éléments arrivant à l'entrée 1 ont priorité. Si le nœud Merge reçoit par exemple cinq éléments à l'entrée 1 et dix éléments à l'entrée 2, il ne traite que cinq éléments, car l'entrée 1 fixe la limite supérieure.

Depuis la refonte majeure du nœud Merge dans la version 0.194.0 et l'extension à plus de deux entrées ainsi que le mode requête SQL dans la version 1.49.0, il est en outre possible de fusionner plus de deux branches simultanément, ce qui simplifie nettement la logique classique à deux branches dans les workflows plus importants. Les détails sur tous les modes de fusion tels qu'Append, Combine et Choose Branch se trouvent dans le guide sur la fusion des flux de données.

Le piège dans les anciens workflows : nœud If plus Merge

Un comportement particulièrement pernicieux, selon la documentation, concerne exclusivement les workflows avec l'ordre d'exécution hérité v0, c'est-à-dire par défaut tous les workflows créés avant la version 1.0. Si tu ajoutes un nœud Merge à une structure contenant un nœud If dans un tel workflow, il peut arriver que les deux flux de sortie du nœud If soient exécutés, alors que le nœud If ne devait en réalité déclencher qu'un seul des deux chemins. La raison : un flux de données déclenche le nœud Merge, qui exécute alors également l'autre flux de données, en réalité inactif.

Ce comportement a été supprimé avec la version 1.0. Quiconque migre ou maintient un ancien workflow et observe des exécutions doubles inexplicables après un nœud If trouve souvent ici la cause. Un passage au nouvel ordre d'exécution dans les paramètres du workflow résout généralement le problème de manière fiable.

Comment vérifier et régler l'ordre d'exécution

Avant de déboguer un workflow existant, il vaut la peine de jeter un coup d'œil rapide aux paramètres du workflow : tu y vois quel ordre d'exécution est actuellement actif et tu peux, si nécessaire, basculer entre v0 et v1.0. Pour les nouveaux workflows, la logique actuelle est généralement recommandée, car elle est plus prévisible et le piège If-plus-Merge décrit ne se produit pas du tout.

Pour les automatisations plus complexes avec plusieurs branches parallèles et des effets de bord, il vaut également la peine d'utiliser délibérément la disposition sur le canevas : place la branche qui doit s'exécuter en premier en haut ou à gauche, et consigne cette intention dans le workflow lui-même, par exemple via une note autocollante. Ainsi, chaque membre de l'équipe peut comprendre pourquoi l'ordre a été choisi exactement de cette manière, et personne n'a besoin de deviner à nouveau la logique lors de la prochaine refonte. Si tes automatisations sont si ramifiées que l'ordre n'est plus compréhensible d'un coup d'œil, nous t'accompagnons avec notre automatisation n8n pour structurer les workflows de manière propre et traçable.

Questions fréquentes

Les branches dans n8n ne s'exécutent-elles vraiment pas en parallèle ?

Non, du moins pas au sens d'une exécution simultanée. Dans les workflows à partir de la version 1.0, n8n traite une branche complètement avant que la suivante ne commence, contrôlé par la position des nœuds sur le canevas. Dans les anciens workflows v0, l'exécution se déroule au contraire nœud par nœud, couche par couche, sur toutes les branches, ce qui n'est pas non plus un véritable parallélisme.

Pourquoi mon nœud Merge semble-t-il attendre indéfiniment ?

En mode Append, le nœud Merge attend l'exécution de toutes les entrées connectées. Si l'une des branches précédentes ne se termine pas, par exemple parce qu'une condition n'est pas remplie ou qu'un nœud génère une erreur, le nœud Merge ne reçoit jamais de signal de cette entrée et reste donc sans sortie.

Que se passe-t-il si les deux entrées du nœud Merge fournissent un nombre différent d'éléments ?

Les éléments à l'entrée 1 ont priorité. Si le nœud Merge reçoit par exemple cinq éléments à l'entrée 1 et dix à l'entrée 2, il ne traite que cinq éléments, car l'entrée 1 fixe la limite supérieure du traitement.

Le piège If-plus-Merge concerne-t-il aussi les nouveaux workflows ?

Non. Selon la documentation de n8n, ce comportement s'applique exclusivement aux workflows avec l'ordre d'exécution hérité v0, c'est-à-dire par défaut à tous les workflows créés avant la version 1.0. Dans les workflows nouvellement créés avec l'ordre d'exécution actuel, ce problème ne se produit plus.

Puis-je modifier ultérieurement l'ordre d'exécution d'un workflow existant ?

Oui. L'ordre d'exécution peut être modifié dans les paramètres du workflow. Cela est particulièrement utile pour les workflows anciens et migrés, si tu observes des exécutions multiples inexplicables après des nœuds If ou Switch et que tu soupçonnes que la cause réside dans l'ancienne logique v0.