Make ou Zapier : lequel choisir pour vos automatisations ?

Choisir entre Make et Zapier sur une démonstration réussie est un piège classique : un flux qui fonctionne le premier jour ne dit rien de son coût au bout de plusieurs mois, ni de la personne qui saura le corriger quand une application changera. Pour une TPE ou une PME, la vraie question est ce que le choix implique : le processus est-il couvert, combien coûte-t-il à votre volume réel, et qui le maintient ?

Quel outil tester en priorité ?

Zapier pour un flux direct, Make pour une logique ramifiée

Pour un flux court reliant quelques applications, commencez vos essais avec Zapier. Pour un scénario comportant plusieurs chemins et transformations, examinez Make en priorité. Ce point de départ permet de réduire la sélection ; les opérations disponibles, le coût et la maintenance départageront ensuite les deux outils.

Deux situations illustratives (fictives) :

• Flux direct. Un formulaire est rempli, une ligne est ajoutée à un tableur, un message part à un collègue. Peu d'étapes, aucune branche : commencez par Zapier, puis vérifiez si Make fait aussi bien pour un coût et un effort de reprise comparables.
• Traitement ramifié. Une demande arrive, on cherche si le contact existe, on le crée ou on le met à jour selon le cas, puis on traite plusieurs lignes de commande avant de notifier. Commencez par Make, puis regardez si Zapier couvre le même besoin avec ses propres limites de forfait.

Zapier propose aussi des boucles et des chemins : les scénarios ramifiés ne sont donc pas réservés à Make.

Les critères qui peuvent inverser votre choix

Le tableau suivant sépare ce qui est documenté de ce qu'il reste à tester chez vous.

Critère	Ce que la documentation indique	Conséquence pour votre décision	À tester
Conception	Make relie les modules par mapping ; un Zap associe un déclencheur à une ou plusieurs actions. Les deux proposent une création visuelle.	Ne pas opposer « visuel » et « non visuel ».	Une autre personne comprend-elle le flux ?
Compatibilité	Make propose l'application HTTP si une intégration manque ; Zapier demande aux développeurs d'indiquer les prérequis d'accès API.	Le nom de l'application ne prouve pas la couverture de l'opération.	Chaque déclencheur, action et champ utile
Coût	Zapier compte des tâches, Make des crédits, avec des exclusions différentes.	Comparer la consommation du même flux, pas les prix d'entrée.	Consommation relevée par parcours
Logique	Make documente routeurs, filtres et agrégation ; Zapier documente notamment le Looping.	Une fonction présente peut dépendre du forfait ou de la génération.	Les conditions et boucles de votre flux
Erreurs	Les mécanismes de reprise diffèrent et ont chacun des conditions.	Une reprise peut aussi coûter ou créer des doublons.	Un échec provoqué, flux réversible

Un outil déjà en place et satisfaisant ne doit pas être remplacé sur la seule base de cette orientation : un changement a un coût de reconstruction et de reprise de la connaissance du flux.

Prise en main : créer ne suffit pas, il faut pouvoir modifier

Deux façons visuelles d'organiser une automatisation

Dans Make, la documentation explique que le mapping relie les modules d'un scénario : on voit les données passer d'un module à l'autre. Chez Zapier, chaque Zap se compose d'un déclencheur et d'une ou plusieurs actions, et l'éditeur est présenté comme visuel et sans code. Pour juger la prise en main, faites construire puis modifier le même scénario par la personne qui devra le maintenir.

Un point d'attention chez Zapier : les Zaps classiques et ceux de nouvelle génération n'ont pas les mêmes fonctions ni les mêmes règles de comptage. Vérifiez lequel vous construisez.

Le bon test : faire comprendre le flux à une autre personne

Un canevas visuel ne garantit pas une maintenance facile. Pour le vérifier :

Précaution préalable : construisez et testez avec des données fictives représentatives, des droits adaptés et des notifications de test ; n'utilisez des données réelles qu'après avoir examiné les exigences d'accès et de confidentialité (voir la section sur la compatibilité), et neutralisez les effets externes irréversibles.

