n8n 3 : breaking changes, impacts et préparation de la migration

n8n prépare une nouvelle version majeure. Sa sortie est actuellement prévue pour octobre 2026, sans date plus précise annoncée publiquement.

n8n 3.0 ne se présente pas, pour le moment, comme une avalanche de nouvelles fonctionnalités. Le sujet principal est ailleurs : renforcer la sécurité, simplifier la configuration et supprimer des composants historiques devenus obsolètes.

Pour un utilisateur récent de n8n Cloud, une bonne partie de ces changements devrait être transparente. Pour une instance self-hosted ancienne, avec des workflows construits depuis plusieurs années, la migration mérite en revanche un vrai audit.

Au 3 août 2026, n8n a confirmé quatre familles de breaking changes :

• le déploiement des instances self-hosted ;
• la suppression d’anciens nœuds et helpers ;
• le renforcement de la sécurité ;
• l’arrêt de plusieurs fonctionnalités historiques.

La documentation reste volontairement partielle. n8n précise qu’elle sera complétée avec les détails et les guides de migration à mesure que la sortie approchera. Il faut donc considérer cet article comme un état vérifié des informations disponibles, pas comme la documentation définitive de n8n 3.0.

Ce que l’on sait réellement de n8n 3.0

n8n présente cette version majeure comme une étape destinée à rendre sa plateforme plus sûre, plus fiable et mieux adaptée aux environnements de production.

Découvrez égalementComment créer un agent IA de tracking Analytics avec n8n ?

La formulation officielle est assez claire : n8n 3.0 doit apporter des améliorations de sécurité et nettoyer les fonctions dépréciées accumulées au fil des versions.

Ce positionnement explique la nature des premiers changements annoncés. Il ne s’agit pas encore d’une liste de nouveautés métier. Il s’agit surtout de supprimer des méthodes d’installation, des nœuds et des comportements que n8n ne souhaite plus maintenir.

Cette liste n’est pas présentée par n8n comme définitive. D’autres changements peuvent encore être ajoutés avant la sortie.

Docker devient obligatoire pour le self-hosting

C’est probablement le changement d’infrastructure le plus important.

À partir de n8n 3.0, une installation self-hosted devra fonctionner dans un déploiement basé sur Docker. Les installations lancées directement avec npm ou npx n8n ne seront plus prises en charge.

Découvrez égalementQuelles tâches automatiser avec n8n et l’IA ?

Aujourd’hui, n8n documente encore npm et Docker parmi les modes d’installation. La version 3 mettra fin à cette coexistence pour les déploiements self-hosted pris en charge.

Qui est concerné ?

Vous êtes directement concerné si votre instance est actuellement lancée avec une commande proche de celle-ci :

npx n8n

ou si n8n est installé globalement avec npm :

npm install -g n8n
n8n start

Une instance déjà exécutée dans Docker, Docker Compose, Kubernetes ou une plateforme qui déploie n8n à partir de son image Docker n’est pas concernée par la suppression de npm elle-même.

Cela ne garantit pas pour autant que la mise à niveau sera transparente. Les variables d’environnement, volumes, bases de données, workers, task runners et nœuds communautaires devront toujours être vérifiés.

Ce que recommande actuellement n8n

Découvrez égalementAnthropic Agents, n8n ou Trigger.dev lequel choisir ?

n8n demande aux utilisateurs de npm ou npx n8n de préparer leur passage vers Docker avant la mise à niveau. Pour les installations locales, Docker Compose est présenté comme la voie qui devrait être la plus simple.

Le guide pas-à-pas spécifique à cette migration n’est pas encore publié. C’est important : on connaît la destination, mais pas encore la procédure officielle détaillée.

Et Coolify ?

Coolify déploie normalement n8n sous forme de conteneur. Une instance n8n installée dans Coolify est donc déjà dans la logique imposée par n8n 3.0.

Il restera néanmoins nécessaire de contrôler :

• l’image utilisée ;
• le tag de version ;
• les volumes persistants ;
• la base PostgreSQL ou SQLite ;
• les variables d’environnement ;
• la stratégie de sauvegarde ;
• le déploiement éventuel de workers et de task runners.

Le breaking change annoncé porte sur l’abandon des installations npm et npx. n8n n’a pas annoncé la fin de Docker Compose, de Kubernetes ou des plateformes d’orchestration de conteneurs.

Suppression des nœuds Function et Function Item

Les anciens nœuds Function et Function Item seront supprimés dans n8n 3.0.

Ils ont déjà été remplacés depuis longtemps par le nœud Code, qui regroupe leurs deux modes d’exécution.

La correspondance annoncée est la suivante :

Le changement ne signifie pas que JavaScript disparaît de n8n. C’est le contraire : le nœud Code devient l’unique nœud généraliste prévu pour exécuter du code personnalisé à la place des anciens nœuds Function.

Function vers Code

L’ancien nœud Function exécutait généralement le code une seule fois pour l’ensemble des items reçus.

Dans le nœud Code, il faut sélectionner :

Run Once for All Items

Exemple de logique traitant tous les items :

const items = $input.all();

return items.map((item) => ({
  json: {
    ...item.json,
    email_normalise: item.json.email?.trim().toLowerCase() ?? null,
  },
}));

Function Item vers Code

L’ancien nœud Function Item traitait chaque item séparément.

Dans le nœud Code, l’équivalent est :

Run Once for Each Item

Exemple :

return {
  json: {
    ...$json,
    email_normalise: $json.email?.trim().toLowerCase() ?? null,
  },
};

Attention à la simple correspondance des modes

Remplacer le type de nœud ne suffit pas toujours à garantir un comportement identique.

Avant de considérer la migration comme terminée, il faut tester :

• le nombre d’items retournés ;
• leur structure JSON ;
• la présence des données binaires ;
• les références vers des items précédents ;
• les branches d’erreur ;
• les expressions utilisées dans les nœuds suivants.

Ce sont des recommandations de contrôle, pas des breaking changes supplémentaires annoncés par n8n.

Suppression du nœud Item Lists

Le nœud historique Item Lists sera également supprimé.

Ce nœud regroupait plusieurs opérations de transformation de listes dans une seule interface. n8n a depuis séparé ces opérations dans des nœuds spécialisés.

Le remplaçant dépend donc de l’opération utilisée dans chaque workflow.

Cette table reprend les alternatives mentionnées dans la documentation n8n 3.0.

Il n’existe donc pas de remplacement automatique unique du type :

Item Lists devient Aggregate.

Ce serait faux.

Un nœud Item Lists configuré pour trier doit être remplacé par Sort. Un autre utilisé pour éclater un tableau doit être remplacé par Split Out. L’audit doit porter sur l’opération configurée, pas seulement sur le nom du nœud.

L’ancien comportement du nœud Execute Workflow disparaît

n8n indique que l’ancien comportement du nœud Execute Workflow sera supprimé.

Ce nœud est aujourd’hui généralement présenté comme Execute Sub-workflow dans l’interface. Il permet à un workflow principal d’appeler un autre workflow.

La première documentation publique ne précise pas encore totalement quel comportement historique sera supprimé ni comment tous les anciens workflows seront migrés.

Une pull request récente du dépôt n8n mentionne toutefois explicitement la dépréciation du mode :

Run once for each item

dans le nœud Execute Sub-workflow.

