MakeSÉCURISER VOS SCÉNARIOS
Prérequis
- Au moins un scénario Make actif en production (formulaire, sync, webhook)
- Table Airtable ou base « incidents automation » pour journaliser
- Canal Slack #ops ou e-mail d’alerte identifié
- Documentation des modules critiques et de leurs codes d’erreur
Un scénario Make en production sans gestion d’erreur peut perdre des leads, des syncs CRM ou des notifications pendant des jours : surtout après une mise à jour d’API tierce. Les error handlers Make, une file de reprise et des alertes actionnables structurent la résilience.
Activer les error handlers Make
Clic droit sur un module fragile (HTTP, CRM, Notion) → « Add error handler ». La branche rouge s’exécute à la place du scénario principal en cas d’échec.
Chaîne handler type : Set variables (contexte erreur) → Create record Airtable « incidents » → Slack message avec lien vers l’historique Make (`execution_id`).
Désactivez « Allow storing of incomplete executions » seulement si vous avez une autre file de reprise : sinon les incomplets s’accumulent dans le dashboard Make.
Retries, backoff et idempotence
Pour les erreurs transitoires (429, 502), ajoutez Sleep puis un module « Resume » ou un scénario séparé « replay » qui lit la file Airtable `status=pending`.
Limitez à 3 tentatives avec backoff croissant (1 min, 5 min, 30 min). Au-delà, passez en `status=manual` et alertez le PM.
Concevez les opérations en upsert (recherche par e-mail + date, clé externe) pour qu’un rejeu ne duplique pas les leads ou les tâches ClickUp.
Scénario de reprise et gouvernance
Créez un scénario « Replay failures » déclenché manuellement ou sur planning nocturne : Iterator sur Airtable `retry_count < 3` → rejoue le module HTTP/CRM avec le payload stocké.
Documentez dans Notion la procédure : qui traite les incidents, SLA de reprise, quand désactiver le scénario parent pendant maintenance API.
Couplez avec make-monitoring-logs-scenarios pour une revue hebdo : taux d’échec par scénario, modules les plus fragiles, tendance après déploiement site.
Erreurs fréquentes
Handler qui envoie Slack sans stocker le payload : impossible de rejouer.
Retry infini sur 400 Bad Request : boucle et coût opérations Make.
Même handler générique pour tous les scénarios sans contexte métier.
Ignorer les « incomplete executions » jusqu’à saturation du quota.
Ce qu’il faut retenir
Error handler sur chaque module critique.
Log structuré + alerte + file de reprise.
Retries bornés ; idempotence sur les upserts.
Procédure humaine documentée pour les cas manual.
FAQ
Traitez-les depuis le dashboard Make avant replay massif. Identifiez la cause (timeout, module supprimé) puis relancez ou archivez.
Oui pour stopper un Iterator après N erreurs consécutives et éviter des milliers d’opérations inutiles.
Dupliquez le scénario en « staging » avec webhook de test et clés API sandbox. Simulez 429/500 via mock HTTP.
