Pandora Tech Blog

Qu’est-ce qu’un SLA et comment le calcule-t-on ?

par | Last updated Aug 20, 2026 | Technologie

Contenu :

Dans l’épisode Reliques de Star Trek : La Nouvelle Génération, La Forge découvre le secret de Scotty et l’origine de sa réputation d’ingénieur capable de faire des miracles dans la légendaire série originale. Lorsque quelqu’un lui demande combien de temps prendra une réparation, il multiplie son estimation réelle par quatre. S’il termine plus tôt, le génie a encore frappé et, si les choses se compliquent, il parvient malgré tout à respecter le délai annoncé. C’est la vieille astuce de l’IT qui devient inutilisable dès que quelqu’un inscrit cette promesse dans un document à côté d’un chiffre. Ce document est le SLA, le Service Level Agreement ou accord de niveau de service.

Il définit trois éléments :

  • Quel niveau de service est attendu de ce que nous fournissons.
  • Comment il est mesuré.
  • Ce qui se passe s’il n’est pas respecté.

Ainsi, le SLA devient la « loi » que toute organisation fournissant des services doit respecter dans la gestion IT pour quelqu’un d’autre… et il nous empêche d’improviser comme Scotty et de passer pour des génies, en nous obligeant à respecter ce qui y est indiqué.
C’est pourquoi nous allons examiner de près ces lois de notre domaine professionnel, puisque les bénéfices en dépendent.

Qu’est-ce qu’un SLA ?

Comme toujours, il faut commencer par ouvrir le dictionnaire, et un SLA est l’accord dans lequel un fournisseur et un client définissent le niveau de service convenu ainsi que la manière de vérifier son respect.
« Physiquement », il peut prendre la forme d’une annexe contractuelle, d’un document interne entre le département IT et le reste de l’entreprise ou d’une page de deux paragraphes dans la proposition d’un intégrateur.
Ce sont les conditions exprimées de manière mesurable, et non un tampon d’avocat, qui transforment un document en SLA. Ainsi, tout SLA un minimum sérieux définira :

  • Services inclus. Messagerie d’entreprise, application de facturation, mise à disposition d’un environnement e-commerce… Il peut inclure pratiquement n’importe quoi, mais plus le périmètre est flou, plus les discussions seront nombreuses lors de la première panne inévitable.
  • Niveau de service attendu. Par exemple, une disponibilité mensuelle de 99,9 %, une première réponse aux incidents critiques sous 30 minutes, une latence inférieure à un certain seuil… L’indicateur concret dépend du contexte, mais il doit être défini d’un commun accord.
  • Comment il est mesuré. Depuis quel point, à quelle fréquence et quel outil collecte la vérité chiffrée. Sans cela, le SLA n’est que de la littérature, rien de plus.
  • Sur quelle période. Mensuelle, trimestrielle, annuelle… La période modifie le résultat bien plus qu’il n’y paraît, comme nous le verrons plus loin avec des chiffres.
  • Responsabilités de chaque partie. Y compris celles du client, qui oublie souvent que l’ouverture d’un ticket avec suffisamment d’informations fait également partie de l’accord. Ainsi, le jeu des responsabilités fonctionne dans les deux sens et ne vise pas uniquement le responsable technique.
  • Conséquences en cas de non-respect. Un SLA est un « pacte de sang », pas le journal de nos bonnes intentions. Il inclut donc des conséquences réelles lorsqu’il n’est pas respecté. Les plus courantes sont des pénalités, des remises, un plan d’action ou une révision du service.

Voyons un exemple simple.
Nous faisons appel à un MSP (fournisseur de services managés) pour gérer nos serveurs virtualisés et le SLA signé indique que :

  • L’infrastructure sera disponible 99,9 % du temps chaque mois.
  • Les incidents critiques seront pris en charge en 30 minutes ou moins, 24×7.
  • Les fenêtres de maintenance seront annoncées 72 heures à l’avance.
  • Un rapport mensuel contenant les données sera fourni.

Grâce à cela, la discussion s’articule autour d’indicateurs tangibles plutôt que d’impressions subjectives.

À quoi sert un SLA ?

