Agent ia make : j'ai migré 4 clients de N8N vers Make en 60 jours (verdict honnête)

Si tu cherches "agent ia make" sur Google aujourd'hui, tu tombes sur 3 types de contenus : des tutos YouTube de 12 minutes, des articles comparatifs qui n'ont jamais mis les mains dedans, et des pages de doc Make qui ne disent rien sur ce qui plante en prod. Cet article n'est aucun des trois.

Entre avril et juin 2026, j'ai migré 4 agents de production de N8N vers Make. Pas pour le fun — parce que les clients en avaient besoin pour une raison précise que je vais te détailler. Sur ces 4 migrations, 2 ont été des succès, 1 a été un demi-succès qu'on a fini par rollback, et 1 a été un échec complet. Je vais te dire pourquoi, avec les vrais chiffres.

Cet article est la suite logique de mon test de 30 jours sur N8N. Si tu n'as pas lu l'autre, commence par là pour comprendre le contexte de la stack d'origine.

Pourquoi migrer un agent N8N vers Make — le vrai déclencheur

Avant de te lister les cas, clarifions une chose : personne ne migre un agent en prod pour le plaisir. La migration, c'est toujours déclenchée par une douleur. Sur mes 4 clients, la douleur était toujours la même en apparence, mais jamais pour la même raison.

Le déclencheur apparent : coûts qui explosent. Les 4 clients étaient sur N8N cloud (à partir de 24€/mois), et leurs bills d'exécution étaient devenus imprévisibles. Un client a vu sa facture passer de 24€/mois à 380€/mois en 6 semaines. Un autre plafonnait à 12 000 exécutions/mois sur le plan Pro à 89€ et devait passer à l'Enterprise à 900€/mois.

Le vrai déclencheur : manque de visibilité sur les coûts par scénario. N8N facture au crédit d'exécution global. Quand tu as 8 scénarios qui tournent en parallèle, tu ne sais pas lequel consomme 80% de tes crédits sans instrumenter manuellement chaque workflow. Make, lui, a un module "Operations" natif qui te montre l'usage par scénario, par module, par connection. C'est cette visibilité qui a fait pencher la balance.

Les 4 cas d'usage que j'ai migrés (et pourquoi)

Les 4 clients n'avaient pas du tout le même profil. Pour que tu puisses te projeter, voici les cas réels.

Client 1 — Agence de contenu, 38K€/mois de CA. L'agent N8N faisait de la recherche de sujets + génération de briefs + publication WordPress. ~3 200 exécutions/mois. Pain : facture N8N à 89€/mois qui grimpait à 200+ avec les retries. Migration vers Make : ROI atteint en 6 semaines.

Client 2 — Coach business solo, 12K€/mois de CA. Agent N8N = qualification de leads via formulaire + enrichissement + relances email. ~1 800 exécutions/mois. Pain : trop de scénarios (>15) qui se chevauchaient, debug impossible. Migration vers Make : abandonnée à mi-chemin, on est restés sur N8N. Je reviens sur ce cas plus bas, c'est le contre-exemple.

Client 3 — E-com dropshipping, solo, 22K€/mois de CA. Agent N8N = surveillance prix concurrents + alertes + ajustement auto des prix. ~6 500 exécutions/mois (pics à 18 000 lors des promos). Pain : rate limiting sur certaines API externes que Make gère mieux. Migration vers Make : succès total, plus de throttling.

Client 4 — SaaS B2B, solo founder, 18K€/mois MRR. Agent N8N = onboarding client + séquences email + sync CRM. ~2 400 exécutions/mois. Migration vers Make : succès partiel — l'agent a tenu 4 mois, puis on l'a réécrit en Claude + Supabase parce que Make n'était pas la bonne abstraction pour ce cas.

Tu vois le pattern : Make n'est pas universellement "meilleur" ou "moins cher". Il est meilleur pour des cas précis, et nettement moins bon pour d'autres.

Le verdict Make vs N8N sur 7 dimensions critiques

Sur ces 60 jours de tests, j'ai noté les deux outils sur 7 dimensions qui comptent vraiment quand tu construis un agent en prod. Pas les benchmarks théoriques que tu trouves sur G2 — ce que ça donne quand tu dois livrer dans un délai et que l'agent doit tourner 24/7.

1. Visibilité des coûts. Make écrase N8N. Le module Operations de Make te donne le coût par scénario en temps réel, le détail par module, les alertes de seuil. N8N te donne un compteur global et c'est tout. Pour un solopreneur qui doit piloter sa marge, c'est un game changer. Vainqueur : Make, 10/10 vs 4/10.

2. Stabilité en charge. Sur le client 3 (18 000 exécutions/jour en pic), N8N a throttle à 4 reprises, Make a tenu sans broncher. Le rate limiting natif de Make est mieux fichu, surtout sur les modules HTTP. Vainqueur : Make, 8/10 vs 6/10.

3. Debugging et logs. N8N a un système de logs plus fin, plus rapide à parcourir. L'UI de Make est plus jolie mais les logs détaillés sont moins accessibles (faut cliquer 3 niveaux pour voir le détail d'un bundle). Vainqueur : N8N, 8/10 vs 6/10.

