Make.com lance enfin If-Else + Merge (en bêta)

Ce 10 mars 2026, Make.com (ex-Integromat) ouvre enfin en bêta deux modules de contrôle de flux très attendus : If-Else et Merge, accessibles pour tous les utilisateurs, gratuitement et sans coût en crédits. L’objectif est clair : remplacer les enchaînements de routeurs et de filtres qui gonflent les scénarios, compliquent le débogage et créent de la maintenance inutile. Pour l’écosystème no-code, c’est un changement de méthode : on branche proprement, puis on fait converger sans devoir empiler des rustines.

À retenir

• If-Else module : crée des chemins conditionnels où une seule branche s’exécute (logique “Vrai/Faux” et “première condition vraie”).
• Merge module : permet la convergence des branches d’un If-Else pour reprendre un workflow unique, sans dupliquer les étapes.
• Disponibilité : bêta ouverte, accessible à tous, gratuitement et sans coût en crédits.
• Point de vigilance majeur : Merge ne fonctionne qu’avec If-Else (les branches d’un routeur ne peuvent pas être “re-collées”).
• Impact concret : des blueprints plus légers, moins de dette technique, une logique plus lisible pour collaborer.
• Bonnes pratiques : comprendre Truthy/Falsy (null, undefined, 0, chaîne vide), soigner le mapping des sorties Merge, et garder le routeur pour le parallèle ou le multi-branche (>2 routes).

La promesse tenue : brancher proprement, recoller sans bricolage

Il y a les nouveautés qui font “joli”. Et celles qui changent vraiment la façon de construire. If-Else et Merge appartiennent clairement à la deuxième catégorie pour les utilisateurs intensifs de Make.com.

De Waves ’25 à la bêta ouverte du 10 mars 2026

L’idée circulait depuis longtemps dans la communauté Make.com : pouvoir faire de la convergence native sans acrobaties. Annoncés comme une évolution structurante pour l’orchestration visuelle lors de Waves ’25, ces modules arrivent désormais officiellement en open beta ce 10 mars 2026. Le message est limpide : Make veut rendre la logique “si… alors… sinon…” et le “retour à la ligne” aussi simples qu’un glisser-déposer.

Pourquoi la convergence était un point faible du no-code

Dans Make, un routeur est très efficace pour lancer des actions en parallèle. En revanche, une fois les routes séparées, elles restent séparées. C’est comme un carrefour sans rond-point : vous pouvez sortir par plusieurs voies, mais rien n’est prévu pour revenir proprement sur une seule route.

Résultat, les utilisateurs expérimentés ont construit des contournements : Set variable/Get variable, Data Store, JSON “tampon”, ou Aggregator (par exemple un JSON aggregator) selon les cas. Ces montages fonctionnent, mais ils alourdissent les scénarios et introduisent des points de fragilité à chaque étape ajoutée.

Un gain immédiat : moins de modules dupliqués, moins de maintenance

Le bénéfice le plus visible est la réduction de duplication. Avant, si deux branches devaient finir par “envoyer un e-mail” ou “mettre à jour un CRM”, on dupliquait souvent les mêmes modules. Désormais, on branche, on traite, on Merge, puis on exécute l’étape commune une seule fois. Concrètement : moins de modules, donc moins de maintenance, et un blueprint plus lisible pour vous… et pour la personne qui reprendra le scénario dans six mois.

If-Else : la logique conditionnelle qui agit sur le flux (pas sur un champ)

Le module If-Else ne remplace pas tout. Il cible précisément ce qui devenait coûteux : simuler une décision binaire avec des routeurs et des filtres empilés.

Un branchement binaire qui garantit “une seule branche”

Le If-Else module crée des chemins conditionnels et garantit qu’une seule branche s’exécute. Et le mécanisme est plus fin qu’il n’y paraît : au lieu de “tester plusieurs routes”, Make évalue les conditions dans l’ordre et exécute la première condition vraie. Si aucune condition n’est vraie, la route Else prend le relais.

Dans les faits, cela pousse à écrire les conditions du plus spécifique au plus général. Cette discipline reste simple à appliquer, mais limite nettement les comportements surprenants.

Routeur, filtre, fonction if() : même mot, usages différents

Il faut distinguer trois niveaux :

• Fonction if() (dans un champ de mapping) : elle retourne une valeur, mais ne change pas la structure du scénario. Elle est parfaite pour dire “si X alors valeur A sinon valeur B”.
• Filtre : il autorise ou bloque le passage d’un bundle sur une route.
• If-Else : il restructure le workflow lui-même, en créant des routes conditionnelles avec exécution exclusive.

Face à un routeur, la différence clé est l’intention : le routeur sert au parallèle (plusieurs routes peuvent s’exécuter), l’If-Else sert à la décision conditionnelle (une décision, une seule voie).

Truthy, falsy, Boolean : des détails qui font casser un scénario

Dans Make, vos conditions reposent souvent sur des valeurs “qui ressemblent à vrai ou faux” sans être strictement des Boolean. D’où l’importance de comprendre les Truthy et Falsy. Une valeur “falsy” typique : null, undefined, 0 ou une chaîne vide. Et une valeur “truthy” : presque tout le reste.

