Un incident web le week-end n’est pas une panne d’un genre technique à part. C’est souvent la même erreur HTTP, le même certificat ou le même disque plein, avec personne pour lire l’alerte avant lundi. Le surcoût vient de la durée, pas d’un mystère propre au samedi. Le monitoring ne raccourcit cette durée que si le message atteint quelqu’un qui peut agir.
Ce qui se déclenche hors bureau
Plusieurs opérations sont calées le vendredi ou la nuit, précisément parce que l’équipe veut « ne pas gêner ». Elles génèrent les tickets du lundi.
- La mise en production de fin de vendredi. Le contrôle de 18 h est vert, celui de 22 h ne l’est plus, et la personne qui a déployé a fermé la session. Un pas de contrôle court ne sert à rien si le déploiement n’est pas suivi d’un essai assumé avant de partir.
- Le certificat. Les renouvellements automatiques échouent parfois sur un défi HTTP ou un quota. L’expiration tombe un dimanche parce que la date d’émission tombait un dimanche, trois mois ou un an plus tôt.
- Les tâches planifiées. Sauvegarde, import, génération d’images : elles tournent quand le trafic prévu est bas. Un journal qui grossit ou un disque qui se remplit se manifeste alors, par des 500 ou des délais, pas pendant la revue du jeudi.
- Le domaine. Un renouvellement refusé par la banque n’attend pas l’ouverture du bureau. Le site peut être intact et le nom, non.
Aucune de ces causes n’exige de chiffre inventé pour être prise au sérieux. Il suffit de regarder, sur vos propres incidents, quel jour la première alerte est partie et quel jour quelqu’un a répondu.
Qui est prévenu
Écrivez la chaîne avant d’en avoir besoin. Une boîte partagée lue le lundi n’est pas une astreinte. Un e-mail vers une personne absente non plus. Le minimum : deux destinataires, un canal consulté le samedi si le site a des visiteurs ce jour-là, et une règle si le premier ne confirme pas.
Le webhook d’alerte ne résout pas l’absence de personne. Il déplace le message vers un outil que l’équipe a accepté de regarder. Si cet outil est coupé le week-end, vous avez seulement changé de boîte aux lettres.
Distinguez l’alerte d’un échec confirmé et le bruit d’un essai isolé. Les seuils existent pour ne pas crier à chaque accroc. Le week-end, un seuil trop sensible habitue à ignorer le téléphone. Un seuil trop lâche laisse passer le samedi entier. Testez la chaîne un jeudi : déclenchez un échec volontaire sur une URL de test, et vérifiez qui reçoit quoi. Une URL de production n’est pas le bon cobaye.
Le lundi matin
Le voyant vert à 9 h ne clot pas le week-end. Ouvrez l’historique de samedi 0 h à lundi 8 h sur l’accueil, le contact ou le paiement. Notez les incidents, même clos : début, fin, code. C’est cette liste qui dit si le formulaire a été mort pendant que les messages clients partaient ailleurs.
Si l’historique est vide parce que le contrôle ne tourne pas le week-end, vous avez choisi de ne pas savoir. Pour une vitrine, un pas de quelques heures couvre quand même samedi et dimanche. Couper la surveillance du vendredi soir au lundi matin laisse exactement le trou où les tâches planifiées et les certificats se manifestent.
SiteGarde peut envoyer l’alerte pendant ces deux jours. La décision qui compte est en amont : qui la lit, et quel déploiement du vendredi est interdit sans contrôle immédiatement après. La synthèse du mois doit citer les incidents du week-end avec leur durée, pas les fondre dans un taux qui a l’air calme.