If-else et Merge dans Make : le routeur a de la concurrence

Regarde la fin d’un de tes scénarios Make à routeur. Trois routes partent du routeur : nouveau client, client existant, cas particulier. Et au bout de chacune, les mêmes modules, copiés-collés : la notification Slack, la ligne ajoutée dans la base, l’email de confirmation. La même fin, en trois exemplaires.

Cette duplication travaille contre toi en silence. Le jour où l’email de confirmation change, la correction se fait trois fois, et l’oubli d’une route fabrique un bug qui n’apparaît qu’un cas sur trois, le pire genre de bug à traquer. Le routeur impose cette structure par construction : ses routes divergent et ne se retrouvent jamais. Trois copies du même travail, personne n’a signé pour ça.

Depuis le 10 mars 2026, Make propose une alternative en disponibilité générale : les modules If-else et Merge, rangés sous Flow Control. Le premier garantit qu’une seule branche s’exécute. Le second réunit les branches en un flux unique, et la fin commune ne s’écrit plus qu’une fois. Ce guide explique ce que les deux modules changent, dans quels cas le routeur garde son métier, et comment migrer un scénario existant sans rien casser, avec un arbre de décision pour choisir le bon outil de branchement à chaque situation.

Ce qu’il te faut

• un compte Make, n’importe quel plan : la fonctionnalité est générale et sans coût en crédit
• un scénario existant avec un routeur et une fin dupliquée, le candidat idéal à la migration
• 1 heure, comparaison d’exécutions comprise

Pourquoi le routeur duplique la fin de tes scénarios

Pour comprendre ce que If-else apporte, il faut d’abord regarder ce que le routeur fait vraiment, parce que son fonctionnement surprend encore des utilisateurs de longue date. Un routeur envoie chaque élément vers toutes ses routes, dans l’ordre. Sur chaque route, un filtre décide si l’élément continue ou s’arrête. Trois routes aux filtres bien exclusifs donnent l’illusion d’un aiguillage : l’élément semble choisir sa voie, alors qu’il a frappé aux trois portes et que deux sont restées closes. Un VRP qui sonne partout, pas un aiguilleur.

Cette mécanique a deux conséquences directes. La première : si deux filtres se chevauchent, un montant de 1 000 euros pile face à un filtre « moins de 1 000 » et un filtre « 1 000 et plus » mal bornés, l’élément passe par les deux routes, et tout ce qui s’y trouve s’exécute deux fois. Deux notifications, deux lignes en base, deux emails au client. La seconde : les routes ne peuvent pas se rejoindre. Tout ce qui doit se produire après le traitement différencié, la fin commune, doit exister sur chaque route, d’où les copies. Et le copier-coller, en automatisation, c’est de la dette qui dort.

Le routeur excelle en revanche dans son vrai métier : lancer plusieurs actions indépendantes sur le même élément, envoyer la facture au client et archiver le PDF et prévenir la compta, trois routes qui vivent leur vie sans jamais avoir besoin de se retrouver. Le problème naît quand on lui fait jouer l’aiguilleur exclusif, un rôle pour lequel il n’a jamais été conçu.

If-else et Merge, la reconvergence enfin native

L’aiguilleur exclusif existe désormais, et il porte bien son nom. D’après la documentation officielle, le module If-else évalue ses conditions dans l’ordre et seule la première condition vraie s’exécute ; si aucune ne correspond, la route else prend le relais. Une seule branche par élément, garanti par construction, là où le routeur garantissait l’inverse.

Le module Merge complète le dispositif : il reconnecte les routes conditionnelles créées par un If-else en un flux unique. La fin commune s’écrit après lui, une seule fois. Le Feature Spotlight officiel résume l’état des lieux : disponibilité générale depuis le 10 mars 2026, tous les utilisateurs, tous les plans, et les deux modules utilisent des opérations sans consommer aucun crédit. Tu les trouveras dans le panneau des modules sous Flow Control, catégorie Conditionals.

Le scénario de l’ouverture, reconstruit, prend cette forme, son « cas particulier » devenant naturellement la route else :

Chaque branche ne contient plus que ce qui la distingue, un module ou deux, et les trois modules de la fin commune existent en un seul exemplaire, après le Merge. La correction de l’email de confirmation redevient une correction, au singulier. Ça passe crème.

