Error workflows, Retry On Fail et notifications Teams : comment construire une gestion des erreurs fiable dans n8n.
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.
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.
Vous créez d'abord un workflow autonome qui existe exclusivement pour le cas d'erreur, puis vous le liez au workflow à surveiller.
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.
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 :
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.
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.
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.
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.
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é.
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.
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.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
Comment sécuriser tes workflows n8n contre les erreurs 429 grâce au nœud Wait, au Batching, au Retry on Fail et à la pagination.
Si vous perdez la clé de chiffrement n8n, tous les identifiants enregistrés deviennent inutilisables. Voici comment sauvegarder correctement workflows, identifiants et clés.
Pin Data, Mock Data et mode Debug dans n8n : comment tester des workflows avec des données de test fixées plutôt qu'en direct contre des systèmes de production.
Un error workflow qui se déclenche vraiment de manière fiable, une logique de retry qui distingue les erreurs réelles des erreurs temporaires, et des notifications qui arrivent aux bonnes personnes : cela relève de l'exploitation professionnelle, pas d'un simple plus. NordFlux assure l'exploitation gérée de n8n, gestion des erreurs, monitoring et voies d'escalade comprises, pour qu'un workflow en échec ne reste pas silencieux jusqu'à ce qu'un client s'en aperçoive. Lors du premier échange, nous identifions où vos workflows restent aujourd'hui muets en cas d'erreur.
