Slack convient aux alertes parce que l’équipe y est déjà. Il convient mal si chaque contrôle y poste une ligne. Au bout de quelques jours, le canal est muet pour tout le monde, y compris le soir où le paiement ne répond plus. Le réglage tient dans le choix du canal, dans le contenu du message, et dans la décision de qui est mentionné.
L’e-mail reste utile en parallèle : il laisse une trace que le défilement de Slack ne garantit pas. Les deux canaux ne doivent pas répéter chaque frémissement. Le message Slack prévient. L’e-mail, ou l’historique de l’outil, permet de relire l’incident le lendemain. Le détail d’un e-mail lisible est dans les alertes e-mail.
Brancher un canal dédié
Créez un canal du type #alertes-site, privé dès que les messages citent des URL non publiques, des noms de clients ou une préproduction. Invitez les personnes qui peuvent agir, et le remplaçant d’astreinte, pas toute la société « pour information ».
Le branchement habituel est une URL de webhook entrant, ou une application Slack du service de surveillance. Cette URL est un secret : elle permet de poster dans le canal. Elle ne se commite pas dans le dépôt, ne se colle pas dans un ticket, et se régénère si elle a fuité. Un webhook par environnement évite que la recette poste au milieu des pannes de production.
Le service qui interroge le site depuis l’extérieur, par exemple le monitoring SiteGarde, envoie alors le message quand la règle d’alerte est atteinte, pas à chaque contrôle réussi. Un message « tout va bien » chaque heure n’a pas sa place dans ce canal. Le rétablissement, lui, oui : sans lui, personne ne sait si l’incident est fini.
Ce qu’on écrit dans le message
Le message tient en quelques lignes, lisibles sur le téléphone :
- panne ou rétablissement ;
- URL exacte ;
- code HTTP ou délai dépassé ;
- heure de début ;
- lien vers le détail dans l’outil.
@here ou @canal seulement si une personne doit intervenir maintenant : accueil, paiement, connexion, formulaire de demandes, en panne confirmée. Un certificat qui expire dans trente jours peut arriver dans le même canal sans mention. Une 404 sur un ancien article non plus. Si tout mentionne tout le monde, les mentions ne veulent plus rien dire. L’organisation de qui dort avec le téléphone est le sujet de l’astreinte.
Quand un hébergement tombe, vingt URL échouent ensemble. Groupez en un message « le site ne répond plus », plutôt qu’une ligne par URL qui pousse le canal vers le bas. La règle de confirmation (deux ou trois échecs, pas le premier timeout) se pose dans l’outil, avant Slack. Le canal ne doit pas servir de filtre humain à des sondes trop nerveuses.
Garder le canal crédible
- Envoyez un message de test le jour du branchement. Vérifiez qu’il arrive dans le bon canal, pas en message direct oublié.
- Déclenchez une vraie condition (URL volontairement fausse sur une surveillance de test) et lisez le message sur un téléphone.
- Coupez, et vérifiez le message de retour.
- Au bout de deux semaines, comptez les messages qui n’étaient pas une panne. S’ils dominent, resserrez la règle. N’ajoutez pas un second canal pour « les vraies alertes » : vous aurez deux endroits à ne plus lire.
- Retirez les webhooks des anciens outils encore actifs. Un plugin oublié qui poste « backup OK » tous les soirs suffit à dégrader le canal.
Slack ne remplace pas la correction. Le message dit qu’une URL a répondu 502 à telle heure. La suite se fait chez l’hébergeur, dans les logs, ou dans le journal des changements de la journée. Épinglez dans le canal le lien vers ce journal et vers la page de statut de l’hébergeur, pas une procédure de vingt pages que personne n’ouvre à 3 h.