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.

Transparence : certains liens de cet article sont des liens partenaires. Si vous créez un compte via l’un d’eux, Flowmatic-Pro perçoit une commission, sans que cela change quoi que ce soit à votre prix. Nous ne recommandons que des outils que nous utilisons nous-mêmes.

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.

Les huit familles d’erreurs, et ce qu’elles disent

Un message d’erreur paraît opaque tant qu’on ne sait pas à quelle famille il appartient. Il n’y en a que huit, et savoir les reconnaître réduit le diagnostic à quelques secondes.

La distinction qui change tout

Ces huit familles se répartissent en deux groupes, et c’est cette répartition qui dicte votre réaction.

Les erreurs permanentes — authentification, autorisation, donnée manquante, format, introuvable — ne se résoudront jamais toutes seules. Réessayer est inutile : cela consomme et échoue à l’identique. Il faut corriger quelque chose.

Les erreurs passagères — limite de débit, panne du service, délai dépassé — disparaissent d’elles-mêmes. Elles appellent un nouvel essai automatique, pas une intervention. Une API qui répond mal à 14 h répondra parfaitement à 14 h 05.

Configurer un nouvel essai sur une erreur permanente est une perte de temps et d’unités. Ne pas en configurer sur une erreur passagère transforme un incident de trois minutes en panne de la journée. C’est la première décision à prendre devant n’importe quel module.

Le réflexe qui économise le plus

Une erreur de donnée manquante ne se corrige presque jamais dans le module qui l’affiche. Elle se corrige dans celui d’avant, celui qui aurait dû fournir la valeur. Quand un message vous dit « champ obligatoire vide », ne touchez pas au module fautif : ouvrez le précédent et regardez ce qu’il produit réellement.

La panne silencieuse : l’erreur qui ne lève aucune erreur

C’est le sujet le plus important de cet article, et celui dont on parle le moins. Une automatisation qui tombe en erreur vous prévient. Une automatisation qui ne fait plus rien ne prévient personne.

Les quatre formes qu’elle prend

Le filtre devenu trop strict. Le libellé sur lequel vous filtriez a changé, l’expéditeur a changé d’adresse, un service a modifié son format de message. Le scénario s’exécute parfaitement et traite zéro élément.

La source vidée. Un partage retiré, un dossier déplacé, une base renommée. Le module ne renvoie plus rien — et une liste vide n’est pas une erreur.

La destination décalée. Quelqu’un a inséré une colonne dans le tableur. Le scénario continue d’écrire, dans les mauvaises cases. Aucun message, des données fausses.

Le scénario désactivé par mégarde. Après une modification, une mise en pause pour un test, un quota épuisé. Il ne tourne simplement plus.

La seule protection qui fonctionne : la surveillance d’absence

Puisqu’aucun mécanisme d’erreur ne détecte ces cas, il faut inverser la logique : surveiller que quelque chose s’est bien passé, plutôt que d’attendre qu’un problème se signale.

Le montage est simple. Un scénario quotidien vérifie que vos automatisations critiques ont bien produit un résultat dans les dernières vingt-quatre heures : une ligne écrite, un message envoyé, une exécution non vide. Si le compte est à zéro alors qu’il devrait y avoir de l’activité, il vous prévient.

Trois modules, une trentaine d’unités par mois. C’est la protection la plus rentable de tout votre système : elle attrape la seule catégorie de pannes que rien d’autre ne voit.

Le seuil à régler

Attention à ne pas déclencher l’alerte le dimanche parce qu’aucune commande n’arrive le week-end. Réglez le seuil sur votre activité réelle et ignorez les jours creux : une alerte qui se déclenche à tort est une alerte qu’on désactive au bout de deux semaines.

Concevoir pour l’échec : quatre questions avant de construire

La meilleure gestion d’erreur est celle qu’on prévoit avant, pas celle qu’on ajoute après la première panne. Quatre questions suffisent, et elles se posent en trois minutes.

1. Que se passe-t-il si cette étape échoue ?

Pour chaque module, une des trois réponses : on s’arrête et on prévient, on continue sans, on réessaie plus tard. Un module d’enrichissement facultatif peut échouer sans conséquence ; un module qui envoie une facture, non.

2. Cette donnée peut-elle être absente ?

Passez en revue chaque champ que vous transmettez. Un formulaire sans téléphone, un e-mail sans pièce jointe, une commande sans commentaire. Pour chaque champ pouvant manquer : une valeur de remplacement, ou un filtre qui écarte le cas. C’est la question qui supprime le plus de pannes futures.

3. Que se passe-t-il si ce scénario s’exécute deux fois ?

