Node Filter n8n : filtrer vos données proprement (conditions, AND/OR, pièges)

Presque aucun workflow n8n ne traite 100 % des items qu'il reçoit : sur les 50 lignes d'un Google Sheet, seules les nouvelles vous intéressent ; sur les 200 emails récupérés, seuls ceux d'un domaine précis ; sur les commandes d'une API, seules celles au-dessus d'un montant. Le node Filter est l'outil dédié à ce tri : il laisse passer les items qui remplissent vos conditions et écarte silencieusement les autres. Simple en apparence, il cache quelques subtilités — combinaison AND/OR, types de données, casse, champs imbriqués — et un piège classique qui « arrête » le workflow quand rien ne passe. Ce guide couvre tout.

Le principe : une entrée, une sortie, des conditions

Le node Filter appartient à la famille des nodes de transformation, aux côtés de Edit Fields (Set) ou de Split Out et Aggregate. Son fonctionnement tient en une phrase : chaque item entrant est évalué contre une ou plusieurs conditions ; s'il les satisfait, il ressort, sinon il disparaît du flux.

Une condition se compose de trois éléments :

1. La valeur à tester : le plus souvent une expression pointant vers un champ de l'item, comme {{ $json.statut }} ou {{ $json.montant }} ;
2. Le type et l'opérateur de comparaison : le node propose des familles d'opérateurs par type de donnée —
   • texte : est égal à, contient, commence par, finit par, correspond à une regex, est vide… ;
   • nombre : égal, supérieur, inférieur, supérieur ou égal… ;
   • date : est après, est avant, est égale à ;
   • booléen : est vrai, est faux ;
   • tableau et objet : contient, est vide, a une longueur donnée… ;
3. La valeur de comparaison : fixe ("payée", 100) ou elle-même une expression.

Pour cibler un champ niché dans le JSON, la dot notation fonctionne partout : {{ $json.client.adresse.ville }} descend dans l'objet, {{ $json.lignes[0].montant }} va chercher le premier élément d'un tableau. Si un niveau peut manquer, préférez l'optional chaining ({{ $json.client?.adresse?.ville }}) pour éviter une erreur d'évaluation — les bases de cette syntaxe sont détaillées dans notre guide des expressions n8n.

Combiner plusieurs conditions : AND ou OR

Dès la deuxième condition, le node demande comment les combiner :

• AND : l'item doit satisfaire toutes les conditions (commande payée et montant > 100 €) ;
• OR : une seule suffit (statut « urgent » ou client VIP).

Le mode de combinaison s'applique à l'ensemble des conditions du node. Si votre logique mélange les deux — « (A et B) ou C » — deux solutions : enchaîner deux nodes Filter (deux AND successifs équivalent à un AND global), ou écrire toute la logique dans une seule expression booléenne :

{{ ($json.statut === "payée" && $json.montant > 100) || $json.vip === true }}

Une condition booléenne « est vrai » sur cette expression remplace trois conditions et leur combinaison — souvent le bon compromis avant de passer au node Code.

Deux réglages méritent l'attention dans les paramètres du node : l'option pour ignorer la casse (par défaut, « Paris » ≠ « paris ») et la souplesse de validation des types, qui détermine si "10" (chaîne) peut être comparé à 10 (nombre) — on y revient dans les pièges.

Filter ou IF : quelle différence ?

Les deux nodes évaluent exactement les mêmes conditions, la différence est topologique :

• Filter : une seule sortie. Les items non conformes sont supprimés, point ;
• IF : deux sorties, true et false. Chaque item part dans l'une des deux branches, aucun n'est perdu.

La règle de choix est simple : si les items écartés n'ont plus aucune utilité dans le workflow, prenez Filter — le canvas reste lisible, sans branche morte. Si vous devez traiter les deux populations (facture payée → archivage, impayée → relance), c'est IF. Et au-delà de deux cas, le node Switch prend le relais : notre guide du routage conditionnel avec IF et Switch détaille ces scénarios.

Expression dans le Filter ou node Code ?

Le Filter avec une expression booléenne couvre l'immense majorité des besoins. Le node Code ne devient pertinent que lorsque :

