Execute Workflow n8n : migrer les sources Local File et URL avant leur suppression

Depuis la version 2.34 de n8n, publiée le 4 août 2026, un bandeau de dépréciation apparaît dans l’éditeur sur tout node Execute Workflow (aussi appelé Execute Sub-workflow) dont la source est réglée sur Local File ou URL. Le message invite à basculer vers la source Database — ou, à défaut, à coller directement le JSON du sous-workflow via la source Parameter. Rien ne casse aujourd’hui : c’est un avertissement, pas une suppression. Mais deux raisons rendent cette migration plus urgente qu’un simple confort d’interface — l’une architecturale, l’autre sécuritaire.

Ce qui change concrètement

Le node Execute Workflow propose quatre façons de désigner le sous-workflow à exécuter :

• Database — sélectionner un workflow existant dans l’instance, par liste ou par ID.
• Local File — indiquer un chemin vers un fichier JSON sur le disque du serveur n8n.
• URL — pointer vers un fichier JSON accessible en HTTP.
• Parameter — coller directement le JSON du workflow dans le champ du node.

Les deux options désormais dépréciées, Local File et URL, datent des toutes premières versions du node (1.1 et antérieures) — une époque où n8n ne proposait pas encore une gestion aussi mature des sous-workflows comme entités de premier rang dans la base de données. Depuis, la source Database est devenue le chemin naturel : le sous-workflow vit comme n’importe quel autre workflow n8n, versionné, visible dans la liste, modifiable dans son propre éditeur — exactement le fonctionnement décrit dans notre guide des sous-workflows.

Pourquoi n8n déprécie en douceur plutôt que de couper directement

Le choix d’un avertissement qui précède de plusieurs versions la suppression réelle n’a rien d’anodin. Robbes, Lungu et Röthlisberger, dans une étude de référence présentée à la conférence ACM SIGSOFT FSE en 2012, How Do Developers React to API Deprecation? The Case of a Smalltalk Ecosystem, ont observé qu’une part significative des développeurs ignore les messages de dépréciation ou ne les traite que très tardivement, souvent au moment où la suppression effective casse déjà leur code en production. C’est précisément ce que la phase d’avertissement de n8n 2.34 cherche à éviter : donner un signal visible, sans date de suppression fixée à l’avance, pour laisser le temps aux workflows existants de migrer avant qu’une future version majeure ne retire réellement ces deux sources.

Concrètement, tant qu’aucune version majeure n’annonce la suppression dans ses breaking changes (le même type d’annonce que celles documentées lors du passage à la v2.0 de n8n), les sources Local File et URL continuent de fonctionner. Mais ne pas migrer, c’est reporter le risque exact que l’étude décrit : découvrir la casse au moment de la mise à jour, plutôt que de la traiter maintenant à froid.

L’angle sécurité que le bandeau ne dit pas

La dépréciation de Local File ne sort pas de nulle part : elle fait suite à un avis de sécurité, GHSA-2vx9-7wpg-88jq, corrigé en n8n 2.19.3 et 2.20.0. L’option Local File du node Execute Workflow lisait un fichier de workflow sur disque sans appliquer les mêmes contrôles que les autres nodes de lecture de fichiers — en particulier, elle ne respectait pas la restriction N8N_RESTRICT_FILE_ACCESS_TO, documentée dans notre guide des variables d’environnement et dans notre guide du node Read/Write Files from Disk. Un utilisateur autorisé à créer ou modifier des workflows pouvait fournir un chemin arbitraire via l’API REST — l’interface masquait déjà l’option depuis la version 1.2, mais l’API, elle, l’acceptait toujours — et ainsi vérifier l’existence de fichiers sur le serveur hôte, voire charger et exécuter un fichier JSON de workflow trouvé à cet endroit.

