Automatiser vos processus avec n8n et l'IA en 2025

n8n est devenu, en trois ans, l'outil que l'on cite dès qu'une PME parle d'automatisation sans vouloir tout confier à un service américain. C'est mérité sur le fond. Mais l'outil a beaucoup changé, sa licence n'est pas celle qu'on croit, et il a connu en 2025-2026 une série de vulnérabilités critiques dont l'une a été exploitée dans la nature. Voici l'état des lieux, vérifié.

Ce que cette version corrige

Cet article a été réécrit le 3 août 2026. La version précédente contenait plusieurs affirmations que je ne peux pas justifier, et il est plus honnête de les nommer que de les faire disparaître discrètement.

Elle annonçait que les PME automatisant leurs tâches gagnent « en moyenne 15 heures par semaine par employé », un taux de recouvrement amélioré de 35 %, une réduction de 80 % du temps de gestion des impayés, une réduction des erreurs de 15 % et une satisfaction client en hausse de 20 %. Aucun de ces chiffres ne renvoyait à une étude. Ils ont été supprimés.

Elle chiffrait aussi une prestation — installation, développement de workflows, formation — et se terminait par une proposition d'audit. Ce site est un portfolio personnel, sans activité commerciale ni vente de services : ces éléments n'avaient rien à y faire et ont été retirés.

Enfin, elle qualifiait n8n d'« alternative open-source à Zapier ». C'est factuellement inexact, et l'éditeur lui-même le dit. La section suivante s'en explique.

Pourquoi vous ne trouverez pas de chiffre de ROI ici

Le calcul de retour sur investissement que faisait l'ancienne version — tant d'heures économisées, multipliées par un coût horaire, divisées par un coût de mise en place — a l'air rigoureux et ne l'est pas. Il repose sur trois hypothèses invérifiables : que la tâche prenait vraiment ce temps, qu'elle disparaît entièrement une fois automatisée, et que le temps libéré est réaffecté à quelque chose de productif.

Dans la pratique, une automatisation ne supprime pas un travail : elle le déplace. Le temps passé à recopier des lignes devient du temps passé à surveiller que le workflow tourne, à le réparer quand une API change, et à traiter les cas particuliers qu'il ne sait pas gérer. Ce solde reste très souvent positif — mais il est propre à chaque organisation, et personne ne peut le calculer à votre place depuis un article de blog.

Ce que l'on peut affirmer sans se tromper : les tâches qui gagnent le plus à être automatisées sont celles qui sont fréquentes, déclenchées par un événement clair, et sans jugement humain. Une relance à J+30, une synchronisation entre deux outils, une notification conditionnelle. À l'inverse, une tâche rare, ambiguë ou politiquement sensible coûtera plus cher à automatiser qu'à faire à la main — et le coût sera payé en maintenance, longtemps après que l'enthousiasme initial soit retombé.

n8n n'est pas open source : ce que dit vraiment sa licence

C'est le point le plus mal compris de l'écosystème, et il a des conséquences concrètes.

n8n est publié sous Sustainable Use License, version 1.0. Le fichier de licence du dépôt est bref et net. Il autorise à utiliser, copier, distribuer et modifier le logiciel, mais « only for your own internal business purposes or for non-commercial or personal use ». La distribution à des tiers n'est permise « only if you do so free of charge for non-commercial purposes ».

L'éditeur revendique lui-même le fait que ce n'est pas de l'open source : selon la définition de l'Open Source Initiative, une licence open source ne peut pas restreindre les usages. Le terme employé est « fair-code », un néologisme défini sur faircode.io.

Ce que cela autorise, en pratique, pour une PME belge :

• héberger n8n en interne et automatiser ses propres processus — sans restriction ;
• construire des workflows pour un client, et facturer ce travail de conception — le consulting est explicitement permis ;
• utiliser n8n comme moteur derrière une fonctionnalité de son propre produit, tant que le processus n'implique pas de collecter les identifiants des utilisateurs finaux pour accéder à leurs données.

Ce que cela interdit :

• héberger n8n et faire payer l'accès à des tiers ;
• le revendre sous sa propre marque.

