n8n 3.0 : ce qui casse, et comment migrer vos automatisations sans panne

Qu'est-ce que n8n 3.0 change pour les entreprises ?

n8n 3.0 est une version de nettoyage et de fiabilisation : elle retire d'anciennes fonctions, durcit la sécurité par défaut et impose Docker pour l'auto-hébergement. La bêta est disponible depuis le 27 octobre 2026 et la version stable est prévue début décembre 2026, selon l'éditeur.

n8n est un outil qui relie vos logiciels entre eux : quand un client remplit un formulaire, un scénario (qu'on appelle un workflow) crée la fiche dans le CRM, envoie un courriel de confirmation et prévient l'équipe. Il existe en version hébergée par l'éditeur et en version que l'on installe sur son propre serveur, dite auto-hébergée. Beaucoup de PME et de développeurs indépendants choisissent la seconde, pour garder la main sur leurs données.

Ce que n8n annonce pour cette version 3.0, c'est d'abord un objectif de fond : améliorer la fiabilité, la stabilité et la sécurité, en supprimant des fonctionnalités anciennes et en revoyant le fonctionnement interne. Ensuite, les nouveautés doivent arriver en continu sur la branche 3.x. Autrement dit, rester en 2.x, c'est choisir de ne plus recevoir de nouveautés.

Je précise un point : cet article s'appuie sur la documentation et les annonces officielles de n8n, consultées à la date de publication. La bêta peut encore évoluer d'ici la version stable. Avant toute décision sur vos propres scénarios, il faut relire la page officielle des changements cassants.

Quels nœuds et fonctions disparaissent avec n8n 3.0 ?

Une longue liste d'anciens nœuds est supprimée, dont Function, Function Item, Item Lists, Cron, Interval et l'ancien nœud OpenAI. Les scénarios qui les utilisent échouent, et ceux qui sont publiés ne s'activent plus : il faut les remplacer par les nœuds actuels.

Un nœud, dans n8n, c'est une brique d'un scénario : « lire un courriel », « appeler une API », « envoyer un message ». La documentation officielle indique les remplaçants à utiliser. Les principaux :

D'autres éléments partent sans équivalent direct, notamment LangChain Code, Motorhead, Zep, SerpApi et Orbit. Si l'un d'eux sert chez vous, il faut repenser la partie concernée du scénario, pas seulement changer une brique.

Plusieurs fonctions disparaissent aussi à l'intérieur des scénarios : l'ancienne manière de retrouver l'élément d'origine ($getPairedItem) est supprimée, la première version de l'AI Agent également, et certaines sources du nœud Execute Sub-workflow (fichier local, URL) ne sont plus acceptées. Côté interface, l'option « Import from URL » et l'onglet « Ask AI » du nœud Code disparaissent.

Pourquoi n8n 3.0 impose-t-il Docker pour l'auto-hébergement ?

Parce que n8n ne prend plus en charge l'installation par npm ou par npx n8n. Si votre n8n a été installé de cette façon sur un serveur, il faut d'abord le faire passer sous Docker, un système qui empaquette l'application avec tout ce dont elle a besoin pour fonctionner.

L'éditeur propose une installation en une ligne et une installation par Docker Compose, un fichier qui décrit l'ensemble des services à lancer. Les déploiements Kubernetes et Helm ne sont pas concernés, selon l'annonce. Pour un site ou un petit serveur, la documentation de n8n décrit un montage classique : n8n et un proxy qui gère le chiffrement HTTPS, un dossier de données conservé dans un volume, et un fichier de variables de configuration.

Le point le plus sensible, c'est le volume de données. La documentation indique que le dossier /home/node/.n8n contient la base SQLite par défaut et la clé de chiffrement de n8n. Même quand on utilise PostgreSQL, ce dossier reste recommandé parce qu'il garde les clés de chiffrement. Perdre cette clé, c'est ne plus pouvoir relire les identifiants enregistrés dans vos scénarios. Je ne migre jamais sans l'avoir sauvegardée à part.

Autre changement de configuration à connaître : le dossier ~/.n8n/binaryData est renommé en ~/.n8n/storage, et n8n refuse de démarrer si les deux dossiers existent en même temps. Plusieurs variables d'environnement sont aussi supprimées ou changent de valeur par défaut :

• N8N_RUNNERS_TASK_TIMEOUT passe de 300 à 60 secondes ;
• N8N_UNVERIFIED_PACKAGES_ENABLED passe à false : les modules communautaires non vérifiés sont désactivés par défaut ;
• OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS disparaît : en mode « queue », les exécutions manuelles passent toujours par les workers ;
• N8N_DB_PING_TIMEOUT est remplacée par DB_PING_TIMEOUT_MS.

Si votre n8n tourne déjà sous Docker, vous avez moins de travail, mais ces variables sont à contrôler. Si une personne a installé n8n il y a deux ans et que plus personne ne s'en souvient, c'est le bon moment pour vérifier comment il est réellement installé.

Quels réglages de sécurité et de délai changent par défaut ?

Le délai par défaut du nœud Code passe de 5 minutes à 1 minute, la rotation des clés de chiffrement est toujours active, et les modules communautaires non vérifiés sont désactivés. Ces changements rendent n8n plus sûr, mais peuvent faire échouer un scénario qui fonctionnait.

Pour les non-spécialistes, la protection SSRF empêche qu'un scénario soit détourné pour interroger des adresses internes de votre réseau. Une liste de blocage plus large est une bonne nouvelle pour la sécurité, mais elle peut bloquer un appel légitime vers un service interne. Il faut le tester.

Deux autres changements de comportement méritent une vérification dans les scénarios de messagerie. Le déclencheur Gmail dans ses anciennes versions se comporte comme la version 1.4 : 10 courriels par défaut (50 au maximum), brouillons ignorés sauf option dédiée, courriels envoyés et programmés ignorés. Un scénario de tri de boîte de réception peut donc se mettre à traiter moins de messages sans afficher d'erreur. C'est le genre de changement silencieux qui fait le plus de dégâts.

Enfin, la clé d'accès aux secrets externes évolue : le paramètre qui permettait de les réserver à certains rôles de projet est supprimé, et les éditeurs et administrateurs de projet y ont accès. Si vous voulez limiter cet accès, n8n conseille de créer des rôles personnalisés avant la mise à jour.

Comment préparer la migration avec le Migration Report de n8n ?

En installant la dernière version 2.x (au moins la 2.39) puis en ouvrant Settings, Migration Report. Cet outil liste les scénarios et réglages concernés, corrige automatiquement certains problèmes et exporte un fichier CSV pour répartir le travail.

C'est une bonne initiative de la part de n8n. Le rapport propose de désigner un responsable par scénario, ce qui est précieux quand plusieurs personnes ont créé des automatisations au fil des ans. Les corrections automatiques sont enregistrées sous la forme d'une nouvelle version du scénario, que l'on valide soi-même. Les identifiants et l'historique d'exécution sont conservés pendant la mise à jour, qui entraîne un court redémarrage.

Voici la démarche recommandée par l'éditeur, que j'applique en y ajoutant quelques précautions :

1. Passer à la dernière 2.x. Si vous êtes encore en 1.x, il n'existe pas de chemin direct vers la 3.x : il faut passer par la 2.x.
2. Lire le Migration Report. Traiter chaque ligne ou la marquer « won't fix » en connaissance de cause.
3. Sauvegarder à part. Base de données, dossier de données avec la clé de chiffrement, fichier de configuration, et export des scénarios importants.
4. Tester sur une copie. Un environnement de test (staging) avec les mêmes scénarios, sans toucher aux vrais clients.
5. Passer en production à un moment calme, avec quelqu'un qui surveille les premières exécutions.

Un rapport vide ne signifie pas zéro risque : l'outil repère ce qu'il sait détecter, pas les hypothèses cachées dans vos scénarios (un service externe qui attend un format précis, par exemple). Les scénarios critiques, ceux qui touchent les commandes, les factures ou les relances clients, méritent un test complet.

Faut-il migrer tout de suite vers n8n 3.0 ?

Non, pas en production pendant la bêta. En revanche, c'est le moment de préparer : faire l'inventaire, lancer le Migration Report et tester sur une copie. La bonne fenêtre pour basculer est la version stable, début décembre, bien avant la fin du support de la 1.x au 31 décembre.

Mon avis, honnêtement : une bêta n'a rien à faire sur des automatisations qui facturent vos clients. Ce que je fais en revanche dès maintenant, c'est la partie la plus longue, celle que personne n'aime : savoir ce qui existe. Combien de scénarios sont actifs, lesquels utilisent d'anciens nœuds, qui s'en sert, ce qui se passe si l'un s'arrête une journée.

Selon votre situation, le calendrier réaliste ressemble à ceci :

• Vous êtes en 1.x : la priorité est de passer en 2.x avant le 31 décembre, car la 1.x ne sera plus suivie. Visez ensuite la 3.x une fois stabilisée.
• Vous êtes en 2.x : vous avez du temps (12 mois de correctifs de sécurité après la sortie stable de la 3.x), mais pas de nouveautés. Planifiez la migration au premier trimestre, sans attendre la fin.
• Vous êtes sur l'offre hébergée par n8n : les sources que j'ai consultées parlent surtout de l'auto-hébergement. Je n'ai pas trouvé le détail du calendrier de bascule pour l'offre hébergée : renseignez-vous auprès de n8n.

Dernier conseil : ne profitez pas de la migration pour tout refaire. On migre à fonctionnalité constante, on vérifie, et seulement ensuite on améliore. Mélanger les deux, c'est la meilleure façon de ne plus savoir d'où vient une panne.

Ce que n8n 3.0 rappelle sur l'entretien des automatisations

Une automatisation n'est pas un objet qu'on installe une fois pour toutes : c'est un petit logiciel, avec des dépendances qui vieillissent. Plus il y en a dans votre entreprise, plus il faut savoir qui les surveille et comment on les met à jour.

Quand un outil se simplifie comme le fait n8n, il force chaque utilisateur à regarder ce qu'il a bâti. C'est inconfortable, mais sain. J'en tire trois habitudes que je recommande à mes clients, quel que soit l'outil (n8n, Make, Zapier ou développement maison) :

1. Tenir un inventaire. Une liste des automatisations, de ce qu'elles font, de qui en est responsable et de ce qui se passe en cas d'arrêt.
2. Éviter les briques obsolètes. Dès qu'un éditeur marque un nœud ou une fonction comme ancien, mieux vaut le remplacer à votre rythme que sous la contrainte.
3. Prévoir des alertes. Un scénario qui s'arrête sans que personne le sache est pire qu'un scénario qui échoue bruyamment.

Les assistants d'IA sont de plus en plus intégrés à ces outils (n8n a d'ailleurs retiré des anciens modes de son AI Agent au profit de la version actuelle), ce qui renforce un autre réflexe : toujours garder un humain qui valide les actions sensibles, comme un envoi massif ou un paiement. Pour aller plus loin sur ce sujet, voyez mes pages sur l'automatisation d'entreprise et les agents IA pour les entreprises.

Faire auditer et migrer vos automatisations par un développeur

Si vos automatisations tournent sous n8n et que vous ne savez pas ce que cette version change pour vous, je peux faire l'inventaire, lancer le diagnostic, préparer la migration vers Docker et basculer vos scénarios sur une copie de test avant la mise en production. Devis gratuit sous 24 h.

Je développe des sites, des applications et des automatisations pour des professionnels depuis une vingtaine d'années, et j'administre moi-même des serveurs en production. Pour une migration comme celle-ci, voici ce que je propose :

Si vous n'avez pas encore d'automatisations mais que vous perdez du temps sur des tâches répétitives, regardez ma page automatisation pour les entreprises. Pour relier vos automatisations à un outil métier sur mesure, il y a aussi les applications et CRM sur mesure.

Le plus simple : contactez-moi par le formulaire ou au 06 37 29 19 67, en me précisant l'outil utilisé et la façon dont il est installé. Je vous dis ce qu'il faut prévoir, que vous me confiiez la suite ou non.

Vos questions

Article publié le 31 octobre 2026.