n8n 2.0 : 6 changements qui peuvent casser tes workflows

Si tu fais tourner n8n en self-hosted et que tu n’es 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 tu aies 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 te laisser découvrir ça en prod un mardi matin, je te liste les six changements qui font vraiment mal, et surtout comment les anticiper. Si tu es sur n8n Cloud, une bonne partie de cet article te concerne moins (j’y reviens), mais lis 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 de freelances et de petites équipes que je croise 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 tu veux le node qui vient de sortir pour ton workflow, il faut migrer. Et migrer sans préparation, sur cette version là, c’est le meilleur moyen de casser de la prod.

1. Le Save/Publish : ton workflow ne passe plus en prod quand tu sauvegardes

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. Tu ouvres un workflow actif, tu modifies un nœud, tu cliques sur “Save”, et hop, ta modif est en production immédiatement. Pratique. Sauf quand tu sauvegardais un truc à moitié fini par réflexe, et que ton automatisation client se mettait à envoyer des mails bizarres dans la seconde.

En 2.0, n8n sépare les deux gestes :

Save enregistre ton brouillon. Tes modifs sont conservées, mais ce qui tourne en production ne bouge pas.
Publish prend ton 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 t’évite de déployer une connerie à moitié testée. Mais ça demande de changer une habitude profondément ancrée. Pendant les premiers jours, tu vas modifier un workflow, te demander pourquoi ta correction n’a aucun effet en prod… et réaliser que tu as oublié de cliquer sur Publish. Note le quelque part, colle un post-it sur ton é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 tu avais pris des libertés dans tes 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 tu as 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 te renvoyer undefined, et ton 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 tu avais quinze workflows qui tapaient dans process.env, tu vas 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 tu l’utilisais pour construire des expressions dynamiques, il faut revoir l’approche.

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

Si tu utilisais le nœud Code en Python, accroche toi. 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 tu avais 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 tu débutes, mon conseil reste le même qu’avant : reste sur le JavaScript pour tes nœuds Code, l’écosystème n8n est pensé autour de JS, et tu auras 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 tes workflows s’appuie dessus, après migration il va te sortir une erreur du genre “Unrecognized node type: n8n-nodes-base.executeCommand”. Pas très parlant quand tu le découvres à froid.

La raison est limpide : un nœud qui peut exécuter n’importe quelle commande sur ta machine, c’est une porte grande ouverte si jamais quelqu’un arrive à injecter du contenu dans ton 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

Tu peux les réactiver via les variables d’environnement de configuration de ton instance, n8n documente lesquelles. Mais avant de le faire par réflexe, pose toi 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 tu avais peut être dans ton fichier de conf ou ton docker-compose ont sauté. À vérifier avant de redémarrer ton 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 ton instance est configurée aux petits oignons depuis deux ans, c’est le genre de détail qui te fait perdre une soirée à comprendre pourquoi ça démarre plus.

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

Ce n’est pas un bug, c’est le 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 te 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 tu l’as 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. Sauvegarde tout. Avant de toucher à quoi que ce soit, fais une sauvegarde complète : base de données n8n, fichier de credentials, variables d’environnement. Si la migration part en vrille, tu veux pouvoir revenir en arrière en cinq minutes, pas reconstruire trois mois de boulot.

2. Lance 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 tes workflows et te liste ce qui va poser problème avant que tu upgrades. C’est ton meilleur ami : il fait à ta place une partie du travail de repérage des points de rupture.

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

4. Migre d’abord sur une instance de test. Ne migre jamais la prod en premier. Monte une instance 2.0 à part (un container Docker temporaire suffit), importe tes workflows critiques, et fais les tourner. Tu vois ce qui casse, tu corriges au calme. C’est dix fois moins stressant.

5. Bascule la prod, puis surveille. Une fois que ton instance de test tourne propre, fais la prod. Et surtout, garde 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. Tu as maintenant la liste, donc tu es dans le premier groupe.

Si tu veux 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. Garde les sous le coude le jour où tu lances ta migration.

Et si tout ça te paraît un peu abstrait parce que tu débutes 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 te montre les bons gestes dès le départ.

FAQ

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

Techniquement non, ton 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 tes 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 tes 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 tes 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 ton instance, documentée par n8n. Mais avant de le faire, demande toi si tu en as 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.

Tu veux 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 t’accompagne de zéro jusqu’aux automatisations de production : nœuds, credentials, gestion des erreurs, agents IA et bonnes pratiques pour du solide.