SLO et alertes : mesurer la fiabilité d'un service IA

Un service IA se mesure mal avec les outils qu’on utilise pour un service classique. Le temps de réponse d’un appel d’API est une chose, mais un agent qui enchaîne des dizaines d’appels de modèle a une latence qui varie fortement d’une requête à l’autre, et une réponse peut être rapide tout en étant fausse. Mesurer la fiabilité d’un service IA demande des indicateurs adaptés, et surtout une décision sur ce que l’on considère comme acceptable.

Le piège le plus courant est de mesurer ce qui est facile à mesurer : la disponibilité du serveur, le taux d’erreur HTTP, le temps de réponse moyen. Ces chiffres rassurent, mais ils ne disent rien de ce qui fait réellement la qualité d’un service IA : la pertinence des réponses, le coût par requête, la dérive du modèle. Un service peut être parfaitement disponible et produire des réponses inutilisables.

Cet article décrit comment définir des objectifs de fiabilité pour un service IA, quels indicateurs suivre, et comment alerter sans se noyer dans le bruit. L’objectif est de vous donner un cadre pour savoir, à tout moment, si votre service tient ses promesses. La partie instrumentation (quoi collecter, avec quels outils) est traitée dans l’article sur l’observabilité LLM ; ici, on parle de ce qu’on décide de cette mesure.

SLO, SLI : définir ce que l’on mesure

Un SLO, pour objectif de niveau de service, est un engagement chiffré sur un indicateur : par exemple, 99 % des réponses sous deux secondes, ou 98 % des extractions correctes. Un SLI, pour indicateur de niveau de service, est la mesure qui permet de vérifier cet engagement. Le SLO dit où l’on veut être, le SLI dit où l’on est.

La difficulté avec les services IA est de choisir des SLI qui reflètent réellement l’expérience. La latence d’un agent est une distribution large, pas une moyenne : il faut la mesurer par percentiles, en s’intéressant au 95e ou au 99e percentile, là où les utilisateurs perçoivent la lenteur. La moyenne masque les queues de distribution, qui sont précisément ce qui fait fuir les utilisateurs.

Le choix des SLI est donc la première décision, et elle engage tout le reste. Un SLO posé sur un mauvais indicateur donne une fausse assurance. Il vaut mieux mesurer moins de choses, mais des choses qui comptent pour l’utilisateur final, que de multiplier les tableaux de bord qui ne disent rien.

La latence et la qualité, deux axes distincts

Un service IA se mesure sur au moins deux axes qui n’ont rien à voir entre eux. La latence, d’une part : combien de temps pour produire une réponse. La qualité, d’autre part : la réponse est-elle correcte, pertinente, sans hallucination. Un service peut être rapide et faux, lent et juste, et toutes les combinaisons intermédiaires.

La latence se mesure automatiquement, en instrumentant chaque étape de la chaîne : temps d’appel au modèle, temps de recherche, temps de génération. OpenTelemetry fournit ce traçage de façon standard, et un outil d’observabilité LLM comme Langfuse ou LangSmith le présente étape par étape pour chaque requête de l’agent. On peut la suivre en continu, par percentile, et alerter quand elle dépasse l’objectif. C’est le versant le plus proche du monitoring classique.

La qualité est plus difficile à mesurer en continu, parce qu’elle demande de juger des réponses. La solution est de constituer un échantillon de requêtes de référence, avec des réponses attendues, et de l’évaluer régulièrement, automatiquement ou par relecture humaine. Des bibliothèques comme Ragas ou DeepEval calculent ces scores, et Langfuse permet de les rattacher aux traces de production pour suivre leur évolution. Cette évaluation périodique est le seul moyen de savoir si le service s’améliore ou dérive, et elle doit être pensée dès la conception. Pour construire cet échantillon et choisir les critères, voir les evals expliquées.

Le coût et la consommation comme indicateurs de fiabilité

