Guide technique n8n 3.0 : ce qui change vraiment

Je vous propose un guide complet sur n8n 3.0 pour comprendre ce qui change vraiment et comment préparer vos workflows à la migration.

Le 27 octobre 2026, n8n a publié la version bêta de n8n 3.0. Une nouvelle version majeure, mais pas celle qu’on pourrait imaginer. Pas de nouvelle interface révolutionnaire, ni de catalogue de fonctionnalités IA supplémentaires. Cette fois, les développeurs ont surtout travaillé sur ce qu’on ne voit pas : l’architecture d’exécution, la sécurité, la stabilité et la suppression de composants historiques.

L’objectif est de rendre n8n plus fiable, notamment sur les installations auto-hébergées qui exécutent des automatisations métier en continu.

Mais il y a une contrepartie : n8n 3.0 introduit des incompatibilités avec certaines configurations et certains workflows existants. Des nœuds disparaissent, plusieurs comportements changent et certaines installations devront être adaptées.

La bonne nouvelle, c’est que n8n fournit un outil de diagnostic et de migration directement intégré à l’application.

Découvrez égalementPourquoi n8n a-t-il fait évoluer son identité visuelle ?

Je vais surtout m’intéresser à ce qui change concrètement pour ceux qui utilisent n8n en production : quels workflows risquent de ne plus fonctionner, quelles configurations vérifier et comment organiser une migration sans compromettre les automatisations existantes.

Source : Annonce officielle n8n 3.0 — 27 octobre 2026.

La version 2.0 avait été publiée en décembre 2025. Depuis, n8n indique avoir diffusé plus de 45 versions intermédiaires. Les nouvelles fonctionnalités sont livrées progressivement, sans attendre une version majeure.

Cette version 3.0 sert donc principalement à faire évoluer les fondations techniques du produit.

Ces changements concernent les éditions Community auto-hébergées, Cloud et Business/Enterprise. Le rapport de migration est également disponible dans toutes ces éditions. Cela ne signifie pas pour autant que toutes les fonctionnalités commerciales deviennent disponibles gratuitement. n8n Community+1

Ce qui change dans n8n 3.0, en un tableau

Ce sont les principaux changements annoncés officiellement. Leur impact dépend de votre architecture et de la manière dont vos workflows ont été construits. n8n Blog

1. Une architecture d’exécution plus fiable, notamment en mode queue

Découvrez égalementComment créer une veille quotidienne automatisée avec n8n ?

Le premier changement important concerne la manière dont n8n exécute les workflows.

Dans une architecture distribuée, n8n peut fonctionner avec plusieurs composants : une instance principale, Redis pour la file d’attente, une base de données et des workers chargés d’exécuter les automatisations.

Architecture simplifiée en mode queue avec n8n 3.0

Schéma conceptuel du mode queue. Il ne décrit pas tous les composants d’un déploiement.

Les exécutions manuelles passent désormais par les workers

Découvrez égalementComment recharger les crédits n8n Assistant ?

Dans n8n 3.0, lorsqu’une instance fonctionne en mode queue, les exécutions manuelles sont systématiquement confiées aux workers.

C’est une évolution intéressante. Jusqu’ici, une exécution lancée depuis l’éditeur pouvait solliciter directement l’instance principale selon la configuration.

Imaginons qu’un utilisateur lance manuellement un workflow qui récupère 100 000 lignes dans une API, applique des transformations JavaScript, puis alimente PostgreSQL. Si ce traitement mobilise fortement les ressources de l’instance principale, il peut perturber les autres opérations.

Avec n8n 3.0, l’exécution manuelle est confiée au système de workers. Le traitement est donc davantage isolé de l’instance principale.

Attention : cela ne signifie pas que les performances vont automatiquement augmenter. Si tous les conteneurs partagent les mêmes ressources CPU et mémoire, ils restent soumis aux limites du serveur. Le principal bénéfice est une meilleure séparation des responsabilités.

Pour les installations en mode queue, je vérifierais la disponibilité des workers, leur capacité à absorber les exécutions manuelles et la configuration du stockage partagé avant toute migration.

Les données binaires ne peuvent plus être stockées en mémoire