Cela arrive : un service qui réenvoie un appel, un rattrapage qui reprend une plage déjà traitée, une relance manuelle. Si la réponse est « on crée un doublon » ou « on renvoie le message deux fois », il faut une protection : chercher avant de créer, ou marquer ce qui a déjà été traité.

4. Comment saurai-je que cela ne fonctionne plus ?

La question que personne ne se pose, et la plus importante des quatre. Si la réponse est « je m’en apercevrai », ce n’est pas une réponse : vous vous en apercevrez trois semaines plus tard. La bonne réponse est un mécanisme : une alerte, un récapitulatif hebdomadaire, une ligne dans un tableau que vous regardez déjà.

Ces quatre questions prennent trois minutes par scénario. Elles sont, de loin, le meilleur investissement de temps de toute la construction.

Les exécutions incomplètes : comprendre et rejouer

Quand un scénario est interrompu en cours de route, les données en transit ne sont pas nécessairement perdues. Encore faut-il avoir activé le mécanisme qui les conserve.

Le réglage à activer

Dans les paramètres du scénario, une option autorise la conservation des exécutions incomplètes. Sans elle, un scénario interrompu perd purement et simplement ce qu’il traitait. Avec elle, l’exécution est mise de côté et attend.

C’est aussi le prérequis du nouvel essai automatique : sans exécution conservée, il n’y a rien à rejouer. Beaucoup de gens configurent des essais qui ne fonctionneront jamais faute d’avoir coché cette case.

Rejouer

Une exécution mise de côté peut être relancée manuellement, une fois le problème corrigé. Elle reprend là où elle s’était arrêtée, avec les données d’origine — vous ne perdez rien et vous ne ressaisissez rien.

Le point d’attention : vérifiez que le problème est réellement réglé avant de rejouer. Une exécution rejouée qui échoue à nouveau retourne dans la file, et vous accumulez.

Purger

C’est le revers de la médaille. Une file d’exécutions incomplètes qui s’accumule finit par occuper de l’espace et brouiller la lecture. Certaines n’ont plus aucun sens à être rejouées : les données sont périmées, l’événement est passé.

Prenez l’habitude de vider cette file une fois par mois : rejouez ce qui a encore du sens, supprimez le reste. Une file de trois cents exécutions en attente ne vous dit plus rien ; une file de trois vous alerte immédiatement.

Provoquer la panne pour tester sa protection

Une gestion d’erreur jamais déclenchée est une hypothèse. Voici comment la vérifier sans attendre l’incident réel.

Simuler une donnée manquante. Le plus simple : modifiez à la main un élément de test en vidant un champ, puis lancez le scénario. Vous vérifiez d’un coup que votre valeur de remplacement fonctionne et que rien ne casse en aval.

Simuler une panne de service. Remplacez temporairement l’adresse d’un appel par une adresse qui n’existe pas. Le module échouera, et vous verrez si votre branche de secours se déclenche comme prévu.

Simuler une authentification cassée. Modifiez un caractère de la clé dans une connexion de test. Vous vérifiez que l’alerte part bien et qu’elle contient une information exploitable.

Simuler un volume anormal. Retirez la limite de résultats sur un module de recherche, sur des données de test. Vous verrez combien d’éléments passent réellement, et si votre scénario tient la charge.

La règle absolue de ces tests

Faites-les sur des données de test et des destinations de test, jamais en production. Le but est de casser volontairement ; assurez-vous que ce qui casse n’a aucune importance.

Une demi-heure de tests de ce genre, une fois, vaut mieux que six mois d’espoir. Et vous découvrirez souvent que votre gestion d’erreur ne fait pas ce que vous croyiez — c’est précisément l’intérêt de l’exercice.

Se construire une mémoire : le journal des incidents

Au bout d’un an, vous aurez rencontré une trentaine de problèmes. Sans trace écrite, vous rediagnostiquerez trois fois le même.

Le montage minimal

Un tableau, cinq colonnes : la date, le scénario concerné, le symptôme, la cause réelle, la correction. Quand un incident survient, vous ajoutez une ligne — trois minutes, à chaud, pendant que tout est frais.

Vous pouvez alimenter ce tableau automatiquement pour la partie technique : votre scénario de surveillance écrit la date, le nom du scénario et le message d’erreur. Vous complétez à la main les deux colonnes qui comptent vraiment, la cause et la correction.

Ce que ce journal vous apporte

Le diagnostic instantané. Un symptôme déjà rencontré se résout en consultant une ligne plutôt qu’en recommençant l’enquête.

Les tendances. Au bout de six mois, vous verrez que trois incidents sur quatre viennent du même service, ou de la même catégorie de cause. Cela vous dit où investir votre effort de fiabilisation.

