Routeurs, filtres et itérateurs : la logique avancée de Make

Jusqu’ici, vos scénarios étaient des lignes droites : un déclencheur, des actions, terminé. Le monde réel, lui, est plein de « ça dépend » : un devis de 8 000 € ne se traite pas comme un devis de 200 €, un e-mail incomplet mérite une relance, pas une facture. Bienvenue dans le module 5 — celui où vos automatisations apprennent à décider. Au programme de ce premier article : les routeurs, les filtres avancés, les itérateurs et agrégateurs : les quatre outils qui séparent les scénarios jouets des systèmes professionnels.

Transparence : certains liens de cet article sont des liens partenaires. Si vous créez un compte via l’un d’eux, Flowmatic-Pro perçoit une commission, sans que cela change quoi que ce soit à votre prix. Nous ne recommandons que des outils que nous utilisons nous-mêmes.

Le routeur : votre aiguillage à scénarios

Un routeur démultiplie le chemin : après lui, plusieurs branches, chacune protégée par sa règle. La logique se lit comme une phrase : « si le devis dépasse 5 000 €, préviens le commercial ; s’il est standard, envoie le devis ; s’il est incomplet, relance ».

Les filtres avancés : au-delà du simple « contient »

Vous connaissez le filtre basique depuis le module 1. Le niveau supérieur :

• Conditions multiples : AND / OR combinés — « montant > 100 ET (source = formulaire OU source = email) ».
• Opérateurs temporels : « date de création < il y a 7 jours » pour les relances.
• Existence : « le champ téléphone existe » — le tri propre/incomplet par excellence.
• Motifs de texte : commence par, se termine par, correspond au modèle (regex pour les aventuriers).

Itérateur et agrégateur : le couple éclater/regrouper

Deux outils miroirs, indispensables dès que vous touchez à des listes :

• L’itérateur transforme un paquet (les 5 pièces jointes d’un e-mail, les 20 lignes d’un export) en éléments individuels, traités un par un par les modules suivants.
• L’agrégateur fait l’inverse : il rassemble plusieurs éléments en un seul (un récapitulatif, un tableau, une archive zip).

Le pattern professionnel par excellence : itérer pour traiter, agréger pour notifier. Vos 20 lignes sont traitées individuellement, mais Slack ne sonne qu’une fois avec le bilan. (Souvenez-vous : un agrégateur = une opération au lieu de vingt — votre quota apprécie.)

Cas pratique fil rouge : le traiteur de commandes

Cinq concepts, un scénario qui gère ce qu’un humain gérerait — y compris les cas tordus. C’est exactement la marche entre les modules 2-3 et le niveau professionnel.

Les quatre motifs de routeur qui reviennent tout le temps

Un routeur peut faire beaucoup de choses ; en pratique, il en fait quatre. Les reconnaître vous évite de réinventer une structure à chaque besoin.

Le parallèle : faire plusieurs choses à la fois

Toutes les branches s’exécutent, sans condition. Une demande entrante est simultanément enregistrée, notifiée et confirmée au client. C’est le motif le plus simple, et le plus utile : il remplace trois scénarios séparés par un seul, avec un seul déclencheur à payer et un seul endroit à ouvrir en cas de problème.

L’exclusif : un seul chemin selon un critère

Chaque branche porte une condition, et elles s’excluent mutuellement : particulier ou professionnel, montant faible ou élevé, français ou étranger. C’est l’aiguillage classique. Le point d’attention est de couvrir tous les cas : une valeur qui ne correspond à aucune condition disparaît silencieusement, sans erreur.

Le repli : la branche qui rattrape le reste

La solution au problème précédent. Une dernière branche sans condition, placée en dernier, récupère tout ce qui n’a satisfait aucune des précédentes. Elle peut simplement écrire la donnée dans une liste « à examiner ».

C’est la branche que personne ne construit et qui révèle le plus de choses : au bout de trois semaines, vous découvrirez des cas de figure auxquels vous n’aviez pas pensé. Sans elle, ces cas seraient simplement passés à la trappe.

L’enrichissement conditionnel

Plus subtil : les branches divergent pour aller chercher des informations différentes, puis le traitement se poursuit de la même façon. Un client professionnel demande une vérification d’entreprise ; un particulier n’en a pas besoin. Dans les deux cas, on finit par créer la même fiche.

