Un SLI (service level indicator, indicateur de niveau de service) mesure le comportement de votre service, par exemple la part de requêtes réussies. Un SLO (service level objective, objectif de niveau de service) est la cible interne fixée pour cette mesure, par exemple 99,9 % de vérifications réussies sur 30 jours. Un SLA (service level agreement, accord de niveau de service) est l’engagement que vous prenez envers vos clients, généralement avec une cible inférieure au SLO et une conséquence, comme un avoir, si vous ne le tenez pas. L’indicateur, c’est ce que vous mesurez ; l’objectif, ce que vous visez ; l’accord, ce que vous signez.
Ce guide explique chaque terme avec des exemples, montre ce que représentent les pourcentages de disponibilité en minutes, et détaille comment choisir les indicateurs d’un site web ou d’une API, décider de ce qui compte comme une indisponibilité et rédiger un SLA compréhensible par vos clients.
Les trois termes en langage clair
SLI : la mesure
Un indicateur de niveau de service est un chiffre que l’on peut calculer à partir de données réelles. C’est presque toujours un ratio : les événements réussis divisés par l’ensemble des événements. Pour un site web, ce peut être la part de vérifications de disponibilité qui ont renvoyé la réponse attendue. Pour une API, la part de requêtes qui ont répondu avec un statut autre que 5xx en moins de 500 millisecondes. Un SLI n’a pas de cible associée. Il dit simplement ce qui s’est passé.
SLO : la cible
Un objectif de niveau de service associe une cible et une fenêtre de temps à un SLI. « 99,9 % des vérifications du tunnel de paiement réussissent, mesuré sur 30 jours glissants » est un SLO. C’est un outil interne. Il indique à l’équipe quand la fiabilité est suffisante pour continuer à livrer des fonctionnalités, et quand il est temps de ralentir pour corriger.
SLA : le contrat
Un accord de niveau de service est l’engagement externe, inscrit dans un contrat ou des conditions d’utilisation. Il précise le service, la cible, la méthode de mesure, les exclusions et ce que le client obtient si vous ne tenez pas l’engagement. Tous les services n’ont pas besoin d’un SLA, mais chaque SLA a besoin d’un SLO derrière lui, sinon rien ne vous avertit que vous êtes sur le point de le rompre.
Comment SLI, SLO et SLA s’articulent
Voyez-les comme des couches. Le SLI est le signal brut. Le SLO est une ligne interne plus stricte tracée sur ce signal. Le SLA est une ligne externe plus souple tracée sur ce même signal. Une configuration courante pour un produit SaaS ressemble à ceci (valeurs d’exemple) :
SLI : part des vérifications à la minute sur app.lumenanalytics.io qui renvoient le statut 200 et contiennent le titre du tableau de bord.
SLO : 99,95 % par mois calendaire.
SLA : 99,9 % par mois calendaire, avec un avoir en cas de manquement.
L’écart entre 99,95 % et 99,9 % constitue la marge de sécurité. Si l’équipe voit le SLO se dégrader dès la deuxième semaine, elle a encore le temps d’agir avant que l’engagement contractuel ne soit menacé.
Les pourcentages de disponibilité en minutes
Sur le papier, les cibles de disponibilité semblent proches, mais chaque « neuf » supplémentaire divise par dix l’indisponibilité autorisée. Le tableau ci-dessous utilise un mois moyen (une année de 365,25 jours divisée par 12), comme le calculateur de disponibilité ; un mois de 30 jours autorise un peu moins.
Cible de disponibilitéIndisponibilité autorisée par moisIndisponibilité autorisée par an99 %7 h 18 min 18 s3 jours 15 h 39 min 36 s99,5 %3 h 39 min 9 s1 jour 19 h 49 min 48 s99,9 min 49 s8 h 45 min 57 s99,95 min 54 s4 h 22 min 58 s99,99 %4 min 22 s52 min 35 s99,999 s5 min 15 s
Deux conséquences pratiques en découlent. D’abord, votre surveillance doit être capable de voir l’indisponibilité que vous promettez. Avec des vérifications toutes les cinq minutes, vous ne pouvez pas mesurer honnêtement une cible mensuelle de 99,99 %, car une seule panne non détectée pourrait consommer tout le budget. Ensuite, toute cible au-dessus de 99,9 % ne laisse presque aucune place à une intervention manuelle. À 99,99 %, un seul incident nocturne traité lentement suffit à griller le mois.
Budgets d’erreur : transformer le SLO en décisions
Un budget d’erreur correspond à la quantité de défaillance que votre SLO autorise. Avec un SLO mensuel de 99,9 %, le budget représente 0,1 % du mois, soit environ 43 minutes et 49 secondes sur un mois moyen (43 minutes et 12 secondes sur un mois de 30 jours). Chaque incident en consomme une partie.
Le budget fait de la fiabilité une décision partagée plutôt qu’un sujet de dispute. Une règle simple qu’appliquent de nombreuses équipes :
Plus de la moitié du budget restant : on livre normalement.
Moins de la moitié restante : on revoit les déploiements risqués et on ajoute une relecture aux modifications de base de données.
Budget épuisé : on suspend les sorties de fonctionnalités pour ce service et on travaille sur les causes des derniers incidents jusqu’à la réinitialisation de la fenêtre.
Un exemple : harborlabs.dev a un SLO mensuel de 99,9 % pour son API publique. Le 9, un déploiement raté provoque 18 minutes d’erreurs. Le 20, un problème de certificat en ajoute 9. Cela fait 27 minutes consommées sur 43, avec dix jours restants. L’équipe repousse la prochaine migration de schéma au mois suivant, car un autre incident de la même ampleur ferait manquer l’objectif.
Choisir les SLI d’un site web ou d’une API
De bons SLI décrivent ce que vivent les utilisateurs, pas ce que ressentent vos serveurs. Un CPU à 90 % n’est pas un SLI. Un paiement qui échoue, si. Commencez avec deux ou trois indicateurs par service :
Disponibilité : la part de vérifications ou de requêtes qui réussissent. Pour un site web, « réussir » doit signifier le bon code de statut et le bon contenu, pas seulement une réponse.
Latence : la part de requêtes qui répondent plus vite qu’un seuil, par exemple 95 % en moins de 800 ms. Une part est plus facile à interpréter qu’une moyenne, qui masque les valeurs lentes isolées.
Exactitude : pour les API, la part de réponses qui contiennent les champs attendus. Un 200 avec un corps vide n’est pas un succès.
Mesurez les parcours qui comptent. Pour une boutique comme northwind.shop, cela veut dire le tunnel de paiement et les pages produits, pas seulement la page d’accueil en cache. Pour une API, ce sont les endpoints sur lesquels s’intègrent vos clients, idéalement via un endpoint de health check qui teste la base de données et les autres dépendances. Un moniteur d’API qui valide le corps de la réponse fait de cet endpoint un SLI fiable.
Ce qui compte dans la disponibilité
La plupart des litiges autour des SLA ne portent pas sur le chiffre, mais sur ce qui est comptabilisé. Tranchez ces points avant de publier une cible :
La maintenance planifiée. De nombreux SLA excluent la maintenance programmée annoncée à l’avance, par exemple avec un préavis de 72 heures et un plafond de quatre heures par mois. Si vous l’excluez, précisez comment elle est annoncée et fixez une limite, sinon la « maintenance » devient une échappatoire.
Les pannes partielles. Le service est-il en panne si la connexion fonctionne mais que le paiement échoue ? Définissez les composants couverts et si la panne de l’un d’eux compte comme une indisponibilité de l’ensemble.
Les performances dégradées. Décidez si les réponses plus lentes qu’un seuil comptent comme des échecs. Si une page met 30 secondes à charger, les utilisateurs la considèrent comme en panne.
Les causes indépendantes de votre volonté. Les problèmes de réseau côté client, les usages abusifs et la force majeure sont couramment exclus. Votre propre hébergeur, en général, non : c’est à vous que les clients ont acheté le service.
La durée minimale. Certains SLA ne comptent que les pannes de plus d’une minute ou confirmées par plus d’une vérification, ce qui correspond à la façon dont la surveillance confirme les défaillances.
En interne, il est souvent judicieux d’inclure la maintenance planifiée dans votre SLO, même si le SLA l’exclut. Les utilisateurs n’ont pas pu accéder au service pour autant, et le SLO est censé refléter leur expérience.
Rédiger un SLA destiné aux clients
Un bon SLA est court et précis. Il doit répondre à six questions : quel service, quelle cible, mesurée comment, sur quelle période, avec quelles exclusions, et que se passe-t-il en cas de manquement. Voici un exemple de clause que vous pouvez adapter :
Service : l’application web Lumen Analytics sur app.lumenanalytics.io
et l’API publique sur api.lumenanalytics.io.
Cible : disponibilité mensuelle de 99,9 %.
Mesure : la disponibilité est mesurée par des vérifications externes
toutes les minutes. Une minute est comptée comme indisponible lorsque
le service renvoie une erreur (5xx) ou aucune réponse, confirmée par
une seconde vérification.
Exclusions : maintenance programmée annoncée au moins 72 heures à
l’avance sur notre page de statut (4 heures maximum par mois) ;
problèmes causés par le réseau ou les systèmes du client.
Avoirs : en dessous de 99,9 % : 10 % de l’abonnement mensuel.
en dessous de 99,0 % : 25 % de l’abonnement mensuel.
Les clients demandent leurs avoirs dans les 30 jours suivant la fin du mois.
Fixez le SLA en dessous de ce que vous atteignez réellement. Si votre historique de surveillance affiche 99,97 % sur l’année écoulée, promettre 99,9 % est réaliste. Promettre 99,99 % parce que cela sonne mieux transforme chaque incident en problème contractuel.
Gardez des avoirs proportionnés et une procédure de réclamation simple. Les clients veulent rarement l’argent. Ils veulent voir que vous prenez l’engagement au sérieux et que vous mesurez honnêtement.
Mesurer avec une surveillance externe
Vos propres logs ne peuvent pas mesurer une panne pendant laquelle votre serveur n’a jamais reçu la requête. Pannes DNS, certificats expirés, problèmes réseau et load balancer planté laissent tous vos métriques internes muettes. C’est pourquoi la mesure d’un SLA doit venir de l’extérieur, par le même chemin que vos clients. Si le sujet est nouveau pour vous, commencez par ce qu’est la surveillance de disponibilité et comment elle fonctionne.
Une configuration solide pour le reporting de SLA :
Vérifiez chaque minute. L’intervalle détermine la résolution de votre mesure.
Confirmez chaque échec par une seconde vérification. Cela évite qu’un simple incident réseau passager n’apparaisse dans vos chiffres d’indisponibilité.
Validez le contenu. Recherchez un mot ou un champ qui n’apparaît que lorsque le service fonctionne.
Conservez l’historique. Il vous faut les heures de début et de fin des incidents pour chaque mois sur lequel vous rendez compte.
Publiez-le. Une page de statut avec l’historique de disponibilité permet à vos clients de voir les mêmes chiffres que vous.
Uptimecheck couvre tout cela avec la surveillance de disponibilité jusqu’à chaque minute depuis Stockholm, Londres et New York, des rapports SLA par moniteur pour le mois en cours ou le mois précédent, ou les 7, 30 ou 90 derniers jours, comparés à votre cible, l’export CSV pour le relevé SLA mensuel, et des rapports hebdomadaires et mensuels par e-mail. Une page de statut reliée aux mêmes moniteurs montre à vos clients l’historique de disponibilité qui soutient votre engagement.
La disponibilité n’est qu’un aspect de la fiabilité. La rapidité avec laquelle vous détectez et corrigez les incidents détermine la part du budget que chacun consomme ; lisez MTTR, MTTA et MTBF expliqués pour le volet réponse.
Checklist : définir vos SLI, SLO et SLA
Listez les parcours utilisateur qui comptent : connexion, paiement, API principale.
Définissez un SLI de disponibilité et, si c’est pertinent, un SLI de latence par parcours.
Mesurez pendant un mois ou deux avant de choisir vos cibles.
Fixez le SLO légèrement en dessous de ce que vous atteignez aujourd’hui, et mettez-vous d’accord sur une politique de budget d’erreur.
Fixez le SLA en dessous du SLO, avec des exclusions claires et des avoirs proportionnés.
Mesurez depuis l’extérieur chaque minute et passez les chiffres en revue chaque mois.
Mesurez la disponibilité que vous promettez depuis l’endroit où se trouvent vos clients. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.