Skip to main content

La gestion des niveaux de service

C’est quoi un niveau de service ?

Un niveau de service (ou SLA, Service Level Agreement), c’est un engagement sur la qualité de service fournie. En clair : ce qu’on promet, et comment on mesure si on tient cette promesse.

Exemple : “Les incidents critiques sont pris en charge en moins de 15 minutes et résolus en moins de 4 heures.”

Pourquoi définir des niveaux de service ?

Sans SLA, tout est urgent et rien ne l’est. On se retrouve à :

  • Traiter les demandes selon l’insistance du demandeur
  • Ne pas savoir si on fait du bon travail
  • Ne pas pouvoir justifier des besoins en ressources

Avec des SLA :

  • Les priorités sont claires
  • Les attentes sont alignées (IT et métiers)
  • On peut mesurer et améliorer

Les composants d’un SLA

1. Le périmètre

Quels services sont couverts ?

  • La messagerie
  • L’ERP
  • Le réseau
  • Les postes de travail

2. Les indicateurs (KPI)

Comment mesure-t-on la qualité ?

IndicateurDescriptionExemple
Disponibilité% de temps où le service fonctionne99,5%
Temps de réponseDélai de prise en charge< 15 min (critique)
Temps de résolutionDélai de résolution< 4h (critique)
Taux de résolution au 1er contactIncidents résolus immédiatement> 70%

3. Les niveaux de priorité

Tous les incidents ne méritent pas la même réactivité.

PrioritéImpactTemps de réponseTemps de résolution
CritiqueService indisponible pour tous15 min4h
HauteService dégradé ou indisponible pour un groupe30 min8h
MoyenneImpact limité, contournement possible2h24h
BasseGêne mineure4h72h

4. Les plages horaires

Les engagements s’appliquent-ils 24/7 ou en heures ouvrées ? C’est fondamental car ça change tout.

Plages courantes :

PlageHorairesHeures/semaineHeures/an
9x58h-17h, lun-ven45h2 340h
10x58h-18h, lun-ven50h2 600h
12x67h-19h, lun-sam72h3 744h
24x7Tout le temps168h8 760h

Un incident critique un dimanche à 3h du matin, c’est différent si on a une astreinte ou non. Et surtout : les SLA ne s’appliquent que pendant les plages définies.

Important : si le SLA est en 9x5 et qu’un incident arrive le vendredi à 16h55, le compteur s’arrête à 17h et reprend le lundi à 8h. Les temps de résolution annoncés sont en heures ouvrées, pas en heures calendaires.

Mettre en place des SLA

Étape 1 : Identifier les services critiques

Tous les services n’ont pas besoin du même niveau d’engagement. La messagerie est probablement plus critique que l’imprimante de la salle de pause.

Étape 2 : Définir des objectifs réalistes

Un SLA qu’on ne peut pas tenir est pire que pas de SLA du tout. Commencer modestement et améliorer progressivement.

Disponibilité 99,9% ça paraît bien, mais qu’est-ce que ça représente concrètement ? Ça dépend de la plage horaire de référence.

En 24x7 (8 760 heures/an) :

DisponibilitéIndisponibilité max/anIndisponibilité max/mois
99%87h36 (3,65 jours)7h18
99,5%43h48 (1,83 jours)3h39
99,9%8h4643 min
99,99%52 min4 min

En 9x5 (2 340 heures/an) - le plus courant en entreprise :

DisponibilitéIndisponibilité max/anIndisponibilité max/mois
99%23h241h57
99,5%11h4258 min
99,9%2h2012 min
99,99%14 min1 min

La différence est significative : 99% en 24x7 autorise 87 heures d’indisponibilité par an. En 9x5, seulement 23 heures.

Avantage du 9x5 : les maintenances planifiées peuvent être effectuées la nuit ou le week-end, hors plage SLA. Une mise à jour qui nécessite 2h d’arrêt le dimanche matin n’impacte pas les engagements.

Inconvénient du 9x5 : les pannes non planifiées surviennent souvent en journée, quand le système est sollicité. Si toutes les pannes tombent en heures ouvrées, la marge de 23 heures est vite consommée.

Attention : une panne hors plage ne compte pas dans les SLA, mais les utilisateurs qui travaillent occasionnellement le week-end s’en souviendront quand même.

Étape 3 : Mesurer

Sans mesure, pas de SLA. Il faut :

  • Un outil de ticketing qui trace les temps (GLPI, par exemple)
  • Un outil de supervision pour la disponibilité
  • Des rapports réguliers

Étape 4 : Communiquer

Les SLA doivent être connus de tous :

  • L’équipe IT (pour les respecter)
  • Les utilisateurs (pour savoir à quoi s’attendre)
  • La direction (pour arbitrer si nécessaire)

Les erreurs classiques

  • SLA irréalistes : promettre 99,99% sans les moyens qui vont avec
  • Pas de mesure : on a des SLA sur le papier, mais personne ne vérifie
  • Trop de complexité : 15 niveaux de priorité et 47 catégories → personne ne s’y retrouve
  • Oublier les dépendances : promettre 99,9% sur un service qui dépend d’un hébergeur qui garantit 99%
  • SLA punitifs : les SLA servent à s’améliorer, pas à sanctionner

SLA internes vs externes

SLA externes : engagement contractuel avec un client ou un fournisseur. Souvent avec pénalités financières.

SLA internes : engagement entre l’IT et les métiers. Pas de pénalités, mais une question de crédibilité et de confiance.

Les deux sont importants. Les SLA internes sont souvent négligés, alors qu’ils structurent le travail au quotidien.

Dans GLPI

GLPI permet de configurer des SLA :

  1. Administration > Niveaux de service
  2. Créer un SLA avec les temps cibles
  3. Associer le SLA aux catégories de tickets
  4. Les tickets affichent automatiquement le temps restant
  5. Rapports disponibles pour suivre le respect des engagements

En résumé

  1. Définir les services couverts et les priorités
  2. Fixer des objectifs réalistes et mesurables
  3. Mesurer systématiquement
  4. Communiquer les engagements et les résultats
  5. Améliorer en continu

Les SLA ne sont pas une contrainte bureaucratique. C’est un outil pour professionnaliser le service IT et aligner les attentes de tous.