SLA informatique : définition, exemples et calcul

Quand une application tombe un lundi matin, la question n’est pas seulement de savoir qui appeler. Il faut aussi pouvoir déterminer ce que le prestataire s’était engagé à faire, dans quel délai et selon quelle méthode la qualité du service est mesurée.

C’est le rôle du SLA informatique, ou accord de niveau de service : transformer une promesse générale en engagements vérifiables.

Disponibilité, temps de réponse, temps de résolution et pénalités de service ne se négocient pas isolément. Ils doivent correspondre aux conséquences réelles d’une panne pour l’activité. Un service de paiement, un outil de production et un site vitrine ne justifient pas forcément le même niveau de couverture.

Pour comprendre la définition du SLA, ses calculs et ses exemples, le plus utile est de suivre un cas concret : celui d’une entreprise fictive qui confie une partie de son infrastructure à un prestataire.

En bref

• Un SLA formalise les services couverts, les niveaux attendus et les responsabilités de chaque partie.
• Un taux de disponibilité doit être converti en durée d’indisponibilité tolérée sur la période choisie.
• La GTI mesure le délai avant le début de la prise en charge ; la GTR vise le rétablissement du service.
• Les indicateurs de performance doivent être définis avec leur méthode de calcul et leurs exclusions.
• Un engagement n’a de valeur que si les mesures, les rapports et les recours sont lisibles.

SLA informatique : définition et rôle de l’accord de niveau de service

Le terme SLA vient de l’anglais Service-Level Agreement. En français, il désigne un accord de niveau de service conclu entre un client et un fournisseur, ou parfois entre des équipes d’une même organisation.

Dans les services informatiques, ce document décrit ce qui est fourni, le niveau de qualité attendu et la manière dont le respect des engagements sera évalué.

Une entreprise, Atelier Nord, utilise un logiciel de gestion hébergé par un prestataire. Une phrase comme « le service sera disponible en continu » ne suffit pas à régler les désaccords. Le contrat doit préciser les applications concernées, les horaires de couverture, les opérations exclues du calcul, la méthode de mesure et la période de référence. Sans ces détails, client et fournisseur peuvent lire la même promesse de deux façons différentes.

La définition du SLA va donc au-delà d’un pourcentage affiché sur une page commerciale. Le document peut encadrer l’hébergement d’un service SaaS, l’infogérance d’un réseau, l’assistance aux utilisateurs ou la maintenance de serveurs. Il peut aussi préciser les obligations liées aux sauvegardes, aux mises à jour, à la sécurité et à la continuité d’activité. Le périmètre doit nommer les ressources couvertes, les sites concernés et les dépendances qui relèvent d’autres fournisseurs.

Un SLA sert d’abord à aligner les attentes. Le client sait quel niveau de service il achète ; le prestataire connaît les contraintes qu’il doit tenir. En cas d’incident, les rôles et les procédures d’escalade permettent d’éviter le ping-pong entre équipes. Si une panne implique le réseau, l’hébergement et une application tierce, le contrat doit indiquer qui coordonne le diagnostic et qui informe le client.

Le texte joue aussi un rôle de gouvernance et de référence contractuelle. Il peut prévoir des crédits de service lorsque certains engagements ne sont pas tenus, mais ces mécanismes ne remplacent pas une définition claire du préjudice ni les dispositions du contrat principal. Pour une entreprise, mieux vaut faire relire les clauses sensibles par les fonctions juridiques et techniques avant signature.

Le SLA n’est pas nécessairement un document séparé. Il peut être une annexe au contrat de prestation, à condition que les deux textes soient cohérents. Un point mérite une attention particulière : la hiérarchie entre les documents en cas de contradiction. Une promesse commerciale, une fiche technique et une clause contractuelle ne doivent pas se contredire au moment où le service est indisponible.

Pour Atelier Nord, le premier travail consiste à classer ses services selon leur impact métier. La boutique en ligne et la gestion des commandes ne peuvent pas être traitées comme un outil interne utilisé une fois par mois. Cette hiérarchie évite de payer un niveau de couverture élevé partout, y compris là où une interruption de quelques heures reste acceptable. Un SLA pertinent décrit un besoin opérationnel, pas une formule séduisante.

Disponibilité, temps de réponse et temps de résolution : ce que le SLA doit préciser

La disponibilité des services est souvent le chiffre le plus visible d’un SLA. Elle indique la part de la période pendant laquelle un service est accessible selon les conditions convenues. Mais un objectif de 99,9 % n’a pas de sens complet tant que le contrat ne précise pas la période mesurée, les points de contrôle, les fenêtres de maintenance et le traitement des interruptions partielles.

