Gérer les erreurs dans n8n : retry, error output et Error Trigger

Il y a un moment dans la vie d’un freelance qui automatise, et tu vas le vivre si ce n’est pas déjà fait : le workflow qui tourne nickel pendant trois semaines, et un matin tu découvres qu’il est en rouge depuis mardi. Une API qui a renvoyé un timeout, un champ vide qui a fait planter un nœud, et tout le reste qui ne s’est jamais exécuté. Personne n’a été prévenu. Le client te demande pourquoi ses leads ne sont pas remontés dans le CRM, et tu n’as aucune idée de depuis quand.

Ce scénario, je l’ai vu des dizaines de fois en accompagnant des gens sur n8n . Et 9 fois sur 10, le problème n’est pas le workflow en lui-même. Le problème, c’est qu’il a été construit en supposant que tout se passerait toujours bien. Or en production, ça ne se passe jamais toujours bien.

Dans ce guide je vais te montrer comment construire des workflows qui encaissent. Pas en théorie : on va s’appuyer sur un vrai workflow que j’utilise dans ma formation, avec son service qui plante volontairement, pour voir chaque mécanisme à l’œuvre. À la fin tu sauras exactement quel outil sortir selon le type d’erreur, et tu auras un filet de sécurité qui te prévient avant que le client ne le fasse.

La première chose à comprendre : toutes les erreurs ne se valent pas

C’est l’erreur de débutant la plus courante, et elle conditionne tout le reste. On a tendance à traiter « une erreur » comme un bloc unique, alors qu’il y a en réalité trois familles distinctes, et chacune appelle une réponse différente.

Type d’erreur	Exemple concret	La bonne réponse
Transitoire	Timeout réseau, rate-limit d’une API, service momentanément down	Réessayer (retry) : ça va probablement marcher au 2ᵉ coup
Métier (prévue)	Stock à zéro, paiement refusé, email invalide	Dévier : une branche de secours qui traite le cas proprement
Imprévue	Bug dans une expression, credential expiré, cas jamais anticipé	Alerter : un filet de sécurité global qui te prévient

Garde cette grille en tête, parce que les trois mécanismes qu’on va voir y répondent un par un. Le retry pour le transitoire. L’error output pour le métier. L’Error Trigger pour l’imprévu. Mélanger les trois, ou n’en utiliser qu’un seul pour tout, c’est exactement ce qui crée les workflows fragiles.

Le cas qu’on va dérouler : un contrôle de stock avant expédition

Pour rendre tout ça concret, je prends un workflow de mon parcours n8n, un fil rouge e-commerce que j’appelle ShopFlow. L’étape qui nous intéresse fait une chose simple : avant d’expédier une commande, elle vérifie le stock auprès d’un service interne, puis bloque les articles en rupture.

Trois commandes passent dans le flux :

return [
  { json: { id: 'CMD-201', produit: 'Clavier', sku: 'KB-01', stock_dispo: 12 } },
  { json: { id: 'CMD-202', produit: 'Souris',  sku: 'MS-02', stock_dispo: 0  } },
  { json: { id: 'CMD-203', produit: 'Écran',   sku: 'SC-03', stock_dispo: 3  } }
];

Et là où ça devient intéressant, c’est que j’ai rendu le service de stock volontairement instable. Une fois sur deux et quelques, il échoue avec un timeout :

// Service de stock INSTABLE : il échoue parfois (timeout transitoire).
if (Math.random() < 0.6) {
  throw new Error('Timeout service stock (transitoire)');
}
// Si on passe, l'appel a réussi (éventuellement après 1-2 retries)
const a = $json;
return { json: Object.assign({}, a, { stock_verifie: true }) };

On a donc nos deux premiers types d’erreurs réunis dans un seul workflow. Le timeout du service, c’est du transitoire. La Souris à stock_dispo: 0, c’est du métier. Voyons comment n8n traite chacun.

Mécanisme 1 : le retry automatique pour les erreurs transitoires

Quand un nœud appelle une API ou un service réseau, l’échec ponctuel fait partie de la vie. Le réseau hoquette, le serveur d’en face est surchargé une seconde, et l’appel d’après serait passé sans problème. C’est exactement le cas où tu ne veux pas que ton workflow s’arrête. Tu veux qu’il réessaie.

n8n a ça intégré dans chaque nœud. Tu ouvres le nœud, onglet Settings, et tu trouves trois réglages.

Réglage (onglet Settings)	Ce qu’il fait	Valeur conseillée
Retry On Fail	Active les tentatives automatiques en cas d’échec	Activé sur les nœuds réseau
Max. Tries	Nombre total de tentatives avant d’abandonner	2 à 3 suffisent presque toujours
Wait Between Tries (ms)	Délai d’attente entre deux tentatives	1000 à 2000 ms

