La facturation à l'opération de Make est un piège — voici les alternatives

Pourquoi les fondateurs cherchent des alternatives à Make

Make est un outil réellement impressionnant. Le builder visuel de workflows avec son canvas drag-and-drop, ses routers, itérateurs et chemins de gestion d'erreurs est le constructeur d'automatisation no-code le plus puissant disponible. Pour les workflows complexes avec du branchement conditionnel et de la transformation de données, rien d'autre n'arrive à la cheville en termes de clarté visuelle.

Mais le modèle de tarification est conçu pour vous faire dépenser plus que prévu.

Make facture à l'« opération ». Chaque exécution de module dans un scénario compte comme une opération. Ca semble raisonnable jusqu'à ce qu'on comprenne ce que ça signifie concrètement. Un scénario qui se déclenche sur un nouveau paiement Stripe, vérifie une condition avec un filtre, route vers deux chemins avec un router, met à jour un Google Sheet sur un chemin, envoie un message Slack sur les deux chemins et enregistre dans une base de données consomme 6-7 opérations par trigger. On lance ça 500 fois par mois et on a brûlé 3 000-3 500 opérations.

Le plan gratuit offre 1 000 opérations par mois avec 2 scénarios actifs. Le plan Core à 10,59 $/mois donne 10 000 opérations. Ca semble généreux jusqu'à ce que les scénarios grossissent. On ajoute des chemins de gestion d'erreurs (qui consomment des opérations quand ils se déclenchent), des itérateurs qui traitent des tableaux élément par élément (chaque itération est une opération), et d'un coup les 10 000 opérations mensuelles sont épuisées le 15 du mois.

Pour un fondateur bootstrapé, ça crée une dynamique frustrante. On construit des automatisations plus sophistiquées parce que le builder de Make y encourage, puis on paye plus parce que la sophistication coûte des opérations. L'outil récompense la complexité tandis que la tarification la punit.

L'autre point de douleur, c'est la fiabilité. Les scénarios Make échouent silencieusement plus souvent qu'ils ne devraient. Un module timeout, une limite d'API est atteinte, un format de données change — et le scénario s'arrête sans notification claire. On découvre une semaine plus tard que le flow d'onboarding client ne tournait plus. Les logs d'exécution aident au debug, mais il faut les consulter de manière proactive.

Comment on a évalué ces alternatives

On a reconstruit des workflows typiques de fondateur indie sur chaque plateforme :

• Onboarding client : Un paiement Stripe déclenche une entrée CRM, un email de bienvenue, une notification Slack et un log dans un spreadsheet
• Routage de leads : Une soumission de formulaire déclenche de l'enrichissement de données, du routage conditionnel basé sur le score du lead, et des notifications d'équipe sur différents canaux
• Distribution de contenu : Un nouvel article de blog déclenche des posts formatés sur trois plateformes sociales avec gestion des images
• Monitoring : Des checks horaires sur l'uptime, les prix des concurrents et les mentions sur les sites d'avis, avec alertes Slack en cas de changement

Pour chaque workflow, on a mesuré :

• Temps de setup : Combien de temps pour construire from scratch ?
• Coût en opérations/tâches : Combien ça coûte réellement à 500 triggers par mois ?
• Expérience de debugging : Quand une étape échoue, est-ce facile à trouver et corriger ?
• Effort de migration : Est-ce difficile de recréer des scénarios Make existants sur cette plateforme ?

Analyse détaillée : ce que chaque alternative fait de mieux

n8n — le mastodonte de l'automatisation auto-hébergée

n8n est l'alternative Make la plus populaire pour une bonne raison : on l'auto-héberge sur un VPS à 5 $/mois et toutes les limites d'exécution disparaissent. Pas de comptage d'opérations. Pas de montée en plan. Pas de facture surprise en fin de mois.

Le builder visuel de workflows couvre le même terrain que Make. On a un éditeur canvas avec des nodes pour les triggers, les actions et la logique. Le branchement est supporté via les nodes IF et Switch. La gestion d'erreurs utilise des workflows dédiés de type error trigger. Plus de 400 intégrations couvrent les principaux outils SaaS — Stripe, Google Workspace, Slack, HubSpot, Shopify et plus.

Les nodes Code, c'est là que n8n prend l'avantage pour les fondateurs techniques. On pose un node JavaScript ou Python n'importe où dans le workflow pour transformer des données, appeler des API ou implémenter de la logique qui nécessiterait plusieurs modules dans Make. Besoin de parser un CSV, calculer une moyenne glissante ou dédupliquer des enregistrements ? On écrit une fonction de 10 lignes au lieu d'enchaîner 5 modules.

