Superviser ses workflows n8n : aucune panne silencieuse

Une tâche manuelle oubliée finit par se voir. Une automatisation en panne, elle, ne se voit pas. Les commandes ne sont plus recopiées, les factures ne sont plus créées, et le premier signal peut venir d’un client, des jours plus tard. Superviser ses workflows n8n, c’est faire en sorte que ce signal arrive chez vous, tout de suite, avec de quoi réparer.

Nous opérons des workflows n8n en production, dont un agent de saisie de dépenses sur Telegram et celui qui attribue un identifiant interne à chaque nouveau bien dans le CRM de Palmora, un portail immobilier que nous accompagnons. Ce guide s’appuie sur la documentation de n8n et sur nos propres incidents. Le choix de l’outil et le cas des logiciels sans API sont traités dans les autres guides de notre rubrique automatisation.

En bref

• Un seul workflow d’erreur, ouvert par le nœud Error Trigger, peut alerter pour tous vos processus.
• Une alerte d’absence couvre ce qu’il ne voit pas : le processus qui ne se lance plus.
• L’historique ne sert que s’il est conservé : vérifiez ce qui est enregistré, et combien de temps.
• Relancer est simple ; ne pas créer de doublon se prépare à la conception.
• Un workflow peut réussir avec des données fausses : contrôlez aussi les volumes et les champs.

Comment être prévenu quand un workflow n8n échoue ?

n8n permet de désigner, pour chaque workflow, un workflow d’erreur qui se lance quand une exécution échoue. Selon la documentation sur la gestion des erreurs, ce workflow doit commencer par le nœud Error Trigger, et le même peut servir à plusieurs workflows. On le construit donc une fois, soigneusement :

1. Créez un workflow dont le premier nœud est l’Error Trigger, donnez-lui un nom clair (« Alertes », par exemple) et enregistrez-le. Il n’a pas besoin d’être publié pour fonctionner.
2. Ajoutez derrière lui l’envoi de l’alerte vers le canal de votre équipe.
3. Dans chaque workflow à surveiller, ouvrez les réglages (Settings) et choisissez ce workflow comme Error Workflow.
4. Provoquez une panne sur une exécution automatique pour vérifier que l’alerte arrive bien.

La quatrième étape compte : selon la documentation du nœud, l’Error Trigger ne part que lorsqu’une exécution automatique échoue, jamais sur un lancement manuel. Pour l’essai, le nœud Stop And Error fait échouer une exécution dans les conditions que vous choisissez.

Ce que doit contenir une bonne alerte :

• le nom du processus en langage métier (« Création des factures fournisseurs », pas « Workflow 14 ») ;
• l’étape qui a échoué et le message d’erreur ;
• le lien vers l’exécution en échec, que n8n fournit si l’exécution est enregistrée (pas quand l’erreur vient du déclencheur lui-même) ;
• ce que la personne qui reçoit l’alerte doit faire, ou qui appeler.

Le canal compte autant que le contenu. Un email de plus dans une boîte saturée ne sert à rien : l’alerte doit arriver là où l’équipe lit déjà, dans un canal réservé aux alertes, qui reste silencieux quand tout va bien. Sur Palmora, ce sont deux salons Discord dédiés.

Limite honnête : le workflow d’erreur ne voit que les échecs. Un processus qui ne se lance plus du tout (workflow mis à l’arrêt par erreur, export qui n’arrive plus dans la boîte surveillée, webhook que plus personne n’appelle) ne produit aucune erreur, donc aucune alerte. Pour un processus censé tourner chaque jour, ajoutez une alerte d’absence : un workflow planifié qui vérifie chaque matin que le travail attendu a bien été fait (des lignes créées la veille, un fichier reçu) et prévient sinon.

Comment savoir ce qui a été traité, et ce qui ne l’a pas été ?

n8n garde la trace des exécutions. La liste des exécutions se filtre par workflow, par statut (en échec, en cours, réussie, en attente) et par date de début, et l’on y ouvre une exécution pour en voir, étape par étape, les données. Encore faut-il qu’elle ait été conservée, et cela se règle :

