Make vs Zapier : j'ai exécuté la même automatisation sur les deux

J'ai construit la même automatisation en trois étapes sur les deux outils au cours de la même semaine : regarder une soumission de formulaire, l'enrichir avec un appel d'IA, puis transférer le résultat dans une feuille de calcul et un canal Slack. La version Zapier a duré vingt minutes. La version Make a duré trois heures et ressemblait à des spaghettis. La partie intéressante est ce qui s’est passé après cela, lorsque j’ai couru les deux pendant un mois.

La configuration est l'endroit où Zapier gagne et ce n'est pas proche. Le modèle de déclenchement et d'action signifie que vous choisissez une application source, choisissez une destination, mappez les champs et cela fonctionne. Make est un outil de programmation visuelle : vous construisez un canevas avec des modules, des branches et des transformations. Ce pouvoir est réel, et c'est aussi pourquoi ma première automatisation Make présentait un bug de cartographie qu'il a fallu un après-midi pour trouver.

Puis les factures sont arrivées. Zapier facture par tâche, et une tâche correspond à peu près à n'importe quelle étape effectuée par une automatisation, donc un flux en trois étapes brûle trois tâches par exécution. Make compte les opérations avec un grain beaucoup plus fin mais vend des allocations d'exploitation généreuses, et pour tout ce qui dépasse une poignée d'étapes, la différence n'est pas marginale. Mon coût mensuel d'automatisation a diminué d'environ deux tiers simplement en suivant la même logique.

La partie à laquelle je ne m'attendais pas était la fiabilité à l'envers. Les messages d'échec de Zapier sont clairs et sa bibliothèque de connexions d'applications est énorme : j'ai trouvé des connecteurs natifs pour des outils que je n'aurais jamais intégrés manuellement. Créez les webhooks nécessaires et une étape de formatage pour deux de mes applications, ce qui signifie que je conserve désormais le code qu'un utilisateur de Zapier obtiendrait gratuitement.

La réponse honnête dépend donc de celui qui le dirige. Si une personne non technique possède le flux de travail et qu'il touche les applications grand public, Zapier vaut la prime pour la bibliothèque de connecteurs et les messages d'erreur. Si quelqu'un de technique en est propriétaire, si le flux de travail comporte des branchements ou des boucles, ou si le volume rend la tarification par tâche pénible, gagnez en termes de coût et de capacité. La zone de chevauchement est petite.

Le conseil de migration que personne n'écrit : ne déplacez pas un Zapier fonctionnel pour le plaisir d'utiliser l'outil le moins cher. Déplacez-le lorsqu'il commence à coûter de l'argent réel ou lorsque le flux nécessite une logique que Zapier ne peut pas exprimer. En attendant, le temps que vous consacrez à la reconstruction vaut plus que l’argent que vous économisez.

Questions fréquemment posées :

Q : Make est-il vraiment moins cher que Zapier ?

R : Pour les automatisations en plusieurs étapes, oui, et l'écart se creuse avec la complexité. Zapier facture par tâche, ce qui signifie approximativement par étape, tandis que Make facture par opération avec des allocations beaucoup plus importantes incluses. Pour un simple flux en deux étapes, la différence est faible ; pour les workflows de branchement, ce n'est pas le cas.

Q : Lequel est le plus simple pour un utilisateur non technique ?

R : Zapier, clairement. Le générateur de déclencheurs et d'actions n'a besoin d'aucun modèle mental du système, et les messages d'erreur vous indiquent ce qui s'est cassé. Suppose que vous comprenez le mappage des données et vous permettra de déboguer à 23 heures sans vous plaindre.

Q : Puis-je migrer un Zapier vers Make ?

R : Oui, mais il s’agit d’une reconstruction plutôt que d’une exportation. Les noms de déclencheurs sont mappés, mais pas le mappage de champs. Migrez un workflow à la fois, laissez l'ancien fonctionner en parallèle pendant un mois et laissez les journaux vous indiquer si le nouveau est réellement équivalent.