Un workflow d'erreur n8n est un second scénario qui démarre tout seul quand l'un de vos scénarios d'automatisation échoue, et qui vous envoie l'alerte avec le lien vers l'exécution en cause. C'est utile et peu coûteux. Mais il ne voit que les pannes qui font du bruit, et ce ne sont pas les plus chères.
Que fait exactement ce workflow d'erreur ?
Il prévient, avec de quoi enquêter. n8n est un outil qui enchaîne des tâches entre vos logiciels (une commande arrive, une facture part). Son gestionnaire d'erreurs commence par un nœud appelé Error Trigger, décrit dans la documentation officielle. Il reçoit le nom du workflow en échec, l'étape fautive, le message d'erreur et l'adresse de l'exécution.
Reste à décider quoi en faire : un message Slack ou un e-mail, plus une ligne dans un journal des échecs.
Côté prix, nous n'avons rien trouvé : la fonction est incluse dans n8n. Et chez Make ou Zapier ? Nos sources n'en disent rien.
Ce gestionnaire est-il vraiment "global" ?
Pas tout à fait. On le crée une fois, mais il faut le choisir à la main dans les réglages de chaque workflow (Options, Settings, Error workflow). Selon un post de la communauté n8n, un nouveau workflow n'hérite de rien. Un oubli, et l'échec passe sans un mot.
Deux détails de plus. Un test manuel ne déclenche rien. Et si c'est le déclencheur lui-même qui plante, il n'y a ni numéro ni lien d'exécution : le message d'alerte doit donc prévoir deux formes.
Et si tout est vert, mais faux ?
C'est la vraie question. Le trigger ne réagit qu'aux erreurs levées.
Prenons une PME de négoce dont un identifiant d'accès expire : l'outil répond par une liste vide, le scénario en conclut qu'il n'y a aucune commande à traiter. Tout est vert. Personne ne s'en aperçoit avant qu'un client appelle.
Les remèdes sont connus. Un contrôle sur les sorties vides qui force l'échec grâce au nœud Stop and Error. Et un "heartbeat", un signal régulier dont l'absence trahit une instance à l'arrêt. Mieux vaut un scénario qui avoue ne rien avoir trouvé qu'un scénario qui continue comme si de rien n'était.
Faut-il relancer automatiquement ce qui échoue ?
L'article dont nous partons le recommande : réessayer avec un délai croissant sur une erreur serveur, une seule fois après un accès expiré, jamais sur une donnée refusée. Le bon sens y est, mais la documentation officielle n'en parle pas. Prenez-le comme un avis de praticien.
Même prudence sur le test indépendant qu'il cite : 25 pannes planifiées captées sur 25, mais quatre autres types d'échec jamais remontés. L'auteur précise lui-même que ce site est financé par affiliation. Un seul banc d'essai, donc.
Qui relira le journal ?
Le journal des échecs ne vaut que s'il est relu, par exemple chaque semaine, pour repérer la même erreur sur la même étape. Sans relecteur, c'est un tiroir de plus.
Pour des entreprises de la région, de Berre-l'Étang à toute la Provence, nous pouvons le rattacher à un contrat d'hébergement et maintenance, pour que quelqu'un s'en charge vraiment. Nos scénarios n8n et Make vont dans le même sens, tout comme les relances de factures sans doublon.
- Le workflow d'erreur n8n alerte sur les erreurs levées, pas sur les résultats faux.
- Il se rattache à la main à chaque workflow : un oubli, et plus d'alerte.
- Ajoutez un contrôle des sorties vides et un heartbeat pour les pannes silencieuses.
- Le journal des échecs n'a de valeur que relu régulièrement.
Questions fréquentes
Un workflow d'erreur n8n est-il payant ?
Nous n'avons trouvé aucun tarif spécifique : c'est une fonction native de n8n, décrite dans sa documentation.
Un nouveau workflow est-il protégé automatiquement ?
Non. Selon un post de la communauté n8n, aucun gestionnaire n'est hérité : il faut le choisir dans les réglages de chaque workflow.
Le workflow d'erreur se déclenche-t-il lors d'un test manuel ?
Non, seule une exécution automatique en échec le déclenche. Pour le tester, il faut provoquer une vraie panne.