Le terme AIOps (Artificial Intelligence for IT Operations) a été créé par Gartner en 2016 pour décrire des plateformes qui combinent le big data et l'apprentissage automatique dans le but d'automatiser et d'améliorer les opérations de technologie de l'information. Dans des environnements où un seul cluster Kubernetes peut émettre des millions d'événements de télémétrie par jour, la corrélation manuelle des alertes n'est plus viable depuis longtemps. AIOps ne remplace pas l'équipe d'exploitation : il 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, journaux et traces distribuées, les trois signaux de l'observabilité moderne — contiennent des schémas qu'un modèle statistique apprend mieux qu'un seuil fixe écrit par un être humain. Un disque qui atteint 90 % d'occupation avec une tendance linéaire prévisible ne devrait pas générer la même alerte à trois heures du matin qu'un pic de latence anormal au 99e percentile d'un microservice critique. AIOps établit cette distinction.
Il convient de situer 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. 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 capables d'extraire 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. Lorsque l'une des trois fait défaut, la plateforme reste une promesse à moitié tenue : elle détecte sans agir, ou bien elle agit sur des données peu fiables.
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 nu. Une architecture de microservices sur des conteneurs éphémères, avec mise à l'échelle automatique 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 rédigées par un humain ne parvient à rester à jour. 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 est au cœur de toute plateforme AIOps. Le problème avec les seuils statiques classiques — « alerter si le CPU dépasse 80 % » — est qu'ils ignorent la saisonnalité. Un serveur de facturation qui atteint 85 % de CPU chaque premier du mois à 09h00 n'est pas en incident : il traite la charge attendue. Un seuil fixe génère là un faux positif récurrent qui érode la confiance de l'équipe dans les alertes, phénomène connu sous le nom d'alert fatigue.
Les techniques habituelles pour surmonter ce problème sont multiples. Les modèles de séries temporelles tels que SARIMA et Prophet capturent la tendance et la saisonnalité, prédisant la plage attendue pour chaque instant et signalant comme anormal ce qui en sort. Pour les données multivariées — lorsqu'il faut corréler simultanément le CPU, la mémoire, la latence et le taux d'erreur — on utilise des algorithmes non supervisés comme l'Isolation Forest, qui isole les observations rares en partitionnant l'espace des caractéristiques, ou encore des autoencodeurs, des réseaux de neurones qui apprennent à reconstruire le comportement normal et se déclenchent lorsque 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 soumis à l'usure. Un disque mécanique expose via S.M.A.R.T. des attributs tels que le compteur de secteurs réalloué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 suffisamment d'avance pour planifier le remplacement lors d'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 avance utile : une prédiction correcte qui arrive cinq minutes avant la défaillance n'apporte aucune valeur opérationnelle ; la même prédiction avec soixante-douze heures d'avance permet d'agir sans urgence.
Corrélation d'événements et réduction du bruit
Lors d'un incident réel, une unique défaillance racine génère une cascade d'alertes : un nœud tombe, ses pods sont replanifiés, les vérifications de santé échouent, les équilibreurs de charge marquent des points de terminaison comme hors service et les alertes de latence se multiplient en aval. La corrélation d'événements regroupe tous ces signaux en un seul incident et, grâce à l'analyse du graphe de dépendances entre services, propose la cause racine probable. Des plateformes telles que Dynatrace avec son moteur Davis, Moogsoft ou Elastic avec ses capacités de machine learning implémentent cette logique de regroupement temporel et topologique, réduisant des dizaines d'alertes à un incident actionnable.
La corrélation repose sur deux dimensions. La dimension temporelle regroupe les événements qui surviennent dans une fenêtre proche, sous l'hypothèse raisonnable qu'ils partagent une même cause. 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 simultanément, 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 la direction des dépendances est ce qui réduit le temps de diagnostic, car l'équipe cesse de poursuivre des symptômes et va directement à la source.
Remédiation automatisée et rôle de l'être humain
Le dernier maillon d'AIOps est la réponse. Une fois l'incident détecté et diagnostiqué, la plateforme peut se limiter à notifier ou peut exécuter une action corrective. Les remédiations habituelles — redémarrer un service bloqué, effectuer une mise à l'échelle horizontale face à un pic de charge soutenu, purger et remplacer un nœud défectueux, renouveler 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 réduit et l'équipe est libérée des tâches mécaniques répétitives.
Cependant, l'automatisation des réponses doit être introduite avec prudence et de manière progressive. Un modèle sûr est celui des trois phases. Dans la première, la plateforme observe uniquement et recommande : « dégradation détectée dans le service X, action suggérée : redémarrage ». Dans la deuxième, elle exécute avec approbation humaine via un clic. Dans la troisième, et uniquement pour les incidents bien caractérisés avec un large historique de succès, elle agit de manière autonome en laissant un enregistrement auditable. Sauter cette progression — automatiser d'emblée sur des détections non encore validées — est la recette pour qu'un faux positif provoque un redémarrage en cascade inutile pendant le pic de trafic. La supervision humaine sur les actions à fort impact reste un principe de conception, non une concession.
Étapes d'implémentation
Une adoption ordonnée d'AIOps suit une séquence raisonnée :
- Consolider l'observabilité en premier. Sans métriques, journaux et traces centralisés 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 piles comme Prometheus avec Grafana ou l'écosystème Elastic constituent le point de départ habituel.
- Établir une ligne de base. Collecter plusieurs semaines de télémétrie pour que les modèles apprennent les cycles quotidiens et hebdomadaires réels.
- Commencer par un cas d'usage délimité. La détection d'anomalies sur une métrique métier critique donne généralement le meilleur retour initial sans risque de saturer l'équipe.
- Maintenir 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.
- Fermer la boucle avec des runbooks. Connecter la détection à l'automatisation de la réponse (redémarrage d'un service, mise à l'échelle horizontale, renouvellement d'un certificat) uniquement lorsque la cause racine est bien caractérisée.
Erreurs fréquentes
L'erreur la plus fréquente est de passer directement à la remédiation automatique sans avoir validé la fiabilité de la détection : automatiser sur des faux positifs amplifie les dégâts au lieu de les réduire. La deuxième erreur est d'alimenter les modèles avec des données sales — séries avec des lacunes, horloges désynchronisées entre nœuds, étiquettes incohérentes — et d'attendre des prédictions propres. La troisième est de traiter AIOps comme un produit qui s'installe et fonctionne seul : les modèles dérivent à mesure que l'architecture évolue 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
| Approche | Données nécessaires | Point fort | Limitation |
|---|---|---|---|
| Seuil statique | Aucune (règle manuelle) | Simple et transparent | Ignore la saisonnalité, génère du bruit |
| Prophet / SARIMA | Série temporelle univariée | Capture tendance et cycles | Faible avec de nombreuses variables simultanées |
| Isolation Forest | Données multivariées non étiquetées | Détecte les combinaisons rares | Moins interprétable |
| Autoencodeur | Grand volume de données normales | Modélise les comportements complexes | Coût de calcul et d'entraînement élevé |
Foire aux questions
AIOps remplace-t-il les ingénieurs d'exploitation ou les SRE ? Non. Il élimine le travail répétitif de triage 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 sont nécessaires pour démarrer ? Au minimum, suffisamment pour couvrir les cycles pertinents de l'activité. Pour capturer la saisonnalité hebdomadaire, plusieurs semaines sont souhaitables ; pour des schémas mensuels, plusieurs mois.
AIOps est-il utile pour une infrastructure de petite taille ? La valeur augmente 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 ; AIOps brille lorsque le nombre de signaux dépasse la capacité de corrélation manuelle.
Comment mesure-t-on le retour sur investissement 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 prévenus grâce à la prédiction.
Chez Summum Sistemas, nous abordons 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 peut exécuter avec confiance. Un programme AIOps bien gouverné se remarque à deux choses mesurables : les alertes qui parviennent à l'équipe sont celles qui comptent vraiment, et un nombre croissant d'incidents se résolvent — ou s'évitent — avant que l'utilisateur final ne perçoive la moindre dégradation. C'est la frontière réelle entre opérer en réagissant et opérer en anticipant.