Indicateurs du support : MTTR, taux de résolution, respect des SLA

Les indicateurs du support (ou KPI, key performance indicators) sont des mesures chiffrées qui disent si le support tient ses engagements et où il doit progresser : délais de prise en charge et de résolution, taux de résolution au premier contact, respect des SLA, stock de tickets ouverts, satisfaction des utilisateurs, disponibilité des services. Ce chapitre définit les indicateurs classiques, montre comment les calculer, comment lire un tableau de bord et quels pièges éviter.

Pourquoi mesurer

Sans chiffres, le support vit au ressenti : « on est débordés », « les utilisateurs sont mécontents », « ça casse tout le temps ». Les indicateurs transforment ces impressions en faits (« +40 % de tickets réseau depuis la migration ») et permettent de décider : un renfort, une formation, un achat, l'ouverture d'un problème. Ils servent aussi à vérifier le SLA du chapitre 7, et ils n'ont de valeur que si les tickets sont bien renseignés : type, catégorie, priorité, statuts à jour. Un ticket mal rempli fausse les statistiques.

Les indicateurs classiques

Lire un rapport mensuel

Le rapport de novembre 2026 du support de Cèdre Habitat :

Les calculs :

• FCR : 231 ÷ 398 × 100 ≈ 58,0 % ;
• résolution au N1 : 302 ÷ 398 × 100 ≈ 75,9 % ;
• respect du SLA : 371 ÷ 398 × 100 ≈ 93,2 % ;
• réouverture : 14 ÷ 398 × 100 ≈ 3,5 % ;
• satisfaction : 96 ÷ 120 × 100 = 80 % (sur 30 % de tickets résolus ayant reçu une réponse : un échantillon à garder en tête) ;
• stock au 30 novembre : 46 + 412 − 398 = 60 tickets ouverts, en hausse de 14.

L'analyse que l'équipe en tire : le N1 absorbe les trois quarts des tickets, mais le stock grossit. Si la hausse continue en décembre, il faudra en chercher la cause (une catégorie qui augmente ? un groupe N2 surchargé ? des tickets en attente oubliés ?) dans les statistiques par catégorie et par groupe.

Lire un tableau de bord et décider

Un rapport mensuel regarde en arrière. Le tableau de bord sert à piloter la semaine : Inès l'ouvre chaque lundi matin. Voici celui du lundi 7 décembre 2026 à 9 h.

Chaque ligne appelle une question, puis une décision.

• Le stock monte pour la deuxième fois (46, puis 60, puis 71) et les entrées dépassent la moyenne de 16 tickets. Ce n'est plus un accident. D'où viennent les tickets en plus ? La ligne Wi-Fi répond en partie.
• 18 tickets Wi-Fi à Vénissieux en une semaine : une série, donc un problème à ouvrir, avec les tickets liés (chapitre 5). Traiter chaque ticket séparément ferait monter le stock sans rien régler.
• 6 retards sur 9 au groupe Applications : un engorgement local. Inès vérifie l'OLA du groupe et la charge de Nadia (une livraison en cours ?), puis réaffecte ou repousse une tâche de projet.
• 12 tickets en attente depuis plus de 5 jours : ils sortent du chrono du SLA mais pas de la tête des utilisateurs, et la satisfaction baisse. Décision : une relance automatique au bout de 2 jours, et une clôture après trois relances sans réponse, annoncée à l'utilisateur.