Les règles du jeu avant de construire

Avant de poser ton premier If-else, quatre règles documentées cadrent la construction, et les connaître d’avance évite les surprises de mi-parcours.

L’ordre des conditions décide de tout. Puisque la première condition vraie l’emporte, les conditions s’écrivent du plus spécifique au plus général. L’erreur classique se voit mieux en suivant un même dossier à 10 000 euros dans les deux ordres :

Le dossier vérifie les deux conditions ; seul l’ordre décide de sa branche, et la condition « montant > 5000 » placée en seconde position ne sera jamais évaluée. Le bon réflexe inverse la pyramide : les cas étroits d’abord, les larges ensuite, l’else en filet final.

La route else fait partie du contrat. Le module exige au minimum une route conditionnelle et une route else, et la documentation précise que ces routes ne peuvent pas être détachées du module. L’else n’a rien d’une case décorative : c’est le chemin des cas que tes conditions n’ont pas prévus, et la meilleure chose à y mettre est une alerte, on y reviendra dans les pièges.

La structure se protège elle-même. Le dernier module d’une route ne peut pas être supprimé. La contrainte étonne la première fois, puis se comprend : elle empêche de laisser une branche amputée qui casserait la reconvergence.

Le Merge reste un choix. La documentation le dit explicitement : tu peux garder les branches séparées, ou poser un Merge pour les réunir. Des branches qui se terminent naturellement, chacune sur sa propre fin, ont le droit de rester séparées ; le Merge sert quand une suite commune existe, et c’est le cas le plus fréquent.

Migrer un routeur existant, pas à pas

Les règles en main, la migration d’un scénario réel peut commencer, et elle se fait en reconstruisant plutôt qu’en convertissant : aucun bouton ne transforme un routeur en If-else, et on verra dans les pièges pourquoi le raccourci du Merge posé sous le routeur se refuse. La procédure sûre tient en six gestes.

Un, clone le scénario, et travaille sur la copie pendant que l’original continue de tourner. Deux, dans la copie, pose un If-else à la place du routeur et traduis chaque filtre de route en condition, dans l’ordre du plus spécifique au plus général, ce qui est aussi l’occasion de découvrir les chevauchements que tes filtres cachaient ; si ton routeur utilisait une route de secours, son intention se transpose directement dans l’else. Trois, réduis chaque branche à ce qui la distingue vraiment : tout ce qui apparaissait sur toutes les routes est un candidat à la fin commune. Quatre, pose le Merge et déplace cette fin commune après lui, en un exemplaire. Cinq, ajoute l’alerte dans la route else. Six, exécute les deux scénarios en parallèle sur plusieurs cas réels, compare les sorties, puis désactive l’original.

Voici le point de départ, un scénario d’onboarding client réel, avec son routeur à trois routes.

La duplication saute aux yeux une fois posée à plat : les trois routes ne diffèrent que par leur premier module, création de fiche, mise à jour ou journalisation du cas, et répètent ensuite exactement la même fin, ajout de ligne, email, journalisation. Quatorze modules au total, dont neuf pour dire trois fois la même chose. Chaque correction sur l’email demande trois modifications, et la troisième s’oublie.

Après migration, il reste neuf modules et la symétrie est parlante : trois branches courtes qui portent uniquement ce qui les distingue, la troisième devenue l’else, le Merge qui referme, et la fin commune écrite une fois. Cinq modules économisés, et surtout une seule version de l’email à maintenir.

La sixième étape mérite son insistance : les filtres d’un routeur et les conditions d’un If-else n’évaluent pas leurs cas dans le même esprit, toutes les routes contre première condition vraie, et seule la comparaison d’exécutions réelles prouve que la traduction est fidèle. Trois ou quatre cas bien choisis suffisent, dont au moins un qui vise l’else.

Mapper les données après le Merge

La reconvergence posée, une question surgit dès le premier champ à remplir dans la fin commune : quelles données arrivent après le Merge ? Le panneau de mapping y propose les sorties des modules de toutes les branches, alors que, par construction, une seule branche s’est exécutée. Les champs produits par les branches non empruntées sont donc vides à l’exécution, et un mapping qui pointe naïvement vers la sortie d’une seule branche affichera un champ vide deux fois sur trois.

