n8n vs Zapier vs Make : La comparaison honnête 2026 pour les entreprises

Autant le dire tout de suite, sans détour : si vous gérez une entreprise de 50 à 250 collaborateurs, que vous traitez des données métier sensibles et que vous n'êtes pas prêt à confier toute votre automatisation de processus à un éditeur SaaS américain, alors cette comparaison se conclut sur n8n. Pas parce que n8n serait sans défaut, il en a, mais parce que les alternatives présentent sur certains points des lacunes tout simplement inacceptables.

Avec ce seul argument, l'article serait évidemment trop court. Nous allons donc passer les trois plateformes au crible : architecture, structure de coûts, conformité RGPD, écosystème d'intégrations, scalabilité réelle, et ce que les éditeurs n'écrivent jamais sur leur page tarifaire, à savoir le vendor lock-in. Le tout illustré par des exemples de configuration concrets.

L'état des lieux 2026 : pourquoi cette comparaison doit être refaite

Les outils d'automatisation ne sont plus optionnels. Une ETI typique synchronise aujourd'hui ses données CRM avec ses systèmes ERP, déclenche des workflows de facturation à partir d'e-mails entrants, achemine les tickets de support et traite des événements webhook de prestataires de paiement, tout cela sans qu'un développeur ait à lever le petit doigt. Selon Gartner, d'ici fin 2026, plus de 69 % des tâches routinières dans les entreprises de taille intermédiaire seront couvertes par l'automatisation Low-Code (Gartner, Magic Quadrant for Integration Platform as a Service, 2025).

Trois éditeurs dominent ce segment. Zapier d'abord (fondé en 2011, plus de 7.000 intégrations natives à ce jour), Make ensuite (anciennement Integromat, rebaptisé en 2022, siège à Prague), et enfin n8n (open source, AGPL-3.0, fondé en 2019 à Berlin).

L'écart technologique entre 2022 et 2026 est considérable. Workflows assistés par IA, nodes LLM natifs, intégration MCP, logique de branchement complexe : rien de tout cela ne relève plus de la niche. Et c'est précisément ce qui redistribue les cartes dans cette comparaison.

Vue d'ensemble rapide : les trois plateformes en un coup d'œil

n8n : automatisation self-hosted avec une ADN enterprise

Architecture

n8n est une application Node.js qui peut tourner comme conteneur Docker, pod Kubernetes ou instance cloud managée. Les workflows sont stockés sous forme de documents JSON, entièrement versionnables. C'est là que se joue la différence fondamentale avec tous les concurrents : votre logique d'automatisation réside dans votre infrastructure, dans vos dépôts Git, sous votre contrôle.

Le moteur d'exécution fonctionne en mode event-driven. Chaque node traite un tableau d'éléments (INodeExecutionData[]), ce qui autorise le traitement en masse sans avoir à bricoler des boucles. Détail qui compte : le node Python et le node JavaScript s'exécutent dans le même contexte de processus, sans la surcharge d'une sandbox.

Exemple concret : automatiser la réception de factures

Prenons un workflow typique d'ETI. Les e-mails entrants avec pièce jointe PDF sont déclenchés via IMAP, le PDF part vers un endpoint OCR, les données de facturation en sont extraites puis écrites directement dans votre ERP (SAP, DATEV, etc.). Voici à quoi ressemble le node Code Python dans n8n :

# n8n Code Node (Python) - Normaliser les données de facturation
import re
from datetime import datetime

items = _input.all()
results = []

for item in items:
    raw = item.json.get("ocr_text", "")

    # Extraction du montant (format DE : 1.234,56 €)
    amount_match = re.search(r"(\d{1,3}(?:\.\d{3})*(?:,\d{2}))\s*€", raw)
    amount_raw = amount_match.group(1) if amount_match else None

    # Conversion en float
    amount_float = None
    if amount_raw:
        amount_float = float(amount_raw.replace(".", "").replace(",", "."))

    # Date de facture
    date_match = re.search(r"(\d{2})\.(\d{2})\.(\d{4})", raw)
    invoice_date = None
    if date_match:
        d, m, y = date_match.groups()
        invoice_date = datetime(int(y), int(m), int(d)).isoformat()

    results.append({
        "json": {
            "amount": amount_float,
            "invoice_date": invoice_date,
            "raw_vendor": re.search(r"Lieferant:\s*(.+)", raw, re.I).group(1).strip()
                          if re.search(r"Lieferant:", raw, re.I) else None,
            "needs_review": amount_float is None or invoice_date is None
        }
    })

