Deux clients, deux besoins identiques, deux outils différents. Voilà comment j'ai choisi.
Le contexte
Client A — startup tech, 3 devs, besoin d'automatiser un pipeline de qualification de leads. Données sensibles, logique complexe, équipe technique.
Client B — PME marketing, 0 dev, besoin de connecter Typeform → Slack → Notion → Airtable. Équipe non-technique qui veut gérer elle-même.
Résultat : n8n pour A, Make pour B. Voici pourquoi.
n8n : puissance et contrôle
n8n est self-hostable (Docker en 5 minutes), open-source, et donne accès à du code JavaScript natif dans chaque node.
// Node "Function" dans n8n — logique pure JS
const leads = $input.all()
return leads
.filter(lead => lead.json.score > 70)
.map(lead => ({
json: {
...lead.json,
priority: lead.json.score > 90 ? 'HOT' : 'WARM',
assignedTo: lead.json.budget > 10000 ? 'senior' : 'junior',
},
}))
Avantages n8n :
- Self-hosted = données qui ne quittent pas votre infra
- Code custom sans limitation
- Webhooks bidirectionnels natifs
- Prix fixe (pas de "crédits" par exécution)
- API complète pour trigger depuis votre code
Limites n8n :
- Interface moins intuitive pour les non-devs
- Maintenance de l'infra Docker vous incombe
- Moins de connecteurs visuels "grand public"
Make : fluidité et accessibilité
Make (ex-Integromat) excelle dans les workflows visuels avec drag & drop, des connecteurs pour 1500+ apps, et une logique de scénarios lisible par n'importe qui.
Avantages Make :
- Onboarding en 10 minutes pour un non-dev
- Connecteurs visuels pour Google Sheets, Notion, HubSpot, Slack...
- Gestion d'erreurs visuelle avec retry automatique
- Pas d'infra à maintenir
Limites Make :
- Pricing par "opérations" — explose vite sur gros volumes
- Pas de code custom natif (workarounds limités)
- Données transitent par les serveurs Make
La règle de décision
Qui maintient le workflow ?
├── Un dev / une équipe tech
│ └── → n8n (self-hosted)
└── Une équipe non-technique
├── Volume < 50k opérations/mois
│ └── → Make (plan Core suffisant)
└── Volume > 50k opérations/mois
└── → n8n (coût maîtrisé)
Le calcul de coût qui change tout
Sur le papier, Make paraît moins cher au démarrage : un plan Core à ~9€/mois contre un VPS à ~5-10€/mois pour n8n. La différence apparaît au scaling.
Make facture à l'opération (chaque étape d'un scénario compte). Un workflow avec 8 étapes exécuté 10 000 fois par mois, c'est 80 000 opérations — largement au-dessus du plan Core (10 000 op.), il faut passer au plan Teams ou Business, avec une facture qui grimpe vite au-delà de 50-100€/mois selon le volume.
n8n self-hosted, lui, tourne sur un VPS à prix fixe quel que soit le nombre d'exécutions. Le seul coût variable est votre propre attention à la charge serveur (et éventuellement un upgrade de VPS si le volume devient massif). Pour un client avec plusieurs workflows à fort volume, la bascule vers n8n se rentabilise généralement en 2-3 mois.
Exemple réel (client B2B, 15k opérations/mois) :
- Make (plan Teams) : ~110 €/mois
- n8n (VPS 2 vCPU/4 Go) : ~12 €/mois + maintenance ponctuelle
- Seuil de rentabilité : ~6 semaines après migration
Le mode hybride
Dans la pratique, je ne pousse pas toujours au tout-ou-rien. Certains clients gardent Make pour les workflows simples gérés par l'équipe marketing (formulaires, notifications, CRM léger), et migrent vers n8n uniquement les pipelines à fort volume ou à logique complexe (scoring, enrichissement, IA). Les deux outils coexistent, chacun sur son terrain : autonomie opérationnelle d'un côté, contrôle technique de l'autre.
La gestion d'erreurs, un critère sous-estimé
On compare souvent n8n et Make sur le prix et la puissance, rarement sur ce qui se passe quand un workflow échoue en pleine nuit. C'est pourtant ce qui détermine si un incident se règle en 5 minutes ou en une matinée perdue.
Make a une longueur d'avance native ici : chaque scénario a un historique d'exécution visuel, avec le payload exact à l'étape qui a échoué, et un bouton "Replay" pour rejouer uniquement cette exécution après correction. Pour une équipe non-technique, c'est la différence entre "on peut corriger nous-mêmes" et "il faut rappeler le développeur".
n8n demande un peu plus de setup pour arriver au même niveau de confort :
// Node "Error Trigger" — se déclenche sur l'échec de n'importe quel workflow
const failedExecution = $input.first().json
await sendSlackAlert({
channel: '#automation-errors',
message: `❌ Workflow "${failedExecution.workflow.name}" a échoué`,
details: failedExecution.execution.error.message,
replayUrl: `https://n8n.example.com/workflow/${failedExecution.workflow.id}/executions/${failedExecution.execution.id}`,
})
Une fois ce node "Error Trigger" branché sur tous les workflows critiques (5 minutes de setup, une seule fois), n8n rattrape son retard : alerte immédiate, lien direct vers l'exécution en échec, contexte complet. La différence n'est donc pas tant "lequel gère mieux les erreurs" que "lequel le fait sans configuration" — un point à ne pas négliger si l'équipe qui va opérer le workflow au quotidien n'est pas technique.
Ce que j'utilise en pratique
Pour mes propres projets et les clients tech : n8n, toujours. Le contrôle total et le coût fixe l'emportent.
Pour les clients qui veulent l'autonomie opérationnelle : Make jusqu'à un certain volume, puis migration vers n8n quand la facture Make devient irrationnelle.
Les deux ont leur place. Le piège est de choisir par défaut plutôt que par raisonnement.