À permettre aux deux parties de discuter en se lançant des données à la figure plutôt que des perceptions, une bataille que personne ne gagne jamais, mais aussi à optimiser la relation et le travail.
Ainsi, le SLA fournit au prestataire un critère objectif pour assurer son service. Il sait ce qu’il doit maintenir, peut dimensionner correctement son équipe et dispose d’arguments solides lors de ces appels du type « ça fonctionne lentement », lorsque les données montrent que le service a été disponible 99,97 % du mois, au-dessus des 99,9 % définis dans le SLA de l’exemple.
Sans SLA, les attentes du client augmentent jusqu’à l’infini et au-delà, pour toujours finir par : « Pourtant, je pensais que c’était inclus. »
De l’autre côté de la tranchée, le client sait clairement ce qu’il peut attendre et, surtout, comment le vérifier.
Cela concerne principalement les fournisseurs de services managés (MSP), car leur produit est précisément le niveau de service.
Tout cela concerne également les départements IT internes car, même en l’absence de pénalités financières, un SLA évite que les priorités technologiques soient définies par le ticket qui crie le plus fort.

Ce qu’un SLA inclut généralement

Il est impossible de couvrir toutes les exigences qui ont un jour été incluses dans un accord de ce type, mais certains éléments reviennent encore et encore dans les SLA, et leur absence peut coûter cher.

  • Le périmètre du service. Autrement dit, quels systèmes, applications et composants sont inclus et lesquels ne le sont pas, ce qui est tout aussi important.
  • La disponibilité garantie. Exprimée en pourcentage, avec sa période de mesure et sa méthode de calcul (nous verrons un exemple).
  • Les horaires de couverture. Car même si le client manque parfois de discernement pour distinguer ces éléments, promettre du « 24×7 » n’est pas la même chose que promettre du « lundi au vendredi de 9 h à 18 h ». De nombreux manquements apparents sont en réalité des incidents ouverts en dehors des horaires convenus dans le SLA.
  • Délai de première réponse. Ou combien de temps il faut à quelqu’un pour prendre en charge l’incendie qui vient de se déclarer.
  • Délai de résolution. Combien de temps il faut pour éteindre l’incendie précédent et remettre le service en fonctionnement. Attention, car confondre ce point avec le précédent est un grand classique. Il est donc important de bien les distinguer dans le SLA.
  • Priorités et classification. Avec des critères permettant de déterminer ce qui est critique, élevé, moyen ou faible, accompagnés d’exemples concrets. Sinon, il n’existe qu’une seule classification pour le client : « tout est critique ».
  • Maintenances programmées. Elles déterminent les fenêtres prévues, le délai de préavis et si elles sont prises en compte dans le calcul de la disponibilité du SLA, encore un de ces détails apparemment anodins qui font toute la différence.
  • Méthode de mesure et rapports. En définissant quel outil génère les données, avec quelle granularité et sous quel format elles sont fournies.
  • Conséquences en cas de non-respect. Et s’il s’agit de compensations financières, de remises futures, de révisions du service, d’un plan d’amélioration signé…
  • Procédure d’escalade. Que se passe-t-il lorsque le premier niveau ne dispose pas d’un extincteur suffisamment grand ? Il faut définir cette escalade avec des noms, des canaux et des délais.
  • Exclusions. Comme les cas de force majeure, les défaillances de tiers, les interruptions de l’opérateur ou les modifications demandées par le client lui-même.

    • Ces exclusions méritent leur propre paragraphe, car elles constituent la partie du document qui ressemble le plus à la patte de singe d’Homer dans Les Simpson, un épisode dans lequel les souhaits se réalisent exactement comme ils sont formulés et jamais comme on l’espérait.

Il est essentiel de comprendre qu’un SLA comportant des exclusions imprécises accorde littéralement ce qui est écrit, et non ce que nous avions imaginé. Ainsi, si l’accord exclut les « incidents causés par des tiers » formulés exactement de cette manière, alors le fournisseur cloud, l’opérateur Internet ou le fabricant du pare-feu sont des tiers et presque n’importe quelle panne peut passer par cette porte.
Des cadres de travail comme ITIL dans la gestion des services IT structurent ces éléments depuis des années. Il est donc judicieux de s’appuyer sur eux, ne serait-ce que pour éviter de réinventer la fastidieuse roue de la classification des priorités chaque fois que nous signons un contrat.

Métriques courantes dans un SLA