return results

Ce code s'exécute sur votre infrastructure. Il ne quitte jamais votre réseau. Aucune entreprise américaine ne traite vos données fournisseurs.

Déploiement Docker : configuration de production

Un docker-compose.yml propre pour n8n en environnement professionnel, compatible rootless, avec PostgreSQL comme backend et Redis pour le mode Queue :

# docker-compose.yml - n8n Enterprise Self-Hosted
version: "3.8"

services:
  n8n:
    image: n8nio/n8n:1.47.0
    restart: unless-stopped
    user: "1000:1000"
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n_user
      - DB_POSTGRESDB_PASSWORD_FILE=/run/secrets/postgres_password
      - N8N_ENCRYPTION_KEY_FILE=/run/secrets/n8n_encryption_key
      - N8N_PROTOCOL=https
      - N8N_HOST=automation.votre-entreprise.fr
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_LOG_LEVEL=info
      - N8N_METRICS=true
    volumes:
      - n8n_data:/home/node/.n8n
    secrets:
      - postgres_password
      - n8n_encryption_key
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    user: "1000:1000"
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n_user
      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    secrets:
      - postgres_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n_user -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    user: "1000:1000"
    command: redis-server --requirepass "${REDIS_PASSWORD}"
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  n8n_data:
  postgres_data:
  redis_data:

secrets:
  postgres_password:
    file: ./secrets/postgres_password.txt
  n8n_encryption_key:
    file: ./secrets/n8n_encryption_key.txt

Remarque sur les secrets : ne jamais utiliser de mots de passe en clair dans docker-compose.yml. Docker Secrets ou un backend Vault (HashiCorp Vault, Bitwarden Secrets Manager) sont obligatoires.

Structure de coûts n8n

L'édition Community est gratuite. L'édition Enterprise (à partir de 500 $/mois, contrat annuel) débloque SAML/SSO, les journaux d'audit, les permissions utilisateurs avancées et le support SLA. Pour la plupart des ETI qui disposent d'une IT interne dédiée, l'édition Community combinée à un hébergement propre suffit largement.

Voici un calcul de coût réel pour 50.000 exécutions de workflow par mois :

• n8n self-hosted (Hetzner CX31, 8 Go RAM) : ~12 €/mois de serveur, plus 0 € de licence, soit 12 €/mois
• n8n Cloud (Starter) : 20 $/mois pour 2.500 exécutions, ce qui ne passe pas à l'échelle
• Zapier Professional : env. 73 $/mois pour 50.000 tasks
• Make Teams : env. 29 $/mois pour 40.000 opérations (paquets arrondis, dépassements coûteux)

Le point mort entre n8n self-hosted et Zapier se situe à quelques centaines d'exécutions par mois, coût d'exploitation inclus.

Zapier : leader du marché avec des faiblesses structurelles pour l'entreprise

Ce que Zapier fait bien

Dans l'univers No-Code, Zapier est ce que Salesforce est au CRM : omniprésent, profondément ancré dans le quotidien des équipes métier, avec un écosystème qu'il est difficile de surpasser. Plus de 7.000 intégrations d'applications natives, des templates Zap préconfigurés pour quasiment tous les cas d'usage, et un éditeur que même des collaborateurs non techniques prennent en main sans formation.

Pour les petites équipes avec une capacité IT limitée, c'est un argument solide.

Là où Zapier échoue pour les ETI

Le premier problème touche à la souveraineté des données. Toutes les données de workflow transitent par les serveurs américains de Zapier, et Zapier Inc. est soumis au US Cloud Act. Concrètement, si des autorités américaines demandent l'accès aux données hébergées chez Zapier, l'éditeur ne peut pas refuser, peu importe que vos données relèvent du RGPD. Pour une entreprise qui traite des données personnelles, des données financières ou des secrets commerciaux dans ses workflows, c'est un problème structurel qu'aucun DPA (Data Processing Agreement) ne vient résoudre.

Vient ensuite l'escalade tarifaire. Zapier facture à la « Task », et chaque action dans un Zap consomme une Task. Les workflows multi-étapes avec leurs nodes Filter, leurs Formatter Steps et leurs Lookup Tables font grimper la facture à toute vitesse. Un workflow qui traite 1.000 enregistrements par jour à travers 8 étapes consomme 8.000 Tasks par jour, soit 240.000 Tasks par mois. Comptez environ 400 $/mois dans le plan Zapier Professional. Et sans le moindre avertissement préalable.

