Chapitre 7/9 • 15 min de lecture

Gestion d'erreurs

Construire des scénarios qui ne cassent pas en silence, et savoir réparer quand ça arrive.

⏱️ En bref : La gestion d'erreurs distingue les amateurs des pros sur Make.com. Sans elle, un scénario casse, vous perdez des données et vous le découvrez 3 semaines plus tard. Ce chapitre couvre les 5 directives d'erreur (Break, Resume, Commit, Rollback, Ignore), les retry policies et les patterns d'alerting que j'utilise en production.

Pourquoi un scénario échoue (et où regarder)

Trois familles d'erreurs sur Make.com, chacune avec son traitement :

  • Erreurs réseau / API : timeout, 502 Bad Gateway, rate limit. Souvent transitoires, donc à retry
  • Erreurs de données : champ vide, type incompatible, valeur hors enum. À filtrer en amont
  • Erreurs de logique : mapping cassé, scénario mal câblé. À corriger dans le builder

Le premier réflexe quand un scénario échoue : ouvrir l'historique d'exécution (icône horloge en bas), cliquer sur l'exécution rouge, et inspecter le module qui a planté. Make affiche le bundle d'entrée, le bundle de sortie (si existant) et le message d'erreur. Dans 80% des cas, la cause saute aux yeux.

Les 5 directives d'erreur Make.com

Sur n'importe quel module, clic droit → Add error handler. Vous obtenez une route alternative avec 5 directives possibles, à comprendre absolument :

  • Break : marquer l'exécution comme incomplète, la stocker dans la queue, retenter automatiquement plus tard. La directive par défaut pour les erreurs API transitoires
  • Resume : forcer un faux output et continuer le scénario comme si tout allait bien. Utile quand l'erreur est non bloquante (ex : la notification Slack a échoué mais le deal a bien été créé)
  • Commit : valider tout ce qui a été fait avant l'erreur (utile pour les transactions)
  • Rollback : annuler tout ce qui a été fait avant l'erreur (idem)
  • Ignore : passer le bundle en silence et continuer avec le suivant. À utiliser quand l'erreur affecte un seul élément d'un lot

💡 Pattern recommandé

Sur tout module qui appelle une API externe : ajouter un error handler avec une directive Break, des retry de 3 tentatives toutes les 15 minutes, et une notification Slack en cas d'échec définitif. Trois lignes de configuration, des heures de débogage évitées.

Configurer une retry policy

Plutôt que de gérer les retry manuellement, Make.com permet de les déclarer en un paramètre. Ouvrir le module, cliquer sur les paramètres avancés (icône engrenage), section Allow storing of incomplete executions → activer.

Ensuite dans les paramètres du scénario (en bas à gauche → ⋮ → Settings) :

  • Sequential processing : OFF si vous voulez que les retry ne bloquent pas les nouvelles exécutions
  • Number of attempts : 3 est un bon défaut. Plus = utile pour les API capricieuses
  • Interval between attempts : 15 min minimum, jusqu'à 24h

Les exécutions incomplètes sont visibles dans l'onglet Incomplete executions du scénario. Vous pouvez les retenter manuellement, les modifier ou les supprimer.

Alerter quand un scénario casse

Make ne vous notifie pas par défaut quand un scénario échoue. Il faut le configurer. Trois approches, par ordre de complexité :

  • Email natif Make : Settings du scénario → activer "Send email when execution fails". Simple mais souvent perdu dans les promos
  • Error handler avec module Slack : ajouter une route d'erreur qui envoie un message Slack avec le nom du scénario, l'erreur et un lien vers l'exécution. Recommandé
  • Scénario monitor centralisé : un scénario maître qui tourne 1×/heure, lit l'API Make pour récupérer toutes les exécutions échouées du compte, et les agrège dans un Slack ou un Notion. C'est ce que je déploie chez mes clients qui ont 20+ scénarios actifs

Debugging : la checklist quand un scénario plante

  • Inspecter le bundle d'entrée du module en erreur : 90% des erreurs viennent d'une donnée inattendue (null, mauvais format, encoding)
  • Vérifier les logs de l'API distante : Pipedrive, HubSpot, Stripe ont tous une console qui montre les requêtes reçues. Comparer avec ce que Make envoie
  • Désactiver temporairement les modules suspects : isoler le problème en commentant des branches
  • Régénérer la connexion : un token OAuth expiré donne souvent des 401 silencieux
  • Tester avec un bundle minimaliste : utiliser le bouton "Run this module only" et lui passer manuellement un bundle de test

⚠️ Piège fréquent

Si votre scénario marche parfaitement en "Run once" mais casse en automatique, vérifiez la concurrence. Sur des scénarios qui touchent une même ressource (créer un deal Pipedrive avec dédoublonnage), deux exécutions parallèles peuvent créer des doublons. Solution : passer en Sequential processing : ON.

Une fois la gestion d'erreurs maîtrisée, le chapitre Bonnes pratiques couvre les conventions de nommage, l'architecture multi-scénarios et les optimisations de coût.