1. Faites construire le flux par une personne.
2. Demandez à une seconde personne, sans aide, d'expliquer chaque étape à voix haute.
3. Demandez-lui de retrouver d'où vient une donnée précise (l'e-mail du contact, par exemple).
4. Demandez-lui de modifier une règle (changer une condition de notification).

Interprétation : si elle réussit dans un outil et bloque dans l'autre, c'est un signal fort, à noter dans votre grille. Si elle bloque partout, le problème vient peut-être du processus lui-même, trop complexe ou mal documenté. Dans ce cas, un appui extérieur (prestataire ou conseil) est utile avant d'investir davantage dans l'un ou l'autre outil.

Compatibilité : vérifier l'opération, pas seulement l'application

Déclencheurs, actions et champs réellement nécessaires

Reprenons l'exemple fictif : un formulaire est reçu, on cherche le contact dans le CRM, on le crée ou on le met à jour, puis on notifie l'équipe. Pour chaque outil, dressez la liste des opérations indispensables :

• le déclencheur (nouvelle réponse au formulaire) ;
• la recherche du contact (par e-mail, par exemple) ;
• la création et la mise à jour, avec les champs personnalisés de votre CRM ;
• les données renvoyées, utilisables dans l'étape suivante ;
• la notification.

Notez ensuite pour chacune : disponible, disponible avec limite, absente. Une opération indispensable absente élimine l'outil avant toute comparaison de prix. Attention aux données d'exemple affichées à la configuration : chez Zapier, elles peuvent omettre les champs personnalisés propres à votre compte. Testez donc avec un enregistrement réel (ou réaliste) de votre CRM.

Tester avec les bons comptes et les bons droits

L'application tierce peut imposer des conditions. Les consignes officielles de Zapier aux développeurs d'intégrations demandent d'expliciter si un type de forfait, un réglage d'accès API dédié ou certaines fonctions doivent être activés. Vérifiez ces prérequis avec les comptes que vous connecterez réellement.

Côté Make, l'aide sur la connexion d'une application indique que l'application HTTP permet de se connecter à un service sans intégration dédiée. Elle précise aussi que Make ne peut pas garantir qu'une connexion modifiée dispose des autorisations (scopes) requises par tous les modules qui l'utilisent, et que les connexions dynamiques relèvent de l'offre Enterprise. HTTP n'est donc ni un contournement des permissions, ni une solution sans suivi : elle suppose une API accessible avec votre forfait et davantage de configuration.

Confidentialité et droits. Avant de connecter un compte réel :

• listez les données personnelles ou sensibles qui transiteront (coordonnées de clients, par exemple) ;
• utilisez un compte aux droits limités à ce que le flux doit faire ;
• relisez les conditions et la politique de confidentialité de chaque éditeur pour les points qui vous concernent.

Cette lecture ne remplace pas un avis juridique. Si les données concernent des clients, des salariés ou des informations de santé, ou si un contrat impose une conservation ou un lieu de traitement précis, consultez votre délégué à la protection des données ou un juriste avant de choisir.

Coût réel : comparer le même processus au même volume

Tâches Zapier et crédits Make : des unités différentes

Les règles documentées, avec leurs exceptions :

• Zapier (Zaps classiques). Les déclencheurs ne comptent pas dans la limite de tâches, et Zapier ne facture pas de tâche pour vérifier la présence de nouvelles données. Une action standard réussie consomme normalement une tâche. Certaines actions en consomment plusieurs ; les actions échouées et certains outils intégrés (Filter, Formatter, Paths) sont exclus.
• Make. Selon la documentation sur les crédits, hors IA, une opération vaut un crédit. Le module Router n'en consomme pas, certains gestionnaires d'erreurs non plus ; le code, l'IA et des fonctions avancées peuvent suivre d'autres taux.

Pour les contrôles sans résultat et les reprises dans Make, mesurez la consommation pendant un essai représentatif. Relevez séparément une période sans événement, un traitement normal et une reprise après erreur, puis intégrez ces usages à votre estimation.

Construire une estimation comparable

Exemple numérique purement illustratif, non observé : supposons un flux de quatre étapes sur le parcours « contact existant » et de cinq sur le parcours « nouveau contact », avec une exclusion de comptage différente selon l'outil. Le principe de calcul :

