Ressources · Intégration n8n

Nœud n8n TriggerConfigurer n8n Trigger dans n8n.

Le nœud n8n Trigger fait réagir un workflow à sa propre vie. Il l'ouvre au moment où ce workflow est publié, republié depuis un état déjà publié, ou quand l'instance démarre. Un paramètre unique, Events, et 3 cases à cocher selon le besoin réel du workflow.

Tester le nœud n8n Trigger sur n8nVoir les 1 paramètres

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

Que surveille vraiment le nœud n8n Trigger ?

Ici, c'est n8n qui se regarde lui-même. Posé dans un workflow, ce nœud le réveille sur trois moments de sa propre vie : sa publication, la republication d'une version déjà publiée, et le démarrage ou redémarrage de l'instance qui l'héberge. Rien d'autre ne le concerne. Un collègue qui publie le workflow d'à côté ne le fera pas bouger d'un millimètre.

Premier usage, le journal des mises en ligne. Coche Workflow Published et chaque première publication laisse une trace lisible, une ligne dans Google Sheets par exemple. Sur une instance partagée entre plusieurs personnes, ça remplace le fichier de suivi que personne ne remplit jamais.

Deuxième usage, le réveil après redémarrage. Avec Instance Started, le workflow s'ouvre dès que l'instance repart, juste après une montée de version ou un redémarrage de conteneur. Le bon réflexe : un appel de vérification avec HTTP Request, le nœud qui appelle n'importe quel endpoint HTTP, puis un message dans le canal technique via Slack. Plus personne n'a besoin d'y penser.

Troisième usage, le suivi des modifications. Published Workflow Updated réagit quand une version déjà publiée est republiée. Comme les 3 événements peuvent cohabiter dans le même nœud, un Switch placé juste derrière sépare les branches : une alerte pour une republication, un simple enregistrement pour un démarrage d'instance.

Quand prendre autre chose. Ce nœud ouvre un workflow sur sa propre vie, point. Il n'interroge aucun service, ne lit aucun fichier, ne regarde aucun compte externe. Tout ce qui part d'un outil tiers passe par le nœud de cet outil, et tout appel d'API dans l'exécution reste le travail de HTTP Request.

Les limites méritent d'être connues avant de construire dessus. Le nœud couvre 3 événements et ne répond qu'aux événements de son propre workflow : impossible d'en faire une vigie centrale sur une instance entière. Sa version est 1, donc aucun autre réglage à ouvrir. En production, le workflow doit être actif pour que le nœud écoute ; en édition, l'exécution de test lance une écoute ponctuelle, une seule.

Paramètres

Comment remplir le paramètre Events ?

Le nœud n8n Trigger compte un paramètre. Pour chacun : le nœud tel que tu le configures dans n8n, ce que le paramètre change, et nos notes de terrain.

01

Events

events

Ce que tu vois dans n8n

Notes & cas d'usage

Tout le nœud tient dans ce champ obligatoire : il désigne les moments qui ouvrent le workflow. Il accepte plusieurs valeurs en même temps, donc un seul nœud couvre à la fois la publication et le redémarrage.

Paramètres clés

  • Published Workflow Updated : se déclenche quand la version du workflow est publiée depuis un état déjà publié.
  • Instance Started : se déclenche quand cette instance n8n démarre ou redémarre.
  • Workflow Published : se déclenche quand la version du workflow est publiée depuis un état non publié.
Cas d'usage
sur une instance auto-hébergée, Instance Started seul suffit pour relancer un contrôle matinal après chaque redémarrage. Les deux événements de publication ensemble transforment le workflow en registre des mises en ligne de l'équipe.
Besoin d'aide

Besoin d'aide pour automatiser n8n Trigger avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

Nœud n8n Trigger : ce qu'on se demande ensuite

01Le nœud n8n Trigger est-il gratuit dans n8n ?
Oui. C'est un nœud core, livré avec n8n : rien à installer, aucun coût supplémentaire côté n8n. Il se comporte pareil sur n8n Cloud, l'offre hébergée par n8n, et sur une instance auto-hébergée avec Docker ou npm, en Community Edition sous licence Sustainable Use. Un workflow construit d'un côté tourne de l'autre sans retouche, et ça compte doublement ici : le nœud réagit à l'instance sur laquelle il vit. Déplace le workflow ailleurs, il rendra compte de cette nouvelle instance. La seule facture possible vient de ce que les nœuds suivants vont appeler, pas de ce déclencheur.
02Qu'est-ce qu'il faut configurer pour qu'il fonctionne ?
Rien du tout, et c'est un vrai confort. Ce nœud n'a ni credential, l'identifiant que n8n stocke pour un service, ni sélecteur Authentication : aucun compte à relier, aucune clé à coller, aucun droit à accorder. On le pose sur la toile, on coche les événements voulus, la configuration s'arrête là. Deux réflexes restent utiles. Le workflow doit être actif pour que le nœud écoute en production, sinon rien ne s'ouvre. Et pendant la construction, l'exécution de test n'arme qu'une écoute ponctuelle : un seul passage, puis il faut la relancer. Tout le reste se joue dans les nœuds placés après.
03Quelles sont ses limites ?
Trois bornes à retenir. D'abord, il ne répond qu'aux événements de son propre workflow : publier ou modifier un autre workflow ne le réveille pas, donc il ne remplace pas une supervision globale de l'instance. Ensuite, il couvre 3 événements et pas un de plus, ce qui exclut la réaction à une exécution en échec, à une connexion d'utilisateur ou à un changement de credential. Enfin, sa version est 1, avec un paramètre unique et aucune collection d'options à ouvrir : rien de caché à régler. On compose avec : un nœud par workflow à suivre, et toute la logique de report dans les nœuds suivants.
04Quand le préférer à un appel HTTP ?
Quand ce qu'on veut capter, c'est le workflow lui-même : sa publication, sa republication, le redémarrage de l'instance. Ces moments n'ont aucune URL à interroger et aucun service extérieur à questionner, seul un nœud posé dans le workflow peut les voir. HTTP Request répond à une autre question : il appelle n'importe quel endpoint HTTP et sert de recours quand un nœud dédié n'expose pas une opération d'API, mais il n'ouvre jamais un workflow tout seul. Dans la pratique, les deux cohabitent : le nœud n8n Trigger ouvre l'exécution, HTTP Request va chercher ce qu'il faut ensuite.
05n8n ou Make pour ce type de suivi ?
La réponse tient à l'endroit où vit l'automatisation. Make est une plateforme hébergée, sans option d'auto-hébergement, facturée à l'opération : un workflow qui part à chaque redémarrage et à chaque publication alimente ce compteur. n8n tourne sur Cloud ou sur ta propre machine, et c'est tout l'enjeu pour un nœud qui rend compte de l'instance : en auto-hébergé, les informations sur tes workflows ne sortent pas de chez toi. Les deux proposent une logique visuelle agréable à construire, donc les vrais critères restent l'hébergement, la maîtrise des données et le modèle de coût.
Hack'celeration Lab

Reçois nos tips intégration chaque semaine.

Pas de spam. Désinscription à tout moment.

Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations