IA prédictive et observabilité : anticiper les incidents plutôt que les subir

En bref

• L'IA prédictive en supervision recouvre cinq usages : prévoir une saturation, détecter une anomalie, corréler les alertes, anticiper la violation d'un engagement de service et estimer le risque d'un changement. Ils n'ont pas la même maturité.
• Les deux usages les plus fiables sont aussi les plus simples : la prévision de saturation (disque, mémoire, licences, quotas) et l'alerte sur la consommation du budget d'erreurs. Des outils courants comme Prometheus et Zabbix les proposent nativement.
• La prédiction dépend des données : métriques, journaux et traces cohérents, une cartographie des dépendances à jour, et un historique qui couvre plusieurs cycles d'activité.
• Prédire ne suffit pas : une alerte prédictive doit déboucher sur une action, un ticket ou une procédure. Le lien avec l'outil de gestion des services (ITSM) est indispensable.
• Mesurer avant d'élargir : nombre d'alertes utiles, délai de détection, part des incidents repérés avant les utilisateurs.

Supervision, observabilité, AIOps : de quoi parle-t-on ?

Terme	Question à laquelle il répond	Exemples
Supervision	Le système fonctionne-t-il, selon des seuils connus ?	disponibilité d'un serveur, taux d'occupation d'un disque, alerte au-delà de 90 %
Observabilité	Pourquoi le système se comporte-t-il ainsi, y compris face à un problème imprévu ?	traces d'une requête entre services, journaux corrélés, métriques détaillées
AIOps	Que peut-on automatiser dans l'exploitation grâce à l'analyse des données ?	réduction du bruit, corrélation, détection d'anomalies, prévision
IA prédictive	Que va-t-il probablement se passer, et quand ?	date de saturation d'un disque, dérive d'un temps de réponse, violation probable d'un engagement de service

L'observabilité fournit la matière, l'IA prédictive l'exploite. Sans données fiables et reliées entre elles, un modèle prédictif ne produit que des alertes de plus.

Les cinq usages de l'IA prédictive, du plus fiable au plus fragile

Usage	Question	Méthode typique	Données nécessaires	Maturité
1. Prévision de saturation	Quand ce disque, ce quota ou ce pool sera-t-il plein ?	régression linéaire ou tendance lissée	une métrique avec un historique suffisant	élevée
2. Consommation du budget d'erreurs	À ce rythme, l'engagement de service sera-t-il tenu ?	calcul du rythme de consommation sur plusieurs fenêtres	un indicateur de service (SLI) et un objectif (SLO)	élevée
3. Détection d'anomalies	Ce comportement est-il inhabituel pour ce jour et cette heure ?	référence saisonnière, apprentissage statistique	plusieurs semaines ou mois d'historique	moyenne, sensible aux faux positifs
4. Corrélation et réduction du bruit	Ces 200 alertes sont-elles un seul incident ?	regroupement temporel et topologique	cartographie des dépendances (CMDB)	moyenne, dépend de la qualité de la CMDB
5. Risque de changement et cause probable	Ce déploiement risque-t-il de provoquer un incident ? Quelle en est la cause ?	apprentissage sur l'historique des changements et des incidents	historique ITSM structuré	encore fragile

L'ordre de déploiement suit l'ordre du tableau : commencer par ce qui est simple, explicable et vérifiable.

Ce que les outils courants savent déjà faire

Il n'est pas nécessaire d'acheter une plateforme dédiée pour commencer à prédire.

Prometheus propose la fonction predict_linear(), qui prévoit la valeur d'une série dans un nombre de secondes donné, par régression linéaire simple. Exemple d'alerte sur un disque qui sera plein dans moins de quatre heures, d'après la tendance des six dernières heures :

predict_linear(node_filesystem_avail_bytes[6h], 4 * 3600) < 0

Zabbix propose deux fonctions prédictives, forecast et timeleft : la première indique la valeur attendue à une échéance donnée, la seconde le temps restant avant d'atteindre un seuil. Plusieurs modèles d'ajustement sont disponibles (linéaire par défaut, polynomial, exponentiel, logarithmique, puissance). La documentation de Zabbix recommande d'utiliser ces fonctions en complément des déclencheurs classiques, pas à leur place.

