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.
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. 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. 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.
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. 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. 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.
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é.
L’accompagnement Agenticiel pour fiabiliser vos services IA
Mettre en place ces mesures demande de l’instrumentation et de la méthode, que peu d’équipes appliquent de bout en bout. Agenticiel aide les PME à définir les bons SLO, à instrumenter leurs services IA, et à mettre en place le budget d’erreur et l’évaluation de qualité qui les tiennent informées.
Nous construisons le monitoring et les alertes en même temps que le service, pour que la fiabilité ne soit pas ajoutée après coup mais pensée dès la conception. Le développement est assuré par une équipe offshore francophone, basée à Madagascar, qui travaille dans votre langue et sur votre fuseau horaire. La sous-traitance de développement vous permet de mettre ces pratiques en place sans détourner votre équipe de son travail courant.
Notre approche consiste à mesurer ce qui compte plutôt que ce qui est facile : nous suivons la latence, la qualité et le coût de vos services IA, et nous vous alertons au moment où il faut agir, pas à chaque incident isolé.