Alerting et ITSM

Objectif

Une alerte utile doit arriver au bon endroit, avec la bonne sévérité et une action attendue. Wadyu ne doit pas créer du bruit. Chaque route doit correspondre à un processus opérationnel MSP : sécurité, conformité, économie, exploitation ou support client.

Événements pertinents

Les événements typiques sont : drift critique, perte de conformité, patch manquant, économie significative détectée, nouveau candidat Reclaim au-dessus d’un seuil, échec de synchronisation Graph, anomalie collecteur, clé expirée, absence de données ou erreur service de synchronisation répétée.

Chaque événement doit posséder un niveau de sévérité, un client, une source, une description, un horodatage et une action recommandée. Sans action claire, une alerte devient une notification inutile.

Providers

Teams convient aux MSP Microsoft-first. Slack convient aux équipes déjà organisées par canaux. PSA convient à la production MSP : HaloPSA, ConnectWise ou équivalent. ServiceNow cible les environnements enterprise. Webhook permet d’intégrer un outil maison.

Pour chaque provider, stockez les endpoints et tokens comme secrets. Les URLs webhook ne doivent pas apparaître dans les captures, exports ou tickets non restreints.

Routage

Le routage doit permettre de filtrer par client, sévérité, type d’événement et module. Exemple : les économies supérieures à 500 CHF par mois vont vers le canal gouvernance, les erreurs Graph répétées vers exploitation, les drifts critiques vers sécurité.

Prévoyez des seuils pour éviter le bruit : regrouper les événements similaires, limiter la fréquence et escalader seulement après répétition ou impact confirmé.

Contenu d’une alerte

Une alerte doit contenir le client, le module, la sévérité, le résumé, l’impact, le lien vers la console, l’action recommandée et la référence d’audit. Elle ne doit pas contenir de secret, token, clé collecteur, access token ou détail personnel non nécessaire.