• Ce qui est enregistré. Selon la documentation de n8n, les réglages de chaque workflow décident s’il faut conserver les exécutions de production en échec, celles qui ont réussi, et les exécutions manuelles. Gardez toujours les échecs. Gardez aussi les réussites d’un processus important : c’est la seule preuve qu’un traitement a eu lieu quand quelqu’un demande si la commande de mardi est passée.
• Combien de temps. Sur une instance auto-hébergée, n8n supprime par défaut les exécutions terminées au-delà de 14 jours ou de 10 000 exécutions, en commençant par les plus anciennes, selon sa documentation sur les données d’exécution. Réglez ces seuils selon votre besoin, sans oublier que l’historique contient vos données : noms, montants, adresses.
• Ce qui disparaît avec le workflow. Supprimer un workflow supprime aussi son historique d’exécutions. Mettez à l’arrêt plutôt que d’effacer un processus dont on pourrait vous demander des comptes.
• Des étapes nommées en clair. Une exécution doit se lire sans son auteur : « Créer la facture » plutôt que « HTTP Request 3 ».

Pour un processus important, envisagez un journal à part : une ligne par élément traité (la facture X, le client Y) avec son statut, que la personne métier consulte sans ouvrir n8n et qui ne dépend pas de la purge de l’outil.

Comment rejouer une exécution sans créer de doublon ?

Une fois la cause corrigée, reste à traiter ce qui ne l’a pas été. Depuis la liste des exécutions, n8n relance une exécution en échec de deux façons : avec le workflow tel qu’il est enregistré aujourd’hui, donc corrigé, ou avec le workflow d’origine. Pour comprendre une panne avant de relancer, la fonction Debug in editor, décrite dans sa documentation, recopie les données d’une exécution passée dans l’éditeur, épinglées sur le premier nœud (en auto-hébergé, selon votre édition). Le réglage Save execution progress permet aussi de reprendre là où l’exécution s’est arrêtée, au prix d’un peu de latence.

Le piège est le doublon. Si un workflow a créé la facture puis échoué au moment d’envoyer l’email, le rejouer depuis le début crée une seconde facture. La parade se construit à la conception, pas pendant la panne :

• chaque étape qui écrit vérifie d’abord si l’élément existe déjà, par un identifiant de référence (numéro de commande, numéro de facture fournisseur) ;
• l’enregistrement le plus important passe avant les actions annexes (notification, email), jamais après ;
• un élément en échec n’arrête pas les autres : sur un lot de cinquante factures, la quarante-septième en erreur ne doit pas bloquer les trois suivantes.

Nous avons appris la deuxième règle à nos dépens. Sur Palmora, les demandes de contact partaient d’abord par email : en cas d’échec, l’erreur était avalée et le site répondait que tout allait bien, même en panne. La parade : enregistrer chaque demande en base avant d’envoyer l’email ; si l’email échoue, rien n’est perdu.

Un traitement long a aussi besoin de points de reprise : sur Palmora, tant qu’un de nos traitements nocturnes n’écrivait pas son cache toutes les 25 unités, chaque exécution interrompue repartait à froid, d’où trois nuits à plus de 4 h de traitement et un dépassement de délai.

Comment repérer un workflow qui réussit avec des données fausses ?

Un workflow peut réussir et produire un résultat faux : un export vide traité « avec succès », un montant lu à zéro parce que le format a changé, un PDF dont l’extraction a raté un champ. Aucun de ces cas ne déclenche le workflow d’erreur. Sur Palmora, sans garde-fous de publication, une réponse d’API vide publierait un site à zéro produit, avec un workflow au vert.

Quelques contrôles simples attrapent ces cas :

• un seuil de volume : nettement moins d’éléments qu’un jour ordinaire, ou aucun, et rien n’est publié avant qu’une personne ait regardé ;
• un contrôle des suppressions : un traitement qui s’apprête à effacer bien plus que d’habitude s’arrête et prévient ;
• des champs obligatoires vérifiés avant l’écriture (pas de facture sans montant ni fournisseur) ;
• une file de vérification humaine pour ce qui est douteux, plutôt qu’une écriture automatique.