Il existe par ailleurs une licence Enterprise distincte, décrite dans un fichier LICENSE_EE.md séparé, qui couvre tous les fichiers dont le nom contient .ee.. C'est derrière cette licence que se trouvent l'authentification unique (SSO), la gestion fine des rôles, le versionnage des workflows via Git, la gestion multi-environnements et les journaux d'audit. Autrement dit : les fonctions dont on a besoin dès qu'on est plusieurs à travailler sérieusement sur la même instance ne sont pas dans l'édition gratuite. C'est légitime de la part de l'éditeur, mais il vaut mieux le savoir avant de bâtir une architecture dessus.

Un dernier point souvent avancé à tort : il n'y a aucune clause de conversion différée vers une licence libre après un délai. J'ai lu les deux fichiers de licence ; ce mécanisme, présent chez certains éditeurs, est absent ici.

Où en est n8n en août 2026

Version. La dernière version publiée au moment où j'écris est n8n 2.32.7, datée du 31 juillet 2026, d'après les releases du dépôt officiel. Le rythme de publication est élevé, plusieurs versions par semaine.

La bascule en version 2.0, en décembre 2025, mérite d'être connue de quiconque exploite une instance ancienne, parce qu'elle est décrite par l'éditeur comme une version de durcissement et qu'elle introduit des ruptures de compatibilité volontaires. D'après les notes officielles de migration, elle active par défaut les task runners — l'exécution du code dans un processus isolé —, bloque par défaut l'accès aux variables d'environnement depuis le nœud Code, et désactive par défaut les nœuds capables d'exécuter des commandes système ou de surveiller le système de fichiers local. Si vous êtes resté en 1.x, ce ne sont pas des détails : ce sont exactement les vecteurs qui ont servi dans les vulnérabilités décrites plus bas.

L'entreprise. n8n a levé 180 millions de dollars en série C, sur une valorisation de 2,5 milliards, annoncée le 9 octobre 2025. Ce n'est pas anecdotique pour qui choisit un outil : cela signifie un éditeur bien financé, donc durable à court terme, mais aussi un éditeur qui devra monétiser. Les fonctions qui basculent de l'édition communautaire vers l'édition payante sont un risque à intégrer dans la décision.

Auto-héberger : ce que cela implique vraiment

L'argument massue de n8n, c'est l'auto-hébergement : vos données restent chez vous. C'est vrai, et c'est réellement un avantage. Mais l'auto-hébergement transfère aussi vers vous une liste de responsabilités que le mode hébergé assumait.

Vous devenez responsable de la disponibilité, des sauvegardes et de leur restauration — une sauvegarde jamais testée n'est pas une sauvegarde —, du renouvellement des certificats, et surtout de l'application des correctifs de sécurité. Ce dernier point n'est pas théorique : entre décembre 2025 et février 2026, quatre vulnérabilités critiques ont nécessité une mise à jour rapide. Une instance auto-hébergée que personne ne surveille est un passif, pas un actif.

L'ancienne version de cet article proposait un fichier docker-compose.yml qui n'est plus valable. Il s'appuyait notamment sur les variables N8N_BASIC_AUTH_ACTIVE, N8N_BASIC_AUTH_USER et N8N_BASIC_AUTH_PASSWORD : ces noms n'apparaissent plus nulle part dans la documentation officielle actuelle. Recopier cet exemple aujourd'hui produirait une instance dont vous croiriez qu'elle est protégée par un mot de passe alors qu'elle ne le serait pas. C'est le genre d'erreur qui explique la moitié des instances exposées que l'on trouve sur Internet.

Plutôt que de vous donner un fichier qui aura vieilli dans six mois, deux principes qui, eux, ne vieillissent pas : n'exposez jamais l'interface directement sur Internet sans authentification devant elle, et partez du principe que votre instance sera trouvée. Les moteurs de recherche d'objets connectés indexent en permanence les ports ouverts ; une instance d'automatisation accessible publiquement est repérée en quelques heures, pas en quelques mois.

Les vulnérabilités de 2025-2026, et ce qu'elles enseignent

Ce n'est pas un procès fait à n8n : tout logiciel de cette complexité a des failles, et l'éditeur les corrige vite. C'est un argument sur la mise à jour. Les quatre entrées ci-dessous ont été vérifiées une par une dans la base du NIST.

