Article updated on 27/08/26
Dans le cadre de l’ITSM (IT Service Management, soit la gestion des services informatiques), un SLA est indispensable pour définir des attentes raisonnables et éviter frustrations et déceptions.
ITIL 4 définit un SLA comme un accord documenté entre un fournisseur de services et un client qui identifie à la fois les services requis et le niveau de service attendu. Son but est de définir ce que le fournisseur de services informatiques et le client doivent attendre lorsqu’ils s’engagent.
Chaque fois qu’un service informatique est conçu ou modifié, le SLA qui l’accompagne doit également être revu et modifié pour s’assurer qu’il est équitable, applicable et réaliste. L’objectif du SLA est de :
- Formaliser les besoins du client de façon à les rendre compréhensibles pour les deux parties.
- Fournir des critères d’évaluation de la prestation.
- Établir une relation de confiance entre les deux parties.
- Éliminer les attentes irréalistes.
En matière de contrat, il faut d’ailleurs bien faire la différence entre un SLA, un OLA (pour « Operation Level Agreement ») et un UC (pour «Underpinning Contract »). Le tableau suivant résume les distinctions essentielles entre ces trois types d’accords dans le cadre ITIL :
| Type | Parties impliquées | Objectif principal | Exemple d’usage |
|---|---|---|---|
| SLA (Service Level Agreement) | Fournisseur de services et client final | Définir la gamme et le niveau de qualité attendu des services couverts, tels que perçus par l’utilisateur | Les tickets P1 doivent être résolus dans les 4 heures suivant leur signalement, avec un taux de conformité mensuel de 99 % |
| OLA (Operational Level Agreement) | Équipes internes du fournisseur de services (ex. : service desk et équipe infrastructure) | Préciser comment chaque équipe interne contribue au respect des engagements du SLA | L’équipe infrastructure s’engage à traiter les escalades du service desk dans un délai de 2 heures pour les incidents critiques |
| UC (Underpinning Contract) | Fournisseur de services et sous-traitant externe | Régir les obligations des prestataires tiers qui contribuent à la délivrance du service | Le prestataire d’hébergement garantit une disponibilité de 99,9 % sur une base mensuelle glissante |
Appliqué à un Service Desk (centre de support informatique), le SLA précise notamment les délais dans lesquels les tickets doivent être acceptés et résolus. Ces trois niveaux forment une chaîne de responsabilité cohérente : si les OLA et UC ne sont pas correctement définis et respectés, le SLA ne peut pas être tenu, quelle que soit la qualité des intentions affichées.
Pourquoi les SLA sont essentiels en ITSM : avantages, risques et défis opérationnels
Un SLA apporte quatre avantages principaux : la réduction des coûts opérationnels, l’amélioration de l’expérience utilisateur, une meilleure visibilité sur les axes d’amélioration, et des objectifs clairs pour le Self-Service (portail en libre-service permettant aux utilisateurs de résoudre eux-mêmes leurs incidents).
Le SLA n’est pas qu’un outil juridique et contractuel. Voici ce qu’il permet concrètement :
- Optimiser les coûts opérationnels en évitant les engagements de service surdimensionnés et en concentrant les ressources sur les priorités réelles. Selon HDI, les organisations dotées de SLA formalisés réduisent significativement le volume de réouvertures de tickets, ce qui diminue directement le coût par incident.
- Améliorer l’expérience utilisateur en fixant des attentes claires et mesurables. Les équipes IT qui suivent activement leurs SLA affichent des scores de satisfaction utilisateur (CSAT) systématiquement plus élevés que celles qui opèrent sans cadre formalisé.
- Disposer d’une vision plus fine des améliorations à venir grâce à l’analyse des écarts entre engagements et performance réelle — un levier d’amélioration continue directement aligné avec les pratiques ITIL 4.
- Disposer d’objectifs clairs en matière de Self-Service, ce qui structure la gestion opérationnelle et permet de mesurer des KPI (Key Performance Indicators, ou indicateurs clés de performance) afin de savoir si les engagements sont bien respectés.
Il faut toutefois être prudent au moment de valider un SLA. Parmi les défis fréquemment rencontrés :
- La fixation d’attentes irréalistes : des délais de résolution intenables ou des taux de disponibilité impossibles à garantir fragilisent la relation dès le départ et exposent le fournisseur de services à des violations contractuelles répétées.
- L’ignorance des SLA en place : un SLA qui n’est pas activement suivi et communiqué aux équipes concernées n’a aucune valeur opérationnelle. Il devient un document de façade qui ne protège ni le client ni le fournisseur de services.
- Des demandes trop importantes et déraisonnables : des exigences disproportionnées par rapport aux ressources disponibles font perdre de la valeur au SLA et génèrent des tensions plutôt que de la confiance.
Sa rédaction doit fournir des descriptions de services complètes. Un SLA doit notamment contenir :
- La description précise des services couverts : périmètre, exclusions et conditions d’application.
- La définition de la disponibilité : ce que recouvre ce terme (heures ouvrées, 24/7, maintenance planifiée exclue, etc.).
- Les délais de réponse et de résolution par niveau de priorité : par exemple, les incidents critiques (P1) doivent être résolus dans les 4 heures suivant leur signalement.
- Les solutions prévues en cas de problème : procédures d’escalade, contacts responsables et mécanismes de compensation en cas de non-respect.
- Les résultats à atteindre en temps normal de fonctionnement : indicateurs de performance cibles et seuils d’alerte associés.
Enfin, si le SLA est souvent considéré comme un document très technique, il est important de s’assurer qu’il soit bien compris par toutes les parties.
Bonnes pratiques pour définir et gérer vos SLA ITSM efficacement
L’utilisation de SLA à plusieurs niveaux pour une grande organisation évite la duplication des efforts tout en assurant la personnalisation des clients et des services. Il existe trois types de SLA qui peuvent être déployés :
- Le SLA au niveau corporate qui couvre toutes les questions générales relatives à l’organisation et tous les salariés. Exemple : les demandes de réinitialisation de mot de passe doivent être traitées dans les 4 heures ouvrées, avec un taux de conformité mensuel de 99 %.
- Le SLA au niveau du client qui traite les questions spécifiques comme les exigences de sécurité d’un ou de plusieurs services. Exemple : le département administratif et financier bénéficie d’un délai de résolution réduit à 2 heures pour les incidents affectant les outils de traitement des paiements, en raison de leur impact direct sur les opérations métier.
- Le SLA au niveau du service qui aborde les questions relatives à un service spécifique. Exemple : pour les salariés utilisant un logiciel de CAO, le SLA précise les délais d’intervention en cas de panne et les versions logicielles supportées.
Chaque SLA doit aussi définir précisément les indicateurs de qualité attendus. Les KPI standards à suivre dans un SLA ITSM incluent notamment :
- Le taux de respect des délais de réponse : pourcentage d’incidents traités dans le délai SLA (cible typique : ≥ 95 %).
- Le taux de résolution dans les délais : pourcentage de tickets résolus avant expiration du délai contractuel (cible typique : ≥ 90 %).
- Le temps moyen de résolution (MTTR) : durée moyenne entre l’ouverture et la clôture d’un incident, à suivre par niveau de priorité.
- Le taux de réouverture des tickets : indicateur de qualité de la résolution (cible typique : < 5 %).
- Le score de satisfaction utilisateur (CSAT) : mesuré par enquête post-résolution (cible typique : ≥ 80 % de satisfaction).
Ces indicateurs doivent être régulièrement analysés, contrôlés et organisés dans un tableau de bord dont la fréquence et le contenu devront être clairement exprimés dans le SLA lui-même. Au-delà du suivi ponctuel, c’est l’analyse des tendances qui crée de la valeur : une dégradation progressive du taux de respect des délais est souvent le premier signal d’un problème de capacité ou de processus qu’il faut traiter avant qu’il ne devienne une violation contractuelle.
Comprendre la gestion des SLA est stratégique pour tenir vos objectifs en matière de qualité du service rendu et de relation client. Pour démarrer efficacement, trois priorités s’imposent : choisir le type de SLA adapté à votre organisation (corporate, client ou service), définir des KPI mesurables avec des seuils d’alerte réalistes, et mettre en place une gouvernance claire précisant qui valide le SLA, à quelle fréquence il est révisé et comment les manquements sont traités. C’est à ces conditions que le SLA devient un véritable levier d’agilité et de résilience pour votre organisation — et non un simple document contractuel.
2025 Gartner® Market Guide des Plateformes ITSM
