Mettre à jour n8n sans perte de données : verrouillage de version, sauvegarde, rollback
Comment mettre à jour n8n en toute sécurité : verrouillage de version, sauvegarde de la base de données et de la clé de chiffrement, procédure correcte.
Si vous perdez la clé de chiffrement n8n, tous les identifiants enregistrés deviennent inutilisables. Voici comment sauvegarder correctement workflows, identifiants et clés.
Une sauvegarde n8n n'est complète que lorsqu'elle sécurise ensemble les workflows, les identifiants et la clé de chiffrement correspondante. Si la clé manque ou diffère de l'original, n8n ne peut plus déchiffrer les identifiants enregistrés, et chaque connexion enregistrée vers une boîte e-mail, un CRM ou une API doit être reconfigurée manuellement. Les workflows eux-mêmes peuvent être exportés et importés au format JSON via l'interface web ou la CLI ; les identifiants nécessitent en plus la clé de chiffrement d'origine ou un export déchiffré délibérément. Pour les entreprises qui hébergent elles-mêmes n8n et assument la responsabilité de leurs automatisations, la clé de chiffrement est donc l'élément le plus important d'une stratégie de sauvegarde fonctionnelle. Situation au : juillet 2026.
La clé de chiffrement chiffre tous les identifiants enregistrés dans n8n avant leur stockage dans la base de données ; sans la clé correspondante, ces données restent définitivement illisibles. Au premier démarrage, n8n génère automatiquement une clé aléatoire et la stocke dans le dossier ~/.n8n. Quiconque souhaite utiliser sa propre clé doit définir la variable d'environnement N8N_ENCRYPTION_KEY avant la création du fichier de configuration ; un changement ultérieur n'est pas repris automatiquement. Si n8n fonctionne en mode file d'attente avec plusieurs workers, la documentation indique que la même clé de chiffrement doit être définie pour chaque worker (documentation n8n sur la clé de chiffrement).
Si la clé de chiffrement est perdue ou diffère de celle utilisée à l'origine pour chiffrer les identifiants, n8n signale que les identifiants n'ont pas pu être déchiffrés, probablement parce qu'une autre clé de chiffrement a été utilisée. La logique du workflow elle-même reste intacte sous forme de structure JSON, mais chaque identifiant enregistré, comme les clés API, les jetons OAuth ou les accès SMTP, devient inutilisable et doit être reconnecté manuellement. Avec quelques workflows, c'est gênant ; avec des automatisations développées comportant de nombreuses connexions à la comptabilité, au CRM ou à la gestion des stocks, cela signifie en pratique un redémarrage complet de toute la gestion des identifiants. La clé de chiffrement doit donc faire partie de chaque routine de sauvegarde, séparément de la sauvegarde de la base de données, mais tout aussi fiable qu'elle.
Pour les sauvegardes, n8n propose des méthodes à la fois via l'interface et via la CLI du serveur ; pour des sauvegardes régulières, la CLI est la méthode la plus fiable. Dans l'interface web, un workflow peut être téléchargé au format JSON via le menu à trois points, ou importé depuis un fichier ou une URL.
Les détails de toutes les commandes se trouvent dans la documentation n8n sur l'export et l'import ainsi que sur la ligne de commande (Export et import dans n8n, Commandes CLI n8n).
Changer la clé de chiffrement n'est pas une opération de routine, mais une intervention qui peut entraîner une perte de données définitive sans sauvegarde préalable. n8n distingue la clé de chiffrement de l'instance, qui en tant que clé maîtresse ne change jamais, et une clé de chiffrement des données sous-jacente, qui chiffre réellement les identifiants et peut être renouvelée via sa propre fonction de rotation. Selon la documentation, cette rotation n'est explicitement pas réversible ; si la fonction associée est de nouveau désactivée, toutes les données chiffrées depuis lors deviennent définitivement inaccessibles, une sauvegarde complète préalable de la base de données étant la seule protection (documentation n8n sur la rotation des clés). Il convient également d'être prudent lors du partage de fichiers JSON de workflows exportés, car les fichiers contiennent des noms d'identifiants et des ID, et les nœuds de requête HTTP importés depuis cURL peuvent même contenir des en-têtes d'authentification en clair. Ces informations doivent être supprimées avant toute transmission.
Quiconque exploite sa propre instance n8n et recherche un accompagnement pour la mise en place de routines de sauvegarde ou le déménagement entre serveurs trouvera un soutien dans l'offre n8n de NordFlux.
Non, une simple sauvegarde de la base de données sécurise certes les workflows et les identifiants chiffrés, mais sans la clé de chiffrement associée, ces identifiants restent illisibles lors de la restauration. Par défaut, la clé se trouve dans un fichier de configuration séparé, dans le dossier ~/.n8n, et doit donc être sauvegardée délibérément, idéalement séparément de la sauvegarde de la base de données, dans un emplacement protégé contre les accès.
Oui, l'export d'un workflow via l'interface ou avec n8n export:workflow ne contient que la structure du workflow avec des références aux noms d'identifiants et aux ID, et non les identifiants eux-mêmes. Pour emporter également les identifiants, un export séparé avec n8n export:credentials est nécessaire, et la destination doit soit disposer de la même clé de chiffrement, soit les identifiants doivent d'abord être exportés en clair avec l'option --decrypted.
La méthode la plus fiable est l'export déchiffré avec n8n export:credentials --all --decrypted sur l'instance source, suivi de l'import habituel sur l'instance de destination, qui rechiffre automatiquement les données avec sa propre clé de chiffrement. Comme le fichier est brièvement en clair pendant cette opération, il doit être supprimé de manière sécurisée immédiatement après l'import.
Sans la clé d'origine ni sauvegarde du fichier de configuration, les identifiants déjà chiffrés ne peuvent plus être récupérés ; chaque connexion concernée doit être réauthentifiée manuellement dans les workflows respectifs. La logique du workflow elle-même n'est pas perdue dans ce cas ; l'effort se limite à ressaisir les identifiants, ce qui peut néanmoins représenter plusieurs heures de travail pour des automatisations étendues.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
Comment mettre à jour n8n en toute sécurité : verrouillage de version, sauvegarde de la base de données et de la clé de chiffrement, procédure correcte.
Comment configurer les identifiants Anthropic et OpenAI dans n8n, choisir le modèle adapté à chaque tâche et maîtriser les coûts en tokens.
Exporter les workflows, recréer les identifiants, adapter les URL de webhook : voici comment réussir le passage de n8n Cloud à l'auto-hébergement.
Une sauvegarde sans encryption key n'échoue qu'au pire moment, quand les credentials restent indéchiffrables. NordFlux met en place pour votre instance n8n des sauvegardes qui couvrent ensemble workflows, credentials et clé, et répète régulièrement la restauration. L'espoir que la sauvegarde fonctionne devient ainsi un vrai plan de reprise.