Référence	Gravité	Nature	Corrigé en
CVE-2025-68613	8,8 (élevé)	Exécution de code via l'évaluation des expressions de workflow, par un utilisateur authentifié	1.120.4 / 1.121.1 / 1.122.0
CVE-2025-68668	9,9 (critique)	Évasion du bac à sable du nœud Code Python, menant à l'exécution de commandes sur l'hôte	2.0.0
CVE-2026-21858	10,0 (critique)	Lecture de fichiers du serveur via certains workflows de formulaire, sans authentification	1.121.0
CVE-2026-25049	9,9 (critique)	Exécution de commandes système via des expressions manipulées	1.123.17 / 2.5.2

Deux observations, et elles comptent plus que les numéros.

La première : CVE-2025-68613 a été ajoutée le 11 mars 2026 au catalogue des vulnérabilités activement exploitées de l'agence américaine CISA. Une faille inscrite à ce catalogue n'est pas une hypothèse de laboratoire : elle est utilisée par des attaquants réels sur des systèmes réels. Le délai entre la publication du correctif (décembre 2025) et l'inscription au catalogue (mars 2026) est le temps qu'ont eu les instances non mises à jour pour se faire compromettre.

La seconde : CVE-2026-21858 était exploitable sans authentification, avec le score maximal de 10,0. Cela signifie qu'aucune protection interne à n8n n'entrait en jeu : il suffisait que l'instance soit joignable. C'est l'illustration la plus nette de la règle énoncée plus haut sur l'exposition réseau.

À côté de ces vulnérabilités du produit lui-même, une attaque de la chaîne d'approvisionnement a visé l'écosystème en janvier 2026, via un paquet communautaire malveillant conçu pour dérober des jetons d'authentification. Ce n'est pas une faille de n8n : c'est le risque inhérent à l'installation de code tiers, sur lequel la section suivante revient.

Un orchestrateur détient les clés de tout le reste

C'est la particularité de cette catégorie d'outils, et elle est trop rarement énoncée : un orchestrateur d'automatisation est, par construction, l'endroit de votre système d'information où sont rassemblés le plus d'identifiants. Pour faire son travail, il détient un accès à votre messagerie, à votre CRM, à votre stockage de fichiers, à votre outil de facturation, souvent à votre base de données, et de plus en plus à une clé d'API de modèle de langage.

Compromettre le serveur de facturation donne accès à la facturation. Compromettre l'orchestrateur donne accès à tout ce que l'orchestrateur sait joindre — sans avoir à attaquer aucun de ces systèmes, puisque les identifiants sont déjà là et que les connexions sont déjà légitimes aux yeux des services distants.

Cela a une conséquence pratique directe : une instance n8n doit être classée au même niveau de criticité que le plus sensible des services auxquels elle se connecte, et pas au niveau d'un « petit outil interne ». C'est aussi ce qui justifie de créer, pour chaque intégration, un compte de service dédié avec les droits minimaux, plutôt que de réutiliser le compte administrateur qui « marche tout de suite ».

La documentation officielle est explicite sur le cas particulier des nœuds communautaires : « community nodes have full access to the machine that n8n runs on, and can do anything, including malicious actions », et « any community node that you use has access to data in your workflows » (page dédiée aux risques). Sur une instance auto-hébergée, on peut les interdire entièrement avec N8N_COMMUNITY_PACKAGES_ENABLED=false.

Durcir une instance : les réglages qui comptent

La page de sécurité de la documentation officielle recense les leviers disponibles. Voici ceux qui ont le meilleur rapport effort/bénéfice, dans l'ordre où je les appliquerais.

