Votre prestataire informatique vous a installé un logiciel de ticketing. Les collaborateurs y déposent leurs demandes, les techniciens y répondent quand ils peuvent, et personne ne sait vraiment si le service rendu est bon, passable ou catastrophique. Sans SLA formalisé, le ticketing n'est qu'un système de file d'attente — pas un outil de pilotage.
Un SLA (Service Level Agreement, ou accord de niveau de service) transforme cette file d'attente en engagement mesurable. Il définit ce que le prestataire doit livrer, dans quel délai, avec quel taux de réussite et quelles conséquences en cas de manquement. Ce guide détaille les indicateurs clés à négocier, les pièges à éviter et les bonnes pratiques issues du référentiel ITIL 4, cadre de référence international pour la gestion des services IT.
Pourquoi un SLA est indispensable autour du ticketing
Sans SLA, votre logiciel de ticketing est un outil technique sans cadre contractuel. Concrètement, cela signifie :
• Aucun engagement de délai : un ticket urgent peut rester ouvert 48 h sans que le prestataire ne soit en faute
• Aucune hiérarchisation objective : qui décide si un ticket est critique ou mineur ? Le technicien ? L'utilisateur ? Personne ?
• Aucune base de discussion : lors de la revue mensuelle, vous n'avez pas de données pour dire « c'est insuffisant » ou « c'est conforme »
• Aucun levier contractuel : si la qualité se dégrade, vous n'avez aucun mécanisme de pénalité ou de remédiation
Le SLA injecte de l'objectivité dans une relation qui repose sinon sur des impressions. Il protège le client (vous) mais aussi le prestataire, qui sait exactement ce qu'on attend de lui.
Les 5 indicateurs clés d'un SLA ticketing
Tous les SLA ne se valent pas. Un bon SLA de support IT repose sur cinq indicateurs mesurables, chacun lié à un aspect concret de la qualité de service.
| Indicateur | Définition | Valeur type (PME) | Ce qu'il mesure |
|---|---|---|---|
| GTI | Garantie de Temps d'Intervention — délai entre l'ouverture du ticket et la première action du technicien | 30 min à 4 h selon priorité | Réactivité |
| GTR | Garantie de Temps de Rétablissement — délai entre l'ouverture du ticket et le retour à un fonctionnement normal | 2 h à 24 h selon priorité | Efficacité |
| Taux de résolution | Pourcentage de tickets résolus dans les délais GTR | 90 % à 98 % | Fiabilité |
| Taux de satisfaction | Note donnée par l'utilisateur après résolution (CSAT) | ≥ 4/5 ou ≥ 80 % | Qualité perçue |
| Taux de réouverture | Pourcentage de tickets clos puis rouverts (même problème) | ≤ 5 % | Résolution réelle |
GTI et GTR sont les deux piliers. La GTI mesure la réactivité (on s'en occupe), la GTR mesure l'efficacité (c'est résolu). Un prestataire peut être très réactif (GTI de 15 min) mais inefficace (GTR de 48 h) — ou l'inverse. Les deux doivent être contractualisés.
Matrice de priorité : classer les tickets pour engager les bons délais
Le SLA n'a de sens que si les tickets sont classés par priorité. Sans matrice, tout est « urgent » — et donc rien ne l'est.
| Priorité | Définition | Exemple | GTI | GTR |
|---|---|---|---|---|
| P1 — Critique | Service bloquant pour l'activité, impact sur le chiffre d'affaires | Serveur de production en panne, ERP inaccessible, caisse bloquée | 15 min | 2 h |
| P2 — Élevée | Service dégradé, contournement possible mais pénible | Messagerie très lente, imprimante principale en panne | 1 h | 8 h |
| P3 — Normale | Gêne sans blocage, l'utilisateur peut continuer à travailler | Écran secondaire ne fonctionne pas, compte à créer | 4 h | 24 h |
| P4 — Basse | Demande d'amélioration, question, tâche planifiable | Mise à jour d'un logiciel, ajout d'un raccourci | 24 h | 5 jours |
Qui attribue la priorité ? Idéalement, l'utilisateur propose une priorité à l'ouverture du ticket, et le prestataire la valide ou la reclasse selon la matrice. Les critères de classification doivent être documentés et accessibles à tous pour éviter les conflits.
À retenir : Un SLA sans matrice de priorité est un engagement aveugle. Un prestataire qui s'engage sur une GTR de 2 h pour tous les tickets, sans distinction de priorité, ment ou surfacture — il ne peut pas mobiliser une astreinte 24/7 pour un raccourci à créer sur un bureau.
Heures ouvrées vs 24/7 : le choix qui change tout
La question la plus sous-estimée dans un SLA : les délais s'appliquent-ils pendant les heures ouvrées (typiquement 9 h – 18 h, lundi à vendredi) ou en 24/7 ?
• Heures ouvrées (HO) : un ticket P1 ouvert vendredi à 17 h avec une GTI de 1 h sera pris en charge lundi à 9 h. C'est 64 heures calendaires, mais 1 heure ouvrée — techniquement conforme au SLA
• Heures non ouvrées (HNO) / 24×7 : le même ticket est pris en charge à 18 h le vendredi. Le coût est nettement supérieur (astreinte, majoration)
Recommandation : La plupart des PME n'ont pas besoin d'un SLA 24/7 intégral. Un modèle hybride fonctionne bien : heures ouvrées pour les tickets P2 à P4, et une astreinte HNO pour les seuls tickets P1 (pannes bloquantes). Le surcoût est modéré (15 % à 25 % du contrat) et ciblé sur les vrais incidents critiques.
Les solutions de ticketing helpdesk modernes permettent de configurer ces plages horaires directement dans le moteur SLA : les compteurs de temps se mettent en pause automatiquement en dehors des heures couvertes.
Clauses de pénalité et de bonus : le SLA a des dents
Un SLA sans conséquence est une déclaration d'intention. Pour qu'il ait un effet réel, il doit prévoir des mécanismes de pénalité en cas de non-respect — et idéalement des bonus en cas de surperformance.
Mécanismes de pénalité courants :
• Avoir sur facture : réduction de 5 % à 15 % de la redevance mensuelle si le taux de résolution dans les délais passe sous le seuil contractuel
• Crédit de service : heures de prestation offertes en compensation
• Clause de résiliation : si le SLA est violé 3 mois consécutifs, le client peut résilier sans frais
• Plan de remédiation obligatoire : le prestataire doit proposer un plan correctif dans les 15 jours suivant un mois de non-conformité
Mécanismes de bonus (moins courants mais très efficaces) :
• Prime de surperformance : si le taux de résolution dépasse 98 % pendant 3 mois consécutifs, le prestataire reçoit un bonus
• Reconduction automatique : un SLA constamment respecté déclenche un renouvellement automatique sans renégociation
Le cadre contractuel idéal pour un contrat de maintenance informatique bien négocié intègre ces mécanismes dès la signature, pas en avenant 12 mois plus tard.
Configurer les SLA dans votre outil de ticketing
Les logiciels de ticketing modernes — GLPI, Freshdesk, Zendesk, Jira Service Management — intègrent tous un moteur SLA configurable. Voici les éléments à paramétrer :
• Règles de priorité automatique : un ticket mentionnant « serveur », « production » ou « bloquant » est automatiquement classé P1
• Compteurs de temps : le chrono GTI démarre à l'ouverture du ticket, le chrono GTR démarre à la première prise en charge
• Plages horaires : les compteurs respectent les heures ouvrées ou HNO selon le contrat
• Escalade automatique : si la GTI est dépassée de 50 %, le ticket est automatiquement escaladé au niveau supérieur et une notification est envoyée au responsable
• Tableau de bord SLA : pourcentage de tickets dans les délais, tickets en dépassement, tendance sur 30/60/90 jours
La supervision et le monitoring de l'infrastructure peuvent aussi alimenter le ticketing en créant automatiquement des tickets P1 lorsqu'une alerte critique est détectée — sans intervention humaine.
Revue de service : le SLA vit ou il meurt
Un SLA signé puis rangé dans un tiroir ne sert à rien. Le SLA doit faire l'objet d'une revue de service régulière — mensuelle ou trimestrielle — entre le client et le prestataire.
Contenu type d'une revue de service SLA :
• Tableau de bord du mois : nombre de tickets, répartition par priorité, taux de respect GTI/GTR
• Tickets en dépassement : analyse des causes, actions correctives
• Évolution de la satisfaction utilisateur (CSAT)
• Taux de réouverture : si en hausse, le prestataire résout en surface sans traiter la cause racine
• Ajustements SLA : les seuils fixés à la signature sont-ils toujours adaptés ? L'entreprise a-t-elle grossi, ajouté des sites, changé de logiciels ?
ITIL 4 recommande explicitement cette boucle de retour d'expérience. Un SLA qui n'évolue pas avec l'entreprise finit par devenir un carcan ou un leurre — dans les deux cas, il perd sa valeur.
Questions fréquentes sur les SLA de ticketing
Quelle est la différence entre SLA, OLA et UC ?
Le SLA (Service Level Agreement) est l'engagement entre le prestataire et le client. L'OLA (Operational Level Agreement) est l'engagement interne entre les équipes du prestataire (ex : le helpdesk s'engage à escalader au niveau 2 en 30 min). Le UC (Underpinning Contract) est l'engagement entre le prestataire et ses propres sous-traitants. Le SLA est le seul qui vous concerne directement, mais les OLA et UC doivent exister en coulisse pour que le SLA soit tenable.
Combien de niveaux de priorité faut-il ?
Quatre niveaux (P1 à P4) suffisent dans 95 % des cas. Au-delà de 5 niveaux, la classification devient ambiguë et les utilisateurs ne savent plus choisir. En dessous de 3, on perd en granularité et tout finit en P1.
Le SLA doit-il couvrir les demandes de service (pas seulement les incidents) ?
Oui. Les demandes de service (création de compte, installation de logiciel, accès VPN) représentent souvent 50 % à 70 % des tickets. Elles méritent leur propre engagement de délai, distinct des incidents. Un ticket « créer un compte utilisateur » en P4 avec un délai de 48 h ouvrées est raisonnable — mais il faut l'écrire.
Que faire si le prestataire conteste un dépassement de SLA ?
C'est là que les données du ticketing sont cruciales. Chaque ticket a un horodatage d'ouverture, de première réponse et de clôture. Si les données sont dans le système, il n'y a pas de contestation possible. D'où l'importance de ne pas gérer le support par email ou téléphone seul — tout doit passer par le ticketing.
Structurer pour piloter, pas pour punir
Le SLA n'est pas un outil punitif — c'est un outil de pilotage. Il donne au prestataire un cadre clair (il sait ce qu'on attend), au client une mesure objective (il sait ce qu'il obtient), et aux deux parties une base de discussion factuelle lors des revues de service.
Si vous n'avez pas de SLA formalisé avec votre prestataire IT, commencez par trois éléments : une matrice de priorité (P1 à P4), une GTI et une GTR par niveau, et un rendez-vous mensuel pour en parler. Le reste — pénalités, bonus, escalade automatique — viendra naturellement une fois que les données s'accumulent et que la relation mûrit.
Image : © Bing Images, 2026