Cette information vient du dépôt officiel, mais la documentation de migration n’est pas encore assez complète pour affirmer que ce mode constitue à lui seul l’intégralité du breaking change. Il faut donc attendre les précisions de n8n avant de décrire exactement le comportement final.

Ce qu’il faut déjà auditer

Repérez les workflows qui appellent des sous-workflows et vérifiez :

• le mode d’exécution sélectionné ;
• le nombre d’appels effectués ;
• la structure des données transmises ;
• le comportement en cas de plusieurs items ;
• l’attente ou non de la fin du sous-workflow ;
• les données renvoyées au workflow parent.

Je ne conseille pas de modifier ces workflows sur la seule base de l’annonce actuelle. Il manque encore le guide officiel détaillant la migration de l’ancien comportement.

Suppression de $getPairedItem

Le helper d’expression déprécié $getPairedItem sera supprimé.

Pour comprendre le sujet, il faut revenir à l’item linking.

n8n traite les données sous forme d’items. Lorsqu’un nœud transforme, divise, regroupe ou crée des items, n8n doit conserver le lien entre les données de sortie et les données reçues précédemment.

Sans cette relation, une expression qui cherche l’item correspondant dans un nœud antérieur peut devenir ambiguë ou échouer.

n8n recommande désormais d’utiliser son mécanisme standard d’item linking, notamment :

• la propriété pairedItem lorsque du code crée manuellement des items ;
• l’expression $("Nom du nœud").item pour retrouver l’item lié ;
• les mécanismes automatiques de liaison lorsque le nœud peut préserver lui-même la correspondance.

La documentation destinée aux créateurs de nœuds précise que pairedItem sert à indiquer de quel item d’entrée provient chaque item de sortie. Elle indique également que l’absence de cette information peut casser les expressions exécutées dans les nœuds suivants.

Exemple avec pairedItem

const items = $input.all();

return items.map((item, index) => ({
  json: {
    nom: item.json.nom,
    statut: "traite",
  },
  pairedItem: {
    item: index,
  },
}));

Ici, chaque item retourné reste lié à l’item d’entrée correspondant.

La suppression de $getPairedItem concerne surtout :

• les expressions historiques qui l’utilisent encore ;
• certains anciens nœuds personnalisés ;
• les Code nodes qui construisent des items sans préserver correctement leur liaison ;
• les workflows complexes comportant des agrégations, divisions ou regroupements d’items.

Renforcement des règles de sécurité

n8n annonce trois changements de sécurité pour la version 3 :

• un traitement plus strict des noms de ressources considérés comme risqués ;
• un comportement plus sécurisé pour les credentials ;
• la rotation des clés activée par défaut.

À ce stade, la documentation ne donne pas encore suffisamment de détails pour expliquer précisément :

• quels noms de ressources seront interdits ou transformés ;
• quels comportements des credentials vont changer ;
• quelles clés seront concernées ;
• comment se déroulera la rotation ;
• quelles variables permettront éventuellement de contrôler ces mécanismes.

n8n résume ces orientations, mais renvoie les détails à de futures mises à jour de la documentation.

Il serait donc prématuré d’inventer un scénario de migration précis.

Ce que l’on peut faire dès maintenant

n8n propose déjà un audit de sécurité natif pour détecter plusieurs catégories de risques :

• credentials inutilisés ;
• expressions dans les requêtes SQL ;
• nœuds accédant au système de fichiers ;
• nœuds officiels considérés comme risqués ;
• nœuds communautaires et personnalisés ;
• webhooks non protégés ;
• paramètres de sécurité manquants ;
• instance obsolète.

L’audit peut être lancé avec la commande :

n8n audit

Il peut également être exécuté par l’API ou depuis le nœud n8n.

Cet audit ne remplace pas le futur outil de migration vers n8n 3. Il permet néanmoins d’identifier une partie des éléments sensibles avant la mise à niveau.

Chat Hub sera retiré

n8n annonce le retrait de Chat Hub dans la version 3.

Il faut distinguer Chat Hub des workflows utilisant un Chat Trigger, des agents IA ou une interface de chat intégrée à un site.

La page actuelle parle du produit ou de la fonctionnalité Chat Hub. Elle ne dit pas que tous les workflows conversationnels, Chat Triggers ou agents IA seront supprimés.

En l’absence de précision supplémentaire, il ne faut donc pas transformer « Chat Hub sera retiré » en « n8n supprime son système de chat » ou « les agents IA ne fonctionneront plus ». Rien dans la source actuelle ne permet de l’affirmer.

n8n indique qu’une solution de migration ou une alternative sera documentée lorsqu’elle existe. Cette alternative n’est pas encore détaillée pour Chat Hub.

L’import d’un workflow depuis une URL disparaît

L’éditeur n8n ne permettra plus d’importer directement un workflow depuis une URL.

Les autres méthodes d’import resteront disponibles :

• copier-coller le JSON ;
• importer un fichier depuis le menu de l’éditeur ;
• utiliser la ligne de commande ;
• utiliser l’API publique.

La suppression concerne donc une méthode précise de l’éditeur, pas l’import de workflows dans son ensemble.

Pour une équipe qui maintient une bibliothèque de workflows, le changement est relativement simple : distribuer des fichiers JSON, utiliser le copier-coller ou industrialiser le déploiement par API.

Les nœuds non fonctionnels seront supprimés

n8n annonce également la suppression des non-functional nodes.

La documentation actuelle ne fournit pas encore la liste exacte de ces nœuds.

On ne peut donc pas affirmer aujourd’hui quelles intégrations disparaîtront, combien de workflows seront concernés ou si tous les nœuds visés disposent d’un remplaçant.

Il faut attendre la publication de la liste officielle.

C’est typiquement le genre d’information pour laquelle une formulation vague doit rester vague. « Des nœuds non fonctionnels seront supprimés » est confirmé. Une liste inventée à partir d’anciens nœuds dépréciés ne le serait pas.

Ce que n8n 3.0 ne permet pas encore d’affirmer

À ce stade, aucune source officielle consultée ne permet de confirmer :

• la date exacte de sortie ;
• le numéro de la première version stable, au-delà de la famille 3.0 ;
• une procédure complète de migration npm vers Docker ;
• la liste exhaustive des nœuds retirés ;
• le détail des nouvelles règles appliquées aux credentials ;
• le fonctionnement exact de la rotation des clés ;
• toutes les modifications du nœud Execute Sub-workflow ;
• un changement global concernant les agents IA ;
• une incompatibilité générale avec Coolify ou Kubernetes ;
• une modification obligatoire de toutes les bases SQLite ;
• la suppression des nœuds communautaires ;
• la disparition du Chat Trigger.

Le dépôt de documentation montre d’ailleurs que la page actuelle a été enrichie le 31 juillet 2026 à partir de quatre familles de changements annoncées. Le résumé de la pull request précise également que certaines recommandations de remplacement ont été déduites de la documentation existante, puis intégrées à la page officielle. Cela confirme le caractère encore progressif de cette documentation.

Comment préparer une instance sans attendre octobre

Il ne faut pas installer une future version majeure en aveugle sur une instance de production. Ce n’est pas propre à n8n 3. C’est une règle élémentaire pour tout système qui exécute des automatisations métier.

Je commencerais par un inventaire simple.

1. Identifier le mode de déploiement

Vérifiez si n8n fonctionne avec :