1. Mettre à jour, et savoir quand une mise à jour sort. Compte tenu de la section précédente, c'est le premier réglage de sécurité, avant tous les autres. Abonnez-vous aux avis de sécurité du dépôt.
2. Ne pas exposer l'instance directement. Un accès par réseau privé virtuel ou derrière un proxy authentifiant élimine d'un coup toute la classe des vulnérabilités non authentifiées.
3. Protéger la clé de chiffrement des identifiants. n8n chiffre les identifiants stockés au moyen d'une clé (N8N_ENCRYPTION_KEY) ; celui qui obtient à la fois la base et la clé obtient tous vos accès. La documentation prévoit une procédure de rotation : elle existe pour être utilisée.
4. Activer la double authentification et, si vous y avez droit, l'authentification unique.
5. Désactiver l'API publique si vous ne l'utilisez pas (N8N_PUBLIC_API_DISABLED). C'est une surface d'attaque gratuite dans le cas contraire.
6. Bloquer les nœuds dont vous n'avez pas besoin avec NODES_EXCLUDE, en commençant par ceux qui exécutent des commandes ou touchent au système de fichiers.
7. Laisser en place les protections activées par défaut en version 2.0 — task runners isolés, N8N_BLOCK_ENV_ACCESS_IN_NODE — plutôt que de les désactiver pour débloquer un workflow. Si un workflow ne fonctionne qu'avec ces protections désactivées, c'est le workflow qu'il faut revoir.
8. Interdire les nœuds communautaires, ou tenir une liste explicite de ceux que vous acceptez, avec la personne qui en a validé le code.
9. Masquer les données sensibles dans les journaux d'exécution. Par défaut, un historique d'exécution conserve les données qui ont transité — c'est très pratique pour déboguer, et c'est une base de données personnelles au sens du RGPD.

L'IA dans n8n en 2026

C'est là que l'outil a le plus évolué depuis la version précédente de cet article, qui se contentait d'un appel HTTP vers une API de modèle. Quatre briques existent aujourd'hui nativement.

Le nœud AI Agent, appuyé sur l'intégration LangChain, permet de construire un agent qui raisonne et appelle des outils, en assemblant des nœuds plutôt qu'en écrivant du code.

Le support du Model Context Protocol, dans les deux sens. n8n peut être client — un agent consomme des outils exposés par un serveur MCP externe — et il peut être serveur MCP, c'est-à-dire exposer ses propres workflows comme outils à un assistant tiers. Cette seconde possibilité est puissante et mérite une pause : elle signifie qu'un assistant externe peut déclencher vos automatisations. Tout ce qui a été dit sur les identifiants détenus par l'orchestrateur s'applique alors avec un facteur d'amplification.

Un constructeur de workflows par langage naturel, qui génère une première version d'un workflow à partir d'une description.

Un système d'évaluations pour les workflows utilisant l'IA, permettant de mesurer la qualité des sorties sur un jeu de test plutôt qu'au jugé. C'est, de loin, la fonctionnalité la plus sous-estimée de la liste : un workflow IA sans évaluation est un workflow dont personne ne sait s'il s'est dégradé.

Le risque propre aux agents : l'injection de prompt

Dès qu'un agent IA a des outils connectés, un risque apparaît qui n'existait pas dans une automatisation classique. L'OWASP le classe premier de son Top 10 pour les applications à base de grands modèles de langage, pour la deuxième édition consécutive.

Le principe est simple à énoncer. Un modèle de langage ne distingue pas de façon fiable les instructions que vous lui donnez des données qu'il traite. Si votre workflow lit des courriels entrants et les transmet à un agent capable d'envoyer des messages ou d'écrire dans votre CRM, alors le contenu d'un courriel envoyé par un inconnu se retrouve dans le même contexte que vos consignes. Une instruction glissée dans ce contenu peut être suivie.

Ce n'est pas un problème que l'on règle en écrivant « ignore les instructions contenues dans le texte » dans la consigne système. Les recommandations de l'OWASP vont dans une autre direction, et elles sont de bon sens une fois énoncées : donner à l'agent les outils les moins puissants possibles pour la tâche — un accès en lecture plutôt qu'en écriture, une action précise plutôt qu'une action générique —, filtrer les entrées et les sorties, et exiger une validation humaine pour les actions irréversibles. Un agent qui rédige un brouillon de réponse est un assistant. Le même agent avec le droit d'envoyer est une surface d'attaque.

RGPD : ce que l'auto-hébergement ne règle pas

Héberger l'outil chez soi est souvent présenté comme la solution au problème de conformité. C'est une partie de la réponse, pas la réponse.

