SLA et matrice d’escalade dans GLPI 11

Un Service Level Agreement transforme une promesse vague (« nous traitons vos tickets rapidement ») en engagement mesurable (« 85 % des incidents de priorité haute sont résolus en moins de 4 heures ouvrées »). Sans SLA, un service desk ne peut pas démontrer sa valeur à la direction, ni détecter les dérives avant qu’elles deviennent des plaintes. GLPI 11 propose un moteur SLA puissant, couplé à des règles d’escalade qui réveillent automatiquement les bons acteurs quand un délai glisse.

Ce tutoriel configure pas à pas une grille SLA réaliste pour un service desk de PME, l’associe à la matrice de priorité, et met en place les escalades à 50 %, 75 % et 100 % du délai contractuel. Le contexte ITSM global est posé dans GLPI 11 helpdesk ITIL : déployer un service desk professionnel.

Étape 1 — Distinguer SLA, OLA et UC

ITIL distingue trois types d’accords selon le périmètre :

• SLA (Service Level Agreement) — accord avec l’utilisateur ou le client final. Mesure du temps perçu par le demandeur
• OLA (Operational Level Agreement) — accord interne entre équipes (le N1 transmet au N2 sous 30 minutes). Mesure les transitions internes
• UC (Underpinning Contract) — contrat avec un fournisseur tiers (l’éditeur de l’ERP s’engage à corriger un bug bloquant en 24 heures). Mesure la dépendance externe

GLPI implémente nativement les SLA. Les OLA s’implémentent avec des règles internes (statut « En attente N2 » + relance auto). Les UC se gèrent via un module « Contrats » qui suit les échéances fournisseur sans déclencher d’escalade automatique sur le ticket utilisateur.

Étape 2 — Définir les deux temps mesurés : TTO et TTR

Un ticket suit deux temps réglementés :

• TTO (Time To Own) — délai entre l’ouverture du ticket et sa première prise en charge effective par un technicien (statut passé à « En cours »)
• TTR (Time To Resolve) — délai entre l’ouverture du ticket et sa résolution (statut « Résolu »)

Le TTO mesure la réactivité, le TTR mesure la capacité à résoudre. Un service desk peut avoir un excellent TTO (les techniciens prennent les tickets très vite) et un TTR catastrophique (ils n’ont pas les compétences ou les droits pour conclure). Mesurer les deux indépendamment révèle où l’amélioration doit porter.

Étape 3 — Construire la grille SLA selon les priorités

Allez dans « Configuration » → « SLA » → « + ». Créez un SLA par priorité, avec deux objectifs (TTO et TTR) chacun :

Ces durées ne sont pas universelles. Adaptez à votre contrat. Mais le bon réflexe : commencez avec des engagements raisonnables que vous tiendrez à 90 %, puis serrez progressivement. Promettre du 30 minutes sur P1 quand l’équipe est de garde de 9h à 17h crée du faux SLA et démolit la confiance.

Étape 4 — Configurer les calendriers d’ouverture

Les SLA s’appliquent rarement en 24/7. Définissez d’abord les calendriers dans « Configuration » → « Calendriers ». Créez par exemple :

• Heures ouvrables : lundi-vendredi 9h-18h, hors jours fériés
• Heures ouvrables étendues : lundi-vendredi 7h-20h + samedi 9h-13h
• Astreinte 24/7 : aucune pause

Pour chaque calendrier, importez les jours fériés français (ou ceux applicables à votre région) via le menu « Jours fériés ». GLPI ne décompte pas le temps sur les périodes non ouvrables : un ticket P3 ouvert vendredi 17h ne déclenche pas l’escalade samedi matin si le calendrier est « Heures ouvrables ».

Étape 5 — Associer SLA et priorité par règles métier

Le moteur de règles métier connecte priorité et SLA. Allez dans « Administration » → « Règles » → « Règles métier pour les tickets ». Créez cinq règles, une par priorité :

Règle SLA P1. Condition : Priorité = Très haute. Actions : SLA TTO = SLA-P1-TTO, SLA TTR = SLA-P1-TTR.

