Importer et exporter des workflows n8n : JSON, CLI, API et templates sans mauvaise surprise

Tout ce que vous construisez dans n8n est un document JSON : nodes, connexions, paramètres, position dans le canvas. Cette transparence est l'un des grands atouts de l'outil — elle rend les workflows portables : partageables avec un collègue, versionnables dans Git, déplaçables de dev en prod, publiables comme template. Encore faut-il connaître les quatre mécanismes d'import/export et leurs pièges (crédentiels, identifiants, versions de nodes). Ce réflexe de traiter l'automatisation comme du code n'est pas qu'une élégance : l'étude de Hilton et al. présentée à la conférence ASE en 2016 (« Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects », voir sur Google Scholar) a montré, sur des milliers de projets, que les équipes qui outillent le cycle intégration-livraison publient plus fréquemment avec moins de défauts — exactement ce que gagne une équipe n8n qui exporte, versionne et redéploie ses workflows au lieu de les modifier à la main en production.

Méthode 1 : l'interface, pour le quotidien

Dans l'éditeur, le menu du workflow propose Download (télécharger le JSON) et Import from File / Import from URL. C'est le chemin naturel pour partager un workflow complet ou récupérer celui d'un collègue. Deux subtilités :

• L'import dans un workflow ouvert remplace son contenu ; pour garder l'existant, créez d'abord un workflow vierge.
• Le JSON embarque les références de crédentiels (nom + ID), jamais les secrets : sur l'instance cible, chaque node marqué en erreur attend qu'on lui réassigne un crédentiel local. C'est une bonne nouvelle pour la sécurité — cohérente avec les principes de notre guide sur la sécurisation des crédentiels.

À connaître absolument : le copier-coller de nodes. Sélectionnez des nodes dans le canvas, copiez, collez dans n'importe quelle autre instance : le presse-papiers transporte le JSON, connexions comprises. Idéal pour réutiliser un bloc éprouvé — une gestion d'erreur type, un étage IA complet.

Méthode 2 : la CLI, pour les sauvegardes et les migrations

Sur une instance self-hosted, la ligne de commande exporte et importe en masse :

# Exporter tous les workflows, un fichier par workflow
n8n export:workflow --all --separate --output=./backup/workflows/

# Réimporter un dossier complet
n8n import:workflow --separate --input=./backup/workflows/

Différence clé avec l'interface : la CLI préserve les identifiants — réimporter un export met à jour les workflows existants au lieu d'en créer des copies. C'est le comportement voulu pour la restauration et la synchronisation entre environnements. La CLI sait aussi exporter les crédentiels (chiffrés par défaut) ; maniez l'option de déchiffrement avec les précautions qui s'imposent et gardez ces exports hors de tout dépôt Git. Pour une stratégie de sauvegarde complète — base de données comprise —, voyez notre guide de la sauvegarde et restauration d'une instance self-hosted.

Méthode 3 : l'API REST, pour l'automatisation

L'API publique de n8n expose les workflows en lecture et en écriture : un GET /workflows récupère les définitions, un POST en crée. C'est la brique des scénarios avancés : promotion automatisée de dev vers prod, sauvegarde continue vers Git (un workflow n8n qui exporte les workflows n8n — et oui, ça fonctionne très bien), inventaire des workflows actifs pour la supervision de l'instance.

Méthode 4 : les templates, pour ne pas partir de zéro

La galerie n8n.io/workflows compte des milliers de templates importables en un clic ou par URL. Trois vérifications avant d'activer un template importé :

1. Crédentiels : tout est à recréer localement — normal et sain.
2. Nodes communautaires : certains templates supposent des community nodes à installer d'abord ; l'éditeur signale les nodes inconnus.
3. Relecture complète : URLs codées en dur, webhooks à régénérer, et — pour tout template manipulant vos données — compréhension de chaque node avant activation. Un template est du code que vous n'avez pas écrit : traitez-le comme tel.

Nos workflows gratuits et les packs FlowKit suivent exactement ce format JSON standard : import en deux clics, crédentiels à brancher, documentation de chaque node incluse.

Les trois pièges qui reviennent toujours

Le piège des versions. Un workflow exporté depuis un n8n récent peut utiliser des versions de nodes inconnues d'une instance plus ancienne. Alignez les versions avant de migrer — notre guide pour mettre à jour n8n sous Docker sans rien casser détaille la marche prudente.

Le piège des IDs croisés. Deux personnes qui s'échangent des exports sur une instance partagée finissent par s'écraser mutuellement. Convenez d'un sens unique : Git comme source de vérité, l'instance comme cible de déploiement — la discipline complète est décrite dans notre guide des environnements dev/prod.

Le piège du « ça marchait en dev ». Un import réussi n'est pas un déploiement réussi : variables d'environnement absentes, webhooks non enregistrés, crédentiels de prod aux droits différents. Après chaque import, une exécution de test par workflow, systématiquement — le réflexe défendu dans notre guide des évaluations et tests de workflows.

L'import/export est la porte d'entrée de la maturité n8n : le jour où vos workflows vivent dans Git, se déploient par API et se restaurent en une commande, votre automatisation cesse d'être une collection de bricolages pour devenir un système.