n8n 2.0 : 6 changements qui peuvent casser vos workflows

Si vous faites tourner n8n en self-hosted et que vous n’êtes pas encore passé en version 2.0, on doit parler. Parce que la branche 1.x ne reçoit plus de nouvelles fonctionnalités depuis le début du printemps, juste des correctifs de sécurité, et que la migration vers la 2.0 n’est plus une option qu’on repousse “quand j’aurai le temps”. Le souci, c’est que cette mise à jour n’est pas une 2.0 cosmétique avec trois boutons qui bougent. C’est une release qui change les valeurs par défaut de sécurité et la mécanique de publication. Traduction : des workflows qui tournaient nickel hier peuvent se mettre à planter après l’update, sans que vous ayez touché à quoi que ce soit.

J’ai migré plusieurs instances, dont la mienne et celles de clients, et j’ai vu les mêmes pièges revenir. Alors plutôt que de vous laisser découvrir ça en prod un mardi matin, je vous liste les six changements qui font vraiment mal, et surtout comment les anticiper. Si vous êtes sur n8n Cloud, une bonne partie de cet article vous concerne moins (j’y reviens), mais lisez quand même la section sur le Save/Publish, parce que celle là touche tout le monde.

Petit rappel : c’est quoi n8n 2.0, et pourquoi maintenant

La 2.0 est sortie en décembre 2025, plus de deux ans après la 1.0. n8n l’a présentée non pas comme une release de features mais comme une release de “durcissement” : sécurité par défaut, fiabilité, performance. En clair, ils ont fermé des portes qui étaient ouvertes par commodité, et qui posaient des problèmes en environnement sérieux.

Pourquoi en parler en juin 2026, six mois après ? Parce que beaucoup d’indépendants et de petites équipes ont gelé leur instance sur la 1.x “tant que ça marche”. Sauf que la 1.x est passée en mode maintenance trois mois après la sortie de la 2.0. Pas de nouveaux nœuds, pas de nouveaux modèles IA, pas de nouvelles intégrations. Si vous voulez le node qui vient de sortir pour votre workflow, il faut migrer. Et migrer sans préparation, sur cette version là, c’est le meilleur moyen de casser vos automatisations.

1. Le Save/Publish : votre workflow ne passe plus en prod quand vous sauvegardez

C’est LE changement que tout le monde va sentir, Cloud comme self-hosted. Et c’est aussi le plus déroutant les premiers jours.

En 1.x, le comportement était simple, presque trop. Vous ouvrez un workflow actif, vous modifiez un nœud, vous cliquez sur “Save”, et hop, votre modif est en production immédiatement. Pratique. Sauf quand vous sauvegardiez un truc à moitié fini par réflexe, et que votre automatisation client se mettait à envoyer des mails bizarres dans la seconde.

En 2.0, n8n sépare les deux gestes :

• Save enregistre votre brouillon. Vos modifs sont conservées, mais ce qui tourne en production ne bouge pas.
• Publish prend votre brouillon et le pousse réellement en live.

Action	Comportement en 1.x	Comportement en 2.0
Sauvegarder un workflow actif	Mise en prod immédiate	Brouillon enregistré, prod inchangée
Pousser en production	Implicite, dès le Save	Geste explicite via “Publish”
Risque de casser la prod par erreur	Élevé	Faible

C’est franchement mieux, parce que ça vous évite de déployer une connerie à moitié testée. Mais ça demande de changer une habitude profondément ancrée. Pendant les premiers jours, vous allez modifier un workflow, vous demander pourquoi votre correction n’a aucun effet en prod… et réaliser que vous avez oublié de cliquer sur Publish. Notez-le quelque part, collez un post-it sur votre écran s’il le faut.

2. Les Code nodes qui lisent des variables d’environnement vont planter

On entre dans le dur, et c’est là que ça casse silencieusement. En 2.0, les “task runners” sont activés par défaut. Concrètement, chaque exécution d’un nœud Code tourne désormais dans un environnement isolé, en mode sécurisé. Excellente nouvelle pour la sécurité. Moins cool si vous aviez pris des libertés dans vos nœuds Code.

Le piège numéro un : l’accès aux variables d’environnement depuis un nœud Code est bloqué par défaut. Si vous avez l’habitude de récupérer une clé API ou une URL de base de données avec un bon vieux process.env.MA_CLE directement dans un nœud Code JavaScript, ça ne marche plus. Le nœud va échouer, ou vous renvoyer undefined, et votre workflow va se vautrer plus loin sans message clair.

// Ce qui marchait en 1.x dans un nœud Code
const apiKey = process.env.OPENAI_API_KEY; // → undefined en 2.0

// La bonne approche en 2.0 :
// stocke le secret dans une CREDENTIAL n8n,
// et appelle l'API via le nœud HTTP Request configuré
// avec cette credential, pas via process.env dans du Code.

