SLA informatique : comprendre les niveaux de service

Qu'est-ce qu'un SLA ?

Le SLA (Service Level Agreement, ou « accord de niveau de service ») est la partie du contrat qui transforme les promesses commerciales en engagements mesurables. Il répond à trois questions : en combien de temps le prestataire prend-il en charge un incident, en combien de temps le résout-il, et quel taux de disponibilité garantit-il pour vos systèmes ?

Sans SLA, « nous sommes très réactifs » ne vous protège de rien. Avec un SLA, un retard se constate, se mesure et déclenche des pénalités. C'est pourquoi le SLA est l'une des annexes les plus importantes d'un contrat d'infogérance.

GTI et GTR : les deux délais à ne pas confondre

GTI : garantie de temps d'intervention

La GTI est le délai maximal entre votre signalement et le début effectif du traitement par un technicien. Une GTI de 30 minutes signifie qu'un technicien commence à travailler sur votre incident dans la demi-heure — pas qu'il l'a résolu.

GTR : garantie de temps de rétablissement

La GTR est le délai maximal de retour à un fonctionnement normal (ou dégradé mais opérationnel, selon la rédaction — vérifiez ce point). Une GTR de 4 heures sur un serveur critique signifie que le service est rétabli dans les 4 heures suivant le signalement.

Attention à trois subtilités de lecture :

• Heures ouvrées ou heures calendaires ? Une GTR de 4 heures ouvrées sur une panne survenue vendredi à 17h peut vous mener à lundi midi.
• Point de départ du chrono : à la création du ticket, ou à sa qualification par le prestataire ? La seconde formulation laisse une zone grise.
• Classification des incidents : les délais varient selon la criticité (critique, majeur, mineur). Vérifiez qui décide de cette classification et selon quels critères.

Des GTI/GTR courtes supposent une supervision permanente : un prestataire qui détecte la panne avant vous tient plus facilement ses délais.

Taux de disponibilité : ce que valent réellement les « 9 »

Le taux de disponibilité exprime le pourcentage du temps pendant lequel un service fonctionne. La différence entre 99 % et 99,9 % paraît minime ; en heures d'arrêt, elle est énorme :

Disponibilité	Indisponibilité max/an	Indisponibilité max/mois
99 %	≈ 3 jours et 15 heures	≈ 7 heures 18 min
99,5 %	≈ 1 jour et 20 heures	≈ 3 heures 39 min
99,9 %	≈ 8 heures 46 min	≈ 44 minutes
99,99 %	≈ 53 minutes	≈ 4 minutes

Deux réflexes de lecture : d'abord, vérifiez le périmètre de la mesure — un hébergeur peut afficher 99,99 % sur son infrastructure alors que votre application, elle, tombe pour d'autres raisons. Ensuite, vérifiez si les maintenances planifiées sont exclues du calcul : c'est courant, et cela peut représenter plusieurs heures par mois. Ce point compte particulièrement pour vos services hébergés et cloud.

Pénalités : un SLA sans sanction n'engage personne

Les pénalités donnent sa force au SLA. En pratique, elles prennent la forme d'avoirs : un pourcentage de la mensualité par tranche de dépassement, souvent plafonné entre 10 et 30 % de la facture mensuelle. Points à vérifier :

• Automaticité : les pénalités s'appliquent-elles de plein droit, ou devez-vous les réclamer par courrier recommandé dans un délai court ?
• Plafond : un plafond trop bas (5 % de la mensualité) vide la clause de son effet dissuasif.
• Libératoire ou non : une pénalité « libératoire » exclut tout autre recours, même si la panne vous a coûté bien plus. À négocier pour les incidents graves.
• Reporting : exigez un rapport mensuel ou trimestriel des temps de réponse constatés. Sans mesure partagée, pas de pénalité applicable.

Erreur fréquente : exiger partout les SLA les plus stricts. Une GTR d'1 heure en 24/7 sur l'ensemble du parc coûte très cher. Réservez les engagements forts aux systèmes réellement critiques, identifiés par exemple lors d'un audit informatique, et acceptez des délais standards sur le reste : c'est le meilleur levier pour maîtriser le budget.