Commençons par clarifier LE malentendu le plus répandu sur le sujet, car un SLA ne se résume pas à un pourcentage de disponibilité entouré d’un contrat pour remplir la page. Cette disponibilité n’est qu’une métrique parmi d’autres et, pour de nombreux services, ce n’est même pas celle qui décrit le mieux l’expérience réelle de l’utilisateur.
C’est pourquoi les métriques que nous retrouverons le plus souvent dans un SLA sont :

  • Disponibilité ou uptime. Elle est calculée comme le pourcentage de temps pendant lequel le service est resté opérationnel au cours de la période définie, mensuelle ou autre.
  • Délai de première réponse. Comme nous l’avons vu précédemment, il s’agit du temps écoulé entre l’ouverture du ticket et le moment où un technicien prend le dossier en charge. Les SLA intelligents comprennent qu’il s’agit de la métrique que l’utilisateur perçoit le plus, et la perception est ce qui compte le plus dans ce monde obsédé par les apparences, car le silence face à une demande d’aide est ce qui devient réellement insupportable.
  • Délai de résolution. Depuis l’ouverture de l’incident jusqu’au rétablissement du service.
  • MTTR. Qui signifie Mean Time To Repair, c’est-à-dire le temps moyen de réparation sur une période donnée. Il nous donne une image de la capacité réelle de l’équipe dans la durée, plutôt que sur des cas isolés.
  • Latence ou performance. Essentielle pour les applications web, les API ou les services de données, car un système qui répond en huit secondes peut être techniquement disponible tout en étant pratiquement inutilisable.
  • Taux d’incidents. Il mesure combien d’incidents sont ouverts par période et de quel type. Cela permet notamment de détecter si le problème relève de l’exploitation ou de la conception.
  • Pourcentage de conformité. En calculant quelle proportion des incidents a été prise en charge et résolue dans les délais convenus.

Comme c’est souvent le cas dans le monde réel, c’est la combinaison de plusieurs métriques qui rend un SLA réellement utile. Un service peut respecter son objectif de disponibilité de 99,9 % et malgré tout être un désastre si, à chaque panne, personne ne répond pendant six heures.

SLA et uptime : différences

J’ai évoqué précédemment une confusion fréquente consistant à prendre « la partie pour le tout » lorsque nous parlions de disponibilité et de SLA, et c’est encore un de ces sujets qui mérite sa propre section.
L’uptime ou disponibilité est une donnée que l’on supervise, une « partie » du « tout » qu’est le SLA, mais ce n’est pas le SLA lui-même. Celui-ci correspond à l’accord complet qui inclut l’uptime comme l’une de ses métriques, avec les délais de réponse, de résolution, les horaires de couverture et tout le reste de ce que nous avons analysé.
Cela dit, parmi les indicateurs du SLA, la disponibilité est généralement reine. Il est possible de mesurer et de gérer l’uptime sans SLA et, de fait, c’est une pratique courante dans toute opération IT, mais disposer d’un SLA sans avoir la capacité de mesurer l’uptime revient à signer un chèque sans regarder le solde du compte.

Comment calculer un SLA

Même si les métriques d’un accord de niveau de service vont au-delà de la disponibilité du service souscrit, presque tout s’articule autour de celle-ci et c’est le premier élément à prendre en compte dans le calcul d’un SLA.
Dans ce cas, et sans que cela fasse jurisprudence dans l’IT, nous n’aurons pas besoin de calculs dignes de la NASA, car un peu d’arithmétique élémentaire suffira :

Disponibilité = (temps disponible / temps total mesuré) × 100

Appliquons cette formule à un exemple. Un mois de 30 jours représente 720 heures, soit 43 200 minutes. Si le service a été indisponible pendant 65 minutes, alors :
Disponibilité = (43 200 − 65) / 43 200 × 100 = 99,85 %
Avec un engagement de 99,9 %, il y a non-respect ce mois-là, car la marge correspondant à 99,9 % sur un mois de 30 jours est d’environ 43,2 minutes, alors qu’ici nous en avons consommé 65.
Cependant, analysons maintenant la partie intéressante, qui montre pourquoi il est essentiel de définir précisément la disponibilité dans le SLA.
Supposons que 30 de ces 65 minutes se soient produites pendant une fenêtre de maintenance programmée de deux heures, annoncée à l’avance et exclue du calcul conformément à l’accord.
Dans ce cas, le temps total mesuré descend à 43 080 minutes (après avoir retiré les deux heures de la mesure, soit 120 minutes) et l’indisponibilité prise en compte dans le SLA tombe à 35 minutes :
(43 080 − 35) / 43 080 × 100 = 99,92 %