Autre changement important : n8n 3.0 supprime le mode de stockage binaire memory.

Les données binaires correspondent notamment aux fichiers manipulés par les workflows : PDF, images, documents Excel, archives ZIP ou pièces jointes.

Désormais, ces fichiers doivent être stockés sur le système de fichiers ou dans un stockage externe pris en charge, notamment S3.

Pour une instance Docker qui traite régulièrement des fichiers, je privilégierais un stockage persistant explicitement configuré, plutôt qu’une dépendance au système de fichiers éphémère du conteneur.

Et dans une architecture distribuée, le choix du stockage doit être cohérent avec le fonctionnement des workers.

La documentation n8n précise également que le changement de mode de stockage peut avoir des conséquences sur l’accès aux anciens fichiers et sur leur nettoyage automatique. n8n Docs

Source technique : Stockage externe des données binaires.

Le Code node dispose de limites d’exécution plus strictes

n8n réduit le délai maximal d’exécution par défaut du Code node, lorsque celui-ci est exécuté par un task runner. Ancienne valeur par défaut

Ancienne valeur par défaut 300 s avec n8n 3.0 ca passe à 60 s. La durée reste configurable. Ce n’est donc pas une limite absolue imposée à tous les scripts.

Mais elle peut avoir un effet immédiat sur certains traitements : manipulation de gros tableaux JSON, calculs coûteux, parsing de données ou transformations volumineuses.

Un script qui se terminait en deux minutes peut désormais dépasser le timeout par défaut.

Je considère ce changement comme une bonne occasion de vérifier si certains Code nodes ne font pas des traitements qui mériteraient d’être exécutés autrement, par exemple directement dans PostgreSQL, BigQuery ou un service Python externe.

n8n annonce également une réduction des limites de décompression, notamment pour protéger les instances contre les archives ZIP anormalement volumineuses après extraction.

2. Sécurité : des paramètres plus restrictifs par défaut

n8n ne sert plus seulement à synchroniser deux applications SaaS. Il est également utilisé pour exécuter du code, manipuler des données sensibles, interroger des API internes et construire des agents IA capables d’agir sur des systèmes métier.

Les paramètres de sécurité deviennent donc particulièrement importants.

La rotation des clés de chiffrement devient systématique

n8n 3.0 active systématiquement le mécanisme de rotation des clés de chiffrement.

Il faut distinguer la prise en charge de la rotation et le renouvellement effectif des clés. Cette évolution ne doit pas être interprétée comme une promesse de rotation automatique à intervalles réguliers sans autre configuration.

Pour les administrateurs, le point sensible reste la sauvegarde des secrets nécessaires au déchiffrement des credentials.

Une sauvegarde de la base de données sans les éléments de chiffrement correspondants peut devenir inexploitable lors d’une restauration.

Les identifiants Slack nécessitent un Signing Secret

Pour les intégrations concernées, les credentials Slack doivent désormais disposer d’un Signing Secret.

Ce secret sert à vérifier l’authenticité des requêtes reçues de Slack. Sans cette vérification, un endpoint exposé risque d’accepter une requête forgée par un tiers.

La modification concerne la configuration des credentials et doit être vérifiée sur les workflows Slack existants.

Renforcement de la protection SSRF

Une attaque SSRF (Server-Side Request Forgery) consiste à détourner un serveur afin qu’il effectue des requêtes vers des destinations auxquelles l’attaquant ne devrait pas avoir accès.

C’est un sujet important pour n8n : un workflow peut appeler des URL dynamiques, parfois déterminées par des données externes ou par un agent IA.

En version 3.0, la liste des destinations bloquées par défaut est étendue lorsque la protection SSRF est activée.

La nuance est importante. Cette modification ne signifie pas que n8n rend automatiquement toutes les installations protégées contre les SSRF.

Pour les workflows qui utilisent des URL dynamiques, je vérifierais les appels vers les réseaux privés, les services internes et les adresses particulières. Un endpoint précédemment accessible pourrait être refusé si les nouvelles restrictions s’appliquent.

Les packages communautaires non vérifiés sont désactivés par défaut

n8n permet d’étendre ses capacités avec des nœuds développés par la communauté.

