Pourquoi les alertes n'arrivent-elles jamais, ou arrivent-elles dans les indésirables ?
En bref
Une surveillance que personne n'entend est une décoration. Les alertes se perdent de trois façons : filtrées par la messagerie, envoyées à une seule personne absente, ou enfouies sous le bruit. Le remède, c'est l'acheminement, plus d'un canal pour ce qui compte, et une franchise sur ce qui a le droit d'interrompre quelqu'un.
Un système de surveillance n’a qu’un seul travail au moment de la panne : atteindre un être humain. Tout ce qui précède — les contrôles, les tableaux de bord, l’historique — n’est que préparation. Et c’est à cette dernière étape, la remise, que la plupart des systèmes échouent en silence.
Où se perd une alerte ?
À trois endroits : dans le filtre de la messagerie, dans la boîte d’une seule personne, ou sous le bruit des autres alertes.
Elle a été filtrée. Le message a été envoyé, accepté, et rangé dans un dossier que personne n’ouvre. Une histoire circule chez ceux qui font tourner des sites : une panne qui a duré plus d’une journée, et l’alerte retrouvée après coup dans les indésirables, horodatée correctement. Rien n’était cassé. Tout a fonctionné exactement comme configuré.
Elle est partie vers une seule personne. La version classique vient des administrateurs de sauvegardes : des mois sans une seule sauvegarde valable, parce que les avis d’échec allaient vers une unique boîte appartenant à quelqu’un qui avait quitté l’entreprise. Une adresse n’est pas un destinataire, c’est un point de défaillance unique avec un nom dessus.
Elle a été enfouie. Celle-là est moderne, et la plus difficile à admettre. Les alertes arrivent, toutes, tout le temps, et à un moment tout le monde a cessé de lire. Un système qui crie au loup quarante fois par semaine a dressé son propre public à ignorer la quarante et unième, qui est la vraie.
Que faut-il corriger en premier ?
D’abord, arrêter le bruit. Une panne devrait devoir se répéter avant d’être annoncée ; un paquet perdu n’est pas une panne. Ce qui tombe ensemble — tout ce qui est sur un serveur, tout ce qui est derrière une ligne — doit produire un message et un rétablissement, pas neuf de chaque. Et pendant une mise en production, les alertes doivent être mises en sourdine exprès, par toi, plutôt qu’ignorées par habitude.
Ensuite, acheminer. Regroupe tes surveillances par qui s’en occupe réellement et donne à chaque groupe son propre destinataire : cette boîte, cette discussion, cette personne. Quand un contact est hors de l’entreprise — l’installateur, le fournisseur, la personne qui ouvre le magasin — donne-lui ses propres alertes, dans sa propre langue. Une alerte dont personne ne se sent responsable est une alerte sur laquelle personne n’agit.
Ensuite, choisis celles qui méritent d’interrompre. Sois honnête et bref : la plupart des services n’ont besoin de réveiller personne. Les deux ou trois qui le méritent doivent atteindre un téléphone, parce qu’un téléphone qui sonne est le seul canal qui n’exige pas que quelqu’un soit en train de regarder quelque chose. Règle-le avec retenue — seulement si le service est encore à terre après quelques minutes, jamais pendant les heures que tu as déclarées silencieuses, un rappel si la ligne était occupée — et il reste crédible.
Enfin, garde une trace. Un appel téléphonique peut être vérifié : s’il a été décroché, et quelle part du message a réellement été entendue avant que quelqu’un raccroche. C’est là toute la différence entre « nous t’avons alerté » et « tu as été prévenu ».
Et les rappels
Le mode de défaillance que personne n’anticipe, c’est l’alerte qui arrive, qui est acquittée à minuit par une personne fatiguée, puis oubliée. Un service encore à terre mérite de le redire — après une heure, après six, puis une fois par jour — jusqu’à ce que quelqu’un le répare, ou décide, délibérément, que cela peut attendre.
Que faire cette semaine
- Envoie-toi une alerte de test sur chaque canal que tu as configuré, et découvre où elle atterrit. Une fois sur deux, c’est tout l’exercice.
- Remplace chaque destinataire « une seule boîte » par un groupe, et écris noir sur blanc qui en est réellement responsable.
- Compte les alertes des sept derniers jours. Tout ce sur quoi tu n’as pas agi est soit un seuil à changer, soit une surveillance à supprimer.
- Choisis les services qui justifient un appel téléphonique. Si la liste dépasse trois, c’est une liste de souhaits, pas un plan.
- Vérifie que les personnes hors de ton entreprise qui doivent savoir reçoivent leurs alertes dans leur propre langue.
La mesure d’un système d’alerte n’est pas la quantité qu’il envoie. C’est de savoir si, à trois heures du matin, tu y crois encore.
Ce que nous ne pouvons pas te dire
- Nous ne pouvons pas garantir qu'un courriel arrive dans une boîte de réception : une fois le message parti de chez nous, c'est le système de messagerie destinataire qui décide s'il est remis, classé ou filtré, et personne ne peut promettre le contraire.
- Nous n'envoyons pas de SMS et nous ne nous branchons pas sur une plateforme d'astreinte séparée : les canaux sont le courriel, la messagerie, les webhooks signés et l'appel téléphonique, et la liste s'arrête là.
- Nous ne pouvons pas joindre un téléphone éteint ou hors couverture : nous pouvons te dire que nous avons essayé, quand, et ce que la ligne a répondu, ce qui est au moins un fait sur lequel agir.
- Nous ne pouvons pas décider à ta place quelle panne mérite de réveiller quelqu'un. Nous pouvons faire en sorte qu'une fois ta décision prise, le message arrive vraiment.
Les questions qu'on pose vraiment
Pourquoi les alertes de panne finissent-elles dans les indésirables ?
Parce qu'elles ressemblent exactement à ce que les filtres anti-spam sont faits pour attraper : générées par une machine, répétitives, envoyées à des heures étranges, souvent avec un lien. Le filtre n'a pas tort de se méfier ; il rend simplement un jugement que tu ne vois jamais. C'est pour cela qu'une alerte qui compte ne devrait jamais dépendre du seul courriel.
Quelle est la différence entre un canal et un acheminement ?
Le canal, c'est la manière dont le message voyage — courriel, discussion, webhook, téléphone. L'acheminement, c'est qui le reçoit. La plupart des échecs d'alerte sont des échecs d'acheminement : tout partait vers une seule adresse, et cette adresse appartenait à quelqu'un qui était parti, ou en vacances, ou qui avait cessé de lire. Des groupes de surveillances doivent avoir leurs propres destinataires, et chaque contact sa propre langue.
Nous recevons trop d'alertes et plus personne ne les lit. Par où commencer ?
En enlevant, pas en ajoutant. Exige qu'une panne se répète avant d'être annoncée. Regroupe ce qui tombe ensemble — un serveur qui tombe doit faire un message, pas neuf. Fais taire ce que tu connais déjà, et fais tout taire pendant une mise en production. Puis regarde ce qui reste : si c'est encore trop, ce sont les seuils qui sont mauvais, pas les gens.
Un appel téléphonique, ce n'est pas excessif ?
Pour la plupart des choses, si. Pour deux ou trois services, c'est le seul canal qui marche, parce qu'il ne dépend pas de quelqu'un qui regarde un écran. Cela vaut la peine de le régler correctement : un appel seulement si le service est encore à terre après quelques minutes, jamais pendant les heures de silence que tu as déclarées, et un rappel si la ligne était occupée ou sans réponse.
Comment savoir qu'une alerte a réellement été délivrée ?
Pour un appel téléphonique, précisément : chaque tentative est enregistrée avec son résultat et le nombre de secondes du message réellement écoutées, si bien que tu distingues un appel décroché d'un appel qui a sonné dans le vide. Pour le courriel, cette certitude n'existe pas, et quiconque te dit le contraire a quelque chose à te vendre.