Vos scénarios Make.com s’arrêtent net au pire moment et vous ne le découvrez qu’après l’appel d’un client. Sur une plateforme qui orchestre désormais des flux critiques en entreprise, une erreur non gérée représente un risque opérationnel. La résilience repose sur trois piliers : une route d’erreur avec la bonne directive, une stratégie de reprise temporisée et un monitoring qui signale la panne avant qu’elle ne se voie.
À retenir
- Bundle d’erreur : chaque échec génère un paquet contenant le type d’erreur, le message de l’API distante et le payload source à l’origine du blocage.
- Erreurs transitoires vs structurelles : ConnectionError (502/503/504), RateLimitError (429) et ModuleTimeoutError (40 à 60 secondes) peuvent être rejouées ; DataError, BundleValidationError et AccountValidationError (401/403) exigent une correction humaine.
- Sans filet, sanction immédiate : sans gestionnaire et sans stockage des exécutions incomplètes, Make.com met en pause un scénario 20 minutes dès un RateLimitError ou un ConnectionError, puis le désactive après plusieurs échecs consécutifs.
- 5 directives natives : Resume (substitution), Rollback (annulation ACID), Commit (validation partielle), Break (mise en file pour retry) et Ignore (passage au bundle suivant).
- Retry intelligent : Break exige l’option Store incomplete executions activée ; le backoff exponentiel suit la formule délai = délai de base x 2tentative, avec un jitter de ±20 % et l’exploitation de l’en-tête Retry-After.
- Architecture anti-perte : filtres par type d’erreur, route de basculement (failover) vers une API secondaire et Dead Letter Queue (DLQ) avec rejeu par lots de 50 à 100 enregistrements pour un taux de perte à 0 %.
- Observabilité en 3 niveaux : L1 natif (Enhanced Error Monitoring sur 7 et 30 jours), L2 heartbeat externe (Better Stack, Cronitor) et L3 centralisé (Datadog, Grafana), avec des alertes indiquant le scénario, le module, le type d’erreur et le lien direct vers l’exécution.
Décoder la panne : pourquoi vos scénarios s’arrêtent sans prévenir
Pour corriger une panne, il faut d’abord en comprendre l’origine. Sur Make.com, toutes les erreurs n’ont pas les mêmes conséquences.
L’avertissement qui laisse passer et l’erreur qui fige tout
Make.com distingue deux niveaux d’incident. L’avertissement (Warning) signale une anomalie mineure, mais le scénario continue son exécution.
L’erreur, elle, bloque le flux. Par défaut, un module en échec interrompt toute la séquence : les modules en aval ne s’exécutent pas et les bundles suivants restent en suspens.
La moindre exception non interceptée peut donc paralyser un flux de commandes, de leads ou de factures. Si elle se répète, Make.com désactive automatiquement la planification du scénario pour préserver ses ressources.
Le bundle d’erreur : la boîte noire de l’exécution
Chaque échec génère un Error Bundle. Il consigne les circonstances précises de la panne, comme la boîte noire d’un avion après un incident.
Il contient trois attributs exploitables : le type formel de l’erreur, le message détaillé renvoyé par l’API distante et le payload d’origine, c’est-à-dire les données sources qui ont provoqué l’échec.
Vous ne corrigez donc pas à l’aveugle. Ce bundle sert à router l’erreur selon son diagnostic et alimente aussi les routes de dérivation ainsi que les journaux d’audit.
Transitoire ou fatale : apprendre à trier les incidents
Il faut d’abord classer l’erreur. Les erreurs transitoires sont passagères : le ConnectionError (HTTP 502, 503, 504) traduit une indisponibilité temporaire du service tiers, le RateLimitError (HTTP 429) signale un quota d’appels dépassé et le ModuleTimeoutError survient quand une API ne répond pas dans le délai strict de 40 à 60 secondes imposé par le runtime.
Ces incidents peuvent être rejoués. Les erreurs structurelles, elles, ne disparaîtront pas seules : le DataError ou le BundleValidationError pointent un champ manquant ou un mauvais typage dans votre mappage. Le AccountValidationError (HTTP 401/403) indique, lui, une authentification invalide.
L’AccountValidationError se déclenche à l’initialisation du module et un gestionnaire local ne peut pas le capter. Il impose une reconnexion manuelle. Sans gestionnaire ni stockage des exécutions incomplètes, Make.com met aussi votre scénario en pause pendant 20 minutes dès le premier 429 ou 5xx.
Les cinq directives qui sauvent un scénario
Make.com propose cinq directives natives. Chacune se place au bout d’une route d’erreur et détermine la suite du traitement. Un mauvais choix peut corrompre des données ; le bon maintient le flux en état de marche.
Resume et ignore : assurer la continuité sans bruit
La directive Resume injecte un bundle de substitution. Votre module Calendly ne renvoie pas de date ? Resume fournit une valeur par défaut, et les étapes suivantes continuent leur course.
Elle évite qu’un scénario entier s’arrête à cause d’une donnée manquante mais non critique. À utiliser seulement si cette valeur de remplacement reste acceptable pour les modules suivants.
La directive Ignore transforme l’exception en simple avertissement. Elle écarte le bundle fautif et passe immédiatement au suivant dans le lot. Sur un traitement par batch de 100 lignes, une ligne mal formée est ignorée sans bloquer les 99 autres. Elle ne consomme pas non plus d’opérations inutiles sur la branche défaillante.
Rollback et commit : annuler ou valider ce qui a déjà été fait
Rollback et Commit répondent à une question simple : faut-il annuler les écritures déjà effectuées ou les conserver malgré l’erreur ?
Rollback interrompt le scénario et restaure l’état initial des modules compatibles ACID, comme un Data Store Make.com, MySQL ou PostgreSQL. Si la troisième écriture sur cinq échoue, les deux premières sont annulées. Cette directive reste inopérante sur les actions irréversibles : un e-mail déjà envoyé ou un fichier supprimé ne reviendra pas.
Commit fait l’inverse. Il valide définitivement ce qui a été écrit avant l’erreur, puis arrête proprement le flux. Vous conservez ainsi les données déjà enregistrées sans risquer de dupliquer les opérations.
Break : mettre en attente plutôt que perdre
La directive Break est souvent la plus utile en production. Elle isole le bundle en échec afin de le traiter plus tard, au lieu de l’ignorer ou d’annuler le scénario.
Le bundle fautif rejoint la file des exécutions incomplètes pour un rejeu manuel ou automatique. Vous définissez le nombre maximal de tentatives et l’intervalle entre chacune d’elles.
L’option Store incomplete executions doit être activée dans les paramètres généraux du scénario. Sans elle, Break ne peut rien enregistrer et l’automatisation s’arrête sans solution de reprise.
Rendre vos automatisations plus résistantes aux pannes
Une directive seule ne suffit pas. Une architecture résiliente combine un retry intelligent, une file de rebut et une supervision capable de détecter les scénarios silencieux. Pour la vision et la compréhension du monde, l’architecture JEPA explore une piste différente des LLM.
Le retry intelligent : backoff exponentiel et jitter
Relancer immédiatement une API déjà en surcharge ne fait qu’aggraver la panne. Utilisez plutôt un backoff exponentiel.
La formule est simple : délai = délai de base x 2tentative. Vous attendez 2 secondes, puis 4, puis 8, puis 16. Make.com applique déjà ce principe nativement sur les erreurs 429 et 5xx.
Sur les flux à forte volumétrie, ajoutez un module Sleep et un facteur d’aléa, le jitter. Un jitter de ±20 % décale légèrement chaque requête et évite que des dizaines d’exécutions concurrentes frappent l’API au même millième de seconde. La charge est ainsi répartie dans le temps.
Exploitez aussi l’en-tête HTTP Retry-After renvoyé par les fournisseurs. Il indique la fenêtre exacte de réinitialisation du quota, ce qui reste plus précis qu’un délai fixe.
L’option Process data in order mérite aussi votre attention. Activée, elle garantit un traitement séquentiel strict, indispensable pour des webhooks dépendants de l’ordre. Elle bloque toutefois tous les nouveaux bundles tant qu’une exécution incomplète n’est pas résolue : le goulot d’étranglement peut vite devenir réel.
File de rebut et basculement : l’assurance anti-perte
Une erreur définitive doit rester traçable. La perdre revient à perdre la donnée et la possibilité de comprendre ce qui s’est passé.
Commencez par filtrer vos routes. Un filtre du type [Error Type] Equal to ConnectionError évite de lancer un retry coûteux sur une erreur de validation de schéma irréversible. Chaque type d’erreur rejoint ainsi la stratégie qui lui correspond.
Prévoyez ensuite un failover. Si votre fournisseur principal renvoie une erreur 5xx, une route de bascule appelle immédiatement un service secondaire. Une API d’enrichissement de secours peut, par exemple, prendre le relais si la première ne répond pas.
La Dead Letter Queue (DLQ) complète ce dispositif. Les bundles définitivement rejetés sont stockés dans un Data Store ou une base externe avec toutes leurs métadonnées : ID du bundle, horodatage, nom du module fautif, code d’erreur et payload JSON brut. Sur les flux critiques, cette trace vise un taux de perte de données de 0 %.
Un scénario secondaire, le Batch Reprocessor, rejoue ensuite ces enregistrements par lots de 50 à 100, une fois la cause racine corrigée. Le flux d’ingestion reste séparé du mécanisme de reprise, ce qui évite d’interrompre le trafic régulier.
Voir venir la panne : le monitoring en trois niveaux
Un scénario silencieux qui ne tourne plus est souvent plus dangereux qu’un scénario qui affiche une erreur. Il faut donc détecter son absence d’activité, pas seulement les pannes visibles.
Le monitoring s’organise en trois couches. Le niveau 1 est natif : l’historique d’exécution et le tableau de bord Enhanced Error Monitoring analysent les tendances sur 7 et 30 jours, classent le top 5 des modules défaillants et calculent l’écart par rapport au volume moyen de pannes.
Le niveau 2 repose sur une sonde de vitalité externe. Des outils comme Better Stack, Cronitor ou healthchecks.io envoient des signaux réguliers, appelés heartbeat. S’ils ne reçoivent plus le signal attendu, ils alertent : le scénario a été désactivé silencieusement ou le webhook ne répond plus.
Le niveau 3 centralise l’observabilité. Vos logs sont envoyés vers Datadog ou Grafana afin de corréler les pannes Make.com avec l’état global du système d’information.
Chaque route d’erreur critique doit expédier un webhook vers Slack, Microsoft Teams ou PagerDuty. La charge utile doit contenir au minimum l’ID du scénario, le nom du module, le type d’erreur, le message et l’URL directe vers l’exécution en échec. Ces informations réduisent le temps nécessaire pour identifier et corriger la panne.
Filtrez les alertes résolues automatiquement par un retry. Sans ce tri, la fatigue d’alerte s’installe et les incidents qui exigent réellement une intervention risquent de passer inaperçus.
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.