SLI, SLO, SLA : comprendre les indicateurs de fiabilité

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 ⏱️ Temps de lecture estimé : 7 minutes

Trois sigles reviennent sans cesse dès qu’on parle de supervision, de fiabilité ou de contrat de service : SLI, SLO et SLA. Ils sont liés, mais répondent à des questions différentes — les confondre est une source fréquente de malentendus entre équipes techniques, management et clients.

À la fin de cette page, vous saurez :

Distinguer un SLI, un SLO et un SLA, et savoir laquelle de ces trois notions répond à « comment on mesure », « quel est l’objectif interne », et « quel est l’engagement contractuel ».
Calculer un budget d’erreur à partir d’un SLO.
Relier ces notions à des outils de supervision concrets (Nagios, par exemple).

Les trois questions

	La question à laquelle il répond	Exemple
SLI — Service Level Indicator	Comment on mesure la performance ?	Le taux de requêtes HTTP répondant en moins de 300 ms
SLO — Service Level Objective	Quel est l’objectif interne visé pour ce SLI ?	99,9 % des requêtes en moins de 300 ms, sur 30 jours glissants
SLA — Service Level Agreement	Quel est l’engagement contractuel envers le client, avec quelles conséquences en cas de non-respect ?	99,5 % de disponibilité mensuelle, avec un avoir financier en cas de manquement

Un moyen simple de les distinguer : un SLI est une mesure (un nombre, une métrique), un SLO est une cible que l’équipe technique se fixe sur cette mesure, et un SLA est une promesse faite à un tiers (souvent avec des pénalités), généralement moins stricte que le SLO interne — pour se garder une marge de sécurité.

SLI (la mesure)  →  SLO (l'objectif interne, strict)  →  SLA (l'engagement contractuel, avec marge)

SLI : que mesurer ?

Un bon SLI est une métrique centrée sur l’expérience utilisateur, pas sur l’infrastructure. Les familles les plus courantes :

Disponibilité : proportion de requêtes qui reçoivent une réponse valide (par exemple, un code HTTP différent de 5xx).
Latence : proportion de requêtes plus rapides qu’un seuil donné (souvent mesurée en percentile : p50, p95, p99).
Taux d’erreur : proportion de requêtes en échec.
Fraîcheur des données (pour un pipeline de données ou une réplication) : délai entre la génération d’une donnée et sa disponibilité.

SLO : fixer un objectif réaliste

Un SLO se formule toujours ainsi : [SLI] doit être ≥ [seuil] sur [fenêtre de temps]. Par exemple :

99,9 % des requêtes de l’API de facturation doivent répondre en moins de 300 ms, mesuré sur une fenêtre glissante de 30 jours.

Le choix du seuil n’est pas arbitraire : viser 100 % est presque toujours le mauvais objectif — cela coûte disproportionnellement cher (astreintes, redondance, ralentissement des livraisons par excès de prudence) pour un gain marginal que l’utilisateur ne perçoit même pas. L’objectif d’un SLO est de trouver le seuil suffisant pour l’usage réel du service.

Le budget d’erreur

La conséquence directe d’un SLO fixé sous les 100 % est le budget d’erreur (error budget) : la marge d’indisponibilité tolérée avant de sortir de l’objectif.

Budget d'erreur = (1 − SLO) × durée de la fenêtre

Exemple concret, pour un SLO de disponibilité de 99,95 % sur un mois (30 jours = 43 200 minutes) :

Budget d'erreur = (1 − 0,9995) × 43 200 minutes
                = 0,0005 × 43 200
                = 21,6 minutes d'indisponibilité tolérée sur le mois

Ce budget d’erreur devient un outil de décision d’équipe, pas juste un chiffre : tant qu’il reste du budget, l’équipe peut prendre des risques mesurés (déploiements plus fréquents, expérimentations). Une fois le budget épuisé, la priorité bascule sur la stabilisation plutôt que sur les nouvelles fonctionnalités — une règle qui évite les débats sans fin sur « est-ce le bon moment de déployer ? ».

SLO visé	Indisponibilité tolérée / mois (30j)	Indisponibilité tolérée / an
99 %	~7h 12min	~3j 15h 36min
99,9 %	~43min	~8h 46min
99,95 %	~22min	~4h 23min
99,99 %	~4min	~53min

SLA : la promesse contractuelle

Le SLA reprend un ou plusieurs SLO, mais formalisés comme un engagement envers un client, généralement avec des conséquences explicites en cas de manquement (avoir, remboursement partiel, droit de résiliation). Deux différences essentielles avec le SLO :

Une marge de sécurité : un SLA promet souvent un seuil moins strict que le SLO interne (par exemple, SLO interne à 99,95 %, SLA client à 99,5 %) — pour absorber les incidents sans déclencher systématiquement des pénalités contractuelles.
Des conséquences formelles : un SLO non atteint déclenche une discussion d’équipe ; un SLA non atteint déclenche une obligation contractuelle.

Relier ces indicateurs à la supervision

Ces notions restent abstraites sans un outil qui mesure réellement le SLI en continu. C’est le rôle d’un système de supervision comme Nagios : définir des checks (temps de réponse HTTP, disponibilité d’un port, espace disque…), les exécuter à intervalle régulier, et déclencher une alerte quand un seuil est franchi.

Nagios (mesure en continu) → alimente le SLI
                            → comparé au seuil du SLO
                            → historique agrégé = respect (ou non) du SLA

Concrètement, une check Nagios de type check_http avec un seuil de latence peut directement nourrir le SLI « proportion de requêtes sous 300 ms » évoqué plus haut : chaque exécution du check est un point de mesure, et l’agrégation de ces points sur la fenêtre du SLO donne le pourcentage à comparer à l’objectif.

Ce qu’il faut retenir

SLI = ce qu’on mesure. SLO = l’objectif interne sur cette mesure. SLA = la promesse contractuelle, généralement plus souple que le SLO.
Un SLO à 100 % est presque toujours une erreur : il interdit tout risque, y compris ceux qui font avancer le produit.
Le budget d’erreur transforme le SLO en outil de décision partagé, pas en simple objectif affiché.
Ces indicateurs n’ont de valeur que s’ils sont mesurés en continu par un outil de supervision — ce sont les fondations théoriques qui donnent son sens à la supervision Nagios pratiquée par ailleurs dans ce parcours.