Qu'est-ce qu'un SLA en support IT ? Guide pratique 2026

Un collaborateur ouvre un ticket le lundi matin. Il ne sait pas si quelqu'un le lira dans l'heure, dans la journée ou la semaine prochaine. De votre côté, l'équipe IT traite les demandes au fil de l'eau, sans règle commune pour dire ce qui passe avant le reste. Cette situation se répète dans beaucoup de PME et chez les MSP qui n'ont pas encore formalisé leurs engagements de support.

Un SLA (accord de niveau de service) répond à ce flou en fixant par écrit ce que vous vous engagez à fournir, en combien de temps, et comment vous le mesurez. Ce guide vous donne une définition claire, le détail des composantes d'un SLA de support informatique, un exemple chiffré, la distinction avec les SLO et les OLA, les pièges à éviter, et quatre étapes pour démarrer sans vous surcharger.

Definition d'un SLA en support IT

Un SLA, ou Service Level Agreement, est un document qui définit les engagements d'un prestataire ou d'une équipe IT envers ses utilisateurs : ce qui est couvert par le support, dans quels délais, avec quel niveau de qualité, et selon quelles règles de mesure. Ce n'est pas un concept réservé aux grands groupes ou aux contrats externalisés : c'est avant tout un cadre pour aligner les attentes et rendre le service vérifiable.

Le SLA ne concerne pas uniquement un prestataire externe. Une équipe IT interne y a tout autant intérêt. Sans accord écrit, chaque responsable métier interprète l'urgence à sa manière, et l'IT finit par arbitrer au cas par cas. Formaliser un SLA interne, même léger, donne aux collaborateurs une référence commune et à l'équipe technique une base pour refuser ou recadrer des demandes hors périmètre sans paraître arbitraire.

Ce que contient un SLA de support informatique

Le périmètre du support. Le SLA précise ce qui est pris en charge : postes de travail, applications métier, serveurs, réseau, outils SaaS, ou une combinaison de ces éléments. Par exemple, vous pouvez inclure la messagerie et l'accès VPN, mais exclure les logiciels installés localement par l'utilisateur sans validation de l'IT.

Les horaires de couverture. Les délais n'ont de sens que si l'on sait quand l'horloge tourne : 8h-18h en jours ouvrés, astreinte le soir et le week-end, ou couverture 24h/24 pour certains services critiques. Un incident signalé vendredi à 19h n'aura pas le même traitement selon que votre SLA compte en heures ouvrées ou en continu.

Les niveaux de priorité. Quatre niveaux suffisent en pratique : critique, élevé, moyen et faible. Chaque niveau doit être défini par des critères objectifs (nombre d'utilisateurs bloqués, arrêt d'un processus métier, simple gêne individuelle) et non par le ton du mail ou la hiérarchie de l'appelant.

Les délais engagés. On distingue généralement le temps de prise en charge (première action de l'équipe), le temps de réponse (premier retour visible pour l'utilisateur), et le temps de résolution ou de contournement (service rétabli ou solution de repli en place). Pour une panne réseau classée critique, le SLA peut prévoir une prise en charge sous 30 minutes et une résolution sous 4 heures.

Les indicateurs de qualité. Au-delà des délais par ticket, le SLA peut fixer des objectifs globaux : taux de disponibilité d'un service, temps moyen de résolution, part des tickets traités dans les délais, score de satisfaction utilisateur. Ces indicateurs permettent de piloter le support sur la durée, pas seulement ticket par ticket.

Par exemple, un SLA peut prévoir qu'un incident critique soit pris en charge en 15 minutes et résolu en 4 heures, tandis qu'une demande standard est traitée sous 2 jours ouvrés.

SLA, SLO et OLA : quelles differences ?

Le SLA est la promesse faite au client ou à l'utilisateur final : c'est l'engagement contractuel ou institutionnel que vous affichez et que vous devez tenir. Le SLO (Service Level Objective) est l'objectif de performance que vous vous fixez en interne pour y parvenir, souvent un peu plus exigeant que le SLA pour garder une marge. L'OLA (Operational Level Agreement) est l'accord entre équipes internes pour que la chaîne tienne : le support niveau 1 s'engage à escalader sous X minutes, l'administrateur système à intervenir sous Y heures, le fournisseur cloud sous Z heures.

Imaginez un restaurant : le SLA, c'est la promesse au client (plat servi en 20 minutes). L'OLA, c'est l'organisation entre cuisine et salle pour que le plat parte à temps. Le SLO, c'est le chronomètre en cuisine qui indique si vous êtes dans les temps avant que le client ne regarde sa montre.

Les erreurs courantes dans la redaction d'un SLA

