La question qui décide, et ce n’est pas le prix.
Sur une automatisation courante, envoyer un message quand un formulaire est rempli, mettre à jour une fiche client après un paiement, les trois outils font exactement la même chose. Le choix ne se joue donc pas sur ce qu’ils savent faire.
Il se joue sur une seule question : qui va vivre avec cette automatisation quand elle sera en place. Si c’est une personne qui ne code pas et qui devra comprendre pourquoi ça bloque un mardi matin, la lisibilité prime sur tout le reste. Si c’est une équipe technique, la capacité à versionner et à héberger soi-même compte davantage.
Zapier : le plus simple, et le plus cher au volume.
Zapier est le plus rapide à mettre en route et celui qui connaît le plus d’outils. Sa logique est linéaire : un déclencheur, des actions à la suite. C’est un avantage tant que le scénario reste simple, et une limite dès qu’il faut des conditions imbriquées.
Son modèle facture à la tâche exécutée. Tant que vous comptez en centaines d’opérations par mois, c’est indolore. Au-delà de quelques milliers, la facture devient le premier sujet de la réunion, et c’est souvent à ce moment qu’on nous appelle.
Make : la lecture visuelle, jusqu’à un certain point.
Make affiche le scénario comme un schéma, ce qui change tout pour la reprise : la personne voit où ça bloque sans avoir à demander. C’est l’outil que nous choisissons quand la personne qui vivra avec l’automatisation n’est pas développeuse.
Son défaut est le revers exact de sa qualité. Passé une trentaine de modules, la vue devient illisible et le nombre d’opérations facturées grimpe vite. Notre repère est simple : si le scénario ne tient plus sur un écran, il ne tient plus dans une tête non plus. À ce stade on découpe, ou on change d’outil.
n8n : le contrôle, contre un coût d’entrée.
n8n s’héberge sur votre propre serveur, ce qui règle deux problèmes d’un coup : la donnée ne sort pas, et le coût cesse de dépendre du volume d’exécutions. En contrepartie, il faut quelqu’un pour installer, mettre à jour et surveiller.
C’est le bon choix quand le volume est élevé, quand les données sont sensibles, ou quand l’automatisation devient un actif qu’on veut versionner comme du code. C’est le mauvais choix pour une équipe de trois personnes sans informaticien.
Comment nous tranchons, en pratique.
Nous posons trois questions, dans cet ordre. Qui reprend en cas de panne ? Combien d’exécutions par mois dans un an, pas aujourd’hui ? Est-ce que la donnée traitée peut sortir de chez vous ?
La première réponse élimine souvent n8n. La deuxième élimine souvent Zapier. La troisième tranche entre les deux qui restent. Nous n’avons jamais eu besoin d’une quatrième question.
Et une remarque qui vaut pour les trois : commencer avec l’outil le plus simple n’est pas une erreur, même si vous devrez changer. Le moment de basculer se reconnaît à un signe précis, quand vous commencez à contourner les limites de l’outil avec des étapes bricolées. Il coûte alors plus cher que celui qui aurait convenu.
Nous installons les trois, et nous n’avons pas de préférence commerciale : aucun de ces éditeurs ne nous rémunère. Ce qui nous coûte cher, ce sont les automatisations qu’on nous demande de reprendre parce que la personne qui les avait faites est partie. C’est ce critère-là qui pèse le plus dans nos recommandations, et c’est celui dont personne ne parle au moment de choisir.
Richad Addou