Attention à un point technique : dans un moteur qui exécute les branches l’une après l’autre, il n’y a pas de « point de rendez-vous » où les chemins se rejoignent. Chaque branche doit aller jusqu’au bout du traitement. Cela signifie parfois dupliquer deux ou trois modules : c’est normal, et cela reste plus lisible que les contorsions destinées à l’éviter.

L’ordre des routes : le piège du premier qui gagne

Détail d’apparence anodine, cause d’erreurs difficiles à diagnostiquer.

Les branches d’un routeur sont évaluées de haut en bas. Si vos conditions se chevauchent, la première qui correspond emporte le morceau — et les suivantes ne verront jamais la donnée.

L’exemple qui parle

Vous voulez traiter différemment les commandes selon leur montant. Vous écrivez trois branches : « supérieur à 100 », « supérieur à 500 », « supérieur à 1000 ». Une commande de 2 000 € part dans la première branche, parce qu’elle est effectivement supérieure à 100. Les deux autres branches ne serviront jamais.

La correction est simple une fois qu’on l’a vue : écrivez les conditions de la plus restrictive à la plus large, ou bornez chaque intervalle des deux côtés. La seconde méthode est plus verbeuse et beaucoup plus sûre : elle rend le chevauchement impossible.

La règle générale

Écrivez toujours vos branches de la plus spécifique à la plus générale, et terminez par le repli. Cette discipline vous évitera la moitié des « pourquoi ma troisième branche ne s’exécute jamais ? ».

Et quand vous ajoutez une branche à un routeur existant, vérifiez sa position. Une nouvelle branche placée en haut peut intercepter des données qui allaient ailleurs depuis six mois — sans que rien ne signale le changement.

Les opérateurs de filtre, un par un

Le filtre paraît simple jusqu’au jour où il ne laisse rien passer alors que la donnée est manifestement là. Voici ce que fait réellement chaque opérateur, et le piège associé.

Les trois causes réelles d’un filtre qui bloque tout

Un espace invisible. Une valeur recopiée depuis un tableur ou un formulaire porte souvent un espace en début ou en fin. Appliquez systématiquement une fonction de nettoyage dans le champ testé : cela règle un cas sur trois.

Une comparaison de texte au lieu d’une comparaison de nombres. Si votre montant arrive sous forme de texte, « 90 » sera considéré comme supérieur à « 800 », parce que la comparaison se fait caractère par caractère. Convertissez explicitement en nombre avant de comparer.

Une casse différente. « Devis » n’égale pas « devis ». Mettez les deux côtés en minuscules dans le filtre, systématiquement : cela ne coûte rien et supprime toute une catégorie de problèmes.

Combiner plusieurs conditions

Un filtre accepte plusieurs conditions, liées par un « et » ou par un « ou ». Attention à la lecture : dans la plupart des interfaces, les conditions d’une même ligne se combinent avec « et », et les lignes entre elles avec « ou ». Une logique mal groupée produit un filtre qui semble correct et ne l’est pas.

Notre conseil : au-delà de trois conditions, n’essayez pas d’être malin. Utilisez deux filtres successifs, ou un routeur. Un filtre à six conditions est un filtre que personne ne relira, vous compris.

L’itérateur : indispensable, et souvent mal employé

L’itérateur découpe une liste en éléments traités un par un. C’est sa seule fonction, et elle est essentielle. Encore faut-il savoir quand il est nécessaire — et quand il ne l’est pas.

Quand il est indispensable

Quand vous recevez un élément contenant une liste, et que vous devez traiter chaque entrée de cette liste séparément. Les trois cas classiques : une commande contenant plusieurs articles, un message contenant plusieurs pièces jointes, une réponse d’interface renvoyant un tableau de résultats.

Quand il est inutile

Quand le module précédent produit déjà plusieurs éléments. C’est l’erreur la plus fréquente : on ajoute un itérateur par réflexe, alors que la suite du traitement se serait exécutée une fois par élément de toute façon. L’itérateur ne fait alors rien d’utile — et il coûte une unité par élément.

Le test : regardez le compteur du module précédent. S’il affiche déjà un nombre supérieur à un, vous n’avez pas besoin d’itérateur.

Quand il est une mauvaise idée

Quand vous itérez pour réagréger juste après. Ce motif — éclater puis regrouper sans rien faire entre les deux — apparaît souvent dans les scénarios de débutants. Si aucun traitement n’a lieu entre les deux, retirez les deux modules : vous divisez le coût par le nombre d’éléments.

Le piège du coût