Sur mon nœud Vérifier stock, la config ressemble à ça côté JSON (ce que tu obtiens si tu exportes le workflow) :

{
  "retryOnFail": true,
  "maxTries": 3,
  "waitBetweenTries": 1000
}

Concrètement : le service échoue, n8n attend une seconde, réessaie. S’il échoue encore, il attend de nouveau et retente. Au bout de 3 essais ratés, il abandonne et le nœud passe en erreur. Avec un taux d’échec de 60% sur mon service de démo, le calcul est vite fait : la probabilité que les trois tentatives ratent d’affilée tombe autour de 20%. Le retry transforme donc un workflow qui plante une fois sur deux en un workflow qui passe quatre fois sur cinq.

Petite limite bonne à connaître : les réglages natifs plafonnent à 5 tentatives et un délai max de 5000 ms par nœud. Pour la grande majorité des cas, c’est largement suffisant. Si tu as besoin de plus, ou d’un délai qui augmente à chaque essai, il y a une technique maison qu’on verra en fin de guide.

Le piège qui fait perdre des heures : retry + On Error ensemble

Voilà un truc que personne ne te dit et qui crée une confusion totale quand tu débutes. Si tu actives Retry On Fail sur un nœud, et que dans le même temps tu mets On Error sur une des options « Continue », alors tes réglages Max. Tries et Wait Between Tries sont purement et simplement ignorés.

Le nœud n’essaie qu’une fois, échoue, et part directement sur la sortie d’erreur. Pas de retry du tout. Le retry n’agit que si On Error est resté sur Stop Workflow.

C’est précisément pour ça que dans ShopFlow le retry et la branche de secours sont sur deux nœuds distincts. Le nœud Vérifier stock porte le retry (erreur transitoire). Le nœud Contrôle rupture qui suit porte l’error output (erreur métier). Chacun son job.

Mécanisme 2 : l’error output pour les erreurs métier

La rupture de stock, ce n’est pas un bug. C’est un cas business parfaitement normal qui va arriver tous les jours. Tu ne veux donc surtout pas réessayer (le stock ne va pas réapparaître en réessayant), et tu ne veux pas non plus que ça casse le traitement des deux autres commandes. Tu veux dévier cette commande vers un traitement spécifique : la mettre en attente de réapprovisionnement.

Pour ça, le réglage On Error du nœud (toujours dans l’onglet Settings) propose trois comportements.

Option « On Error »	Comportement	Quand l’utiliser
Stop Workflow (défaut)	L’erreur arrête tout le workflow	Erreur grave qui doit tout bloquer
Continue (using regular output)	Le nœud continue, l’item fautif passe quand même	Erreur que tu peux ignorer sans conséquence
Continue (using error output)	Une 2ᵉ sortie « erreur » s’ouvre, les items fautifs y partent	Erreur métier que tu veux traiter à part

C’est la troisième option qui nous intéresse. Quand tu la choisis, le nœud affiche deux sorties : la sortie normale (les items qui ont réussi) et une sortie rouge « erreur » (les items qui ont échoué). Tu branches chaque sortie où tu veux.

Dans mon nœud Contrôle rupture, je lève une erreur explicite si le stock est insuffisant :

const a = $json;
if (a.stock_dispo < 1) {
  throw new Error('Rupture de stock sur ' + a.sku + ' (' + a.produit + ')');
}
return { json: Object.assign({}, a, { statut_stock: 'disponible' }) };

Et côté config, le nœud est réglé sur :

{ "onError": "continueErrorOutput" }

Résultat sur mes trois commandes :

• CMD-201 (Clavier, stock 12) part sur la sortie normale, direction Préparer expédition.
• CMD-203 (Écran, stock 3) pareil, expédition préparée.
• CMD-202 (Souris, stock 0) lève l’erreur, part sur la sortie d’erreur, direction Mise en attente de réappro.

La commande en rupture est traitée proprement, et les deux autres ne sont pas impactées. C’est ça, la différence entre un workflow qui plante au premier grain de sable et un workflow qui encaisse.

Mécanisme 3 : l’Error Trigger, ton filet de sécurité global

On a couvert le transitoire et le métier. Reste le plus sournois : l’erreur que tu n’as pas prévue. Le retry qui a épuisé ses 3 tentatives. Le credential qui a expiré pendant la nuit. L’API qui a changé son format de réponse. Le cas auquel tu n’avais tout simplement pas pensé en construisant le workflow.

Par définition, tu ne peux pas mettre une branche de secours sur un cas que tu n’as pas anticipé. C’est là qu’intervient l’Error Trigger, et c’est le mécanisme que je vois le moins utilisé alors que c’est le plus important des trois.

