n8n vs Zapier vs Make : quelles différences ?
+
Zapier et Make sont des SaaS : rapide à lancer, coût qui explose en volume, données chez l'éditeur. n8n est open source, self-hostable, pricing maîtrisé, code autorisé. Pour des flux internes stratégiques, n8n gagne.
Peut-on faire tourner n8n on-premise ?
+
Oui. Docker, Kubernetes, VM simple : votre DSI garde la main. On opère aussi n8n en cloud dédié quand vous préférez externaliser le run.
n8n sait-il appeler des LLM ?
+
Oui nativement : Anthropic Claude, OpenAI, Google Gemini, Mistral, Ollama. On orchestre des chaînes d'agents avec mémoire, tools et human-in-the-loop.
Combien de temps pour un workflow type ?
+
De 1 jour (synchro simple) à 2-3 semaines (agent IA complet avec monitoring, retry, observabilité). Notre méthode SmotFlow découpe en phases testables.
Combien coûte un déploiement n8n ?
+
n8n est open source et gratuit en self-hosted. Les coûts viennent de l'infrastructure (serveurs : 50 à 500 €/mois selon volumétrie) et du build des workflows. Un workflow simple démarre à 1-3 jours-homme. Un agent IA complet avec mémoire, observabilité et human-in-the-loop : 2 à 4 semaines. Le forfait n8n Cloud officiel existe aussi (à partir de 50 €/mois) si on préfère externaliser le run, mais le self-hosting reste la voie native.
n8n est-il vraiment open source ?
+
Oui. n8n est distribué sous Sustainable Use License : libre d'utilisation interne, code accessible, contributions ouvertes. La licence interdit uniquement de revendre n8n en SaaS concurrent. Pour 99 % des entreprises (qui veulent automatiser leurs propres process), c'est strictement équivalent à de l'open source classique. Vous pouvez auditer le code, le modifier, contribuer.
Comment connecter n8n à notre ERP ou CRM ?
+
n8n dispose nativement de 500+ connecteurs (Salesforce, HubSpot, SAP, Microsoft Dynamics, Sage, Odoo, Pipedrive…). Pour les ERP custom ou les API internes, deux options : utiliser le node HTTP générique avec une auth standard (OAuth, API Key, JWT), ou écrire un node custom en TypeScript pour encapsuler la logique. Sur les flux critiques, nous mettons en place du retry, du dead letter queue et du monitoring.
n8n peut-il remplacer un ESB ou un middleware classique ?
+
n8n peut remplacer un middleware sur les flux à enjeu modéré (volumétrie < 100 000 events/jour, latence non critique). Pour des flux à très haut débit ou des contraintes temps réel strictes (trading, IoT industriel), un ESB classique (Mulesoft, Apache Camel, Kafka) reste préférable. Notre angle : démarrer avec n8n, monter en charge progressivement, et réarchitecturer vers un ESB seulement quand la volumétrie ou les SLA l'imposent. C'est très rare en pratique.