SLO vs SLA : la différence, les SLI et le budget d'erreur

1 novembre 2026 8 min de lecture

Un SLA (accord de niveau de service) est un contrat avec un client qui dit ce qui se passe quand un service n’atteint pas un niveau promis, le plus souvent un crédit de service. Un SLO (objectif de niveau de service) est la cible interne sur laquelle une équipe pilote le service ; le livre SRE conseille de la fixer plus stricte que le SLA pour que les problèmes soient réglés avant que le contrat ne soit enfreint. Un SLI (indicateur de niveau de service) est la mesure dans laquelle les deux sont exprimés, par exemple la part des requêtes qui réussissent.

	SLI	SLO	SLA
Ce que c’est	Une mesure	Une cible pour un SLI	Un contrat fondé sur des SLO
Fixé par	L’ingénierie	Le product owner et l’ingénierie	Les équipes commerciales et juridiques
En cas d’échec	Rien en soi	Budget d’erreur consommé	Crédits de service ou pénalités
Exemple	Appels de paiement réussis	99,95 % sur quatre semaines	99,9 % par mois, sinon un crédit

Les exemples sont des illustrations ; les sources sont le livre SRE et le workbook SRE de Google ainsi que le SLA Amazon Compute, vérifiés le 1er novembre 2026.

Que signifient SLI, SLO et SLA ?

Service level indicator, service level objective et service level agreement : indicateur, objectif et accord de niveau de service. L’indicateur est ce que vous mesurez, l’objectif la valeur que vous visez, et l’accord ce que vous promettez à quelqu’un d’autre, avec des conséquences à la clé.

Le chapitre « Service Level Objectives » du livre SRE définit un SLA comme « un contrat explicite ou implicite avec vos utilisateurs qui prévoit des conséquences si les SLO qu’il contient sont respectés (ou manqués) ». Le test du chapitre tient en une question : que se passe-t-il si les SLO ne sont pas atteints ? Sans conséquence explicite, vous avez presque certainement affaire à un SLO.

Le chapitre ajoute que la plupart des gens pensent SLO quand ils disent SLA, et qu’une vraie violation de SLA peut finir en procès pour rupture de contrat. Quand une réunion tourne au débat SLA vs SLO, demandez donc d’abord si une conséquence, en général financière, est inscrite dans un contrat.

Le livre SRE conseille de garder une marge de sécurité : « un SLO interne plus strict que le SLO annoncé aux utilisateurs vous laisse le temps de réagir aux problèmes chroniques avant qu’ils ne deviennent visibles de l’extérieur ». Son chapitre « Embracing Risk » applique la même idée à un contrat : un objectif externe de 99,9 % adossé à un objectif interne plus exigeant.

Qu’est-ce qu’un budget d’erreur ?

C’est 100 % moins le SLO : la part des requêtes ou du temps qui peut échouer dans la fenêtre. Tant qu’il reste du budget, l’équipe continue de livrer ; une fois épuisé, le travail de fiabilité passe en premier.

Le chapitre « Implementing SLOs » du workbook SRE donne le calcul : avec un SLO de 99,9 %, un service qui reçoit 3 millions de requêtes sur quatre semaines peut en faire échouer 3 000, si bien qu’une panne de 1 500 erreurs consomme la moitié du budget. Le chapitre « Embracing Risk » du livre en explique le but : la gestion produit fixe le SLO, le monitoring mesure la disponibilité réelle, et l’écart est la marge de non-fiabilité qui reste pour le trimestre. Quand ce budget est épuisé, les mises en production sont arrêtées ou ralenties.

Combien d’indisponibilité permet 99,9 % ?

Environ 43 minutes sur une fenêtre de 30 jours. Chaque neuf supplémentaire divise la marge par dix, si bien que 99,99 % laisse à peine plus de 4 minutes.

SLO	Budget d’erreur	Indisponibilité sur 30 jours	Échecs par million
99 %	1 %	7 h 12 min	10 000
99,5 %	0,5 %	3 h 36 min	5 000
99,9 %	0,1 %	43 min 12 s	1 000
99,95 %	0,05 %	21 min 36 s	500
99,99 %	0,01 %	4 min 19 s	100

Multipliez les 43 200 minutes d’une fenêtre de 30 jours par le budget d’erreur. Gardez en tête l’avertissement du workbook : chaque neuf supplémentaire coûte plus cher alors que son intérêt pour les utilisateurs tend vers zéro.

À quoi ressemble un vrai SLA ?

Il fixe un pourcentage mesuré, une période de facturation, un barème de crédits et ce qui ne compte pas. Le SLA Amazon Compute en est un exemple public et court.

