Gestion des erreurs dans n8n : Error Workflows et notifications d'erreur

Un workflow d'erreur (error workflow) est dans n8n une automatisation tout à fait normale que vous définissez dans les paramètres du workflow sous « Error workflow » et qui démarre automatiquement dès que l'exécution d'un autre workflow échoue. Combiné avec le nœud Error Trigger, les paramètres Retry On Fail de nœuds individuels et une notification par e-mail ou Microsoft Teams, cela permet de garantir que les erreurs ne passent pas inaperçues, mais sont automatiquement répétées ou signalées à l'équipe responsable. Au : juillet 2026.

Qu'est-ce qu'un error workflow et quand se déclenche-t-il ?

Selon la documentation n8n, un error workflow est un workflow séparé que vous définissez « dans Workflow Settings » pour une autre automatisation et qui est exécuté dès que l'exécution de celle-ci échoue. D'après la documentation, un cas d'usage typique consiste à envoyer des « notifications par e-mail ou Slack » en cas d'erreur. Un seul error workflow peut être réutilisé pour plusieurs workflows productifs, de sorte que vous n'avez pas besoin de construire une gestion des erreurs propre pour chaque automatisation. Il est important de noter qu'un error workflow ne peut pas être testé par une exécution manuelle : d'après la documentation, l'Error Trigger ne réagit que lorsque l'exécution automatisée d'un autre workflow échoue réellement. Vous trouverez plus de détails dans la documentation n8n sur la gestion des erreurs.

Comment configurer un error workflow ?

Vous créez d'abord un workflow autonome qui existe exclusivement pour le cas d'erreur, puis vous le liez au workflow à surveiller.

• Créer le workflow gestionnaire d'erreurs : Créez un nouveau workflow avec l'Error Trigger comme premier nœud, donnez-lui un nom tel que « Error Handler » et enregistrez-le.
• Ouvrir le workflow cible : Ouvrez le workflow dont vous souhaitez surveiller les erreurs, puis accédez à Options puis Settings.
• Attribuer l'error workflow : Dans le champ « Error workflow », sélectionnez le workflow gestionnaire d'erreurs créé précédemment et enregistrez le paramètre.

Un workflow démarré uniquement via l'Error Trigger n'a pas besoin d'être publié séparément pour fonctionner en tant qu'error workflow.

Quelles informations l'Error Trigger fournit-il en cas d'erreur ?

L'Error Trigger transmet des données structurées sur l'exécution ayant échoué, à partir desquelles une notification pertinente peut être composée. Selon la documentation du nœud Error Trigger ces données comprennent notamment :

• execution.id et execution.url : identifiant et lien vers l'exécution ayant échoué, mais absents si l'erreur se produit déjà dans le nœud déclencheur de l'automatisation principale.
• execution.error : le message d'erreur proprement dit, y compris la trace de la pile (stack trace).
• execution.lastNodeExecuted : le nœud au niveau duquel l'exécution a échoué.
• execution.retryOf : présent uniquement si l'exécution ayant échoué était elle-même déjà une répétition.
• workflow.id et workflow.name : quel workflow est concerné.

De plus, le nœud Stop And Error permet de forcer délibérément une erreur, par exemple pour déclencher volontairement l'error workflow en cas de données invraisemblables, même si techniquement aucune erreur de nœud n'est présente.

Comment un appel ayant échoué peut-il être répété automatiquement via Retry ?

Avant même qu'une exécution soit considérée comme définitivement échouée et n'aboutisse dans l'error workflow, chaque nœud individuel peut être configuré pour d'abord répéter automatiquement plusieurs fois un appel ayant échoué. Pour cela, ouvrez le nœud concerné, passez aux paramètres et activez-y « Retry On Fail ». Avec « Max Tries », vous définissez combien de fois n8n répète la tentative, avec « Wait Between Tries (ms) » le temps d'attente entre les tentatives en millisecondes. Les deux valeurs sont limitées selon la documentation sur la gestion des limites de débit (rate limits) d'API : Max Tries à 5 maximum, Wait Between Tries à 5000 millisecondes maximum. En particulier pour les services soumis à des limites de débit, la documentation recommande de fixer le temps d'attente au-dessus de l'intervalle de limite de débit de l'API concernée, afin que la tentative suivante ne soit pas de nouveau rejetée.

Comment notifier votre équipe par e-mail ou Microsoft Teams ?

Après l'Error Trigger, ajoutez simplement dans l'error workflow le nœud par lequel la notification doit être envoyée. Pour les notifications par e-mail, le nœud Send Email convient, il nécessite une connexion avec des identifiants SMTP et envoie les messages au choix en texte, en HTML ou dans les deux formats. Pour le signalement dans un canal Teams, le nœud Microsoft Teams est disponible, il publie des messages dans un canal via des identifiants Microsoft enregistrés. Dans les deux cas, vous construisez le texte du message à partir des champs fournis par l'Error Trigger, par exemple le nom du workflow, le message d'erreur issu de execution.error et le lien vers l'exécution via execution.url, afin que les destinataires reconnaissent immédiatement quel processus est concerné et où ils peuvent consulter les détails. Toute personne souhaitant faire sécuriser un environnement n8n existant de manière techniquement fondée avec des error workflows, des stratégies de Retry et des notifications trouvera un soutien auprès des services n8n de NordFlux.

Questions fréquentes sur la gestion des erreurs dans n8n

Ai-je besoin d'un error workflow propre pour chaque workflow ?

Non, un seul error workflow peut être défini dans les paramètres de plusieurs workflows comme error workflow commun. Une automatisation de notification centrale suffit ainsi souvent pour de nombreux workflows productifs. Pour les processus particulièrement critiques, vous pouvez néanmoins créer un error workflow spécialisé avec sa propre logique d'escalade.

Puis-je tester un error workflow manuellement ?

Non, selon la documentation n8n, un error workflow ne peut pas être testé par une exécution manuelle, car l'Error Trigger ne réagit que lorsque l'exécution automatisée d'un autre workflow échoue réellement. Pour vérifier tout de même ce comportement, vous pouvez, dans un workflow de test, utiliser le nœud Stop And Error pour forcer délibérément une erreur et ainsi déclencher l'error workflow lié.

Quelle est la différence entre Retry On Fail et un error workflow ?

Retry On Fail répète automatiquement l'appel d'un seul nœud au sein de la même exécution, tandis que l'error workflow n'intervient que lorsque l'exécution entière a définitivement échoué malgré toutes les tentatives de répétition. Les deux mécanismes se complètent utilement : les retries absorbent les perturbations de courte durée telles que le dépassement des limites de débit, l'error workflow informe ensuite les personnes des échecs définitifs.

Le workflow gestionnaire d'erreurs doit-il être activé ou publié ?

Non, un workflow démarré exclusivement via l'Error Trigger n'a pas besoin, selon la documentation, d'être publié séparément pour fonctionner. Il est appelé automatiquement dès qu'un autre workflow le référence dans ses paramètres comme error workflow et échoue lui-même.