Un SLA, ça ressemble à une formalité administrative. En pratique, c’est l’un des documents les plus structurants d’une relation de service — et l’un des plus mal rédigés. SLA signifie Service Level Agreement, soit un accord de niveau de service. Il définit précisément ce qu’un fournisseur s’engage à délivrer, dans quels délais, avec quelles garanties. Pas de flou, pas d’interprétation : tout est écrit noir sur blanc.
Ce type de contrat concerne d’abord les services informatiques — hébergement, cloud, helpdesk — mais on le retrouve aussi dans la logistique, les télécoms ou même les ressources humaines internes. La forme varie, les principes restent identiques. Voyons ce qui se cache vraiment derrière ce sigle.
Ce que signifie concrètement un SLA
La définition au-delà du sigle
Un SLA est un accord formel entre un fournisseur de service et son client. Il traduit des engagements qualitatifs en indicateurs mesurables. Dire « nous sommes réactifs » ne veut rien dire. Écrire « temps de première réponse inférieur à 4 heures ouvrées » — voilà un SLA. L’accord fixe un seuil, et les deux parties savent exactement à quoi s’en tenir.
Trois éléments structurent tout SLA solide :
- Les indicateurs de performance retenus (disponibilité, temps de réponse, taux de résolution…)
- Les niveaux cibles associés à chaque indicateur (ex. : 99,9 % de disponibilité mensuelle)
- Les conséquences en cas de non-respect : crédits de service, pénalités financières, clauses de résiliation
Pourquoi ce n’est pas qu’un contrat de plus
Un accord de niveau de service n’est pas une clause générique glissée en annexe. Il sert à aligner les attentes dès le départ — avant que les problèmes surgissent. Les conflits entre clients et fournisseurs naissent rarement d’une mauvaise volonté ; ils viennent presque toujours d’une attente non formalisée. Le SLA coupe court à ça.
Il joue aussi un rôle de pilotage interne. Les équipes qui savent qu’un SLA mesure leur temps de résolution travaillent différemment de celles qui n’ont aucun filet de référence. C’est un levier de management autant qu’un outil contractuel.
Les types de SLA selon les contextes
SLA orienté client
C’est le plus courant. Un fournisseur signe un accord spécifique avec un client donné, adapté à ses besoins. Une PME qui externalise son infrastructure IT aura des engagements différents d’une banque qui gère des transactions 24h/24. Le contenu varie — les exigences de disponibilité, les plages horaires de support, les délais de résolution — mais la logique reste la même : tout est personnalisé.
SLA orienté service
Ici, c’est le service lui-même qui fixe les règles, indépendamment du client. Un éditeur SaaS qui publie ses conditions de disponibilité sur sa page de statut pratique ce modèle. Tous les clients bénéficient du même niveau d’engagement, sans négociation individuelle. C’est simple à gérer, moins flexible, et courant dans les offres cloud standardisées.
SLA multi-niveaux
Ce format combine les deux approches. On distingue généralement trois couches :
- Un niveau corporate : les règles générales valables pour toute l’organisation
- Un niveau service : les engagements propres à chaque offre
- Un niveau client : les conditions spécifiques négociées avec chaque compte
Ce modèle est adopté par les grandes entreprises de services managés. Il évite de réécrire un accord complet pour chaque nouveau client tout en laissant une marge de personnalisation.
Les indicateurs clés qui définissent un bon SLA
Disponibilité et temps de réponse
La disponibilité est souvent l’indicateur phare, surtout dans les services cloud et informatiques. On l’exprime en pourcentage sur une période donnée. Un taux de 99,9 % en mensuel autorise environ 43 minutes d’indisponibilité par mois — ce qui paraît peu, mais peut être critique pour un service de paiement en ligne. Passer à 99,99 % réduit cette fenêtre à 4 minutes : la différence de coût est réelle.
Le temps de réponse, lui, mesure la rapidité à laquelle le fournisseur accuse réception d’un incident. À ne pas confondre avec le temps de résolution, qui mesure le délai pour clore le problème. Les deux métriques coexistent dans un SLA équilibré.
Temps de résolution et taux de résolution au premier contact
Le temps de résolution fixe une limite maximale pour corriger un dysfonctionnement selon sa criticité. Un incident bloquant (niveau P1) aura un objectif de résolution de 4 heures ; un bug mineur (P4) pourra attendre 5 jours ouvrés. Ce découpage par priorité est une bonne pratique que l’on retrouve dans presque tous les SLA helpdesk et IT.
Le taux de résolution au premier contact — parfois appelé FCR, First Contact Resolution — mesure la proportion de demandes résolues sans escalade. Un FCR élevé signifie que les équipes de support traitent efficacement sans passer la main. C’est un indicateur de performance opérationnelle autant que de satisfaction client.
Mesurer la satisfaction : l’angle souvent oublié
Certains SLA intègrent des indicateurs de satisfaction, recueillis via des enquêtes post-intervention. C’est rare, mais pertinent. Un fournisseur qui respecte ses délais mais génère une mauvaise expérience client a un problème que les métriques techniques ne détectent pas. Sur ABCsondage.fr, les outils de Sondages permettent justement de collecter ce type de retour de façon structurée, pour alimenter le pilotage d’un accord de service avec des données réelles.
Mettre en place un SLA : les étapes pratiques
Cadrer les besoins avant de rédiger
On ne rédige pas un SLA depuis un bureau sans avoir interrogé les parties prenantes. Quels services sont couverts ? Quels incidents sont prioritaires ? Quelles plages horaires le support doit-il garantir ? Ces questions semblent évidentes — elles sont pourtant souvent sautées. Le résultat : un accord qui ne correspond pas aux usages réels.
Commencer par un audit des incidents des 6 derniers mois permet d’ancrer les objectifs dans la réalité opérationnelle. Fixer un temps de réponse de 30 minutes quand la moyenne historique est de 3 heures, c’est soit un objectif ambitieux avec un plan derrière, soit une promesse en l’air.
Rédiger, valider, faire vivre
Un SLA bien construit passe par plusieurs étapes :
- Définir le périmètre du service couvert et les exclusions explicites
- Choisir les indicateurs mesurables et leur méthode de calcul
- Fixer les niveaux cibles en accord avec le client
- Préciser les modalités de reporting (fréquence, format, responsable)
- Définir les remèdes contractuels en cas de non-respect
- Prévoir une clause de révision périodique (souvent annuelle)
Ce dernier point est souvent négligé. Un accord signé il y a 3 ans peut être totalement décalé par rapport à l’évolution du service ou des attentes du client. Réviser régulièrement, c’est garder l’accord utile.
Le SLA dans les environnements cloud
Les grands fournisseurs cloud — AWS, Microsoft Azure, Google Cloud — publient leurs SLA publiquement. Azure garantit par exemple 99,99 % de disponibilité pour ses machines virtuelles en configuration redondante. Ces engagements sont assortis de crédits de service automatiques si le taux chuте en dessous du seuil. Pas besoin d’appeler un commercial : le crédit est calculé et appliqué selon les règles publiées.
Pour les entreprises qui achètent du cloud et le revendent (MSP, intégrateurs), la question est de chaîner le SLA fournisseur avec celui proposé aux clients finaux. Promettre 99,99 % de disponibilité en s’appuyant sur une infrastructure qui garantit 99,9 % crée un écart de risque — un calcul à faire sérieusement avant de signer.
Les erreurs courantes qui vident un SLA de sa substance
Indicateurs trop nombreux ou non mesurables
Un SLA avec 25 indicateurs, personne ne le pilote vraiment. Mieux vaut 5 métriques suivies rigoureusement que 20 métriques oubliées dans un tableau Excel. Choisir, c’est prioriser — et c’est souvent là que les négociations se tendent, car chaque partie veut intégrer ses propres critères.
Les indicateurs doivent aussi être objectivement mesurables. « Qualité de service satisfaisante » n’est pas un KPI. « Taux de tickets résolus dans les délais impartis supérieur à 95 % » en est un.
Ignorer les exclusions
Un SLA sans exclusions claires est une source de litiges. Qu’arrive-t-il si l’indisponibilité vient du réseau de l’opérateur internet du client ? Si le problème est causé par une mise à jour décidée par le client lui-même ? Ces cas doivent être traités explicitement. Les fournisseurs cloud le font systématiquement — les prestataires de services plus petits ont tendance à oublier cette partie, parfois au prix fort.
Questions fréquentes
Quelle différence entre un SLA et un contrat de service classique ?
Un contrat de service décrit ce qui est fourni (les prestations). Un SLA va plus loin : il fixe des niveaux de performance mesurables et des conséquences contractuelles si ces niveaux ne sont pas atteints. Le SLA est souvent une annexe du contrat principal, mais c’est lui qui donne des dents à l’engagement du fournisseur.
Qu’est-ce qu’un crédit de service dans un SLA ?
Un crédit de service est une compensation financière accordée au client lorsque le fournisseur ne respecte pas ses engagements. Il prend généralement la forme d’un remboursement partiel de la facture ou d’une extension de service gratuite. Chez les fournisseurs cloud, ces crédits sont calculés automatiquement selon des barèmes publiés — pas besoin de réclamation manuelle.
Un SLA interne s’applique-t-il entre équipes d’une même entreprise ?
Oui. On parle alors d’OLA — Operational Level Agreement. Une DSI peut fixer avec les équipes support internes des engagements de temps de réponse et de résolution, sans qu’il y ait de relation commerciale. L’objectif reste le même : clarifier les attentes, mesurer la performance et responsabiliser les acteurs.
Combien de temps faut-il pour rédiger un SLA ?
Pour un accord simple entre deux parties, comptez une à deux semaines de travail effectif : audit des besoins, sélection des indicateurs, rédaction, validation juridique et signature. Un SLA multi-niveaux pour un grand compte peut prendre deux à trois mois, surtout si plusieurs équipes et sous-traitants sont impliqués dans la chaîne de service.
Le SLA couvre-t-il les pannes causées par des tiers ?
En général, non. Les SLA contiennent des clauses d’exclusion pour les événements hors du contrôle du fournisseur : panne de l’opérateur internet du client, force majeure, incident causé par une action du client lui-même. Ces exclusions doivent être rédigées précisément, sinon elles créent des zones grises propices aux litiges.