Gérer les erreurs dans n8n : Retry, Continue on Error et Error Workflow expliqués

Un workflow n8n qui échoue en silence, c'est un email client jamais envoyé, un document jamais ingéré dans votre base RAG, ou une piste d'audit qui se troue sans que personne ne le remarque avant le contrôle. n8n propose trois mécanismes de gestion des erreurs, souvent mal distingués : le retry automatique par node, l'option « Continue on Error », et le workflow d'erreur dédié. Bien combinés, ils transforment une automatisation fragile en système qui encaisse les pannes réseau, les rate limits d'API et les documents malformés — et qui vous prévient quand ça compte vraiment.

Trois mécanismes, trois usages différents

Il est tentant de tout gérer avec une seule case à cocher. En pratique, chaque mécanisme répond à un problème précis :

• Retry On Fail — pour les erreurs transitoires : une API momentanément indisponible, un timeout réseau, un rate limit. Le node réessaie tout seul, le workflow continue comme si de rien n'était.
• On Error : Continue — pour les erreurs non bloquantes : un enregistrement mal formé sur mille, une ligne à ignorer sans interrompre le lot entier.
• Error Trigger + Error Workflow — pour les erreurs définitives : quand tout le reste a échoué, quelqu'un doit être prévenu, avec assez de contexte pour agir vite.

Les trois se combinent sur un même workflow : retry en première ligne, Continue on Error pour ne pas bloquer un traitement par lots, Error Workflow en filet de sécurité final.

Retry On Fail : le bon réflexe, avec une réserve importante

Dans les Settings de chaque node (icône en haut du panneau de configuration), activez Retry On Fail. Deux réglages suivent :

• Max Tries — nombre de tentatives, 2 à 3 pour commencer.
• Wait Between Tries — délai en millisecondes entre deux essais. Sur un rate limit d'API, 1000 ms est un minimum ; pour les modèles d'embeddings ou de génération, montez plutôt à 3000-5000 ms.

C'est le réglage le plus rentable de tout ce guide sur un node HTTP Request ou un appel à un modèle IA : la majorité des échecs en production sont des erreurs 429 ou 503 passagères, pas des bugs. Réessayer trois fois avec un court délai résout silencieusement l'immense majorité des cas.

La réserve à connaître : n'activez jamais Retry On Fail sur un node qui produit un effet de bord non répétable — envoi d'email, message Slack, insertion en base sans contrainte d'unicité. Un timeout après que l'action a réellement eu lieu côté serveur (mais avant que la réponse revienne à n8n) déclenchera un retry... et une deuxième action. Sur ces nodes, laissez l'échec remonter tel quel, ou sécurisez l'écriture avec une clé unique côté base de données avant d'envisager le retry.

Continue on Error : traiter un lot sans qu'un élément le bloque

Chaque node propose, toujours dans ses Settings, un champ On Error avec trois valeurs :

• Stop Workflow (par défaut) — l'exécution s'arrête net, l'erreur remonte.
• Continue — le workflow poursuit sur la sortie normale du node, avec un champ d'erreur mêlé aux données.
• Continue Using Error Output — le node gagne une seconde sortie, dédiée aux échecs, séparée de la sortie de succès.

En pratique, préférez systématiquement la troisième option dès que vous traitez plusieurs éléments (une boucle sur des emails, des lignes Supabase, des documents à ingérer). Elle vous laisse brancher deux chemins distincts : les succès continuent normalement, les échecs partent vers un node qui les journalise ou les met de côté pour un traitement manuel — sans jamais interrompre le lot entier pour un seul élément fautif.

C'est exactement le pattern utilisé dans un pipeline d'ingestion de documents pour un assistant RAG : sur cent PDF à vectoriser, si le vingtième est corrompu ou illisible, vous voulez que les quatre-vingt-dix-neuf autres s'ingèrent quand même, et que le PDF fautif atterrisse dans une liste à examiner — pas que tout le batch s'arrête.

Error Trigger et Error Workflow : le filet de sécurité global

Retry et Continue on Error gèrent le cas par cas, node par node. Il manque une dernière ligne de défense : que faire quand un workflow échoue vraiment, malgré tout ?

