Make ou Zapier : lequel pour automatiser une TPE ou une PME ?

C'est le point que presque personne n'explique, et c'est celui qui compte.

Zapier compte une tâche par action réussie. Un Zap qui reçoit un formulaire et crée une fiche dans votre CRM consomme une tâche. Simple à anticiper.

Make compte une opération par module exécuté. Le même flux, s'il passe par un filtre, une recherche, une mise en forme puis une création, consomme quatre opérations. Le compteur monte donc avec la complexité du scénario, pas seulement avec le nombre de déclenchements.

Cela donne une règle contre-intuitive. Sur des flux simples et nombreux, Zapier est souvent plus lisible en coût. Sur des flux complexes, Make coûte plus d'opérations par exécution, mais permet de faire en un seul scénario ce qui demanderait plusieurs Zaps chaînés, et le total penche généralement en sa faveur. Sur des flux qui traitent des listes, Make gagne largement : un itérateur qui traite cent lignes reste un scénario, là où l'équivalent chez Zapier devient vite coûteux ou impossible.

La seule façon honnête de trancher : prendre vos trois flux réels, les dessiner, compter. C'est vingt minutes de travail et cela évite une mauvaise surprise au trimestre suivant.

La conséquence pratique est contre-intuitive : le scénario le plus coûteux n'est pas le plus complexe, c'est celui qui traite le plus de lignes. Un enchaînement de trois étapes déclenché 1 000 fois par jour pèsera toujours plus lourd qu'un scénario de vingt étapes déclenché dix fois. C'est la première chose à vérifier avant d'estimer un budget d'automatisation, et c'est presque toujours celle qu'on regarde en dernier.

La plupart des automatisations commencent simples et se complexifient. Quand un devis est signé, crée le projet. Puis : sauf si le client existe déjà. Puis : et si le montant dépasse 10 000 euros, notifie le responsable. Puis : et crée une tâche par ligne du devis.

À la troisième condition, un Zap devient difficile à lire et à maintenir. Chez Make, ces règles sont des routeurs et des filtres posés visuellement sur le schéma. Vous voyez le flux, vous voyez les branches, vous comprenez ce qui s'est passé quand ça casse.

Cette lisibilité n'est pas un confort esthétique. C'est ce qui détermine si vos équipes pourront maintenir le flux sans nous rappeler.

Le seuil se repère facilement. Tant que le flux se lit comme une phrase, « quand ceci arrive, fais cela, puis cela », les deux conviennent et le plus simple gagne. Dès qu'il faut écrire « sauf si », « pour chacun des éléments » ou « en attendant que », la représentation visuelle cesse d'être un confort et devient une nécessité.

Ce n'est pas une question de puissance brute : les deux savent traiter des cas complexes. C'est une question de relecture. Un flux qu'on ne peut plus relire est un flux qu'on ne corrigera pas, et une automatisation qu'on ne corrige pas finit par être contournée à la main.

Une automatisation en production sans alerte n'est pas terminée. C'est vrai des deux côtés, avec un niveau de finesse différent.

Zapier signale les échecs, permet le rejeu et l'historique. Suffisant pour des flux simples. Make permet de définir des routes d'erreur par module, avec reprise, mise en attente ou notification ciblée. Vous décidez du comportement pour chaque point de rupture.

Dans les deux cas, la règle que nous appliquons est identique : tout flux en production a une alerte en cas d'échec, et un responsable identifié qui la reçoit. Sans cela, une automatisation cassée reste invisible jusqu'à ce qu'un client s'en plaigne.

Le point à cadrer avant de construire n'est pas technique, il est opérationnel : qui est prévenu quand une automatisation échoue, et sous quel délai ? Une automatisation silencieuse qui tombe un vendredi soir produit des données incomplètes tout le week-end, et personne ne le découvre avant que le client ne le signale.

Notre exigence sur ce type de projet : toute automatisation qui touche un client ou une facture doit lever une alerte visible par un humain, pas seulement une ligne dans un journal que personne n'ouvre.

Nous ne publions pas de montants ici : les grilles évoluent trop souvent pour rester justes, et un tarif faux dans un comparatif décrédibilise le reste de la page. La mécanique, elle, est stable et suffit à décider.

Les deux facturent au volume traité, avec des paliers. Le coût suit donc le nombre de déclenchements et le nombre d'étapes exécutées, pas le nombre de scénarios créés. Une automatisation rarement déclenchée ne coûte presque rien, même si elle est sophistiquée.

À cet abonnement s'ajoutent deux postes que personne ne budgète. Le temps de conception d'abord, qui est ponctuel. Le temps de surveillance ensuite, qui est récurrent : quelqu'un doit vérifier que les flux tournent, traiter les échecs et adapter les scénarios quand un outil connecté change son interface.

Ce second poste est celui qui décide de la rentabilité réelle. Une automatisation qui fait gagner deux heures par mois et qui en demande une de maintenance n'est pas un gain, c'est un déplacement de charge.

C'est le risque le plus fréquent sur ces projets, et il n'apparaît jamais dans les comparatifs de fonctionnalités.

Une automatisation est du logiciel écrit par quelqu'un. Si cette personne part, ce qui reste est un enchaînement d'étapes sans commentaire, dont l'intention doit être devinée. Sur un scénario visuel, cette relecture est pénible mais possible. Sur un enchaînement linéaire de trente étapes, elle revient souvent à reconstruire.

Notre règle sur ce type de livrable : chaque scénario porte un nom explicite, une description de ce qu'il fait et de ce qui se passe s'il échoue, et la liste des outils qu'il touche. Cela prend dix minutes à la construction et fait la différence entre une automatisation qui survit à un départ et une qui meurt avec.

La question à poser avant de choisir l'outil est donc celle-ci : dans un an, qui ouvrira ce scénario, et comprendra-t-il ce qu'il regarde ?

Une TPE qui démarre, avec quelques automatisations simples entre des outils courants et personne de technique en interne : Zapier. La mise en route est plus directe, le vocabulaire plus accessible, et à ce volume la facturation à la tâche reste avantageuse.

Une PME qui monte en charge, avec des flux qui traitent des listes, des conditions et plusieurs centaines de déclenchements par jour : Make. La facturation à l'opération devient plus favorable dès que le volume grimpe, et la représentation visuelle reste lisible là où l'enchaînement linéaire devient illisible.

Une équipe qui internalise, avec quelqu'un capable de maintenir les scénarios et l'intention de couvrir des processus métier complets : Make également, pour la lisibilité et la reprise. C'est aussi le moment où la question d'un outil auto-hébergé se pose sérieusement, pour des raisons de coût au volume et de maîtrise des données.

En cas d'hésitation à volume faible, commencez par le plus simple. Migrer trois scénarios est un après-midi ; migrer trente est un projet.