C’est pratique, mais cela pose une question de sécurité : un package peut exécuter du code dans l’environnement n8n et accéder à certaines ressources selon ses permissions.

En version 3.0, les packages communautaires non vérifiés sont désactivés par défaut. Les installations qui dépendent de ces extensions doivent donc être examinées avant la migration.

Je ne supprimerais pas systématiquement tous les nœuds communautaires. Je commencerais par identifier ceux qui sont réellement utilisés, puis je contrôlerais leur statut, leur maintenance et leur compatibilité.

Source : Audit de sécurité intégré à n8n.

3. Auto-hébergement : Docker devient la méthode d’installation prise en charge

C’est probablement l’un des changements les plus structurants pour ceux qui administrent eux-mêmes leur instance.

n8n 3.0 ne prend plus en charge l’installation directe via npm ou npx.

Le déploiement auto-hébergé doit désormais passer par Docker. Les installations Kubernetes et Helm continuent d’être prises en charge.

n8n propose également un script d’installation simplifié pour faciliter la transition des utilisateurs habitués à npx.

Pour une installation professionnelle, je préfère néanmoins conserver une configuration Docker Compose explicite, versionnée et sauvegardée. Elle permet de contrôler les images, les volumes, le réseau et les variables d’environnement.

Voici un exemple volontairement minimal pour un environnement de test :

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:3.0.0
    restart: unless-stopped

    ports:
      - "127.0.0.1:5678:5678"

    environment:
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris

    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Ce fichier est un exemple de structure, pas une configuration de production complète. Le tag 3.0.0 désigne la version ciblée et ne doit pas être confondu avec la bêta disponible au 29 octobre 2026.

Il manque notamment la configuration d’accès HTTPS, la gestion explicite des secrets, une politique de sauvegarde et, selon les besoins, PostgreSQL et des workers.

Surtout, ne remplacez pas simplement l’image d’une instance 2.x par une image 3.x en espérant que la migration se déroule sans intervention.

Source : Installation simplifiée officielle de n8n.

4. Quels nœuds disparaissent dans n8n 3.0 ?

La suppression des anciens nœuds est l’un des points à examiner en priorité.

Certains composants conservés pour assurer la compatibilité avec de vieux workflows sont désormais retirés. n8n propose généralement des alternatives plus récentes, mais toutes les migrations ne se résument pas à remplacer un nom de nœud.

Cette liste reprend les principales catégories annoncées, pas l’inventaire exhaustif des composants supprimés.

La documentation officielle détaille également d’autres suppressions. Un rapport de migration reste nécessaire pour déterminer les conséquences sur une instance précise.

Source : Liste officielle des incompatibilités n8n 3.0.

Function et Function Item : attention au mode d’exécution

Le remplacement des anciens nœuds Function et Function Item par Code paraît simple.

Mais ces anciens nœuds n’utilisaient pas exactement le même modèle d’exécution.

Le Code node peut fonctionner en mode Run Once for All Items ou Run Once for Each Item.

Prenons un exemple de transformation d’une liste de commandes :

// Code node : Run Once for All Items

const items = $input.all();

return items.map(item => ({
  json: {
    ...item.json,
    montantTTC: Number(item.json.montantHT) * 1.2
  }
}));

Dans cet exemple, chaque item conserve ses données d’origine et reçoit un champ montantTTC.

Le code est compatible avec le fonctionnement actuel du Code node. Ce n’est pas un outil de migration universel : les anciens scripts doivent être examinés en fonction de leur logique.

Item Lists : plusieurs nœuds spécialisés au lieu d’un seul

L’ancien Item Lists regroupait plusieurs opérations de manipulation de données.

n8n dispose maintenant de nœuds spécialisés pour les opérations de séparation, d’agrégation, de tri, de limitation et de déduplication.

Je trouve cette approche plus lisible, notamment lorsqu’un workflow devient complexe.

Mais il faut vérifier la forme des données obtenues. Une opération d’agrégation peut produire une structure différente de celle attendue par le nœud suivant. Ce sont ces détails qui peuvent provoquer des régressions silencieuses.

Cron et Interval : migration vers Schedule Trigger

