Gérer les erreurs dans n8n : Error Trigger et alertes

Un workflow n8n qui tourne depuis des mois donne vite l'impression d'être fiable. Puis un jour, une API change de format, un identifiant expire, un champ arrive vide : le workflow s'arrête, et personne ne le sait avant qu'un client demande où est sa facture. La question n'est pas de savoir si un workflow échouera, mais qui sera prévenu, et comment.

Cet article décrit le dispositif prévu par n8n pour répondre à cette question : le workflow d'erreur, le nœud Error Trigger, le nœud Stop and Error et les réglages d'erreur de chaque nœud. Les faits viennent de la documentation officielle citée en fin d'article ; les recommandations de mise en place sont notre analyse, à adapter à votre contexte.

Le principe : un workflow dédié aux échecs

n8n sépare le traitement normal du traitement des échecs. Vous créez un workflow d'erreur, c'est-à-dire un workflow qui commence par le nœud Error Trigger. Quand un autre workflow échoue, n8n lance ce workflow d'erreur et lui transmet les détails de l'incident.

Pour relier un workflow à son workflow d'erreur, la documentation indique d'ouvrir le workflow concerné, puis Options > Settings, et de choisir le workflow d'erreur dans le champ Error workflow. Un même workflow d'erreur peut servir plusieurs workflows.

C'est le premier avantage d'architecture : un seul endroit décide de ce qui se passe en cas d'échec (message, destinataire, ticket), au lieu de dupliquer la logique d'alerte dans chaque automatisation.

Ce que reçoit l'Error Trigger

D'après la documentation de n8n, quand un workflow échoue, l'Error Trigger reçoit notamment :

• workflow.id et workflow.name : le workflow qui a échoué ;
• execution.error.message et execution.error.stack : le message d'erreur et la trace ;
• execution.lastNodeExecuted : le dernier nœud exécuté, donc l'endroit où chercher ;
• execution.mode : le mode d'exécution ;
• execution.id et execution.url : de quoi retrouver l'exécution, uniquement si elle a été enregistrée en base ;
• execution.retryOf : présent seulement si l'exécution était elle-même une relance.

Un cas particulier mérite l'attention : si c'est le nœud déclencheur du workflow principal qui échoue, les données sont différentes. Il n'y a pas d'objet execution ; n8n fournit à la place un objet trigger avec l'erreur (nom, message, nœud, horodatage) et le mode. Un message d'alerte qui suppose toujours la présence de execution.url produira donc un lien vide dans ce cas.

Les limites à connaître avant de s'y fier

La documentation de l'Error Trigger signale trois points qui surprennent souvent.

1. Il ne se déclenche que sur une exécution automatique en échec. Vous ne pouvez pas le tester en lançant manuellement le workflow principal. Pour valider votre alerte, il faut provoquer une vraie erreur sur une exécution automatique (par exemple avec un déclencheur planifié).
2. Par défaut, un workflow qui contient un Error Trigger est son propre workflow d'erreur. Utile pour un test rapide, risqué si l'on oublie de le réaffecter : l'alerte ne concernera alors que lui-même.
3. Le workflow d'erreur n'a pas besoin d'être publié pour fonctionner, selon la documentation. Vérifiez néanmoins sur votre version que l'alerte part bien en conditions réelles.

Notre lecture : un workflow d'erreur qui n'a jamais été éprouvé est un faux sentiment de sécurité. Prévoyez un test de bout en bout le jour de la mise en production, puis après chaque changement de version de n8n.

Provoquer un échec volontaire avec Stop and Error

Toutes les anomalies ne sont pas des erreurs techniques. Une commande sans montant, un fichier vide, un statut inattendu : le workflow peut continuer sans planter et produire un résultat faux.

Le nœud Stop and Error permet de faire échouer volontairement l'exécution selon les conditions que vous choisissez, ce qui déclenche ensuite le workflow d'erreur. Le schéma est simple : un nœud de test (par exemple un « If ») vérifie qu'une donnée essentielle est présente, et envoie vers Stop and Error si ce n'est pas le cas. L'incident devient visible au lieu de se propager silencieusement vers votre CRM ou votre comptabilité.

Les réglages par nœud : Retry On Fail et On Error

En amont du workflow d'erreur, chaque nœud dispose de réglages qui déterminent ce qui se passe quand lui échoue. La documentation des nœuds décrit notamment :

• Retry On Fail : quand l'exécution du nœud échoue, il est relancé jusqu'à ce qu'il réussisse. Adapté à une panne passagère d'un service tiers ; inutile si l'erreur vient d'une donnée invalide, qui échouera de la même façon à chaque tentative. Consultez dans l'interface du nœud les paramètres de relance disponibles pour votre version.
• On Error, avec trois comportements :
  • Stop Workflow : arrête tout le workflow ;
  • Continue : passe au nœud suivant malgré l'erreur, avec les dernières données valides ;
  • Continue (using error output) : poursuit l'exécution et transmet l'information d'erreur au nœud suivant, pour la traiter explicitement.