Le support des webhooks est excellent. N'importe quel service externe capable d'envoyer un HTTP POST peut déclencher un workflow n8n. Ca étend la surface d'intégration bien au-delà de la bibliothèque de nodes intégrée.

L'auto-hébergement nécessite Docker (la méthode recommandée) et un reverse proxy comme Nginx ou Caddy pour le HTTPS. La documentation couvre les setups courants sur DigitalOcean, Hetzner et AWS. Un VPS de 1 Go de RAM gère des centaines de workflows confortablement. Pour un fondateur qui a déjà déployé un conteneur Docker, le setup prend moins d'une heure.

Le compromis, c'est la responsabilité opérationnelle. Quand n8n tourne sur votre serveur, l'uptime est votre problème. Un conteneur Docker crashé, un disque plein ou une mise à jour OS non surveillée peut stopper silencieusement toutes les automatisations. Mettre en place un monitoring avec Uptime Kuma ou UptimeRobot est non négociable.

L'offre cloud de n8n commence à 24 $/mois pour 2 500 exécutions. Ce n'est pas radicalement moins cher que les plans payants de Make. Le cloud est là pour les fondateurs qui veulent le builder n8n sans l'overhead de l'auto-hébergement, mais les économies réelles sont entièrement dans l'auto-hébergement.

Quand choisir n8n : On est à l'aise avec Docker, on veut éliminer les coûts par opération et le volume d'automatisation justifie l'auto-hébergement. Le point de break-even est généralement autour de 2 000-3 000 opérations par mois — au-delà, n8n auto-hébergé fait économiser chaque mois.

Zapier — simple mais cher

Zapier est le plus gros concurrent de Make et prend l'approche inverse du design de workflow. Là où Make offre un canvas visuel avec des routers et itérateurs, Zapier propose une chaîne linéaire : trigger, puis action, puis action, puis action.

Cette simplicité est le vrai avantage de Zapier. Construire un Zap prend moins de temps que construire un scénario Make. L'UX guide à travers chaque étape avec des suggestions pré-remplies et un mapping de données qui fonctionne généralement du premier coup. Pour les fondateurs non techniques que le canvas de Make déroute, Zapier est un soulagement.

La bibliothèque d'intégrations est inégalée. Plus de 7 000 apps ont des connecteurs Zapier natifs. Pour les outils SaaS de niche — CRM spécifiques à un secteur, apps de gestion de projet obscures, processeurs de paiement régionaux — Zapier a souvent la seule intégration pré-construite disponible. Make est à environ 1 800 intégrations. Pour les outils mainstream, le recouvrement est quasi total. Pour la longue traîne, Zapier gagne.

Zapier Tables et Interfaces méritent d'être mentionnés. Ils étendent Zapier au-delà de l'automatisation pure vers une plateforme applicative légère. On construit une base de données simple (Tables), on crée un formulaire ou dashboard (Interfaces) et on connecte le tout avec des Zaps. Pour les fondateurs qui veulent une seule plateforme pour l'automatisation et les outils internes simples, c'est convaincant.

Le problème, c'est la tarification. Zapier facture par task, et chaque action dans un Zap compte. Un Zap à 5 étapes déclenché 200 fois coûte 1 000 tasks. Le plan Starter à 29,99 $/mois donne 750 tasks. Le Professional à 73,50 $/mois donne 2 000. Le plan Core de Make à 10,59 $/mois donne 10 000 opérations — environ 3-5x plus de débit par dollar, selon la complexité du scénario.

Quand choisir Zapier : On a besoin d'une intégration niche spécifique que seul Zapier a, ou l'équipe est non technique et l'UX linéaire de Zapier est la seule qu'elle peut utiliser sans support. On accepte le premium comme le coût de la simplicité.

Activepieces — le builder auto-hébergé plus simple

Activepieces occupe le sweet spot entre la complexité de Make et la simplicité de Zapier. L'UI est propre, la courbe d'apprentissage est douce et la version auto-hébergée supprime toutes les limites de tâches.

Le builder de workflows utilise un modèle linéaire par étapes similaire à Zapier, mais avec le support du branchement que les utilisateurs de Make attendent. Construire une automatisation basique (trigger, filtre, action, action) prend quelques minutes. Les panneaux de configuration des étapes sont clairs et bien conçus — moins de bruit visuel que les dialogues de configuration de modules de Make.

L'auto-hébergement tourne dans un seul conteneur Docker. Pas de setup multi-service complexe. On pull l'image, on définit quelques variables d'environnement, on lance le conteneur. Pour un fondateur qui n'a jamais touché à Docker, la documentation guide le processus en 15 minutes. L'empreinte ressources est assez légère pour partager un VPS avec d'autres services.

