AIOps : le jour où 12 000 alertes se sont enfin tues

J'entre dans la salle de supervision. Les écrans sont magnifiques : des murs de rouge, des compteurs qui défilent, des graphes qui clignotent. Et devant ces écrans : personne. Plus exactement, des gens qui ne les regardent plus. « De toute façon, m'explique un exploitant, on a douze mille alertes par jour. Si on devait toutes les traiter, on ne ferait que ça. » Voilà le paradoxe le plus cruel de la supervision : à force de tout alerter, on n'alerte plus rien.

La fatigue d'alerte, ce mal silencieux

Le mécanisme est implacable. On ajoute une sonde, puis une autre, puis un nouvel outil de monitoring, chacun avec ses seuils, chacun criant dans son coin. Très vite, le volume dépasse la capacité humaine d'attention. Les équipes apprennent — par survie — à ignorer les alertes. Et le jour où la vraie alerte tombe, celle qui annonçait la panne majeure, elle se noie dans le bruit des onze mille neuf cent quatre-vingt-dix-neuf autres. La panne n'est pas arrivée par manque de supervision. Elle est arrivée par excès de supervision mal filtrée.

Trop d'alertes, c'est exactement comme pas d'alerte. Pire : ça donne l'illusion d'être couvert.

L'AIOps n'ajoute pas de l'IA. Il rend du silence.

On présente souvent l'AIOps comme « mettre de l'intelligence artificielle dans les opérations ». C'est une définition de brochure. Sur le terrain, ce que l'AIOps apporte d'abord, c'est le silence utile. Concrètement :

• La corrélation d'événements. Cinq cents alertes qui surgissent en même temps ne sont presque jamais cinq cents problèmes. C'est, le plus souvent, un problème qui se propage. L'AIOps regroupe ces alertes en un seul incident signifiant. Cinq cents lignes deviennent une.
• La déduplication et le filtrage du bruit. Les alertes répétitives, transitoires, sans conséquence sont écartées ou regroupées, au lieu d'inonder la file.
• La détection d'anomalies par apprentissage. Au lieu de seuils statiques (« alerte si CPU > 80 % ») qui hurlent à chaque pic normal, on apprend le comportement habituel de chaque système et on n'alerte que sur l'écart réellement anormal. Fini les fausses alertes du samedi soir de sauvegarde.

La corrélation a besoin de la carte

Voici le point que les démonstrations escamotent, et que vingt ans de terrain m'ont appris à exiger : une corrélation pertinente a besoin de connaître la topologie. Pour comprendre que l'alerte « base de données lente » et l'alerte « application qui rame » et l'alerte « client mécontent » sont le même incident, le moteur doit savoir que ces éléments sont reliés. Cette connaissance, elle vient de la CMDB et de la découverte automatisée. Sans carte des dépendances, l'AIOps corrèle dans le vide ; avec elle, il remonte la chaîne jusqu'à la cause probable. C'est pourquoi je le répète à chaque projet : pas de bon AIOps sans bonne CMDB. Tout est lié, au sens propre.

Du réactif au proactif

Une fois le bruit dompté, l'étape suivante s'ouvre : anticiper. En apprenant les signatures qui précèdent les incidents, l'AIOps peut alerter avant la rupture — une dérive lente, un motif récurrent annonciateur. On passe de « réparer vite » à « éviter la panne ». Et au-delà, on peut déclencher des remédiations automatiques sur les cas connus : le système se soigne lui-même pour les incidents routiniers, et réserve l'attention humaine aux situations vraiment nouvelles.

Garder l'humain dans la boucle

Un avertissement, tout de même, parce que je n'aime pas les boîtes noires : l'AIOps doit expliquer. Une « cause probable » qui tombe du ciel sans justification ne sera jamais adoptée par des exploitants — et ils auront raison de s'en méfier. Le bon AIOps montre pourquoi il a corrélé, sur quelles données il a détecté l'anomalie, quel chemin de dépendances il a remonté. L'objectif n'est pas de remplacer le jugement humain : c'est de lui donner, enfin, de quoi se concentrer sur l'essentiel.

Ce que ça donne avec une bonne plateforme

Rendre le silence à une salle de supervision, c'est exactement ce que je viens chercher avec BMC Helix Operations Management et ses capacités d'AIOps : corrélation d'événements consciente de la topologie, détection d'anomalies par apprentissage, regroupement en incidents signifiants et identification de la cause probable. Et l'atout décisif : tout cela s'appuie sur la même CMDB et la même découverte automatisée que le reste de la plateforme. L'AIOps ne corrèle pas dans le vide — il s'appuie sur la carte réelle de votre SI, et déverse ses conclusions directement dans l'ITSM pour passer de la détection à l'action. Douze mille alertes redeviennent quelques incidents qui comptent. Et les écrans, à nouveau, servent à quelque chose.