AIOps : moins d'alertes, et les bonnes

Pourquoi ajouter un outil de supervision ne règle rien

Parce que le volume d'alertes n'est pas un problème d'outillage mais de conception. Un outil supplémentaire produit des alertes supplémentaires, sur les mêmes événements, vus sous un autre angle. Les équipes finissent par filtrer mentalement, et les incidents continuent d'être signalés par les utilisateurs avant de l'être par la supervision.

Ce mécanisme est connu et documenté : au-delà d'un certain volume, une alerte cesse d'être un signal pour devenir du bruit de fond. Le seuil est atteint bien plus tôt qu'on ne l'imagine.

Le travail consiste donc à réduire, pas à ajouter. Corréler les événements qui décrivent la même cause, supprimer ceux qui ne déclenchent aucune action, et faire remonter ce qui a une conséquence pour un service rendu.

Le test est simple et impitoyable : si une alerte ne déclenche jamais d'action, elle ne doit pas exister.

Comment améliore-t-on le rapport signal sur bruit ?

Par la corrélation, l'apprentissage des seuils et le changement d'unité d'observation. On regroupe les événements qui décrivent un même incident, on remplace les seuils fixés à la main par des seuils appris sur le comportement réel, et on supervise des services rendus plutôt que des équipements.

• La corrélation. Un lien qui tombe produit des dizaines d'événements sur autant d'équipements. Ils décrivent un seul incident et doivent remonter comme tel.
• Les seuils appris. Un seuil fixé à 80 % d'utilisation est arbitraire : sur certains liens c'est normal, sur d'autres c'est déjà une anomalie. Un seuil appris sur plusieurs semaines tient compte des cycles d'activité.
• La supervision par service. « Le lien vers le site B est saturé » n'appelle aucune décision de la part d'une direction. « L'application de facturation est inutilisable depuis le site B » en appelle une.
• La suppression. L'étape la moins pratiquée et la plus rentable. Toute alerte qui n'a déclenché aucune action depuis des mois se supprime, ou se transforme en indicateur.

Qu'est-ce que l'automatisation ne doit pas décider seule ?

Tout ce qui n'a pas été validé à l'avance avec vous. Une remédiation automatique s'exerce dans un périmètre écrit (quelles actions, sur quels équipements, dans quelles conditions)et chaque exécution est journalisée avec son déclencheur, sa règle et son résultat. Toute action hors périmètre exige une validation humaine.

Cette contrainte n'est pas un excès de prudence : c'est une exigence d'auditabilité. Dans les secteurs que nous servons, il faut pouvoir expliquer après coup pourquoi une action a eu lieu, et démontrer qu'elle relevait d'un cadre décidé.

Elle protège aussi de l'effet le plus coûteux d'une automatisation mal bornée : l'action corrective qui aggrave l'incident. Redémarrer un service, isoler un équipement ou bloquer un flux sont des gestes utiles, et destructeurs s'ils s'appliquent au mauvais moment.

Nous commençons donc systématiquement par les remédiations réversibles et à faible portée, puis nous élargissons à mesure que la confiance dans le dispositif se construit sur des faits.

Quelles données alimentent ces analyses ?

Des données techniques d'infrastructure : télémétrie, journaux d'équipements, flux réseau, états de configuration. Aucune donnée personnelle n'y entre sans encadrement contractuel explicite et sans évaluation préalable des facteurs relatifs à la vie privée.

La distinction compte, parce que les journaux d'une infrastructure contiennent parfois des identifiants d'utilisateurs, des adresses ou des noms de fichiers. Traiter ces contenus comme de simples données techniques serait une erreur de qualification.

Nous établissons donc, avant tout déploiement, ce qui est collecté, pour quelle finalité, et pendant combien de temps. C'est aussi ce qui permet de répondre à un auditeur sans avoir à reconstituer l'information.

La question de l'endroit où ces traitements s'exécutent se pose dans les mêmes termes, et c'est l'objet de notre approche d'IA souveraine.

Questions fréquentes