Quand un programme ABM en PME B2B francophone dépasse les sept à dix automatisations Zapier, deux limites apparaissent : le coût mensuel grimpe vite (Zapier facture par paliers de tâches qui s’épuisent rapidement), et la complexité des workflows conditionnels devient ingérable dans l’interface linéaire de Zapier. Make (anciennement Integromat) résout les deux problèmes avec une tarification à la tâche unitaire trois à cinq fois moins chère à volume équivalent, et une interface visuelle de type schéma qui rend lisibles les workflows avec branchements, boucles et agrégations. La contrepartie est une courbe d’apprentissage plus marquée : deux à trois jours pour devenir autonome contre une demi-journée pour Zapier.
Cet article décrit comment construire ses premiers workflows ABM sans code dans Make en PME B2B francophone : la structure d’un scénario type avec ses modules et routeurs, les six cas d’usage prioritaires qui justifient le passage de Zapier à Make, les pièges à éviter (gestion des erreurs, latence des bundles, dette technique des scénarios non documentés), et l’articulation avec la méthodologie PROPULSE pour ne pas tomber dans le syndrome de l’usine à gaz invisible.
Comprendre la logique des scénarios Make et leurs trois briques essentielles
Un scénario Make se construit en assemblant visuellement des modules reliés par des connexions. Chaque module représente une action sur un outil tiers (lire une ligne Google Sheets, créer un contact HubSpot, envoyer un email Lemlist, poster un message Slack). Les modules s’enchaînent dans l’ordre d’exécution et peuvent être enrichis de trois briques essentielles qui font la différence avec Zapier.
La première brique est le routeur qui permet de diriger le flux vers différentes branches selon des conditions (par exemple : si le tier du compte est 1, déclencher la séquence A ; si le tier est 2, déclencher la séquence B). La deuxième brique est l’itérateur qui permet de boucler sur une liste d’éléments et d’exécuter une action sur chacun (par exemple : pour chaque contact d’un compte cible, vérifier son score d’engagement et notifier le commercial si le seuil est dépassé). La troisième brique est l’agrégateur qui consolide plusieurs éléments en un seul (par exemple : assembler tous les signaux d’un compte sur les sept derniers jours en un seul résumé Slack). Cette combinaison routeur + itérateur + agrégateur permet de construire des workflows ABM qui seraient impossibles dans Zapier. La logique de structurer les workflows par tier rejoint celle qu’on décrit dans notre article sur l’ABM et Notion : organiser sa stratégie account-based dans un espace collaboratif.
Six cas d’usage prioritaires qui justifient le passage de Zapier à Make
Le premier cas d’usage que nous déployons chez Propuls’Lead est le scoring d’engagement multicritère. Plutôt que d’attribuer simplement des points par interaction (logique Zapier linéaire), Make permet de combiner plusieurs sources (ouvertures email, clics, visites site, interactions LinkedIn, signaux corporate) avec des poids différents par tier de compte et par canal, et de recalculer le score en quasi-temps réel. Le deuxième cas est le routage intelligent des leads entrants : un formulaire de contact rempli est dispatché vers le bon commercial selon le secteur, la taille de l’entreprise, le tier du compte et la charge actuelle de chaque commercial.
Le troisième cas est la synchronisation bidirectionnelle entre Notion (workspace ABM) et un CRM (HubSpot, Pipedrive) : les modifications dans l’un sont répercutées dans l’autre avec gestion des conflits, ce qui est techniquement impossible en Zapier sans bricolage. Le quatrième cas est l’envoi de digests hebdomadaires personnalisés : chaque commercial reçoit le lundi matin un email Slack qui consolide les signaux de la semaine sur ses comptes prioritaires, les opportunités à relancer et les rappels en retard. Le cinquième cas est la détection automatique de comptes dormants : un scénario tourne tous les dimanches soir, identifie les comptes sans interaction depuis 45 jours, propose une séquence de réactivation et notifie le commercial responsable. Le sixième cas est l’enrichissement à la volée : quand un nouveau contact entre dans le CRM, Make appelle séquentiellement Clearbit, Dropcontact ou Hunter pour compléter les données manquantes. La logique de centraliser toutes ces orchestrations rejoint celle qu’on décrit dans notre article sur l’ABM et Zapier : les automatisations qui connectent vos outils ABM entre eux.
La tarification Make en pratique : pourquoi le coût marginal est si faible
Make facture en operations (chaque module exécuté compte pour 1 operation). Le plan Core à 9 euros par mois inclut 10 000 operations, soit l’équivalent de ce que Zapier facture 50 euros au plan Starter. Le plan Pro à 16 euros par mois inclut 10 000 operations avec accès aux fonctionnalités avancées (logs détaillés, scénarios à exécution toutes les minutes, custom variables). Le plan Teams à 29 euros par mois ouvre la collaboration multi-utilisateurs et les templates partagés.
À volume comparable (50 000 operations par mois pour un programme ABM mature avec sept à dix scénarios actifs), Make coûte 30 à 50 euros par mois contre 250 à 400 euros par mois pour Zapier. La différence se creuse dès que les scénarios deviennent complexes (les routeurs, itérateurs et agrégateurs consomment proportionnellement moins d’operations que les Zaps Zapier qui multiplient les déclenchements). Pour une équipe ABM qui automatise sérieusement, cette différence représente plusieurs milliers d’euros d’économie annuelle. La logique de l’arbitrage économique entre outils rejoint celle qu’on décrit dans notre article sur la stack ABM pour PME à moins de 200 euros par mois.
Trois pièges à éviter quand on construit ses premiers scénarios Make
Le premier piège est l’absence de gestion d’erreurs. Make propose des modules Error handlers qui permettent de définir ce qui se passe quand un module échoue (réessayer trois fois, envoyer une alerte Slack, écrire l’erreur dans un Google Sheets de logs). Sans ces handlers, un scénario peut s’interrompre silencieusement et personne ne s’en rend compte avant trois semaines. Configurer un Error handler sur chaque scénario critique est non négociable.
Le deuxième piège est la latence des bundles. Make traite les triggers par bundles (paquets de plusieurs déclenchements regroupés) avec une cadence par défaut de 15 minutes pour les plans Core et Pro. Pour les actions critiques (notification de RDV pris, alerte signal d’intent fort), passer en exécution toutes les minutes est nécessaire, ce qui consomme beaucoup plus d’operations. Anticiper cette consommation au moment du dimensionnement du plan évite la mauvaise surprise. Le troisième piège est la dette technique des scénarios non documentés. Un scénario Make complexe avec routeurs et itérateurs devient illisible six mois après sa création si on n’a pas annoté chaque module et documenté chaque branche conditionnelle. Tenir un wiki interne (dans Notion par exemple) qui décrit chaque scénario actif, sa fonction, ses dépendances et son responsable évite l’effet boîte noire. La logique de la documentation rejoint celle qu’on décrit dans notre article sur l’ABM CRM : comparatif des solutions adaptées à la stratégie par comptes.
Articuler Make avec la méthodologie PROPULSE
La méthodologie PROPULSE que nous appliquons chez Propuls’Lead pose une discipline simple sur l’usage de Make en ABM. Cinq à dix scénarios maximum la première année, un Error handler obligatoire sur chaque scénario, une documentation à jour dans Notion pour chaque scénario actif (fonction, modules, dépendances, responsable), et une revue trimestrielle de 60 minutes pour mesurer la valeur générée par chaque scénario et désactiver ceux qui n’ont plus d’usage.
L’arbitrage entre Zapier et Make se fait sur trois critères. Si le programme ABM consomme moins de 5 000 operations par mois et n’a aucun workflow conditionnel complexe, Zapier reste le bon choix. Si le programme dépasse 10 000 operations par mois, Make devient économiquement plus pertinent. Si certains workflows nécessitent des branchements conditionnels, des boucles ou des agrégations, Make devient techniquement plus adapté. La logique de progressivité de l’investissement outil rejoint celle qu’on décrit dans notre article sur l’ABM et outils de veille : surveiller ses comptes cibles sans abonnement premium : la stack ABM monte en sophistication au rythme du programme, pas l’inverse.
Ce qu’on retient pour construire ses workflows ABM avec Make en 2026
La construction de workflows ABM avec Make en PME B2B francophone se construit sur cinq disciplines : maîtriser les trois briques essentielles des scénarios Make (routeurs, itérateurs, agrégateurs) qui permettent les workflows impossibles en Zapier, déployer six cas d’usage prioritaires (scoring multicritère, routage des leads, synchronisation bidirectionnelle CRM-Notion, digests hebdomadaires personnalisés, détection des comptes dormants, enrichissement à la volée), provisionner le bon plan Make dès le départ en anticipant la consommation d’operations (Plan Pro à 16 euros pour démarrer), configurer un Error handler sur chaque scénario critique et documenter chaque scénario actif dans Notion, et tenir une revue trimestrielle de 60 minutes pour mesurer la valeur générée et nettoyer les scénarios obsolètes. Chez Propuls’Lead, nous voyons que les PME B2B qui font la bascule de Zapier vers Make au moment opportun économisent 200 à 400 euros par mois sur leur stack d’automatisation tout en débloquant des workflows ABM avancés impossibles auparavant.