Même mois, mêmes interruptions, mais cette fois le résultat passe du non-respect au respect.
Dans cet exemple, il n’y aurait aucune astuce de la part du prestataire et le SLA l’indique clairement. C’est pourquoi les clauses détaillées concernant les exclusions et les fenêtres de maintenance ont autant de poids que le pourcentage lui-même, et c’est aussi pourquoi il est intéressant de voir comment les grandes entreprises rédigent ces accords, depuis les accords de niveau de service d’AWS jusqu’aux SLA des services en ligne de Microsoft, où le mode de calcul, les exclusions et la procédure de réclamation occupent davantage de place que le chiffre de disponibilité lui-même.
À titre indicatif, voici ce que chaque pourcentage représente en temps d’indisponibilité autorisé, en prenant comme référence des mois de 30 jours et des années de 365 jours :

Disponibilité

Par mois

Par an

99 %

7 h 12 min

3 jours 15 h 36 min

99,9 %

43 min 12 s

8 h 45 min 36 s

99,99 %

4 min 19 s

52 min 34 s

On comprend alors pourquoi chaque neuf supplémentaire multiplie le prix. Passer de 99 % à 99,9 % relève d’une exploitation rigoureuse, mais passer de 99,9 % à 99,99 % exige une véritable redondance, un basculement automatique et une équipe capable de réagir dans une enveloppe de seulement quatre minutes d’interruption par mois.
C’est là que trop de commerciaux promettent ce neuf supplémentaire qui, aux yeux d’un public non technique, peut sembler anodin, mais que notre infrastructure peut très facilement être incapable de garantir.
Les autres métriques du SLA sont évaluées par rapport aux cas traités plutôt qu’au temps de fonctionnement du service, comme les incidents que nous avons pris en charge dans le délai convenu (divisés par le total puis multipliés par cent). Dans ces cas, l’arithmétique est la même, même si l’on compte les galères plutôt que les minutes.

Exemple pratique de SLA dans l’IT

Pour rendre tous ces concepts plus concrets, examinons un accord type pour une application métier, résumé dans son tableau de conditions.

Concept

Engagement

Service

Application de gestion d’entreprise

Disponibilité

99,9 % par mois

Première réponse (critique)

30 minutes

Objectif de résolution (critique)

4 heures

Couverture des incidents critiques

24×7

Maintenance programmée

Fenêtre mensuelle annoncée 72 h à l’avance, exclue du calcul

Rapport

Mensuel, avec le détail des interruptions et des incidents

Ce tableau nous apprend qu’aucune de ses lignes ne signifie grand-chose prise séparément.
Par exemple, ces 99,9 % sans couverture 24×7 laissent les nuits sans protection. De même, un délai de résolution de quatre heures sans définition claire de ce que signifie ce « critique » entre parenthèses se transforme en négociation chaque fois que le téléphone sonne.
L’essentiel est qu’un SLA forme un ensemble et fonctionne lorsque toutes ses conditions vont dans la même direction.

SLA de support et délais de réponse

Dans les environnements de support et de helpdesk, nous avons un exemple très clair de la manière dont l’attention d’un SLA se déplace de la disponibilité vers les délais, avec quatre concepts qu’il vaut mieux ne pas confondre.

  • Première réponse. Le délai avant qu’un technicien confirme la prise en charge de l’incident et en assume la responsabilité. Attention, car cela n’implique pas une résolution, seulement que quelqu’un a pris le volant de la voiture qui fonce dans le ravin.
  • Réponse pendant le cycle de l’incident. Examinons la métrique oubliée qui évite le plus de réclamations et qui définit à quelle fréquence l’état de l’incident est mis à jour tant qu’il reste ouvert. Le client veut sentir que la personne au volant fait autre chose que simplement le tenir.
  • Délai de résolution. Le temps qui s’écoule jusqu’à ce que le service soit de nouveau opérationnel, avec ou sans solution définitive. Il convient de distinguer une solution temporaire d’une clôture complète, car le client ne les perçoit pas de la même manière.
  • Escalade. Le moment où un incident passe au niveau supérieur, la personne à qui revient le problème et le processus automatique qui met cette escalade en œuvre, car si l’escalade dépend du fait que quelqu’un s’en souvienne… alors ce n’est pas vraiment une escalade.