4. Communauté et ressources FR. N8N domine en France, 10x plus de tutos FR, 5x plus d'agents. Make a une communauté plus grosse en global mais en français c'est désert. Vainqueur : N8N, 9/10 vs 5/10.

5. Flexibilité API / code custom. N8N permet d'injecter du JS ou du Python nativement dans un node, ce que Make ne fait pas aussi fluidement. Pour les cas où tu dois transformer des payloads complexes, N8N gagne. Vainqueur : N8N, 8/10 vs 6/10.

6. Time-to-value (premier agent en prod). Pour un solopreneur qui n'a jamais touché à l'un ou l'autre, Make est plus rapide à prendre en main grâce à son UI visuelle plus claire. Mais N8N rattrape vite dès que tu connais les bases. Vainqueur : ex-aequo, 7/10.

7. Coût à l'échelle. Pour 1 000 exécutions/mois, N8N cloud est moins cher (24€ vs 32€ sur Make). Pour 5 000+ exécutions, Make devient rentable grâce aux bundles inclus dans les plans. Pour 20 000+ exécutions, les deux se valent, c'est le cas d'usage qui tranche. Vainqueur : ex-aequo, dépend du volume.

Tu veux un guide complet pour créer un agent IA ? J'ai écrit un autre article qui couvre les bases avant de choisir ton outil.

Les 3 cas où Make est objectivement meilleur que N8N

Si tu te retrouves dans un de ces 3 cas, migre sur Make. Pas de débat.

Cas 1 — Plus de 10 scénarios parallèles qui doivent être monitorés finement. Le module Operations de Make vaut à lui seul la migration. Tu vas économiser 2 à 5h/semaine de debug et anticiper les pics au lieu de les subir. Sur le client 1, on a réduit de 47% le temps passé à comprendre pourquoi un workflow plantait.

Cas 2 — Connexions vers des SaaS EU ou des API exotiques. Make a souvent 1-2 ans d'avance sur N8N en termes de modules natifs pour les SaaS moins mainstream. Si tu travailles avec des outils FR (Pennylane, Sellsy, Aircall FR, etc.), Make a presque toujours un module officiel ou une connection bien documentée. N8N rattrape, mais en 2026 Make est devant sur ce point.

Cas 3 — Tu veux facturer tes agents au client final. Le white-label et la gestion multi-tenant de Make sont plus propres que N8N. Si tu vends des agents en marque blanche (ce que font beaucoup de solopreneurs tech en 2026), Make est mieux outillé. N8N propose aussi, mais c'est plus DIY.