• npm ou npx ;
• Docker ;
• Docker Compose ;
• Coolify ;
• Kubernetes ;
• une offre Cloud gérée par n8n.

Les installations npm et npx sont les seules explicitement annoncées comme non prises en charge dans n8n 3.0.

2. Rechercher les nœuds historiques

Dans les exports JSON de vos workflows, recherchez les types correspondant aux anciens nœuds :

n8n-nodes-base.function
n8n-nodes-base.functionItem
n8n-nodes-base.itemLists

La présence de ces chaînes permet de repérer les workflows susceptibles de nécessiter une migration.

Exemple de recherche dans un répertoire d’exports :

grep -R \
  -e '"n8n-nodes-base.function"' \
  -e '"n8n-nodes-base.functionItem"' \
  -e '"n8n-nodes-base.itemLists"' \
  ./workflows

Cette commande est une méthode d’audit proposée ici. Elle n’est pas présentée comme un outil officiel n8n.

3. Rechercher $getPairedItem

grep -R '\$getPairedItem' ./workflows

Chaque occurrence devra être revue et remplacée par le mécanisme moderne d’item linking adapté au workflow.

4. Inventorier les sous-workflows

Repérez les workflows contenant Execute Workflow ou Execute Sub-workflow.

Ne les modifiez pas au hasard. Documentez :

• le workflow appelé ;
• le mode configuré ;
• la quantité d’items reçue ;
• la quantité d’exécutions attendue ;
• le résultat renvoyé.

Ces informations permettront de tester le futur comportement de n8n 3 dès qu’il sera précisément documenté.

5. Exporter les workflows

Un export des workflows ne constitue pas une sauvegarde complète de l’instance, mais il facilite :

• la comparaison avant et après migration ;
• la recherche dans les JSON ;
• le retour manuel vers une version antérieure d’un workflow ;
• les tests sur une instance séparée.

6. Sauvegarder la base et les données persistantes

Pour une instance Docker, il faut identifier tout ce qui persiste en dehors du conteneur :

• base PostgreSQL ou fichier SQLite ;
• dossier .n8n ;
• données binaires locales ;
• fichiers utilisés par les workflows ;
• clés de chiffrement ;
• variables d’environnement ;
• fichiers Docker Compose ;
• configurations du reverse proxy.

Le conteneur est remplaçable. Les volumes et la base ne le sont pas.

7. Tester sur une copie

La méthode la plus sûre consiste à restaurer une copie de l’instance dans un environnement isolé, puis à y installer la version candidate de n8n 3.

Il faut alors contrôler au minimum :

• le démarrage de l’instance ;
• l’accès aux credentials ;
• l’ouverture des workflows ;
• les triggers ;
• les webhooks ;
• les sous-workflows ;
• les Code nodes ;
• les fichiers binaires ;
• les nœuds communautaires ;
• les agents et outils IA ;
• les exécutions planifiées ;
• les workers et files d’attente ;
• les logs et erreurs.

8. Ne pas mettre à jour tous les composants séparément

Pour les architectures utilisant plusieurs composants n8n, la documentation recommande déjà de maintenir les composants principaux, workers et runners sur la même version, notamment pour éviter les incompatibilités de protocole.

Cette règle devient encore plus importante lors d’un changement de version majeure.

Tableau de préparation

Faut-il migrer dès la sortie ?

Pour une instance de production, je ne migrerais pas le jour de la sortie sans validation préalable.

n8n 3.0 est, par définition, une version majeure comportant des breaking changes. Le bon moment dépendra de quatre éléments :

• la publication du guide de migration final ;
• la disponibilité d’une version stable ;
• le résultat des tests sur une copie ;
• la présence ou non de composants supprimés dans vos workflows.

Une instance récente, déjà sous Docker et sans nœuds historiques, demandera probablement moins de travail.

Une instance ancienne, avec des centaines de workflows, des nœuds communautaires, des Code nodes complexes et plusieurs workers, mérite une véritable recette.

Ce que je retiens

n8n 3.0 ne révolutionne pas encore l’interface visible. Il remet de l’ordre dans les fondations.

Le changement le plus clair concerne le self-hosting : Docker deviendra obligatoire et les installations npm ou npx ne seront plus prises en charge.

Côté workflows, les anciens nœuds Function, Function Item et Item Lists doivent disparaître. $getPairedItem suivra le même chemin. Le nœud Execute Sub-workflow perdra également un ancien comportement, encore insuffisamment documenté.

Plusieurs fonctions seront retirées, dont Chat Hub et l’import depuis une URL. Des règles de sécurité plus strictes sont annoncées, mais leurs détails ne sont pas encore publiés.

Le piège serait de combler ces zones vides par des suppositions.

Pour l’instant, la bonne stratégie est plus simple :

• migrer les anciens nœuds déjà identifiés ;
• sortir de npm ou npx ;
• auditer les sous-workflows ;
• sauvegarder proprement l’instance ;
• préparer un environnement de test ;
• suivre les mises à jour de la documentation officielle.

Cet article sera mis à jour à mesure que n8n précisera les changements de la version 3.0.

Dernière mise à jour : 3 août 2026.

n8n 3.0 : breaking changes, impacts et préparation de la migration

n8n prépare une nouvelle version majeure. Sa sortie est actuellement prévue pour octobre 2026, sans date plus précise annoncée publiquement.

n8n 3.0 ne se présente pas, pour le moment, comme une avalanche de nouvelles fonctionnalités. Le sujet principal est ailleurs : renforcer la sécurité, simplifier la configuration et supprimer des composants historiques devenus obsolètes.

Pour un utilisateur récent de n8n Cloud, une bonne partie de ces changements devrait être transparente. Pour une instance self-hosted ancienne, avec des workflows construits depuis plusieurs années, la migration mérite en revanche un vrai audit.

Au 3 août 2026, n8n a confirmé quatre familles de breaking changes :

• le déploiement des instances self-hosted ;
• la suppression d’anciens nœuds et helpers ;
• le renforcement de la sécurité ;
• l’arrêt de plusieurs fonctionnalités historiques.

La documentation reste volontairement partielle. n8n précise qu’elle sera complétée avec les détails et les guides de migration à mesure que la sortie approchera. Il faut donc considérer cet article comme un état vérifié des informations disponibles, pas comme la documentation définitive de n8n 3.0.

Ce que l’on sait réellement de n8n 3.0

n8n présente cette version majeure comme une étape destinée à rendre sa plateforme plus sûre, plus fiable et mieux adaptée aux environnements de production.

La formulation officielle est assez claire : n8n 3.0 doit apporter des améliorations de sécurité et nettoyer les fonctions dépréciées accumulées au fil des versions.

Ce positionnement explique la nature des premiers changements annoncés. Il ne s’agit pas encore d’une liste de nouveautés métier. Il s’agit surtout de supprimer des méthodes d’installation, des nœuds et des comportements que n8n ne souhaite plus maintenir.

Cette liste n’est pas présentée par n8n comme définitive. D’autres changements peuvent encore être ajoutés avant la sortie.

Docker devient obligatoire pour le self-hosting

C’est probablement le changement d’infrastructure le plus important.

À partir de n8n 3.0, une installation self-hosted devra fonctionner dans un déploiement basé sur Docker. Les installations lancées directement avec npm ou npx n8n ne seront plus prises en charge.