Les anciens déclencheurs de planification sont remplacés par Schedule Trigger.

Le nouveau nœud repose sur le système de planification plus robuste de n8n.

Pour les workflows planifiés, je vérifierais en particulier le fuseau horaire, la fréquence réelle d’exécution, le comportement après redémarrage et la publication du workflow.

Un déclenchement toutes les heures ou chaque matin à 8 h peut avoir des conséquences métier importantes. Ce type de migration mérite un test réel, pas seulement une validation de configuration.

Attention à ne pas confondre HTTP Request et HTTP Request Tool

Un échange publié sur le forum officiel n8n apporte une précision utile.

Un utilisateur avait interprété la liste des suppressions comme annonçant la disparition de HTTP Request. Ophir Prusak, de l’équipe n8n, a corrigé ce point le 27 octobre : le nœud HTTP Request classique n’est pas supprimé. Il ne faut pas le confondre avec l’ancien composant HTTP Request Tool.

Même prudence avec les différents nœuds de déclenchement.

C’est exactement pour cette raison qu’il faut analyser les types et versions de nœuds réellement présents dans vos workflows, plutôt que se baser uniquement sur leur nom affiché. n8n Community

5. Les changements qui concernent les agents IA et les expressions

Pour ceux qui utilisent n8n pour construire des agents IA, cette version mérite également une attention particulière.

n8n retire les anciens modes AI Agent et l’intégration OpenAI historique. Cela ne signifie évidemment pas la disparition des agents IA ou de l’intégration OpenAI dans n8n.

Ce sont les anciennes implémentations qui sont concernées.

Les anciens agents IA doivent être contrôlés

Un workflow IA peut associer un modèle de langage, de la mémoire, des outils et des sous-workflows.

Lors d’une migration, je vérifierais les connexions entre ces composants, mais aussi leur comportement.

Un agent qui utilise un ancien mode d’exécution peut nécessiter une adaptation de sa configuration. Le fait que le workflow s’ouvre correctement dans l’éditeur ne garantit pas qu’il produise les mêmes résultats.

Pour une automatisation métier, je testerais au minimum les appels d’outils, la transmission des paramètres, la gestion des erreurs et les conditions de déclenchement des actions.

Certaines méthodes d’expression doivent être remplacées

L’analyse des modifications proposées dans le dépôt GitHub de n8n révèle également des adaptations à prévoir dans les expressions avancées.

C’est notamment le cas de $getPairedItem(), une méthode historique liée à la correspondance des données entre les nœuds.

Les alternatives documentées comprennent notamment :

$('Nom du noeud').item

Ou, pour accéder à un item correspondant à un index précis :

$('Nom du noeud').itemMatching(0)

La méthode pairedItem() fait aussi partie des alternatives selon le contexte.

Ces méthodes ne sont pas interchangeables dans tous les cas. Le choix dépend notamment du contexte d’exécution et de la manière dont n8n conserve les liens entre les items.

Un autre cas concerne $evaluateExpression() lorsqu’il est appelé directement dans du JavaScript exécuté par le Code node. La migration peut nécessiter de déplacer l’évaluation dans un champ d’expression situé en amont.

Ces informations sont corroborées par les travaux publiés sur le dépôt GitHub officiel. La pull request examinée était toutefois fermée sans fusion : elle documente les changements recherchés et leurs recommandations, mais ne prouve pas à elle seule que toutes les nouvelles règles de détection sont livrées dans la bêta.

Source technique : GitHub n8n — adaptations des règles de migration des expressions.

6. Les fonctionnalités d’interface retirées

Quelques fonctionnalités moins centrales disparaissent ou changent de statut.

Chat Hub est désactivé par défaut. Il reste possible de le réactiver dans la branche 3.x. n8n indique vouloir privilégier ses nouvelles expériences autour des assistants et agents IA.

L’option Import from URL est supprimée de l’éditeur. Il ne faut pas en conclure que toutes les méthodes d’importation de workflows disparaissent : c’est cette fonction précise qui est retirée.

Enfin, l’onglet Ask AI du Code node est supprimé.

Ces changements ne devraient pas être bloquants pour la majorité des automatisations exécutées en production. En revanche, ils peuvent modifier les habitudes des équipes qui conçoivent les workflows.