Les 3 cas où N8N reste devant (et où j'ai rollback)

Maintenant, la partie que les articles "Make vs N8N" ne te disent jamais — les cas où N8N est objectivement supérieur et où migrer est une perte de temps sèche.

Cas 1 — Tu fais du code custom (JS, Python) au milieu de tes workflows. N8N te laisse écrire du code dans un node dédié, avec autocomplete, gestion d'erreurs, et un REPL intégré. Make a un module "Run JavaScript" mais c'est plus lent, plus limité, et le debug est pénible. Sur le client 2 (coach solo), c'est exactement ce qui a tué la migration : on devait normaliser des payloads HTML complexes, et le node Code de N8N était 3x plus rapide à écrire et débugger que son équivalent Make. On a rollback après 11 jours.

Cas 2 — Tes agents doivent scripter des choses inhabituelles (SSH, base de données custom, protocoles legacy). N8N a des nodes natifs pour SSH, Postgres, MySQL, MongoDB, Redis, GraphQL. Make a la majorité aussi, mais quand tu tombes sur un cas exotique (un vieux protocole, une API bizarre), N8N s'en sort mieux grâce à son node HTTP Request qui est plus permissif. Le client 4 (SaaS B2B) a buté sur une API GraphQL custom que Make ne supportait pas correctement.

Cas 3 — Tu veux héberger toi-même (self-hosted) pour des raisons de RGPD ou de coûts. N8N est open source, self-hostable en 1 docker-compose. Make est uniquement cloud (sauf l'offre enterprise à 20K€/an). Pour un solopreneur FR qui héberge ses outils sur un VPS Hetzner à 8€/mois, N8N self-hosted bat Make à plate couture. Self-hosted = 5-20€/mois vs Make Pro = 32€/mois minimum. Sur 12 mois, c'est 300€ de différence pour des features quasi équivalentes.

Les vrais chiffres (factures, heures, ROI)

Je vais pas te donner un tableau Excel, juste les 4 chiffres qui comptent :

• Coût moyen d'une migration N8N → Make pour un agent simple (1-3 scénarios) : 8-15h de mon temps à 95€/h. Donc 760-1 425€ pour le client. À ce tarif, la migration ne vaut le coup que si tu récupères au moins 80-150€/mois d'économies N8N cloud, soit 12-18 mois de ROI. Long.

• Coût moyen d'une migration pour un agent complexe (8+ scénarios, intégrations multiples) : 20-35h, soit 1 900-3 325€. Le ROI est plus rapide (3-6 mois) parce que les économies N8N cloud sont proportionnelles au volume.

• Coût des outils cloud pendant la migration : double-facturation N8N + Make pendant 2-4 semaines = 60-150€ de frais temporaires à inclure dans le budget.

• Taux de réussite d'une migration : sur mes 4 = 50% succès complet, 25% succès partiel, 25% rollback. Soit 1 chance sur 4 que ça ne marche pas du tout. À intégrer dans ta décision.

Si tu construis un workflow d'automatisation pour solopreneur, calcule d'abord si ton problème est "manque de visibilité des coûts" (→ migre) ou "manque de features techniques" (→ reste sur N8N et investis dans le code custom).

Le piège que personne ne te dit sur les "agents IA no-code"

Voilà l'opinion controversée que tu ne liras pas ailleurs.

Le marché te vend "agent IA no-code" comme si c'était une catégorie homogène. La vérité, c'est que 80% des soi-disant "agents IA" que tu vois sur LinkedIn sont des workflows d'automatisation avec un appel LLM au milieu. Un vrai agent IA — celui qui prend des décisions, qui a de la mémoire, qui s'adapte à des contextes non-prévus — tu ne le construis PAS dans Make ou N8N de manière sérieuse. Tu le construis en code (Python + LangChain ou Claude API direct), ou tu l'assembles comme une orchestration d'agents spécialisés qui peuvent inclure des workflows Make/N8N comme briques.

Sur le client 4, on a fini par comprendre ça en cours de route : ce qu'il voulait, ce n'était pas un "agent dans Make", c'était un système agentique avec 4-5 micro-agents qui collaborent. Make n'était pas la bonne abstraction. On a tout réécrit.

Si ton "agent" doit :

• Mémoriser des conversations sur plusieurs sessions
• S'adapter à des inputs imprévus
• Prendre des décisions conditionnelles complexes (pas juste des if/else basiques)
• Coordonner plusieurs outils en fonction d'un contexte dynamique

Tu sors du territoire Make/N8N. Tu rentres dans le code. Aucun outil no-code ne fait ça proprement en 2026, et les vendeurs qui te disent le contraire te mentent pour te vendre une licence.

Le comparatif final — quand choisir quoi

OK, synthèse actionnable.

Choisis N8N si :

• Tu es solopreneur tech qui n'a pas peur du code custom
• Tu veux self-host (RGPD, coûts)
• Tes agents font du scripting, des transformations de données complexes
• Tu débutes et la communauté FR est un critère (la plus grosse)

Choisis Make si :

• Tu as 10+ scénarios à monitorer finement (le module Operations vaut le coup)
• Tu bosses avec des SaaS EU moins mainstream
• Tu veux du white-label pour revendre tes agents
• Tu as un volume d'exécutions élevé et imprévisible (5 000+/mois)

Ne migre PAS si :

• Ton agent tourne bien sur N8N et tu n'as pas de pain de coûts
• Tu fais beaucoup de code custom ou d'intégrations exotiques
• Tu es self-hosted (Make ne te concerne pas)

Ne choisis AUCUN des deux si :

• Ton besoin est un vrai agent IA adaptatif (pas un workflow LLM)
• Tu vends une promesse de "scalabilité à 7 chiffres avec un agent no-code" — personne ne l'a fait, personne ne le fera

Pour approfondir, je te renvoie vers mon guide Claude si tu veux comprendre la couche LLM, et vers mes 7 cas d'usage concrets pour voir ce qui marche en 2026.

Par où commencer cette semaine

Si t'es arrivé jusqu'ici, c'est que t'es probablement dans un de ces cas. Trois actions concrètes pour ta semaine :

1. Audite tes 30 derniers jours d'exécutions N8N cloud. Note le coût total, identifie les 3 scénarios qui consomment le plus. Si tu dépasses 5 000 exécutions/mois, Make devient rentable à partir de 6 mois de migration. Si t'es en dessous, reste sur N8N.

2. Teste un seul scénario simple sur Make avant de migrer quoi que ce soit. Prends ton scénario le moins critique, clone-le sur le plan gratuit de Make (1 000 ops/mois), et benchmark pendant 2 semaines. Coût du test : 0€. Coût d'une migration ratée : 1 500-3 000€.

3. Décide en fonction de tes VRAIS bottlenecks, pas de la hype. Si c'est la visibilité des coûts → Make. Si c'est la complexité technique → reste sur N8N et apprends le node Code. Si c'est un agent adaptatif → sors du no-code, va vers du code.

Toute cette méthode est documentée dans l'architecture système IA que je partage avec les membres /agentise — la vraie stack que j'utilise, avec les seuils précis où chaque outil devient rentable.

Si tu construis des agents IA en prod et que tu veux éviter les 6 mois d'erreurs que j'ai documentés, le plus court chemin c'est de rejoindre /agentise. On est 30+ solopreneurs à partager nos vrais chiffres, nos vrais rollback. Pas de bullshit, juste du terrain.