Les SLA, ou l’art délicat de promettre un service et de décevoir

Les accords de niveau de service, plus connus sous leur acronyme anglais SLA, occupent depuis longtemps une place centrale dans les relations entre directions informatiques, métiers, fournisseurs et prestataires.

Ils rassurent, ils cadrent, ils donnent l’impression que les choses sont maîtrisées.

Sur le principe, rien n’est contestable, une organisation a besoin de savoir ce qu’elle peut attendre d’un service et un fournisseur doit être en mesure d’expliquer ce qu’il s’engage à délivrer.

Une DSI ne peut plus fonctionner sur des promesses implicites ou des arrangements informel et le SLA répond donc à une nécessité réelle : rendre explicite ce qui, trop souvent, reste flou.

Il traduit une attente en engagement, un besoin en indicateur, une relation de confiance en cadre mesurable.

Mais c’est précisément là que se trouve le premier malentendu : parce qu’un SLA est écrit, signé et mesuré, on finit parfois par croire qu’il décrit fidèlement la qualité réelle du service.

Or, il n’en donne qu’une image partielle, un indicateur peut être juste tout en étant insuffisant. Une application peut afficher un excellent taux de disponibilité sur le mois et avoir été indisponible au moment exact où le métier en avait le plus besoin.

Un incident peut avoir été résolu dans les délais prévus, mais au prix d’une communication médiocre, d’un contournement mal compris ou d’une perte de confiance durable chez les utilisateurs.

C’est l’une des grandes limites des SLA : ils mesurent souvent ce qui est facile à mesurer, pas nécessairement ce qui est important à vivre et le délai de prise en charge d’un ticket est une donnée objective.

Le sentiment d’abandon d’un utilisateur qui n’a reçu aucune information pendant plusieurs heures l’est beaucoup moins.

Le danger apparaît lorsque l’indicateur devient plus important que le service lui-même.

Certaines organisations finissent par gérer les SLA comme on gère des compteurs : tant que les chiffres sont dans le vert, le service est réputé satisfaisant.

Cette logique peut produire des situations absurdes : des tableaux de bord impeccables, mais des utilisateurs mécontents, des engagements respectés, mais une perception de qualité dégradée, des équipes persuadées d’avoir bien travaillé, tandis que les métiers estiment ne pas avoir été compris.

Le SLA devient alors un outil défensif.

Le fournisseur explique qu’il a respecté ses obligations, le client répond que le service n’a pas été à la hauteur.

La DSI s’abrite derrière ses indicateurs, les métiers opposent leur vécu.

Cette dérive est d’autant plus fréquente que les systèmes d’information modernes sont devenus profondément interdépendants.

Un service numérique ne repose presque jamais sur un seul composant ni sur une seule équipe, derrière une application apparemment simple se cachent des infrastructures, des réseaux, des bases de données, des flux, des briques d’authentification, des solutions cloud, des prestataires, des processus métiers et des responsabilités parfois éclatées.

Promettre un niveau de service sans comprendre cette chaîne revient à s’engager sur un résultat dont on ne maîtrise pas toujours les conditions de production.

C’est dans les incidents que cette faiblesse apparaît le plus nettement :

L’application est disponible, mais l’authentification ne fonctionne pas.

Le serveur répond, mais le réseau est instable.

Le fournisseur respecte son périmètre contractuel, mais une dépendance interne bloque la résolution.

La DSI s’est engagée sur un délai, mais elle dépend d’un tiers qui n’est pas soumis au même niveau d’exigence, dans ces moments, le SLA révèle moins la solidité du service que les angles morts de sa gouvernance.

Il y a donc une condition préalable trop souvent négligée : avant de promettre, il faut comprendre.

Comprendre les dépendances techniques, bien sûr, mais aussi les dépendances organisationnelles et métiers.

Un SLA pertinent ne peut pas être rédigé uniquement depuis une grille standard ou un modèle contractuel, il doit être construit à partir d’une connaissance fine du système réel, de ses fragilités, de ses points de passage obligés, de ses modes dégradés et de ses impacts potentiels sur l’activité.

Un autre piège réside dans le coût de la promesse.

Tout le monde souhaite des services disponibles, rapides, sûrs et résilients, mais un niveau de service élevé n’est jamais gratuit.

Il suppose des architectures robustes, des dispositifs de supervision, des procédures testées, des équipes formées, des astreintes organisées, des capacités de reprise, des sauvegardes vérifiées et une gouvernance claire.

Plus l’engagement est ambitieux, plus l’organisation doit accepter d’investir pour le tenir.

Or, dans la pratique, les SLA sont parfois rédigés comme des expressions de souhaits.

On exige une disponibilité très élevée sans architecture redondante, on promet une reprise rapide sans exercices réguliers, on annonce une prise en charge quasi immédiate sans équipe dimensionnée pour le faire, on veut du service continu avec une organisation pensée pour les heures ouvrées.

Ce décalage entre l’engagement affiché et les moyens réellement mobilisés crée une fragilité majeure : le SLA cesse d’être un instrument de confiance pour devenir une promesse intenable.