La logique de n8n est saine : un secret n’a rien à faire en clair dans un nœud Code, il doit vivre dans le système de credentials, chiffré. Mais si vous aviez quinze workflows qui tapaient dans process.env, vous allez devoir tous les revoir.

Deuxième piège dans la même veine : la méthode $evaluateExpression() ne fonctionne plus à l’intérieur d’un nœud Code. Le mode sécurisé désactive l’évaluation de chaînes en tant que code, et c’est précisément le mécanisme sur lequel cette fonction reposait. Si vous l’utilisiez pour construire des expressions dynamiques, il faut revoir l’approche.

3. Le node Python n’est plus le même

Si vous utilisiez le nœud Code en Python, accrochez-vous. n8n 2.0 a retiré Pyodide, la version de Python qui tournait dans le navigateur. À la place, c’est du Python natif uniquement, ce qui veut dire que les task runners deviennent obligatoires et que le mode externe est requis pour ce type de nœud.

Pour la plupart des gens qui font du no-code et un peu de JavaScript, ça change rien, ils ne touchent pas au Python. Mais si vous aviez bricolé des nœuds Python pour du traitement de données, du parsing, ou des petits calculs, ils ne vont pas se comporter pareil. Certaines libs disponibles sous Pyodide ne le sont plus de la même façon en Python natif. À tester impérativement avant de pousser en prod.

Honnêtement, si vous débutez, mon conseil reste le même qu’avant : restez sur le JavaScript pour vos nœuds Code, l’écosystème n8n est pensé autour de JS, et vous aurez beaucoup moins de surprises.

4. Deux nœuds sont désactivés par défaut (et c’est voulu)

n8n 2.0 désactive par défaut deux nœuds considérés comme à risque : Execute Command (qui lance des commandes système) et Local File Trigger (qui surveille le système de fichiers). Si un de vos workflows s’appuie dessus, après migration il va vous sortir une erreur du genre “Unrecognized node type: n8n-nodes-base.executeCommand”. Pas très parlant quand vous le découvrez à froid.

La raison est limpide : un nœud qui peut exécuter n’importe quelle commande sur votre machine, c’est une porte grande ouverte si jamais quelqu’un arrive à injecter du contenu dans votre workflow. Sur une instance exposée, c’est exactement le genre de truc qui transforme une automatisation en faille.

Nœud	État en 2.0	Pour le réactiver
Execute Command	Désactivé par défaut	Variable d’environnement dédiée à passer à true
Local File Trigger	Désactivé par défaut	Variable d’environnement dédiée à passer à true
OAuth callback non authentifié	Bloqué par défaut	Authentification désormais requise sur les callbacks

Vous pouvez les réactiver via les variables d’environnement de configuration de votre instance, n8n documente lesquelles. Mais avant de le faire par réflexe, posez-vous la question : est-ce que j’ai vraiment besoin que mon instance puisse lancer des commandes shell ? Souvent, on peut remplacer un Execute Command par un appel HTTP propre ou un nœud dédié, et fermer la porte pour de bon.

5. Des options de config qui disparaissent

Côté infra self-hosted, plusieurs réglages que vous aviez peut être dans votre fichier de conf ou votre docker-compose ont sauté. À vérifier avant de redémarrer votre instance, sinon elle risque de ne pas se lancer ou de se comporter bizarrement :

• L’option --tunnel (le tunnel de dev pour exposer un webhook local) a été retirée.
• La variable N8N_CONFIG_FILES a été supprimée.
• Le réglage QUEUE_WORKER_MAX_STALLED_COUNT a disparu.
• Les valeurs par défaut de N8N_RESTRICT_FILE_ACCESS_TO et N8N_GIT_NODE_DISABLE_BARE_REPOS ont changé, dans le sens plus restrictif.
• Le “Start node” historique a été retiré des workflows.

Aucun de ces points n’est dramatique pris isolément, mais si votre instance est configurée aux petits oignons depuis deux ans, c’est le genre de détail qui vous fait perdre une soirée à comprendre pourquoi ça démarre plus.

6. La 1.x ne vous sauvera plus très longtemps

C’est une question de calendrier. n8n a annoncé que la 1.x ne reçoit que des correctifs de sécurité et de bugs pendant trois mois après la sortie de la 2.0, sans aucune nouvelle fonctionnalité. Ce délai est passé. Rester en 1.x aujourd’hui, c’est vous couper de tous les nouveaux nœuds, des nouveaux modèles IA branchés nativement, et des améliorations continues.

Donc la vraie question n’est pas “est-ce que je migre”, c’est “est-ce que je migre préparé ou en catastrophe”. Et comme vous l’avez vu, sur cette release précise, l’impro se paie cash.

Le plan de migration en 5 étapes

Voilà la méthode que j’applique, dans l’ordre, pour migrer une instance sans transformer ça en nuit blanche.

1. Sauvegardez tout. Avant de toucher à quoi que ce soit, faites une sauvegarde complète : base de données n8n, fichier de credentials, variables d’environnement. Si la migration part en vrille, vous voulez pouvoir revenir en arrière en cinq minutes, pas reconstruire trois mois de boulot.

