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. Une analogie simple les distingue : un SLI est le thermomètre, un SLO est la température souhaitée, et un SLA est le contrat avec le chauffagiste qui prévoit des pénalités si la maison est trop froide.

Définitions

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

	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é

SLO	Error budget	Indisponibilité/mois	Indisponibilité/an
99 %	1 %	~7 h 18 min	~3,65 jours
99,5 %	0,5 %	~3 h 39 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

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’oeil 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)

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

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)

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

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.