Aujourd’hui, n8n documente encore npm et Docker parmi les modes d’installation. La version 3 mettra fin à cette coexistence pour les déploiements self-hosted pris en charge.

Qui est concerné ?

Vous êtes directement concerné si votre instance est actuellement lancée avec une commande proche de celle-ci :

npx n8n

ou si n8n est installé globalement avec npm :

npm install -g n8n
n8n start

Une instance déjà exécutée dans Docker, Docker Compose, Kubernetes ou une plateforme qui déploie n8n à partir de son image Docker n’est pas concernée par la suppression de npm elle-même.

Cela ne garantit pas pour autant que la mise à niveau sera transparente. Les variables d’environnement, volumes, bases de données, workers, task runners et nœuds communautaires devront toujours être vérifiés.

Ce que recommande actuellement n8n

n8n demande aux utilisateurs de npm ou npx n8n de préparer leur passage vers Docker avant la mise à niveau. Pour les installations locales, Docker Compose est présenté comme la voie qui devrait être la plus simple.

Le guide pas-à-pas spécifique à cette migration n’est pas encore publié. C’est important : on connaît la destination, mais pas encore la procédure officielle détaillée.

Et Coolify ?

Coolify déploie normalement n8n sous forme de conteneur. Une instance n8n installée dans Coolify est donc déjà dans la logique imposée par n8n 3.0.

Il restera néanmoins nécessaire de contrôler :

• l’image utilisée ;
• le tag de version ;
• les volumes persistants ;
• la base PostgreSQL ou SQLite ;
• les variables d’environnement ;
• la stratégie de sauvegarde ;
• le déploiement éventuel de workers et de task runners.

Le breaking change annoncé porte sur l’abandon des installations npm et npx. n8n n’a pas annoncé la fin de Docker Compose, de Kubernetes ou des plateformes d’orchestration de conteneurs.

Suppression des nœuds Function et Function Item

Les anciens nœuds Function et Function Item seront supprimés dans n8n 3.0.

Ils ont déjà été remplacés depuis longtemps par le nœud Code, qui regroupe leurs deux modes d’exécution.

La correspondance annoncée est la suivante :

Le changement ne signifie pas que JavaScript disparaît de n8n. C’est le contraire : le nœud Code devient l’unique nœud généraliste prévu pour exécuter du code personnalisé à la place des anciens nœuds Function.

Function vers Code

L’ancien nœud Function exécutait généralement le code une seule fois pour l’ensemble des items reçus.

Dans le nœud Code, il faut sélectionner :

Run Once for All Items

Exemple de logique traitant tous les items :

const items = $input.all();

return items.map((item) => ({
  json: {
    ...item.json,
    email_normalise: item.json.email?.trim().toLowerCase() ?? null,
  },
}));

Function Item vers Code

L’ancien nœud Function Item traitait chaque item séparément.

Dans le nœud Code, l’équivalent est :

Run Once for Each Item

Exemple :

return {
  json: {
    ...$json,
    email_normalise: $json.email?.trim().toLowerCase() ?? null,
  },
};

Attention à la simple correspondance des modes

Remplacer le type de nœud ne suffit pas toujours à garantir un comportement identique.

Avant de considérer la migration comme terminée, il faut tester :

• le nombre d’items retournés ;
• leur structure JSON ;
• la présence des données binaires ;
• les références vers des items précédents ;
• les branches d’erreur ;
• les expressions utilisées dans les nœuds suivants.

Ce sont des recommandations de contrôle, pas des breaking changes supplémentaires annoncés par n8n.

Suppression du nœud Item Lists

Le nœud historique Item Lists sera également supprimé.

Ce nœud regroupait plusieurs opérations de transformation de listes dans une seule interface. n8n a depuis séparé ces opérations dans des nœuds spécialisés.

Le remplaçant dépend donc de l’opération utilisée dans chaque workflow.

Cette table reprend les alternatives mentionnées dans la documentation n8n 3.0.

Il n’existe donc pas de remplacement automatique unique du type :

Item Lists devient Aggregate.

Ce serait faux.

Un nœud Item Lists configuré pour trier doit être remplacé par Sort. Un autre utilisé pour éclater un tableau doit être remplacé par Split Out. L’audit doit porter sur l’opération configurée, pas seulement sur le nom du nœud.

L’ancien comportement du nœud Execute Workflow disparaît

n8n indique que l’ancien comportement du nœud Execute Workflow sera supprimé.

Ce nœud est aujourd’hui généralement présenté comme Execute Sub-workflow dans l’interface. Il permet à un workflow principal d’appeler un autre workflow.

La première documentation publique ne précise pas encore totalement quel comportement historique sera supprimé ni comment tous les anciens workflows seront migrés.

Une pull request récente du dépôt n8n mentionne toutefois explicitement la dépréciation du mode :

Run once for each item

dans le nœud Execute Sub-workflow.

Cette information vient du dépôt officiel, mais la documentation de migration n’est pas encore assez complète pour affirmer que ce mode constitue à lui seul l’intégralité du breaking change. Il faut donc attendre les précisions de n8n avant de décrire exactement le comportement final.

Ce qu’il faut déjà auditer

Repérez les workflows qui appellent des sous-workflows et vérifiez :

• le mode d’exécution sélectionné ;
• le nombre d’appels effectués ;
• la structure des données transmises ;
• le comportement en cas de plusieurs items ;
• l’attente ou non de la fin du sous-workflow ;
• les données renvoyées au workflow parent.

Je ne conseille pas de modifier ces workflows sur la seule base de l’annonce actuelle. Il manque encore le guide officiel détaillant la migration de l’ancien comportement.

Suppression de $getPairedItem

Le helper d’expression déprécié $getPairedItem sera supprimé.

Pour comprendre le sujet, il faut revenir à l’item linking.

n8n traite les données sous forme d’items. Lorsqu’un nœud transforme, divise, regroupe ou crée des items, n8n doit conserver le lien entre les données de sortie et les données reçues précédemment.

Sans cette relation, une expression qui cherche l’item correspondant dans un nœud antérieur peut devenir ambiguë ou échouer.

n8n recommande désormais d’utiliser son mécanisme standard d’item linking, notamment :

• la propriété pairedItem lorsque du code crée manuellement des items ;
• l’expression $("Nom du nœud").item pour retrouver l’item lié ;
• les mécanismes automatiques de liaison lorsque le nœud peut préserver lui-même la correspondance.

La documentation destinée aux créateurs de nœuds précise que pairedItem sert à indiquer de quel item d’entrée provient chaque item de sortie. Elle indique également que l’absence de cette information peut casser les expressions exécutées dans les nœuds suivants.

Exemple avec pairedItem

const items = $input.all();

return items.map((item, index) => ({
  json: {
    nom: item.json.nom,
    statut: "traite",
  },
  pairedItem: {
    item: index,
  },
}));

Ici, chaque item retourné reste lié à l’item d’entrée correspondant.

La suppression de $getPairedItem concerne surtout :

• les expressions historiques qui l’utilisent encore ;
• certains anciens nœuds personnalisés ;
• les Code nodes qui construisent des items sans préserver correctement leur liaison ;
• les workflows complexes comportant des agrégations, divisions ou regroupements d’items.

Renforcement des règles de sécurité

n8n annonce trois changements de sécurité pour la version 3 :