2. Lancez le Migration Report. n8n 2.0 fournit un outil de rapport de migration, accessible depuis les paramètres de l’instance pour les administrateurs. Il scanne vos workflows et vous liste ce qui va poser problème avant que vous upgradiez. C’est votre meilleur ami : il fait à votre place une partie du travail de repérage des points de rupture.

3. Faites l’inventaire des points sensibles. En parallèle du rapport, cherchez manuellement dans vos workflows les process.env dans les nœuds Code, les $evaluateExpression, les nœuds Execute Command et Local File Trigger, et vos éventuels nœuds Python. Listez-les. Chaque ligne, c’est une chose à corriger ou à reconfigurer.

4. Migrez d’abord sur une instance de test. Ne migrez jamais la prod en premier. Montez une instance 2.0 à part (un container Docker temporaire suffit), importez vos workflows critiques, et faites-les tourner. Vous voyez ce qui casse, vous corrigez au calme. C’est dix fois moins stressant.

5. Basculez la prod, puis surveillez. Une fois que votre instance de test tourne propre, faites la prod. Et surtout, gardez un oeil sur les exécutions pendant les 48 heures qui suivent. La plupart des surprises (une credential mal reconfigurée, un nœud Code qui renvoie undefined) se voient dans les logs d’exécution, pas au moment du démarrage.

Ce que je retiens de cette migration

n8n 2.0, c’est une release qui va dans le bon sens. Elle ferme des trous de sécurité que des outils sérieux n’auraient jamais dû laisser ouverts, et elle pousse les bonnes pratiques (les secrets dans les credentials et pas en clair, la séparation brouillon/prod) au niveau de la valeur par défaut. Sur le fond, ils ont raison.

Mais “aller dans le bon sens” et “ne rien casser au passage” sont deux choses différentes. Cette 2.0 récompense ceux qui migrent en ayant lu les breaking changes, et punit ceux qui font un docker pull en se croisant les doigts. Vous avez maintenant la liste, donc vous êtes dans le premier groupe.

Si vous voulez creuser, la page officielle des breaking changes n8n liste chaque point dans le détail, et l’article d’annonce de la 2.0 explique la philosophie derrière. Gardez-les sous le coude le jour où vous lancez votre migration.

Et si tout ça vous paraît un peu abstrait parce que vous débutez sur n8n, c’est normal, et c’est exactement le genre de réflexes qu’on travaille ensemble. Construire des workflows propres, sécurisés et qui survivent à une montée de version, ça ne s’improvise pas, mais ça s’apprend vite quand on vous montre les bons gestes dès le départ.

FAQ

Est-ce que je suis obligé de migrer vers n8n 2.0 ?

Techniquement non, votre instance 1.x continue de tourner. Mais elle ne reçoit plus de nouvelles fonctionnalités depuis le printemps 2026, juste des correctifs. Donc plus de nouveaux nœuds, plus de nouveaux modèles IA, plus de nouvelles intégrations. En pratique, rester en 1.x trop longtemps, c’est se condamner à une stagnation.

Mes workflows no-code vont-ils survivre à la migration ?

Dans la grande majorité des cas, oui. Les changements qui cassent touchent surtout les nœuds Code (variables d’environnement, $evaluateExpression, Python) et les nœuds système (Execute Command, Local File Trigger). Si vos workflows sont 100% no-code classique, le principal ajustement sera le passage au système Save/Publish.

C’est quoi la différence entre Save et Publish en n8n 2.0 ?

Save enregistre vos modifications sous forme de brouillon, sans toucher à ce qui tourne en production. Publish prend ce brouillon et le déploie réellement en live. En 1.x, sauvegarder un workflow actif le mettait en prod immédiatement, ce n’est plus le cas. Il faut désormais cliquer sur Publish pour déployer.

Pourquoi mes nœuds Code ne peuvent plus lire process.env ?

Parce que les task runners sont activés par défaut en 2.0 et isolent l’exécution du code, en bloquant l’accès aux variables d’environnement. C’est une mesure de sécurité. La bonne méthode est de stocker vos secrets dans les credentials n8n (chiffrées) et de les utiliser via les nœuds dédiés comme HTTP Request, plutôt que de les lire en dur dans un nœud Code.

Comment réactiver le nœud Execute Command en 2.0 ?

Via une variable d’environnement de configuration de votre instance, documentée par n8n. Mais avant de le faire, demandez-vous si vous en avez réellement besoin : un nœud capable de lancer des commandes système est un risque de sécurité, et il existe souvent une alternative plus propre (un appel HTTP, un nœud spécifique) qui rend cette réactivation inutile.

---

Vous voulez apprendre à construire des workflows n8n propres, sécurisés et qui ne s’écroulent pas à la première montée de version ? La formation n8n vous accompagne de zéro jusqu’aux automatisations de production : nœuds, credentials, gestion des erreurs, agents IA et bonnes pratiques pour du solide.