Dans n8n, le nœud Stop And Error transforme un contrôle raté en échec véritable : placé derrière une condition (zéro ligne, montant manquant), il fait échouer l’exécution, et votre workflow d’erreur prévient comme pour n’importe quelle panne.

Ils comptent plus encore quand l’automatisation passe par une porte détournée (export, email, écran), comme dans notre guide pour automatiser un logiciel qui n’a pas d’API : un changement de format côté source y donne vite un résultat faux sans erreur visible.

Faut-il aussi surveiller le serveur qui fait tourner n8n ?

Si n8n est auto-hébergé, oui : le serveur fait partie du dispositif. Une instance arrêtée n’envoie aucune alerte, puisqu’elle ne fait plus rien. Au minimum :

• une sonde externe, qui tourne ailleurs que sur le serveur surveillé et vérifie que l’instance répond ;
• le disque : selon la documentation de n8n, la base peut grossir jusqu’à saturer le stockage ; ne conservez rien d’inutile et laissez la purge active (sur SQLite, la place libérée n’est pas rendue automatiquement) ;
• les sauvegardes et les mises à jour, dont nous détaillons ce qui casse vraiment dans notre article sur la sauvegarde d’un serveur à soi.

Que vérifier avant de passer un workflow en production ?

Un workflow qui ne coche pas ces six cases n’est pas en production : il est en essai, et quelqu’un doit le savoir. Si vous partez de zéro, commencez par le workflow d’erreur et l’alerte d’absence : ce sont eux qui transforment une panne silencieuse en panne connue.

C’est ce que nous livrons dans notre offre : chaque processus automatisé arrive avec ses alertes et l’historique de chaque exécution, plus un compteur du coût par exécution, et l’ancienne façon de faire reste en secours tant que la nouvelle n’a pas fait ses preuves. La supervision et les corrections peuvent ensuite nous être confiées, en option à 350 € par mois.

Questions fréquentes

Que se passe-t-il quand un workflow n8n plante la nuit ?

Sans workflow d’erreur, rien : l’exécution est marquée en échec dans la liste des exécutions, si les échecs sont enregistrés, et personne n’est prévenu. Avec un workflow d’erreur, l’Error Trigger reçoit le détail de l’échec et l’alerte part aussitôt vers le canal choisi. Le matin, il reste à corriger la cause et à relancer l’exécution depuis la liste, en vérifiant d’abord qu’aucune étape n’a déjà écrit quelque chose.

Combien de temps garder l’historique des exécutions ?

Assez pour répondre aux questions de l’équipe, pas plus que nécessaire, puisqu’il contient des données personnelles : le RGPD interdit de les conserver plus longtemps que ne l’exige la finalité du traitement (article 5 du RGPD). En auto-hébergé, n8n purge par défaut les exécutions terminées au-delà de 14 jours ou de 10 000 exécutions, deux seuils qui se règlent.

Faut-il un outil de supervision externe ?

Pour les workflows, n8n fournit l’essentiel : workflow d’erreur, liste des exécutions, relance. Pour l’instance elle-même, il faut au moins une sonde installée sur une autre machine, puisqu’une instance arrêtée ne peut pas signaler sa propre panne. Un outil plus complet, qui suit aussi le disque et la mémoire, devient utile dès que d’autres services partagent le serveur.

Qui doit recevoir les alertes ?

Une personne nommée, avec un suppléant pour ses absences, plutôt que « toute l’équipe » : une alerte adressée à tout le monde n’engage personne. Décidez aussi de ce qui peut attendre le matin et de ce qui justifie un appel, et écrivez-le dans l’alerte elle-même avec la marche à suivre : la personne ne doit pas avoir besoin de l’auteur du workflow pour agir.

Ces mécanismes existent-ils dans Make et Zapier ?

Les principes ne dépendent pas de l’outil : être prévenu d’un échec, détecter une absence, rejouer sans doublon, contrôler les données. Les réglages, eux, diffèrent : vérifiez dans la documentation de Make ou de Zapier comment chacun alerte, conserve et relance ses exécutions avant d’y confier un processus critique. Notre comparatif de n8n, Make et Zapier aide à choisir selon votre volume et la nature de vos données.