Parcours (hypothèse)	Étapes comptées dans l'outil A	Étapes comptées dans l'outil B	Part des demandes (hypothèse)
Contact existant	2	3	60 %
Nouveau contact	3	4	40 %

Sur ces hypothèses, la consommation moyenne par demande est de 2 × 0,6 + 3 × 0,4 = 2,4 unités pour A, et de 3 × 0,6 + 4 × 0,4 = 3,4 pour B. À 500 demandes par mois, cela fait 1 200 unités pour A et 1 700 pour B. Ces valeurs fictives illustrent le calcul ; remplacez-les par les consommations de Make et de Zapier relevées pour votre scénario :

1. relevez la consommation de chaque parcours dans l'historique de chaque outil ;
2. pondérez par la part de chaque parcours dans votre activité ;
3. multipliez par le volume mensuel prévu ;
4. cherchez, sur les pages officielles (Zapier, Make), le forfait qui couvre ce total, en vérifiant périodicité, devise, taxes et règles de dépassement.

Ce calcul par demande n'est qu'une première composante. Ajoutez-y, seulement si vous les avez effectivement observées, la consommation relevée sans événement sur une durée représentative (ramenée au mois) et celle des reprises, estimée avec une hypothèse annoncée, par exemple le nombre de reprises que vous jugez plausible par mois multiplié par la consommation mesurée d'une reprise. Veillez à ne pas compter deux fois : une reprise déjà incluse dans la consommation par demande ne s'ajoute pas une seconde fois. Une lecture prudente consiste à présenter un total bas (demandes seules) et un total haut (avec ces consommations), puis à choisir le forfait qui couvre le haut.

Lecture du résultat : comme une unité Zapier et une unité Make n'ont pas la même valeur monétaire, c'est le coût du forfait nécessaire, et non le nombre d'unités, qui se compare. Si l'écart est faible, il ne justifie pas à lui seul le choix : la maintenance pèsera davantage.

Ajouter la mise en place et la maintenance

Pour un coût total sur trois ans, additionnez : abonnement, éventuel forfait supérieur de l'application tierce ou accès API, temps de construction, temps de correction des échecs et temps de transmission à un remplaçant. Une estimation sérieuse de ce dernier poste ne peut venir que de votre essai. Si le volume est élevé ou le flux critique pour la facturation, un avis externe pour chiffrer ce coût total évite les mauvaises surprises.

Plusieurs étapes, conditions et transformations

Traduire un besoin métier en traitement vérifiable

Décrivez en phrases ce que le flux doit faire : « si le contact existe, le mettre à jour, sinon le créer » (condition) ; « pour chaque ligne de commande, ajouter une entrée » (boucle) ; « regrouper les lignes en un seul message » (agrégation). Chaque phrase devient un point de test.

Vérifier la fonction et ses conditions d'accès

Côté Make, la page tarifaire décrit l'offre gratuite comme incluant routeurs et filtres, et la documentation mentionne l'agrégation de lignes de données en tableau ou en texte. Make distingue aussi les fonctions personnalisées (Enterprise) du Make Code, facturé au temps d'exécution. Vérifiez le forfait nécessaire et le comptage des fonctions que vous utiliserez.

Côté Zapier, la page des flux de travail documente le Looping pour traiter des éléments individuellement. Cette page annonçait aussi des chemins illimités, des boucles multiples et des étapes après boucle pour les Zaps nouvelle génération, en accès anticipé réservé aux offres payantes, avec une exemption de tâches présentée comme temporaire. Rien ne confirme ici que cet accès ou cette exemption s'appliquent encore : vérifiez le statut, le forfait et le comptage pour la version testée, et ne bâtissez ni recommandation ni budget sur leur maintien.

Conséquence pratique : n'intégrez jamais une exemption temporaire dans un budget durable. Pour chaque fonction dont dépend votre flux, notez : disponible dans quel forfait, dans quelle génération d'éditeur, avec quelle règle de comptage. Une fonction présente seulement dans un forfait supérieur change le calcul de coût de la section précédente.

Erreurs et maintenance : départager avec un essai représentatif

Comprendre ce qui sera réellement rejoué