Chaque élément produit par un itérateur consomme, et surtout multiplie tout ce qui suit. Un itérateur sur trente lignes suivi de quatre modules, c’est cent vingt unités pour un seul élément d’entrée. Placez toujours vos filtres après l’itérateur mais avant les modules coûteux : vous écartez alors les éléments inutiles au plus tôt.

L’agrégateur : trois familles, trois usages

L’opération inverse de l’itérateur, et probablement le module le plus rentable de tout l’outil : il coûte une seule unité, quel que soit le nombre d’éléments regroupés.

L’agrégateur de texte

Il colle bout à bout les valeurs reçues, avec un séparateur de votre choix. C’est lui qui transforme quarante lignes en un message lisible. Le séparateur classique est le retour à la ligne ; vous pouvez aussi construire du texte structuré, avec un tiret devant chaque entrée.

Usage type : le récapitulatif quotidien. Quarante notifications deviennent un e-mail. Le gain n’est pas seulement financier — il est surtout dans votre boîte de réception.

L’agrégateur numérique

Somme, moyenne, minimum, maximum, comptage. Il produit un chiffre à partir d’une liste. C’est la brique des rapports : le chiffre d’affaires de la semaine, le nombre de demandes traitées, le panier moyen.

L’agrégateur de tableau

Le plus puissant et le moins compris. Il regroupe les éléments en une structure, sans les aplatir en texte. C’est ce qu’il faut utiliser quand la destination attend une liste structurée : créer une commande avec ses lignes, envoyer un lot de données à une interface, écrire plusieurs lignes en une seule opération.

Le bénéfice est double : vous économisez des unités — une écriture groupée au lieu de trente — et vous évitez les refus pour excès d’appels, puisque vous sollicitez le service une fois au lieu de trente.

Le groupement

Tous les agrégateurs acceptent une clé de groupement : au lieu d’un seul résultat, vous obtenez un résultat par valeur distincte. Un récapitulatif par client, un total par catégorie, une liste par jour. C’est l’option qui transforme un agrégateur en outil d’analyse, et elle tient dans un champ que la plupart des gens laissent vide.

Le motif éclater — transformer — regrouper

C’est la structure la plus utile de toute la logique avancée, et elle mérite d’être connue comme un modèle.

Le principe : un itérateur découpe la liste, quelques modules traitent chaque élément, un agrégateur recompose le résultat.

Trois applications concrètes

La commande détaillée. On éclate les lignes d’une commande, on va chercher le libellé et le prix de chaque article, on regroupe le tout en un récapitulatif propre à insérer dans un e-mail de confirmation.

Le rapport par client. On éclate les enregistrements de la semaine, on filtre, on agrège en groupant par client. On obtient une ligne par client, avec son total.

L’envoi groupé. On éclate une liste de destinataires, on personnalise chaque message, on regroupe par lots de vingt pour respecter les limites du service d’envoi.

Les deux erreurs à éviter

Oublier de regrouper. Le scénario envoie alors un message par élément. C’est le cas classique du « j’ai reçu trente e-mails identiques ».

Placer le filtre après l’agrégateur. Il ne sert alors plus à rien pour la consommation : tous les éléments ont déjà traversé les modules coûteux. Le filtre se place entre l’itérateur et le traitement, toujours.

Ce que coûte chaque structure

Récapitulons, parce que ces choix de conception se paient tous les mois.

Deux lignes valent d’être retenues. Les deux structures gratuites — filtre et routeur — sont celles qui organisent la logique : vous pouvez en abuser sans conséquence. Les deux structures qui multiplient — itérateur et recherche — sont celles qui font les factures : c’est là qu’il faut limiter, et nulle part ailleurs.

La conception économique d’un scénario tient donc en une phrase : organiser avec ce qui est gratuit, limiter ce qui multiplie.

Quand la logique ne fait pas ce que vous croyez

Un scénario qui s’exécute sans erreur mais produit un résultat inattendu est plus difficile à diagnostiquer qu’un scénario en panne. Voici la méthode, dans l’ordre.

1. Lisez les compteurs, pas le canevas. Ouvrez une exécution réelle et regardez le nombre affiché sur chaque module. Vous cherchez l’endroit où le nombre change de façon inattendue : il tombe à zéro, ou il explose. C’est là qu’est le problème, et nulle part ailleurs.

