Une alerte e-mail n’est utile que si elle arrive dans une boîte lue par quelqu’un qui peut agir, avec assez d’informations pour savoir quelle URL est en cause. Le message « votre site a un problème », sans code, sans URL et sans heure, oblige à tout revérifier. Le message qui n’arrive pas du tout laisse croire que la nuit a été calme.
L’e-mail est un canal lent et fragile (indésirables, boîte pleine, personne en congés). Il reste adapté comme trace écrite. Pour une panne qui réveille, couplez-le à un canal plus immédiat. La mise en place générale d’une alerte est décrite dans créer une alerte de panne.
Où envoyer, et depuis quelle adresse
L’adresse de destination est une liste ou une boîte partagée (alertes@ ou technique@), plus un remplaçant si une seule personne est d’astreinte. Quand cette personne part, on retire son adresse de la liste sans reconstruire toute la surveillance. Une alerte envoyée seulement au fondateur, sur une boîte qu’il ne consulte plus le week-end, n’est pas une alerte d’équipe.
L’expéditeur utilise un domaine que vous contrôlez, avec SPF, DKIM et une politique DMARC cohérente. Un outil qui envoie depuis une adresse générique mal alignée tombe dans les courriers indésirables le jour d’une vraie panne, pas pendant le test. Si vous passez par un service de surveillance externe, comme le monitoring SiteGarde, vérifiez quand même le dossier des indésirables de la boîte partagée après la première alerte réelle, pas seulement après l’e-mail de bienvenue.
N’envoyez pas les alertes de production sur une liste qui reçoit aussi les newsletters. Elles se noient. Une boîte ou un libellé réservé aux incidents suffit.
Ce que le message doit montrer
L’objet se lit sur un écran verrouillé. Il contient l’essentiel :
- le nom du site ou l’URL courte ;
- l’état : panne ou rétablissement ;
- le code ou le symptôme (
HTTP 502, délai dépassé, certificat) ; - l’heure.
Exemple d’objet : [Panne] exemple.fr/paiement — HTTP 502 — 03:12.
Le corps répète l’URL exacte, le code reçu, l’heure de début, le point de contrôle qui a vu l’échec, et le lien vers le détail. Il ne remplace pas le diagnostic. Il évite d’ouvrir le mauvais site quand vous en surveillez plusieurs. Un second message au rétablissement, avec la durée, ferme l’incident. Sans ce second message, personne ne sait si c’est revenu ou si l’outil s’est tu.
Quand dix URL tombent ensemble parce que l’hébergement est en panne, groupez. Dix e-mails à la même minute décrivent un seul incident et poussent la boîte à classer le suivant en indésirable. Une alerte « le site ne répond plus », plus le détail dans l’outil, vaut mieux qu’une rafale.
Éviter la boîte qu’on ne lit plus
Une alerte pour chaque accrochage d’une minute habitue l’équipe à archiver sans lire. Exigez deux ou trois échecs de suite avant l’envoi, et réservez l’e-mail immédiat aux URL dont la panne coûte vraiment. Le réglage des faux signaux est le sujet des faux positifs.
Testez le canal le jour de la configuration, puis après chaque changement de domaine d’envoi ou de boîte :
- Déclenchez une alerte de test vers la liste partagée.
- Vérifiez la réception hors indésirables, sur le webmail et sur un téléphone qui sert la nuit.
- Lisez l’objet sans ouvrir : on doit comprendre l’URL et l’état.
- Coupez le test et vérifiez que le message de rétablissement arrive aussi.
- Retirez les anciennes adresses encore en copie.
Relisez une fois par trimestre qui est encore sur la liste. Le test d’il y a un an ne prouve pas que la boîte actuelle reçoit encore les messages. Un filtre « ranger les alertes » trop large, posé par quelqu’un d’agacé, a le même effet qu’une panne de l’expéditeur : le silence.