7. Migration Report : l’outil indispensable pour préparer n8n 3.0

C’est, à mon avis, l’élément le plus utile de cette nouvelle version.

Plutôt que de demander aux administrateurs de comparer manuellement tous leurs workflows avec une longue documentation, n8n intègre un rapport qui identifie les incompatibilités connues.

L’outil est disponible dès n8n 2.39, dans :

Settings → Migration Report

Le rapport présente deux catégories importantes.

Workflow issues : les incompatibilités dans les automatisations

Cette partie identifie les workflows concernés par les modifications de n8n 3.0.

Pour de nombreuses incompatibilités, n8n propose une correction automatique.

Le fonctionnement est intéressant : la correction produit une nouvelle version du workflow, qu’il faut ensuite examiner et publier. Pendant cette préparation, la version déjà publiée continue de fonctionner sur l’instance 2.x.

C’est préférable à une modification immédiate de tous les workflows actifs.

Instance issues : les incompatibilités de configuration

Le second volet concerne la configuration générale de l’instance.

Il peut s’agir d’un paramètre d’hébergement, d’une fonctionnalité retirée ou d’un changement de comportement.

Un rapport sans erreur de workflow ne signifie donc pas que l’instance est prête à migrer. Il faut également examiner les problèmes de configuration.

Gestion des responsables et suivi des corrections

Le Migration Report propose plusieurs fonctions utiles lorsqu’une instance regroupe de nombreux workflows.

Il identifie les workflows concernés, suggère un responsable à partir du dernier utilisateur ayant modifié le workflow et permet aux administrateurs de réattribuer les interventions.

Les responsables peuvent recevoir un email indiquant les corrections à réaliser.

Les workflows non publiés ou inactifs depuis longtemps peuvent également être écartés du traitement avec un statut won't fix.

Enfin, un export CSV permet de conserver un inventaire des problèmes et de leur traitement.

Pour les instances professionnelles comportant des dizaines, voire des centaines de workflows, cet inventaire peut devenir un véritable support de recette.

Exemple de suivi de migration

Exemple fictif de tableau de suivi, pas une capture de données issues d’une instance réelle.

Il faut toutefois garder une limite en tête : ce rapport détecte des incompatibilités connues. Il ne remplace pas une recette fonctionnelle.

Un workflow peut ne présenter aucune incompatibilité signalée et produire malgré tout un résultat inattendu après modification de son environnement.

Source : Documentation officielle du Migration Report n8n 3.0.

8. Comment migrer vers n8n 3.0 sans mettre la production en danger ?

La procédure officielle repose sur quatre grandes étapes : mettre à jour la branche 2.x, corriger les incompatibilités, sauvegarder l’instance, puis effectuer la migration sur un environnement de test avant la production.

J’ajouterais quelques contrôles techniques, particulièrement pour les installations Docker.

Vérifier son instance actuelle

Pour une installation Docker Compose :

docker compose ps

Pour obtenir l’image et la version du conteneur :

docker compose images

Il faut également identifier l’architecture réelle : instance unique, PostgreSQL, Redis, workers, stockage externe, reverse proxy, etc.

Mettre à jour vers une version 2.x récente

Au 29 octobre 2026, le dépôt GitHub officiel indique notamment une version stable 2.45.6.

L’intérêt de rester temporairement sur la branche 2.x est de disposer d’une version récente du Migration Report sans basculer immédiatement vers la v3.

Je recommande de figer une version précise de l’image Docker plutôt que d’utiliser un tag latest pour ce type d’opération.

Examiner toutes les incompatibilités

Dans le Migration Report, il faut traiter les problèmes de workflows et les problèmes d’instance.

Pour les corrections automatiques, il faut contrôler la nouvelle version produite, puis la tester avant publication.

Sur une grosse instance, je commencerais par les workflows qui exécutent des actions critiques : paiements, synchronisations CRM, mouvements de données, mises à jour de bases et opérations déclenchées par des agents IA.

Sauvegarder toute l’installation

La sauvegarde doit couvrir les données nécessaires à une restauration complète, pas seulement les exports JSON des workflows.