L’Amazon Compute Service Level Agreement (mis à jour le 25 mai 2022 ; vérifié le 1er novembre 2026) s’engage sur un Monthly Uptime Percentage d’au moins 99,99 % par région pour les instances EC2 réparties sur deux Availability Zones ou plus, et 99,5 % pour une instance seule. La disponibilité vaut 100 % moins la part des minutes pendant lesquelles EC2 était indisponible. Selon le Region-Level SLA, sous 99,99 %, le crédit vaut 10 % de la facture EC2 du mois dans la région, sous 99,0 % il vaut 30 %, et sous 95,0 % il vaut 100 % ; pour une instance seule, le palier à 10 % commence sous 99,5 %. Les crédits s’imputent sur les paiements futurs, doivent être réclamés via le support AWS et constituent le recours « seul et exclusif », sauf disposition contraire du contrat client.

Rapporté au tableau d’indisponibilité, le palier à 10 % du Region-Level SLA couvre d’environ 4 minutes à 7 heures d’indisponibilité sur un mois de 30 jours. Un SLA plafonne ce que le fournisseur doit ; empêcher les pannes de nuire à vos utilisateurs, c’est le rôle de vos propres objectifs.

Comment choisir des SLI pour la latence et la disponibilité ?

Mesurez la latence en percentile et la disponibilité en événements réussis divisés par tous les événements, au plus près de l’utilisateur. Les moyennes et les mesures prises au seul serveur masquent les requêtes dont on se plaint.

Latence. Le livre SRE préfère les percentiles à la moyenne, car une moyenne peut rester plate pendant que les requêtes les plus lentes ralentissent nettement. Le workbook écrit les SLI de latence comme un ratio, par exemple les appels terminés en moins de 100 ms divisés par tous les appels. « 99 % des appels de paiement en moins de 400 ms » revient donc à « p99 du paiement sous 400 ms » sur la fenêtre, ce qui se reporte tel quel dans un test. Notre article sur la latence de queue explique pourquoi le p99 compte dès qu’une page appelle plusieurs services.

Disponibilité. La disponibilité temporelle compte les minutes de fonctionnement, comme le fait le SLA d’AWS. La disponibilité par requêtes compte les requêtes réussies : « Embracing Risk » décrit un service de 2,5 millions de requêtes par jour avec un objectif quotidien de 99,99 %, qui peut renvoyer 250 erreurs et tenir quand même son objectif.

Où les SLO dérapent-ils ?

Le plus souvent par excès d’objectifs, par des cibles à 100 % et par des indicateurs mesurés là où les utilisateurs ne sont pas. Chacun produit un chiffre sur lequel personne n’agit, ou un chiffre qui semble bon pendant que les utilisateurs souffrent.

Trop de SLO. Le livre SRE conseille d’en avoir le moins possible : si citer un SLO ne permet jamais de gagner une discussion sur les priorités, il ne vaut probablement pas la peine.
Des cibles à 100 %. Le workbook juge que 100 % est la mauvaise cible : les composants tombent en panne, le changement est la première source de pannes, et un SLO à 100 % ne laisse que le temps de réagir.
Mesurer seulement au serveur. Les métriques serveur ratent des problèmes que les utilisateurs ressentent, comme un script lent dans la page. Le workbook propose de mesurer au load balancer ou côté client.

Quel rapport entre le test de charge et les SLO ?

Un SLO fournit au test de charge ses critères de réussite, et un test au pic attendu montre si le SLO de latence tiendra avant que ce trafic n’arrive. Le monitoring de production ne vous le dit qu’après coup.

Le livre SRE note qu’un nombre plus élevé de requêtes par seconde (QPS) entraîne souvent des latences plus grandes et que les services présentent fréquemment une falaise de performance au-delà d’un certain seuil de charge. Un test de charge peut trouver cette falaise s’il tourne au pic attendu, avec un mélange de requêtes réaliste, et mesure le SLI qu’utilise le SLO. Fixez chaque seuil du test un peu plus strict que le SLO, comme le décrit notre guide des critères de réussite d’un test de charge. Une exécution dure quelques minutes et ne peut donc pas mesurer une disponibilité mensuelle.

LoadFocus, qui publie ce site, juge les tests de charge sur des seuils de réussite enregistrés sur le test : Max P95 et Max P99 du temps de réponse, un taux d’erreur maximal et un débit minimal, pour les tests cloud, JMeter et k6. Son monitoring d’API propose des rapports SLA et SLO qui fixent un objectif SLO par moniteur et affichent la disponibilité, le budget d’erreur consommé et un statut OK ou Dépassé.

FAQ

Que signifie SLO ? Service level objective, ou objectif de niveau de service : une valeur cible pour un niveau de service mesuré, par exemple 99,9 % de requêtes réussies sur quatre semaines. Il est fixé en interne, par le produit et l’ingénierie, et n’entraîne en soi aucune pénalité contractuelle.

Peut-on avoir un SLO sans SLA ? Oui. Le livre SRE cite la recherche Google comme un service important sans SLA public, qui est pourtant piloté avec des SLI et des SLO.

Un SLO devrait-il valoir 100 % ? Non. Un objectif de 100 % ne laisse aucun budget d’erreur, si bien que chaque échec l’enfreint et qu’aucun changement n’est jamais sûr à livrer.