Fixer un SLA de disponibilité ou un SLO de latence sans méthode revient à parier le budget infrastructure sur une intuition. Voici comment calibrer ces seuils pour une API d'inférence IA, avec le calcul d'erreur type d'une ETI qui a visé trop haut.
La confusion entre ces trois sigles coûte cher dès qu'un service d'inférence passe en production. Dans la terminologie popularisée par Google, le SLI (Service Level Indicator) est la métrique observée, le SLO (Service Level Objective) est la cible interne fixée sur cette métrique, et le SLA (Service Level Agreement) est l'engagement contractuel envers un client, assorti le plus souvent de pénalités. Les SLO sont plus granulaires et constituent des assurances basées sur des KPI spécifiques des utilisateurs, tandis que le SLA est un contrat englobant dont le SLO forme un sous-ensemble.
Pour une API d'inférence, cette distinction a une conséquence pratique immédiate : le SLO doit être plus strict que le SLA, pour laisser une marge de manœuvre interne avant que l'engagement contractuel ne soit rompu. Confondre les deux niveaux, comme le font encore beaucoup d'équipes data qui industrialisent leur premier service de production, conduit soit à sur-engager l'entreprise auprès de ses clients, soit à sous-dimensionner l'infrastructure sans filet de sécurité.
Le concept central pour calibrer un seuil n'est pas la disponibilité visée en elle-même, mais ce qu'elle autorise comme marge d'erreur. Un error budget est la quantité d'irrégularité qu'un service est autorisé à avoir avant de rompre son objectif de niveau de service, selon la formule error budget = 1 − SLO.
Concrètement, voici ce que différents paliers de disponibilité impliquent en temps d'indisponibilité cumulée :
Pour un SLO mensuel plutôt qu'annuel, la référence la plus citée reste celle de 99,9 % : une SLO de 99,9 % laisse un error budget de 0,1 %, soit 43,2 minutes d'indisponibilité autorisée par mois. Ce chiffre n'est pas un dogme, c'est un point de départ pour raisonner en coûts et en risques plutôt qu'en pourcentages abstraits.
Le même raisonnement s'applique à l'erreur applicative, pas seulement à l'indisponibilité pure. Le SLA peut être calculé comme le pourcentage de requêtes réussies sur le total des requêtes valides, en excluant les problèmes côté client — une nuance essentielle pour une API d'inférence, où une partie des échecs provient de prompts mal formés ou de dépassements de contexte côté appelant, et ne devrait pas peser sur le SLA du fournisseur du service.
Contrairement à un SLA de disponibilité binaire (le service répond ou non), la latence d'une API d'inférence se négocie en percentiles, et ces percentiles varient radicalement selon le cas d'usage. Pour un chat interactif, par exemple, 300 ms de temps avant le premier jeton (P99) est le seuil où les utilisateurs cessent de percevoir un délai ; à 500 ms, la majorité perçoit un retard ; à 800 ms, les abandons de session augmentent de manière mesurable.
Les ordres de grandeur changent du tout au tout selon le type de traitement :
Un piège classique consiste à fixer un seuil de latence unique pour toute une API, sans distinguer les usages synchrones (chat, complétion de code) des usages asynchrones (traitement par lots, agents). Le bon réflexe, documenté dans les pratiques récentes de SLO engineering, est d'établir un objectif sur le temps total de traitement du job plutôt que sur le temps avant premier jeton pour les charges par lots, et de dimensionner la capacité en conséquence.
Sur la disponibilité pure des fournisseurs d'inférence, les repères du marché donnent une fourchette utile pour négocier un contrat : 99,95 % minimum pour de l'inférence en production, 99,99 % si l'application est orientée utilisateur avec une faible tolérance aux interruptions, en vérifiant les définitions de l'indisponibilité, les modalités de compensation, et si les SLA d'API et d'instances GPU diffèrent. Un niveau inférieur à 99,9 % est généralement jugé inadapté à des charges de production.
Fixer un SLO ne sert à rien si l'équipe ne sait pas quand réagir avant qu'il soit dépassé. La méthode de référence, documentée dans le SRE Workbook de Google, combine plusieurs fenêtres temporelles et plusieurs seuils de vitesse de consommation du budget d'erreur :
SLO budget consumption 2% sur 1 heure avec un burn rate de 14,4 déclenche une page ; 5% sur 6 heures avec un burn rate de 6 déclenche une page ; 10% sur 3 jours avec un burn rate de 1 déclenche un ticket.
L'intérêt de croiser une fenêtre courte et une fenêtre longue est d'éviter les fausses alertes : les alertes à fenêtre unique détectent soit rapidement avec de faux positifs, soit précisément mais lentement ; l'approche multi-fenêtre multi-burn-rate résout ce problème en combinant une fenêtre courte à combustion rapide avec une fenêtre longue à combustion plus lente. Pour une équipe data qui expose une API d'inférence à des équipes métier internes ou à des clients externes, c'est ce dispositif — pas le seul tableau de bord de disponibilité mensuelle — qui permet de réagir avant la violation contractuelle plutôt qu'après.
Prenons le cas représentatif d'une ETI industrielle qui a lancé en 2025 une API d'inférence interne pour de la maintenance prédictive, exposée à une vingtaine d'usines. Le cahier des charges initial, rédigé sans benchmark, fixait un SLA de disponibilité à 99,99 % et un SLO de latence P99 à 150 ms pour tous les types de requêtes, y compris les requêtes de génération de rapports longs.
Le choix de 99,99 % n'était pas anodin sur le plan technique : ce niveau nécessite une architecture redondante avec basculement automatique, ce qui multiplie les coûts d'infrastructure. Côté datacenter, l'ordre de grandeur est documenté : le choix de la disponibilité a un impact direct sur le coût total, la part du budget liée au niveau de redondance étant estimée à 60 %. Appliqué à une infrastructure GPU dédiée plutôt qu'à un datacenter classique, le surcoût se traduit par du multi-région redondant, du failover automatique et une capacité de réserve dimensionnée pour absorber un pic sans jamais dégrader la latence — autant d'éléments que l'ETI n'avait budgétés qu'à hauteur d'un SLA à 99,9 %.
Le second problème, plus insidieux, portait sur la latence uniforme à 150 ms. En appliquant ce seuil à des requêtes hétérogènes — alertes courtes de 50 tokens et rapports de synthèse de 2 000 tokens — l'équipe s'est retrouvée à sur-provisionner des GPU pour que même les requêtes longues respectent un P99 pensé pour du chat interactif. Or sur-dimensionner immobilise du budget, laisse des GPU sous-utilisés et fait s'évaporer le retour sur investissement. Le phénomène n'est pas isolé : à l'échelle du marché, un taux d'utilisation des GPU de 5% est le symptôme d'un problème structurel, les entreprises ayant sécurisé des capacités massives, souvent via des contrats de 3 à 5 ans, qui restent des coûts fixes sur leurs bilans que le matériel soit utilisé ou non.
Le correctif a consisté à reprendre la méthode depuis le début : séparer les SLO par type de requête (chat court, génération de rapport), fixer le SLA contractuel un cran en dessous du SLO interne, et redescendre la cible de disponibilité à 99,9 % pour les usages non critiques tout en réservant 99,95 % aux seuls flux d'alerte temps réel. Le gain n'a pas été mesuré en pourcentage marketing mais en requêtes correctement dimensionnées : l'équipe a pu réaffecter une partie de la capacité GPU libérée, sans toucher à la qualité perçue par les utilisateurs métier, qui ne faisaient de toute façon pas la différence entre 150 ms et 400 ms sur un rapport de synthèse.
Pour une équipe qui industrialise une API d'inférence, la démarche qui évite ce type d'écueil tient en quatre étapes :
Cette méthode ne dispense pas d'un travail de dimensionnement capacitaire en amont, qui reste le facteur déterminant du coût final du service. Sur ce point, notre offre de conseil et de formation en industrialisation de l'IA accompagne les équipes data dans le calibrage conjoint des SLO de latence et du dimensionnement GPU, pour éviter à la fois le sous-provisionnement qui dégrade l'expérience utilisateur et le sur-provisionnement qui immobilise le budget sans bénéfice mesurable. Pour les ETI qui démarrent cette démarche, notre page expertise détaille les méthodes de mesure et d'alerting appliquées aux services d'inférence en production.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus