C'est quoi un SLO ? Guide complet avec formules et tracker

Vijay Krishnaswamy · 3 octobre 2026 · Data analysis basics

Résumé

C'est quoi un SLO ? Un service level objective est une cible de fiabilité écrite sous forme de chiffre sur une période, par exemple 99,9% de requêtes réussies sur 30 jours. L'écart entre 100% et votre cible c'est le budget d'erreur : 43,2 minutes par mois à 99,9%. Ce guide trie SLI, SLO et SLA, puis vous donne les formules Excel et Google Sheets pour suivre le budget, le taux de consommation et l'état des déploiements.

Golden retriever sitting next to a laptop showing a green availability chart

Alors, c'est quoi un SLO ? Un SLO (service level objective) est une cible de fiabilité que vous fixez pour un service, écrite sous forme d'un chiffre sur une période donnée. « 99,9% des requêtes réussissent sur 30 jours » : c'est un SLO. Ça dit à votre équipe combien de défaillances elle peut se permettre avant d'arrêter de livrer et de commencer à réparer. Les maths derrière, c'est juste une division, c'est pour ça qu'un tableur suffit amplement.

Biscuit a déjà cherché les formules pour vous. Vous, vous apportez les chiffres.

Les trois sigles que vous croisez tout le temps, triés sur le volet

SLI, SLO, SLA. Les gens les mélangent en réunion, donc voici la version courte.

SLI (service level indicator) : c'est ce que vous mesurez. La part des requêtes qui reviennent sans erreur, la part des pages qui chargent en moins de 300 ms, la part des tâches qui se terminent à l'heure.
SLO (service level objective) : c'est la cible pour cette mesure. « Le SLI doit être au moins 99,9% sur 30 jours. »
SLA (service level agreement) : c'est un contrat avec des conséquences, généralement de l'argent remboursé, attaché à une cible.

Le test le plus simple vient du SRE book de Google : demandez-vous ce qui se passe si vous ratez la cible. Si rien de contractuel ne se passe, vous regardez un SLO, pas une SLA. Votre SLO devrait être plus strict que toute SLA que vous avez signée, comme ça vous avez un avertissement avant qu'un client demande un remboursement.

En langage tableur : le SLI, c'est une colonne de mesures, le SLO c'est une cellule avec la cible, et la SLA c'est un PDF que quelqu'un au département légal garde dans un dossier.

Pourquoi 99,9% et 99,99% ne sont pas des promesses équivalentes

Chaque 9 de plus divise par dix le temps d'indisponibilité que vous avez droit. Sur un mois de 30 jours (43 200 minutes), voilà ce que chaque cible vous laisse :

99% : budget de 1%, soit 432 minutes (7,2 heures) de downtime autorisé par 30 jours
99,5% : budget de 0,5%, soit 216 minutes (3,6 heures)
99,9% : budget de 0,1%, soit 43,2 minutes
99,95% : budget de 0,05%, soit 21,6 minutes
99,99% : budget de 0,01%, soit 4,32 minutes

Cette dernière ligne, c'est le piège. Quatre minutes par mois, ça veut dire qu'un humain n'a même pas fini de lire l'alerte avant que le budget soit grillé. La plupart des outils internes, des tableaux de bord et des petits produits SaaS n'en ont pas besoin, et la chasser coûte vraiment cher en redondance et en appels la nuit.

Oubliez les 99,99% sauf si un client vous paie spécifiquement pour ça. Le conseil de Google est direct aussi : commencez avec une cible lâche que vous pourrez resserrer plus tard, parce qu'une cible stricte que vous devez relâcher enseigne à tout le monde à ignorer le chiffre.

Close-up of a fuel gauge needle, a picture of an error budget being spent

Le budget d'erreur : le chiffre sur lequel votre équipe va vraiment argumenter

Le budget d'erreur, c'est ce qu'il vous reste après le SLO. Cible 99,9%, donc le budget c'est 0,1%. Sur 30 jours, ça fait 43,2 minutes de « mauvais » temps que vous avez le droit de dépenser.