• la logique dépend d'autres items (comparer chaque item à la moyenne du lot, dédupliquer par rapport aux précédents) — une expression ne voit qu'un item à la fois via $json ;
• le filtre exige des structures intermédiaires (construire un Set des identifiants déjà vus, croiser deux listes) ;
• vous voulez journaliser pourquoi chaque item a été écarté.

Dans un node Code, le filtre s'écrit en une ligne :

return items.filter(item => item.json.montant > 100 && item.json.statut === "payée");

Mais tant que la condition se formule item par item, restez sur le node Filter : il est visible sur le canvas, modifiable sans lire de code, et ses conditions se documentent d'elles-mêmes.

Trois cas d'usage concrets

• Ne garder que les nouvelles lignes : après lecture d'un Google Sheet ou d'une API, filtrez sur {{ $json.date_creation }} « est après » la date de la dernière exécution (stockée dans une Data Table ou un fichier). Pour une déduplication robuste sur identifiant, le node dédié fait mieux : voyez notre guide de Remove Duplicates ;
• Filtrer des emails : après un trigger Gmail ou IMAP, une condition « l'expéditeur finit par @client-important.fr » ou « le sujet contient facture » élimine le bruit avant tout traitement IA — chaque item filtré en amont est un appel API économisé ;
• Exclure les items déjà traités : filtrez sur un champ de marquage ({{ $json.traite }} « est faux ») que le workflow positionne en fin de course. Ce pattern évite les doubles envois quand un workflow tourne en boucle sur la même source, en complément des boucles Loop Over Items pour le traitement par lots.

Ce travail de tri n'est pas un détail cosmétique : l'étude de référence d'Erhard Rahm et Hong Hai Do, « Data Cleaning: Problems and Current Approaches », publiée en 2000 dans l'IEEE Data Engineering Bulletin (voir sur Google Scholar), a classifié les problèmes de qualité de données (valeurs manquantes, doublons, incohérences de format) et montré que leur détection et leur élimination sont une part majeure de tout pipeline d'intégration de données — exactement le rôle que jouent Filter et ses voisins dans un workflow n8n.

Les pièges classiques

• Zéro item en sortie = suite du workflow non exécutée. Ce n'est pas un bug : n8n n'exécute pas un node qui ne reçoit rien. Si un node aval doit tourner même sans résultat (rapport « rien à signaler », compteur), activez Always Output Data dans ses paramètres — le node produira alors un item vide qu'il faut gérer explicitement (tester {{ $json.isEmpty() }} ou l'absence d'un champ attendu) ;
• Comparer des types différents : une API renvoie souvent "10" en chaîne là où vous comparez à 10 en nombre. Selon la validation de types configurée, la condition échoue ou convertit silencieusement. Le réflexe sûr : convertir explicitement dans l'expression ({{ Number($json.montant) }}) ou normaliser en amont avec un node Set ;
• La casse : « VIP » ≠ « vip » par défaut. Activez l'option d'insensibilité à la casse ou normalisez avec .toLowerCase() ;
• Champ absent vs champ vide : un champ manquant, null ou une chaîne vide ne réagissent pas pareil aux opérateurs « est vide » / « existe ». Épinglez des données réelles et testez les trois cas — le débogage de workflows passe souvent par là ;
• Filtrer trop tard : placez le Filter le plus tôt possible dans le workflow. Filtrer 500 items après les avoir enrichis par IA, c'est payer 450 appels pour rien.

En résumé

Le node Filter est le videur de vos workflows n8n : une entrée, une sortie, et seuls les items conformes passent. Choisissez-le plutôt qu'IF quand les items écartés ne servent plus, combinez les conditions en AND/OR ou dans une expression booléenne unique pour les logiques mixtes, et réservez le node Code aux filtres qui regardent plusieurs items à la fois. Surveillez les trois pièges récurrents — sortie vide qui stoppe la suite (Always Output Data), comparaisons de types différents, sensibilité à la casse — et filtrez toujours le plus tôt possible : chaque item écarté en amont est du temps, des quotas et des appels API économisés en aval.