Nœud Execute Command n8nConfigurer Execute Command dans n8n.

Un point se règle avant tous les autres : ce nœud n'est pas disponible sur n8n Cloud. Il suppose une instance auto-hébergée, en Docker ou en npm, sur la Community Edition sous licence Sustainable Use. Depuis n8n 2.0 il arrive en plus désactivé par défaut, parce qu'ouvrir un shell depuis un workflow reste un risque réel sur une instance partagée avec des utilisateurs non maîtrisés. Savoir cela dès le départ évite de dessiner un workflow qui ne tournera jamais là où il devait tourner.

Cela posé, le premier usage est la maintenance d'exploitation. Purger un cache, relancer un service, compter des fichiers avant d'alerter l'équipe : les gestes qu'un administrateur tapait dans un terminal, rejoués à heure fixe derrière un planificateur. Plusieurs commandes tiennent dans un seul nœud, enchaînées par && ou écrites sur des lignes séparées dans le champ Command.

Le deuxième usage tient au rythme d'exécution. Un lot de fichiers arrive sous forme d'items, et le convertisseur doit passer une fois sur chacun, le nom du fichier venant de l'item par une expression du type {{ $json.field }}. Vient ensuite la commande de nettoyage, qui ne doit passer qu'une fois : Execute Once activé, le nœud ne s'exécute plus pour chaque entrée. Ce basculement résume la différence entre les deux paramètres du nœud.

Le troisième usage est l'archivage de nuit. Le planificateur se déclenche, le nœud lance la commande de sauvegarde de la base, un nœud suivant dépose le fichier ailleurs. Le nœud Postgres ne rendrait pas ce service : ce qu'on veut ici, c'est le binaire livré avec la base, pas une requête envoyée par une connexion applicative.

Il faut aussi savoir passer la main. Tout ce qui parle HTTP appartient au nœud HTTP Request, y compris les commandes curl qu'on tape par réflexe : curl n'est pas présent dans l'image Docker n8n, et l'y remettre suppose de construire sa propre image par-dessus l'officielle. Tout ce qui doit tourner ailleurs appartient au nœud Ssh, car celui-ci ne quitte jamais son hôte : sous Docker, la commande s'exécute dans le conteneur n8n et pas sur la machine en dessous, et en mode file d'attente elle tourne sur le worker qui a pris la tâche en production, les exécutions manuelles restant sur l'instance principale tant que OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS n'est pas à true. La Formation n8n part de ces bases.