Comment débugger un scénario Make qui plante ?
Débugger un scénario Make consiste à ouvrir l'onglet History pour repérer l'exécution en échec, lire le message d'erreur du module concerné, puis rejouer ce module seul avec les mêmes données jusqu'à comprendre ce qu'il reçoit réellement. La majorité des pannes viennent d'une donnée d'entrée inattendue ou d'une connexion expirée, pas d'un bug de Make lui-même.
Ouvrez l'onglet History du scénario, repérez le module marqué en échec, lisez le message d'erreur, puis exécutez ce module isolément pour comparer ce qu'il reçoit réellement à ce qu'il attend.
Pourquoi un scénario Make plante-t-il ?
Un scénario Make est une suite de modules qui se transmettent des « bundles », des paquets de données structurées. Quand un module reçoit un bundle qu'il n'attend pas — un champ manquant, un format de date différent, une réponse d'API vide — il s'arrête et remonte une erreur au lieu de continuer avec une donnée incorrecte.
Dans la grande majorité des cas, la cause n'est pas un défaut de Make mais une hypothèse fausse sur ce qu'un module précédent envoie réellement. Débugger consiste donc surtout à retrouver ce point de rupture, pas à chercher un bug caché dans l'outil.
Où trouver l'historique d'une exécution qui a échoué ?
Chaque scénario Make conserve l'historique de ses exécutions, avec le détail des données entrées et sorties par chaque module.
- Ouvrir l'onglet History du scénarioAccessible depuis la page du scénario, il liste chaque exécution avec son statut et sa durée.
- Repérer l'exécution en échecElle apparaît en rouge, avec le module responsable clairement identifié.
- Lire le message d'erreur completIl précise en général le module, le champ ou le code de retour à l'origine du blocage.
- Inspecter le bundle d'entrée et de sortieCliquer sur un module de l'exécution affiche exactement ce qu'il a reçu et ce qu'il a tenté de renvoyer.
Ce niveau de détail est la première chose à consulter avant de modifier quoi que ce soit dans le scénario : il évite de corriger un module qui fonctionnait très bien.
Quelles sont les erreurs les plus fréquentes et comment les corriger ?
| Type d'erreur | Cause probable | Piste de correction |
|---|---|---|
| Champ manquant | Le module référence un champ absent du bundle reçu. | Comparer le mapping du module au résultat réel du module précédent. |
| Connexion expirée | Le jeton d'accès ou le mot de passe de l'application connectée a expiré. | Recréer la connexion depuis l'écran de configuration du module. |
| Quota d'opérations dépassé | Le plan Make ou l'API tierce atteint sa limite d'appels. | Vérifier la consommation dans le tableau de bord de l'organisation. |
| Délai dépassé (timeout) | Un service tiers répond trop lentement ou est temporairement indisponible. | Vérifier le statut du service, ajouter un délai d'attente plus long si le module le permet. |
| Erreur de module IA (OpenAI, Claude) | Clé API invalide, quota du fournisseur atteint ou prompt mal formé. | Retester le module isolément ; voir aussi notre article sur l'utilisation de ChatGPT ou Claude dans Make. |
Le centre d'aide Make sur la gestion des erreurs détaille les types d'erreurs et d'avertissements les plus courants, avec des pistes de correction pour chacun.
Comment utiliser les gestionnaires d'erreur d'un scénario Make ?
Plutôt que de laisser un scénario s'arrêter net, Make permet d'attacher un gestionnaire d'erreur à un module pour définir un comportement précis en cas d'échec.
- RetryRelance automatiquement le module en échec, utile pour une erreur temporaire côté service tiers.
- ResumePoursuit l'exécution avec une valeur de remplacement définie manuellement.
- CommitValide les opérations déjà effectuées avant l'erreur, sans les annuler.
- RollbackAnnule les opérations effectuées depuis le début de l'exécution en cas d'échec.
- Skip / BreakIgnore le bundle en erreur pour continuer sur les suivants, ou interrompt proprement le scénario.
Le choix du bon gestionnaire dépend surtout de ce que le module fait : un module qui envoie un e-mail ne se traite pas comme un module qui écrit dans une base de données. La documentation officielle des gestionnaires d'erreur Make détaille le comportement exact de chacun.
Que faire des exécutions incomplètes (Incomplete Executions) ?
Quand une erreur survient sans gestionnaire configuré, Make peut conserver l'exécution interrompue dans un onglet dédié plutôt que de perdre la donnée en cours de traitement.
Ce que fait cette fonction
- Elle stocke le bundle qui n'a pas pu être traité jusqu'au bout.
- Elle permet de corriger puis de relancer l'exécution manuellement.
- Elle évite de perdre silencieusement une donnée entrée dans le scénario.
Ce qu'il faut savoir
- Elle est désactivée par défaut : à activer dans les paramètres du scénario.
- Le nombre d'exécutions incomplètes conservées est limité selon le plan.
- Elle ne remplace pas un gestionnaire d'erreur, elle le complète.
D'après le centre d'aide Make sur les exécutions incomplètes, cette fonctionnalité doit être activée volontairement dans les paramètres du scénario avant de pouvoir l'utiliser.
À quoi ressemble un vrai débogage sur le terrain ?
Voici un exemple représentatif de notre méthode, sans donnée client ni chiffre inventé.
Une connexion expirée, pas un bug du scénario
Sur un scénario Make connecté à un CRM, des exécutions échouaient de façon intermittente sans changement récent du scénario. L'onglet History a montré que le module concerné recevait une erreur d'authentification, pas une donnée mal formée. La connexion au CRM avait simplement expiré côté fournisseur. La recréer a suffi à stabiliser le scénario.
Ce type de panne illustre une règle générale : avant de modifier la logique d'un scénario, il faut vérifier si le problème vient d'une connexion, d'un quota ou d'une donnée source, pas d'un défaut du scénario lui-même.
Comment éviter que l'erreur ne se reproduise ?
Si le diagnostic dépasse le temps disponible en interne, ces trois réflexes suffisent déjà à réduire nettement le nombre d'incidents qui se répètent d'une semaine à l'autre sur un scénario en production.
Quels contenus lire ensuite ?
Ces ressources complètent cet article sans cibler la même requête :
Questions fréquentes sur le débogage Make
Comment voir exactement quelle donnée un module a reçue ?
Dans l'onglet History, cliquer sur une exécution puis sur un module affiche son bundle d'entrée et de sortie, ce qui permet de comparer ce qui était attendu et ce qui a réellement circulé.
Un scénario qui fonctionnait hier peut-il échouer sans modification ?
Oui, si une source externe change : une API tierce modifie sa réponse, une connexion expire, ou la donnée reçue en entrée change de format sans que le scénario n'ait été touché.
Faut-il coder pour lire les messages d'erreur de Make ?
Non. Les messages d'erreur sont écrits en langage courant et indiquent en général le module et le champ concernés. Une lecture attentive suffit dans la plupart des cas.
Quelle différence entre un gestionnaire d'erreur et les exécutions incomplètes ?
Le gestionnaire d'erreur définit un comportement automatique (relancer, ignorer, annuler) au moment de l'échec. Les exécutions incomplètes conservent le bundle en erreur pour une correction et une relance manuelles ultérieures.
Comment être alerté automatiquement en cas d'échec d'un scénario ?
Make peut envoyer une notification par e-mail dès qu'une exécution échoue, et un module dédié peut aussi relayer l'alerte vers Slack, Teams ou une autre messagerie selon la configuration choisie.