Le calcul du SLA pour la disponibilité s’exprime généralement ainsi : durée de service disponible divisée par durée totale de service prévue, puis multipliée par 100. Si l’accord mesure le service sur une période mensuelle, il faut déterminer si les maintenances planifiées sont incluses ou retranchées du temps total. Une indisponibilité pour un seul site peut également être traitée différemment d’une panne générale. Ces choix contractuels influent directement sur le résultat.

Ces durées supposent une mesure sur l’année entière, sans retrancher de maintenance planifiée. Un contrat calculé au mois produira des tolérances différentes selon le nombre de jours et les heures de service prévues. Voilà pourquoi un pourcentage seul est insuffisant : il faut le traduire en durée concrète et vérifier la période de référence.

La GTI, ou garantie de temps d’intervention, fixe le délai maximal entre le signalement et le début de la prise en charge. La GTR, ou garantie de temps de rétablissement, fixe le délai visé ou garanti pour remettre le service en état. Les deux notions ne sont pas interchangeables. Un prestataire peut accuser réception d’un incident rapidement sans parvenir à rétablir l’application dans le même délai.

Le temps de réponse correspond, selon la définition retenue, au délai avant un premier retour ou une première action. Le temps de résolution décrit le délai pour traiter l’incident jusqu’à sa clôture ou au rétablissement convenu. Le SLA doit préciser le point de départ du chronomètre : ouverture d’un ticket, appel au support ou détection automatique. Il doit aussi définir les horaires applicables. Quatre heures ouvrées ne signifient pas quatre heures calendaires.

Les indicateurs de performance ne se limitent pas à ces délais. Un contrat de support peut suivre le taux de résolution au premier contact, les incidents récurrents, les tickets abandonnés ou le respect des fenêtres de maintenance. Chaque mesure doit avoir une formule, une source de données et un responsable. Un tableau de bord lisible aide à repérer les écarts ; un écran rempli de dizaines de chiffres ne facilite pas forcément la décision.

Dans l’exemple d’Atelier Nord, le prestataire peut s’engager à répondre à un incident critique sous une heure et à rétablir le service sous quatre heures, pendant une couverture définie. Ces valeurs sont des paramètres d’exemple, pas une norme à reprendre telle quelle. Le bon indicateur est celui qui décrit une conséquence utile pour le métier.

Calcul du SLA : méthode et exemple de disponibilité

Pour calculer la disponibilité, il faut d’abord choisir une période et définir ce que signifie « service disponible ». Une page d’accueil qui répond, mais dont les commandes ne peuvent pas être validées, est-elle considérée comme opérationnelle ? Si le service repose sur plusieurs composants, le contrat doit préciser si la mesure porte sur l’infrastructure, l’application complète ou un parcours utilisateur représentatif.

La formule courante est la suivante : disponibilité = (durée totale de service prévue moins durée d’indisponibilité retenue) ÷ durée totale de service prévue × 100. Le terme « retenue » compte. Une maintenance planifiée, une panne causée par un fournisseur tiers ou un incident lié à une configuration du client peuvent être exclus, selon le contrat. Il faut lire ces exclusions avant de comparer deux offres.

Prenons un mois de 30 jours avec une disponibilité prévue en continu, soit 720 heures. Supposons que le service ait subi 3 heures d’indisponibilité comptabilisées. Le calcul donne (720 − 3) ÷ 720 × 100, soit environ 99,583 %. Un objectif mensuel de 99,5 % serait donc atteint dans cet exemple, tandis qu’une cible de 99,9 % ne le serait pas.

Ce calcul ne dit pas tout. Trois heures d’arrêt concentrées en pleine journée peuvent coûter davantage que trois heures sur une période nocturne où aucun utilisateur ne travaille. Le SLA peut distinguer les plages de service, à condition que celles-ci soient définies précisément. Une entreprise qui opère à l’international devra aussi vérifier le fuseau horaire utilisé, notamment pour les délais d’intervention et les fenêtres de maintenance.

La méthode de collecte doit être vérifiable. Les données peuvent provenir d’un outil de supervision, de journaux applicatifs ou d’une mesure externe depuis plusieurs points de contrôle. Si le prestataire est seul à produire le rapport, le client doit savoir comment les résultats sont établis et dans quelles conditions il peut contester une mesure. Une panne non détectée par l’outil de suivi ne disparaît pas pour autant du vécu des utilisateurs.

Les crédits de service sont souvent associés aux écarts constatés. Le SLA doit décrire leur calcul, leur plafond, leur mode d’application et les éventuels délais de réclamation. Une pénalité exprimée par une formule vague, sans montant ni procédure, protège peu le client. Inversement, un barème déconnecté du prix ou de la capacité du fournisseur peut tendre la relation sans améliorer le rétablissement.

