IF, Switch, Filter : router ses données dans n8n sans se tromper de branche

Un workflow qui applique le même traitement à tout ce qui entre ne sert pas à grand-chose : l'intérêt de l'automatisation commence quand chaque donnée prend le chemin qui lui correspond — l'email urgent part en alerte Slack, la facture part en comptabilité, le lead sérieux part au commercial. Ce routage conditionnel repose sur trois nodes core de n8n : IF, Switch et Filter. Ils sont simples en apparence, mais concentrent quelques pièges qui expliquent une bonne partie des workflows débutants qui « marchent presque » : items routés du mauvais côté, cas non prévus qui disparaissent, champs absents qui font tout basculer en false. Ce guide fait le tour des trois nodes, des expressions utiles, et du pattern qui monte : router selon une classification produite par un LLM.

Le node IF : deux sorties, mais item par item

Le node IF évalue une ou plusieurs conditions et envoie chaque item vers la sortie true ou false. Les conditions couvrent les types courants — string (equals, contains, starts with…), number (larger, smaller…), boolean, date (before, after) — et se combinent en AND (toutes doivent être vraies) ou OR (au moins une). Un test typique :

• {{ $json.montant }} — Number — larger than — 500
• combiné en AND avec {{ $json.pays }} — String — equals — FR

Le point que presque tous les débutants ratent : l'IF ne route pas « le workflow », il route chaque item individuellement. Si le node reçoit 10 items, chacun est évalué séparément — 7 peuvent partir en true et 3 en false, et les deux branches s'exécutent dans la même exécution. Il n'y a pas de « chemin choisi » global. Pour tester une condition d'ensemble (« au moins un item en erreur »), agrégez d'abord les items en un seul, puis appliquez l'IF sur ce résultat.

Le node Switch : plusieurs sorties, deux modes

Dès que le routage dépasse deux cas, enchaîner des IF devient illisible. Le node Switch définit autant de sorties que nécessaire, selon deux modes.

Mode Rules : vous empilez des règles évaluées dans l'ordre — la première qui correspond détermine la sortie de l'item. Exemple pour un tri de tickets : règle 1 si {{ $json.priorite }} equals critique, règle 2 si equals haute, règle 3 si equals normale. Chaque règle peut recevoir un nom de sortie explicite (option Rename Output), ce qui rend le canvas immédiatement lisible.

Mode Expression : au lieu d'une liste de règles, vous écrivez une seule expression qui renvoie l'index de la sortie (0, 1, 2…). Par exemple :

{{ $json.score >= 80 ? 0 : $json.score >= 50 ? 1 : 2 }}

Ce mode est compact et pratique quand la logique est calculatoire (tranches de score, modulo pour répartir une charge), mais moins auto-documenté que le mode Rules — réservez-le aux cas où les règles seraient artificielles.

La sortie Fallback, à brancher toujours. En mode Rules, l'option Fallback Output ajoute une sortie qui récupère les items ne correspondant à aucune règle. Sans elle, un item non prévu disparaît silencieusement — et avec un LLM en amont qui renvoie un jour Urgent au lieu de urgent, ça arrive plus vite qu'on ne croit. Branchez le fallback au minimum vers un log ou une notification : c'est votre filet de sécurité et votre meilleur détecteur de cas oubliés.

Le node Filter : écarter sans créer de branche

Parfois vous ne voulez pas router, juste garder ou écarter : ne traiter que les emails de moins de 24 h, ignorer les leads sans adresse email. Le node Filter applique les mêmes conditions qu'un IF mais n'a qu'une seule sortie : les items qui passent continuent, les autres sont simplement abandonnés. C'est plus propre qu'un IF dont on laisserait la sortie false dans le vide — l'intention (« ceci est un filtre, pas un embranchement ») est explicite sur le canvas.

Les expressions qui servent tous les jours

Le cœur d'une condition, c'est son expression. Quelques patterns à connaître (approfondis dans notre guide des expressions JavaScript dans n8n) :

• {{ $json.champ }} : la valeur d'un champ de l'item courant ;
• {{ $json.sujet.toLowerCase().includes("facture") }} : test de sous-chaîne insensible à la casse, très utile en condition boolean « is true » ;
• {{ $json.email.endsWith("@gmail.com") }} : détecter les adresses personnelles dans une qualification de leads ;
• {{ $json.montant > 1000 && $json.devise === "EUR" }} : combiner directement dans une expression plutôt qu'en règles multiples.

