Erreur n8n : le workflow qui vous prévient avant le client

Une erreur n8n ne prévient personne : si vous ne construisez pas l’alerte vous-même, n8n ne vous signalera jamais l’échec d’un workflow. Le client, lui, s’en aperçoit trois jours après, quand l’opportunité est déjà perdue. Voici le workflow de notification que je déploie chez tous mes clients : il capte les erreurs techniques et les erreurs métier, les range dans une Data Table et vous alerte par Slack ou par email.

16:32

Les deux familles d’erreurs dans un workflow n8n

Avant de construire, séparez les deux cas : ils n’ont pas la même cause et ne suivent pas le même chemin.

L’erreur métier vient d’une manipulation qui ne correspond pas à ce qui est attendu. Exemple de la vidéo : un workflow surveille un dossier Google Drive et attend un fichier Excel. L’utilisateur dépose un CSV. Rien ne plante : le traitement ne doit simplement pas tourner, et quelqu’un doit le savoir (« ce fichier n’est pas au bon format »).

L’erreur technique vient d’un nœud qui plante : une API qui ne répond pas, une URL fausse, un paramétrage raté. Là, n8n arrête l’exécution. Et si vous n’avez rien prévu, il ne vous envoie aucune notification.

Dans les deux cas, c’est à vous de mettre en place l’alerte. Le système tient en deux workflows :

1. Le workflow surveillé, celui qui fait le travail pour le client.
2. Le workflow « Notification », qui reçoit toutes les erreurs et prévient la bonne personne.

Le workflow de notification : deux déclencheurs, un seul circuit

Le workflow Notification a deux points d’entrée :

• l’Error Trigger, lancé par n8n quand un workflow surveillé tombe en erreur technique ;
• le déclencheur When Executed by Another Workflow, appelé à la main par vos workflows quand ils détectent une erreur métier.

Les deux branches se rejoignent ensuite sur les mêmes nœuds : normalisation, enregistrement dans la Data Table, choix du canal, envoi. Vous écrivez la mise en forme une seule fois, et elle sert à tous les workflows de toutes vos instances.

Brancher l’Error Trigger sur les erreurs techniques

L’Error Trigger ne se déclenche pas tout seul. Dans chaque workflow à surveiller, ouvrez le menu des trois points, puis Settings, et choisissez Notification dans le champ Error workflow. Enregistrez. Sans ce réglage, le workflow Notification ne sera jamais appelé. Un même workflow d’erreur peut servir à autant de workflows que vous voulez.

Les autres réglages de cet écran sont détaillés dans le guide pour créer un workflow n8n.

Pourquoi votre test manuel ne déclenche rien

C’est le piège qui fait croire que le système ne marche pas. Si vous lancez le workflow surveillé à la main dans l’éditeur, le workflow d’erreur ne part pas. La documentation de n8n le confirme : un workflow d’erreur ne se teste pas par une exécution manuelle.

Dans la vidéo, le test se fait donc en conditions réelles : un déclencheur horaire réglé une minute plus tard, un nœud HTTP Request qui appelle une URL qui n’existe pas, et le workflow en production. À 16 h 47, l’exécution tombe en erreur, et quelques secondes plus tard une exécution apparaît dans Notification, arrivée par l’Error Trigger.

Depuis n8n 2.0, « en production » veut dire publié : le bouton Publish a remplacé l’interrupteur Active que l’on voit dans la vidéo, tournée en décembre 2025.

Ce que reçoit l’Error Trigger

L’exécution reçue contient tout ce qu’il faut pour retrouver la panne :

• workflow.name et workflow.id : le workflow en cause ;
• execution.id et execution.url : l’exécution, et le lien pour l’ouvrir ;
• execution.lastNodeExecuted : le nœud qui a planté ;
• execution.error.message : le message d’erreur ;
• execution.mode : le mode de lancement.

Deux cas particuliers, d’après la documentation de n8n (vérifiée le 27/10/2026). L’id et l’URL de l’exécution n’existent que si l’exécution est sauvegardée en base. Et si c’est le déclencheur du workflow surveillé qui plante, les détails arrivent dans trigger et non dans execution, sans id d’exécution.

Préparer le message

Juste après l’Error Trigger, un nœud Edit Fields prépare cinq valeurs : le canal, le titre, le message, le type et le destinataire. Le type prend l’une des trois valeurs : erreur, alerte ou info.

canal         slack
titre         Erreur technique : {{ $json.workflow.name }}
message       Exécution {{ $json.execution.id }}
              Nœud : {{ $json.execution.lastNodeExecuted }}
              Erreur : {{ $json.execution.error.message }}
type          erreur
destinataire  alertes@votre-domaine.fr

Pour les erreurs techniques, le canal et le destinataire, c’est vous : c’est vous qui allez réparer.

Remonter une erreur métier par un sous-workflow

L’erreur métier, n8n ne la voit pas : pour lui, le workflow s’est bien passé. C’est donc le workflow surveillé qui la signale.

Reprenons le dossier Google Drive. Un nœud If compare le type du fichier reçu (son mime type) à celui d’un fichier Excel. Si le fichier n’en est pas un, la branche « faux » appelle le nœud Execute Sub-workflow, avec Notification comme workflow cible. Vous y remplissez les mêmes cinq champs :

• message : « Le fichier exemple.csv n’est pas un fichier Excel » ;
• type : erreur ;
• titre : « Format de fichier incompatible » ;
• canal : email ;
• destinataire : la personne qui a déposé le fichier, ou rien.