2. Ouvrez le module juste avant. Regardez les données qui en sortent réellement, champ par champ. Dans la majorité des cas, le problème est une donnée absente ou dans un format inattendu — pas une erreur de logique.

3. Testez votre condition sur cette donnée. Recopiez la valeur réelle et vérifiez à la main que votre filtre devrait la laisser passer. C’est souvent là qu’apparaît l’espace invisible ou la différence de casse.

4. Simplifiez. Si rien n’apparaît, retirez des modules jusqu’à ce que le comportement redevienne compréhensible, puis rajoutez-les un par un. C’est fastidieux et cela fonctionne toujours.

5. Vérifiez l’ordre des branches. Si le problème concerne un routeur, c’est la première chose à regarder. Une condition trop large placée en haut intercepte tout.

Un dernier conseil qui vaut pour toute cette logique avancée : renommez vos modules. « Filtrer les commandes de plus de 500 € » se relit ; « Filter 3 » ne veut rien dire. Sur un scénario à trois branches et deux itérateurs, cette simple discipline divise par deux le temps de diagnostic.

Les boucles : ce qui est possible, et comment s’en passer

Question qui revient dès qu’on dépasse les scénarios linéaires : comment répéter une opération jusqu’à ce qu’une condition soit remplie ? La réponse demande de distinguer trois choses qu’on appelle toutes « boucle ».

La boucle sur une liste connue

C’est le cas le plus fréquent, et il ne demande aucune boucle : c’est exactement ce que fait l’itérateur. Vous connaissez les éléments à traiter, vous les découpez, la suite s’exécute une fois par élément. Neuf fois sur dix, quand quelqu’un cherche une boucle, c’est de cela qu’il a besoin.

La boucle de pagination

Vous interrogez une interface qui renvoie ses résultats par pages de cinquante, et vous voulez tout récupérer. Il faut alors rappeler la même adresse avec un numéro de page qui augmente, jusqu’à ce qu’elle ne renvoie plus rien.

C’est une vraie boucle, et les plateformes visuelles la gèrent différemment : par un module dédié, par un renvoi du flux vers un module antérieur, ou en découpant en deux scénarios dont le premier rappelle le second. Le point commun de toutes les méthodes : prévoyez toujours une condition d’arrêt de sécurité, un nombre maximum de passages. Une boucle de pagination sans garde-fou qui rencontre une interface au comportement inattendu peut consommer un quota mensuel en quelques minutes.

La boucle d’attente

« Réessayer jusqu’à ce que le fichier soit prêt », « attendre que le paiement soit confirmé ». C’est le cas où il ne faut surtout pas construire de boucle. Un scénario qui attend consomme, occupe un emplacement d’exécution, et finit par buter sur la durée maximale autorisée.

La bonne réponse est de retourner le problème : au lieu d’attendre, faites-vous prévenir. Si le service sait envoyer une notification quand l’opération est terminée, un second scénario prend le relais. Si ce n’est pas possible, un scénario planifié qui vérifie toutes les quinze minutes et ne fait rien quand ce n’est pas prêt coûte infiniment moins qu’une attente active.

La règle générale

Sur une plateforme d’automatisation, une boucle est presque toujours le signe qu’on essaie de programmer là où il faudrait orchestrer. Demandez-vous : puis-je transformer cette répétition en une liste à parcourir, ou en un événement qui me réveillera ? La réponse est positive dans la grande majorité des cas, et le scénario obtenu est plus simple, moins cher et plus robuste.

Un cas complet : la commande à traiter

Pour rassembler tout ce qui précède, déroulons un scénario réaliste de bout en bout, en nommant chaque structure employée.

Le besoin : à chaque commande reçue, enregistrer chaque article dans le suivi de stock, envoyer au client un récapitulatif détaillé, alerter l’équipe si le montant dépasse un seuil, et signaler tout article en rupture.

La construction, étape par étape

1. Le déclencheur. Un appel entrant depuis la boutique : instantané, et sans réveil à vide.

2. Le premier routeur, en parallèle. Deux branches qui s’exécutent toutes les deux : l’une traite le détail des articles, l’autre gère l’alerte de montant. Elles n’ont rien à voir l’une avec l’autre ; les séparer rend le canevas lisible.

3. Branche « montant » — un filtre. Une seule condition : le total dépasse le seuil. Coût nul, et rien ne s’exécute en dessous du seuil.

4. Branche « articles » — un itérateur. Il découpe la liste des lignes de commande. À partir d’ici, tout s’exécute une fois par article.