Le piège classique, c’est le “0”. Est-ce une donnée valide (ex : 0 € de remise) ou l’absence de donnée ? La réponse change votre branchement. Avant de déployer, testez donc vos bundles réels et regardez ce que le module considère comme vrai ou faux.

Merge : la convergence native, enfin, mais avec une règle stricte

Merge est le “nœud de ralliement” qui manquait. Mais il arrive avec une contrainte assumée, qu’il faut intégrer dès la conception de vos scénarios.

Ce que Merge remplace dans la vraie vie

Avant Merge, faire converger deux routes revenait souvent à stocker quelque chose quelque part, puis à le relire. Par exemple :

• Variable via Set variable puis Get variable (simple, mais parfois confus quand le scénario grandit).
• Data Store (robuste, mais c’est une couche de stockage à maintenir).
• Aggregator ou assemblage JSON (puissant, mais pas toujours nécessaire si votre but est juste de “continuer après la décision”).

Le Merge module vise précisément ce cas d’usage : vous avez séparé le flux, maintenant vous voulez exécuter une étape commune sans copier-coller.

La règle à connaître par cœur : Merge suit If-Else, pas un routeur

Make le répète : un routeur ne se merge pas. Le module Merge ne fonctionne qu’avec un flux If-Else. Cela implique que si vous avez besoin de paralléliser (exécuter plusieurs actions), le routeur reste votre outil… mais il ne vous offrira pas de convergence “propre” ensuite.

En pratique, posez-vous cette question avant de dessiner votre blueprint : “Est-ce que je veux exécuter plusieurs branches, ou choisir une branche ?” Si c’est “choisir”, If-Else + Merge est le bon duo. Si c’est “exécuter plusieurs”, routeur.

Exemple concret : approbation de dépenses, puis log unique

La documentation propose un scénario simple et parlant : des notes de frais soumises via un formulaire, puis deux chemins : au-dessus d’un seuil, on demande une validation ; en dessous, on approuve automatiquement. Dans l’exemple, le seuil est à 100 USD, soit environ 86 € au taux indiqué (1 USD = 0,86 €). Après ce branchement, le besoin est identique dans les deux cas : écrire une ligne dans Google Sheets avec un statut (“review required” ou “approved”).

Sans Merge, vous dupliquez “Add a row” sur deux routes. Avec Merge, vous mappez une sortie unique (par exemple “Approval”) et vous n’avez qu’un seul module Google Sheets après la convergence. Au final, le scénario est plus court, plus stable, et plus facile à relire en cas d’incident.

Des blueprints plus légers, un débogage plus rapide, et des règles de conception à adopter

Ces modules ne font pas que simplifier les schémas. Ils poussent aussi à mieux structurer la logique, et l’effet se voit rapidement sur la charge de travail humaine… et parfois sur la performance technique.

Lisibilité : le scénario tient enfin sur un écran

Les scénarios Make gonflent vite. Un routeur, trois filtres, deux duplications “juste pour finir”, et vous obtenez un blueprint qui oblige à scroller, puis à revenir en arrière pour comprendre ce qui se passe. If-Else + Merge agit comme une pince : on écarte juste ce qu’il faut, puis on referme.

Vous réduisez ainsi la taille visuelle, donc le temps de compréhension. Et en équipe, le gain est net : vous transmettez une logique claire, pas un schéma illisible.

Performance et “guard pattern” : moins de tests redondants

Quand on simule une conditionnelle avec des routes parallèles, on finit parfois par tester plusieurs fois la même condition, route après route, comme un vigile qui demande trois fois votre badge. Ce “guard pattern” mal maîtrisé augmente la complexité et peut ralentir l’exécution, ne serait-ce que par multiplication d’étapes et d’évaluations.

Avec If-Else, la logique se centralise : une décision, une route active. Cela réduit la redondance et rend le débogage plus direct : vous cherchez la condition qui a matché, puis vous suivez une seule branche.

Guide de migration : quand garder le routeur, et comment passer à If-Else + Merge

Quelques règles simples pour migrer sans casser vos automatisations :

• Gardez le routeur si vous avez plus de deux routes, ou si vous voulez lancer des actions en parallèle (ex : notifier Slack et créer un ticket et écrire dans une base).
• Passez à If-Else dès que votre besoin est une décision (oui/non, ou “première condition vraie”). Votre blueprint s’allège immédiatement.
• Utilisez Merge pour éviter la duplication des étapes communes (email, mise à jour CRM, écriture en base, journalisation), et mappez explicitement les sorties (noms de sortie, valeurs attendues).
• Vérifiez les valeurs falsy avant de déployer : null, undefined, 0, chaîne vide. Un champ vide dans un bundle peut faire basculer une route sans que vous l’ayez prévu.
• Anticipez les restrictions : une fois dans un flux If-Else, vous ne pouvez pas ajouter un routeur “après” dans ce même segment. Pensez votre orchestration visuelle en amont.

Pour aller plus loin, la documentation officielle détaille les différences de comportement, l’ajout des modules et un pas-à-pas complet : If-else and Merge, ou en vidéo ici.