La différence avec l’erreur technique tient au destinataire. L’erreur métier part souvent chez l’utilisateur du client, celui qui peut la corriger en redéposant le bon fichier. Vous n’avez rien à faire.

Côté Notification, le déclencheur When Executed by Another Workflow reçoit ces champs. Déclarez-les dans ses réglages (mode « Define using fields below ») : n8n les propose alors au nœud qui l’appelle, et vous ne les oubliez plus.

Deux remarques sur n8n 2.x. Publiez le workflow Notification : le guide des changements de la 2.0 demande qu’un sous-workflow appelé en production le soit. Et si vous préférez qu’une erreur métier fasse vraiment échouer l’exécution, le nœud Stop and Error la transforme en erreur technique, qui part alors par l’Error Trigger. Vous perdez au passage le choix du destinataire : l’alerte arrive chez vous, pas chez l’utilisateur.

Normaliser, pour que les deux chemins parlent la même langue

Les deux branches arrivent sur un même nœud de normalisation. Il remplit ce qui manque et calcule la mise en forme, ce qui évite qu’un champ vide casse l’envoi.

// Nœud Code, mode « Run Once for Each Item »
const couleurs = { info: '#2F80ED', alerte: '#F2994A', erreur: '#EB5757' };
const type = $json.type || 'info';

return {
  json: {
    message: $json.message,
    type,
    titre: $json.titre || 'Notification n8n',
    canal: $json.canal || 'email',
    destinataire: $json.destinataire || 'alertes@votre-domaine.fr',
    couleur: couleurs[type] || couleurs.info,
  },
};

Trois règles à garder :

1. Sans type reçu, le message est traité comme une info : rien ne part en rouge par accident.
2. Chaque type a sa couleur dans le bloc Slack : bleu pour une info, orange pour une alerte, rouge pour une erreur. Dans la vidéo, un emoji s’ajoute au titre selon le même principe.
3. Un destinataire par défaut est prévu. L’erreur métier de la démonstration arrive sans destinataire. Sans valeur par défaut, l’email ne partirait pas, et l’erreur passerait de nouveau inaperçue.

Garder l’historique dans une Data Table n8n

Avant d’envoyer quoi que ce soit, chaque erreur est enregistrée dans une Data Table de n8n. Une Data Table, c’est une sorte de Google Sheet intégrée à n8n : pas de fichier à garder ailleurs, pas d’accès à créer.

Pour la créer : depuis l’écran d’accueil (Overview), onglet Data tables, bouton Create Data table. Ajoutez les colonnes avec le +. Dans la vidéo, il y en a trois : type, titre, message. Dans le workflow, un nœud Data Table en opération Insert ajoute une ligne à chaque passage.

Résultat : toutes les erreurs de tous les workflows reliés atterrissent au même endroit. Dans la démonstration, la ligne « exemple.csv » apparaît dans la table quelques secondes après le dépôt du fichier.

Une limite que la vidéo ne montre pas. Selon la documentation de n8n (27/10/2026), toutes les Data Tables d’une instance partagent 200 MiB par défaut. n8n prévient à 80 %, et à 100 % les insertions échouent. Un journal d’erreurs qui grossit sans fin finirait donc par faire planter… le workflow qui signale les pannes. Deux parades :

• un petit workflow planifié qui supprime chaque semaine les lignes de plus de 90 jours (opération Delete du nœud Data Table) ;
• en self-hosted, une limite plus haute avec la variable N8N_DATA_TABLES_MAX_SIZE_BYTES (l’hébergement est expliqué dans l’article sur n8n gratuit).

Vous préférez une Google Sheet ou votre propre base ? Le principe ne change pas : remplacez le nœud Data Table.

Envoyer sur Slack, par email ou ailleurs

Un nœud Switch lit le canal et oriente vers le bon envoi. Dans la vidéo, deux sorties : email et Slack. Vous en ajoutez une par canal utile au client : Telegram, Teams, WhatsApp.

Pour Slack, l’envoi passe par un bot. Créez la connexion depuis le nœud Slack (Create new credential) : la documentation de n8n décrit chaque étape côté Slack. Elle est en anglais ; demandez à ChatGPT ou Claude de vous la résumer en français si besoin.

Le message reçu sur Slack contient le titre (« Erreur interne »), le nom du workflow, l’identifiant de l’exécution, le message d’erreur (ici, l’URL appelée n’est pas valide), le nœud en cause et l’heure. Avec ces cinq informations, vous ouvrez le bon workflow sur la bonne exécution sans chercher.

L’email, lui, reprend le titre dans l’objet et le message dans un corps mis en couleur selon le type. C’est ce qui le rend lisible pour l’utilisateur du client, qui n’ouvrira jamais n8n.

Ce que ça change pour vous, freelance

En démonstration, ce workflow passe presque inaperçu. Son effet se voit trois mois après la livraison.

Sans lui, le client découvre la panne avant vous. Il ne se demande pas si l’API a lâché : il se demande si vous êtes fiable. Avec lui, vous écrivez au client « j’ai vu l’erreur de cette nuit, c’est réglé » avant qu’il ait remarqué quoi que ce soit. C’est la même logique que mettre à jour une application client sans casser la prod : le client ne doit jamais être le premier à voir le problème.

C’est aussi ce qui fait revenir un client après la première mission, comme je le raconte dans l’article sur la première mission freelance IA. Et si vous débutez sur l’outil, la masterclass n8n reprend les bases avant de construire ce système.