Troisième écueil : l'absence de flexibilité de code dans les nodes critiques. Le Zapier Code Step ne supporte que JavaScript (ni Python, ni Shell), et l'accès aux bibliothèques externes reste fortement limité. Les transformations de données un peu complexes, monnaie courante en comptabilité ou dans les environnements ERP, imposent soit des contournements, soit des appels API externes.

Enfin, le lock-in par le format propriétaire. Les workflows Zapier n'existent que sous forme de configuration propriétaire dans la base de données de l'éditeur. Aucun export vers un format ouvert, pas de versioning Git, pas de processus de review. Si Zapier bloque votre compte, double ses prix ou arrête son service, vous vous retrouvez les mains vides.

Ce n'est pas un risque hypothétique. Zapier a augmenté ses prix plusieurs fois entre 2021 et 2024 et a progressivement supprimé le grandfathering pour les plans existants.

Make : le compromis technique aux racines européennes

Positionnement et architecture

Make (anciennement Integromat) a été fondé en 2012 à Prague et fait aujourd'hui partie du groupe Celonis. Son interface visuelle est plus puissante que celle de Zapier : les workflows y sont représentés sous forme de graphes de flux de données, avec un routage explicite, des modules Iterator, des Aggregators et une gestion des erreurs qui dépasse nettement ce que propose Zapier.

Make propose une région de données EU, ce qui résout le problème RGPD le plus évident. Du moins tant que Celonis opère comme entreprise européenne et qu'aucune acquisition par un groupe américain ne vient changer la donne. Le risque, lui, reste bien réel.

Points forts face à Zapier

Côté facturation, Make compte à l'« Opération », mais les modules Filter, eux, ne consomment rien, à la différence de Zapier. Pour des workflows truffés de logique conditionnelle, l'écart de coût devient vite significatif. La logique de workflow est aussi plus riche : Router, Error Handler, Iterator et Aggregator sont des concepts natifs, ce qui rend Make adapté à des processus plus exigeants. Enfin, l'intégration API tient la route, avec un module HTTP qui donne le contrôle total sur les headers, les flux OAuth2 et la manipulation des réponses webhook.

Faiblesses en environnement enterprise

Make n'est pas un produit self-hosted. Il n'existe pas de version on-premises officiellement supportée, et la région EU proposée réduit le risque sans pour autant l'éliminer.

Le module de code JavaScript est, comme chez Zapier, fortement limité. Quant à l'exécution de Python, elle n'est tout simplement pas prévue.

Make ne propose pas non plus de backend Git natif pour versionner les workflows. Les scénarios s'exportent bien sous forme de Blueprints (JSON), mais on est loin d'un véritable workflow de versioning.

Calcul de coût réel pour le même cas d'usage (50.000 exécutions/mois) :

• Make Teams : 29 $/mois (40.000 opérations), avec un dépassement d'env. 9 $ pour 10.000 opérations supplémentaires, soit 38 $/mois

Pas mal du tout sur le papier. Sauf que les données, elles, vivent sur un serveur tiers.

Conformité RGPD : la comparaison que les éditeurs ne veulent pas faire

C'est le domaine où beaucoup de responsables IT ont un angle mort. « Nous avons signé un DPA » n'est pas une réponse suffisante. Un accord de traitement des données déplace la responsabilité, soit, mais il n'empêche en rien l'accès aux données par les autorités américaines.

Pour les entreprises dans des secteurs réglementés (services financiers, santé, secteur public), n8n self-hosted est la seule option qui passe un audit RGPD sans lacune structurelle.

Écosystème d'intégrations : chiffres et réalité

Zapier mène la danse avec plus de 7.000 intégrations natives. Sur le papier, c'est impressionnant. En pratique, une ETI typique en utilise au grand maximum 20 à 30. Et les systèmes qui font vraiment la différence, SAP, DATEV, solutions ERP sectorielles, logiciels métier spécifiques, ne sont intégrés nativement et de bout en bout chez aucun des trois éditeurs.

Du coup, le nombre brut d'intégrations pèse beaucoup moins lourd qu'on ne le croit. Ce qui compte réellement, c'est la flexibilité des requêtes HTTP. Puis-je connecter n'importe quelle API REST ? Transformer des webservices SOAP ? Implémenter des flux d'authentification sur mesure (OAuth2, API Key, Certificate-based) ?

Sur ce terrain, n8n offre une flexibilité HTTP totale, des Custom Nodes via packages npm et un dépôt communautaire de plus de 400 nodes (mai 2026). Zapier permet bien la requête HTTP via « Webhooks by Zapier », mais avec des options d'authentification limitées, et l'intégration d'une application personnalisée passe par un compte Zapier Platform. Make, de son côté, propose un module HTTP robuste, une bonne prise en charge d'OAuth2 et des Custom Apps via son portail développeur.