Un tableau de bord utile tient sur un écran, compare chaque valeur à un repère (la semaine précédente, la moyenne, l'objectif) et débouche sur des actions avec un responsable. Un compteur que personne ne regarde ou qui ne déclenche jamais de décision peut être retiré.

Interroger la base de GLPI en SQL

GLPI enregistre ses données dans une base MySQL ou MariaDB. Pour une question que les statistiques intégrées ne couvrent pas, une requête SQL avec COUNT et GROUP BY (cours SQL) donne la réponse. On l'exécute sur une copie de la base ou avec un compte en lecture seule, jamais en écrivant dans la base de production.

Les tickets sont dans la table glpi_tickets. Les colonnes utiles ici : date (ouverture), solvedate (résolution), time_to_resolve (échéance de résolution calculée par le SLA), priority (de 1, très basse, à 5, très haute, et 6 pour majeure), itilcategories_id (la catégorie) et is_deleted (1 pour un ticket mis à la corbeille). Les noms complets des catégories sont dans glpi_itilcategories.completename.

Le nombre de tickets ouverts en novembre par catégorie, de la plus chargée à la moins chargée :

SELECT c.completename AS categorie, COUNT(*) AS nb_tickets
FROM glpi_tickets AS t
LEFT JOIN glpi_itilcategories AS c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.date >= '2026-11-01' AND t.date < '2026-12-01'
GROUP BY c.completename
ORDER BY nb_tickets DESC;

Trois détails comptent. La jointure externe (LEFT JOIN) garde les tickets sans catégorie, qui sortent sur une ligne à NULL : un chiffre à surveiller, car ce sont des tickets mal qualifiés. La borne < '2026-12-01' inclut toute la journée du 30 novembre, ce que <= '2026-11-30' ne ferait pas avec des dates qui portent une heure. Et le filtre is_deleted = 0 écarte la corbeille.

MTBF, MTTR et disponibilité

Pour un service (et non plus pour les tickets), trois indicateurs mesurent la fiabilité.

Exemple : sur 30 jours (720 heures), le serveur de messagerie a connu 3 pannes de 2 h, 1 h et 3 h.

• Durée totale des pannes : 6 h. MTTR = 6 ÷ 3 = 2 h.
• Temps de fonctionnement : 720 − 6 = 714 h. MTBF = 714 ÷ 3 = 238 h.
• Disponibilité = 238 ÷ (238 + 2) × 100 ≈ 99,17 %, soit aussi 714 ÷ 720 × 100.

Pour améliorer la disponibilité, deux leviers : moins de pannes (la gestion des problèmes et des changements font monter le MTBF) et des pannes plus courtes (la supervision, la base de connaissances, des procédures de redémarrage font baisser le MTTR).

Moyenne ou médiane ?

Un délai moyen se laisse tirer par quelques tickets très longs. Sur dix tickets résolus en 0,5 h, 0,5 h, 1 h, 1 h, 1 h, 1,5 h, 2 h, 2 h, 3 h et 40 h, la moyenne est de 5,25 h alors que neuf tickets sur dix sont réglés en 3 heures au plus. La médiane (la valeur du milieu, ici 1,25 h) ou un percentile (« 90 % des tickets résolus en moins de 3 h ») décrivent mieux l'expérience de la plupart des utilisateurs. Un bon tableau de bord montre les deux, et isole les tickets anormalement longs pour les analyser.

Les pièges des indicateurs

Un indicateur devient vite un objectif, et un objectif mal choisi pousse à mal travailler.

C'est l'effet pastèque du chapitre 7 : des indicateurs au vert et des utilisateurs mécontents. La parade est de suivre plusieurs indicateurs qui se contrôlent mutuellement, et de toujours regarder la satisfaction.

Exercices

SELECT t.priority AS priorite,
       COUNT(*) AS resolus,
       SUM(CASE WHEN t.solvedate <= t.time_to_resolve THEN 1 ELSE 0 END) AS dans_le_delai,
       ROUND(100.0 * SUM(CASE WHEN t.solvedate <= t.time_to_resolve THEN 1 ELSE 0 END)
             / COUNT(*), 1) AS taux_sla
FROM glpi_tickets AS t
WHERE t.is_deleted = 0
  AND t.solvedate >= '2026-11-01' AND t.solvedate < '2026-12-01'
  AND t.time_to_resolve IS NOT NULL
GROUP BY t.priority
ORDER BY t.priority DESC;