En outre, tout cela doit s’appuyer sur un système de priorités, faute de quoi le prestataire de services IT passera son temps à courir comme un poulet sans tête.
La méthode habituelle consiste à croiser l’impact (combien de personnes ou quelle part de l’activité est affectée) avec l’urgence (combien de temps quelque chose peut attendre avant que tout ne commence à s’effondrer) afin d’obtenir le niveau. Nous associerons ensuite des délais à chaque niveau.
C’est à ce moment qu’un outil de gestion des incidents et des SLA cesse d’être un luxe, car les compteurs doivent fonctionner automatiquement dans le système de tickets, se mettre en pause lorsque l’incident est en attente d’informations du client et envoyer des alertes avant l’expiration du délai.

Différence entre SLA, SLO et SLI

Une seule lettre fait toute la différence. Zara a réussi à faire annuler l’enregistrement de la marque Zora en Inde en raison de leur ressemblance, susceptible de semer la confusion chez les acheteurs, tandis que Google s’est empressé de réserver des domaines comme « Goggle » afin d’éviter que le trafic issu de fautes de frappe ne soit redirigé vers des domaines malveillants ou contenant de la publicité trompeuse.
Il en va de même ici avec trois sigles que l’on confond à cause de cette unique voyelle, mais pour éviter cela…

  • SLI (Service Level Indicator ou indicateur de niveau de service) : il s’agit de l’indicateur mesuré, de la donnée brute, comme le pourcentage de requêtes traitées correctement.
  • SLO (Service Level Objective ou objectif de niveau de service) : il s’agit de l’objectif interne que l’équipe souhaite atteindre.
  • SLA : ce que nous avons déjà vu, à savoir l’engagement convenu avec le client et les conséquences qui y sont associées.

La règle pratique veut que le SLO soit toujours plus exigeant que le SLA, afin que l’IT dispose d’une marge de réaction avant de ne plus respecter ce qui a été promis.
Tout cela découle de la pratique du Site Reliability Engineering, que Google a formalisée dans son chapitre consacré aux objectifs de niveau de service, un sujet qui pourrait être développé bien davantage que ce que je peux faire ici sans transformer cet article en tome perdu de Harry Potter.
Pour ceux qui souhaitent consulter l’explication complète, elle se trouve dans notre guide sur les différences entre SLA, SLO et SLI.

Comment superviser le respect d’un SLA

Un SLA que l’on vérifie à la fin du mois en demandant autour de soi comment les choses se sont passées est une enquête de satisfaction, mais pour paraphraser Malraux de manière (très) libre, le respect doit être continu ou ne sera pas, et sa mesure doit elle aussi être ininterrompue.
Cela implique plusieurs choses, et toutes en même temps.

  • Il faut mesurer la disponibilité en permanence et depuis un point pertinent, car vérifier un service web depuis le même centre de données qui l’héberge revient à faire corriger un examen par l’élève qui l’a passé.
  • Il est nécessaire de consigner les incidents avec des horodatages fiables pour l’ouverture, la prise en charge, l’escalade et la clôture.
  • Il faut conserver les données historiques, car les données d’un seul mois ne permettent pas de détecter une dégradation progressive.
  • Comme tout cela vise à améliorer la gestion et ne relève pas uniquement de la vanité, des alertes sont indispensables afin de se déclencher lorsque la marge restante approche de la limite.

Une fois la supervision des serveurs et de l’infrastructure mise en place, le respect devient un calcul automatique par période et le rapport cesse d’être une pénible tâche manuelle au 30e jour du mois.
Et voici un autre détail souvent négligé : le système de supervision peut lui aussi tomber en panne.
Si notre vigie devient aveugle pendant deux heures, cette période doit être interprétée d’une manière ou d’une autre et il convient de décider à l’avance si elle compte comme indisponibilité dans le SLA ou comme donnée inconnue.
Laisser cette période à l’appréciation de la personne qui rédige le rapport est une tentation inutile, car ce qui l’arrange le plus finira par prévaloir au lieu de ce qui reflète le mieux la réalité.

Comment Pandora FMS aide à mesurer les SLA

