SLI, SLO et Error Budget : le langage commun entre ops et métier

Vendredi 17 h, un développeur veut déployer une fonctionnalité avant le week-end. L'ops hésite : "Le service a été instable cette semaine." Débat sans fin, décision au feeling. Avec un SLO et un error budget, la réponse est immédiate : "Il reste 60 % du budget ce mois-ci, on peut déployer", ou "Le budget est à 8 %, on gèle et on stabilise." Les SLI (Service Level Indicators), SLO (Service Level Objectives) et error budgets sont les outils du SRE (Site Reliability Engineering) qui transforment la question subjective "est-ce assez fiable ?" en une décision mesurable et partagée entre équipes techniques et métier.

Ce que vous allez apprendre

SLI, SLO, SLA : définitions, différences et relations entre ces concepts
Error budget : le calcul et pourquoi 100 % n'est jamais un bon objectif
Burn rate : mesurer la vitesse de consommation du budget pour alerter intelligemment
Politique d'error budget : que faire concrètement quand le budget s'épuise
Exemples concrets : SLI/SLO pour une API web, un paiement et un pipeline de données

SLI, SLO, SLA : trois niveaux de fiabilité

Ces trois termes se confondent souvent, alors qu'ils appartiennent à trois registres distincts. Le SLI est une mesure : un pourcentage de requêtes réussies, une latence au 99e centile. Le SLO est un objectif interne fixé sur ce SLI, que l'équipe se donne pour arbitrer entre fiabilité et vitesse de livraison. Le SLA est un engagement contractuel envers un client, assorti de pénalités. On mesure donc un SLI, on se fixe un SLO, on signe un SLA.

Définitions

Ce tableau fixe le vocabulaire de tout le reste du guide. Lisez-le dans l'ordre des colonnes : chaque terme se distingue du suivant par qui le fixe et pour qui. Le piège classique est de croire que le SLA est simplement un SLO « officiel » : ce sont deux objets différents, l'un est un objectif de pilotage interne, l'autre un engagement juridique assorti de pénalités.

Concept	Ce que c'est	Exemple concret
SLI (Service Level Indicator)	Une métrique qui reflète l'expérience utilisateur	"Proportion de requêtes HTTP avec un code 2xx/3xx"
SLO (Service Level Objective)	Un objectif interne sur un SLI, défini par l'équipe	"99,9 % des requêtes doivent renvoyer un code 2xx/3xx sur 30 jours"
SLA (Service Level Agreement)	Un engagement contractuel avec le client, assorti de pénalités	"Disponibilité mensuelle ≥ 99,5 %, sinon crédit de 10 %"

SLO et SLA : deux audiences, deux conséquences

La ligne qui porte le plus de conséquences est « Si non atteint ». Manquer un SLO déclenche une réaction interne, un gel de fonctionnalités ; manquer un SLA coûte de l'argent, sous forme de crédits ou de pénalités. C'est précisément pour absorber cet écart de gravité qu'on garde le SLO plus strict que le SLA, sujet de l'encadré qui suit.

	SLO	SLA
À qui	Équipe interne	Client ou utilisateur externe
Formalisé dans	Documentation interne, dashboards	Contrat commercial
Si non atteint	Gel des features, focus fiabilité	Pénalités financières, crédits
Niveau habituel	Plus strict que le SLA	Plus souple (marge de sécurité)

L'error budget : pourquoi 100 % n'est pas un bon objectif

L'error budget est l'inverse du SLO. Si votre SLO est 99,9 %, votre error budget est 0,1 %. C'est la quantité d'indisponibilité tolérée sur une période donnée.

Pourquoi ne pas viser 100 % ? Parce que la fiabilité a un coût exponentiel. Passer de 99,9 % à 99,99 % coûte souvent 10 fois plus cher en infrastructure, en complexité et en temps d'ingénierie. Et pendant ce temps, vous ne livrez aucune fonctionnalité. L'error budget formalise ce compromis : chaque point de fiabilité gagné est un point de vélocité perdu.

Le calcul concret

Pour un SLO de 99,9 % sur 30 jours :

Error budget = 100 % − 99,9 % = 0,1 %
Budget en minutes = 30 jours × 24 h × 60 min × 0,001 = 43,2 minutes

Cela signifie que le service peut être indisponible ou dégradé pendant environ 43 minutes sur un mois sans violer l'objectif.