• un traitement plus strict des noms de ressources considérés comme risqués ;
• un comportement plus sécurisé pour les credentials ;
• la rotation des clés activée par défaut.

À ce stade, la documentation ne donne pas encore suffisamment de détails pour expliquer précisément :

• quels noms de ressources seront interdits ou transformés ;
• quels comportements des credentials vont changer ;
• quelles clés seront concernées ;
• comment se déroulera la rotation ;
• quelles variables permettront éventuellement de contrôler ces mécanismes.

n8n résume ces orientations, mais renvoie les détails à de futures mises à jour de la documentation.

Il serait donc prématuré d’inventer un scénario de migration précis.

Ce que l’on peut faire dès maintenant

n8n propose déjà un audit de sécurité natif pour détecter plusieurs catégories de risques :

• credentials inutilisés ;
• expressions dans les requêtes SQL ;
• nœuds accédant au système de fichiers ;
• nœuds officiels considérés comme risqués ;
• nœuds communautaires et personnalisés ;
• webhooks non protégés ;
• paramètres de sécurité manquants ;
• instance obsolète.

L’audit peut être lancé avec la commande :

n8n audit

Il peut également être exécuté par l’API ou depuis le nœud n8n.

Cet audit ne remplace pas le futur outil de migration vers n8n 3. Il permet néanmoins d’identifier une partie des éléments sensibles avant la mise à niveau.

Chat Hub sera retiré

n8n annonce le retrait de Chat Hub dans la version 3.

Il faut distinguer Chat Hub des workflows utilisant un Chat Trigger, des agents IA ou une interface de chat intégrée à un site.

La page actuelle parle du produit ou de la fonctionnalité Chat Hub. Elle ne dit pas que tous les workflows conversationnels, Chat Triggers ou agents IA seront supprimés.

En l’absence de précision supplémentaire, il ne faut donc pas transformer « Chat Hub sera retiré » en « n8n supprime son système de chat » ou « les agents IA ne fonctionneront plus ». Rien dans la source actuelle ne permet de l’affirmer.

n8n indique qu’une solution de migration ou une alternative sera documentée lorsqu’elle existe. Cette alternative n’est pas encore détaillée pour Chat Hub.

L’import d’un workflow depuis une URL disparaît

L’éditeur n8n ne permettra plus d’importer directement un workflow depuis une URL.

Les autres méthodes d’import resteront disponibles :

• copier-coller le JSON ;
• importer un fichier depuis le menu de l’éditeur ;
• utiliser la ligne de commande ;
• utiliser l’API publique.

La suppression concerne donc une méthode précise de l’éditeur, pas l’import de workflows dans son ensemble.

Pour une équipe qui maintient une bibliothèque de workflows, le changement est relativement simple : distribuer des fichiers JSON, utiliser le copier-coller ou industrialiser le déploiement par API.

Les nœuds non fonctionnels seront supprimés

n8n annonce également la suppression des non-functional nodes.

La documentation actuelle ne fournit pas encore la liste exacte de ces nœuds.

On ne peut donc pas affirmer aujourd’hui quelles intégrations disparaîtront, combien de workflows seront concernés ou si tous les nœuds visés disposent d’un remplaçant.

Il faut attendre la publication de la liste officielle.

C’est typiquement le genre d’information pour laquelle une formulation vague doit rester vague. « Des nœuds non fonctionnels seront supprimés » est confirmé. Une liste inventée à partir d’anciens nœuds dépréciés ne le serait pas.

Ce que n8n 3.0 ne permet pas encore d’affirmer

À ce stade, aucune source officielle consultée ne permet de confirmer :

• la date exacte de sortie ;
• le numéro de la première version stable, au-delà de la famille 3.0 ;
• une procédure complète de migration npm vers Docker ;
• la liste exhaustive des nœuds retirés ;
• le détail des nouvelles règles appliquées aux credentials ;
• le fonctionnement exact de la rotation des clés ;
• toutes les modifications du nœud Execute Sub-workflow ;
• un changement global concernant les agents IA ;
• une incompatibilité générale avec Coolify ou Kubernetes ;
• une modification obligatoire de toutes les bases SQLite ;
• la suppression des nœuds communautaires ;
• la disparition du Chat Trigger.

Le dépôt de documentation montre d’ailleurs que la page actuelle a été enrichie le 31 juillet 2026 à partir de quatre familles de changements annoncées. Le résumé de la pull request précise également que certaines recommandations de remplacement ont été déduites de la documentation existante, puis intégrées à la page officielle. Cela confirme le caractère encore progressif de cette documentation.

Comment préparer une instance sans attendre octobre

Il ne faut pas installer une future version majeure en aveugle sur une instance de production. Ce n’est pas propre à n8n 3. C’est une règle élémentaire pour tout système qui exécute des automatisations métier.

Je commencerais par un inventaire simple.

1. Identifier le mode de déploiement

Vérifiez si n8n fonctionne avec :

• npm ou npx ;
• Docker ;
• Docker Compose ;
• Coolify ;
• Kubernetes ;
• une offre Cloud gérée par n8n.

Les installations npm et npx sont les seules explicitement annoncées comme non prises en charge dans n8n 3.0.

2. Rechercher les nœuds historiques

Dans les exports JSON de vos workflows, recherchez les types correspondant aux anciens nœuds :

n8n-nodes-base.function
n8n-nodes-base.functionItem
n8n-nodes-base.itemLists

La présence de ces chaînes permet de repérer les workflows susceptibles de nécessiter une migration.

Exemple de recherche dans un répertoire d’exports :

grep -R \
  -e '"n8n-nodes-base.function"' \
  -e '"n8n-nodes-base.functionItem"' \
  -e '"n8n-nodes-base.itemLists"' \
  ./workflows

Cette commande est une méthode d’audit proposée ici. Elle n’est pas présentée comme un outil officiel n8n.

3. Rechercher $getPairedItem

grep -R '\$getPairedItem' ./workflows

Chaque occurrence devra être revue et remplacée par le mécanisme moderne d’item linking adapté au workflow.

4. Inventorier les sous-workflows

Repérez les workflows contenant Execute Workflow ou Execute Sub-workflow.

Ne les modifiez pas au hasard. Documentez :

• le workflow appelé ;
• le mode configuré ;
• la quantité d’items reçue ;
• la quantité d’exécutions attendue ;
• le résultat renvoyé.

Ces informations permettront de tester le futur comportement de n8n 3 dès qu’il sera précisément documenté.

5. Exporter les workflows

Un export des workflows ne constitue pas une sauvegarde complète de l’instance, mais il facilite :

• la comparaison avant et après migration ;
• la recherche dans les JSON ;
• le retour manuel vers une version antérieure d’un workflow ;
• les tests sur une instance séparée.

6. Sauvegarder la base et les données persistantes

Pour une instance Docker, il faut identifier tout ce qui persiste en dehors du conteneur :

• base PostgreSQL ou fichier SQLite ;
• dossier .n8n ;
• données binaires locales ;
• fichiers utilisés par les workflows ;
• clés de chiffrement ;
• variables d’environnement ;
• fichiers Docker Compose ;
• configurations du reverse proxy.

Le conteneur est remplaçable. Les volumes et la base ne le sont pas.

7. Tester sur une copie

La méthode la plus sûre consiste à restaurer une copie de l’instance dans un environnement isolé, puis à y installer la version candidate de n8n 3.

Il faut alors contrôler au minimum :

