SLA/OLA réalistes : comment arrêter les KPI cosmétiques

Il y a une scène qui se rejoue dans beaucoup d’organisations : un tableau de bord “qualité de service” qui brille en comité, des pourcentages à 99,x qui rassurent, et pourtant des utilisateurs qui continuent de dire “ça rame”, “ça tombe”, “personne ne répond”. À la fin, tout le monde a l’impression d’avoir raison. Les équipes IT parce que les KPI sont au vert. Les métiers parce que l’expérience, elle, est au rouge.

Ce décalage a un nom : les KPI cosmétiques. Des indicateurs qui ont l’air sérieux mais ne mesurent pas ce qui compte. Et il a une cause : des SLA/OLA mal construits, trop génériques, trop politiques, ou trop déconnectés des vrais parcours utilisateurs.

Un SLA n’est pas un poster de bonnes intentions. C’est un contrat de réalité. Un OLA n’est pas un document interne “pour faire joli”. C’est la mécanique qui rend le SLA tenable. Tant qu’on mélange communication et pilotage, on fabrique des chiffres qui apaisent… jusqu’au jour où l’incident qui compte vraiment arrive.

Pourquoi les SLA “par défaut” fabriquent du faux vert

Le SLA classique, c’est souvent : disponibilité 99,9 %, temps de prise en charge, temps de résolution, parfois un NPS ou un “taux de satisfaction”. Sur le papier, c’est propre. Dans les faits, le vert vient de trois astuces involontaires.

La première : on mesure ce qui est facile à mesurer. La disponibilité d’un composant, pas la disponibilité d’un service. Un serveur, pas un parcours. Un lien, pas un usage. Résultat : tout marche “techniquement”, mais l’utilisateur ne peut pas finaliser son action parce qu’une brique intermédiaire, une dépendance, un DNS, une identité ou une API est en panne.

La deuxième : on moyenne les douleurs. Un 99,9 % peut cacher des coupures très visibles si elles tombent aux mauvais moments. Un service peut être “up” 99,9 % du temps et être inutilisable à cause de latence, de dégradations intermittentes ou de saturation. Les métiers ne vivent pas la moyenne, ils vivent le pic.

La troisième : on s’arrange avec le périmètre. On exclut les incidents “hors SLA”, on recatégorise, on ferme un ticket et on en ouvre un autre, on joue sur la définition de “résolu”. Souvent ce n’est même pas de la mauvaise foi : c’est la conséquence naturelle d’un cadre mal défini, où chacun protège son territoire.

SLA vs OLA : le malentendu qui détruit la crédibilité

Le SLA est l’engagement vis-à-vis du client interne (ou externe). Il répond à une question simple : “qu’est-ce que je peux attendre de ce service ?”. L’OLA est interne : il décrit comment les équipes entre elles rendent le SLA possible. Il répond à une autre question : “qui fait quoi, en combien de temps, avec quelles dépendances ?”.

Le problème typique, c’est d’écrire des SLA ambitieux sans OLA réalistes. Exemple : “résolution P1 en 4 heures”. Très bien. Mais si l’infra dépend d’un prestataire N1 qui escalade en 2 heures, et d’un éditeur qui répond en 8 heures, ce SLA est un mensonge structurel. Il ne pilote rien : il génère de la frustration et pousse les équipes à “faire rentrer” le réel dans des cases.

À l’inverse, certains OLA sont des listes de tâches sans liens avec les résultats métiers. Tout le monde exécute, personne ne comprend ce qui est prioritaire. La clé est là : le SLA doit être écrit côté valeur, l’OLA côté mécanique, et les deux doivent être mathématiquement compatibles.

Arrêter les KPI cosmétiques : commencer par mesurer l’expérience, pas les composants

La bascule la plus efficace est conceptuelle : passer des indicateurs “techniques” à des indicateurs “service”. Cela ne veut pas dire abandonner le technique, mais l’ordonner.

Un service, ce n’est pas un serveur. C’est un usage. Et un usage, ça se décrit : “ouvrir sa session”, “envoyer un mail”, “accéder à un dossier partagé”, “valider une commande”, “sortir une étiquette”, “rendre un résultat”, “télécharger un document”. Les SLA utiles s’alignent sur ces parcours.

Concrètement, plutôt qu’une disponibilité globale, on définit des SLI (Service Level Indicators) qui parlent de réalité : taux de succès d’authentification, temps de réponse médian et P95, taux d’erreurs applicatives, disponibilité d’une API critique, délai de synchronisation, taux de réussite d’une sauvegarde restaurable. Ce sont des métriques qui permettent d’expliquer un incident et de prévenir le suivant.

Le KPI cosmétique dit “on est bons”. Le KPI utile dit “voici ce qui casse, quand, et pourquoi”.

Le piège des SLA “universels” : il faut des classes de service, pas un SLA pour tout

L’une des raisons des SLA absurdes, c’est l’idée qu’il faudrait un SLA unique “pour l’IT”. Or tout n’a pas la même valeur, ni le même coût de protection.

