Un scénario n8n peut se terminer en succès et envoyer ses données au mauvais client. Un laboratoire publié sur le forum de la communauté n8n le montre, et le relie à un bug encore ouvert. Un sous-workflow (un petit scénario appelé par un autre) y renvoie deux lignes identiques, et le scénario parent les adresse aux mauvais destinataires. Cela concerne des montages précis, pas tout n8n, et seul un test avec des données distinctes par client le détecte.
Ce qui s'est passé dans le laboratoire
Le parent transmet quatre commandes, celles des clients A, B, C et D. Le sous-workflow les traite sur deux branches, puis un nœud Merge (qui rassemble des flux) en retient une seule. Les deux branches retirent l'identité du client des données visibles et produisent les mêmes deux lignes : un produit identique, en quantité un.
De retour dans le parent, une requête HTTP retrouve le client en remontant jusqu'au nœud "Orders" d'origine. Quand la branche "deux dernières commandes" est retenue, les destinataires prévus sont D et C. Les requêtes partent pourtant vers A et B. Le récepteur répond "ok", les deux scénarios sont marqués réussis, et les données de chaque étape métier sont identiques à celles du test témoin.
Selon l'auteur, le lien entre une ligne de sortie et la ligne d'entrée dont elle provient (le pairedItem) se perd au retour du sous-workflow, et n8n retombe sur un appariement local. Version testée : 2.41.7.
Ce qui est établi, ce qui ne l'est pas
Établi : le ticket n8n 35559 a été ouvert le 5 août 2026 et reste ouvert, sans correctif lié. Il décrit un lien hors limites après un Merge en fin de sous-workflow, avec des expressions qui renvoient une valeur nulle sans erreur. Le 25 octobre 2026, un commentateur a reproduit le cas sur la 2.41.7, avec des requêtes HTTP vers de mauvais destinataires.
Plus fragile : un autre utilisateur n'avait pas réussi à reproduire le bug en août, et le comportement est décrit comme intermittent. Le laboratoire est synthétique, avec des lignes volontairement identiques, et son auteur propose une aide payante. L'explication interne vient de lui seul, sans confirmation de n8n.
Le ticket 14568, plus ancien et fermé en octobre 2025, décrivait déjà des liaisons cassées par le sous-workflow. Un utilisateur y a signalé que le problème persistait dans une version ultérieure, avec un Merge. Il s'agit donc d'un bug ouvert et documenté, pas d'une panne générale.
Quels scénarios sont exposés ?
Ceux où un sous-workflow réordonne, filtre ou fusionne des lignes avant que le parent n'envoie vers un client, un CRM ou une facture. Prenons une PME de négoce dont le scénario prépare des confirmations d'expédition pour plusieurs clients : si le sous-workflow trie les commandes puis les fusionne, un message peut partir chez un autre client que prévu, sans alerte.
Un scénario simple, sans sous-workflow ni Merge, n'est pas visé par ce signalement.
La documentation n8n précise par ailleurs que la référence à une ligne d'un autre nœud renvoie une valeur nulle quand ce nœud est sur une autre branche, typiquement après un Merge en mode Append. L'erreur n'apparaît alors que dans l'aperçu de l'expression, pas à l'exécution.
Pour Zapier ou Make, nous n'avons rien trouvé : mieux vaut tester que supposer. Un workflow d'erreur, lui, ne capte rien ici, puisqu'aucune erreur n'est levée.
Comment s'en protéger sans attendre un correctif
Premier réflexe : un test de bout en bout avec des données différentes pour chaque client, qui compare le destinataire réel au destinataire attendu. Un récepteur de test qui enregistre ce qu'il reçoit suffit. Un statut "succès" ne prouve pas que la bonne donnée est partie au bon endroit.
Deuxième précaution : faire voyager un identifiant client stable dans les données elles-mêmes, plutôt que de le retrouver en remontant le scénario. C'est notre recoupement, pas une consigne écrite telle quelle dans les sources, mais il évite de dépendre du mécanisme en cause.
Les tickets proposent aussi des contournements : brancher le sous-workflow sur la première entrée du Merge, passer en mode "Run once for each item", ou éviter un Merge à plusieurs entrées. La documentation recommande first(), last(), all() avec un index, ou un Merge en mode Combine. Un nœud de code qui recopie le lien peut échouer, selon un commentateur. Rétrograder n8n est possible, mais lourd.
L'outil d'audit de l'auteur est en dépôt libre, mais il ne couvre qu'un cas étroit. Une cohérence technique ne remplace pas un contrôle métier.
Nous concevons des scénarios n8n et Make pour des entreprises de Provence, notamment autour de Septèmes-les-Vallons, et ce contrôle fait partie de nos vérifications avant livraison. La discussion d'origine est sur le forum n8n.
- Un sous-workflow n8n avec Merge peut réussir et pourtant rattacher les données au mauvais client : le bug est ouvert (ticket 35559), reproduit en labo et par un commentateur, mais intermittent.
- Les scénarios simples, sans sous-workflow ni Merge, ne sont pas visés.
- Testez avec des données distinctes par client et comparez le destinataire réel à l'attendu.
- Transportez un identifiant client dans les données plutôt que de le retrouver par remontée.
Questions fréquentes
Ce défaut touche-t-il tous les scénarios n8n ?
Non. Le cas décrit suppose un sous-workflow qui fusionne ou réordonne des lignes avant que le scénario parent n'envoie vers un client. Un scénario simple, sans sous-workflow ni Merge, n'est pas concerné par ce signalement.
n8n a-t-il corrigé ce bug ?
Au moment de la rédaction, le ticket n8n numéro 35559 est ouvert, sans correctif lié. Un ancien ticket voisin a été fermé en octobre 2025, mais un utilisateur a signalé que le problème persistait dans une version ultérieure.
Zapier ou Make ont-ils le même problème ?
Nous n'avons trouvé aucune source qui le dise. Le défaut décrit est lié à la façon dont n8n relie les lignes de données entre un scénario et son sous-workflow, il ne faut donc pas l'étendre à d'autres outils sans test.
Faut-il payer pour auditer ses scénarios ?
L'auteur du laboratoire présente un outil d'audit en dépôt libre, sans installation. Il propose aussi une aide payante, dont nous n'avons pas trouvé le tarif. L'outil ne couvre qu'un cas étroit : un test maison reste nécessaire.