Zapier ou Make : la question arrive en général le jour où quelqu'un recopie, pour la dixième fois de la semaine, une ligne de formulaire dans un CRM puis dans un tableur. Les deux outils promettent la même chose, de l'automatisation no code sans développeur. Les comparatifs alignent le nombre d'applications connectées et les offres. Ce n'est pas là que je vois les vraies différences.
Pour un client, j'ai monté une prospection multicanale en no code avec Airtable, Zapier et des séquences d'e-mails. Pour mes propres machines de contenu, j'ai fait l'inverse : des scripts et un fichier de configuration. Je n'ai pas fait tourner Make en production, et je le dis : ce que j'en écris vient de sa documentation. Voici ce que je compare avant de choisir, et les cas où je ne prendrais ni l'un ni l'autre.
01Ce que fait vraiment un outil d'automatisation no code
Le principe est le même des deux côtés. Un événement dans une application (un formulaire envoyé, une ligne ajoutée, un e-mail reçu) déclenche une suite d'actions dans d'autres applications. Zapier appelle cette suite un Zap : selon ses concepts de base, un Zap se compose d'un déclencheur et d'une ou plusieurs actions. Make parle de scénario et de modules.
La première différence pratique tient au moment où l'outil apprend qu'il s'est passé quelque chose. Soit l'application source le prévient tout de suite, par un webhook ; soit l'outil va vérifier à intervalle régulier. La documentation de Make sur les webhooks l'explique bien : un webhook sert de déclencheur instantané, et quand l'application n'en fournit pas, le déclencheur interroge l'application à intervalle. Chez Zapier, la page des offres indique une vérification toutes les 15 minutes sur l'offre gratuite, 2 minutes en Professional et 1 minute en Team.
Quinze minutes, c'est très bien pour ranger des factures. C'est long pour rappeler un prospect qui vient de remplir un formulaire de démo. Je pose donc cette question en premier : combien de temps ce flux peut-il attendre ?
02Tâches, opérations, crédits : ce que chacun compte
C'est la partie que les gens découvrent sur leur première facture, alors je la lis toujours avant de construire.
Chez Zapier, l'action réussie
La documentation sur le décompte des tâches est claire : seule une action réussie compte comme tâche. Le déclencheur ne compte jamais, les filtres et les chemins (Paths) non plus, ni les étapes de mise en forme, d'attente ou de boucle. Quand votre quota est atteint, Zapier met les nouvelles exécutions en attente jusqu'au renouvellement du cycle de facturation. Sur l'offre gratuite, la page des offres annonce 100 tâches par mois et des Zaps en deux étapes, sans filtres ni chemins.
Chez Make, le module et le lot
Make compte autrement. Sa page sur les opérations définit une opération comme l'exécution d'un module, et un module compte autant d'opérations qu'il traite de lots. Le déclencheur fait exception : il compte une fois par vérification, quel que soit le nombre de lots qu'il ramène. Les opérations consomment des crédits, que la page des offres de Make présente comme l'unité de facturation, avec 1 000 crédits par mois sur l'offre gratuite.
Concrètement, si un déclencheur ramène dix nouvelles lignes et que trois modules les traitent, vous consommez une opération pour le déclencheur et trente pour le reste. Le même flux, chez Zapier, compterait trois tâches par ligne. Aucun des deux modèles n'est moins cher par principe : tout dépend du volume et de la forme du flux. Avant de choisir une offre, faites le calcul sur un mois réel, avec les volumes du mois dernier.
03Quand un pas échoue
Un flux automatique finit toujours par rencontrer une erreur : un compte déconnecté, un champ renommé, une application qui ne répond pas. Ce qui compte, c'est ce que l'outil fait à ce moment-là, et qui s'en aperçoit.
Chez Zapier, la page de dépannage indique qu'un Zap s'éteint tout seul si 95 % de ses exécutions des sept derniers jours sont en erreur. Le rejeu automatique des exécutions en erreur existe, mais pas sur l'offre gratuite, où il faut rejouer à la main.
Make va plus loin dans le réglage. On pose des gestionnaires d'erreur sur un module : ignorer le lot fautif et continuer, réessayer plus tard, substituer une valeur, valider ce qui a été fait ou tout annuler. Attention à ce dernier : la documentation du gestionnaire Rollback précise que Make ne peut pas annuler ce qu'ont fait les modules qui ne gèrent pas les transactions. Un e-mail parti reste parti. Les réglages du scénario permettent aussi de garder une exécution échouée pour ne pas perdre ses données.
La vidéo officielle de Zapier sur les Zaps à plusieurs étapes montre un flux de prospects assez complet : un formulaire, une mise en forme des données, deux chemins selon le budget saisi, une boucle sur les services choisis, puis des e-mails personnalisés. L'animateur teste chaque étape avant de publier. C'est la bonne habitude, mais un test ne couvre que les cas prévus, et l'erreur de production arrive quand même.
Dans mes machines de contenu, une vérification qui n'a pas eu lieu compte comme un échec, jamais comme un succès. Pour un flux no code, j'applique la même logique : un propriétaire nommé, et une erreur qui envoie une alerte à quelqu'un qui la lira. Un flux qui casse en silence pendant trois semaines fait plus de dégâts qu'un flux qui n'a jamais existé, parce que tout le monde croit que le travail est fait.
04Zapier ou Make selon la forme de votre flux
Je ne choisis pas l'outil d'abord. Je dessine le flux sur une page, puis je regarde sa forme.
- Un flux linéaire, court, à faible volume (un formulaire vers un CRM, puis une notification) : Zapier, pour sa prise en main rapide.
- Un flux avec des embranchements, des boucles sur des listes ou un traitement d'erreur fin : Make me semble plus adapté sur le papier, parce qu'il montre le scénario en entier et laisse régler chaque module.
- Un flux qui manipule beaucoup de lignes à chaque passage : je ferais le calcul des deux décomptes avant de trancher, parce que c'est là que les écarts se creusent.
- Un flux qui porte des règles qui doivent bloquer : ni l'un ni l'autre.
Ce quatrième cas, c'est le mien. Mes machines de contenu ont un brief qui refuse la rédaction tant qu'il manque une source, et un contrôle final rouge, orange ou vert avant toute publication. J'ai choisi des scripts et une configuration versionnée : une règle écrite dans la configuration bloque vraiment, je peux la tester, et un changement laisse une trace. Dans un outil visuel, une condition se modifie d'un clic sans que personne le voie. Je l'explique dans l'article sur ma machine de contenu avec relecture humaine.
Le no code est très bien pour déplacer des données ; il l'est moins pour porter une décision. Pour la prospection de ce client, en revanche, c'est Zapier que j'ai utilisé, avec Airtable comme base.
Une limite honnête : un outil no code n'est pas gratuit en temps. Quelqu'un doit savoir ce que fait chaque Zap ou scénario, les mettre à jour quand une application change, et comprendre pourquoi un flux s'est arrêté. Sans cette personne, les automatisations s'accumulent et plus personne ne sait à quoi sert chacune.
05Les données personnelles qui transitent
Un flux de prospection fait passer des noms, des e-mails et parfois des numéros de téléphone par un outil de plus. Pour le RGPD, cet outil est un sous-traitant. La CNIL rappelle, sur sa page Travailler avec un sous-traitant, que ce traitement doit être encadré par un contrat avec le responsable de traitement, c'est-à-dire vous.
Si l'outil, ou l'un de ses propres sous-traitants, est établi aux États-Unis, une autre question se pose. Selon les questions-réponses de la CNIL sur l'adéquation des États-Unis, depuis la décision du 10 juillet 2023, un transfert vers un organisme américain certifié au Data Privacy Framework ne demande pas d'outil supplémentaire, à condition de vérifier qu'il figure bien sur la liste officielle. Sinon, il faut des garanties comme les clauses contractuelles types.
En pratique, je ferais trois choses avant de brancher un flux : lire l'accord de traitement des données de l'outil, noter le flux dans le registre des traitements, et ne faire passer que les champs nécessaires. Un Zap qui recopie toute la fiche contact alors qu'il n'a besoin que de l'e-mail transporte des données pour rien.
06Par où commencer lundi
Prenez la tâche que quelqu'un recopie à la main le plus souvent. Écrivez-la en une phrase : quand il se passe ceci dans tel outil, faire cela dans tel autre. Puis répondez à quatre questions avant d'ouvrir Zapier ou Make :
- combien de temps ce flux peut-il attendre entre l'événement et l'action ?
- combien de passages par mois, et combien de lignes à chaque passage ?
- que doit-il se passer si une étape échoue, et qui sera prévenu ?
- quelles données personnelles traversent l'outil, et lesquelles sont vraiment utiles ?
Avec ces réponses, le choix se fait souvent tout seul. Si votre flux alimente ensuite une base de contenu, l'article sur Airtable pour le contenu montre comment je la structure ; si le goulot est la mise en ligne, voyez pourquoi j'automatise la publication avant de produire plus. Et pour relier un formulaire de site à un CRM, j'ai détaillé une intégration HubSpot sur un site.
Si vous voulez qu'on regarde ensemble un flux précis, mes missions d'automatisation et de direction de projet commencent par là, et le portfolio montre ce que j'ai déjà construit. On peut en parler.