Dans une installation auto-hébergée, cela comprend généralement la base de données, les volumes persistants, les secrets, les variables d’environnement et les éventuels stockages de fichiers.

Pour PostgreSQL, une sauvegarde logique peut par exemple être réalisée avec pg_dump.

# Exemple : sauvegarde logique PostgreSQL
# Adapter les noms de conteneur, base et utilisateur.

docker exec postgres 
  pg_dump -U n8n -d n8n -Fc 
  > sauvegarde_n8n.dump

Ce code est uniquement un exemple pour une base PostgreSQL configurée avec ces noms. Il ne sauvegarde ni les volumes Docker ni les secrets.

Je recommande également de vérifier que la sauvegarde peut réellement être restaurée sur une instance isolée.

Tester la migration sur une copie de l’instance

Une instance de staging doit reproduire suffisamment fidèlement la production : mêmes versions de services, configuration comparable et workflows représentatifs.

Il faut aussi éviter qu’elle déclenche des actions réelles.

Une instance de test qui conserve les webhooks, les planifications et les credentials de production peut, par exemple, envoyer des emails, déclencher des facturations ou modifier des données dans les systèmes métier.

Pour cette raison, je désactiverais ou isolerais les sorties sensibles avant de lancer les tests.

Valider les résultats métier

Je ne me contenterais pas d’observer des exécutions affichées comme réussies.

Je comparerais les résultats obtenus avec ceux de la version 2.x : nombre d’items, données transformées, écritures en base, réponses API, fichiers produits et notifications envoyées.

L’objectif n’est pas simplement d’obtenir des workflows verts dans l’interface, mais de confirmer que les automatisations produisent toujours les résultats attendus.

Voici une checklist que vous pouvez utiliser directement.

Checklist de migration n8n 3.0

0/9Mettre à jour l’instance vers une version 2.x récenteExaminer les deux onglets du Migration ReportCorriger ou qualifier les incompatibilitésVérifier les nœuds communautaires et les credentialsSauvegarder base, volumes, configuration et secretsRestaurer une copie dans un environnement de testTester les workflows métier et les agents IAValider les résultats et les performancesPréparer une fenêtre de déploiement en production

Réinitialiser Copier

9. Peut-on revenir de n8n 3.0 à n8n 2.x ?

C’est l’avertissement qu’il ne faut surtout pas négliger.

n8n ne prend pas en charge le retour direct de la version 3.x vers la version 2.x.

Une fois la migration effectuée, la méthode de retour consiste à restaurer une sauvegarde antérieure.

Cela implique deux conséquences pratiques.

D’abord, remplacer simplement l’image Docker 3.x par une image 2.x ne constitue pas une procédure de rollback valide. Les modifications de schéma ou de données effectuées pendant la migration peuvent rendre la base incompatible avec l’ancienne version.

Ensuite, restaurer une sauvegarde implique potentiellement de perdre les modifications réalisées après cette sauvegarde.

Je traiterais donc la migration comme une opération de déploiement avec une procédure de restauration documentée.

Il n’y a aucune raison de précipiter le passage en v3 sur un environnement critique : n8n annonce maintenir la branche 2.x pendant 12 mois après la publication stable de la version 3, pour les correctifs de sécurité et les bugs critiques.

Les nouvelles fonctionnalités seront, en revanche, développées exclusivement sur la branche 3.x à partir de cette sortie stable. n8n Help Center

10. Faut-il passer à n8n 3.0 dès maintenant ?

Pour une instance de production qui fonctionne correctement, je ne vois aucune raison technique de passer immédiatement sur la bêta.

n8n 3.0 apporte des changements structurels intéressants, mais la publication officielle ne fournit pas de benchmarks permettant de mesurer un gain général de performances ou de quantifier une amélioration de stabilité.

Je ne présenterais donc pas cette version comme un n8n « plus rapide de X % ». Ce serait inventer des résultats qui n’ont pas été publiés.

En revanche, certains changements vont dans le bon sens : meilleure séparation des exécutions en mode queue, limites de sécurité plus restrictives, abandon de composants anciens et homogénéisation des déploiements auto-hébergés.

