MakeMONITORER LES SCÉNARIOS
Prérequis
- Inventaire des scénarios Make actifs avec owner nommé
- Table Airtable « Make runs » ou « incidents automation »
- Classification P0 (bloquant métier) / P1 (dégradé) / P2 (confort)
- Canal Slack dédié ops ou notifications e-mail PM
Un scénario Make cassé depuis une mise à jour API peut passer inaperçu jusqu’à ce qu’un client signale un lead manquant. Sans observabilité minimale — tags, logs centralisés, revue périodique — vous pilotez les automations à l’aveugle. Airtable, Slack et l’historique Make suffisent pour la plupart des projets agence.
Classifier et documenter les scénarios
Maintenez un registre Notion ou Airtable : nom scénario, priorité, trigger, owner, dernière revue, dépendances API. Chaque scénario P0 a un paragraphe « impact si down » (ex. perte leads site vitrine).
Dans Make, ajoutez une description au scénario et liez l’URL de la doc. Les nouveaux arrivants comprennent le rôle sans ouvrir chaque module.
Identifiez les scénarios sans error handler — premier candidat à la remediation avant d’ajouter plus de logs.
Centraliser logs et métriques
En fin de scénario (branche succès), créez une ligne Airtable « runs » : statut success, durée, compteur records. En error handler (voir make-gestion-erreurs-reprise), statut fail + résumé.
Construisez une vue Airtable « 7 derniers jours » avec taux succès par scénario. Un graphique natif ou une interface suffit — pas besoin de Datadog pour dix scénarios.
Option : scénario agrégateur hebdo → Slack résumé « P0 : 412 OK, 2 FAIL » avec liens vers les exécutions Make en échec.
Revue hebdomadaire et alerting
Bloquez 20 minutes chaque lundi : parcourez l’historique Make des P0, traitez les incomplets, vérifiez les pics d’opérations (quota proche).
Alertes immédiates : error handler P0 → Slack @channel ops avec seuil « plus de 3 échecs / heure » via compteur Airtable + Make watch.
Après chaque déploiement site (formulaire, webhook), lancez un test manuel et contrôlez la ligne Airtable correspondante dans l’heure.
Erreurs fréquentes
Surveiller uniquement le dashboard Make sans agrégation : difficile de voir les tendances.
Trop d’alertes P2 : l’équipe ignore le canal #ops.
Oublier de monitorer les scénarios « petits » qui alimentent le reporting client.
Logs sans execution_id : corrélation impossible avec le support Make.
Ce qu’il faut retenir
Scénarios P0/P1 identifiés et documentés.
Chaque run critique laisse une trace Airtable.
Revue hebdo + alertes sur seuils, pas sur chaque succès.
Couplé aux error handlers pour boucle fermée.
FAQ
Rarement avant des dizaines de scénarios ou des SLAs stricts. Airtable + Slack + historique Make couvrent l’essentiel en agence.
30–90 jours en Airtable pour l’opérationnel ; archivez ou purgez selon la politique client et le RGPD.
Le PM ou l’intégrateur Make référent — pas « l’équipe » anonyme. Un owner par scénario P0.
