Comment votre entreprise découvre-t-elle aujourd’hui qu’un système est en panne ? Pour la plupart des PME, la réponse honnête est : par un humain. Un collaborateur qui ne parvient pas à se connecter, un client qui appelle parce que la boutique en ligne ne charge pas, un comptable dont le rapport refuse de tourner. Le système est peut-être tombé à 02h14. Vous l’apprenez à 09h30. Ces sept heures sont la partie la plus chère de tout l’incident.

La détection d’incidents consiste précisément à refermer cet écart. Non pas empêcher que quelque chose casse un jour, personne n’y arrive, mais rapprocher autant que possible le moment où l’on sait du moment où cela se produit.

Comment fonctionne la détection, sans jargon

Une plateforme de monitoring mesure en continu une longue série de signaux : ce service répond-il encore, à quel point ce disque est-il rempli, combien de temps met cette page web à répondre, quand expire ce certificat. Chaque signal est comparé à ce qui est normal. En cas d’écart, une alerte suit.

Cela semble simple, et la base l’est réellement. Un service qui ne répond plus est connu en moins d’une minute. Un disque qui se remplit s’annonce des jours à l’avance. Un certificat qui expire dans deux semaines ne doit jamais être une surprise. Une bonne partie des incidents « soudains » sont en réalité un train lent, visible depuis des semaines. Personne ne regardait la voie.

Le piège : le bruit

Il existe un moyen infaillible de ruiner un monitoring : le mauvais réglage. Une plateforme qui envoie cent alertes par jour est ignorée au bout d’une semaine, y compris la cent-unième alerte, celle qui compte vraiment. J’ai vu des équipes en environnement enterprise développer collectivement une fatigue d’alerte, et ce schéma est encore plus dangereux dans une PME, où aucune salle de contrôle ne regarde les alertes de toute façon.

Bien régler, c’est faire des choix. Qu’est-ce qui est assez critique pour réveiller quelqu’un la nuit ? Qu’est-ce qui peut attendre le matin ? Qu’est-ce qui est normal pour votre environnement à vous ? Un serveur de sauvegarde dont le trafic réseau grimpe chaque nuit n’est pas un incident. Le même pic à quinze heures, peut-être bien. Ce contexte ne se construit pas en un après-midi, et il fait la différence entre un chien de garde et un chien qui aboie.

Ce que la détection vaut sur papier

Au-delà du gain opérationnel, il y a un second rendement : la preuve. Chaque détection et chaque suivi sont consignés avec horodatage. Quiconque a déjà rempli un questionnaire fournisseur d’un client NIS2 reconnaîtra la question immédiatement : « détectez-vous les incidents, et à quelle vitesse ? » Avec un historique d’alertes, la réponse n’est pas une promesse. C’est un rapport que vous joignez au dossier.

Par où commencer

Ne commencez pas par vouloir tout surveiller. Commencez par la question : quels sont les trois systèmes qui font le plus mal quand ils tombent ? Pour la plupart des PME, c’est l’environnement mail, l’application comptable ou ERP, et le site ou la boutique en ligne. Mettez-y de la détection, réglez-la correctement, puis élargissez une fois que cela tourne.

Via Althona, je mets en place exactement ce type d’environnement avec CheckMK, réglé sur ce qui est normal pour votre entreprise, avec des alertes qui ne partent que quand il le faut. Envie de savoir à quelle vitesse vous remarqueriez une panne aujourd’hui ? Planifiez un entretien sans engagement. La réponse honnête à cette question constitue souvent la moitié du business case à elle seule.