L'un des aspects les plus déroutants lorsqu'on débute sur Make.com est la gestion des erreurs. Vous avez passé des heures à construire un scénario parfait, il fonctionne à merveille, puis un jour, sans crier gare, il s'arrête. La raison ? Une seule petite erreur non gérée.
Contrairement à d'autres plateformes, Make a une politique très stricte : par défaut, une erreur désactive votre scénario. Cette approche, bien que sévère, nous oblige à construire des automatisations plus robustes. Comprendre comment anticiper et gérer ces erreurs est donc une compétence essentielle pour passer de créateur de scénarios occasionnel à véritable expert de l'automatisation.
Pourquoi la gestion d'erreur est-elle si importante sur Make
Le comportement par défaut de Make est simple : si un module rencontre une erreur et que vous n'avez rien prévu pour la gérer, l'exécution s'arrête immédiatement. Dans la plupart des cas, Make désactivera également l'ensemble du scénario pour éviter que des erreurs répétées ne consomment vos opérations.
Cela signifie qu'un scénario critique pour votre entreprise, comme la synchronisation de vos contacts CRM ou le traitement de nouvelles commandes, peut être mis hors service par un simple problème de connexion temporaire ou une donnée mal formatée.
Heureusement, Make nous donne tous les outils nécessaires pour reprendre le contrôle. L'idée n'est pas d'empêcher les erreurs de se produire – c'est souvent impossible – mais de dire à Make quoi faire lorsqu'elles se produisent.
Les différents types de gestionnaires d'erreur
Pour intercepter une erreur, il suffit de faire un clic droit sur un module et de sélectionner "Add error handler". Une route alternative, représentée par des pointillés, apparaît. Vous pouvez alors y connecter un ou plusieurs modules pour définir un chemin de secours.
Make propose plusieurs directives, appelées gestionnaires d'erreur, qui dictent le comportement à adopter. Chacune a un rôle très précis.
Le gestionnaire Ignore
C'est le plus simple à comprendre. La directive Ignore dit littéralement à Make : "S'il y a une erreur sur ce module, ne t'en préoccupe pas, oublie les données qui ont causé le problème et continue le scénario avec les autres."
- Quand l'utiliser ? Idéal pour les opérations non critiques où la perte d'une seule donnée n'est pas grave. Par exemple, si vous synchronisez une grande liste de contacts et que quelques-uns échouent à cause de données invalides, vous préférez peut-être que les 99% restants soient traités plutôt que de tout arrêter.
- Impact sur le scénario : L'exécution est considérée comme un succès, même si des erreurs ont été ignorées.
Attention : Utiliser Ignore sans discernement peut masquer des problèmes plus profonds dans votre automatisation. Utilisez-le uniquement lorsque vous êtes certain que l'erreur est isolée et sans conséquence.Le gestionnaire Resume
La directive Resume est l'une des plus puissantes. Elle permet de remplacer la sortie d'un module en erreur par une valeur de remplacement que vous définissez. Le scénario continue ensuite comme si de rien n'était, en utilisant cette valeur de secours.
- Quand l'utiliser ? Parfait lorsque vous avez besoin qu'une valeur existe pour que le reste du scénario fonctionne, même si elle n'est pas parfaite.
- Exemple concret : Imaginez un scénario qui récupère le prénom d'un client pour personnaliser un email. Si le module de recherche échoue, au lieu de bloquer l'envoi, vous pouvez utiliser
Resumepour fournir un prénom par défaut comme "Cher client". L'email partira, assurant la continuité du processus. - Impact sur le scénario : L'exécution est marquée comme un succès.
Le gestionnaire Break
La directive Break est conçue pour gérer les erreurs temporaires. Lorsqu'une erreur survient, Break arrête le traitement des données problématiques, les stocke dans une file d'attente appelée "Incomplete executions", et tente de les retraiter plus tard.
Pour que cela fonctionne, vous devez activer une option cruciale dans les paramètres de votre scénario : "Allow storing of incomplete executions".
- Quand l'utiliser ? C'est la solution de choix pour les erreurs de connexion passagères ou les limitations de taux d'API (quand un service vous demande de ralentir). Le service était peut-être indisponible pendant quelques secondes ; une nouvelle tentative quelques minutes plus tard a de grandes chances de réussir.
- Configuration : Vous pouvez définir le nombre de tentatives et l'intervalle entre elles.
- Impact sur le scénario : L'exécution est marquée avec un avertissement (Warning). Le scénario reste actif et continue de traiter les nouvelles données.
Le gestionnaire Rollback
Le Rollback est le comportement le plus sécuritaire pour les opérations qui impliquent des transactions, comme les modifications de bases de données. Si une erreur se produit à n'importe quelle étape du scénario, Rollback annule toutes les opérations effectuées depuis le début de l'exécution.
- Quand l'utiliser ? Indispensable lorsque vous avez besoin d'une exécution "tout ou rien". Par exemple, lors d'une commande en ligne, vous voulez mettre à jour le stock ET créer une facture. Si la création de la facture échoue, vous ne voulez surtout pas que le stock ait été déduit.
Rollbacks'assure que la base de données revient à son état initial. - Impact sur le scénario : L'exécution est marquée comme une erreur.
Le gestionnaire Commit
Le Commit est l'opposé du Rollback. S'il est déclenché, il arrête le scénario mais valide toutes les opérations transactionnelles qui ont réussi jusqu'au point de l'erreur.
- Quand l'utiliser ? C'est un cas d'usage plus rare. Il peut être utile si vous effectuez une série d'opérations indépendantes et que vous souhaitez conserver le résultat de celles qui ont fonctionné, même si l'une d'elles échoue en cours de route.
- Impact sur le scénario : L'exécution est marquée comme un succès.
Tableau comparatif des gestionnaires d'erreur
Pour y voir plus clair, voici un résumé des différentes directives et de leurs cas d'usage.
| Gestionnaire | Action Principale | Cas d'usage idéal | Statut de l'exécution |
|---|---|---|---|
| Ignore | Passe à la suite en ignorant les données en erreur. | Opérations non critiques, traitement de masse où quelques pertes sont acceptables. | Succès |
| Resume | Remplace la sortie en erreur par une valeur de secours. | Quand une valeur est nécessaire pour la suite, même si elle est par défaut. | Succès |
| Break | Met l'exécution en pause et retente plus tard. | Erreurs temporaires (API indisponible, limite de taux atteinte). | Avertissement (Warning) |
| Rollback | Annule toutes les opérations de l'exécution en cours. | Opérations transactionnelles qui doivent être atomiques ("tout ou rien"). | Erreur |
| Commit | Valide les opérations réussies jusqu'à l'erreur et arrête. | Opérations transactionnelles où un succès partiel est acceptable. | Succès |
Mettre en place une stratégie de gestion d'erreur efficace
Construire des scénarios résilients ne se résume pas à ajouter une directive au hasard. Voici une approche structurée :
- Identifier les points de défaillance Regardez votre scénario et demandez-vous : "Quels modules sont les plus susceptibles de planter ?". En général, ce sont tous les modules qui communiquent avec un service externe (API, base de données, etc.). La connexion peut être perdue, les données peuvent être invalides, les permissions peuvent changer.
- Choisir la bonne directive pour chaque cas
- Un module qui récupère des données d'une API externe ?
Breakest souvent le meilleur choix pour gérer les pannes temporaires. - Un module qui traite des données entrantes qui peuvent être mal formatées ?
Ignorepeut être une option si la donnée n'est pas critique, ouResumesi une valeur par défaut est acceptable. - Un module qui met à jour une base de données ?
Rollbackest la sécurité par défaut.
- Construire des chemins d'erreur intelligents Le plus grand atout de Make est que vous pouvez connecter n'importe quel module après une directive d'erreur. Cela ouvre des possibilités infinies :
- Notification : Connectez un module Slack ou Email pour vous alerter (ou votre client) en temps réel lorsqu'une erreur spécifique se produit. Vous pouvez même inclure les détails de l'erreur dans le message.
- Journalisation : Envoyez les détails de l'erreur vers une feuille Google Sheets ou une base de données Airtable pour conserver un historique des problèmes et les analyser plus tard.
- Logique de secours : Si la recherche d'une information via une API A échoue, vous pouvez utiliser un chemin d'erreur pour tenter de la récupérer via une API B.
Une bonne pratique consiste à terminer chaque chemin d'erreur par une directive. Par exemple, après avoir envoyé une notification Slack, vous pouvez utiliser Break pour quand même essayer de retraiter les données plus tard.Conclusion : Penser en termes de résilience
La gestion d'erreur sur Make peut sembler intimidante au début, mais elle est en réalité incroyablement puissante. Elle transforme les erreurs d'une fatalité qui stoppe votre travail en événements prévisibles que vous pouvez contrôler.
En adoptant une approche proactive – en identifiant les points faibles de vos scénarios et en définissant des chemins de secours clairs – vous ne construisez pas seulement des automatisations qui fonctionnent. Vous construisez des systèmes fiables, résilients et professionnels, capables de fonctionner sans surveillance constante et de gérer les imprévus du monde numérique.
