n8n : workflow d'erreur (on error)

Ce que fait réellement un workflow d'erreur n8n

Un workflow d'erreur n8n est un workflow distinct que n8n exécute lorsqu'une exécution d'un autre workflow échoue. Selon la documentation de n8n sur la gestion des erreurs, on le construit en créant un nouveau workflow qui commence par le nœud Error Trigger, puis en ouvrant les paramètres du workflow à surveiller pour y sélectionner ce nouveau workflow comme workflow d'erreur. Un même workflow d'erreur peut être assigné à de nombreux workflows : les équipes maintiennent donc souvent un gestionnaire unique et partagé plutôt qu'un par automatisation.

La façon la plus utile de le voir est comme un point d'accroche, pas comme un mécanisme de réparation. L'exécution échouée reste en échec. Ce que vous gagnez, c'est un moment fiable où n8n vous transmet des informations sur l'échec, et un endroit pour décider de la suite : qui est prévenu, ce qui est consigné et si quelque chose est relancé. Les équipes qui considèrent le workflow d'erreur comme un outil qui traite les erreurs tout seul découvrent souvent, en plein incident, qu'il s'est contenté de les signaler.

Ce que reçoit l'Error Trigger, et ce qui manque

La documentation présente les données que l'Error Trigger reçoit pour une exécution échouée : les identifiants et un lien vers l'exécution, le message d'erreur et la pile d'appels, le dernier nœud exécuté, le mode d'exécution, ainsi que l'ID et le nom du workflow. Lorsque l'échec se produit dans le nœud déclencheur lui-même, la structure est différente et réduite, car il n'existe parfois aucune exécution enregistrée vers laquelle pointer. Votre gestionnaire doit gérer ces deux formes au lieu de supposer que chaque champ est toujours présent.

Ce que la charge utile ne contient pas, c'est le sens métier. Elle vous indique qu'un nœud a échoué, pas quelle commande client, quelle facture ou quel ticket est concerné, et les messages d'erreur des services tiers sont souvent laconiques. Si votre alerte doit dire ce qui est cassé et pour qui, vous devez ajouter ce contexte vous-même, par exemple en associant les noms de workflows à des responsables et à des descriptions d'impact dans une table de correspondance que le gestionnaire peut lire.

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

Un workflow d'erreur ne réagit qu'aux exécutions que n8n considère comme échouées. Cela laisse plusieurs angles morts faciles à négliger quand les premières alertes arrivent et que tout semble couvert.

La documentation décrit aussi le nœud Stop And Error, qui permet de faire échouer volontairement une exécution lorsqu'une condition que vous définissez n'est pas remplie. C'est l'outil principal pour combler l'écart entre un workflow qui a techniquement réussi et un workflow qui a fait ce qu'il fallait.

• Un workflow qui s'exécute correctement mais écrit des données fausses ou vides ne produit aucun échec, sauf si vous ajoutez vos propres contrôles.
• Un workflow qui ne démarre jamais, par exemple un webhook que personne n'appelle, ne crée rien auquel le workflow d'erreur pourrait réagir.
• Le workflow d'erreur est lui-même un workflow et peut échouer : s'il publie dans un outil de messagerie dont les identifiants ont expiré, l'alerte disparaît sans bruit.
• Le comportement et les champs disponibles peuvent changer d'une version de n8n à l'autre : vérifiez les détails dans la documentation actuelle correspondant à votre instance.

Concevoir le gestionnaire autour de la détection, du contexte, de la reprise et de l'apprentissage

La détection précoce suppose que chaque workflow de production ait un workflow d'erreur assigné, et que vous vérifiiez cette assignation à chaque création ou import de workflow. Un gestionnaire partagé n'est utile que si rien ne lui échappe. Associez-le à des contrôles Stop And Error sur les résultats qui comptent, par exemple zéro ligne renvoyée là où au moins une est attendue.

Un contexte exploitable signifie que l'alerte répond à trois questions sans que personne n'ait à ouvrir n8n : quel workflow, qu'est-ce qui a échoué et qui en est responsable. Incluez le lien vers l'exécution pour que la personne qui intervient arrive directement sur l'exécution en échec. Une reprise maîtrisée signifie que les relances sont délibérées. Relancer automatiquement un workflow qui envoie des paiements ou des e-mails peut doubler les dégâts : limitez donc les relances automatiques aux étapes que vous savez pouvoir répéter sans risque, et confiez tout le reste à une personne.

L'amélioration après incident signifie que le gestionnaire enregistre aussi une trace dans un endroit durable, pas seulement un message de discussion qui disparaît dans le fil. Des échecs récurrents sur le même nœud sont un signal de conception : un délai d'expiration manquant, un appel d'API fragile ou une entrée qui devrait être validée plus tôt.

Exemple : une aide à la décision pour un workflow de synchronisation de commandes en échec

Exemple (hypothétique) : un workflow synchronise toutes les dix minutes les nouvelles commandes d'une boutique vers un outil comptable. Le workflow d'erreur reçoit un échec dont le dernier nœud exécuté est l'appel à l'API comptable, avec un message qui mentionne une erreur d'authentification. Le gestionnaire identifie le responsable, publie une alerte avec le lien vers l'exécution et consigne l'incident. Comme l'étape crée des écritures financières, il ne relance pas automatiquement.

La checklist ci-dessous est un moyen pratique de décider ce que votre propre gestionnaire doit faire pour chaque workflow qu'il couvre.

• Un workflow d'erreur est-il assigné dans les paramètres de ce workflow ? Sinon, rien ne se déclenchera.
• Le gestionnaire gère-t-il les échecs au niveau du déclencheur, qui n'ont pas de détails d'exécution ?
• L'alerte nomme-t-elle le responsable et l'impact métier, et pas seulement le nœud ?
• L'étape en échec peut-elle être répétée sans risque ? En cas de doute, prévenez une personne au lieu de relancer.
• Existe-t-il un contrôle Stop And Error pour le résultat le plus important ?
• Chaque incident est-il consigné quelque part où vous le relirez plus tard ?
• L'alerte évite-t-elle de copier des données sensibles de la charge utile dans des canaux largement accessibles ?

La place d'une supervision dédiée, et ses limites

Un workflow d'erreur est une brique solide, mais il vit à l'intérieur de la plateforme qu'il surveille et ne voit que ce que n8n signale comme échoué. Datvero aborde la question de l'extérieur : il est conçu pour surveiller les automatisations sur n8n, ainsi que sur Make et Zapier, et pour transformer les échecs en alertes dotées d'un contexte de diagnostic suffisant pour agir, avec un historique des incidents dont on peut tirer des leçons. C'est un complément à un workflow d'erreur bien construit, pas un remplacement.

Quel que soit l'outil utilisé, la fiabilité repose toujours sur la configuration de votre instance n8n et sur la manière dont votre équipe réagit aux alertes. Une couche de supervision ne peut pas compenser des workflows d'erreur non assignés ou des responsabilités floues. Les alertes et les étapes de reprise doivent aussi respecter vos contrôles d'accès et vos obligations de protection des données : évitez donc de transférer des charges utiles brutes contenant des données personnelles là où elles n'ont pas leur place.