Le principal intérêt aujourd’hui consiste à préparer la migration, pas à se précipiter.

Pour les nouvelles installations destinées à la production, je resterais sur la dernière version stable de la branche 2.x tant que la 3.x stable n’est pas disponible et suffisamment validée pour le projet concerné.

Pour les instances existantes, je commencerais dès maintenant par le Migration Report. Il permet d’identifier les travaux à prévoir sans prendre le risque d’une montée de version prématurée.

FAQ : les questions importantes sur n8n 3.0

n8n 3.0 est-il disponible en version stable ?

Non, au 29 octobre 2026, n8n 3.0 est disponible en bêta depuis le 27 octobre. La version stable est annoncée pour début décembre 2026, sous réserve de modification du calendrier.

Est-ce que mes workflows n8n 2.x fonctionneront en version 3 ?

Beaucoup pourront continuer à fonctionner, mais pas nécessairement tous. Plusieurs anciens nœuds et certains comportements sont supprimés ou modifiés. Le Migration Report permet d’identifier les incompatibilités connues.

Le rapport de migration est-il disponible dans n8n Community ?

Oui. Il est disponible à partir de n8n 2.39 dans les paramètres, y compris dans l’édition Community auto-hébergée.

Est-ce que n8n 3.0 supprime les agents IA ?

Non. Ce sont certains anciens modes AI Agent et composants historiques qui sont retirés. Les fonctionnalités d’automatisation utilisant l’IA restent présentes.

Puis-je installer n8n 3.0 avec npm ?

Non. Les installations auto-hébergées par npm ou npx ne sont plus prises en charge. Docker devient la méthode de déploiement prise en charge. Kubernetes et Helm restent compatibles.

Peut-on revenir en version 2.x après une migration ?

Il n’existe pas de procédure de downgrade direct prise en charge. Il faut restaurer une sauvegarde réalisée avant la migration.

Quand le support de n8n 2.x s’arrêtera-t-il ?

n8n annonce 12 mois de maintenance après la sortie stable de la version 3. Pendant cette période, la branche 2.x recevra des correctifs de sécurité et des corrections de bugs critiques, mais pas les nouvelles fonctionnalités.

n8n 3.0 marque surtout une étape de maturité

Avec cette version, n8n cherche à consolider son architecture plutôt qu’à multiplier les nouveautés visibles.

Je trouve ce choix cohérent avec l’évolution de ses usages. Lorsqu’une plateforme sert à automatiser des processus métier, synchroniser des bases de données, orchestrer des API et faire fonctionner des agents IA, sa fiabilité compte autant que le nombre de nœuds disponibles dans l’éditeur.

Mais une nouvelle version majeure reste une opération technique. Même lorsque l’éditeur paraît presque inchangé, les conséquences sur les workflows, les données et l’infrastructure peuvent être importantes.

Ma priorité serait donc simple : mettre à jour vers une version 2.x récente, consulter le Migration Report et commencer à corriger les incompatibilités. Le passage à la version 3 pourra ensuite se faire sur la base de tests, plutôt que sur la promesse d’une nouvelle version.

Sources officielles et documentation technique

Les références principales pour vérifier les changements et suivre les évolutions de n8n 3.0 :

• Annonce officielle n8n 3.0 — 27 octobre 2026
• Inventaire officiel des breaking changes de n8n 3.0
• Guide du Migration Report v3
• Centre d’aide n8n — Préparer la migration
• Versions publiées sur le dépôt GitHub de n8n
• Annonce et échanges avec l’équipe n8n sur le forum officiel

Franck Scandolera

Dev d’applications métier · Data Engineer · Automatisation IA

Clients : Logis Hôtels, Yelloh Village, BazarChic, FFF, Texdecor…

• Apps & agents IA : Node.js, Python, API, RAG, OpenAI, Mistral, Claude
• Data Engineering : BigQuery, Snowflake, PostgreSQL, ClickHouse, dbt, Airflow, Dataform, Looker, Power BI, Metabase
• Automatisation IA : n8n, Apps Script, scraping, API, LLM
• Tracking & perf Web : GA4, GTM server, Matomo, Piano, Tealium, CAPI, Core Web Vitals