• le démarrage de l’instance ;
• l’accès aux credentials ;
• l’ouverture des workflows ;
• les triggers ;
• les webhooks ;
• les sous-workflows ;
• les Code nodes ;
• les fichiers binaires ;
• les nœuds communautaires ;
• les agents et outils IA ;
• les exécutions planifiées ;
• les workers et files d’attente ;
• les logs et erreurs.

8. Ne pas mettre à jour tous les composants séparément

Pour les architectures utilisant plusieurs composants n8n, la documentation recommande déjà de maintenir les composants principaux, workers et runners sur la même version, notamment pour éviter les incompatibilités de protocole.

Cette règle devient encore plus importante lors d’un changement de version majeure.

Tableau de préparation

Faut-il migrer dès la sortie ?

Pour une instance de production, je ne migrerais pas le jour de la sortie sans validation préalable.

n8n 3.0 est, par définition, une version majeure comportant des breaking changes. Le bon moment dépendra de quatre éléments :

• la publication du guide de migration final ;
• la disponibilité d’une version stable ;
• le résultat des tests sur une copie ;
• la présence ou non de composants supprimés dans vos workflows.

Une instance récente, déjà sous Docker et sans nœuds historiques, demandera probablement moins de travail.

Une instance ancienne, avec des centaines de workflows, des nœuds communautaires, des Code nodes complexes et plusieurs workers, mérite une véritable recette.

Ce que je retiens

n8n 3.0 ne révolutionne pas encore l’interface visible. Il remet de l’ordre dans les fondations.

Le changement le plus clair concerne le self-hosting : Docker deviendra obligatoire et les installations npm ou npx ne seront plus prises en charge.

Côté workflows, les anciens nœuds Function, Function Item et Item Lists doivent disparaître. $getPairedItem suivra le même chemin. Le nœud Execute Sub-workflow perdra également un ancien comportement, encore insuffisamment documenté.

Plusieurs fonctions seront retirées, dont Chat Hub et l’import depuis une URL. Des règles de sécurité plus strictes sont annoncées, mais leurs détails ne sont pas encore publiés.

Le piège serait de combler ces zones vides par des suppositions.

Pour l’instant, la bonne stratégie est plus simple :

• migrer les anciens nœuds déjà identifiés ;
• sortir de npm ou npx ;
• auditer les sous-workflows ;
• sauvegarder proprement l’instance ;
• préparer un environnement de test ;
• suivre les mises à jour de la documentation officielle.

Cet article sera mis à jour à mesure que n8n précisera les changements de la version 3.0.

Dernière mise à jour : 3 août 2026.

n8n 3.0 : breaking changes, impacts et préparation de la migration

n8n prépare une nouvelle version majeure. Sa sortie est actuellement prévue pour octobre 2026, sans date plus précise annoncée publiquement.

n8n 3.0 ne se présente pas, pour le moment, comme une avalanche de nouvelles fonctionnalités. Le sujet principal est ailleurs : renforcer la sécurité, simplifier la configuration et supprimer des composants historiques devenus obsolètes.

Pour un utilisateur récent de n8n Cloud, une bonne partie de ces changements devrait être transparente. Pour une instance self-hosted ancienne, avec des workflows construits depuis plusieurs années, la migration mérite en revanche un vrai audit.

Au 3 août 2026, n8n a confirmé quatre familles de breaking changes :

• le déploiement des instances self-hosted ;
• la suppression d’anciens nœuds et helpers ;
• le renforcement de la sécurité ;
• l’arrêt de plusieurs fonctionnalités historiques.

La documentation reste volontairement partielle. n8n précise qu’elle sera complétée avec les détails et les guides de migration à mesure que la sortie approchera. Il faut donc considérer cet article comme un état vérifié des informations disponibles, pas comme la documentation définitive de n8n 3.0.

Ce que l’on sait réellement de n8n 3.0

n8n présente cette version majeure comme une étape destinée à rendre sa plateforme plus sûre, plus fiable et mieux adaptée aux environnements de production.

La formulation officielle est assez claire : n8n 3.0 doit apporter des améliorations de sécurité et nettoyer les fonctions dépréciées accumulées au fil des versions.

Ce positionnement explique la nature des premiers changements annoncés. Il ne s’agit pas encore d’une liste de nouveautés métier. Il s’agit surtout de supprimer des méthodes d’installation, des nœuds et des comportements que n8n ne souhaite plus maintenir.

Cette liste n’est pas présentée par n8n comme définitive. D’autres changements peuvent encore être ajoutés avant la sortie.

Docker devient obligatoire pour le self-hosting

C’est probablement le changement d’infrastructure le plus important.

À partir de n8n 3.0, une installation self-hosted devra fonctionner dans un déploiement basé sur Docker. Les installations lancées directement avec npm ou npx n8n ne seront plus prises en charge.

Aujourd’hui, n8n documente encore npm et Docker parmi les modes d’installation. La version 3 mettra fin à cette coexistence pour les déploiements self-hosted pris en charge.

Qui est concerné ?

Vous êtes directement concerné si votre instance est actuellement lancée avec une commande proche de celle-ci :

npx n8n

ou si n8n est installé globalement avec npm :

npm install -g n8n
n8n start

Une instance déjà exécutée dans Docker, Docker Compose, Kubernetes ou une plateforme qui déploie n8n à partir de son image Docker n’est pas concernée par la suppression de npm elle-même.

Cela ne garantit pas pour autant que la mise à niveau sera transparente. Les variables d’environnement, volumes, bases de données, workers, task runners et nœuds communautaires devront toujours être vérifiés.

Ce que recommande actuellement n8n

n8n demande aux utilisateurs de npm ou npx n8n de préparer leur passage vers Docker avant la mise à niveau. Pour les installations locales, Docker Compose est présenté comme la voie qui devrait être la plus simple.

Le guide pas-à-pas spécifique à cette migration n’est pas encore publié. C’est important : on connaît la destination, mais pas encore la procédure officielle détaillée.

Et Coolify ?

Coolify déploie normalement n8n sous forme de conteneur. Une instance n8n installée dans Coolify est donc déjà dans la logique imposée par n8n 3.0.

Il restera néanmoins nécessaire de contrôler :

• l’image utilisée ;
• le tag de version ;
• les volumes persistants ;
• la base PostgreSQL ou SQLite ;
• les variables d’environnement ;
• la stratégie de sauvegarde ;
• le déploiement éventuel de workers et de task runners.

Le breaking change annoncé porte sur l’abandon des installations npm et npx. n8n n’a pas annoncé la fin de Docker Compose, de Kubernetes ou des plateformes d’orchestration de conteneurs.

Suppression des nœuds Function et Function Item

Les anciens nœuds Function et Function Item seront supprimés dans n8n 3.0.

Ils ont déjà été remplacés depuis longtemps par le nœud Code, qui regroupe leurs deux modes d’exécution.

La correspondance annoncée est la suivante :

Le changement ne signifie pas que JavaScript disparaît de n8n. C’est le contraire : le nœud Code devient l’unique nœud généraliste prévu pour exécuter du code personnalisé à la place des anciens nœuds Function.

Function vers Code

L’ancien nœud Function exécutait généralement le code une seule fois pour l’ensemble des items reçus.

Dans le nœud Code, il faut sélectionner :

Run Once for All Items

Exemple de logique traitant tous les items :

