Le node Merge dans n8n : combiner les données de plusieurs branches sans tout casser

Un workflow n8n qui reste linéaire du déclencheur à la dernière étape est rare : dès qu'un IF, un Switch ou un appel API parallèle entre en jeu, les données se retrouvent réparties sur plusieurs branches — et il faut les recombiner avant la suite. C'est exactement le rôle du node Merge, l'un des nodes core les plus utilisés et pourtant l'un des plus mal compris, parce que ses quatre modes ne se comportent pas du tout de la même façon. Se tromper de mode ne provoque pas toujours une erreur visible : parfois, le workflow tourne, mais silencieusement mélange ou perd des données. Ce guide détaille les quatre modes, leurs pièges, et un cas pratique directement inspiré des workflows d'automatisation par IA.

Pourquoi le node Merge revient dans presque tous les workflows IA

Le besoin de recombiner des branches apparaît dès qu'un workflow enrichit une donnée sans la remplacer. Exemple typique : un email passe par un node de classification IA (comme dans notre guide sur le tri d'emails par IA) qui renvoie une catégorie et un résumé — mais la suite du workflow a aussi besoin du corps original de l'email, de l'expéditeur, de la date de réception. Deux options s'offrent à vous : soit le prompt du LLM renvoie l'intégralité des champs d'origine en plus de sa classification (fragile, coûteux en tokens, et le modèle peut altérer un champ qu'il était censé se contenter de recopier), soit vous laissez le LLM ne renvoyer que ce qu'il a produit, et vous le recombinez ensuite avec la donnée d'origine grâce au node Merge. La seconde approche est presque toujours la bonne : elle sépare clairement ce que le modèle doit produire de ce qu'il doit transporter.

Les quatre modes du node Merge

Append : empiler sans appariement

Append concatène les items des deux entrées, dans l'ordre — d'abord tous ceux de l'entrée 1, puis tous ceux de l'entrée 2. Aucun rapprochement n'est fait entre les items : si vous cherchez à associer une donnée d'une branche à son équivalent dans l'autre, ce n'est pas le bon mode. Append convient plutôt à la situation inverse : rassembler dans un seul flux des résultats indépendants, par exemple les sorties de plusieurs branches d'un Switch qui n'ont pas vocation à être comparées entre elles, avant un traitement commun (écriture dans une même table, par exemple).

Combine : le mode le plus utilisé, avec trois variantes

Combine fusionne les items deux à deux plutôt que de les empiler, selon l'un des trois réglages de « Combine By » :

