MakeALERTES PROJET SLACK
Prérequis
- Workspace Slack avec app Make autorisée
- Service émetteur capable d’envoyer un header de signature (HMAC) ou bearer token
- Canaux Slack #projet, #incidents définis
- Variables Make pour secrets (jamais en clair dans les modules)
Un webhook Make exposé sans authentification peut être spammé ou détourné — notifications fantômes, données injectées, quota Make épuisé. En validant la signature ou un secret partagé, en structurant les payloads et en routant par gravité, vous obtenez des alertes projet actionnables sans bruit ni risque évident.
Créer le webhook Make et sécuriser l’entrée
Ajoutez un module « Custom webhook » — notez l’URL générée. Activez « JSON » comme type de données attendu. Renommez le scénario `[P1] Webhook → Slack`.
Configurez l’émetteur (Vercel deploy hook, formulaire custom, GitHub Action) pour envoyer un header `X-Signature` (HMAC-SHA256 du body avec secret) ou `Authorization: Bearer <token>` stocké en variable Make.
Dans Make, premier module après webhook : Router ou script de validation — si signature invalide, route vers « reject » (HTTP 401 response optionnelle) sans appeler Slack.
Parser, filtrer et formater le message Slack
Parse JSON → Set variables (`project`, `event`, `severity`, `url`). Router : branche high → Slack #incidents ; branche default → #projet.
Message Slack structuré : titre avec indicateur de gravité, champs en bullet, lien cliquable vers la tâche ClickUp ou le deploy Vercel. Évitez les murs de texte JSON.
Masquez les données sensibles : pas d’e-mail client complet en canal public — utilisez les 4 derniers caractères ou l’ID interne.
Agréger plusieurs sources et monitorer
Un même scénario peut recevoir plusieurs émetteurs si le secret et le schéma JSON sont partagés — ou dupliquez par source avec le même handler Slack pour limiter la complexité.
Branchez un error handler (make-gestion-erreurs-reprise) : échec Slack API → e-mail de secours au PM. Un incident non notifié est pire qu’un faux positif filtré.
Loggez chaque appel accepté/refusé dans Airtable (timestamp, event, signature_ok) pour audit léger — voir make-monitoring-logs-scenarios.
Erreurs fréquentes
Webhook public sans vérification : spam ou abus de quota Make.
Secret roté côté émetteur sans mise à jour Make : toutes les alertes rejetées silencieusement.
Notifier #general pour chaque build preview : bruit immédiat.
Payload non validé : injection de texte Slack (@channel forgé) si champs copiés tels quels.
Ce qu’il faut retenir
Signature ou bearer vérifié avant toute action.
Messages Slack courts, structurés, sans données sensibles.
Routage par gravité ; error handler de secours.
Logs d’acceptation/rejet pour diagnostiquer les pannes.
FAQ
Souvent pour le simple. Make reste utile pour agréger deploy + formulaire + monitoring custom avec le même format de message.
Utilisez le module crypto Make (HMAC SHA256) sur le body brut et comparez au header. Le crypto natif Make suffit en général.
Datastore Make ou compteur Airtable : plus de N appels / minute → route « throttle » avec alerte unique, pas 50 messages Slack.