La bibliothèque d'intégrations est la limitation principale. Avec 100+ connecteurs (appelés « pieces »), Activepieces couvre l'essentiel — Google, Slack, Discord, Stripe, GitHub, Notion et plus. Mais si un workflow dépend d'un outil moins courant, on peut tomber sur un trou. La communauté contribue régulièrement de nouvelles pieces, et la piece HTTP gère tout outil avec une API, mais ça demande de la configuration manuelle.

La tarification cloud est compétitive. Le plan gratuit inclut 1 000 tasks par mois. Le plan Pro à 10 $/mois donne 10 000 tasks — similaire au plan Core de Make mais avec un comptage de tâches plus simple (chaque exécution de flow compte comme 1 task, peu importe le nombre d'étapes). C'est une différence qui compte. Un flow à 6 étapes dans Make coûte 6 opérations par exécution. Le même flow en cloud Activepieces coûte 1 task.

Les fonctionnalités de workflow avancées sont moins matures que chez Make. Les routers, itérateurs et chemins de gestion d'erreurs complexes existent mais ne sont pas aussi polis. Si les workflows sont simples à modérés (ce qui couvre 80 % des cas d'usage de fondateurs solo), ça n'a pas d'importance. Si on construit des scénarios multi-branches complexes avec des boucles imbriquées, Make ou n8n gèrent ça mieux.

Quand choisir Activepieces : On veut un builder plus simple que Make, on peut auto-héberger un conteneur Docker et les workflows n'ont pas besoin de branchement ou d'itération avancés.

Pipedream — le terrain de jeu des développeurs

Pipedream ne prétend pas être un outil d'automatisation drag-and-drop. C'est une plateforme code-first où chaque étape d'un workflow peut être un bloc de code complet. Node.js, Python, Go ou Bash — on choisit son langage, on importe les dépendances et on écrit la logique dont on a besoin.

Pour un développeur qui trouve le builder visuel de Make limitant, Pipedream est libérateur. Besoin de parser un payload JSON complexe, lancer une regex sur plusieurs champs, ou appeler trois API en séquence avec gestion d'erreurs ? On écrit une fonction de 20 lignes au lieu de câbler une douzaine de modules visuels. Le code tourne sur l'infrastructure de Pipedream avec accès complet aux packages npm et bibliothèques Python.

Les data stores intégrés résolvent le problème du « où je mets mon state ? ». Du stockage clé-valeur accessible depuis n'importe quelle étape du workflow permet de tracker les timestamps de dernière exécution, dédupliquer les webhooks entrants, accumuler des données entre les exécutions et implémenter du rate limiting — le tout sans base de données externe.

Le plan gratuit utilise des crédits quotidiens qui se rechargent toutes les 24 heures. Pour les automatisations à faible volume — quelques dizaines d'exécutions par jour — le plan gratuit fonctionne indéfiniment. Le modèle de crédits est moins prévisible que le modèle d'opérations de Make, mais le coût effectif par exécution est typiquement inférieur.

La limitation est claire : si on ne sait pas écrire du JavaScript ou du Python, Pipedream n'est pas fait pour vous. Le builder visuel existe mais c'est une couche fine autour du code. Les fondateurs non techniques devraient regarder Activepieces ou rester sur Make.

Pas d'option auto-hébergée. Les workflows tournent exclusivement sur l'infrastructure cloud de Pipedream. Pour les fondateurs qui veulent la souveraineté des données ou éviter la dépendance à un vendor, c'est une contrainte significative.

Quand choisir Pipedream : On est développeur et les automatisations impliquent de la logique custom, de la transformation de données ou de l'orchestration d'API que les builders visuels gèrent maladroitement.

Windmill — le moteur d'exécution de scripts

Windmill n'essaie pas de remplacer Make. C'est une plateforme open source pour exécuter des scripts, construire des workflows à partir de scripts et générer des UI à partir de scripts. Si les « automatisations » sont en réalité des jobs backend schedulés — synchro de données, génération de rapports, batch processing, polling d'API — Windmill est construit exactement pour ça.

Support complet de TypeScript, Python, Go, Bash et SQL avec gestion des dépendances par script. Chaque script a son propre environnement isolé avec des dépendances épinglées. Fini le « ça marchait sur ma machine » quand une version de dépendance change.