Répliquez pour P2 à P5. L’ordre d’exécution importe peu si les conditions sont mutuellement exclusives. Si vous préférez un seul ticket « catch-all », activez une règle par défaut SLA = SLA-P3 qui s’applique quand aucune priorité n’est encore définie, puis surchargez par des règles spécifiques.

Étape 6 — Définir les niveaux d’escalade

Une escalade est une action déclenchée quand un SLA passe un seuil. GLPI propose des escalades en pourcentage du délai SLA. Le bon réglage tient en trois niveaux :

Configurez les actions dans la fiche SLA → onglet « Niveaux d’escalade » → ajouter. Chaque niveau définit un délai (en pourcentage ou en valeur absolue) et une liste d’actions : envoyer une notification à un acteur, modifier le ticket (urgence, statut, groupe d’attribution), exécuter une tâche planifiée.

Évitez d’ajouter cinq niveaux d’escalade. Au-delà de trois, le signal devient bruit et tout le monde l’ignore. Trois seuils bien choisis avec trois acteurs distincts couvrent 95 % des cas.

Étape 7 — Cas particulier des tickets « En attente »

Quand un technicien met un ticket « En attente » d’information du demandeur, le compteur SLA doit s’arrêter. Sans ce mécanisme, le service desk se ferait pénaliser pour le délai de réponse de l’utilisateur, ce qui est injuste et incite à mal renseigner les statuts.

Dans « Configuration » → « Générale » → « Assistance », activez « Suspendre le calcul du SLA pour les tickets en attente ». GLPI met alors en pause le compteur pendant toute la durée du statut « En attente », et le relance dès le retour à « En cours ».

Vérifiez le comportement avec un ticket de test : ouvrez, attribuez, passez « En attente » pendant deux heures, repassez « En cours ». L’historique du ticket doit montrer la pause SLA. Sans cette suspension, vos chiffres SLA fluctueront aléatoirement selon la disponibilité des demandeurs et perdront leur valeur de pilotage.

Étape 8 — Notifications et webhooks d’escalade

Une notification e-mail c’est bien, un message dans le canal d’équipe c’est mieux pour les priorités hautes. Sur le niveau d’escalade 100 % d’un SLA P1, ajoutez l’action « Appeler webhook sortant ». Configurez le webhook dans « Configuration » → « Webhooks » pour pointer sur l’URL d’un canal Slack, Teams ou Mattermost dédié au service desk.

Le payload envoyé contient l’ID du ticket, le titre, le demandeur, le technicien attribué, l’âge du ticket et l’URL directe. Côté chat, un bot affiche un message clair que l’équipe ne peut pas manquer. La friction passe de « je vérifie ma boîte mail » à « je vois immédiatement dans le canal d’équipe ».

Étape 9 — Reporter et améliorer

Les SLA n’ont d’intérêt que si vous lisez les chiffres. GLPI 11 expose un widget dashboard « Taux de respect du SLA » qui affiche pour chaque priorité le pourcentage de tickets clos dans les temps. Affichez le widget en page d’accueil du module Assistance.

Suivez quatre métriques mensuelles :

• Taux de respect TTO par priorité (cible : ≥ 95 %)
• Taux de respect TTR par priorité (cible : ≥ 85 %)
• Top 3 catégories qui plombent le SLA
• Top 3 techniciens dont les tickets dérapent le plus

La dernière métrique ne sert pas à blâmer, mais à comprendre : un technicien systématiquement en dérapage est souvent un signal de surcharge, de manque de droits, ou de complexité du périmètre confié. Ajuster avant que la personne ne s’épuise est un acte de management, pas de sanction.

Erreurs fréquentes

Documenter le SLA dans un contrat de service

Publiez un document court (deux pages) qui formalise vos engagements vis-à-vis des utilisateurs : périmètre couvert, plages horaires, délais par priorité, exclusions, processus en cas de défaillance majeure. Affichez-le en pied du portail self-service et en intranet. Ce contrat de service rend les SLA visibles et acceptés, ce qui change radicalement la conversation avec les directions métier quand un délai est dépassé.