Les plateformes d'observabilité du marché (Datadog, Dynatrace, Splunk, Elastic, ServiceNow, entre autres) ajoutent la détection d'anomalies saisonnières, la corrélation automatique et des assistants d'analyse. Elles apportent un gain réel sur les usages 3 à 5, à condition de leur fournir des données propres et une topologie à jour.

Le cas le plus rentable : alerter sur le budget d'erreurs

Plutôt que d'alerter sur chaque seuil technique, les pratiques d'ingénierie de la fiabilité (SRE) alertent sur la vitesse à laquelle un service consomme son « budget d'erreurs ». Pour un objectif de 99,9 % de disponibilité sur 30 jours, le budget est de 0,1 % d'erreurs ; consommer ce budget à un rythme de 1 l'épuise exactement en fin de période.

Le guide SRE de Google propose comme point de départ, pour un objectif de 99,9 % :

Niveau	Fenêtre longue	Fenêtre courte	Rythme de consommation	Part du budget consommée
Astreinte immédiate	1 heure	5 minutes	14,4	2 %
Astreinte immédiate	6 heures	30 minutes	6	5 %
Ticket	3 jours	6 heures	1	10 %

L'alerte se déclenche quand les deux fenêtres dépassent le seuil en même temps. C'est une prédiction au sens propre : elle annonce qu'à ce rythme, l'engagement de service ne sera pas tenu, bien avant qu'il soit violé.

Les prérequis, souvent sous-estimés

1. Des données standardisées : métriques, journaux et traces collectés de manière homogène. OpenTelemetry, projet diplômé de la Cloud Native Computing Foundation, est devenu la norme ouverte pour les traces, les métriques et les journaux ; les profils sont en phase alpha publique.
2. Une cartographie des dépendances : sans savoir quel serveur porte quelle application et quel service métier, aucune corrélation n'est fiable. La base de configuration (CMDB) de l'outil ITSM doit être à jour.
3. Un historique suffisant : une détection d'anomalies saisonnière a besoin de plusieurs cycles (semaines, fins de mois, périodes de forte activité) pour apprendre ce qui est normal.
4. Des engagements de service définis : on ne peut pas prédire la violation d'un objectif qui n'existe pas. Commencer par trois à cinq services critiques.
5. Un circuit de traitement : chaque alerte prédictive doit avoir un destinataire, une procédure et, le plus souvent, un ticket.

Relier la prédiction au centre de services

Une prédiction qui reste dans l'outil de supervision ne sert à rien. Le circuit cible :

Étape	Outil	Ce qui se passe
Détection	supervision et observabilité	la prévision ou l'anomalie franchit un seuil
Qualification	règles de corrélation	regroupement des alertes liées, identification du service touché via la CMDB
Création	outil ITSM (par exemple GLPI)	ticket d'incident ou de demande, avec la priorité du service et la procédure associée
Traitement	équipe d'exploitation, assistant IA	application de la procédure, éventuellement suggérée par un assistant connecté à la base de connaissances
Apprentissage	gestion des problèmes	analyse des incidents répétés, ajustement des seuils et des modèles

C'est sur cette chaîne que l'IA générative apporte aussi un gain : un assistant qui retrouve la bonne procédure dans la base de connaissances, comme le décrit notre article sur le RAG.

La méthode en cinq étapes

1. Choisir trois à cinq services critiques et définir pour chacun un indicateur de service et un objectif.
2. Faire l'inventaire des alertes existantes sur ces services : combien par mois, combien ont donné lieu à une action. Supprimer ou regrouper les alertes qui n'en déclenchent jamais.
3. Déployer les deux usages fiables : prévision de saturation sur les ressources finies (disques, licences, quotas, certificats) et alerte sur la consommation du budget d'erreurs.
4. Brancher le circuit ITSM : création automatique de tickets avec la bonne priorité, procédure rattachée, retour d'expérience après chaque incident.
5. Évaluer, puis élargir : après trois mois de mesures, introduire la détection d'anomalies et la corrélation sur les services où les données sont propres.

Les indicateurs à suivre