• Matching Fields — le mode le plus fiable pour un enrichissement : vous indiquez un champ commun (un identifiant d'email, un ID de ligne Supabase) et le node associe chaque item de l'entrée 1 à celui de l'entrée 2 qui partage la même valeur, quel que soit leur ordre. Cinq réglages de sortie sont disponibles : ne garder que les correspondances, ne garder que les non-correspondances, tout garder, ou enrichir spécifiquement l'entrée 1 ou l'entrée 2 avec les champs de l'autre.
• Position — associe les items par leur rang (le 1er avec le 1er, le 2e avec le 2e…), sans se soucier de leur contenu. Rapide à mettre en place, mais dangereux dès qu'un filtre en amont a pu faire perdre des items sur une seule branche : l'appariement glisse silencieusement, et rien ne signale l'erreur.
• All Possible Combinations — produit le produit cartésien des deux entrées (chaque item de l'entrée 1 avec chaque item de l'entrée 2). Utile pour générer des combinaisons (associer chaque destinataire à chaque modèle de message, par exemple), rarement pour un simple enrichissement.

SQL Query : pour les logiques de fusion complexes

Ce mode traite les entrées comme des tables (input1, input2…) et accepte une requête SQL paramétrable pour les combiner — jointures, agrégations, filtres complexes. Il devient pertinent quand la logique de fusion dépasse ce qu'un simple appariement par champ permet d'exprimer, sans pour autant justifier un node Code séparé.

Choose Branch : ne garder qu'une seule entrée

Choose Branch ne fusionne rien : il laisse passer une seule des entrées (ou un item vide) et ignore l'autre. Utile en fin de workflow quand deux branches convergent mais qu'une seule doit réellement continuer — par exemple après un test A/B où seule la branche gagnante doit écrire en base.

Gérer les conflits de champs (Clash Handling)

Quand les deux entrées partagent un champ du même nom, n8n doit choisir une valeur : par défaut, l'entrée 2 l'emporte. Dans Options > Clash Handling, vous pouvez inverser cette priorité, ou choisir « Always Add Input Number to Field Names » pour conserver les deux valeurs en suffixant chaque champ du numéro de son entrée — la sécurité par défaut quand vous n'êtes pas certain que la donnée « perdante » soit vraiment superflue.

Ce mécanisme d'appariement par champ (Matching Fields) n'a rien d'un détail d'implémentation propre à n8n : il reprend, à échelle réduite, un problème que la statistique appelle le record linkage — rapprocher deux enregistrements censés désigner la même entité. La théorie de référence sur le sujet, publiée par Fellegi et Sunter dès 1969, formalise déjà les trois issues possibles d'un tel rapprochement : lien certain, non-lien certain, et cas ambigu nécessitant une règle de décision explicite. Le node Merge simplifie radicalement ce cadre — il compare une égalité stricte sur un champ plutôt qu'une probabilité de correspondance — mais le principe reste le même : mieux vaut une règle d'appariement explicite (Matching Fields) qu'un appariement implicite par ordre (Position), qui échoue silencieusement dès que les hypothèses ne tiennent plus.

Cas pratique : enrichir une classification IA avec la donnée d'origine

Reprenons le workflow de tri d'emails du Pack Inbox IA (79 €) : un email passe par un Structured Output Parser qui renvoie uniquement categorie, resume et expediteur_important. Pour router puis journaliser l'email dans Supabase, il faut aussi le sujet, l'expéditeur et le corps original — des champs que le LLM n'a jamais reçu à reproduire. La construction la plus robuste :

1. Un node Set juste après le trigger IMAP capture les champs originaux utiles et leur attribue un identifiant stable (par exemple le messageId de l'email).
2. Le même identifiant est propagé jusqu'à la sortie du LLM, en le rappelant dans le prompt ou en le préservant via $json si le node LangChain le transmet automatiquement.
3. Un node Merge en mode Combine → Matching Fields, avec messageId comme champ commun et le réglage « Enrich Input 1 » (l'email original), recolle la classification IA à l'email complet — sans jamais avoir demandé au modèle de recopier un champ qu'il aurait pu altérer.

Cette séparation entre ce que le LLM produit et ce qu'il transporte réduit aussi le nombre de tokens envoyés et reçus, un point qui compte quand le volume grandit — voir notre guide sur le suivi du coût des appels IA.

Merge vs un node Code fait maison

Un node Code avec une boucle JavaScript peut reproduire n'importe lequel de ces comportements — et c'est parfois justifié pour une logique vraiment spécifique, dans l'esprit de notre guide sur les expressions JavaScript en node Code. Mais pour les cas courants (appariement par identifiant, empilement, sélection de branche), le node Merge reste préférable : il est visuellement explicite dans le canvas, ne demande aucune ligne de code à maintenir, et ses modes couvrent la quasi-totalité des besoins réels sans qu'un développeur ait à relire une boucle for à chaque modification du workflow.

L'erreur qu'un merge visuel évite

La tentation, en dehors de n8n, est souvent de recombiner deux jeux de données à la main dans un tableur — coller-spécial, RECHERCHEV, tri manuel par colonne. Les recherches menées depuis les années 1990 sur la fiabilité des tableurs montrent que ce type de manipulation manuelle est une source d'erreurs largement sous-estimée : l'étude de synthèse de Panko (1998) recense des taux d'erreur significatifs dans la quasi-totalité des feuilles de calcul de taille réelle auditées, la plupart du temps liés précisément à des opérations de rapprochement ou de recopie entre plages de données. Un node Merge configuré une fois, versionné avec le reste du workflow (voir notre guide sur la sauvegarde des workflows avec Git), élimine cette classe d'erreur : l'appariement est déterministe et rejoué à l'identique à chaque exécution, contrairement à une manipulation refaite à la main à chaque nouveau fichier.

Pour aller plus loin

Le node Merge n'est pas glamour, mais c'est l'un de ceux dont la mauvaise configuration passe le plus souvent inaperçue — jusqu'à ce qu'un rapport ou une alerte contienne une donnée décalée. Retenez la règle simple : Append pour empiler sans lien, Combine → Matching Fields pour enrichir par identifiant (le cas le plus fréquent dans les workflows IA), Position seulement quand l'ordre des deux branches est garanti, et Choose Branch pour ne garder qu'un seul chemin. Les workflows des packs FlowKit s'appuient sur ces mêmes principes pour combiner en toute fiabilité sortie IA et données métier — une base solide à réutiliser dans vos propres automatisations.