n8n 3.0 abandonne les installations npm et casse les nœuds de workflow hérités

La plateforme d'automatisation n8n se prépare à publier une version majeure 3.0 qui introduit des changements cassants significatifs pour les instances auto-hébergées. Publiée en bêta le 27 octobre 2026, avec un lancement stable prévu début décembre, cette mise à jour modifie fondamentalement la façon dont le logiciel est déployé et dont les workflows existants fonctionnent. Les équipes gérant leurs propres serveurs n8n doivent se préparer à des changements d'infrastructure obligatoires et à du refactoring de code avant la fermeture de la fenêtre de mise à niveau.

Ce qui s'est passé

Le changement opérationnel le plus immédiat est la suppression des méthodes d'installation basées sur npm. La version 3.0 ne publiera pas de package n8n exécutable sur npm, ce qui signifie que les commandes telles que npm install n8n ou npx n8n ne sont plus prises en charge. Les utilisateurs auto-hébergés doivent migrer vers des conteneurs Docker pour exécuter le logiciel. Ce changement inclut également des modifications des chemins de stockage de fichiers ; le répertoire hérité ~/.n8n/binaryData est remplacé par ~/.n8n/storage. L'application refusera de démarrer si les deux répertoires existent, nécessitant un nettoyage manuel lors de la transition. De plus, la rotation des clés de chiffrement est désormais activée par défaut, et le nœud Compression a des limites plus strictes, plafonnant les opérations à 256 MiB ou 1 000 entrées.

Au-delà de l'infrastructure, la mise à jour supprime plusieurs nœuds et fonctions centraux qui avaient été dépréciés dans les versions précédentes. Les déclencheurs Cron et Interval ont disparu, entièrement remplacés par le Schedule Trigger. Les nœuds hérités tels que Function, Function Item et Item Lists ont été supprimés, provoquant l'échec des exécutions s'ils sont encore présents dans les anciens workflows. L'outil de migration peut convertir certains d'entre eux en nœuds Code, mais une revue manuelle est nécessaire. Par ailleurs, la méthode d'expression $getPairedItem a été retirée des nœuds Code, obligeant les développeurs à mettre à jour leurs scripts pour utiliser des alternatives comme .itemMatching() ou .pairedItem().

Les paramètres de sécurité et d'intégration ont également été renforcés. Les déclencheurs Slack exigent désormais un Signature Secret dans les identifiants, ce qui arrêtera les flux d'approbation et d'alerte existants s'ils ne sont pas mis à jour. La plateforme a étendu sa liste de blocage Server-Side Request Forgery (SSRF) pour inclure la plage 100.64.0.0/10 par défaut, pouvant potentiellement bloquer les connexions à certains services internes privés sauf autorisation explicite via des variables d'environnement. Les packages communautaires non vérifiés sont désactivés par défaut, ce qui signifie que les nœuds personnalisés tiers ne se chargeront pas sauf si l'utilisateur accepte explicitement le risque en définissant un indicateur d'environnement.

Détails clés

• Changement de déploiement : les installations npm et npx ne sont plus prises en charge ; les utilisateurs doivent passer à Docker.
• Suppression de nœuds : les nœuds Cron, Interval, Function, Function Item et Item Lists sont supprimés.
• Modifications de code : $getPairedItem est retiré ; le délai d'expiration par défaut des tâches Code passe de 300 s à 60 s.
• Intégration Slack : les déclencheurs imposent désormais un Signature Secret dans la configuration des identifiants.
• Chemin de stockage : ~/.n8n/binaryData est renommé en ~/.n8n/storage ; l'ancien chemin doit être supprimé.
• Calendrier de support : le support de la version 1.x prend fin le 31 décembre 2026 ; les correctifs de sécurité pour la 2.x prennent fin 12 mois après la sortie stable de la 3.x.

Contexte

n8n est un outil d'automatisation de workflow qui permet aux utilisateurs de connecter différentes applications et services via une interface visuelle. Pour de nombreuses entreprises, notamment celles traitant des données sensibles, l'auto-hébergement d'n8n offre un contrôle sur l'emplacement des données et leur traitement. Cependant, maintenir un logiciel auto-hébergé nécessite de suivre les évolutions en amont. Les changements cassants dans les versions majeures impliquent souvent la suppression de fonctionnalités dépréciées pour réduire la dette technique et améliorer la sécurité. Dans ce contexte, la suppression du support npm simplifie la charge de maintenance pour les développeurs en se concentrant sur un modèle de déploiement unique et conteneurisé. De même, la suppression des nœuds hérités force les utilisateurs à adopter des pratiques de codage plus modernes, efficaces et sécurisées au sein de leurs workflows.

Pourquoi c'est important

Pour les équipes gérant leur propre infrastructure d'automatisation, cette mise à niveau n'est pas facultative si elles souhaitent rester supportées. La suppression du support npm signifie que tous les pipelines CI/CD existants ou configurations de serveur reposant sur une installation directe de node seront rompus lors de la mise à niveau. Cela nécessite une re-architecture fondamentale des scripts de déploiement. De plus, la réduction stricte du timeout des nœuds Code de 300 secondes à 60 secondes peut faire échouer inopinément les transformations de données longues. Les équipes traitant de grands jeux de données ou effectuant des calculs complexes dans des nœuds de code JavaScript doivent soit optimiser leurs scripts, soit configurer la variable d'environnement N8N_RUNNERS_TASK_TIMEOUT pour éviter des pannes en production.

L'impact sur les workflows critiques pour l'entreprise est significatif. Les flux gérant les commandes, les factures ou les mouvements de stock dépendent souvent de nœuds hérités ou de déclencheurs temporels spécifiques. S'ils ne sont pas identifiés et migrés avant la mise à niveau, les opérations commerciales pourraient s'arrêter. L'exigence de vérifier manuellement les workflows migrés automatiquement ajoute une couche de travail d'assurance qualité qui ne peut être ignorée. De plus, les protections SSRF plus strictes peuvent silencieusement bloquer les appels API internes auparavant autorisés, obligeant les équipes réseau à revoir et mettre à jour les listes d'autorisation pour les plages IP privées.

Ce que vous pouvez faire

• Vérifiez votre version actuelle : Si vous êtes sur la version 1.x, mettez à niveau vers la 2.x d'abord, car il n'y a pas de chemin direct vers la 3.x.
• Exécutez le Rapport de Migration : Utilisez l'outil intégré dans les Paramètres (disponible dans n8n 2.39+) pour identifier les problèmes de workflow et d'instance.
• Priorisez les flux critiques : Corrigez d'abord les workflows impliqués dans les transactions financières ou d'inventaire, et examinez attentivement le code migré automatiquement.
• Auditez les nœuds Code : Recherchez les méthodes dépréciées comme $getPairedItem et identifiez les tâches s'exécutant plus de 60 secondes.
• Testez en préproduction : Sauvegardez votre instance de production, restaurez-la dans un environnement de staging, effectuez la mise à niveau et rejouez des entrées réelles pour vérifier les nombres d'enregistrements.
• Planifiez une interruption de service : Effectuez la mise à niveau finale pendant une période calme et confirmez que tous les workflows programmés s'activent correctement ensuite.