Nous croyons en Pandora FMS par-dessus tout, car il s’agit de la concrétisation de plus de 20 ans d’expérience, mais rassurez-vous, je ne suis pas commercial et je ne vais pas jouer à l’être. Parlons donc de faits plutôt que de discours de vente.
Pandora FMS aide-t-il à gérer les SLA ?
Absolument oui.
Pandora FMS permet de calculer le respect des SLA à partir de données objectives collectées depuis l’infrastructure.
Pour Pandora, il n’existe aucune couche supplémentaire de maquillage, et il n’en ajoute aucune, ce qui permet d’extraire la vérité qui compte pour les deux signataires du contrat de service. Ainsi, Pandora FMS joue le rôle de vigie, analyste, référentiel et notaire.
Les rapports SLA nous permettent de définir l’objectif, que ce soit par module ou par service, ainsi que la période de mesure et les intervalles considérés comme valides. À partir de ces éléments, ils fournissent le pourcentage atteint, accompagné du détail de chaque interruption survenue pendant la période.
La documentation technique sur les types de rapports présente les différentes variantes disponibles et explique le comportement de chacune avec les données historiques.
Avec tout cela, les fonctionnalités les plus utilisées pour les SLA dans Pandora FMS sont :

  • Périodes d’activité. En limitant le calcul aux horaires de couverture convenus afin qu’une interruption à 3 h du matin ne pénalise pas un SLA qui, conformément au contrat, doit être mesuré de 9 h à 18 h.
  • Maintenances planifiées. Les fenêtres d’arrêt du service sont déclarées dans le système et le rapport les comptabilise comme du temps valide, de sorte qu’elles ne pénalisent pas le SLA. Exactement ce qu’exigeait l’exemple de calcul présenté plus haut.
  • Vue des services. Le SLA peut être défini sur un service composite et pas uniquement sur une machine, avec même la possibilité d’attribuer des pondérations à chaque élément. C’est là que réside la différence entre évaluer un serveur et mesurer ce qui compte réellement pour l’activité.
  • Historiques et tendances. Les données sont conservées dans Pandora FMS afin de comparer les périodes et de détecter une éventuelle dégradation progressive, celle qui ne déclenche aucune alarme mais grignote notre marge mois après mois.
  • Rapports programmés. Le rapport mensuel est généré et envoyé automatiquement dans le format défini, ce qui rend le reporting automatique et durable lorsque l’on gère quarante clients.

Cela dit, Pandora FMS ne fait pas de magie (pas encore) et ne remplace pas un accord correctement rédigé. Si le SLA définit des objectifs que personne ne peut mesurer, même le meilleur outil ne fera que documenter avec précision que l’on ne sait pas si quoi que ce soit est réellement respecté.
Ce qui nous amène au point fondamental suivant, car un outil ne vaut que par le processus qui se trouve derrière lui. Voyons donc comment l’optimiser.

Bonnes pratiques pour définir un SLA

C’est le moment de vérité (aussi bien pour le client que pour le prestataire IT), celui où nous ne voulons pas nous enfermer dans un pacte faustien qui semble excellent sur le papier, mais qui finira par nous mordre la main au quotidien.
Pour l’éviter, nous devons :

  • Nous engager uniquement sur des métriques mesurables. Car s’il n’existe aucun moyen automatique d’obtenir la donnée, cette clause ne devrait pas figurer dans le contrat.
  • Écrire précisément comment chaque indicateur est calculé. Cela inclut la formule, la source des données, leur période et le point de mesure. Deux parties disposant du même chiffre mais utilisant des méthodes différentes pour l’obtenir finiront par se disputer.
  • Définir clairement la période de mesure. Une interruption de 40 minutes représente une disponibilité mensuelle de 99,91 % et, dans le même temps, une disponibilité hebdomadaire de 99,60 %. Laquelle de ces deux périodes compte ? Car avec la même interruption, nous pouvons respecter ou ne pas respecter l’engagement selon la période prise en compte. Il ne s’agit donc jamais d’un simple détail administratif.
  • Définir précisément les exclusions. Car se contenter d’indiquer « défaillances de tiers » revient à signer ce chèque en blanc dont je parlais au début.
  • Bien distinguer la réponse de la résolution. Car il s’agit d’engagements différents, avec des équipes, des coûts et des indicateurs distincts.
  • Réviser les niveaux lorsque le service évolue. Si nous migrons vers le cloud, si le nombre d’utilisateurs augmente fortement ou si nous mettons à niveau les équipements, ces nouvelles circonstances invalident les hypothèses initiales qui avaient été signées, et ces éventualités doivent être précisées dans le contrat.
  • Éviter les objectifs impossibles à superviser. Ce qui constitue la Directive Première résumant toutes les précédentes.