La transmission. Si quelqu’un doit reprendre vos automatisations, ce journal vaut plus que n’importe quelle documentation. Il raconte ce qui casse réellement, pas ce qui devrait fonctionner.

C’est le document le moins gratifiant à tenir et le plus utile à relire. Vingt lignes suffisent pour qu’il devienne précieux.

Les erreurs intermittentes : le cas le plus difficile

Un scénario qui échoue une fois sur dix, sans raison apparente, est bien plus pénible qu’un scénario qui échoue toujours. Voici comment aborder ce cas.

Les quatre causes possibles

Une limite de débit atteinte aux heures de pointe. C’est la première hypothèse à tester : regardez si les échecs se concentrent à certaines heures. Si oui, espacez ou groupez vos appels.

Une donnée particulière qui casse. Un caractère spécial, un champ anormalement long, une valeur vide. Les échecs semblent aléatoires alors qu’ils suivent une caractéristique des données. Comparez les éléments qui échouent : ils ont presque toujours quelque chose en commun.

Un chevauchement d’exécutions. Deux exécutions du même scénario tournent en même temps et se marchent dessus — l’une écrit pendant que l’autre lit. Le symptôme est typiquement un doublon ou une valeur incohérente. Les réglages du scénario permettent d’interdire ce chevauchement.

Une instabilité réelle du service. Cela existe, et vous n’y pouvez rien. Un nouvel essai automatique règle le problème sans que vous ayez à comprendre.

La méthode

Ne cherchez pas la cause dans le scénario : cherchez ce qui distingue les exécutions qui échouent de celles qui réussissent. Ouvrez cinq échecs et cinq succès côte à côte, et comparez. L’heure, la taille des données, la présence d’un champ, la source. Le facteur commun apparaît presque toujours au bout de dix minutes.

Et tant que vous cherchez, configurez un nouvel essai automatique : cela ne résout pas la cause, mais cela supprime le symptôme et vous laisse enquêter tranquillement.

Six réflexes de construction qui suppriment la moitié des pannes

1. Limiter les résultats sur chaque module de recherche. Un champ que presque personne ne remplit, et qui évite à la fois les dépassements de quota et les délais dépassés.

2. Prévoir une valeur de remplacement pour tout champ facultatif. Trois secondes par champ, et toute une famille d’erreurs disparaît.

3. Chercher avant de créer. Systématique dès qu’il s’agit de contacts, de clients ou de commandes.

4. Placer les filtres au plus tôt. Moins de données traversent le scénario, moins il y a d’occasions d’échouer — et la facture baisse en prime.

5. Renommer chaque module. Un message d’erreur qui cite « Rechercher le client dans le tableur » vous situe immédiatement ; un message qui cite « Module 7 » ne vous dit rien.

6. Écrire deux lignes de notes. Ce que fait le scénario, ce qu’il suppose, quoi vérifier s’il tombe. C’est ce que vous lirez en premier dans six mois, à un moment où vous serez pressé.

Aucun de ces réflexes n’est technique. Tous prennent moins d’une minute. Ensemble, ils suppriment l’essentiel des pannes que nous rencontrons en audit — ce qui en dit long sur la nature réelle des problèmes de fiabilité : ils viennent rarement de l’outil, presque toujours de la construction.

Quand il vaut mieux laisser échouer

Terminons par un contrepoint. Tout ne mérite pas d’être protégé, et sur-construire a un coût.

Une gestion d’erreur alourdit le scénario. Chaque branche de secours est un chemin de plus à comprendre, à tester et à maintenir. Sur une automatisation sans enjeu, elle coûte plus qu’elle ne rapporte.

Une alerte de trop est une alerte de moins. Si vous recevez quinze notifications d’incident par semaine sur des scénarios secondaires, vous cesserez de les lire — y compris celle qui concernait la facturation.

Certains échecs se corrigent tout seuls. Un scénario planifié qui échoue une fois retentera au prochain réveil. Si le décalage d’une heure n’a aucune conséquence, il n’y a rien à construire.

La règle de proportion

Protégez ce qui touche à l’argent, aux clients et aux données irremplaçables. Laissez échouer le reste, et contentez-vous de le savoir — une ligne dans un récapitulatif hebdomadaire suffit.

Un système où tout est blindé est un système que personne n’ose modifier. Un système où l’on sait ce qui compte et où seul cela est protégé reste vivant, modifiable, et beaucoup plus fiable en pratique.

Trois pannes réelles, du symptôme à la cause

Les méthodes s’oublient ; les cas restent. Voici trois incidents rencontrés en accompagnement, déroulés du symptôme jusqu’à la correction.

« Mes relances partent aux clients qui viennent de commander »

Le symptôme : plusieurs clients signalent avoir reçu une relance leur demandant s’ils étaient toujours intéressés, alors qu’ils avaient commandé la veille.