5. Une recherche, limitée à un résultat. Pour chaque article, on va chercher son état de stock. Le champ « nombre maximum de résultats » est réglé à 1 : sans cela, ce module serait le plus coûteux du scénario.

6. Un second routeur, exclusif. Stock suffisant d’un côté, rupture de l’autre, et une branche de repli pour l’article introuvable dans le catalogue — le cas auquel on ne pense jamais et qui se produit toujours.

7. Un agrégateur de texte. Les lignes traitées sont recomposées en un récapitulatif lisible. Une seule unité, quel que soit le nombre d’articles.

8. L’envoi au client. Un seul message, contenant le récapitulatif complet.

Ce que ce scénario illustre

Onze modules, dont trois gratuits — les deux routeurs et le filtre. Le coût réel tient dans l’itérateur et la recherche : ce sont les deux seuls endroits qui multiplient, et ce sont les deux seuls qu’il fallait optimiser.

C’est la leçon de tout cet article. Les structures de logique — routeurs et filtres — sont gratuites : organisez-les librement, elles rendent le scénario clair. Les structures qui parcourent — itérateurs et recherches — sont celles qui coûtent : c’est là, et uniquement là, qu’il faut limiter, filtrer et borner.

FAQ — vos questions fréquentes

Combien de branches un routeur peut-il avoir ?

Techniquement beaucoup, raisonnablement : 3 à 5. Au-delà, votre scénario devient un plat de spaghettis — découpez en plusieurs scénarios qui s’appellent (le pattern « usine à gaz » des 5 erreurs de débutant vous guette).

Quelle différence entre un filtre sur une route et un module IF de n8n ?

Même concept, ergonomie différente : Make place la condition SUR le lien (la clé à molette), n8n en fait un node visible avec deux sorties true/false. Si vous venez du module 3, vous êtes déjà à l’aise.

L’itérateur consomme-t-il vraiment une opération par élément ?

Oui — itérer 50 pièces jointes = 50 exécutions des modules suivants. C’est le comportement attendu (chaque élément EST traité), mais budgétez-le : la formule modules × éléments × fréquence avant d’activer.

Existe-t-il un « routeur » conditionnel à plus de deux sorties dans n8n ?

Oui : le node « Switch », l’équivalent direct du routeur Make avec ses règles ordonnées. Tout ce que vous venez d’apprendre se transpose en cinq minutes.

Peut-on imbriquer un routeur dans une branche de routeur ?

Oui, et cela reste lisible sur deux niveaux. Au-delà, le canevas devient difficile à suivre et le diagnostic pénible. Quand vous atteignez un troisième niveau d’imbrication, c’est en général le signe qu’il faut découper : un scénario qui appelle un autre scénario, ou une structure repensée autour d’un champ de catégorie calculé en amont plutôt que d’une cascade de conditions.

Comment traiter un cas particulier qui n’arrive qu’une fois par mois ?

Ne construisez pas une branche complète pour lui. La bonne réponse est la branche de repli : elle écrit la donnée dans une liste « à examiner » et vous envoie une notification. Vous traitez le cas à la main en deux minutes, une fois par mois. Automatiser un cas rare coûte plus cher à construire et à maintenir que le temps qu’il fait perdre.

Un filtre placé sur une branche de routeur remplace-t-il un filtre classique ?

C’est exactement la même chose du point de vue du fonctionnement et du coût : la condition d’une branche est un filtre. La différence est de lisibilité. Utilisez un filtre simple quand il n’y a qu’un chemin possible, et un routeur dès qu’il y a plusieurs traitements alternatifs. Un routeur à une seule branche conditionnelle est un filtre déguisé, et il rend le canevas moins clair.

Comment limiter le nombre d’éléments traités par un itérateur ?

L’itérateur lui-même n’offre pas de limite : il découpe ce qu’on lui donne. La limitation se fait en amont — dans le champ « nombre maximum de résultats » du module qui produit la liste — ou juste après, avec un filtre sur la position de l’élément. Pendant une phase de mise au point, la première méthode est de loin la meilleure : elle évite de récupérer les données inutiles plutôt que de les écarter après coup.

En résumé

Routeur pour décider, filtres pour trier tôt, itérateur pour traiter les listes, agrégateur pour notifier sobrement : vos scénarios pensent désormais. Prochaine étape — parce qu’un scénario qui pense peut aussi se tromper : gérer les erreurs et déboguer comme un pro.