Et par expérience, voici un petit conseil que l’on voit rarement mentionné.
Ne promettons pas le neuf supplémentaire que nos indicateurs ne peuvent pas soutenir. C’est tentant, mais non, stop. Les mardis de maintenance de n’importe quel MMO enseignent depuis vingt ans la même leçon, éprouvée auprès de millions de joueurs : une interruption annoncée, prévisible et respectée génère beaucoup moins de plaintes que dix minutes d’indisponibilité survenant sans prévenir.
Nous avons davantage écrit sur l’équilibre entre ce qui est promis et ce qui est soutenable lorsque nous expliquons comment réduire les heures de support sans perdre le respect des SLA, améliorer l’efficacité opérationnelle en IT, ainsi que dans notre guide consacré aux types de SLA et aux bonnes pratiques.

Questions fréquentes

Reconstituons la carte du terrain parcouru à travers les questions les plus fréquentes à ce sujet :

Que signifie SLA ?

Service Level Agreement ou accord de niveau de service, le document qui définit le niveau de service auquel on s’engage, la manière dont son respect est mesuré et ce qui se passe si cet engagement n’est pas tenu.
Un SLA peut être signé pour de nombreuses activités, mais pour ce qui nous intéresse ici…

Qu’est-ce qu’un SLA en informatique ?

L’accord formel qui régit le niveau d’un service IT et qui détaille le pourcentage de disponibilité des systèmes, les délais de prise en charge des incidents, les horaires de couverture et la manière de vérifier que les engagements sont respectés.
Le SLA s’applique aussi bien aux prestataires externes qu’aux départements IT internes.

Comment calculer un SLA ?

Son respect est mesuré en fonction des différents indicateurs clés qui y sont définis et qui peuvent varier, mais lorsque la plupart des gens posent cette question, ils pensent en réalité à la disponibilité et à la manière de l’évaluer, puisqu’elle constitue généralement l’un des principaux composants du SLA global.
Cette disponibilité est calculée en divisant le temps disponible par le temps total mesuré, puis en multipliant le résultat par 100. Les exclusions convenues, telles que les fenêtres de maintenance programmées, sont déduites de ce temps total.
Les autres métriques du SLA, comme les éventuels délais de réponse, sont calculées comme le pourcentage de cas pris en charge dans le délai convenu.

Quelle est la différence entre SLA et uptime ?

Dans le prolongement de ce qui précède, l’uptime est une métrique, le pourcentage de temps pendant lequel le système a été disponible, tandis que le SLA correspond à l’accord complet.
Celui-ci peut inclure l’uptime parmi ses indicateurs, ainsi que les délais de réponse, de résolution et la couverture.

Qu’est-ce qu’un SLA de délai de réponse ?

L’engagement concernant le temps nécessaire pour prendre en charge un incident, en fonction de sa priorité.
On distingue généralement la première réponse, les mises à jour pendant le cycle de l’incident et la résolution, avec des délais différents pour chaque niveau de criticité.

Que se passe-t-il en cas de non-respect d’un SLA ?

Cela dépend de ce qui a été convenu dans le contrat. Il s’agit généralement de compensations financières ou de remises sur la facture, même si, dans de nombreux accords internes, la conséquence prend la forme d’un plan d’action documenté et d’une révision du service.

Quelle est la différence entre SLA, SLO et SLI ?

Le SLI (Service Level Indicator) est l’indicateur mesuré, le SLO est l’objectif interne défini pour cet indicateur, tandis que le SLA est l’engagement convenu avec le client.
Le SLO doit évidemment être plus exigeant que le SLA, afin que l’IT dispose d’une marge vis-à-vis du client.

L’accord est la partie la plus simple

Comme nous l’avons vu, un SLA transforme les attentes en engagements assortis d’un chiffre, d’une période, d’une méthode de calcul et de conséquences en cas de non-respect. Cela change la discussion entre le prestataire et le client, car nous cessons de débattre pour savoir si le service « fonctionne bien » en termes vagues et nous passons à la vérification de données objectives convenues qui apportent la véritable réponse.
Ce qui donne de la valeur à ces données, ce sont la supervision continue, l’historique et les rapports, car sans eux l’accord n’est rien de plus qu’une promesse creuse présentée sous forme de tableau.
Avant les SLA, Scotty pouvait multiplier par quatre ses estimations d’ingénierie parce que personne ne les mesurait à bord de l’Enterprise, mais dès que quelqu’un sort la règle… le service cesse d’être une astuce de réputation pour devenir de l’ingénierie pure, que l’on calcule, supervise et défend à l’aide de données.

Shares