Imaginez un jauge d'essence. Les déploiements risqués consomment du carburant. Une migration de base de données qui foirote consomme du carburant. Une panne à 3h du matin consomme beaucoup de carburant. Quand le réservoir est plein, livrez plus vite. Quand il est vide, arrêtez d'ajouter des fonctionnalités et réparez la fiabilité.

La politique officielle de Google elle-même est concrète : si un service grille son budget sur une fenêtre de quatre semaines, tous les changements s'arrêtent sauf les corrections P0 et les patches de sécurité jusqu'à ce que le service soit revenu dans son SLO. Le budget, c'est un outil de négociation, pas une punition. Ça laisse un chef de produit et un ingénieur argumenter à partir de la même cellule au lieu d'argumenter sur des sentiments.

Ça vaut la peine si vous avez plus d'une équipe qui touche au même service. C'est excessif si vous êtes un solopreneur avec une page d'accueil et un formulaire de contact.

Choisir un SLI que vos utilisateurs reconnaîtraient

Les meilleurs SLI décrivent un moment qu'une personne remarquerait. Trois couvrent la plupart des services :

Disponibilité : la part des requêtes qui réussissent. Facile à mesurer, facile à expliquer.
Latence : la part des requêtes plus rapides qu'un seuil. « 95% des recherches reviennent en moins de 300 ms » c'est mieux qu'une moyenne, parce que les moyennes cachent la queue lente qui énerve les gens.
Fraîcheur : pour les pipelines de données et les rapports, la part des exécutions qui se terminent avant la deadline. Celle-ci plaît aux gens des tableurs : « la feuille des ventes du matin est à jour à 8h sur 99% des jours de semaine. »

Écrivez le SLI comme une fraction : bons événements divisés par événements valides. Cette seule habitude rend chaque SLO calculable en une seule cellule, et elle vous force à décider ce qui compte comme « bon » avant l'incident, pas pendant.

Pour la fenêtre, une moyenne mobile de 30 jours c'est l'usage courant. Un mois calendrier c'est plus simple pour un rapport mais réinitialise le budget le 1er, ce qui pousse les équipes à vouloir déployer des trucs risqués à la fin du mois. Dans une feuille, une fenêtre mobile, c'est juste filtrer l'onglet Incidents sur les 30 derniers jours avec SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Construire un tracker SLO dans Google Sheets ou Excel en 10 minutes

Vous n'avez pas besoin d'une plateforme de monitoring pour commencer. Vous avez besoin de deux onglets : Incidents et SLO.

Sur l'onglet Incidents, notez chaque panne avec une heure de début en colonne A, une heure de fin en colonne B, et la durée en colonne C :

=(B2-A2)*24*60

B2 et A2 : fin et début de la panne en date-heure.
*24*60 : transforme la différence en jours en minutes.

Marche dans Excel et Sheets, toutes les versions.

Maintenant l'onglet SLO. Mettez ces libellés en colonne A et les formules en colonne B :