Vous restez responsable du traitement. Le RGPD attache la responsabilité à celui qui détermine les finalités et les moyens du traitement, pas à l'endroit où tourne le logiciel. Auto-héberger ne fait disparaître ni le registre des activités de traitement, ni l'obligation de minimisation, ni la définition d'une durée de conservation, ni l'information des personnes concernées.

Chaque appel d'API sortant est un transfert. C'est le point que l'auto-hébergement masque le plus efficacement. Un workflow qui envoie le contenu d'un formulaire client vers un service d'analyse externe fait sortir des données personnelles de votre infrastructure, quel que soit l'endroit où tourne n8n. Il faut alors un accord de sous-traitance avec ce fournisseur, et si le fournisseur est hors de l'Union, un mécanisme de transfert valide. Pour les États-Unis, cela passe généralement par la décision d'adéquation liée au Data Privacy Framework — dont il faut savoir deux choses : qu'elle suppose de vérifier que le fournisseur concerné est effectivement certifié, et qu'elle fait l'objet de contestations juridiques toujours en cours.

Les journaux d'exécution sont un traitement à part entière. C'est l'angle mort le plus fréquent. Une instance qui conserve indéfiniment l'historique de ses exécutions accumule, sans que personne ne l'ait décidé, une base de données personnelles hors du système qui était censé les héberger. Définir une durée de rétention et masquer les champs sensibles n'est pas une option de confort.

L'Autorité de protection des données belge propose aux PME un programme d'accompagnement dédié, le projet Boost, qui est un point de départ raisonnable si ces questions sont nouvelles pour vous.

AI Act : où en est-on au 2 août 2026

Le règlement (UE) 2024/1689 est entré en vigueur le 1er août 2024, et son application est échelonnée. D'après la page officielle de la Commission européenne, les pratiques interdites s'appliquent depuis le 2 février 2025, les obligations relatives aux modèles à usage général depuis le 2 août 2025, et le 2 août 2026 marque l'application générale du règlement — y compris les règles de transparence et la compétence effective des autorités nationales pour le faire appliquer. Les règles visant les systèmes utilisés dans certains domaines à haut risque s'appliqueront à partir du 2 décembre 2027, et celles visant les systèmes intégrés à des produits à partir du 2 août 2028.

Pour une PME qui utilise un modèle de langage via une API dans ses workflows, la conséquence pratique la plus immédiate relève de la transparence : lorsqu'un utilisateur interagit avec un système d'IA, il doit pouvoir le savoir. Un agent de support qui répond à vos clients sans que rien ne l'indique est exactement le cas visé.

Je m'arrête là volontairement. La qualification exacte d'une organisation au sens du règlement — et la répartition des obligations qui en découle — dépend de son rôle précis dans la chaîne, et je n'ai pas la compétence pour la trancher dans un article. C'est une question à poser à un juriste, pas à un praticien de l'automatisation.

Les alternatives, et leurs licences réelles

Puisque la licence de n8n est le point le plus mal compris, autant comparer ce qui se compare. Le tableau ci-dessous porte sur la licence, pas sur les fonctionnalités.

Outil	Licence	Positionnement
n8n	Sustainable Use License (fair-code, non-OSI) + licence Enterprise	Automatisation visuelle et IA, auto-hébergeable
Activepieces	MIT	Le concurrent direct réellement open source
Windmill	AGPLv3 + édition Enterprise	Orienté développeurs, scripts et workflows
Node-RED	Apache 2.0 (fondation OpenJS)	Programmation par flux, très fort sur l'IoT
Automatisch	AGPLv3 + édition Enterprise	Équivalent auto-hébergeable de Zapier
Kestra	Apache 2.0 + édition Enterprise	Orchestration déclarative en YAML
Temporal	MIT	Exécution durable, approche « tout en code »
Apache Airflow	Apache 2.0 (fondation Apache)	Pipelines de données planifiés, en Python
Zapier, Make, Power Automate	Propriétaires, sans auto-hébergement	Services hébergés

