n8n est une plateforme qui fait de l'« automatisation des workflows » un projet open source : le dépôt n8n maintenu par l'organisation n8n-io sur GitHub a dépassé les 200 000 étoiles, ce qui en fait l'un des projets d'infrastructure d'automatisation les plus en vue du moment. On peut le résumer comme « le Zapier open source », à une différence près : la plateforme entière peut s'installer sur votre propre serveur. Les données ne quittent pas votre réseau, et l'auto-hébergement n'impose aucune limite d'exécutions.
Qu'est-ce que n8n, exactement
En une phrase : une plateforme d'automatisation de workflows combinant un canevas visuel et des nœuds de code, avec orchestration native d'agents IA.
Sur le canevas, on assemble des nœuds en workflows : déclencheurs planifiés, webhooks, appels d'API, lectures et écritures en base de données ; la logique complexe s'écrit directement dans des nœuds Code en JavaScript ou Python, avec prise en charge des paquets npm. Ces dernières années, n8n a mis le cap sur l'IA : ses nœuds d'agents IA basés sur LangChain appellent directement les grands modèles de langage, branchent des outils et exécutent des raisonnements en plusieurs étapes, et la bibliothèque officielle de modèles compte déjà plus de 9 000 workflows prêts à l'emploi. « n8n » est l'abréviation de « nodemation » et se prononce « n-eight-n ».
Pourquoi un tel engouement
Premièrement, la mise en production des agents IA exige une couche d'orchestration : les modèles réfléchissent, mais ce sont les appels d'outils, les branchements et les validations humaines qui font le vrai travail — l'orchestration d'agents à la LangGraph résout la même classe de problèmes, tandis que n8n offre une interface visuelle aux équipes non purement techniques. Deuxièmement, la souveraineté des données : la finance ou la santé ne peuvent pas confier leurs données à un SaaS tiers. Troisièmement, la tarification : le cloud officiel facture à l'exécution, l'auto-hébergement ne coûte que le serveur — les équipes à fort volume font le calcul et migrent.
Pour qui — et pour qui pas
Indiqué : développeurs indépendants et petites équipes avec des bases d'exploitation ; entreprises dont les données ne peuvent pas quitter l'intranet ; scénarios où l'on branche des agents IA sur des systèmes existants avec des appels fréquents aux API internes et aux bases de données ; équipes à fort volume sensibles à la facturation SaaS à l'usage.
À éviter : quiconque ne veut jamais toucher à un serveur — en auto-hébergement, mises à jour, sauvegardes et sécurité sont à votre charge ; pour deux ou trois automatisations simples avec une équipe entièrement non technique, l'expérience SaaS pure de Zapier ou Make est plus reposante. Un point d'attention : n8n est sous licence fair-code (Sustainable Use License) — code source visible mais pas une licence open source reconnue par l'OSI. Si votre service juridique est strict sur les licences, relisez le texte de la licence avant de choisir.
Coût de déploiement : la partie qui se paie en vraie monnaie
La prise en main est éclair : une commande Docker suffit, SQLite par défaut, on ouvre le port 5678 dans le navigateur et c'est parti — c'est le « coût d'essai ».
La production est une autre comptabilité : les essais légers démarrent à 1 vCPU et 2 Go de RAM ; l'exploitation réelle recommande 2 vCPU et 4 Go avec PostgreSQL ; en cas de forte concurrence ou d'exécutions IA longues, il faut le mode file d'attente (Redis comme file de tâches, processus principal séparé des workers). Un VPS à la hauteur coûte environ 4 à 10 dollars par mois, contre 24 euros par mois pour l'offre d'entrée du cloud officiel, plafonnée en exécutions — le coût matériel est réellement plus bas. Pour faire tourner aussi les modèles en local, voir cette analyse du coût d'un déploiement Ollama local. Ne pas oublier les coûts cachés : correctifs de sécurité, montées de version, sauvegardes et alertes nocturnes sont un investissement humain continu.
Quatre choses à savoir avant l'auto-hébergement
Premièrement : clé de chiffrement perdue, tous les identifiants stockés perdus. n8n chiffre tous les identifiants tiers avec N8N_ENCRYPTION_KEY, stockée dans le répertoire /home/node/.n8n. La documentation officielle prévient : si ce répertoire est introuvable au démarrage, n8n génère automatiquement une nouvelle clé et les anciens identifiants ne pourront plus jamais être déchiffrés. Des membres de la communauté ont perdu la clé en migrant du mode simple vers le mode file d'attente et vu toutes leurs connexions mourir en une nuit. Contre-mesure : définir la clé explicitement dès le premier jour, la sauvegarder hors du serveur, et migrer la clé avant les données.
Deuxièmement : les changements cassants des versions majeures sont la norme. n8n publie vite et les versions majeures cassent régulièrement des choses : la 2.0 a sorti l'exécuteur de tâches de l'image principale — l'auto-hébergement exige désormais l'image n8nio/runners séparée ; la 3.0 (prévue en octobre 2026) imposera Docker pour l'auto-hébergement, abandonnera les installations npm et supprimera des nœuds historiques. Les migrations de base de données n'avancent que dans un sens — il n'existe pas de chemin de retour officiel. Contre-mesure : figer la version de l'image en production, sauvegarder la base avant toute montée de version, et passer d'abord les workflows concernés au crible avec le rapport de migration officiel.
Troisièmement : la configuration par défaut ne tient pas la charge ni la concurrence. SQLite par défaut plus monoprocessus : dès que la concurrence augmente ou qu'un workflow transporte de gros volumes, les plaintes les plus fréquentes de la communauté portent sur l'explosion de la mémoire voire le plantage du conteneur. La production exige PostgreSQL, le nettoyage automatique des anciennes exécutions, et le découpage en sous-workflows si la mémoire coince. Attention aux utilisateurs d'agents IA : exécutions longues et appels d'outils en plusieurs tours consomment bien plus de mémoire que l'automatisation classique — prévoir 1 à 2 Go par worker en mode file d'attente.
Quatrièmement : l'auto-hébergement, c'est reprendre toute la responsabilité sécurité. Une étude GitGuardian de septembre 2026, en scannant les commits Git publics, a trouvé 4 576 jetons d'API n8n divulgués ; 129 autres instances publiques tournaient encore avec des clés de chiffrement faibles déjà divulguées. Ports exposés, proxys inverses, HTTPS, correctifs — tout ce que la plateforme faisait pour vous à l'ère du SaaS vous incombe désormais. Contre-mesure : ne pas exposer directement le port 5678 sur Internet, gérer jetons et clés via variables d'environnement et gestion des secrets, et imposer HTTPS en production.
Informations sur le dépôt officiel
- Plateforme : GitHub
- Organisation : n8n-io
- Projet : n8n (dépôt n8n-io/n8n)
- Licence : Sustainable Use License (fair-code : code source visible, auto-hébergeable ; pas une licence open source reconnue par l'OSI)