C'est le rôle du Error Trigger (errorTrigger), un node déclencheur spécial qu'on place dans un workflow séparé, dédié à la gestion d'erreurs. Ce workflow d'erreur se rattache ensuite à un ou plusieurs workflows métier via Settings du workflow → Error Workflow (dans le menu ⋯ en haut à droite de l'éditeur), où vous sélectionnez le workflow qui doit se déclencher en cas d'échec.

Quand un workflow métier échoue sans qu'aucun de ses nodes n'ait absorbé l'erreur en Continue on Error, n8n déclenche automatiquement l'Error Trigger du workflow associé, avec un objet contenant :

{
  "execution": {
    "id": "1847",
    "url": "https://votre-instance.app/workflow/abc123/executions/1847",
    "error": {
      "message": "ETIMEDOUT: connect ETIMEDOUT",
      "stack": "..."
    }
  },
  "workflow": {
    "id": "abc123",
    "name": "Tri des emails entrants"
  }
}

À partir de là, un workflow d'erreur minimal ressemble à ceci : Error Trigger → node de mise en forme → Slack ou Telegram. Le message envoyé mérite d'être construit avec soin, car c'est lui que vous lirez à 22h un vendredi :

🔴 Échec : {{ $json.workflow.name }}
Erreur : {{ $json.execution.error.message }}
Voir l'exécution : {{ $json.execution.url }}

Un même workflow d'erreur peut être partagé par tous vos workflows métier : c'est en général plus lisible qu'un Error Trigger dupliqué dans chacun. Réservez un canal Slack dédié aux alertes n8n plutôt que de les mêler à votre canal général — le bruit tue l'attention bien plus vite que le silence.

Journaliser les erreurs, pas seulement les afficher

Une alerte Slack se perd dans le défilement au bout de quelques jours. Pour tout workflow soumis à une exigence de traçabilité — c'est le cas de la plupart des automatisations qui touchent des données personnelles ou des processus métier sensibles — insérez aussi chaque échec dans une table Supabase dédiée, avant ou en parallèle de l'alerte : workflow_name, execution_id, error_message, occurred_at. C'est la même logique que la piste d'audit décrite dans notre guide piste d'audit RGPD avec n8n et Supabase : un contrôleur ou un client qui demande « avez-vous eu des incidents sur ce traitement en mars ? » mérite une réponse en une requête SQL, pas une recherche dans l'historique Slack.

Pensez aussi au paramètre Save Data On Error, dans les Settings du workflow (par défaut sur Save) : il conserve les données d'entrée de l'exécution ayant échoué, consultables depuis l'interface d'exécutions. Sans lui, vous savez *qu'*une erreur a eu lieu, mais pas sur quelles données — un détail qui change tout au moment de déboguer.

Les erreurs qui font perdre une soirée

• Continue on Error posé partout par réflexe : le workflow ne s'arrête plus jamais, mais les erreurs s'accumulent invisibles — jusqu'au jour où le client demande pourquoi la moitié des dossiers n'a jamais été traitée.
• Retry sur un node à effet de bord : doublons de messages, d'emails ou de lignes en base, difficiles à détecter après coup.
• Un seul Error Trigger dans le workflow métier lui-même plutôt que dans un workflow séparé : il ne se déclenche pas si l'échec survient avant que ce node soit atteignable, notamment sur une panne du trigger initial.
• Aucune alerte configurée : le workflow échoue, personne ne le sait, jusqu'à ce qu'un client s'en aperçoive à votre place.
• Save Data On Error désactivé pour économiser de l'espace : au moment où vous en avez besoin, l'information a disparu.

Construire cette fiabilité sans repartir de zéro

Chacun des quatre workflows du Pack Inbox IA (79 €) embarque déjà un retry réglé sur les appels IA et IMAP, et une remontée d'erreur vers Slack ou Telegram. Le Pack Conformité & Audit (149 €) va plus loin avec la journalisation systématique, erreurs comprises, dans une table Supabase append-only — exactement le pattern décrit ci-dessus, prêt à l'emploi. Et si vous voulez les trois familles de workflows avec cette rigueur de base déjà intégrée, le Bundle FlowKit Complet (269 €) regroupe l'ensemble.

Un workflow n8n n'est jamais terminé le jour où il fonctionne en test : il l'est le jour où vous pouvez faire confiance à son silence — sachant que s'il échouait, vous le sauriez avant votre client.