La fonctionnalité d'UI auto-générée est particulièrement utile pour les fondateurs solo. On définit des paramètres d'entrée typés dans un script, et Windmill crée un formulaire web pour le lancer. Le comptable peut déclencher le rapport de CA mensuel en remplissant une plage de dates sur un formulaire web, sans accès au terminal ni compréhension du script derrière.

Windmill auto-hébergé n'a aucune limite d'exécution. Le plan gratuit cloud donne 1 000 exécutions par mois. Le plan Team à 10 $/user/mois ajoute des fonctionnalités de collaboration et des limites plus élevées.

Windmill n'a pas de bibliothèque de connecteurs SaaS drag-and-drop. Chaque intégration est un script qui appelle une API. Pour un développeur, c'est très bien — on a un contrôle total. Pour un fondateur non technique, c'est rédhibitoire. Si on veut connecter Stripe à Google Sheets en trois clics, Windmill n'est pas le bon outil.

Quand choisir Windmill : Les besoins en automatisation sont des besoins en scripting. Jobs schedulés, pipelines de données, batch processing et outils internes construits sur de la logique backend.

Power Automate — le choix du stack Microsoft

Power Automate est la plateforme d'automatisation de Microsoft. Si l'entreprise tourne sur Microsoft 365 — Excel, Teams, SharePoint, Outlook, Dynamics 365 — Power Automate s'intègre plus profondément avec ce stack que n'importe quel autre outil.

L'automatisation desktop (RPA) est la fonctionnalité qui se démarque. Power Automate peut contrôler des applications Windows legacy sans API — cliquer sur des boutons, remplir des formulaires, scraper des données de vieux logiciels desktop. Pour les entreprises coincées avec des outils legacy impossibles à remplacer, c'est véritablement utile. Make et Zapier ne savent pas faire ça.

AI Builder ajoute des modèles pré-entraînés pour le traitement de documents, la reconnaissance de formulaires et l'analyse de texte. Extraire des données de factures, classifier des tickets de support, analyser le sentiment dans les retours clients — le tout dans un flow. De l'IA enterprise-grade intégrée dans la plateforme d'automatisation.

C'est au niveau de la tarification que ça se complique. Le plan per-user à 15 $/mois semble raisonnable jusqu'à ce qu'on ait besoin de connecteurs premium (beaucoup d'intégrations non-Microsoft nécessitent une licence premium à coût supérieur). Le plan per-flow à 100 $/mois pour 5 flows a du sens en enterprise mais est absurde pour un fondateur solo. Le plan gratuit avec un compte Microsoft personnel est limité aux connecteurs basiques et à de faibles volumes d'exécution.

L'UX donne l'impression d'avoir été conçue par un comité au sein d'une grande entreprise. Le builder de flows est fonctionnel mais encombré. Trouver le bon connecteur, configurer des actions, debugger des échecs — tout demande plus de clics que l'équivalent dans Make. Si on a déjà utilisé SharePoint, on connaît l'esthétique.

Quand choisir Power Automate : On est profondément ancré dans l'écosystème Microsoft, on a besoin de RPA desktop, ou l'organisation a déjà des licences Power Platform. Pour tout le monde, l'UX et la complexité tarifaire n'en valent pas la peine.

Le calcul des opérations : combien coûte vraiment l'automatisation

Le plus gros piège de la tarification d'automatisation, c'est de ne pas comprendre comment chaque plateforme compte l'usage. Voici le même workflow — « un nouveau paiement Stripe déclenche une mise à jour CRM, un envoi d'email, un message Slack et un log dans un spreadsheet » — chiffré sur chaque plateforme :

• Make : 5 modules par exécution. À 500 triggers/mois = 2 500 opérations. Le plan gratuit (1 000 ops) ne suffit pas. Le plan Core à 10,59 $/mois couvre le besoin.
• Zapier : 4 tasks par exécution (le trigger ne compte pas comme une task). À 500 triggers/mois = 2 000 tasks. Le plan Professional à 73,50 $/mois est nécessaire.
• n8n auto-hébergé : 500 exécutions/mois. Coût = 5 $/mois pour le VPS. Aucun frais par exécution.
• Activepieces auto-hébergé : 500 exécutions de flow/mois. Coût = 5 $/mois pour le VPS. Aucun frais par tâche.
• Activepieces cloud : 500 tasks/mois (chaque exécution = 1 task). Le plan gratuit suffit.
• Pipedream : 500 exécutions/mois. Les crédits quotidiens du plan gratuit couvrent probablement le besoin.

Les options auto-hébergées offrent 80-95 % d'économies à n'importe quel volume significatif. Même parmi les options cloud, Make est nettement moins cher que Zapier et le cloud Activepieces compte les exécutions de flow, pas les étapes individuelles — une différence subtile mais importante.