Fixer des délais trop ambitieux sans regarder le volume réel de tickets ni les effectifs disponibles est l'erreur la plus fréquente. Un engagement de résolution en 2 heures pour tout incident critique paraît rassurant sur le papier, mais si votre équipe reçoit dix incidents critiques par semaine avec deux techniciens, le SLA devient une fiction. Un accord régulièrement non respecté dégrade la confiance plus vite que l'absence totale de cadre.

Un SLA dont les indicateurs ne sont pas mesurés reste un document de plus dans un tiroir. Si personne ne consulte chaque semaine le taux de respect des délais, les écarts ne seront visibles qu'au moment de la plainte d'un directeur. Sans outil qui enregistre l'heure d'ouverture, de première réponse et de clôture, vous ne pouvez pas prouver que vous tenez vos engagements, ni corriger ce qui dérape.

Appliquer les mêmes délais à toutes les demandes est une autre source d'échec. Un mot de passe oublié et une panne serveur n'ont pas le même impact métier : les traiter avec la même priorité et le même délai dilue l'effort sur les vrais urgences et frustre les utilisateurs qui attendent une réponse simple. Un SLA solide différencie les priorités et adapte les délais à l'impact réel, pas à la formulation du ticket.

Comment mettre en place un SLA en pratique

Commencez par lister les types de demandes que vous recevez (incident, demande de changement, accès, matériel) et leur impact métier réel : combien de personnes sont bloquées, un processus de facturation est-il arrêté, ou s'agit-il d'une gêne isolée ? Cette cartographie évite de calquer le SLA sur l'urgence perçue au téléphone.

Ensuite, définissez quatre niveaux de priorité avec des critères objectifs pour chacun. Critique : service métier indisponible pour plusieurs utilisateurs. Élevé : dégradation importante sans arrêt total. Moyen : incident limité à un poste ou contournable. Faible : demande planifiable sans impact immédiat. Chaque niveau doit être compréhensible par un non-technicien qui ouvre un ticket.

Fixez ensuite des délais réalistes en vous appuyant sur vos données actuelles. Combien de temps s'écoule-t-il aujourd'hui entre l'ouverture et la première réponse ? Entre la prise en charge et la résolution pour les incidents du mois dernier ? Partir de la moyenne et du pire cas observé donne un SLA tenable ; partir d'un idéal marketing garantit l'échec dès le premier mois.

Enfin, choisissez un outil qui mesure automatiquement le respect des SLA sur chaque ticket. Sans suivi automatisé, vous passerez des heures à exporter des tableaux pour savoir si vous êtes en retard. Avec un helpdesk qui calcule les échéances selon la priorité et le calendrier de couverture, le SLA devient un outil de pilotage quotidien.

Qwease intègre la gestion des SLA par priorité avec un calendrier heures ouvrées pré-configuré pour la France, jours fériés inclus et fuseau Europe/Paris. Le respect des SLA est visible en temps réel sur chaque ticket et dans les tableaux de bord, ce qui permet d'anticiper les dépassements avant qu'un utilisateur ne les signale.

Voir comment Qwease gère les SLA : essai gratuit 30 jours, sans carte bancaire, à 12 € par agent et par mois après la période d'essai.

Questions frequentes

Quelle est la différence entre un SLA et un contrat de support ?

Le contrat de support décrit la relation commerciale : prestations incluses, tarifs, durée, conditions de résiliation. Le SLA en est une partie : il précise les niveaux de service mesurables (délais, disponibilité, qualité). Vous pouvez avoir un contrat sans SLA détaillé, mais sans SLA chiffré, les engagements de délai restent flous en cas de litige.

Un SLA est-il obligatoire pour une équipe IT interne ?

Aucune obligation légale générale n'impose un SLA à une équipe interne. En revanche, dès que plusieurs services dépendent de l'IT ou que la direction exige de la visibilité, un SLA interne clarifie les priorités et sert de base aux revues de performance. C'est un outil de gestion, pas une formalité contractuelle.

Comment mesurer le respect d'un SLA sans outil dédié ?

Vous pouvez le faire manuellement sur un tableur en notant pour chaque ticket la date d'ouverture, de première réponse et de clôture, puis en comparant aux délais fixés. Cette méthode convient pour un volume faible et une phase de test. Dès que le flux dépasse quelques dizaines de tickets par mois, le calcul devient chronophage et les oublis faussent les statistiques.

Peut-on avoir des SLA différents selon les clients ou les départements ?

Oui, et c'est souvent pertinent. Un MSP propose des niveaux de service différents selon le contrat souscrit. En interne, la direction peut avoir des délais plus courts que les autres services, ou le support production peut être couvert 24h/7j alors que le reste de l'entreprise est en heures ouvrées. L'important est que chaque public sache quel SLA s'applique à lui.

Un SLA bien conçu part de votre réalité actuelle, pas d'un modèle théorique. Formalisez-le, mesurez-le pendant un trimestre, puis ajustez les délais et les priorités à partir des chiffres observés.