SLA en infogérance : principes, KPI, exemples et pièges (PME)
Par Léo Dugué
Le 25-02-26
Table des matières
Un SLA (Service Level Agreement / accord de niveau de service) n’est pas une promesse marketing. C’est un engagement mesurable, rattaché à un périmètre, à des horaires, à des canaux, et à une méthode de preuve (ticketing + KPI). Sans cela, le terme « SLA » n’est que pure décoration.
Dans l’univers des PME, le piège est classique : vous pensez acheter un « temps de résolution » garanti, mais on vous vend en réalité un simple « temps de prise en charge ».
Le résultat est prévisible : le prestataire infogérant répond rapidement pour respecter son engagement, mais le problème de fond reste non résolu, paralysant vos opérations, malgré .
Distinguer la prise en charge, la résolution et le rétablissement pour déceler les ambiguïtés dans les contrats.
Construire un SLA vérifiable en définissant précisément les criticités, les canaux, les horaires, les exclusions, les preuves et le reporting.
Identifier et éviter les pièges courants : le « best effort » déguisé, les clauses de disponibilité floues, les KPI mal adaptés et les pénalités inapplicables — voir aussi pièges d’infogérance : promesses et zones grises.
Piloter votre infogérance avec les KPI pertinents (MTTR, FCR, respect par criticité) et savoir comment les vérifier.
Comprendre le lien indissociable entre le SLA, le contrat, le périmètre et la gouvernance pour assurer un pilotage efficace.
Mieux discerner les points forts et le fonctionnement de l’infogérance.
Les 8 éléments fondamentaux d’un SLA d’infogérance
Périmètre : la liste exhaustive de ce qui est couvert (in-scope) et de ce qui est explicitement exclu (out-of-scope).
Horaires de service : les plages de couverture (ex : 8×5, 12×5, 24×7), la gestion des jours fériés et les éventuelles astreintes.
Canaux de communication : les moyens de contact officiels (portail, email, téléphone, chat) et la hiérarchie entre eux.
Niveaux de criticité : une grille de classification claire des incidents basée sur l’impact métier, avec des exemples concrets.
Délais par criticité : des objectifs distincts pour la prise en charge, le rétablissement du service et la résolution de l’incident.
Règles de mesure : la méthodologie précise de calcul des délais (horodatage, début, fin, pauses, exclusions).
Preuve et Reporting : un tableau de bord mensuel, l’accès aux tickets, des exports de données et la liste des métriques obligatoires.
Gouvernance et remédiation : des revues périodiques, des plans d’actions en cas de dérive, des seuils d’alerte et des clauses de renégociation ou de résiliation.
Prise en charge vs Résolution vs Rétablissement : le piège n°1
1) Temps de prise en charge (Acknowledgement / Response Time)
Ce délai mesure le temps entre la création de votre ticket et la première action du prestataire, comme un accusé de réception ou le début d’un diagnostic. C’est un indicateur d’activité, mais il ne garantit en rien la remise en service de vos outils.
2) Temps de résolution (Resolution Time)
Il s’agit du temps nécessaire pour corriger la cause racine du problème et clore définitivement le ticket. C’est souvent cette mesure que la PME pense acheter, mais elle est rarement la seule à considérer.
3) Temps de rétablissement (Restore Time / « GTR »)
Ce KPI mesure le délai pour rendre le service de nouveau opérationnel, même si c’est par une solution de contournement (workaround). Pour la continuité de l’activité, cet indicateur est souvent plus critique que le temps de résolution.
De nombreux prestataires mettent en avant ces notions sans pour autant définir les règles de mesure précises, ouvrant la porte à des interprétations abusives.
Exemple de matrice de criticité (à adapter)
Criticité
Exemple PME
Objectif Prise en Charge
Objectif Rétablissement
Objectif Résolution
Canal
Critique
ERP ou système de caisse à l’arrêt
15 minutes
1 heure
4 heures
Téléphone + Ticket
Haute
Messagerie principale hors service
30 minutes
4 heures
24 heures
Ticket prioritaire
Moyenne
Problème sur un poste non bloquant
1 heure
N/A
48 heures
Ticket
Basse
Demande d’information ou de service
4 heures
N/A
5 jours ouvrés
Ticket
Le point clé : Sans une distinction claire entre ces trois métriques, vous ne savez pas ce que votre prestataire s’engage réellement à livrer.
Les KPI qui comptent vraiment (et ceux qui ne sont que décoration)
Les KPI de pilotage à exiger
Respect des délais par criticité : Le pourcentage de tickets respectant les engagements de prise en charge, de rétablissement et de résolution, pour chaque niveau de criticité.
MTTR (Mean Time To Repair/Resolve) : Le temps moyen pour restaurer le service. Il est crucial de définir s’il s’agit du rétablissement ou de la résolution.
Backlog : Le volume de tickets ouverts et en retard, qui reflète la charge réelle et la capacité du prestataire.
FCR (First Contact Resolution) : Le pourcentage de tickets résolus dès le premier contact, un excellent indicateur de l’efficacité du support.
Les KPI d’hygiène (utiles mais insuffisants)
Temps de prise en charge moyen : Peut être excellent même si les résolutions traînent.
Satisfaction client (CSAT) : Utile, mais peut être biaisé si les tickets sont fermés prématurément.
Les KPI à cadrer avec précaution
Disponibilité (Uptime) de 99,9% : Pertinent pour de l’hébergement, mais souvent trompeur pour un service de support si le périmètre mesuré n’est pas clairement défini.
Mesure et preuve : comment rendre un SLA opposable
Un SLA n’a de valeur que s’il est mesurable et vérifiable. Voici les éléments à formaliser pour le rendre opposable.
Checklist de la preuve
Outil de ticketing centralisé : Chaque demande doit générer un ticket horodaté à chaque étape (création, prise en charge, communication, résolution).
Règles de calcul claires : Le contrat doit spécifier comment le temps est décompté (début, fin, pauses pour attente client, horaires ouvrés/non ouvrés).
Exclusions explicites : Lister les cas où le SLA ne s’applique pas (maintenances planifiées, pannes dues à un tiers, modifications non autorisées).
Accès aux données : Le client doit pouvoir accéder à un reporting transparent, incluant un export des tickets et la méthode de calcul des KPI.
Fréquence de reporting et gouvernance : Un point de suivi mensuel est un minimum pour analyser les performances et décider des plans d’action.
Cette approche s’aligne avec les meilleures pratiques ITSM, où le SLA est un outil de pilotage actif et non un simple document contractuel. Pour aller plus loin sur la traçabilité des incidents et les obligations associées, voir preuves, traçabilité et reporting (RGPD).
SLA, OLA, UC : l’impact de la chaîne de sous-traitance
SLA (Service Level Agreement) : le contrat entre vous et votre prestataire.
OLA (Operational Level Agreement) : les accords internes au prestataire (entre ses différentes équipes) pour garantir le SLA.
UC (Underpinning Contract) : les contrats entre votre prestataire et ses propres fournisseurs (éditeurs de logiciels, opérateurs télécoms, hébergeurs).
Ce que vous devez exiger
Que le prestataire identifie clairement les dépendances externes qui impactent votre SLA.
Qu’il définisse ce qui est sous son contrôle direct et ce qui ne l’est pas.
En cas de dépendance, qu’une procédure d’escalade et un engagement de communication soient formalisés (mise à jour toutes les X heures sur les incidents critiques).
Pénalités : L’illusion de la sanction
Les pénalités financières classiques posent trois problèmes en PME : elles sont souvent faibles par rapport à la perte réelle, elles nécessitent des preuves difficiles à constituer si la mesure est floue, et elles génèrent des conflits plutôt que des améliorations. Ces clauses font partie des points à vérifier dans tout contrat d’infogérance : clauses indispensables.
Alternatives plus pragmatiques
Crédits de service (Service Credits) : des avoirs sur facture, calculés selon des règles simples en cas de non-respect des objectifs.
Plan d’amélioration obligatoire : déclenché automatiquement lorsque les seuils critiques sont atteints deux mois consécutifs.
Clause de réversibilité ou de résiliation : la possibilité de sortir du contrat si le service n’est pas à la hauteur, encadrée par des conditions claires.
Exemples et Coût : Un SLA est un choix économique
Les exemples de délais comme « 4h / 24h » que l’on trouve chez les prestataires ne sont que des indicateurs de marché, pas des standards universels. Un SLA est avant tout un arbitrage entre le niveau d’exigence et le coût — pour comprendre comment le SLA influe directement sur la facture, voir ce qui fait varier le prix d’une infogérance (dont le SLA).
Plus les exigences sont élevées (disponibilité 24/7, temps de rétablissement très courts, astreinte N3), plus la capacité requise est importante — et donc, plus le coût est élevé.
Un bon SLA est celui qui est aligné sur les besoins réels de votre activité : quels outils doivent repartir en 1 heure ? En 4 heures ? Le lendemain ? Répondre à ces questions avant de signer un contrat, c’est éviter de payer pour des engagements inutiles ou de sous-estimer des risques critiques.
Un document contractuel qui formalise les niveaux de service attendus (délais, qualité, mesure) entre un client et un prestataire informatique. Sans périmètre défini et sans méthode de preuve, il n’est pas opposable.
Quelle est la différence entre temps de réponse et temps de résolution ?
Le temps de réponse (ou de prise en charge) mesure la rapidité à laquelle le prestataire accuse réception de votre demande. Le temps de résolution est le délai pour corriger le problème de fond. Ce sont deux notions très différentes avec des implications contractuelles distinctes.
Que signifie « temps de rétablissement » (GTR) ?
C’est le temps nécessaire pour que le service soit de nouveau fonctionnel, même via une solution temporaire (contournement). Pour la continuité d’activité, c’est souvent l’indicateur le plus important à négocier.
Quels sont les KPI essentiels pour un helpdesk ?
Le respect des délais par criticité, le MTTR (temps moyen de réparation), le volume de tickets en attente (backlog) et le FCR (résolution au premier contact) sont les indicateurs les plus pertinents pour piloter un contrat d’infogérance.
Quelle est la différence entre SLA, OLA et UC ?
Le SLA est l’accord client-prestataire. L’OLA est l’accord interne au prestataire entre ses équipes. L’UC est le contrat entre le prestataire et ses propres fournisseurs (éditeurs, opérateurs, hébergeurs). Un SLA solide repose sur des OLA et UC cohérents.
Les pénalités sont-elles indispensables dans un SLA ?
Pas nécessairement. Pour une PME, des mécanismes plus simples — reporting transparent, crédits de service et clause de sortie claire — sont souvent plus efficaces et plus faciles à actionner qu’une clause pénale complexe.