B1: 0.999                         (votre cible SLO)
B2: 30                            (fenêtre en jours)
B3: =B2*24*60                     (total minutes dans la fenêtre)
B4: =B3*(1-B1)                    (budget d'erreur en minutes)
B5: =SUM(Incidents!C2:C)          (downtime jusqu'ici)
B6: =1-B5/B3                      (disponibilité réelle)
B7: =B4-B5                        (budget qui reste, en minutes)
B8: =B5/B4                        (part du budget grillée)

Avec une cible 99,9%, B3 retourne 43 200 et B4 retourne 43,2. Notez une panne de 12 minutes et B8 affiche 27,8%. Voilà ce que ça donne dans une vraie cellule.

Une note sur C2:C dans B5 : la plage ouverte c'est la syntaxe Sheets. Dans Excel, utilisez une plage fixe comme Incidents!C2:C500 ou une référence de tableau.

Ajoutez une cellule de statut comme ça personne ne doit lire le chiffre :

=IF(B8>=1,"Gel des livraisons",IF(B8>=0.5,"À surveiller","C'est bon"))

B8>=1 : budget complètement ou surconsommé.
B8>=0.5 : moitié grillée, donc révisez les changements risqués.
Autre : feu vert.

Choisissez vos propres seuils. Cinquante pour cent c'est une première estimation, pas une loi de la physique.

Coincé sur la syntaxe pour votre propre version de cette feuille ? Décrivez-la en français clair et laissez l'outil l'écrire.

Compter des requêtes au lieu des minutes

Suivre par le temps c'est facile à expliquer mais grossier. Si votre service est « en panne » 5 minutes à 4h du matin quand personne n'est en ligne, ça fait moins de dégâts que 5 minutes à midi. Les équipes sérieuses définissent le SLI par requêtes plutôt que.

Collez un export de votre journal des requêtes dans un onglet, avec le code de statut HTTP en colonne B. Puis :

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

COUNTIF(B2:B,">=500") : compte les requêtes qui ont renvoyé une erreur serveur.
COUNTA(B2:B) : compte toutes les requêtes. Un moins la part d'erreur vous donne la part de succès.

Le résultat c'est votre SLI de disponibilité en fraction. Comparez-le à la cellule cible et vous avez le SLO complet en une ligne. Excel 2016 et 365 acceptent tous les deux COUNTIF ; remplacez juste B2:B par une plage bornée.

Deux avertissements honnêtes. Les tableurs plantent sur des millions de lignes, exportez plutôt des totaux quotidiens au lieu des logs bruts. Et une réponse 4xx c'est généralement l'erreur de l'utilisateur, pas votre panne, donc décidez cette règle une fois et écrivez-la.

Notebook, pencil, coffee and a stopwatch laid out for tracking uptime by hand

Taux de consommation : la formule qui vous avertit avant qu'il ne soit trop tard

Savoir que vous avez grillé 27,8% de votre budget c'est bien. Savoir que vous le grilles plus vite que le calendrier le prévoit, c'est utile. Ce rapport c'est le taux de consommation.

=B8/(B9/B2)

B8 : part du budget grillée jusqu'ici.
B9 : jours écoulés dans la fenêtre (entrez-le à la main ou utilisez =TODAY()-B10, avec la date de début de la fenêtre en B10).
B2 : total de la fenêtre en jours.

Un taux de 1 veut dire vous terminerez la fenêtre avec exactement zéro budget. Plus que 1, vous vous dirigez vers un gel. Moins que 1, vous avez de la marge. Si vous êtes 10 jours dans une fenêtre de 30 jours et vous avez déjà grillé 60%, le taux c'est 1,8. C'est le chiffre à mettre sur un écran.

C'est la même idée que les grands outils de monitoring utilisent pour les alertes sur taux de consommation. Une feuille ne vous sonnera pas à 3h du matin, donc traitez-la comme une couche de reporting, pas une alarme.

Voici un exemple concret avec des chiffres vrais. Votre SLO c'est 99,9% sur 30 jours, donc le budget c'est 43,2 minutes. Jour 1 à 8 : un mauvais déploiement met la page de paiement hors ligne pendant 14 minutes. C'est 32,4% du budget grillé en un quart de la fenêtre, un taux de environ 1,2. Rien n'est en feu, mais la feuille dit maintenant « À surveiller », et la prochaine migration risquée reçoit un deuxième regard. Jour 15 : une panne du fournisseur ajoute 30 minutes. Total 44 minutes, 101,9% grillé. La cellule de statut bascule sur « Gel des livraisons », et la conversation sur les priorités a lieu avec un chiffre sur la table au lieu d'un sentiment.

C'est toute la valeur de l'exercice. Pas les neuf, mais la cellule partagée sur laquelle tout le monde peut pointer.

Quand le tableur ne suffit plus

Un tracker comme celui-ci marche pour un ou deux services et une revue hebdomadaire. Ça se casse quand vous avez des dizaines de services, vous avez besoin de collecte de données automatique, ou vous voulez des alertes qui se déclenchent en minutes plutôt qu'à la prochaine réunion de lundi.

C'est le moment de regarder un vrai outil d'observabilité. Datadog et Grafana ont tous les deux des fonctionnalités SLO natives qui tirent le SLI directement de vos métriques et tracent le budget pour vous.

Choisissez Grafana si vous voulez de l'open source et vous avez déjà Prometheus. Choisissez Datadog si vous préférez payer pour ne rien gérer vous-même. De toute façon, gardez la feuille pour la revue mensuelle parce que tout le monde dans la salle peut l'ouvrir et personne n'a besoin d'un login chez un vendeur.

Si vous voulez de l'aide pour rédiger un premier ensemble de SLI pour un service, un assistant général est un bon partenaire pour du brainstorming. Vérifiez chaque chiffre qu'il vous donne, parce qu'il va volontiers inventer une cible qui sonne plausible.

Les erreurs qui rendent un SLO inutile, et ce qu'il faut faire lundi

Quelques motifs que Biscuit a vus mal tourner :

Copier votre performance actuelle comme cible. Si vous avez tourné à 99,97% le trimestre dernier, un SLO de 99,97% gèle une cadence que vous ne pourrez peut-être pas tenir.
Trop de SLO. Deux ou trois par service. Au-delà, personne ne se souvient lequel compte.
Mesurer ce qui est facile, pas ce que les utilisateurs sentent. La charge CPU n'est pas un SLI. Les checkouts qui échouent en sont un.
Aucune conséquence. Un SLO sans politique de budget d'erreur c'est un voeu. Décidez à l'avance ce qui se passe à 50%, 100% et 150% grillé.
Ne jamais revisiter la cible. Révisez-la tous les trimestres. Si vous ne venez jamais près de dépenser le budget, la cible est trop lâche.

Golden retriever asleep in a quiet home office at night while the dashboard stays green

Maintenant la partie lundi. Choisissez un service. Écrivez un seul SLI en une phrase qu'un non-ingénieur pourrait suivre. Fixez une cible lâche, 99,5% ou 99,9%. Construisez les deux onglets ci-dessus, notez les incidents du mois dernier, et voyez ce que le budget dit.

Si la réponse c'est « on a grillé 300% », vous venez de découvrir pourquoi tout le monde se sent épuisé. Si c'est « on a grillé 4% », resserrez la cible ou livrez plus vite. De toute façon, vous avez maintenant un chiffre à débattre au lieu d'un sentiment.

Bon chien. Maintenant allez noter ces incidents.

Questions fréquentes

C'est quoi un SLO en termes simples ?

Un SLO (service level objective) est une cible de fiabilité pour un service, par exemple « 99,9% des requêtes réussissent sur 30 jours ». Ça transforme une vague aspiration comme « être fiable » en un chiffre que votre équipe peut mesurer et suivre.

Quelle est la différence entre un SLO et une SLA ?

Un SLO est une cible interne. Une SLA est un contrat avec des conséquences, généralement des remboursements ou des crédits, si la cible est ratée. Si rater le chiffre n'entraîne pas de pénalité contractuelle, c'est un SLO. Fixez votre SLO plus strictement que votre SLA.

C'est quoi un budget d'erreur ?

Le budget d'erreur c'est ce que le SLO vous permet de perdre. Un SLO de 99,9% laisse un budget de 0,1%, soit 43,2 minutes de downtime sur 30 jours. Les équipes le dépensent sur les incidents et les déploiements risqués, et ralentissent quand il s'épuise.

Comment calculer un SLO dans Excel ou Google Sheets ?

Calculez le total de minutes dans la fenêtre (jours*24*60), multipliez par (1 - cible) pour avoir le budget, puis soustrayez le downtime enregistré. Pour les SLI basés sur requêtes, divisez les bonnes requêtes par les requêtes totales, par exemple avec COUNTIFS et COUNTA.

Quelle est une bonne cible pour un SLO ?

Commencez lâche, puis resserrez. 99,5% ou 99,9% convient à la plupart des outils internes et petits produits. 99,99% laisse environ 4 minutes de downtime par mois et ne vaut rarement le coup sauf si un client paie spécifiquement pour ça.

Combien de SLO devrait avoir un service ?

Deux ou trois qui correspondent à ce que les utilisateurs sentent vraiment, comme la disponibilité et la latence. Au-delà et personne ne se souvient lequel entraîne les décisions.