AIOps : l'IA pour des opérations IT avancées

Le terme AIOps (Artificial Intelligence for IT Operations) a été forgé par Gartner en 2016 pour décrire des plateformes combinant big data et apprentissage automatique dans le but d'automatiser et d'améliorer les opérations informatiques. Dans des environnements où un unique cluster Kubernetes peut émettre des millions d'événements de télémétrie par jour, la corrélation manuelle des alertes a cessé d'être viable depuis longtemps. L'AIOps ne remplace pas l'équipe d'exploitation : elle amplifie sa capacité à détecter, diagnostiquer et résoudre les incidents avant qu'ils ne dégradent le service.

La prémisse technique est directe. Les données opérationnelles — métriques, logs et traces distribuées, les trois signaux de l'observabilité moderne — contiennent des motifs qu'un modèle statistique apprend mieux qu'un seuil fixe écrit par une personne. Un disque qui atteint 90 % d'occupation avec une tendance linéaire prévisible ne devrait pas générer la même alerte à 3 heures du matin qu'un pic de latence anormal au 99ᵉ percentile d'un microservice critique. L'AIOps établit cette différence.

Il convient de situer l'AIOps dans un cycle plus large. L'observabilité classique répond à la question « que se passe-t-il ? » en affichant des tableaux de bord et en déclenchant des alertes. L'AIOps va plus loin et répond « qu'est-ce qui est anormal, pourquoi cela se produit-il et que convient-il de faire ? ». Ce saut exige trois capacités enchaînées : l'ingestion et la normalisation de grands volumes de télémétrie hétérogène, des modèles qui extraient le signal du bruit, et un mécanisme d'action qui relie la conclusion à une réponse — notifier la bonne personne ou exécuter une remédiation automatisée. Quand l'une des trois manque, la plateforme reste une promesse à moitié tenue : elle détecte mais n'agit pas, ou elle agit mais sur des données qui ne méritent pas confiance.

Le contexte qui a rendu cette approche indispensable est le changement d'architecture. Un monolithe déployé sur trois serveurs générait un volume de signaux qu'une équipe pouvait surveiller à l'œil. Une architecture de microservices sur des conteneurs éphémères, avec autoscaling et déploiements continus plusieurs fois par jour, multiplie les sources de télémétrie et réduit la durée de vie moyenne de chaque composant à quelques minutes. Dans cet environnement, la topologie change en permanence et aucun ensemble de règles statiques écrit par une personne ne parvient à rester à jour. L'AIOps apprend cette topologie changeante à partir des données elles-mêmes.

Détection d'anomalies : du seuil statique au modèle adaptatif

La détection d'anomalies (anomaly detection) est le cœur de toute plateforme AIOps. Le problème des seuils statiques classiques — « alerte si le CPU dépasse 80 % » — est qu'ils ignorent la saisonnalité. Un serveur de facturation qui atteint 85 % de CPU chaque 1er du mois à 09 h 00 n'est pas en incident : il traite la charge attendue. Un seuil fixe génère alors un faux positif récurrent qui érode la confiance de l'équipe dans les alertes, le phénomène connu sous le nom d'alert fatigue.

Les techniques habituelles pour surmonter cela sont multiples. Les modèles de séries temporelles comme SARIMA et Prophet capturent la tendance et la saisonnalité, en prédisant la plage attendue pour chaque moment et en marquant comme anormal ce qui en sort. Pour les données multivariées — lorsqu'il faut corréler CPU, mémoire, latence et taux d'erreur simultanément — on utilise des algorithmes non supervisés comme Isolation Forest, qui isole les observations rares en partitionnant l'espace des caractéristiques, ou des autoencodeurs, réseaux de neurones qui apprennent à reconstruire le comportement normal et se déclenchent quand l'erreur de reconstruction augmente. Le choix dépend du volume de données et de la disponibilité ou non d'incidents historiques étiquetés.

Maintenance prédictive de l'infrastructure

La maintenance prédictive (predictive maintenance) applique les mêmes principes au matériel et aux composants sujets à l'usure. Un disque mécanique expose via S.M.A.R.T. des attributs comme le nombre de secteurs réaffectés ou les erreurs de lecture non corrigibles ; un modèle entraîné sur l'historique des pannes peut estimer la probabilité de défaillance dans les sept prochains jours avec une antériorité suffisante pour programmer le remplacement dans une fenêtre de maintenance, et non en pleine production.

La même approche s'applique aux certificats TLS proches de l'expiration, à la dérive de capacité des bases de données et à l'épuisement des pools de connexions. La métrique clé ici n'est pas seulement la précision du modèle, mais son antériorité utile : une prédiction correcte qui arrive cinq minutes avant la panne n'apporte pas de valeur opérationnelle ; la même prédiction avec soixante-douze heures de marge permet d'agir sans urgence.

Corrélation d'événements et réduction du bruit

Lors d'un incident réel, une seule panne racine génère une cascade d'alertes : un nœud tombe, ses pods sont replanifiés, les health checks échouent, les répartiteurs de charge marquent des endpoints comme indisponibles et les alertes de latence se multiplient en aval. La corrélation d'événements regroupe tous ces signaux en un incident unique et, grâce à l'analyse du graphe de dépendances entre services, propose la cause racine probable. Des plateformes comme Dynatrace avec son moteur Davis, Moogsoft ou Elastic avec ses capacités de machine learning mettent en œuvre cette logique de regroupement temporel et topologique, réduisant des dizaines d'alertes à un incident actionnable.