Si la gouvernance de la licence est votre critère décisif — parce que vous voulez pouvoir revendre, ou simplement ne dépendre d'aucune décision commerciale future —, Activepieces et Node-RED sont les réponses les plus directes. Si c'est la richesse du catalogue d'intégrations et la maturité de la partie IA, n8n garde une avance nette. Les tarifs des offres hébergées changent trop souvent pour être recopiés ici : les pages de prix des éditeurs font foi.

Par où commencer, concrètement

Une trame en cinq étapes, applicable sans accompagnement.

1. Choisir la bonne première tâche. Fréquente, déclenchée par un événement clair, sans jugement humain, et dont l'échec est visible immédiatement. Résistez à l'envie de commencer par le processus le plus important : commencez par celui dont la panne ne fera de mal à personne.

2. Écrire le processus à la main avant de l'automatiser. Si vous ne savez pas décrire les étapes et les cas particuliers en quelques lignes, l'automatisation ne les inventera pas — elle les figera.

3. Poser l'instance proprement dès le premier jour. Pas d'exposition directe sur Internet, sauvegarde de la base et de la clé de chiffrement, mises à jour surveillées. Reprendre cela après coup, sur une instance devenue critique, coûte bien plus cher.

4. Un compte de service dédié par intégration, avec les droits minimaux. C'est la mesure qui limite les dégâts le jour où quelque chose tourne mal, et c'est aussi celle qu'on ne prend jamais le temps de faire ensuite.

5. Décider de la durée de conservation des exécutions avant d'en avoir des milliers. Cette décision est facile à prendre le premier jour et pénible à rattraper le millième.

Et un conseil qui vaut pour toute la démarche : gardez une trace écrite de ce que chaque workflow fait et de qui l'a demandé. Une instance d'automatisation devient très vite un ensemble de mécanismes que plus personne ne sait expliquer — c'est le vrai coût caché de l'automatisation, et il n'apparaît dans aucun calcul de retour sur investissement.

Ce que je n'ai pas pu vérifier

• Les tarifs. Ils changent, et deux relevés successifs de la même page m'ont donné des montants différents selon la devise affichée. Je préfère renvoyer aux pages officielles plutôt que de publier un chiffre faux.
• La qualification exacte au sens de l'AI Act d'une PME qui appelle un modèle via une API. Les analyses convergent, mais je ne les ai pas confirmées sur le texte du règlement lui-même, et ce n'est pas mon domaine.
• L'état précis du contentieux sur la décision d'adéquation UE–États-Unis. Je sais qu'il est en cours ; je n'ai pas pu consulter directement les décisions de justice, dont le site bloque la consultation automatisée.
• Les chiffres d'adoption de n8n (nombre d'instances, part de l'auto-hébergement). Les seules données disponibles viennent de l'éditeur ou d'agrégateurs invérifiables. Elles ne figurent donc pas dans cet article.

---

Sources

• n8n — LICENSE.md (Sustainable Use License 1.0)
• fair-code — définition
• n8n — releases du dépôt officiel
• n8n 2.0 — breaking changes
• n8n — annonce de la série C, 9 octobre 2025
• n8n — sécurité de l'instance
• n8n — risques des nœuds communautaires
• n8n — intégration LangChain
• n8n — MCP Server Trigger
• CVE-2025-68613 — NIST NVD
• CVE-2025-68668 — NIST NVD
• CVE-2026-21858 — NIST NVD
• CVE-2026-25049 — NIST NVD
• CISA — catalogue des vulnérabilités activement exploitées
• OWASP Top 10 for LLM Applications
• Règlement (UE) 2024/1689 sur l'intelligence artificielle — EUR-Lex
• Cadre réglementaire de l'IA — Commission européenne
• Transferts de données UE–États-Unis — Commission européenne
• Projet Boost pour les PME — Autorité de protection des données

---

À propos de l'auteur

Jean-Baptiste Dhondt. Ancien des télécommunications de l'Armée belge, en reconversion vers la cybersécurité. Certifié CCNA et AZ-900, bachelier en informatique en cours.

Je suis praticien, pas consultant, et je n'ai aucune prestation à vous vendre. J'écris ces articles pour documenter ce que j'apprends et pour le soumettre à la contradiction. Si vous relevez une erreur ou une source manquante, la page de contact est faite pour ça.