Il est 2 heures du matin. Votre téléphone vibre. Vous vous réveillez en sursaut, le cœur qui s’accélère, et vous vous précipitez sur votre laptop parce que votre monitoring de disponibilité hurle que tout brûle.
Vous vérifiez les serveurs. Vous pingez la base de données. Vous vous traînez à travers les théâtres de réponse aux incidents.
Tout va bien.
L’alerte n’était que du bruit.
Ca arrive deux fois par semaine. Parfois trois. Et si vous faites tourner plusieurs services avec plusieurs moniteurs, vous êtes carrément sur un hamster wheel de privation de sommeil que personne ne mentionne en public mais que tout le monde déplore dans les channels Slack privés à 3 heures du matin.
La fatigue d’alerte, c’est pas juste chiant. C’est le secret inavoué du monitoring, et elle coûte bien plus cher aux équipes que la plupart ne l’imaginent.
Pourquoi votre corps déteste les fausses alarmes plus que vous ne le croyez
Quand une alerte se déclenche, votre système nerveux s’en fout de savoir si c’est réel. Votre corps bascule en mode crise. Le cortisol monte en flèche. La fréquence cardiaque s’accélère. Les pupilles se dilatent. Votre cortex préfrontal — la partie rationnelle — se fait détourner par votre amygdale, qui ne connaît qu’une seule chose : menace détectée.
Imaginez maintenant que ça se reproduise deux fois par semaine pendant un an.
La recherche est sans appel. Les ingénieurs confrontés à des alertes fausses fréquentes perdent en moyenne 45 minutes de sommeil par incident, plus 20 à 30 minutes supplémentaires pour se rendormir. C’est pas 45 minutes une seule fois. C’est 45 minutes multiplié par plus de 100 fausses alertes par an. On parle de semaines de dette de sommeil accumulée.
Mais la perte de sommeil, c’est que le début.
« Après assez de faux positifs, votre équipe commence à ignorer les alertes. Elle coupe les notifications Slack. Elle met PagerDuty en sourdine. Jusqu’à ce que la vraie panne arrive et que personne ne se manifeste. »
C’est l’effet du petit berger qui criait au loup, et c’est bien plus dangereux qu’une seule nuit blanche. Une fois que votre équipe cesse de faire confiance à vos moniteurs, elle arrête d’y répondre. Les vraies pannes passent entre les mailles parce que tout le monde a été conditionné, par la répétition, à traiter chaque alerte comme du bruit.
Ensuite, il y a le coût du changement de contexte. Chaque alerte interrompt le travail profond — cet état de concentration où les ingénieurs construisent vraiment des choses. La recherche montre qu’il faut en moyenne 23 minutes pour retrouver sa concentration complète après une interruption. Trois fausses alertes le matin ? Vous venez de liquider tout votre après-midi de productivité pour rien.
Ajoutez l’épuisement de l’équipe, et vous avez la tempête parfaite. Les ingénieurs commencent à détester leurs outils de monitoring. Certains les désactivent carrément. C’est là que le vrai danger commence.
Le problème architectural qu’on refuse d’admettre
La plupart des moniteurs de disponibilité utilisent la même approche brutale : frapper une URL, vérifier le code de réponse HTTP, déclencher une alerte si quelque chose semble louche.
C’est simple. C’est peu coûteux à exploiter. C’est aussi fondamentalement cassé.
Voici ce que vous mesurez réellement quand vous faites cette vérification depuis une seule région géographique :
Les délais d’expiration de connexion TCP qui n’ont rien à voir avec votre service réel. Votre serveur de monitoring pourrait avoir une route instable vers votre serveur pendant 30 secondes, et soudain vous avez une alerte. Votre site va bien. Le réseau du monitor ne va pas bien.
Les délais d’expiration agressifs qui se déclenchent lors de pics de trafic légitime. Vous réglez un délai d’expiration de 5 secondes sur une API qui répond normalement en 200 ms, le trafic monte en flèche à 10 fois la charge normale, et boom — fausse alerte alors que tout fonctionne réellement.
Les v