La première hypothèse, fausse : un bogue dans la condition de relance. Elle a été vérifiée et fonctionnait parfaitement.

La cause réelle : les commandes prises par téléphone n’étaient plus reportées dans le suivi le jour même. Le scénario appliquait fidèlement sa règle sur des données devenues fausses. L’automatisation n’était pas en cause : c’est le processus humain en amont qui avait changé.

La correction : une condition de sécurité supplémentaire — ne relancer que si aucune facture n’existe au nom du client, quelle que soit la source. La leçon générale : quand un scénario envoie quelque chose à un client, ajoutez toujours une vérification indépendante de la donnée qui a déclenché l’envoi.

« Le scénario marche, mais le tableau est vide depuis trois semaines »

Le symptôme : aucune erreur, des exécutions vertes tous les jours, et plus une seule ligne écrite depuis vingt et un jours.

Le diagnostic : l’historique montrait des exécutions traitant zéro élément. Le module de lecture ne renvoyait rien.

La cause réelle : le compte utilisé par la connexion avait été retiré du partage du dossier source lors d’un ménage des accès. Le compte pouvait toujours s’authentifier — la connexion était verte — mais ne voyait plus aucun fichier. Une autorisation valide et un accès à la donnée sont deux choses différentes.

La correction : le partage rétabli, et surtout un scénario de surveillance d’absence ajouté. Trois semaines de données perdues auraient été trois jours avec cette alerte.

« Une exécution sur dix échoue, sans logique apparente »

Le symptôme : un scénario de traitement de commandes qui échouait de façon apparemment aléatoire, avec un message de format invalide.

La méthode employée : ouvrir cinq échecs et cinq succès côte à côte, et chercher ce qui les distingue.

La cause réelle : les commandes qui échouaient contenaient toutes un commentaire client comportant un retour à la ligne. Cette valeur cassait la mise en forme du champ de destination. Rien d’aléatoire : un caractère particulier, présent une fois sur dix.

La correction : une fonction de nettoyage appliquée au champ avant écriture. Deux minutes de correction, pour un problème qui durait depuis six semaines faute d’avoir comparé les échecs entre eux.

Ce que ces trois cas ont en commun

Aucun n’était un défaut de la plateforme. Dans les trois cas, le scénario a fait exactement ce qu’on lui avait demandé : c’est le contexte autour de lui qui avait changé — une habitude de saisie, un droit d’accès, une donnée inhabituelle.

C’est la nature même de l’automatisation, et la raison pour laquelle la surveillance compte autant que la construction. Un scénario fige une décision prise un jour donné et continue de l’appliquer indéfiniment. Ce n’est pas un défaut : c’est précisément ce qu’on lui demande. Mais cela implique que quelqu’un vérifie, de temps en temps, que la décision est toujours la bonne.

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.

Faut-il traiter les erreurs différemment selon la plateforme ?

Les mécanismes portent des noms différents mais recouvrent les mêmes idées : un réglage par étape pour réessayer ou continuer, un chemin séparé pour les éléments fautifs, et un dispositif global qui vous prévient. Ce qui change vraiment d’une plateforme à l’autre, c’est la facilité à rejouer une exécution échouée — vérifiez ce point précis si vous traitez des commandes ou des paiements, car c’est là que se joue la différence entre un incident et une perte.

Mon scénario échoue toujours sur le même élément. Que faire ?

Isolez-le. Récupérez les données de cet élément précis, épinglez-les ou recopiez-les dans un scénario de test, et travaillez dessus jusqu’à comprendre. Dans la grande majorité des cas, il s’agit d’un caractère inhabituel, d’un champ anormalement long, ou d’une valeur vide là où toutes les autres sont remplies. Une fois la cause identifiée, ajoutez un filtre ou une valeur de remplacement plutôt que de traiter le cas à la main chaque semaine.

Combien de temps faut-il conserver l’historique des exécutions ?

Une à deux semaines suffisent pour le diagnostic courant : au-delà, vous ne remonterez jamais. La durée de conservation dépend de votre formule, et la réduire allège le système sans rien vous coûter d’utile. Ce qui doit durer, en revanche, c’est votre journal des incidents : quelques lignes de texte qui, elles, gardent leur valeur pendant des années.

Comment prévenir plusieurs personnes en cas d’incident ?

Évitez la liste de diffusion : quand tout le monde est prévenu, personne ne se sent responsable. Le montage qui fonctionne désigne un destinataire unique par catégorie d’incident — celui qui peut réellement corriger — et écrit tout le reste dans un tableau consultable. Une alerte adressée à quelqu’un est traitée ; une alerte adressée à tout le monde est ignorée par tout le monde.

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.