Articles associés

• GLPI 11 helpdesk ITIL : déployer un service desk professionnel
• Workflows ITIL incidents et demandes
• API REST GLPI : intégrer un script Python
• Sécuriser GLPI en production

Références

• ITIL 4 — Service Level Management
• Documentation utilisateur GLPI

Construire un SLA différencié par client interne

Une grande PME ou une ETI sert plusieurs directions métier avec des exigences contractuelles différentes. La direction financière qui clôture les comptes le 5 du mois ne supporte pas un incident de 24 heures sur l’ERP ; la direction marketing tolère plus de latence sur l’outil de mailing. GLPI gère cela via la dimension Entité et la dimension Catégorie dans les règles métier.

Concrètement, déclarez une entité par direction métier (ou par client si vous êtes ESN), et créez des SLA spécifiques :

• SLA Finance-P2 — TTR 4 heures pour les incidents catégorie ERP/Comptabilité durant la période de clôture mensuelle
• SLA Finance-P2 standard — TTR 1 jour ouvré hors période de clôture
• SLA Marketing-P2 — TTR 1 jour ouvré toute l’année

Les règles métier basculent automatiquement vers le bon SLA selon l’entité, la catégorie, et la date (via un calendrier nommé « Période de clôture »). Cette finesse n’est pas anodine : elle rend visible un effort réel envers les métiers à forte exigence, et donne du sens aux engagements pris.

Les pièges du reporting SLA brut

Le pourcentage de respect SLA brut peut tromper. Trois écueils classiques à surveiller :

Le ticket clos en sur-effort. Un technicien qui sait qu’un ticket dépasse abandonne parfois la qualité pour « cocher la case » avant le SLA. Croisez le SLA avec le taux de réouverture des tickets (ticket réouvert dans les 7 jours suivant la clôture) — un SLA à 95 % avec un taux de réouverture à 20 % cache un problème.

L’effet « clôture du vendredi soir ». Certains services desk améliorent artificiellement leur SLA en clôturant en masse le vendredi avant 18h les tickets qui dormaient depuis le lundi. Suivez la médiane du temps de résolution, pas seulement le respect SLA, pour repérer ce biais.

Le ticket de complaisance. Un super-utilisateur qui ouvre lui-même son ticket et le résout immédiatement gonfle artificiellement les statistiques. Marquez les tickets « auto-résolus en moins de 5 minutes » comme une catégorie séparée dans le reporting.

Coupler SLA et capacité d’équipe

Promettre 4 heures de TTR sur les P1 quand l’équipe compte deux techniciens en astreinte tournante est mathématiquement faisable, mais émotionnellement épuisant. Une règle de proportionnalité s’impose : pour un SLA P1 à 4 heures, prévoyez au moins trois techniciens formés et habilités à traiter, dont un de garde à chaque heure.

Pour une PME de moins de 100 utilisateurs, considérez plutôt des SLA P1 à 8 heures, P2 à 1 jour ouvré, P3 à 3 jours ouvrés. Cela rend l’engagement tenable avec deux à trois techniciens et n’expose pas à du « SLA marketing » que personne n’arrivera à honorer.

Réviser les SLA tous les six mois

Un SLA n’est jamais gravé dans le marbre. Tous les six mois, organisez une revue avec la direction métier et les techniciens. Quatre questions à poser :

• Les délais actuels sont-ils tenus à plus de 90 % ? Si oui, peut-on se permettre de les serrer ?
• Quelles catégories de tickets posent systématiquement problème, et pourquoi ?
• Y a-t-il des nouveaux services à intégrer dans le périmètre couvert ?
• Le contrat de service publié reflète-t-il toujours la réalité opérationnelle ?

Une révision documentée et signée tous les six mois maintient l’alignement entre les équipes, démontre une dynamique d’amélioration, et nourrit les rapports annuels de la DSI. C’est exactement ce qu’attend un comité de direction qui veut comprendre la valeur réelle du service desk.