Un poste bureautique n’a pas le même enjeu qu’un service de production. Un outil de collaboration n’a pas le même impact qu’un dispositif patient critique. La maturité commence quand on accepte de dire : certains services ont un niveau d’exigence plus élevé, donc un coût plus élevé, donc une gouvernance plus stricte.

C’est là qu’intervient la notion de classes de service. Par exemple : critique, important, standard. Chacune avec ses engagements, ses fenêtres de maintenance, ses priorités, ses niveaux d’astreinte, et ses budgets implicites. Ce n’est pas qu’un choix IT : c’est un arbitrage métier, assumé, documenté.

Sans classes de service, vous finissez avec deux options : soit vous promettez trop à tout le monde (et vous échouez), soit vous promettez peu (et vous perdez la confiance). Les classes de service permettent une troisième voie : promettre juste, et tenir.

Un SLA réaliste se construit avec un “budget d’erreur”, pas avec une incantation

Il y a une idée simple, rarement utilisée dans les environnements classiques : accepter que l’objectif n’est pas “zéro incident” mais “incident maîtrisé”. Cela se traduit par un budget d’erreur : combien d’indisponibilité, d’erreurs, de latence excessive est acceptable sur une période donnée, avant de déclencher une action correctrice (gel de changements, plan de fiabilisation, montée de version, refonte d’un composant).

C’est puissant parce que cela reconnecte l’indicateur à la décision. Un KPI sans conséquence est cosmétique. Un KPI qui déclenche un arbitrage devient un outil de pilotage.

Le budget d’erreur a aussi une vertu politique : il oblige à discuter du niveau de risque accepté par le business. Et quand le business choisit, l’IT n’est plus seule à porter la promesse.

L’OLA : la partie qu’on oublie, et qui fait exploser les engagements

Un OLA réaliste n’est pas un organigramme déguisé. C’est une chaîne de responsabilité. On y décrit les dépendances et les délais d’escalade : N1, N2, N3, éditeurs, infogérants, réseau, sécurité, exploitation, équipes produit. Et surtout : les points de friction.

Si un incident P1 doit être résolu en 4 heures, l’OLA doit être écrit à rebours : combien de temps pour détecter, qualifier, escalader, engager l’éditeur, obtenir un contournement, communiquer. Et si ce n’est pas tenable, il faut changer la promesse ou changer la mécanique. Tout le reste est du storytelling.

Un bon OLA clarifie aussi les responsabilités en période de crise : qui est incident manager, qui décide d’un rollback, qui valide un contournement risqué, qui communique aux métiers, qui tient la timeline. Sans ça, les KPI deviennent un théâtre : on “poursuit les chiffres” au lieu de résoudre.

Les deux KPI qui tuent les KPI cosmétiques

Si vous voulez aller vite, il y a deux indicateurs qui font souvent tomber les masques.

Le premier : le temps de rétablissement utilisateur (pas le temps de “résolution technique”). Quand l’utilisateur retrouve un service utilisable, même via un contournement, c’est cela qui compte. Mesurer ce délai oblige à travailler la continuité et les plans B, pas seulement la réparation parfaite.

Le second : le taux de récidive. Combien d’incidents reviennent, sous une forme similaire, parce qu’on a “corrigé” sans traiter la cause ? Si le taux de récidive est élevé, alors vos KPI de résolution rapide sont probablement des KPI de fermeture de tickets.

Ces deux KPI réorientent l’organisation : moins de cosmétique, plus de fiabilisation.

Mettre fin au faux vert : une méthode simple en cinq décisions

La première décision : définir 10 à 20 services “vraiment critiques” et écrire des SLA orientés usages pour eux. Pas pour tout. Commencez petit, mais sérieux.

La deuxième : construire les OLA à rebours, en intégrant les délais des fournisseurs. Si l’éditeur répond en 8 heures, arrêtez de promettre 4 heures, ou changez le contrat, ou mettez une capacité de contournement.

La troisième : introduire les classes de service et les budgets d’erreur. Sans arbitrage métier, il n’y a pas de SLA réaliste.

La quatrième : faire évoluer les métriques vers des SLI de parcours, et compléter la disponibilité par de la performance (latence, taux d’erreur, succès d’authentification, etc.). Le “service up mais inutilisable” doit devenir visible.

La cinquième : lier les KPI à des conséquences de pilotage : quand le budget d’erreur est consommé, on bascule en mode fiabilisation. Sinon, on continuera à empiler du changement sur du fragile.

Le vrai bénéfice : récupérer la confiance

Arrêter les KPI cosmétiques, ce n’est pas “faire plus de reporting”. C’est faire moins de théâtre. Un SLA réaliste ne promet pas la lune : il promet quelque chose de compréhensible, mesurable, et tenu. Un OLA réaliste ne fait pas semblant : il décrit la mécanique et ses limites, donc il permet de l’améliorer.

Au fond, un bon SLA/OLA ne sert pas à prouver que l’IT travaille. Il sert à rendre le service prévisible. Et dans une organisation, la prévisibilité vaut plus que tous les pourcentages à 99,9 affichés en vert. Parce que le jour où tout se joue, ce n’est pas le KPI qui vous sauve : c’est la capacité à rétablir vite, à expliquer clairement, et à éviter que ça recommence.