const items = $input.all();

return items.map((item) => ({
  json: {
    ...item.json,
    email_normalise: item.json.email?.trim().toLowerCase() ?? null,
  },
}));

Function Item vers Code

L’ancien nœud Function Item traitait chaque item séparément.

Dans le nœud Code, l’équivalent est :

Run Once for Each Item

Exemple :

return {
  json: {
    ...$json,
    email_normalise: $json.email?.trim().toLowerCase() ?? null,
  },
};

Attention à la simple correspondance des modes

Remplacer le type de nœud ne suffit pas toujours à garantir un comportement identique.

Avant de considérer la migration comme terminée, il faut tester :

• le nombre d’items retournés ;
• leur structure JSON ;
• la présence des données binaires ;
• les références vers des items précédents ;
• les branches d’erreur ;
• les expressions utilisées dans les nœuds suivants.

Ce sont des recommandations de contrôle, pas des breaking changes supplémentaires annoncés par n8n.

Suppression du nœud Item Lists

Le nœud historique Item Lists sera également supprimé.

Ce nœud regroupait plusieurs opérations de transformation de listes dans une seule interface. n8n a depuis séparé ces opérations dans des nœuds spécialisés.

Le remplaçant dépend donc de l’opération utilisée dans chaque workflow.

Cette table reprend les alternatives mentionnées dans la documentation n8n 3.0.

Il n’existe donc pas de remplacement automatique unique du type :

Item Lists devient Aggregate.

Ce serait faux.

Un nœud Item Lists configuré pour trier doit être remplacé par Sort. Un autre utilisé pour éclater un tableau doit être remplacé par Split Out. L’audit doit porter sur l’opération configurée, pas seulement sur le nom du nœud.

L’ancien comportement du nœud Execute Workflow disparaît

n8n indique que l’ancien comportement du nœud Execute Workflow sera supprimé.

Ce nœud est aujourd’hui généralement présenté comme Execute Sub-workflow dans l’interface. Il permet à un workflow principal d’appeler un autre workflow.

La première documentation publique ne précise pas encore totalement quel comportement historique sera supprimé ni comment tous les anciens workflows seront migrés.

Une pull request récente du dépôt n8n mentionne toutefois explicitement la dépréciation du mode :

Run once for each item

dans le nœud Execute Sub-workflow.

Cette information vient du dépôt officiel, mais la documentation de migration n’est pas encore assez complète pour affirmer que ce mode constitue à lui seul l’intégralité du breaking change. Il faut donc attendre les précisions de n8n avant de décrire exactement le comportement final.

Ce qu’il faut déjà auditer

Repérez les workflows qui appellent des sous-workflows et vérifiez :

• le mode d’exécution sélectionné ;
• le nombre d’appels effectués ;
• la structure des données transmises ;
• le comportement en cas de plusieurs items ;
• l’attente ou non de la fin du sous-workflow ;
• les données renvoyées au workflow parent.

Je ne conseille pas de modifier ces workflows sur la seule base de l’annonce actuelle. Il manque encore le guide officiel détaillant la migration de l’ancien comportement.

Suppression de $getPairedItem

Le helper d’expression déprécié $getPairedItem sera supprimé.

Pour comprendre le sujet, il faut revenir à l’item linking.

n8n traite les données sous forme d’items. Lorsqu’un nœud transforme, divise, regroupe ou crée des items, n8n doit conserver le lien entre les données de sortie et les données reçues précédemment.

Sans cette relation, une expression qui cherche l’item correspondant dans un nœud antérieur peut devenir ambiguë ou échouer.

n8n recommande désormais d’utiliser son mécanisme standard d’item linking, notamment :

• la propriété pairedItem lorsque du code crée manuellement des items ;
• l’expression $("Nom du nœud").item pour retrouver l’item lié ;
• les mécanismes automatiques de liaison lorsque le nœud peut préserver lui-même la correspondance.

La documentation destinée aux créateurs de nœuds précise que pairedItem sert à indiquer de quel item d’entrée provient chaque item de sortie. Elle indique également que l’absence de cette information peut casser les expressions exécutées dans les nœuds suivants.

Exemple avec pairedItem

const items = $input.all();

return items.map((item, index) => ({
  json: {
    nom: item.json.nom,
    statut: "traite",
  },
  pairedItem: {
    item: index,
  },
}));

Ici, chaque item retourné reste lié à l’item d’entrée correspondant.

La suppression de $getPairedItem concerne surtout :

• les expressions historiques qui l’utilisent encore ;
• certains anciens nœuds personnalisés ;
• les Code nodes qui construisent des items sans préserver correctement leur liaison ;
• les workflows complexes comportant des agrégations, divisions ou regroupements d’items.

Renforcement des règles de sécurité

n8n annonce trois changements de sécurité pour la version 3 :

• un traitement plus strict des noms de ressources considérés comme risqués ;
• un comportement plus sécurisé pour les credentials ;
• la rotation des clés activée par défaut.

À ce stade, la documentation ne donne pas encore suffisamment de détails pour expliquer précisément :

• quels noms de ressources seront interdits ou transformés ;
• quels comportements des credentials vont changer ;
• quelles clés seront concernées ;
• comment se déroulera la rotation ;
• quelles variables permettront éventuellement de contrôler ces mécanismes.

n8n résume ces orientations, mais renvoie les détails à de futures mises à jour de la documentation.

Il serait donc prématuré d’inventer un scénario de migration précis.

Ce que l’on peut faire dès maintenant

n8n propose déjà un audit de sécurité natif pour détecter plusieurs catégories de risques :

• credentials inutilisés ;
• expressions dans les requêtes SQL ;
• nœuds accédant au système de fichiers ;
• nœuds officiels considérés comme risqués ;
• nœuds communautaires et personnalisés ;
• webhooks non protégés ;
• paramètres de sécurité manquants ;
• instance obsolète.

L’audit peut être lancé avec la commande :

n8n audit

Il peut également être exécuté par l’API ou depuis le nœud n8n.

Cet audit ne remplace pas le futur outil de migration vers n8n 3. Il permet néanmoins d’identifier une partie des éléments sensibles avant la mise à niveau.

Chat Hub sera retiré

n8n annonce le retrait de Chat Hub dans la version 3.

Il faut distinguer Chat Hub des workflows utilisant un Chat Trigger, des agents IA ou une interface de chat intégrée à un site.

La page actuelle parle du produit ou de la fonctionnalité Chat Hub. Elle ne dit pas que tous les workflows conversationnels, Chat Triggers ou agents IA seront supprimés.

En l’absence de précision supplémentaire, il ne faut donc pas transformer « Chat Hub sera retiré » en « n8n supprime son système de chat » ou « les agents IA ne fonctionneront plus ». Rien dans la source actuelle ne permet de l’affirmer.

n8n indique qu’une solution de migration ou une alternative sera documentée lorsqu’elle existe. Cette alternative n’est pas encore détaillée pour Chat Hub.

L’import d’un workflow depuis une URL disparaît

L’éditeur n8n ne permettra plus d’importer directement un workflow depuis une URL.

Les autres méthodes d’import resteront disponibles :

• copier-coller le JSON ;
• importer un fichier depuis le menu de l’éditeur ;
• utiliser la ligne de commande ;
• utiliser l’API publique.

La suppression concerne donc une méthode précise de l’éditeur, pas l’import de workflows dans son ensemble.