Le principe : tu crées un workflow séparé, dédié, dont le tout premier nœud est un Error Trigger. Ce workflow ne fait rien de métier. Son seul rôle, c’est de se déclencher automatiquement à chaque fois qu’un autre workflow plante sans avoir rattrapé l’erreur.

Voici comment le brancher, en trois étapes :

1. Crée un nouveau workflow et pose un nœud Error Trigger comme déclencheur. Ne mets rien d’autre pour l’instant.
2. Branche derrière une notification : un nœud Slack ou Gmail qui t’envoie les détails. L’Error Trigger fournit automatiquement le nom du workflow en faute, le nœud où ça a cassé, et le message d’erreur.
3. Désigne ce workflow comme filet : dans les Settings de chacun de tes workflows de production, il y a un champ Error Workflow. Tu y sélectionnes ton workflow d’alerte. À partir de là, dès qu’une erreur non rattrapée survient, ton alerte se déclenche.

Un exemple de message Slack que tu peux composer avec les données de l’Error Trigger :

🔴 Workflow en erreur : {{ $json.workflow.name }}
Nœud fautif : {{ $json.execution.lastNodeExecuted }}
Message : {{ $json.execution.error.message }}
Heure : {{ $json.execution.startedAt }}

À partir de ce moment, tu ne découvres plus tes pannes trois jours trop tard. Tu reçois un ping en temps réel, avec assez de contexte pour savoir où regarder. Et tu peux brancher un seul workflow d’alerte comme filet pour toute ton instance : un seul Error Workflow protège des dizaines de workflows de prod.

Pour aller plus loin : le backoff exponentiel maison

Je te parlais du plafond de 5 tentatives et 5000 ms sur le retry natif. Dans 95% des cas tu n’en as pas besoin. Mais si tu tapes une API qui rate-limit agressivement (certaines APIs te bannissent temporairement si tu insistes trop vite), la bonne pratique est le backoff exponentiel : attendre 1 seconde, puis 2, puis 4, puis 8. Chaque échec double le délai, ce qui laisse le service respirer.

Le retry natif ne fait pas ça (son délai est fixe). Mais tu peux le reconstruire à la main avec trois nœuds : un Set pour stocker le compteur de tentatives, un IF pour vérifier si tu as atteint la limite, et un Wait dont la durée est calculée par une expression du genre {{ 2 ** $json.tentative * 1000 }}. Tu boucles tant que l’appel échoue et que le compteur n’a pas atteint ton maximum.

C’est plus de travail à câbler, donc réserve cette technique aux cas où le retry natif ne suffit vraiment pas. Pour 9 workflows sur 10, Retry On Fail avec 3 tentatives fait parfaitement le boulot.

Ta checklist robustesse, à appliquer sur chaque workflow de prod

Avant de mettre un workflow en production, passe-le au crible de ces questions. C’est exactement la grille que j’utilise pour mes propres automatisations clients.

Question	Si la réponse est non
Mes nœuds réseau (HTTP, API) ont-ils Retry On Fail activé ?	Active-le avec Max. Tries = 3
Mes cas métier connus ont-ils une branche de secours (error output) ?	Ajoute un onError + traitement dédié
Ai-je un workflow Error Trigger branché comme Error Workflow ?	Crée-le, c’est ta priorité numéro 1
Suis-je notifié quand un workflow plante (Slack, email) ?	Branche la notif derrière l’Error Trigger
Ai-je vérifié que retry et error output ne sont pas sur le même nœud ?	Sépare-les sur deux nœuds distincts

Si tu coches ces cinq cases sur chacun de tes workflows, tu es déjà au-dessus de l’immense majorité des automatisations que je vois passer. La robustesse, ce n’est pas un sujet avancé réservé aux experts. C’est cinq réflexes que tu prends dès le départ, et qui te font gagner un temps fou en SAV.

En résumé

La gestion des erreurs dans n8n tient en trois outils, un par type d’erreur. Le retry (Retry On Fail / Max. Tries / Wait Between Tries) pour les pannes transitoires de réseau. L’error output (On Error → Continue using error output) pour les cas métier que tu veux dévier sans tout casser. L’Error Trigger branché en Error Workflow pour être alerté de tout ce que tu n’as pas vu venir.

Le piège à éviter : ne mets jamais le retry et l’error output sur le même nœud, sinon le retry est ignoré. Sépare les responsabilités, comme dans le workflow ShopFlow qu’on a déroulé, et chaque mécanisme fait son travail.

Si tu veux construire ce genre de workflows robustes pas à pas, avec les exercices ShopFlow complets (le contrôle de stock instable, les branches de secours, l’Error Trigger global), c’est exactement ce que je couvre dans ma formation n8n. On part de zéro et on va jusqu’aux patterns que j’utilise en production chez mes clients.

Et pour creuser le détail de chaque réglage, la doc officielle n8n sur l’error handling est la référence à garder sous le coude.