Auto-hébergé vs cloud : le vrai compromis

Auto-héberger n8n, Activepieces ou Windmill sur un VPS à 5-10 $/mois élimine la tarification par opération entièrement. Mais le vrai coût, c'est votre temps et votre attention.

L'auto-hébergement fonctionne bien quand :

• On est à l'aise avec Docker et l'administration Linux de base
• Les automatisations ne sont pas business-critical (quelques heures de downtime ne feront pas perdre de clients)
• On a du monitoring en place pour catcher les erreurs
• Le volume d'exécution est assez élevé pour que les économies justifient l'overhead de maintenance

Le cloud managé fonctionne bien quand :

• Les automatisations gèrent des workflows critiques pour le CA (traitement de paiements, onboarding client)
• On ne veut pas penser à l'uptime serveur, aux backups ou aux mises à jour Docker
• Le volume d'automatisation est assez faible pour que la tarification cloud reste raisonnable
• On valorise davantage son temps que la différence de coût mensuel

Pour la plupart des projets indie pré-revenu, l'auto-hébergement est le choix évident. Un droplet DigitalOcean à 5 $/mois avec n8n gère des milliers d'exécutions par mois. Le même usage sur Make coûterait 10-50 $/mois selon la complexité des scénarios. Sur un an, les économies financent les renouvellements de domaines, le service email et un bout de runway.

Pour un SaaS profitable avec des workflows qui gèrent les paiements clients et l'onboarding, les 30-60 $/mois pour un plan managé Make ou Zapier sont une assurance bon marché contre la plateforme d'automatisation qui tombe à 2 h du matin parce que le VPS est à court d'espace disque.

Quand rester sur Make

Make justifie son prix dans des situations spécifiques :

• Les workflows ont réellement besoin du builder visuel de Make — branchement complexe avec routers, itérateurs traitant des tableaux et gestion d'erreurs multi-chemins difficile à reproduire ailleurs
• On a investi un temps significatif à construire des scénarios et le coût de migration dépasse les économies potentielles
• L'équipe dépend d'intégrations Make spécifiques non disponibles sur les alternatives
• La tarification à l'opération fonctionne réellement pour le pattern d'usage (scénarios simples avec peu de modules, volume de triggers modéré)
• On utilise les data stores de Make, les fonctions d'agrégation intégrées ou les fonctionnalités de développement d'apps custom

Le canvas visuel de Make est un vrai avantage concurrentiel. Aucun autre outil ne rend la logique de workflow complexe aussi visuellement claire. Si les automatisations sont complexes par nature et qu'on valorise la capacité de voir le flow entier d'un coup d'oeil, Make reste peut-être le bon outil malgré la tarification.

La question clé, c'est de savoir si on paye pour de la puissance qu'on utilise réellement. Si les scénarios sont principalement linéaires (trigger, action, action, action), on paye la taxe d'opérations de Make pour un workflow qu'Activepieces ou Zapier gèrent aussi bien pour moins cher.

Faire la transition : conseils de migration

1. Auditez d'abord vos opérations Make. Vérifiez le dashboard de votre organisation pour l'usage réel mensuel d'opérations. Identifiez les scénarios qui consomment le plus d'opérations — ce sont les priorités de migration.
2. Mappez les équivalents de modules. Pour chaque module Make dans vos scénarios, vérifiez que la plateforme cible a un connecteur équivalent ou que l'API de l'outil peut être appelée via requête HTTP. Faites un tableur. Faites ça avant de vous engager.
3. Commencez par le scénario le plus simple. Migrez d'abord un workflow trigger-action basique pour apprendre les particularités de la nouvelle plateforme. Ne tentez pas votre scénario multi-router le plus complexe au jour 1.
4. Faites tourner les deux plateformes en parallèle. Gardez les scénarios Make actifs en testant les mêmes workflows sur la nouvelle plateforme pendant au moins deux semaines. Comparez les résultats d'exécution côte à côte pour catcher les cas limites.
5. Attention aux différences de format de données. Make gère le mapping de données et la coercition de types de manière spécifique. Les dates, tableaux et objets imbriqués peuvent se comporter différemment sur la nouvelle plateforme. Testez avec de vraies données, pas des payloads d'exemple.
6. Configurez les alertes d'échec immédiatement. Chaque plateforme gère les erreurs d'exécution différemment. Configurez des notifications email ou Slack pour les exécutions échouées sur la nouvelle plateforme avant d'y router du vrai trafic. Les erreurs silencieuses sont le risque numéro un pendant la migration.