Make. L'aide sur les exécutions incomplètes indique qu'une exécution peut être reprise à partir du module en erreur, avec la configuration d'origine ; une correction peut nécessiter une résolution manuelle. Le stockage des exécutions incomplètes doit être activé, le Retry exige un scénario actif, et certaines erreurs ne créent pas d'exécution incomplète.

Zapier. L'aide sur la reprise (replay) distingue deux cas :

• la reprise depuis l'historique : le Zap doit être actif, avoir des tâches disponibles, dans un délai de 60 jours ; Filter et Paths ne sont jamais rejoués ; des modifications structurelles peuvent la bloquer ; sur l'offre gratuite, la reprise manuelle est limitée aux statuts en erreur ;
• la relance entière depuis l'éditeur : elle réexécute toutes les étapes, réévalue Filter et Paths, et ne fonctionne pas si l'application ou l'événement déclencheur a changé.

Préparer un essai sans effets irréversibles

Avant de commencer :

• un compte de test, ou un jeu d'enregistrements clairement identifiés comme tels, dans le CRM ;
• les mêmes droits d'accès dans les deux outils ;
• les notifications redirigées vers une boîte de test ;
• un historique d'exécutions activé, y compris le stockage des exécutions incomplètes côté Make.

Tester le fonctionnement normal et les cas d'échec

Dans chaque outil, utilisez les mêmes données et testez quatre cas sur un flux réversible :

1. Cas normal : une demande complète avec contact existant, puis une avec nouveau contact.
2. Doublon : la même demande envoyée deux fois.
3. Donnée manquante : un champ obligatoire vide (e-mail absent).
4. Échec après une première écriture : par exemple, interrompre le service de notification après la création du contact.

Consigner les résultats et organiser la transmission

Voici une grille remplie à titre d'exemple fictif, pour montrer comment lire les résultats (les observations ne sont pas réelles) :

Cas	Outil A (exemple)	Outil B (exemple)	Lecture
Normal	Réussi, 2 unités	Réussi, 3 unités	Pas de différence de résultat métier ; coût à convertir en euros.
Doublon	Contact dupliqué	Contact mis à jour	Observation à approfondir : la configuration de la recherche est-elle en cause avant l'outil ?
Champ manquant	Erreur visible, reprise manuelle	Erreur visible, reprise depuis l'historique	Les deux exigent une intervention ; noter le temps nécessaire.
Échec après écriture	Relance entière : nouveau doublon	Reprise au module en échec : pas de doublon	Diagnostic prudent : confirmer par un second essai avant de conclure.

Distinguer l'observation (« un doublon est apparu »), l'hypothèse de cause (« la recherche n'était peut-être pas configurée sur l'e-mail ») et la vérification contrôlée (modifier ce seul paramètre, puis refaire le test). Rapprochez les données d'entrée, la configuration et l'étape en échec ; la répétition d'une anomalie montre qu'elle est reproductible, pas quelle en est la cause. Une anomalie ne signifie pas automatiquement que l'outil est défaillant.

Si votre flux touche à la facturation, à la comptabilité ou à des données clients sensibles, et que l'essai révèle des doublons ou des pertes que vous ne savez pas expliquer, faites relire la configuration par un prestataire ou un consultant avant la mise en production.

Décider : retenir l'outil que votre équipe pourra exploiter

Appliquez les critères dans cet ordre :

1. Compatibilité : écartez l'outil auquel manque une opération indispensable, ou dont l'accès exige un forfait que vous ne voulez pas payer.
2. Fonctionnement vérifié : les cas normaux et les cas d'échec donnent un résultat métier acceptable.
3. Coût comparable : forfait nécessaire au volume réel, après vérification des prix actuels.
4. Reprise maîtrisée : vous savez ce qui est rejoué, ce qui est recompté et comment éviter les doublons.
5. Transmission : une autre personne sait expliquer et modifier le flux.

Retenez Zapier si votre flux se construit et se transmet facilement dans son éditeur ; retenez Make si ses modules et ses chemins rendent votre logique plus claire. Dans les deux cas, confirmez les actions indispensables, mesurez le coût au volume prévu et confiez le suivi à une personne identifiée. Si vous utilisez déjà un outil qui répond à ces critères, gardez-le : une migration doit résoudre un problème concret.