Une plateforme répond aux sondes de supervision. Ses serveurs sont allumés, sa page d’accueil s’ouvre et son fournisseur annonce une disponibilité presque parfaite. Pourtant, les clients ne peuvent plus télécharger leurs factures. Pour eux, le service est en panne.
Ce décalage explique l’intérêt des objectifs de niveau de service, ou SLO. Ils obligent à définir ce qui doit fonctionner, pour qui, pendant quelle période et avec quelle marge de dégradation acceptable. Le chiffre obtenu sert ensuite à arbitrer les investissements et les changements. Il ne remplace ni un contrat ni l’analyse des incidents.
La difficulté consiste rarement à calculer un pourcentage. Elle consiste à choisir un pourcentage qui décrit une expérience utile.
En bref — Un SLI mesure une propriété du service ; le SLO fixe son objectif. Le budget d’erreur représente la dégradation tolérée sur une période précise. Il faut mesurer les parcours importants, distinguer disponibilité et rapidité, puis décider à l’avance de ce qui se passe lorsque le budget est consommé.
Partir d’une action client, pas d’un serveur
Prenons une entreprise fictive qui propose un portail de commandes aux professionnels. Un acheteur doit consulter son catalogue, vérifier un prix négocié, envoyer une commande puis retrouver son accusé de réception. Quatre opérations visibles. Derrière, les composants peuvent être nombreux : authentification, application, base de données, moteur tarifaire et messagerie.
Le responsable métier peut accepter un retard sur l’export mensuel. Il peut beaucoup moins accepter une commande perdue ou facturée deux fois. Appliquer le même objectif à toutes les fonctions diluerait cette différence.
Commencez donc par nommer trois parcours critiques, leur résultat attendu et le dommage associé à leur échec. Il ne s’agit pas encore de parler de processeur, de mémoire ou de nombre de conteneurs. Ces mesures aideront au diagnostic, mais elles ne prouvent pas qu’un utilisateur a obtenu son résultat.
Une phrase utile ressemble à ceci : « Un acheteur autorisé peut envoyer une commande valide et recevoir une confirmation identifiable. » Elle permet de discuter de réussite métier, de délai et de traçabilité. « L’API répond en HTTP 200 » reste trop faible si la réponse contient un message d’erreur ou confirme une opération jamais enregistrée.
Ce travail prolonge la définition de critères vérifiables dans un cahier des charges. La différence est temporelle : la recette contrôle une version ; le SLO suit l’expérience réelle dans la durée.
Construire un indicateur dont le dénominateur est explicite
Le SLI, indicateur de niveau de service, peut exprimer la proportion d’événements satisfaisants parmi les événements éligibles. Pour les commandes, on pourrait compter les tentatives valides qui aboutissent à un enregistrement durable et à une confirmation, divisées par toutes les tentatives valides observées au point de mesure choisi.
Le mot « éligibles » mérite une définition écrite. Exclut-on les robots ? Les essais internes ? Les commandes correctement refusées parce que le client n’a pas les droits ? Les interruptions de maintenance ? Une exclusion choisie après un incident peut améliorer le tableau sans améliorer le service.
Une règle raisonnable distingue un refus métier attendu d’un dysfonctionnement technique. Un panier dépassant une limite contractuelle n’est pas nécessairement une panne. Un client incapable de commander parce que le contrôle de limite ne répond plus en est potentiellement une. Il faut conserver des codes de cause assez fins pour éviter d’amalgamer ces situations.
| Parcours fictif | Événement satisfaisant proposé | Risque à surveiller |
|---|---|---|
| Validation d’une commande | Enregistrement confirmé une seule fois | Réponse positive sans écriture durable |
| Consultation d’une facture | Document correct accessible à l’utilisateur autorisé | Page disponible mais fichier introuvable |
| Recherche d’un produit | Résultat rendu avec les données requises | Résultat rapide mais prix périmé |
| Export comptable | Export complet livré avant l’heure convenue | Traitement terminé avec des lignes manquantes |
Ces définitions sont des exemples de conception, pas des objectifs universels. Un export quotidien et une transaction interactive n’ont pas le même rythme. Pour un traitement différé, la fraîcheur des données ou l’achèvement avant une échéance peuvent être plus pertinents qu’un pourcentage de réponses HTTP.
Documentez aussi les limites d’observation. Les journaux du serveur ne voient pas toujours les requêtes qui n’arrivent jamais jusqu’à lui. Une sonde externe peut détecter un problème réseau sans représenter toutes les configurations clientes. La mesure depuis le navigateur rapproche l’observation de l’utilisateur, mais dépend elle-même de la collecte des événements.
La meilleure première mesure est celle que l’équipe peut expliquer et maintenir. Elle doit rester améliorable. Un angle mort identifié vaut mieux qu’une précision affichée qui repose sur une collecte incomprise.
Calculer le budget sans mélanger requêtes et minutes
Un SLO de 99,9 % de requêtes réussies autorise une proportion d’échecs de 0,1 % sur sa fenêtre d’évaluation. Dans notre exemple fictif, un million de requêtes éligibles donnent un budget de 1 000 échecs. Si 600 ont déjà échoué, 60 % du budget ont été consommés ; il en reste 400 pour ce volume observé.
Ce budget ne correspond pas automatiquement à une durée d’arrêt. Une minute pendant un pic commercial peut contenir beaucoup plus de requêtes qu’une minute la nuit. Convertir mécaniquement ce SLO en minutes ferait perdre cette information.
Avec une mesure fondée sur le temps, le calcul change. Un mois fictif de 30 jours contient 43 200 minutes. Les durées ci-dessous ne valent que pour une définition de disponibilité temporelle couvrant toute cette période.
| Objectif temporel | Indisponibilité théorique autorisée sur 30 jours |
|---|---|
| 99 % | 432 minutes |
| 99,9 % | 43,2 minutes |
| 99,95 % | 21,6 minutes |
| 99,99 % | 4,32 minutes |
Le tableau ne constitue pas une promesse contractuelle. La granularité des mesures, les exclusions et les règles d’arrondi influencent le résultat réel. Il montre surtout que chaque niveau supplémentaire réduit fortement la marge disponible.
Il faut ensuite choisir une fenêtre : mois calendaire, quatre semaines glissantes ou autre période adaptée. Une fenêtre glissante évite qu’une panne disparaisse artificiellement du bilan le premier jour du mois suivant. Une période calendaire facilite certaines revues budgétaires. Garder les deux vues peut être utile, à condition de savoir laquelle déclenche la politique opérationnelle.
La rapidité mérite son propre objectif
Un service peut réussir toutes ses requêtes et rester pénible à utiliser. Si chaque écran met dix secondes à s’ouvrir, les utilisateurs répètent leurs actions, abandonnent ou appellent le support. La disponibilité seule ne décrit pas cette expérience.
On peut donc ajouter un SLO de latence : par exemple, dans un scénario pédagogique, 99 % des recherches éligibles doivent produire leur réponse en moins de 800 millisecondes au point de mesure défini. Le seuil doit être discuté avec les équipes produit et les usages réels ; ce n’est pas une référence valable pour tous les sites.
Attention aux moyennes. Une moyenne stable peut cacher une petite fraction de réponses extrêmement lentes. Les percentiles ou le comptage des événements dépassant un seuil rendent cette queue de distribution visible. Mesurer côté serveur et côté utilisateur aide également à distinguer calcul applicatif, transfert et affichage.
Évitez toutefois d’additionner des objectifs sans priorité. Une petite équipe gérera mieux quelques indicateurs liés aux actions essentielles qu’une centaine de seuils techniques déclenchant des alertes concurrentes. Un indicateur doit mener à une décision identifiable : intervenir, investiguer, différer un changement ou accepter temporairement un mode dégradé.
Pour une recherche, le mode dégradé peut afficher moins de résultats tout en restant utile. Pour un paiement, il peut être inacceptable de confirmer sans preuve. La qualité attendue dépend du parcours, et doit apparaître dans la définition des événements satisfaisants.
Transformer le budget en décisions
Le budget d’erreur n’est pas une permission de négliger les clients. C’est un mécanisme d’arbitrage. Une équipe qui ne connaît pas sa marge prend parfois autant de risques après plusieurs incidents qu’en période stable. À l’inverse, elle peut geler tous les changements pendant des mois sans distinguer leurs effets.
Écrivez une politique courte avant la première crise. Elle précise qui examine le budget, quelles décisions peuvent être suspendues, quelles exceptions restent possibles et comment reprendre le rythme normal. Une correction de sécurité urgente ne se traite pas comme une nouvelle fonction facultative ; elle demande une évaluation de risque documentée.
Dans notre entreprise fictive, l’équipe pourrait décider qu’un budget épuisé impose une revue des changements récents, une limitation des déploiements risqués et un plan correctif. Les travaux réduisant directement le risque continueraient. Une dérogation serait approuvée par un responsable nommé, avec motif, surveillance et procédure de retour arrière.
Le gel automatique de toute activité serait souvent contre-productif. Un défaut de données peut exiger un déploiement pour être corrigé. Le bon mécanisme expose le risque et rend l’arbitrage visible, au lieu de transformer un chiffre en interdiction aveugle.
Le suivi gagne aussi à séparer les conséquences immédiates et les causes. « 250 confirmations n’ont pas été délivrées » décrit un dommage observable. « Une dépendance a dépassé son quota » décrit une cause possible. Le client a besoin d’une solution, tandis que l’équipe doit prévenir la répétition.
La gestion des erreurs et des reprises dans les automatisations complète ce dispositif lorsque les traitements impliquent plusieurs services. Une reprise mal conçue peut transformer une indisponibilité courte en doublons durables.
Alerter sur une menace réelle, sans épuiser l’équipe
Une alerte utile doit signaler un problème qui appelle une action. Un dépassement fugace sans conséquence peut justifier une analyse différée, plutôt qu’un réveil nocturne. Une panne complète du parcours de commande demande, elle, une réaction rapide même avant l’épuisement du budget mensuel.
Le taux de consommation du budget, souvent appelé burn rate, compare le taux d’événements dégradés au taux autorisé par le SLO. Dans un exemple fictif avec 0,1 % d’échecs autorisés, un taux observé de 1 % représente une consommation dix fois plus rapide que la référence. Ce rapport seul ne dit pas combien de budget sera consommé demain : le trafic et la durée de l’incident comptent aussi.
Des fenêtres courtes et longues permettent de distinguer une flambée récente d’une dérive persistante. Les paramètres doivent être testés sur l’historique et ajustés au volume. À faible trafic, une seule requête ratée produit un pourcentage spectaculaire ; des sondes synthétiques et des contrôles ciblés peuvent compléter l’analyse.
La fiche d’alerte doit indiquer le parcours affecté, la fenêtre, le volume, les symptômes et le premier contrôle à réaliser. Ajoutez le responsable, le moyen d’escalade et une procédure accessible lorsque les outils habituels sont en panne. Une belle notification qui mène à une documentation inaccessible reste peu opérationnelle.
Une revue mensuelle qui produit des changements précis
La revue ne devrait pas se limiter à constater « objectif atteint ». Il faut regarder les segments masqués par l’agrégation : clients d’une région, navigateur particulier, grandes commandes ou utilisateurs ayant un rôle spécifique. Un résultat global satisfaisant peut coexister avec un parcours inutilisable pour un groupe réduit.
Pour chaque incident significatif, rapprochez les événements dégradés, la durée, les utilisateurs concernés et la cause confirmée. Cherchez une correction proportionnée : limiter un délai d’attente, réduire une dépendance synchrone, tester la reprise, augmenter une capacité ou rendre un refus plus explicite.
Consignez la version de l’indicateur. Modifier le périmètre ou l’exclusion d’un type d’erreur change la série. Présenter l’ancien et le nouveau calcul pendant une transition évite d’attribuer une amélioration à une intervention technique alors qu’elle vient d’une définition différente.
La fiabilité a enfin un coût complet. Exemple fictif : 900 euros d’infrastructure et huit heures mensuelles d’exploitation valorisées à 45 euros donnent 1 260 euros par mois. Ce calcul ne prouve pas la rentabilité d’un objectif plus élevé. Il donne une base pour comparer coût supplémentaire, réduction du risque et contraintes commerciales, selon la méthode du retour sur investissement d’un projet numérique.
Négocier un engagement fournisseur sans copier son chiffre
Le contrat du fournisseur et le SLO interne peuvent couvrir des périmètres différents. Un hébergeur peut mesurer la disponibilité de ses ressources sans garantir que votre application traite correctement une commande. Le mécanisme de compensation contractuelle ne constitue pas non plus une estimation de votre dommage commercial.
Avant une négociation, demandez le point de mesure, la période, les exclusions et le mode de preuve. Vérifiez qui ouvre un incident, dans quel délai et avec quels éléments. Une organisation incapable de retrouver les heures et les ressources concernées peut avoir du mal à faire examiner sa demande, même lorsque l’interruption a été réelle.
N’additionnez pas simplement les pourcentages de plusieurs fournisseurs. L’effet de leurs indisponibilités dépend de l’architecture, des dépendances communes, des mécanismes de secours et du comportement des utilisateurs. Une application possédant un chemin de repli peut continuer à rendre un service limité ; une application entièrement dépendante d’une opération synchrone peut s’arrêter avec elle.
Un exercice utile consiste à demander : « Si cette dépendance disparaît pendant vingt minutes, que voit le client et quelle action peut-il encore réaliser ? » La réponse peut révéler un investissement plus pertinent qu’une montée de gamme générale : mettre en attente une opération, servir une donnée moins fraîche clairement identifiée ou permettre la consultation sans modification.
Ce raisonnement doit être validé par des essais encadrés. Le mode dégradé annoncé sur un schéma peut échouer si les délais d’attente se cumulent ou si l’authentification dépend du service indisponible. Le SLO sert alors à choisir le résultat à protéger, et le test vérifie que la solution proposée le protège effectivement.
Un SLO bien conçu rend finalement trois choses possibles : dire aux métiers ce que l’équipe protège, voir assez tôt quand cette protection se dégrade et choisir une intervention cohérente. Le pourcentage prend sa valeur dans ces décisions. Sans elles, il reste un chiffre rassurant posé au-dessus d’un service que les clients peuvent toujours trouver inutilisable.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
