Une alerte en marque blanche est l’e-mail que le client lit, pas celui que l’outil vous envoie. L’alerte interne de SiteGarde contient l’URL, le code HTTP, l’état précédent, le nouvel état et un lien vers le moniteur. Ce message reste dans l’agence. Le client reçoit un second e-mail, parti de votre domaine, qui dit ce qui est constaté et quand vous redonnez des nouvelles.
Ce que le client peut faire avec le message
Il doit pouvoir, sans vous appeler, répondre à trois questions : quel site, depuis quand, est-ce que vous êtes déjà dessus. S’il doit ouvrir une pièce jointe, deviner le nom du site dans une URL longue, ou cliquer un lien qui lui demande un compte qu’il n’a pas, le message a raté son rôle.
Décidez à l’avance qui est destinataire. En général : une adresse nominative chez le client (pas info@ seulement) et une copie à la boîte d’astreinte de l’agence. Le client n’est pas en copie de toutes les alertes internes. Une page brochure qui renvoie 404 à 2 h du matin ne justifie pas de le réveiller. Le critère de réveil se fixe dans la fiche du compte, avant le premier incident.
Le message d’incident
Gardez un modèle, et remplissez-le avec les valeurs du contrôle, pas avec une phrase inventée.
| Champ | Exemple | Rôle |
|---|---|---|
| Objet | Nom du site — indisponible — HTTP 502 | Reconnaissable sur un écran verrouillé |
| Constat | https://example.com/ répond 502 depuis 06:14 (heure de Paris) | Fait vérifiable |
| Périmètre | Accueil et page devis, pas le blog | Évite la panique hors sujet |
| Action en cours | Ticket ouvert chez l’hébergeur, référence H-18442 | Prouve que quelqu’un agit |
| Prochain point | Nouveau message avant 06:45, même sans changement | Pose une heure, pas dès que possible |
Le code HTTP vient du contrôle, pas d’une impression. Un délai de connexion sans réponse n’est pas un 500 : écrivez délai dépassé, aucune réponse HTTP. Un 503 posé par vous pendant une mise à jour ne part pas avec le modèle d’incident, il part avec le modèle de maintenance, avant le créneau.
Envoyer depuis le domaine de l’agence
- Créez une boîte ou un alias
alerte@sur le domaine de l’agence. - Vérifiez que le SPF du domaine autorise le serveur qui envoie réellement (la boîte, ou l’outil de messagerie transactionnelle que vous utilisez).
- Signez avec DKIM. Sans signature, le message d’un incident à 6 h finit dans les courriers indésirables, et le client dira qu’il n’a pas été prévenu.
- Mettez en Reply-To une adresse lue par la personne d’astreinte, pas une no-reply.
- Envoyez un essai à votre propre adresse et à celle du client le jour de l’ouverture du compte. Demandez-lui de confirmer qu’il l’a vu hors des indésirables.
Le nom de l’outil, le score sur 100 et le lien d’interface ne figurent pas dans ce message. Le client n’a pas à savoir quel logiciel a sonné. Il a à savoir que l’agence a constaté un 502 et qu’elle a un ticket.
Le retour à la normale
Le second modèle est plus court. Objet : Nom du site — rétabli — HTTP 200. Corps : heure de début, heure de fin, code actuel, ce que vous avez fait en une phrase (relance PHP-FPM, retour arrière d’une extension, bascule DNS). Ajoutez si le contenu a été modifié ou non. Un client qui a publié un article pendant la panne veut savoir si vous avez restauré une sauvegarde par-dessus.
N’envoyez pas le retour à la normale tant que vous n’avez pas rejoué la requête vous-même, depuis un réseau autre que le serveur. Un cache local peut vous montrer un 200 que le visiteur n’a pas.
Ce que vous ne transférez pas
Le transfert brut de l’alerte interne montre un expéditeur que le client ne connaît pas, un vocabulaire (score, niveau critical) qui n’est pas dans votre contrat, et parfois l’URL d’un autre site si vous avez mal filtré les destinataires. Sur une agence qui gère plusieurs comptes dans le même outil, une erreur de copie peut envoyer au client A le nom du site du client B. Le modèle maison, rempli à la main ou par un script qui ne contient que les champs de ce client, coupe ce risque.
Rangez les deux modèles (incident et rétablissement) dans le dossier du client, à côté de la liste des destinataires et du critère de réveil. C’est le livrable. Le jour de la panne, vous ne rédigez plus : vous remplissez l’heure, l’URL et le code. Le suivi multi-sites, lui, se prépare dans le guide monitoring pour agences. Si l’alerte interne doit aussi alimenter un canal d’équipe, réglez-le à part, comme décrit pour les webhooks d’alerte.