Une automatisation qui plante bruyamment, c'est agaçant mais ça se répare. Une automatisation qui s'arrête sans prévenir, c'est autrement plus coûteux : on ne s'en aperçoit qu'au moment où un client signale qu'il n'a jamais reçu son devis, parfois trois semaines plus tard. Une fois votre premier workflow n8n en place, la vraie question n'est plus « est-ce que ça marche ? » mais « est-ce que je le saurai quand ça ne marchera plus ? ».
Voici les cinq réflexes à mettre en place pour qu'une automatisation reste fiable dans le temps.
1. Comprendre ce qui casse réellement
Quand une automatisation tombe en panne, ce n'est presque jamais votre logique qui est en cause. Ce sont les choses extérieures qui bougent :
- Une connexion expire. Un mot de passe changé, un accès Google révoqué, un collaborateur parti dont le compte est désactivé.
- Un service répond différemment. Un outil met à jour son API et le champ que vous lisiez ne s'appelle plus pareil.
- Vous dépassez un quota. Beaucoup de services limitent le nombre d'appels par minute. En temps normal vous êtes loin du plafond ; le jour où 80 demandes arrivent d'un coup, ça bloque.
- Une donnée inattendue arrive. Un formulaire rempli sans numéro de téléphone, un nom avec une apostrophe, un champ vide là où vous attendiez une date.
Retenez surtout que la majorité de ces pannes sont temporaires. C'est une bonne nouvelle : beaucoup se règlent toutes seules si le workflow est construit pour ça.
2. Être prévenu avant votre client
C'est le point le plus important, et le plus vite mis en place. Dans n8n, vous pouvez créer un workflow dédié aux erreurs qui se déclenche automatiquement dès qu'un autre workflow échoue.
La marche à suivre :
- Créez un nouveau workflow avec le nœud Error Trigger en première position, et nommez-le par exemple « Alerte erreurs ».
- Derrière ce nœud, branchez ce qui vous alerte réellement : un email vers vous, un message Slack, un SMS pour les processus critiques.
- Dans chacun de vos workflows existants, ouvrez Options > Settings et sélectionnez ce workflow dans le champ Error workflow.
Un seul workflow d'alerte suffit pour toute votre installation : vous le construisez une fois, vous le branchez partout.
Le message d'alerte reçoit le nom du workflow qui a échoué, le message d'erreur et l'identifiant de l'exécution (execution.id et execution.url), ce qui vous donne un lien direct vers ce qui s'est passé.
Deux pièges classiques. Le lien vers l'exécution n'existe que si vous conservez les exécutions en base, vérifiez que le réglage Save failed production executions est actif. Et l'Error Trigger ne se déclenche pas sur les exécutions lancées à la main depuis l'éditeur : il ne réagit qu'aux exécutions automatiques. Inutile de chercher à le tester en cliquant sur « Execute workflow ».
3. Rendre les pannes passagères inoffensives
Puisque la plupart des erreurs sont temporaires, autant laisser le workflow réessayer avant de crier à l'aide.
Sur chaque nœud sensible (appel à une API, envoi, lecture d'un service externe), ouvrez l'onglet Settings du nœud et activez :
- Retry On Fail : le nœud retente l'opération en cas d'échec.
- Max Tries : le nombre de tentatives. Trois suffit dans la grande majorité des cas.
- Wait Between Tries (ms) : le délai entre deux tentatives, en millisecondes. Comptez 5 000 (5 secondes) pour une coupure réseau ordinaire.
Si vous butez sur un quota, calez ce délai sur la limite du service : pour une API qui autorise un appel par seconde, un délai de 1 000 ms suffit à repasser sous le plafond.
Le même onglet propose un réglage On Error, qui décide de la suite quand le nœud échoue malgré tout :
- Stop Workflow : tout s'arrête. C'est le bon choix pour un processus où la suite n'a aucun sens sans l'étape précédente.
- Continue : le workflow poursuit avec les dernières données valides.
- Continue (using error output) : le workflow continue en dirigeant l'erreur vers une branche séparée, où vous pouvez la consigner ou la signaler.
Cette troisième option est celle qu'on sous-utilise le plus. Si vous enrichissez 200 fiches clients et qu'une seule échoue, vous ne voulez pas perdre les 199 autres : vous voulez traiter l'exception à part.
4. Ne jamais envoyer deux fois le même message
C'est le risque que les nouvelles tentatives et les relances manuelles font apparaître, et le plus embarrassant vis-à-vis d'un client. Un workflow de relance qui repart depuis le début parce qu'on l'a relancé à la main, et vos clients reçoivent le même rappel de facture en double.
Le principe à viser s'appelle l'idempotence : un workflow doit pouvoir tourner deux fois sans produire deux fois l'effet. Deux façons de l'obtenir :
Marquer ce qui est fait. Ajoutez une colonne « Relancé le » dans votre tableur ou votre CRM, ou posez un libellé Gmail sur les messages traités. Au début du workflow, filtrez pour ne garder que les lignes non marquées. Écrivez ce marqueur juste après l'envoi, pas en fin de workflow : si le workflow casse entre les deux, c'est là que les doublons se glissent.
Utiliser le nœud Remove Duplicates. Il propose un mode Remove Items Processed in Previous Executions, qui compare les données entrantes à celles des exécutions précédentes. Réglez Keep Items Where sur « Value Is New » et indiquez dans Value to Dedupe On le champ qui identifie de façon unique chaque élément : un numéro de facture, une adresse email, une référence de commande. n8n conserve un historique (10 000 éléments par défaut, ajustable via History Size) et écarte tout ce qu'il a déjà vu.
5. Garder une trace et relire une fois par mois
Un workflow qui tourne bien devient invisible, et c'est précisément le problème. Deux réglages et une habitude suffisent à garder la main.
Côté réglages, dans Options > Settings de chaque workflow :
- Save failed production executions : indispensable pour comprendre après coup ce qui a échoué.
- Timeout Workflow : demande à n8n d'annuler une exécution qui dépasse une certaine durée, plutôt que de la laisser suspendue indéfiniment.
Pour les processus vraiment critiques (facturation, relances, prise de rendez-vous), ajoutez une ligne de journal dans un Google Sheet à chaque passage : date, client concerné, action effectuée, résultat. Le jour où un client affirme n'avoir rien reçu, vous avez la réponse en dix secondes.
Enfin, bloquez un quart d'heure par mois dans votre agenda pour ouvrir la liste des exécutions et vous poser trois questions : combien d'échecs depuis le mois dernier, y a-t-il une erreur qui revient, et un accès va-t-il bientôt expirer ? La plupart des grosses pannes envoient des signaux faibles pendant des semaines.
En conclusion
La différence entre une automatisation qu'on garde et une automatisation qu'on finit par désactiver ne tient pas à sa sophistication, mais à la confiance qu'on peut lui accorder. Commencez par le workflow d'alerte : c'est trente minutes de travail, et c'est ce qui transforme une panne silencieuse en simple notification.