n8n, Zapier ou Make : comment on tranche vraiment

On nous pose la question à quasiment chaque nouveau projet d'automatisation : n8n, Zapier ou Make ? Dans notre bilan sur n8n, on explique pourquoi c'est notre choix par défaut. Voici comment on arrive à cette conclusion, et les cas où ce n'est pas le bon choix.

La comparaison habituelle liste des fonctionnalités et des connecteurs. C'est le mauvais point de départ : les trois outils couvrent à peu près les mêmes intégrations courantes (CRM, Slack, Google Sheets, bases de données). Ce qui les distingue vraiment se joue ailleurs.

L'hébergement

Zapier est du SaaS multi-tenant, sans option d'auto-hébergement : la donnée transite systématiquement par leur infra. Make propose un cloud avec quelques options de résidence des données, mais reste sur le même principe. n8n est le seul des trois qui peut tourner entièrement sur une infra qu'on contrôle.

Pour une entreprise soumise à des contraintes réglementaires fortes (santé, finance, secteur public), ce point élimine souvent Zapier et Make avant même d'évaluer le reste. On détaille ce que cette option implique concrètement (parce que ce n'est pas gratuit en responsabilité) dans notre guide sur l'auto-hébergement de n8n.

Le modèle de pricing

Zapier et Make facturent au volume d'exécutions ("tasks", "opérations"). Le tarif d'entrée est bas, mais la courbe monte vite avec le volume : un workflow qui tourne toutes les cinq minutes peut représenter plusieurs milliers d'exécutions mensuelles sans effort. n8n auto-hébergé facture l'infrastructure sous-jacente, pas le nombre d'exécutions : le coût reste stable qu'on tourne 10 fois ou 10 000 fois par mois.

Le point de bascule dépend du volume, mais il arrive plus vite qu'on ne le pense : souvent en dessous de la centaine de milliers d'exécutions mensuelles, l'écart de coût devient significatif.

L'extensibilité par le code

Zapier et Make restent conçus pour rester no-code de bout en bout ; leurs points d'extension par script existent mais sont volontairement bridés. n8n intègre un nœud Function qui accepte du JavaScript complet, ce qui repousse largement la limite avant de devoir sortir de l'outil pour une logique un peu spécifique.

Ce n'est pas un avantage sans contrepartie : plus la limite recule, plus il est tentant d'empiler la logique dans le workflow plutôt que de s'arrêter à temps. C'est exactement le terrain qu'on couvre dans notre article sur la dérive de complexité : la capacité à faire plus avec n8n rend ce piège plus facile à atteindre, pas moins.

Qui va le maintenir dans six mois

C'est le critère le plus souvent oublié en phase de choix, et le plus déterminant en pratique.

Zapier reste l'option la plus accessible pour une équipe non technique : l'interface guide, les erreurs sont explicites, la logique reste volontairement simple. Make demande un peu plus de familiarité mais garde une approche très visuelle, appréciée des équipes marketing ou ops qui veulent piloter leurs automatisations sans dépendre de l'IT à chaque changement. n8n paie sur la durée, mais demande d'être à l'aise avec des notions plus proches du développement : JSON, expressions, gestion d'erreur explicite.

Notre grille, dans l'ordre où on la pose

1. La donnée doit-elle rester sur notre infra ? Si oui, n8n auto-hébergé s'impose ; sinon, les trois restent en lice.
2. Quel volume est attendu à horizon douze mois, pas à horizon trois mois ? Un projet qui démarre petit mais doit scaler mérite d'anticiper le pricing, pas de le découvrir en cours de route.
3. Qui maintient les workflows après la mise en place ? Une équipe non technique s'en sortira mieux avec Zapier qu'avec un n8n mal documenté que personne ne sait plus lire.

Le bon outil n'est pas le plus riche en connecteurs sur la page d'accueil : c'est celui dont le modèle d'hébergement et de pricing colle à ce qu'on construit dans douze mois, pas à la démo qu'on a vue hier.

On part par défaut sur n8n auto-hébergé dès qu'un des trois critères penche dans ce sens. Mais Zapier reste le bon choix pour un besoin ponctuel et un volume faible porté par une équipe non technique, et Make garde son intérêt pour des automatisations visuelles qu'une équipe métier veut piloter sans dépendre de nous.