Pour une équipe qui maintient une bibliothèque de workflows, le changement est relativement simple : distribuer des fichiers JSON, utiliser le copier-coller ou industrialiser le déploiement par API.

Les nœuds non fonctionnels seront supprimés

n8n annonce également la suppression des non-functional nodes.

La documentation actuelle ne fournit pas encore la liste exacte de ces nœuds.

On ne peut donc pas affirmer aujourd’hui quelles intégrations disparaîtront, combien de workflows seront concernés ou si tous les nœuds visés disposent d’un remplaçant.

Il faut attendre la publication de la liste officielle.

C’est typiquement le genre d’information pour laquelle une formulation vague doit rester vague. « Des nœuds non fonctionnels seront supprimés » est confirmé. Une liste inventée à partir d’anciens nœuds dépréciés ne le serait pas.

Ce que n8n 3.0 ne permet pas encore d’affirmer

À ce stade, aucune source officielle consultée ne permet de confirmer :

• la date exacte de sortie ;
• le numéro de la première version stable, au-delà de la famille 3.0 ;
• une procédure complète de migration npm vers Docker ;
• la liste exhaustive des nœuds retirés ;
• le détail des nouvelles règles appliquées aux credentials ;
• le fonctionnement exact de la rotation des clés ;
• toutes les modifications du nœud Execute Sub-workflow ;
• un changement global concernant les agents IA ;
• une incompatibilité générale avec Coolify ou Kubernetes ;
• une modification obligatoire de toutes les bases SQLite ;
• la suppression des nœuds communautaires ;
• la disparition du Chat Trigger.

Le dépôt de documentation montre d’ailleurs que la page actuelle a été enrichie le 31 juillet 2026 à partir de quatre familles de changements annoncées. Le résumé de la pull request précise également que certaines recommandations de remplacement ont été déduites de la documentation existante, puis intégrées à la page officielle. Cela confirme le caractère encore progressif de cette documentation.

Comment préparer une instance sans attendre octobre

Il ne faut pas installer une future version majeure en aveugle sur une instance de production. Ce n’est pas propre à n8n 3. C’est une règle élémentaire pour tout système qui exécute des automatisations métier.

Je commencerais par un inventaire simple.

1. Identifier le mode de déploiement

Vérifiez si n8n fonctionne avec :

• npm ou npx ;
• Docker ;
• Docker Compose ;
• Coolify ;
• Kubernetes ;
• une offre Cloud gérée par n8n.

Les installations npm et npx sont les seules explicitement annoncées comme non prises en charge dans n8n 3.0.

2. Rechercher les nœuds historiques

Dans les exports JSON de vos workflows, recherchez les types correspondant aux anciens nœuds :

n8n-nodes-base.function
n8n-nodes-base.functionItem
n8n-nodes-base.itemLists

La présence de ces chaînes permet de repérer les workflows susceptibles de nécessiter une migration.

Exemple de recherche dans un répertoire d’exports :

grep -R \
  -e '"n8n-nodes-base.function"' \
  -e '"n8n-nodes-base.functionItem"' \
  -e '"n8n-nodes-base.itemLists"' \
  ./workflows

Cette commande est une méthode d’audit proposée ici. Elle n’est pas présentée comme un outil officiel n8n.

3. Rechercher $getPairedItem

grep -R '\$getPairedItem' ./workflows

Chaque occurrence devra être revue et remplacée par le mécanisme moderne d’item linking adapté au workflow.

4. Inventorier les sous-workflows

Repérez les workflows contenant Execute Workflow ou Execute Sub-workflow.

Ne les modifiez pas au hasard. Documentez :

• le workflow appelé ;
• le mode configuré ;
• la quantité d’items reçue ;
• la quantité d’exécutions attendue ;
• le résultat renvoyé.

Ces informations permettront de tester le futur comportement de n8n 3 dès qu’il sera précisément documenté.

5. Exporter les workflows

Un export des workflows ne constitue pas une sauvegarde complète de l’instance, mais il facilite :

• la comparaison avant et après migration ;
• la recherche dans les JSON ;
• le retour manuel vers une version antérieure d’un workflow ;
• les tests sur une instance séparée.

6. Sauvegarder la base et les données persistantes

Pour une instance Docker, il faut identifier tout ce qui persiste en dehors du conteneur :

• base PostgreSQL ou fichier SQLite ;
• dossier .n8n ;
• données binaires locales ;
• fichiers utilisés par les workflows ;
• clés de chiffrement ;
• variables d’environnement ;
• fichiers Docker Compose ;
• configurations du reverse proxy.

Le conteneur est remplaçable. Les volumes et la base ne le sont pas.

7. Tester sur une copie

La méthode la plus sûre consiste à restaurer une copie de l’instance dans un environnement isolé, puis à y installer la version candidate de n8n 3.

Il faut alors contrôler au minimum :

• le démarrage de l’instance ;
• l’accès aux credentials ;
• l’ouverture des workflows ;
• les triggers ;
• les webhooks ;
• les sous-workflows ;
• les Code nodes ;
• les fichiers binaires ;
• les nœuds communautaires ;
• les agents et outils IA ;
• les exécutions planifiées ;
• les workers et files d’attente ;
• les logs et erreurs.

8. Ne pas mettre à jour tous les composants séparément

Pour les architectures utilisant plusieurs composants n8n, la documentation recommande déjà de maintenir les composants principaux, workers et runners sur la même version, notamment pour éviter les incompatibilités de protocole.

Cette règle devient encore plus importante lors d’un changement de version majeure.

Tableau de préparation

Faut-il migrer dès la sortie ?

Pour une instance de production, je ne migrerais pas le jour de la sortie sans validation préalable.

n8n 3.0 est, par définition, une version majeure comportant des breaking changes. Le bon moment dépendra de quatre éléments :

• la publication du guide de migration final ;
• la disponibilité d’une version stable ;
• le résultat des tests sur une copie ;
• la présence ou non de composants supprimés dans vos workflows.

Une instance récente, déjà sous Docker et sans nœuds historiques, demandera probablement moins de travail.

Une instance ancienne, avec des centaines de workflows, des nœuds communautaires, des Code nodes complexes et plusieurs workers, mérite une véritable recette.

Ce que je retiens

n8n 3.0 ne révolutionne pas encore l’interface visible. Il remet de l’ordre dans les fondations.

Le changement le plus clair concerne le self-hosting : Docker deviendra obligatoire et les installations npm ou npx ne seront plus prises en charge.

Côté workflows, les anciens nœuds Function, Function Item et Item Lists doivent disparaître. $getPairedItem suivra le même chemin. Le nœud Execute Sub-workflow perdra également un ancien comportement, encore insuffisamment documenté.

Plusieurs fonctions seront retirées, dont Chat Hub et l’import depuis une URL. Des règles de sécurité plus strictes sont annoncées, mais leurs détails ne sont pas encore publiés.

Le piège serait de combler ces zones vides par des suppositions.

Pour l’instant, la bonne stratégie est plus simple :

• migrer les anciens nœuds déjà identifiés ;
• sortir de npm ou npx ;
• auditer les sous-workflows ;
• sauvegarder proprement l’instance ;
• préparer un environnement de test ;
• suivre les mises à jour de la documentation officielle.

Cet article sera mis à jour à mesure que n8n précisera les changements de la version 3.0.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.