Deux réflexes règlent la question. Le premier, structurel : quand les branches produisent le même type de résultat, une fiche créée d’un côté, une fiche mise à jour de l’autre, fais-leur produire des champs de même forme, et le mapping de la fin commune se raccroche à la branche qui a tourné. Le second, expressif : la fonction ifempty() prend la première valeur non vide qu’on lui tend, et enchaîner les sorties des branches règle le cas en une expression. {{ifempty(3.fiche_id; 5.fiche_id)}} prend l’identifiant de la branche création s’il existe, celui de la branche mise à jour sinon. Le détail de cette fonction et de ses pièges vit dans le guide des fonctions inline, et ce montage est son cas d’usage le plus naturel.

L’arbre de décision : if() inline, filtre, If-else ou routeur

Le montage maîtrisé de bout en bout, migration et mapping compris, reste la question qui se posera à chaque nouveau scénario : Make offre désormais quatre outils de branchement, et chacun a son terrain. L’arbre tient en un schéma :

La première branche renvoie au niveau le plus léger : quand la différence entre deux cas tient dans le contenu d’un champ, le libellé d’un email, une mention qui change, une fonction inline dans le champ règle l’affaire sans aucun module. Le filtre écarte : les items qui ne remplissent pas la condition s’arrêtent, sans chemin alternatif. If-else et Merge prennent le relais dès que les cas demandent des traitements réellement différents qui doivent ensuite se retrouver. Et le routeur garde son métier d’origine, le parallèle : plusieurs actions indépendantes sur le même élément, sans reconvergence à prévoir.

La frontière la plus utile de cet arbre sépare la première branche de la troisième : un If-else dont chaque branche ne fait que remplir un champ différemment est un if() inline qui s’ignore, trois modules pour le travail d’une expression. L’inverse vaut aussi, une expression inline qui simule des chemins entiers à coups d’imbrications est un If-else qui s’ignore. L’âne de Buridan, ce paradoxe de philosophie où l’animal meurt de faim à force d’hésiter entre deux options équivalentes, connaît la sortie : tranche vite, la solution la plus simple qui fait le travail gagne.

L’impact réel sur les opérations

L’arbre de décision choisit l’outil, reste à savoir ce que la migration change sur la facture, et la réponse honnête demande de distinguer deux situations, parce que le gain ne se loge pas où on l’attend.

Avec des filtres parfaitement exclusifs, un élément n’empruntait déjà qu’une seule route du routeur, et la fin dupliquée ne s’exécutait qu’une fois par élément. Dans ce cas, la migration économise peu d’opérations : son gain est ailleurs, dans la fin commune unique à maintenir et dans le canvas qui redevient lisible.

Le vrai gain d’opérations apparaît sur les filtres qui se chevauchent, le défaut invisible des routeurs vieillissants. Chaque élément qui matchait deux routes exécutait deux fois la fin dupliquée : deux fois les opérations, et surtout deux fois les effets de bord, le client notifié en double, la ligne écrite en double. If-else supprime ce cas par construction, puisqu’une seule branche s’exécute quoi qu’il arrive.

La formule pour estimer ton propre gain : compte, dans l’historique d’exécutions, les éléments passés par plus d’une route, multiplie par le nombre de modules de ta fin dupliquée. En illustration chiffrée, purement hypothétique : un scénario à mille exécutions mensuelles dont 5 % chevauchent deux routes, avec une fin commune de quatre modules, gaspille deux cents opérations par mois, et envoie surtout cinquante doublons à de vrais clients. Le second chiffre pèse plus lourd que le premier, et aucun des deux n’apparaît sur une facture tant qu’on ne le cherche pas.

Ce qui va te bloquer

Quatre obstacles reviennent sur ce chantier, du plus frustrant au plus sournois.

Le Merge qui refuse ton routeur. Le premier réflexe de tout le monde : garder le routeur existant et poser un Merge en dessous pour réunir ses routes. Refus. Le Feature Spotlight est explicite, le module Merge fonctionne exclusivement avec If-else, et les chemins d’un routeur ne peuvent pas être fusionnés. Le refus est un choix de conception : les routes d’un routeur sont des actions parallèles, chacune vit sa vie, et les fusionner poserait la question insoluble de qui attend qui. Pour faire converger, on reconstruit avec If-else. Make te refuse ce raccourci en face, et il a raison.