Le piège numéro un : les champs absents ou null. Si $json.client.pays est testé alors que client n'existe pas sur certains items, l'expression échoue ou renvoie undefined — et l'item part en false sans qu'aucune erreur ne vous alerte. Deux parades : l'opérateur optionnel {{ $json.client?.pays }}, et le repli par défaut {{ $json.statut ?? "inconnu" }} qui donne une valeur explicite aux données incomplètes. Dans un Switch, vous pouvez même consacrer la première règle aux champs vides, pour traiter ces items à part au lieu de les laisser contaminer les autres branches.

Après le routage : recombiner avec Merge

Router n'est souvent que la première moitié du travail : après un traitement différencié, les branches doivent fréquemment converger — pour écrire dans la même table, envoyer le même récapitulatif. C'est le rôle du node Merge, avec ses modes Append (empiler les sorties d'un Switch) ou Combine (rapparier par identifiant), détaillés dans notre guide complet du node Merge. Le duo Switch → traitements → Merge est probablement le motif structurel le plus courant des workflows n8n non triviaux.

Le pattern qui monte : router selon une classification IA

Les conditions écrites à la main atteignent vite leurs limites sur du texte libre : impossible de lister tous les mots-clés qui font qu'un email est « urgent ». Le pattern moderne : un LLM classe l'élément (catégorie, urgence, langue, intention) en sortie structurée — un JSON fiable produit via le Structured Output Parser — puis un Switch en mode Rules route sur le champ renvoyé : {{ $json.categorie }} equals support, commercial, facturation… C'est exactement l'architecture de notre workflow de tri d'emails par IA via IMAP, et le même schéma porte la qualification de leads entrants comme le scoring de tickets de support par IA : le LLM produit le critère, le Switch exécute le routage. Deux règles d'hygiène : contraindre le LLM à un ensemble fermé de valeurs (une enum dans le schéma de sortie), et brancher le Fallback du Switch quand même — un modèle finit toujours par sortir du cadre un jour.

Garder un humain dans la boucle sur les cas ambigus

Quand le classifieur est un LLM, toutes les décisions ne se valent pas : classer une newsletter est sans enjeu, router une réclamation client vers la mauvaise équipe — ou déclencher automatiquement un remboursement — l'est beaucoup plus. La bonne pratique consiste à prévoir explicitement une branche « incertain » : demandez au modèle un niveau de confiance ou une catégorie incertain dans sa sortie structurée, et routez ces items vers une revue manuelle — par exemple via une approbation humaine avec le node Wait et Slack — plutôt que de forcer une décision automatique.

Ce n'est pas de la frilosité : c'est un résultat classique de la recherche sur les facteurs humains. L'étude de référence de Parasuraman et Riley, « Humans and Automation: Use, Misuse, Disuse, Abuse » publiée dans Human Factors en 1997, montre que les échecs de l'automatisation viennent rarement de la technique seule, mais de son usage : la sur-confiance (misuse) pousse à déléguer à la machine des décisions qui mériteraient une revue humaine, tandis que la sous-confiance (disuse) conduit à ignorer des automatismes pourtant fiables. Appliqué à nos workflows : automatisez à fond les cas clairs, et assumez une branche humaine pour les cas ambigus — c'est précisément ce dosage qui rend l'automatisation durable, parce que l'équipe peut lui faire confiance sans la subir.

Bonnes pratiques pour des routages qui restent maintenables

• Nommez vos branches. Renommez les sorties du Switch (Rename Output) et les nodes eux-mêmes : « Switch — catégorie email » se relit dans six mois, « Switch1 » non.
• Testez chaque chemin. Épinglez des données d'exemple (pin data) sur le node amont et vérifiez qu'un item de chaque catégorie — y compris un item volontairement malformé — atterrit sur la bonne sortie avant de mettre en production.
• Fallback branché, toujours. Même vers un simple log. Un item perdu en silence est le pire bug à diagnostiquer.
• Sécurisez les champs testés. ?. et ?? dans les expressions, ou une règle dédiée aux données incomplètes.
• Un IF pour deux cas, un Switch au-delà. Trois IF en cascade font le travail d'un Switch, en trois fois moins lisible.

Pour aller plus loin

IF, Switch et Filter forment, avec Merge, la grammaire de base de tout workflow n8n qui dépasse la ligne droite — et la marche d'entrée vers les automatisations IA, où le routage s'appuie sur la classification d'un modèle plutôt que sur des mots-clés codés en dur. Si vous débutez sur cette partie, notre guide pour débuter avec les nodes IA dans n8n pose les fondations ; et les workflows FlowKit, comme le tri d'emails par IA, appliquent exactement les patterns de cet article — Switch nommés, Fallback branché, branche de revue humaine incluse — prêts à importer et adapter à votre contexte.