Prenons le cas de l'intégration SAP. Aucune des trois plateformes ne dispose d'une intégration SAP native prête pour la production. La solution passe dans tous les cas par un module HTTP visant les API REST de SAP, ou par une couche middleware. Et c'est précisément là que n8n garde l'avantage, grâce à ses nodes Python et à la possibilité d'exécuter directement du code prêt pour la production.

Workflows IA 2026 : qui est vraiment prêt ?

C'est le sujet qui a dominé le marché en 2025 et 2026. Les trois éditeurs ont intégré des fonctionnalités IA, mais la qualité varie énormément de l'un à l'autre.

Chez n8n, on trouve des nodes LLM natifs pour OpenAI, Anthropic Claude, Google Gemini et Ollama (en local), ainsi qu'une intégration LangChain. Le node MCP-Client (depuis n8n 1.35) gère le Model Context Protocol, le node Agent fait du Tool-Calling, et le RAG basé sur les workflows s'appuie sur des nodes Pinecone, Qdrant ou Weaviate. Techniquement, c'est ce qui se fait de plus avancé aujourd'hui.

Un exemple parle de lui-même. Imaginez un workflow qui lit les e-mails de support entrants, les classe via un modèle Ollama local (aucun échange de données avec des API externes), détermine la priorité et enregistre le tout automatiquement dans votre système de ticketing. Entièrement on-premises, sans qu'une seule ligne de données client ne quitte votre réseau.

{
  "nodes": [
    {
      "name": "Email Trigger",
      "type": "n8n-nodes-base.emailReadImap",
      "parameters": {
        "mailbox": "support@votre-entreprise.fr",
        "format": "resolved"
      }
    },
    {
      "name": "Classification via Ollama",
      "type": "@n8n/n8n-nodes-langchain.lmChatOllama",
      "parameters": {
        "model": "llama3.2:3b",
        "baseUrl": "http://ollama.intern:11434",
        "prompt": "Classifie cette demande de support en : [critique, haute, moyenne, basse]. Réponds uniquement avec le niveau de priorité.\n\nDemande : {{ $json.text }}"
      }
    }
  ]
}

Chez Zapier, « Zapier AI » permet de créer des Zaps en langage naturel et de passer des appels LLM simples via OpenAI. C'est suffisant pour des cas d'usage basiques, mais inadapté dès qu'on touche aux workflows agentiques avec Tool-Use ou à l'exploitation d'un LLM local.

Make joue dans la même catégorie : « Make AI » reste comparable à Zapier, avec intégration OpenAI et manipulation de texte. Ni support LLM local, ni MCP au programme.

Performance et scalabilité : benchmarks

Ces chiffres sont issus de tests internes réalisés dans le cadre de projets clients chez NextGen IT (environnement de test : Hetzner CX41, 16 Go RAM, 4 vCPU, Debian 12, n8n 1.47.0 en mode Queue avec 4 workers).

Les éditeurs SaaS brident volontairement. Leur modèle commercial repose sur des paquets de volume, c'est leur droit. Mais n8n, sur votre propre matériel, ignore tout simplement cette limitation artificielle.

Vendor lock-in : les coûts cachés

C'est le sujet dont personne ne parle. Jusqu'au jour où il est trop tard.

Avec Zapier, toute votre logique d'automatisation existe sous forme de configuration propriétaire sur les serveurs de l'éditeur. Imaginez : après trois ans, vous avez construit 200 Zaps, et Zapier double ses prix. Vos options se résument à payer ou à tout reconstruire. Aucun export, aucune portabilité.

Et le lock-in ne s'arrête pas là. Il y a d'abord la dépendance cognitive : votre équipe apprend les concepts maison de Zapier (Zap, Trigger, Action) plutôt que des concepts d'automatisation génériques, et ce savoir ne se transfère nulle part ailleurs. Il y a ensuite le lock-in d'intégration, car certaines intégrations Zapier reposent sur des accès API spécifiques à la plateforme, impossibles à reproduire en dehors. Il y a enfin le lock-in de processus : quand les workflows ne sont ni documentés ni versionnés, l'entreprise finit par perdre la connaissance institutionnelle de ses propres processus. Que survienne un changement d'éditeur ou le départ d'un collaborateur, et ces processus s'évaporent.