Pour Atelier Nord, un rapport mensuel devrait rapprocher les incidents enregistrés, les durées retenues, les exclusions appliquées et les crédits éventuels. Le client peut alors contrôler le résultat sans devoir reconstruire les événements à partir de courriels dispersés. Un calcul n’est utile que si ses règles sont partagées avant la panne.

Les services numériques ayant parfois des dépendances logicielles nombreuses, il est utile de savoir ce qui est réellement couvert par chaque contrat. Pour les équipes qui évaluent des outils, ce guide sur la définition du logiciel libre aide à clarifier une autre dimension du choix : les conditions d’usage et de maîtrise du logiciel, distinctes des engagements de disponibilité du fournisseur.

Exemples de SLA et différences entre SLA, SLO et OLA

Les exemples de SLA deviennent plus parlants lorsqu’ils correspondent à un usage précis. Pour un site vitrine consulté principalement en journée, un support en heures ouvrées peut suffire. Pour une boutique en ligne, une indisponibilité pendant une période de commandes peut avoir des conséquences directes sur le chiffre d’affaires. La bonne couverture dépend donc du service rendu, de ses utilisateurs et de la capacité de l’entreprise à contourner une panne.

Une grille d’infogérance pourrait, à titre illustratif, prévoir une disponibilité mensuelle cible, une assistance du lundi au vendredi sur une plage horaire écrite, puis des délais distincts selon la gravité. Un incident critique bloquant les commandes peut recevoir une prise en charge plus rapide qu’une demande de création de compte. Le contrat doit également expliquer qui attribue le niveau de criticité et comment il peut être réévalué si les faits évoluent.

Le SLA est l’engagement présenté au client ou au métier. Le SLO, ou objectif de niveau de service, est une cible interne que le fournisseur ou l’équipe opérationnelle suit pour tenir cet engagement, souvent avec une marge de sécurité. Si le SLA impose 99,9 % de disponibilité, l’équipe peut se fixer un objectif interne supérieur afin de repérer une dérive avant qu’elle ne devienne un manquement contractuel.

L’OLA, ou accord de niveau opérationnel, organise le travail entre les équipes qui contribuent à la prestation. Il précise les responsabilités, les délais de transfert d’un ticket et les modalités d’escalade. Un SLA promettant un rétablissement rapide reste fragile si l’équipe d’assistance attend plusieurs heures une intervention du réseau ou de l’hébergement. L’OLA rend la promesse exécutable en interne.

Le contrat de maintenance, lui, décrit généralement les conditions de l’intervention : équipements couverts, pièces, déplacements, réparations et exclusions. Il peut être associé au SLA, mais les deux documents ne sont pas synonymes. Dans le cas d’une maintenance matérielle par un prestataire tiers, il faut notamment vérifier le stock de pièces, les délais d’acheminement et la couverture des équipements arrivés en fin de support constructeur.

Pour une solution SaaS, les questions portent souvent sur la disponibilité de l’application, les délais de support et les opérations de maintenance. Pour une infrastructure hébergée, la mesure peut concerner le réseau, le stockage ou la capacité de restauration. Une seule grille universelle serait trompeuse : les métriques doivent suivre le service, pas le modèle de contrat préféré du fournisseur.

Une équipe qui souhaite renforcer ses compétences numériques peut aussi consulter des ressources de formation aux métiers du digital. Comprendre les mesures et les responsabilités facilite les échanges entre équipes techniques, marketing et direction. SLA, SLO et OLA se complètent : l’un formalise la promesse, l’autre la cible, le troisième l’organisation qui la rend possible.

Pour visualiser le fonctionnement d’un centre de services et la gestion des incidents, une recherche vidéo peut compléter la lecture. Les contenus choisis gagnent à montrer des processus concrets plutôt que de promettre un niveau de disponibilité sans expliquer sa mesure.

Questions fréquentes sur le SLA informatique

Que signifie SLA en informatique ?

SLA signifie Service-Level Agreement, traduit par accord de niveau de service. Ce document précise les prestations informatiques, les niveaux attendus, les méthodes de mesure et les recours prévus en cas de manquement.

Quelle différence entre GTI et GTR ?

La GTI fixe le délai maximal avant le début de la prise en charge d’un incident. La GTR concerne le délai de rétablissement du service. Le contrat doit définir leur point de départ, les horaires applicables et les niveaux de priorité.

Comment calculer un taux de disponibilité ?

Divisez la durée de service prévue moins la durée d’indisponibilité retenue par la durée totale prévue, puis multipliez par 100. Les maintenances planifiées et autres exclusions doivent être définies dans le SLA.

Les pénalités garantissent-elles le rétablissement du service ?

Non. Les crédits de service compensent contractuellement certains écarts, selon les conditions prévues. Ils ne remplacent ni une procédure d’escalade efficace ni des engagements précis de prise en charge et de rétablissement.