Gérer les erreurs et déboguer ses automatisations

Voici la vérité que les tutoriels enthousiastes oublient : toute automatisation finira par échouer. Une API qui change, un quota dépassé, une connexion expirée, un champ renommé — la question n’est pas « si », mais « quand ». La différence entre l’amateur et le professionnel tient en une phrase : l’amateur découvre l’échec trois semaines après, le professionnel reçoit une alerte en trois secondes et corrige en cinq minutes. Cet article vous fait passer du premier camp au second.

Lire une erreur comme un médecin lit une radio

L’historique d’exécutions est votre salle d’autopsie. Cliquez sur l’exécution en erreur : chaque module montre ce qu’il a reçu, produit, et où ça a cassé. Les codes reviennent toujours aux mêmes familles :

Les trois stratégies de gestion d’erreur

Make permet d’attacher un gestionnaire d’erreur à chaque module (clic droit → « Add error handler »). Trois comportements à connaître :

• Retry : réessayer N fois avec un délai. Parfait pour les pannes passagères (5xx, 429). Trois essais à 10 minutes règlent 90 % des cas sans vous réveiller.
• Resume : continuer avec une valeur par défaut. Parfait pour les données optionnelles manquantes — le scénario ne s’arrête pas pour un champ téléphone vide.
• Break (+ alerte) : stopper proprement et prévenir. Pour tout le reste — ce qui mérite un œil humain.

Le scénario sentinelle : votre alarme universelle

Plutôt que de configurer une alerte par scénario, les pros montent UNE sentinelle : un petit scénario déclenché par « Watch incomplete executions » qui poste chaque échec dans un canal Slack dédié #automation-alerts, avec le nom du scénario et le lien direct vers l’exécution. Cinq modules, un quart d’heure de montage, et plus aucun échec silencieux — jamais.

Canal #automation-alerts

[ALERTE] Scenario « Leads -> CRM » a échoué
Module  : Sheets - Add a row
Erreur  : 401 Invalid credentials
Voir    : https://eu2.make.com/scenario/12345/log/...
Quoi faire : Connexions -> recréer « Sheets compta »

Déboguer méthodiquement (la checklist des 5 minutes)

1. Lisez le message d’erreur en entier — la cause y est écrite 8 fois sur 10.
2. Regardez les données d’entrée du module fautif : souvent c’est la donnée, pas le module.
3. Rejouez l’exécution avec « Run once » après correction.
4. Si c’est récurrent, ajoutez le garde-fou (filtre d’existence, retry, valeur par défaut).
5. Notez le correctif dans la description du scénario — votre futur vous remerciera.

FAQ — vos questions fréquentes

À quoi sert exactement le « error handler » par rapport aux alertes e-mail de Make ?

Les alertes e-mail préviennent ; le gestionnaire d’erreur AGIT : réessayer, continuer avec une valeur par défaut, exécuter une branche de secours… C’est la différence entre un détecteur de fumée et un extincteur automatique. Les deux se combinent.

Comment tester ma gestion d’erreur sans attendre une vraie panne ?

Provoquez-la : renommez temporairement la feuille cible, coupez la connexion, envoyez une donnée volontairement invalide. Vérifiez que le retry/resume/break se comporte comme prévu, puis remettez en ordre. Dix minutes qui valident des mois de tranquillité.

n8n gère-t-il les erreurs de la même façon ?

Le concept est identique avec un bonus : un « Error Workflow » global peut être déclenché par l’échec de n’importe quel workflow — l’équivalent natif de notre sentinelle. Settings → Error Workflow, et votre alarme universelle est en place.

Que faire des exécutions incomplètes accumulées ?

Traitez-les comme une boîte de réception : rejouez celles qui comptent après correction, supprimez les obsolètes. Une revue hebdomadaire de 5 minutes suffit — c’est le pendant « erreurs » de l’audit de coûts mensuel.

En résumé

Lire l’historique, choisir retry/resume/break selon la panne, monter la sentinelle universelle, déboguer la cause plutôt que le symptôme : vos automatisations sont désormais fiables, pas juste fonctionnelles. La suite logique du module : webhooks et API, l’automatisation en temps réel.