Indicateur	Ce qu'il mesure
Part des alertes suivies d'une action	la pertinence des alertes, et donc le bruit
Délai moyen de détection	le temps entre le début d'un incident et son repérage
Délai moyen de rétablissement	le temps entre le repérage et le retour à la normale
Part des incidents détectés avant les utilisateurs	l'efficacité réelle de la supervision
Taux de prédictions confirmées	la fiabilité des modèles prédictifs
Budget d'erreurs restant par service	le respect des engagements de service

Le premier indicateur est le plus révélateur : une supervision qui génère beaucoup d'alertes sans action fatigue les équipes, qui finissent par ignorer aussi les alertes importantes.

Les pièges à éviter

• Ajouter de l'IA sur un bruit existant : un modèle entraîné sur des milliers d'alertes inutiles apprend surtout le bruit.
• Faire confiance à une boîte noire : une prévision doit être explicable (quelle métrique, quelle tendance, quelle échéance) pour que l'équipe agisse.
• Automatiser la remédiation trop tôt : redémarrer un service ou agrandir un volume automatiquement suppose des garde-fous, une traçabilité et une validation pour les actions irréversibles.
• Oublier la dérive : un comportement normal change après une migration, une nouvelle version ou une croissance d'activité ; les références doivent être réévaluées.
• Sous-estimer le coût des données : collecter tous les journaux et toutes les traces coûte cher en stockage et en licences. Définir ce qui est conservé, combien de temps, et à quel niveau de détail.

Exemple d'application (fictif)

Exemple fictif, à visée illustrative. Une direction informatique reçoit environ 3 000 alertes par mois sur son portail client et son système de facturation, dont la plupart ne donnent lieu à aucune action.

Étape	Action	Résultat attendu
Mois 1	objectifs de service définis pour les deux applications, inventaire des alertes	liste des alertes à supprimer, regrouper ou conserver
Mois 2	prévision de saturation sur disques, certificats et licences ; alerte sur le budget d'erreurs	alertes moins nombreuses, chacune associée à une action
Mois 3	tickets créés automatiquement dans GLPI avec la priorité du service et la procédure	traitement tracé, retour d'expérience structuré
Mois 4 et suivants	détection d'anomalies sur les temps de réponse en fin de mois	élargissement uniquement si le taux de prédictions confirmées est jugé suffisant

Questions fréquentes

L'IA prédictive peut-elle éviter toutes les pannes ?
Non. Elle anticipe les incidents qui s'annoncent par une tendance ou un comportement inhabituel. Une panne matérielle soudaine, une erreur de configuration ou une attaque peuvent survenir sans signe préalable.

Faut-il une plateforme AIOps pour commencer ?
Non. Les prévisions de saturation et les alertes sur le budget d'erreurs sont disponibles dans des outils courants comme Prometheus ou Zabbix. Une plateforme dédiée devient utile pour la corrélation et la détection d'anomalies à grande échelle.

Combien d'historique faut-il ?
Pour une tendance simple, quelques heures à quelques jours suffisent. Pour une détection d'anomalies saisonnière, il faut couvrir plusieurs cycles d'activité, donc plusieurs semaines à plusieurs mois.

Quelle différence entre supervision et observabilité ?
La supervision vérifie des états connus à l'aide de seuils. L'observabilité permet de comprendre un comportement imprévu en croisant métriques, journaux et traces.

L'IA peut-elle corriger les incidents seule ?
Pour des actions simples, réversibles et bien encadrées, oui. Pour le reste, elle prépare le diagnostic et propose une procédure ; la décision reste humaine.

Par où commencer

Choisissez trois services critiques, définissez leurs objectifs et comptez les alertes qui n'ont jamais déclenché d'action : c'est le point de départ de toute supervision prédictive. Les équipes Novagios accompagnent ces projets : services managés pour la supervision et l'exploitation au quotidien, IT Service Management pour relier les alertes au centre de services, cloud et infrastructures, data et intelligence artificielle pour les modèles, et NovAssist pour un assistant connecté à vos procédures et à GLPI. Pour un premier diagnostic, contactez nos experts.

---

Sources

• Prometheus, documentation des fonctions de requête (predict_linear, double_exponential_smoothing).
• Zabbix, documentation « Predictive trigger functions » (forecast, timeleft).
• Google, The Site Reliability Workbook, chapitre « Alerting on SLOs ».
• OpenTelemetry, documentation « Signals » et page de statut du projet.