Ce n’est pas un cas isolé : une étude récente d’Akhoundali, Hamidi, Rietveld et Gadyatskaya, Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub (2025), a recensé plus de 1 700 projets Node.js open source touchés par un motif de code comparable — un chemin de fichier construit à partir d’une entrée insuffisamment validée. n8n étant lui-même une application Node.js, cet avis de sécurité illustre le même motif à l’échelle d’un de ses propres nodes core plutôt que d’un projet tiers. La leçon vaut au-delà du seul node Execute Workflow : tout champ qui accepte un chemin ou une URL mérite une revue explicite de ce qui peut réellement l’alimenter.

Migrer : la marche à suivre

1. Repérer les nodes concernés. Il n’existe pas de recherche native « tous les Execute Workflow en source Local File » dans l’éditeur : le plus fiable est d’exporter les workflows via l’API REST ou en masse (CLI ou API décrites dans notre guide d’import/export), puis de grep le JSON exporté sur "source": "localFile" ou "source": "url". Sur une instance avec plusieurs dizaines de workflows, c’est nettement plus rapide que d’ouvrir chaque canvas un par un.

2. Basculer vers Database. Si le fichier JSON référencé correspond déjà à un workflow existant dans l’instance, ouvrez le node, changez le champ Source sur Database, puis sélectionnez ce workflow dans la liste (ou collez son ID si vous le connaissez). Si le fichier ne correspond à aucun workflow encore importé, importez-le d’abord — via Import from File dans l’éditeur, exactement comme décrit dans notre guide d’import/export — puis référencez le workflow ainsi créé.

3. Réserver Parameter aux cas réellement dynamiques. Si le JSON du sous-workflow est généré à la volée par un système externe et n’a pas vocation à exister comme workflow n8n séparé, la source Parameter reste légitime : elle ne dépend ni d’un chemin disque ni d’une URL, seulement du contenu collé dans le node.

4. Vérifier le comportement après bascule. Un sous-workflow appelé en source Database répond exactement de la même façon qu’en Local File ou URL une fois le changement fait — testez néanmoins l’exécution complète, en particulier si le workflow appelé utilisait des identifiants d’items spécifiques ou un mode d’exécution (Run Once for All Items / for Each Item) sensible à la structure d’entrée.

5. Ajouter cette vérification à la routine de mise à jour. Notre méthode de mise à jour n8n sous Docker recommande déjà de lire les breaking changes avant chaque montée de version majeure — c’est exactement le réflexe qui permettra de repérer, le jour venu, l’annonce de suppression effective de ces deux sources avant qu’elle ne surprenne personne.

Cas d’usage avec les packs FlowKit

Les workflows livrés dans nos packs découpent déjà leurs pipelines en blocs séparés selon le principe des sous-workflows — le Pack Assistant RAG (119 €) isole par exemple l’ingestion documentaire du chatbot de conversation. Ces liaisons sont construites en source Database dès l’origine, pour la simple raison que c’est la façon la plus stable de référencer un sous-workflow sur une instance qui évolue dans le temps. Pour un consultant ou une agence qui maintient les automatisations de plusieurs clients, le Pack Conformité & Audit (149 €) applique le même principe de traçabilité à la piste d’audit elle-même : chaque étape horodatée en base plutôt que dispersée dans des fichiers volants. Les deux packs, avec le Pack Inbox IA (79 €), sont réunis dans le Bundle FlowKit Complet (269 € au lieu de 347 € achetés séparément).

En résumé

Le bandeau de dépréciation apparu en n8n 2.34 sur les sources Local File et URL du node Execute Workflow n’est pas une simple préférence d’architecture : il fait suite à une faille de sécurité réelle, corrigée depuis plusieurs versions, et il annonce une suppression qui, si l’expérience d’autres écosystèmes logiciels sert de guide, surprendra surtout ceux qui auront ignoré l’avertissement jusqu’à la mise à jour majeure qui la déclenche. Migrer vers la source Database — ou Parameter pour les cas réellement dynamiques — prend quelques minutes par workflow concerné, et élimine au passage une dépendance fragile à un chemin de fichier ou une URL que n8n ne validait pas avec la même rigueur que ses autres nodes de lecture de fichiers.