Tableau de référence : SLO → budget d'indisponibilité

Ce tableau traduit chaque niveau de SLO en temps d'indisponibilité toléré, la forme la plus parlante pour une équipe. Repérez d'abord la ligne qui correspond à votre objectif, puis lisez la colonne mensuelle : c'est le temps total, cumulé, pendant lequel le service peut être dégradé sur un mois sans manquer l'objectif. Ce n'est pas un temps par incident, mais une enveloppe globale que plusieurs pannes se partagent.

SLO	Error budget	Indisponibilité/mois	Indisponibilité/an
99 %	1 %	~7 h 12 min	~3,65 jours
99,5 %	0,5 %	~3 h 36 min	~1,83 jour
99,9 %	0,1 %	~43 min	~8,76 h
99,95 %	0,05 %	~21 min	~4,38 h
99,99 %	0,01 %	~4 min 19 s	~52 min

Hypothèses : mois = 30 jours, année = 365 jours.

Choisir les bons SLI

Un bon SLI reflète ce que l'utilisateur perçoit, pas ce que le serveur mesure en interne. "CPU < 80 %" n'est pas un SLI : le CPU peut être à 95 % sans que l'utilisateur le ressente, ou à 40 % pendant une panne réseau.

Les quatre familles de SLI

Presque tous les SLI utiles se rangent dans l'une de ces quatre familles. Elles vous servent de liste de contrôle au moment de définir vos indicateurs : commencez par la disponibilité et la latence, qui couvrent la majorité des services. Notez la nuance de la ligne latence : une réponse rapide mais en erreur n'est pas un bon événement, une erreur 500 servie en 10 ms ne compte pas comme « traitée en moins de 200 ms ».