Les workflows n8n, eux, sont des documents JSON. Ils vivent dans votre dépôt Git, chaque modification est traçable. Et si n8n venait à disparaître demain (l'entreprise est rentable et en forte croissance, mais admettons), vous exportez votre JSON et réimplémentez la logique ailleurs : les processus sont documentés, les données restent chez vous.

Chemins de migration : ce que coûte un changement

De Zapier à n8n

Pour des Zaps simples du type Trigger-Action, la migration reste gérable. Pour des workflows multi-étapes complexes mobilisant des applications intégrées Zapier (Formatter, Filter, Delay), comptez plutôt 2 à 4 heures par workflow, documentation et réimplémentation comprises.

Un conseil important : exportez sans attendre toutes vos configurations Zap, sous forme de captures d'écran ou de documentation. Zapier ne propose aucun export lisible par machine. Faites-le dès aujourd'hui, indépendamment de toute décision de migration.

De Make à n8n

Make propose des exports Blueprint en JSON. Le format est propriétaire, mais assez structuré pour permettre une conversion semi-automatique. Des outils communautaires pour la migration Make-vers-n8n existent déjà (GitHub : make-to-n8n-converter, parmi diverses contributions communautaires). Prévoyez tout de même des ajustements manuels sur chaque workflow.

Check-list de migration

• Documenter tous les workflows actifs (déclencheur, étapes, logique métier, comportement en cas d'erreur)
• Inventorier les credentials et API keys associés
• Définir les priorités : les workflows critiques en premier
• Planifier une période de fonctionnement en parallèle de 2 à 4 semaines (Dual-Run)
• Mettre en place un monitoring sur les deux systèmes pour détecter les divergences
• Décommissionnement progressif de l'ancien système après vérification des fonctionnalités

Matrice de décision : quel outil pour quel contexte ?

Légende : ✅ = approprié, ⚠️ = approprié sous conditions, ❌ = inapproprié

La recommandation honnête

Pour les ETI françaises et DACH qui disposent d'une IT interne (même réduite à une seule personne), avec des processus de traitement de données soumis au RGPD et un horizon d'au moins 24 mois, mon choix est sans ambiguïté : n8n self-hosted.

Les surcoûts initiaux (installation du serveur, configuration de départ, montée en compétence des équipes) s'amortissent en général en 6 à 12 mois face à Zapier. Passé ce cap, la structure de coûts évolue de façon linéaire avec votre infrastructure, et non de manière exponentielle avec votre volume d'automatisation. C'est toute la différence.

Zapier reste pertinent si votre entreprise n'a pas d'IT interne, n'automatise que des données non sensibles et place la rapidité de démarrage au-dessus de tout. Mais calculez dès maintenant, noir sur blanc, un chemin de migration pour le jour où l'automatisation deviendra critique pour votre activité.

Make est un compromis acceptable si vous vous accommodez d'une résidence des données en EU, ne voulez pas vous auto-héberger et avez besoin de workflows plus complexes que ce que permet Zapier. Gardez simplement un œil sur le risque M&A.

Ce que vous pouvez faire dès demain

1. Inventoriez vos workflows Zapier/Make existants, aujourd'hui, avant qu'il ne soit trop tard.
2. Déployez une instance de test n8n sur un serveur Hetzner. Le docker-compose.yml présenté ci-dessus est prêt pour la production en 30 minutes.
3. Migrez un workflow non critique comme preuve de concept.
4. Définissez vos niveaux de sensibilité des données : qu'est-ce qui ne peut pas quitter le périmètre de l'entreprise ?

Au fond, l'automatisation n'est pas une question d'outil. C'est une question d'architecture. Et une architecture qui tourne sur des serveurs tiers, hors de votre contrôle, reste une architecture fragile.

Ressources complémentaires

• Documentation n8n : docs.n8n.io (Community Nodes, guide de self-hosting, configuration du mode Queue)
• GitHub n8n : github.com/n8n-io/n8n (Issues, Roadmap, répertoire des Community Nodes)
• Gartner, Magic Quadrant for Integration Platform as a Service, Worldwide, octobre 2025
• BSI-Grundschutz-Kompendium 2025, module CON.2 (protection des données), Office fédéral allemand de la sécurité des systèmes d'information
• Comité européen de la protection des données, Lignes directrices 01/2021 sur l'utilisation des services cloud par le secteur public (applicable à titre de référence pour les entreprises privées)

Niklas est Backend Engineer chez NextGen IT et supervise l'infrastructure d'automatisation des clients ETI en DACH et en France. Cet article reflète une expérience pratique issue de déploiements en production.