n8n 2.0 est la version stable de la plateforme d'automatisation open source depuis décembre 2025. La branche 1.x n'a reçu que des correctifs de sécurité pendant trois mois, jusqu'en mars 2026. Rester dessus expose votre production sans filet, et vos scénarios d'intelligence artificielle avec elle. La bonne nouvelle, c'est que la montée en version casse un nombre limité de choses, toujours les mêmes. L'éditeur fournit même un outil pour les repérer avant de toucher au serveur.
Cet article donne la liste exacte des ruptures, la préparation côté serveur, la migration en six étapes et ce qui arrive avec n8n 3.0. Si vous découvrez l'outil, commencez plutôt par notre guide complet de n8n en français. Si la question porte sur le budget, notre article sur le prix réel de n8n détaille la facturation à l'exécution.
Ce que n8n 2.0 change vraiment
n8n 2.0 est une version de durcissement. L'éditeur a regroupé trois chantiers dans la même montée de version majeure. Le premier isole l'exécution du code. Le deuxième fiabilise le stockage. Le troisième sépare ce que vous éditez de ce qui tourne en production. Dans son annonce de lancement, n8n chiffre le gain du nouveau pilote SQLite à dix fois plus rapide sur ses propres tests.
Le contexte explique l'ampleur du chantier. Entre la version 1.0 et la version 2.0, le projet est passé d'environ 30 000 à plus de 160 000 étoiles sur GitHub, et son forum de 6 267 à 115 192 membres. Une base d'utilisateurs de cette taille déploie en production, avec des données clients et des accès à des systèmes internes. Les réglages permissifs des débuts ne tenaient plus.
Les six ruptures qui cassent un scénario n8n
Tous les changements de n8n 2.0 ne se valent pas. Six d'entre eux arrêtent franchement un scénario qui tournait la veille. Les trois premiers sont critiques, au sens où le scénario échoue dès la première exécution après la montée en version.
- Le nœud Start a disparu. C'était la façon historique de démarrer un scénario. Remplacez-le par un Manual Trigger pour les exécutions manuelles, ou par un Execute Workflow Trigger si un autre scénario appelle celui-ci. Un nœud Start désactivé se supprime simplement.
- Le Code node ne lit plus les variables d'environnement. Le réglage N8N_BLOCK_ENV_ACCESS_IN_NODE passe à true par défaut. Tout script qui lisait process.env renvoie désormais une erreur. Les secrets doivent passer par les credentials de la plateforme.
- Les task runners s'activent par défaut. Le code s'exécute dans un processus isolé, en mode sécurisé. La conséquence la plus visible touche la fonction $evaluateExpression, qui ne répond plus dans le Code node et renvoie null ou une erreur.
- Les sous-scénarios renvoient leur sortie. En 1.x, un scénario parent qui attendait un enfant mis en pause récupérait l'entrée de l'enfant. Il récupère maintenant son résultat final. Ce correctif rend enfin utilisables les nœuds de validation humaine dans un sous-scénario.
- Quatre nœuds de services arrêtés sont retirés. Spontit, crowd.dev, Kitemaker et Automizy quittent le catalogue parce que les services qu'ils appelaient n'existent plus.
- Le bouton Activer devient Publier. Ce point mérite sa propre section plus bas, parce qu'il change une méthode de travail et pas seulement un libellé.
Pourquoi votre Code node ne se comporte plus pareil
Les task runners sont le vrai cœur de n8n 2.0. Avant, le code JavaScript d'un Code node s'exécutait dans le même processus que n8n. Un script mal écrit, ou volontairement malveillant, voyait la mémoire du serveur et ses variables d'environnement. Depuis la version 2.0, ce code part dans un processus séparé aux droits réduits.
Trois effets de bord reviennent dans les retours de la communauté officielle. Le premier concerne la fonction $evaluateExpression, décrite ci-dessus, pour laquelle la documentation des changements de rupture recommande de sortir l'évaluation du Code node plutôt que de réactiver le mode non sécurisé. Le deuxième touche Python, dont l'ancienne exécution dans le navigateur laisse la place à un vrai interpréteur côté runner. Le troisième est le délai d'attente, car un script qui ne trouve pas de runner libre échoue sur un message d'expiration.
Le bouton Activer n'existe plus, place à Save et Publish
Dans n8n 1.x, un seul geste suffisait. Vous modifiez un scénario, vous enregistrez, et la version enregistrée part en production si le scénario est actif. Un essai laissé en l'état tournait pour de vrai. n8n 2.0 coupe ce lien. Les modifications s'enregistrent automatiquement en brouillon, en une à cinq secondes, et la production continue de jouer la dernière version publiée.
Ce changement répond à un problème que je décrivais sur LinkedIn en février 2026, dans un post sur la frontière entre un agent de développement et une plateforme d'automatisation. Le piège que je pointais tient en une phrase. Quand ça marche en local, personne ne vérifie que c'est vraiment en production. Et quand un scénario casse à trois heures du matin, vous ne voulez pas un terminal. Vous voulez des logs lisibles, des reprises automatiques et une alerte.
Concrètement, la publication est asynchrone. n8n calcule la différence entre la dernière version publiée et la nouvelle, puis ne réapplique que les déclencheurs qui ont changé. Les webhooks et les planifications inchangés continuent de tourner sans interruption. Le bouton affiche Publishing jusqu'à la confirmation, et cet état est stocké côté serveur, donc un rechargement de page ne le perd pas.
Ce qu'il faut préparer côté serveur
Cette partie ne concerne que les instances auto-hébergées. Elle réclame une fenêtre de maintenance et une sauvegarde, parce qu'une migration de schéma de base de données ne se rejoue pas à l'envers. Voici les réglages qui changent de valeur par défaut ou qui disparaissent.
| Réglage | Avant | En n8n 2.0 | Ce que vous devez faire |
|---|---|---|---|
| Base de données | MySQL, MariaDB, PostgreSQL ou SQLite | PostgreSQL ou SQLite | Migrez vos données vers PostgreSQL avant la montée en version |
| N8N_DEFAULT_BINARY_DATA_MODE | default, en mémoire | filesystem, database ou s3 | Choisissez un mode et vérifiez l'espace disque du conteneur |
| N8N_RESTRICT_FILE_ACCESS_TO | Aucune valeur, tout le disque | Le dossier ~/.n8n-files | Déplacez les fichiers lus ou écrits par vos scénarios |
| N8N_SKIP_AUTH_ON_OAUTH_CALLBACK | true | false | Retestez chaque intégration OAuth après la bascule |
| Permissions du fichier de configuration | Libres | 0600 exigées | Corrigez les droits, ou désactivez le contrôle sous Windows |
| n8n --tunnel | Disponible | Retiré | Passez par ngrok, localtunnel ou Cloudflare Tunnel |
Deux autres réglages passent inaperçus jusqu'à l'incident. Le nœud Git bloque désormais les dépôts nus par défaut. Et la variable N8N_CONFIG_FILES a été supprimée, donc une instance qui chargeait sa configuration par ce biais démarre avec des valeurs par défaut sans le dire franchement.
Comment migrer de n8n 1.x vers 2.0 sans casser la production
L'ordre des opérations compte plus que la vitesse. n8n fournit un rapport de migration intégré, disponible dans les dernières versions de la branche 1, sous Réglages puis Rapport de migration. Il est réservé aux administrateurs globaux de l'instance. Il affiche combien de vos scénarios passeront sans modification, et classe les problèmes restants en critique, moyen et faible.
Ce détail de dernière exécution est le plus utile du rapport. Dans la plupart des instances que Tandem reprend, une bonne moitié des scénarios listés n'a pas tourné depuis des mois. Les traiter avant la montée en version coûte du temps pour rien. Classez par date d'exécution, traitez ce qui tourne vraiment, archivez le reste.
Vos scripts et vos agents migrent aussi
Le point le plus souvent oublié ne vit pas dans l'interface. Tout ce qui pilote n8n de l'extérieur a été écrit pour la version 1.x. La commande d'interface en ligne update:workflow disparaît et laisse la place à deux commandes distinctes, publish:workflow et unpublish:workflow. Les scripts de déploiement qui activaient un scénario après un import échouent donc en silence si personne ne les relit.
Même chose pour les intégrations maison. Les hooks frontaux workflow.activeChange et workflow.activeChangeCurrent sont remplacés par workflow.published. Une supervision branchée sur les anciens hooks continue de tourner sans jamais remonter d'événement, ce qui est la pire forme de panne.
Le cas le plus récent est celui des agents de développement qui écrivent du n8n à votre place. J'ai filmé ce montage dans mon tutoriel sur la génération de scénarios n8n avec Claude Code, et je l'ai détaillé dans une édition de ma newsletter. Le principe tient en trois pièces, un serveur MCP qui expose le catalogue de nœuds, une clé d'API vers votre instance, et un fichier de contexte qui explique le projet à l'agent.
Ce montage reste valable en n8n 2.0, à une condition. L'agent s'appuie sur ce qu'il connaît du catalogue de nœuds, donc un modèle qui a appris la version 1.x vous proposera un nœud Start ou un script qui lit process.env. Deux lignes dans le fichier de contexte suffisent à corriger le tir. Indiquez la version majeure de votre instance, et interdisez explicitement les nœuds retirés.
Le même raisonnement vaut pour vos agents en production. Notre tutoriel de création d'agent IA sur n8n détaille la structure attendue par le nœud AI Agent. Il donne aussi les garde-fous à poser avant toute mise en ligne.
n8n 3.0 arrive en octobre 2026, et Docker devient obligatoire
Migrer vers n8n 2.0 en pensant être tranquille deux ans serait une erreur de planification. La page officielle des changements de rupture de la version 3.0 annonce la prochaine version majeure pour octobre 2026. Elle porte un changement de déploiement qui touchera beaucoup d'instances françaises.
- L'auto-hébergement passe obligatoirement par Docker. Les installations lancées par npm ou npx ne seront plus supportées. n8n ne publiera même plus de paquet exécutable sur npm.
- Le délai d'attente des task runners tombe à une minute, contre cinq minutes aujourd'hui. Un script lourd dans un Code node échouera, sauf réglage explicite.
- Les paquets communautaires non vérifiés sont désactivés par défaut. Tout nœud installé depuis npm sans vérification réclamera une activation volontaire.
- La première version du nœud AI Agent est retirée, avec ses modes SQL Agent, Conversational Agent, ReAct et Plan and Execute. Les scénarios déjà passés en Tools Agent ne bougent pas.
- Le dossier de données binaires est renommé. Un volume monté sur l'ancien chemin empêche n8n de démarrer si les deux dossiers coexistent.
Faut-il migrer vers n8n 2.0 maintenant
Oui, et la question ne se pose plus vraiment. La branche 1.x n'a plus reçu de correctif de sécurité depuis mars 2026, et n8n 3.0 arrive en octobre 2026. Une instance restée en 1.x devra enchaîner deux montées de version majeures, avec les ruptures des deux cumulées. C'est exactement la situation que vous voulez éviter.
La migration elle-même est courte quand elle est préparée. Sur les instances que Tandem reprend, la partie technique tient en une demi-journée pour une instance de taille moyenne, et l'essentiel du temps part dans la relecture des scénarios à Code node. Le vrai risque n'a jamais été la montée en version. Il tient à l'outillage périphérique, aux scripts de déploiement et aux supervisions que personne ne relit.
Si vous hésitez encore entre n8n et une plateforme fermée, notre comparatif n8n face à Make et Zapier pose les critères. Et si vous préférez déléguer la montée en version et la reprise des scénarios, Tandem intervient sur ces chantiers via son offre d'agence n8n et son offre Autopilote.