Un service IA a un indicateur que les services classiques n’ont pas : la consommation de jetons, et donc le coût par requête. Un agent qui se met à boucler, à réessayer trop, ou à produire des réponses plus longues que nécessaire voit son coût exploser sans que la disponibilité bouge. Le coût est ici un signal de santé, pas seulement une question budgétaire.

Il faut donc suivre le nombre de jetons consommés par requête, le nombre d’appels au modèle par tâche, et le coût unitaire. Langfuse et LangSmith calculent ce coût automatiquement pour les modèles courants (GPT, Claude, Gemini, Mistral). Une dérive de ces chiffres signale souvent un problème : un prompt dégradé, un modèle changé, un garde-fou qui ne fonctionne plus. Le coût est un indicateur avancé de défaillance.

Ce suivi a aussi une vertu de pilotage : il permet de comparer le coût de la réponse automatisée à celui d’une réponse humaine, et de décider sur des chiffres si l’automatisation vaut le coup. C’est un usage de la mesure qui dépasse la simple surveillance.

Le budget d’erreur : la bonne façon d’alerter

La méthode la plus saine pour alerter sur un service repose sur le budget d’erreur. Si le SLO promet 99 % de réponses sous deux secondes, on accepte 1 % d’échecs sur une période donnée : c’est le budget d’erreur. On alerte non pas à chaque échec, mais quand le budget est consommé trop vite, c’est-à-dire quand le taux d’échec sur une fenêtre récente projette un dépassement du budget sur la période.

Cette approche évite le bruit des alertes unitaires, qui finissent par être ignorées. Prometheus et Grafana, ou Datadog, savent calculer ce rythme de consommation du budget et déclencher l’alerte vers l’astreinte. On ne réveille personne pour une requête lente isolée. On alerte quand le rythme d’échecs indique que l’objectif de la période ne sera pas tenu, ce qui correspond précisément au moment où il faut agir.

Le budget d’erreur a aussi une vertu de cadence : il force à se poser la question de la fiabilité au rythme de la consommation du budget, et à arbitrer entre fiabiliser et livrer de nouvelles fonctionnalités. C’est un outil de gestion, pas seulement une règle d’alerte. Il sert aussi de critère d’arrêt lors d’un déploiement canary : si la nouvelle version consomme le budget plus vite que l’ancienne, on revient en arrière.

Suivre la dérive du modèle et des données

Un service IA a une particularité que les services classiques n’ont pas : il dépend d’un modèle et de données qui changent. Une mise à jour du modèle, un changement dans la façon dont les utilisateurs formulent leurs questions, un corpus qui grossit : tout cela peut dégrader la qualité sans qu’aucun composant technique ne tombe en panne.

Cette dérive ne se voit pas dans les indicateurs de disponibilité, elle se voit dans l’évaluation périodique de la qualité. Il faut donc la suivre de façon délibérée : comparer la qualité d’une période à la précédente, détecter les baisses, et les corréler aux changements apportés. C’est le seul moyen de ne pas découvrir après coup que le service s’est dégradé.

Concrètement, on conserve l’historique de l’évaluation de qualité, et l’on alerte quand le score baisse au-delà d’un seuil. Cette alerte est le pendant, pour la qualité, de ce que le budget d’erreur fait pour la latence et la disponibilité.

La fiabilité d’un service dépend aussi de sa chaîne de dépendances : npm install et sécurité en 2026 : incidents et réglages.

En pratique : fiabiliser vos services IA

Pour démarrer, pas besoin de tout poser d’un coup. Trois SLO suffisent souvent : un sur la latence au 95e percentile, un sur la qualité mesurée par l’échantillon de référence, un sur le coût par tâche. Avec un budget d’erreur sur chacun et une alerte de dérive sur la qualité, vous savez déjà quand agir, et surtout quand ne pas réveiller quelqu’un.

Sur les agents qu’on met en production, ces indicateurs sont définis avec le métier avant la mise en ligne, puis branchés en même temps que le service. Ils font partie de notre méthode, au même titre que les evals, la CI/CD et les garde-fous : un agent n’est livré que lorsqu’on sait dire, chiffres à l’appui, s’il tient ses objectifs.