La condition large qui avale tout. Symptôme : toutes les exécutions passent par la première branche, les autres semblent mortes. La cause tient à la règle de la première condition vraie : une condition trop générale en tête de liste matche avant les conditions précises qui suivent. Réordonne du plus spécifique au plus général, et teste avec un cas qui devrait atterrir dans chaque branche.

L’else silencieux qui avale les cas imprévus. L’else est obligatoire, mais rien n’oblige à y mettre quelque chose d’utile, et un else vide devient une poubelle discrète : les cas que tes conditions ne couvrent pas y disparaissent sans laisser de trace. Mets-y au minimum une notification vers un canal que tu lis, et soigne son contenu : la valeur qui n’a matché aucune condition, l’identifiant de l’élément concerné, et le nom du scénario, de quoi diagnostiquer sans rouvrir l’historique. Le jour où le CRM invente un nouveau statut, tu l’apprendras par une alerte qui dit déjà tout, plutôt qu’en cherchant pourquoi des dossiers s’évaporent. Un else qui alerte transforme chaque cas imprévu en amélioration de tes conditions ; un else vide les transforme en mystères. Et on ne collectionne pas les mystères en production.

L’imbrication qui recrée le labyrinthe. L’imbrication est supportée, un If-else dans une branche d’un autre, chaque niveau fermé par son propre Merge. Deux niveaux se lisent encore. Au troisième, le canvas retrouve la complexité qu’on cherchait à fuir, en pire, parce qu’elle est structurelle. Si ta logique demande trois niveaux de décision, une partie relève probablement de conditions combinées dans un seul If-else, ou d’une fonction inline en amont qui prépare une valeur simple à brancher. Trois niveaux, c’est la poupée russe qui contient une poupée qui contient une poupée : à l’ouverture de la quatrième, plus personne ne sait laquelle il tient.

Les limites

La première limite découle de l’exclusivité du Merge : les scénarios existants ne se convertissent pas d’un clic, chaque migration est une reconstruction, avec le temps de validation qui va avec. Sur un parc de trente scénarios à routeurs, la migration est un chantier de fond à prioriser par la douleur : commence par ceux dont la fin dupliquée change souvent. La douleur est un excellent chef de projet.

La deuxième tient au partage des rôles : If-else ne remplace le routeur que dans son mésusage d’aiguilleur. Le traitement parallèle, plusieurs actions indépendantes sur le même élément, reste le territoire du routeur, et un scénario peut légitimement contenir les deux, un If-else pour la logique de cas, un routeur pour l’éventail d’actions finales.

La limite suivante est sémantique : If-else tranche sur des conditions explicites, pas sur une appréciation. Si le choix dépend du ton d’un email, de l’intention d’un prospect ou d’un contexte difficile à réduire à des règles, empiler les branches rendra le scénario fragile. C’est le type de décision pour lequel un agent IA dans Make peut produire une classification structurée, que le If-else utilise ensuite comme entrée.

La troisième est une affaire de calendrier : le dispositif est récent, et les habitudes collectives se forment encore. Les tutoriels antérieurs à mars 2026 décrivent une bêta ou ignorent la fonctionnalité, et les patterns de la communauté, quelle granularité de conditions, quand imbriquer, se stabiliseront avec l’usage. Les règles de cet article s’appuient sur la documentation du moment ; vérifie la page officielle si tu lis ceci dans un an.

Matrice de contrôle avant de basculer

Chaque ligne se vérifie sur le scénario migré, avant de désactiver l’original.

La quatrième ligne est celle qui autorise la bascule ; les trois dernières sont celles qui confirment, après quelques jours, que la migration tient ses promesses.

Le bénéfice se voit au premier coup d’œil sur le canvas : des branches courtes qui disent leur cas, une fin unique qui dit la suite, et un else qui monte la garde. Si tu migres un scénario à routeur dans les prochaines semaines, viens raconter le avant-après sur le hub lesnocodeurs, le nombre de modules économisés et les chevauchements de filtres découverts en route : ces retours de terrain aideront ceux qui hésitent encore à ouvrir le chantier.