Le choix a une vraie conséquence. « Continue » sans réflexion est le réglage le plus dangereux : l'erreur est avalée, le workflow semble réussir, et le workflow d'erreur ne se déclenche pas. À l'inverse, « Continue (using error output) » permet de traiter un échec attendu (par exemple, un contact introuvable dans un CRM) sans arrêter le reste, tout en gardant une trace.

Une architecture minimale pour une PME

Voici le dispositif que nous recommandons comme point de départ. Il s'appuie sur les mécanismes ci-dessus ; les choix de canaux sont à adapter.

1. Un workflow d'erreur commun, créé une fois, relié à tous les workflows de production via Error workflow.
2. Un message d'alerte exploitable : nom du workflow, dernier nœud exécuté, message d'erreur, lien vers l'exécution quand il existe. Prévoir le cas du déclencheur en échec, où ces champs sont absents.
3. Un canal que quelqu'un lit vraiment : messagerie d'équipe ou e-mail d'une personne nommée, pas une boîte que personne n'ouvre.
4. Des contrôles de cohérence avec Stop and Error sur les données critiques (montant, identifiant client, destinataire).
5. Une règle écrite pour chaque nœud externe : relancer en cas de panne passagère, s'arrêter si la donnée est invalide, traiter à part les cas attendus.
6. Le test de l'alerte sur une vraie exécution automatique, à refaire après les changements importants.
7. Un propriétaire : une personne responsable de lire les alertes et de décider de la suite.

Ce dernier point est souvent oublié. Une alerte sans propriétaire finit ignorée. Si vos workflows déclenchent des actions d'un agent IA, la même logique s'applique avec encore plus de rigueur : voir notre article sur les workflows comme outils d'un agent IA pour le découpage des responsabilités entre agent et workflows.

Ce que ce dispositif ne couvre pas

Soyons précis sur les limites. Le workflow d'erreur vous prévient d'un échec ; il ne le corrige pas. Il ne détecte pas non plus un workflow qui ne s'est jamais déclenché (un planificateur arrêté, par exemple), puisqu'aucune exécution n'a échoué. Pour ces cas, il faut un contrôle complémentaire, comme un workflow de vérification quotidienne qui contrôle qu'un résultat attendu est bien apparu.

Enfin, si vous hésitez encore sur l'outil lui-même, notre comparatif n8n, Make et Zapier pour une PME pose les critères de choix, dont la maintenance au quotidien.

Questions fréquentes

Comment être prévenu quand un workflow n8n échoue ?

Créez un workflow qui commence par un nœud Error Trigger, puis sélectionnez-le dans Options > Settings > Error workflow du workflow à surveiller. À chaque échec d'une exécution automatique, ce workflow d'erreur reçoit les détails et peut envoyer l'alerte de votre choix.

Pourquoi mon Error Trigger ne se déclenche pas quand je teste ?

Selon la documentation de n8n, il ne s'exécute que lorsqu'une exécution automatique échoue : un lancement manuel du workflow principal ne le déclenche pas. Testez avec une exécution réelle, par exemple via un déclencheur planifié volontairement en erreur.

Que faire si le déclencheur du workflow lui-même échoue ?

Les données reçues par le workflow d'erreur changent : il n'y a plus d'objet execution, mais un objet trigger contenant l'erreur et le nœud concerné. Votre message d'alerte doit gérer ce cas, sans quoi il manquera le lien vers l'exécution.

Quelle différence entre Continue et Continue (using error output) ?

« Continue » passe au nœud suivant malgré l'erreur, avec les dernières données valides. « Continue (using error output) » transmet l'information d'erreur au nœud suivant pour que vous la traitiez explicitement. Le second est préférable dès que l'échec doit rester visible.

Rendre vos automatisations observables

Vos workflows tournent déjà, mais vous ne savez pas ce qui se passe quand l'un d'eux échoue ? Décrivez-nous votre situation : nous passons en revue les automatisations existantes, identifions les points sans alerte et mettons en place un dispositif d'erreur adapté à votre équipe. Nos offres détaillent les formats d'accompagnement, et vous pouvez nous contacter directement.

Sources

• n8n, Error handling, documentation consultée le 13 octobre 2026.
• n8n, Error Trigger, documentation consultée le 13 octobre 2026.
• n8n, Nodes (paramètres des nœuds : Retry On Fail, On Error), documentation consultée le 13 octobre 2026.