Famille	Ce qu'elle mesure	Exemple de SLI
Disponibilité	Le service répond	Proportion de requêtes HTTP avec code ≠ 5xx
Latence	Le service répond vite	Proportion de requêtes traitées en < 200 ms et sans erreur (un 500 rapide n'est pas un "good event")
Qualité	Le service répond correctement	Proportion de réponses complètes (pas de dégradation gracieuse)
Fraîcheur	Les données sont à jour	Proportion de lectures dont l'âge < 1 minute

Un SLI est un ratio

Un SLI s'exprime toujours comme une proportion :

Numérateur : les bonnes expériences (requêtes réussies, requêtes rapides, données fraîches)
Dénominateur : les expériences valides (toutes les requêtes utilisateur légitimes)

Le dénominateur doit exclure le trafic qui ne reflète pas l'expérience utilisateur : healthchecks, sondes internes, endpoints techniques, trafic canary. Sans cette exclusion, on obtient un SLI artificiellement élevé ("99,99 % parce qu'on a compté les /health").

Caractéristiques d'un bon SLI

Un SLI utile vérifie trois critères :

Centré utilisateur : il mesure ce que l'utilisateur voit, pas une métrique technique interne
Quantifiable : on peut le calculer automatiquement à partir de données existantes (logs, métriques, sondes)
Compréhensible : un product manager ou un manager non technique peut comprendre ce que "99,9 % des requêtes en < 200 ms" signifie

Construire un SLO en 6 étapes

Identifier les parcours utilisateur critiques

Ne mesurez pas tout. Concentrez-vous sur les interactions qui comptent pour le business : connexion, recherche, paiement, consultation de compte. Ce sont les CUJ (Critical User Journeys) dans la terminologie Google SRE.
Choisir un SLI pour chaque parcours

Associez au moins un SLI de disponibilité et un de latence à chaque parcours critique. Par exemple, pour un checkout : "proportion de paiements réussis" + "P95 latence du checkout < 2 s".
Fixer un objectif initial conservateur

Mesurez d'abord votre fiabilité actuelle pendant 2 à 4 semaines. Fixez un SLO légèrement en dessous de cette mesure. Il est beaucoup plus facile d'assouplir un SLO que de le durcir une fois que les équipes se sont habituées à un niveau de confort.
Calculer l'error budget

Error budget = 100 % − SLO. Traduisez-le en minutes par mois pour que tout le monde comprenne. "43 minutes par mois" est plus parlant que "0,1 %".
Instrumenter et visualiser

Créez un dashboard qui montre en temps réel le SLI actuel et la consommation du budget. L'équipe doit voir d'un coup d'œil combien de budget il reste.
Définir une politique d'error budget

Documentez explicitement ce qui se passe quand le budget atteint certains seuils. Sans politique, le budget s'épuise et rien ne change, c'est l'anti-pattern le plus courant.

La politique d'error budget

L'error budget n'a de valeur que s'il déclenche des actions concrètes. Le SRE Workbook de Google recommande de définir une politique formelle, documentée et approuvée par les parties prenantes (engineering et product).

Exemple de politique par palier

Budget restant	Comportement attendu
> 50 %	Business as usual, déploiements normaux
25 % – 50 %	Revue des déploiements risqués, tests renforcés
< 25 %	Gel des features non critiques, focus stabilité
Épuisé	Feature freeze complet, convenu à l'avance, seuls les correctifs de sécurité et les P0 passent

Quand le budget est épuisé, les développeurs consacrent leur temps à la fiabilité (dette technique, tests, résilience) plutôt qu'aux nouvelles fonctionnalités. Le budget se régénère naturellement à la fin de la fenêtre de mesure (généralement 30 jours glissants).

Scénario concret : consommation progressive du budget

Prenons un SLO de 99,9 % sur 30 jours, soit un budget de 43 minutes.

Jour 3, un incident réseau cause 15 minutes d'indisponibilité. Budget restant : 28 min (65 %)
Jour 12, un déploiement raté provoque 10 minutes de temps de réponse dégradé. Budget restant : 18 min (42 %)
Jour 18, une latence anormale dure 5 minutes. Budget restant : 13 min (30 %). On entre en zone de vigilance.

À ce stade, la politique impose de revoir les déploiements à venir. Si un quatrième incident survient, le budget tombe sous 25 % et on gèle les features.

Burn rate : alerter sur la vitesse, pas sur le seuil

Le burn rate (taux de combustion) mesure à quelle vitesse le budget se consomme par rapport à la vitesse "normale". Un burn rate de 1 signifie qu'on consomme le budget exactement au rythme prévu sur 30 jours. Un burn rate de 10 signifie qu'on l'épuisera en 3 jours au lieu de 30.

Pourquoi alerter sur le burn rate plutôt que sur le SLO brut ? Parce que sur une fenêtre courte et un trafic faible, la mesure est instable : un SLO à 99,85 % sur 5 minutes peut refléter du bruit statistique et non un problème réel. En revanche, un burn rate de 14× sur 1 heure signifie que 2 % du budget mensuel s'est évaporé en une heure. C'est la vitesse de dégradation qui compte, pas la valeur instantanée.

L'approche multi-fenêtres

Le SRE Workbook de Google recommande l'alerting multi-window, multi-burn-rate. Le principe : combiner une fenêtre longue (pour détecter les tendances) et une fenêtre courte (pour confirmer que le problème est toujours en cours et éviter les faux positifs).

Sévérité	Fenêtre longue	Fenêtre courte	Burn rate	Ce que ça signifie
Critique (page)	1 h	5 min	> 14,4×	2 % du budget consumé en 1 h
Urgent (ticket)	6 h	30 min	> 6×	5 % du budget consumé en 6 h
Avertissement	3 jours	6 h	> 1×	Tendance de dépassement sur le mois

L'alerte ne se déclenche que si les deux fenêtres (longue ET courte) confirment un burn rate élevé. Cela élimine la majorité des faux positifs.

Exemples concrets de SLI/SLO

Service web (API REST)

Pour une API web classique, deux dimensions suffisent à cadrer l'expérience : le service répond (disponibilité) et il répond vite (latence). Remarquez qu'on fixe deux objectifs de latence distincts, au 95e et au 99e centile : le P95 protège l'expérience du plus grand nombre, le P99 borne les cas les plus lents sans exiger la perfection sur chaque requête.

SLI	Mesure	SLO
Disponibilité	Proportion de requêtes HTTP avec code ≠ 5xx	≥ 99,9 % sur 30 j
Latence P95	95e centile du temps de réponse	< 200 ms
Latence P99	99e centile du temps de réponse	< 1 s

API de paiement

Un service de paiement remonte la barre : l'argent tolère moins d'erreurs qu'une page web. Le SLO de disponibilité passe donc à 99,95 %, et surtout apparaît une exigence d'un autre type, l'idempotence. Rejouer une requête ne doit jamais débiter deux fois, et cet indicateur n'a pas d'error budget : c'est une exigence absolue, pas un objectif statistique.

SLI	Mesure	SLO
Taux de succès	Proportion de transactions terminées sans erreur	≥ 99,95 % sur 30 j
Latence P99	99e centile du temps de réponse bout en bout	< 2 s
Idempotence	Proportion de requêtes rejouées traitées correctement	Zéro tolérance, SLO « must », aucun error budget alloué

Pipeline de données (batch)

Un traitement par lots ne se juge pas comme une API : personne n'attend une réponse en millisecondes, mais les données doivent arriver à temps, complètes et correctes. Les trois SLI ci-dessous couvrent ces trois angles. La fraîcheur est souvent le plus critique : une donnée juste mais vieille de plusieurs heures peut fausser une décision autant qu'une donnée erronée.

SLI	Mesure	SLO
Complétude	Proportion de jobs terminés dans les délais	≥ 99 % sur 30 j
Fraîcheur	Âge maximum des données en sortie	< 15 min
Qualité	Proportion de lignes sans erreur de parsing	≥ 99,9 % sur 30 j

Pièges courants

Ces erreurs reviennent projet après projet, et la plupart naissent d'une bonne intention mal placée. La plus fréquente est le SLO trop ambitieux fixé « par sécurité » : viser 99,99 % sans raison business laisse un budget de 4 minutes par mois qu'un seul incident mineur suffit à faire exploser. Lisez la colonne de droite comme une liste d'actions correctives directement applicables.

Piège	Pourquoi c'est un problème	Que faire
SLO trop ambitieux (99,99 % "par sécurité")	Budget de 4 min/mois, chaque incident mineur viole l'objectif	Commencer à 99,9 % et durcir si nécessaire
SLO déconnecté de l'utilisateur (CPU < 80 %)	Ne prédit pas l'expérience réelle	Mesurer la latence et les erreurs vues par l'utilisateur
Trop de SLO (50 indicateurs par service)	Personne ne les suit, perte de focus	1 à 3 SLI par service critique, pas plus
Pas de politique d'error budget	Le budget s'épuise, rien ne change	Documenter et faire signer la politique
SLO = SLA	Aucune marge de sécurité, alerte quand il est déjà trop tard	SLO plus strict que le SLA
Pas d'ownership	Personne ne se sent responsable du SLO	Nommer un owner par SLO

À retenir

Un SLI mesure ce que l'utilisateur perçoit (disponibilité, latence, qualité, fraîcheur), pas une métrique serveur interne.
Un SLO est un objectif interne sur un SLI, il oriente les décisions d'ingénierie et de product management.
Un SLA est un engagement contractuel avec le client, le SLO interne doit toujours être plus strict pour garder une marge.
L'error budget (100 % − SLO) transforme la fiabilité en ressource finie : on la "dépense" pour livrer des fonctionnalités.
Viser 100 % est contre-productif : le coût de chaque "9" supplémentaire est exponentiel, et le budget de changement tombe à zéro.
Le burn rate mesure la vitesse de consommation du budget, alerter sur la vitesse est plus pertinent qu'alerter sur un seuil brut.
Sans politique d'error budget formalisée et appliquée, tout le mécanisme SLI/SLO est cosmétique.

Sources

Google, Service Level Objectives (SRE Book, chapitre 4) : sre.google/sre-book/service-level-objectives, la référence fondatrice, définit SLI, SLO et SLA dans le contexte Google.
Google, Implementing SLOs (SRE Workbook, chapitre 2) : sre.google/workbook/implementing-slos, guide pratique pas à pas pour construire et piloter des SLO.
Google, Alerting on SLOs (SRE Workbook, chapitre 5) : sre.google/workbook/alerting-on-slos, multi-window multi-burn-rate alerting, avec les formules de calcul.
Google, Error Budget Policy : sre.google/workbook/error-budget-policy, exemple concret de politique d'error budget chez Google.

Prochaines étapes

Golden Signals, RED, USE : choisir quoi mesurer Les frameworks pour décider quels SLI collecter selon le type de composant.

Observabilité vs monitoring Comprendre pourquoi mesurer ne suffit pas, il faut pouvoir interroger.

Alerting : bonnes pratiques Mettre en place des alertes qui réveillent à bon escient grâce au burn rate.

Gestion des incidents Que faire concrètement quand l'error budget s'épuise et qu'un incident survient.