La corrélation s'appuie sur deux dimensions. La dimension temporelle regroupe les événements survenant dans une fenêtre proche, sous l'hypothèse raisonnable qu'ils partagent une cause commune. La dimension topologique, plus puissante, utilise la carte des dépendances entre services — construite à partir des traces distribuées — pour distinguer le symptôme de la cause : si le service de paiement dépend de la base de données utilisateurs et que les deux alertent en même temps, le graphe suggère que la racine se trouve en amont, dans la base de données, et que l'alerte de paiement en est dérivée. Cette capacité à ordonner la cascade selon le sens des dépendances est ce qui réduit le temps de diagnostic, car l'équipe cesse de poursuivre les symptômes et va directement à l'origine.

Remédiation automatisée et rôle de l'humain

Le dernier maillon de l'AIOps est la réponse. Une fois l'incident détecté et diagnostiqué, la plateforme peut se limiter à notifier ou exécuter une action corrective. Les remédiations habituelles — redémarrer un service bloqué, monter en charge horizontalement face à un pic de charge soutenu, drainer et remplacer un nœud défectueux, faire pivoter un certificat proche de l'expiration — sont orchestrées via des runbooks automatisés déclenchés par la détection. La valeur est double : le temps de résolution est raccourci et l'équipe est libérée de tâches mécaniques répétées.

Cela dit, l'automatisation de la réponse doit être introduite avec prudence et de façon progressive. Un schéma sûr est celui des trois phases. Dans la première, la plateforme se contente d'observer et de recommander : « dégradation détectée sur le service X, action suggérée : redémarrage ». Dans la deuxième, elle exécute avec une approbation humaine d'un clic. Dans la troisième, et seulement pour des incidents bien caractérisés avec un large historique de succès, elle agit de façon autonome en laissant une trace auditable. Sauter cette progression — automatiser d'emblée sur des détections encore non validées — est la recette pour qu'un faux positif provoque un redémarrage inutile en cascade en plein pic de trafic. La supervision humaine sur les actions à plus fort impact reste un principe de conception, pas une concession.

Étapes de mise en œuvre

Une adoption ordonnée de l'AIOps suit une séquence raisonnable :

1. Consolider d'abord l'observabilité. Sans métriques, logs et traces centralisés et avec un étiquetage cohérent (service, environnement, version), il n'y a pas de matière première pour entraîner quoi que ce soit. Des stacks comme Prometheus avec Grafana ou l'écosystème Elastic sont le point de départ habituel.
2. Établir une ligne de base. Recueillir plusieurs semaines de télémétrie pour que les modèles apprennent les cycles quotidiens et hebdomadaires réels.
3. Commencer par un cas d'usage circonscrit. La détection d'anomalies sur une métrique métier critique offre généralement le meilleur retour initial sans risque de saturer l'équipe.
4. Garder l'humain dans la boucle. Les premières semaines, les actions automatisées doivent être proposées, pas exécutées. La confiance dans la remédiation automatique se gagne avec un historique de succès.
5. Boucler le cycle avec des runbooks. Relier la détection à l'automatisation de la réponse (redémarrage d'un service, montée en charge horizontale, rotation d'un certificat) uniquement quand la cause racine est bien caractérisée.

Erreurs courantes

L'erreur la plus fréquente est de sauter directement à la remédiation automatique sans avoir validé la fiabilité de la détection : automatiser sur des faux positifs amplifie le dommage au lieu de le réduire. La deuxième erreur consiste à alimenter les modèles avec des données sales — séries avec des trous, horloges désynchronisées entre les nœuds, étiquettes incohérentes — et à espérer des prédictions propres. La troisième est de traiter l'AIOps comme un produit qui s'installe et fonctionne tout seul : les modèles dérivent à mesure que l'architecture change et nécessitent un réentraînement périodique. Un bon cadre de référence pour structurer la gouvernance de ces systèmes est la norme ISO/IEC 23053, qui décrit le cadre des systèmes utilisant l'apprentissage automatique.

Comparatif des approches de détection

Questions fréquentes

L'AIOps remplace-t-elle les ingénieurs d'exploitation ou SRE ? Non. Elle élimine le travail répétitif de tri des alertes et laisse à l'équipe le diagnostic des problèmes complexes et l'amélioration du système. La fiabilité reste une responsabilité humaine.

Combien de données historiques faut-il pour commencer ? Au minimum, suffisamment pour couvrir les cycles pertinents de l'activité. Pour capter la saisonnalité hebdomadaire, il convient de disposer de plusieurs semaines ; pour des motifs mensuels, de plusieurs mois.

L'AIOps est-elle utile dans une petite infrastructure ? La valeur croît avec la complexité et le volume de télémétrie. Dans les petits environnements, une bonne observabilité avec des alertes bien conçues peut suffire ; l'AIOps brille quand le nombre de signaux dépasse la capacité de corrélation manuelle.

Comment mesure-t-on le retour d'une plateforme AIOps ? Avec des métriques opérationnelles concrètes : réduction du temps moyen de détection (MTTD) et de résolution (MTTR), pourcentage d'alertes actionnables par rapport au bruit, et incidents évités grâce à la prédiction.

Chez Summum Sistemas, nous abordons l'AIOps comme une couche qui se construit sur une base d'observabilité solide, jamais l'inverse. L'objectif n'est pas d'accumuler des modèles sophistiqués, mais de transformer l'avalanche de télémétrie d'une infrastructure moderne en une poignée de décisions opérationnelles que l'équipe puisse exécuter en toute confiance. Un programme AIOps bien gouverné se remarque à deux éléments mesurables : les alertes qui parviennent à l'équipe sont celles qui comptent vraiment, et un nombre croissant d'incidents est résolu — ou évité — avant que l'utilisateur final ne perçoive la moindre dégradation. C'est la véritable frontière entre opérer en réagissant et opérer en anticipant.