Une entreprise peut respecter 95 % de ses SLA, afficher une satisfaction supérieure à 4/5 et réduire son temps moyen de résolution, tout en continuant à recevoir des plaintes des utilisateurs. Certains doivent relancer le support, répéter plusieurs fois leur demande ou passer par plusieurs interlocuteurs avant d’obtenir une solution.
SLA respectés, utilisateurs mécontents : pourquoi votre tableau de bord ITSM cache encore les vrais problèmes
Le problème ne vient pas forcément des indicateurs eux-mêmes, mais de la manière dont ils sont présentés. Lorsqu’ils sont analysés séparément, ils montrent qu’un délai a été respecté, sans expliquer si la résolution a réellement été simple, efficace et utile pour l’utilisateur.
📊 Ce que vous devez retenir de cette thématique :
SLA, XLA et performance ITSM
Lire aussi cet article sur l’univers de la maintenance industrielle et ses solutions numériques innovantes
SLA ou XLA : les indicateurs qui révèlent enfin l’expérience réelle des utilisateurs en ITSM
Ajouter des XLA — indicateurs centrés sur l’expérience utilisateur — à un tableau de bord SLA ne suffit pas. Chaque résultat doit permettre de comprendre une situation, d’en identifier la cause et de décider d’une action d’amélioration.
Respecter les SLA ne signifie pas résoudre le problème
- La résolution est conforme, mais incomplète
Le ticket est fermé dans les délais, puis rouvert parce que la cause n’a pas été traitée, ou parce que la réponse ne permet pas à l’utilisateur de reprendre réellement son activité.
- Le délai est acceptable, mais le parcours est pénible
La demande est résolue rapidement, mais l’utilisateur a dû répéter son problème, changer de canal, relancer le support et passer par plusieurs agents avant d’obtenir une réponse.
- Le SLA est atteint, mais l’impact métier reste trop élevé
Un incident peut être résolu dans le délai contractuel tout en bloquant une équipe commerciale, une chaîne de production ou un processus d’onboarding. Le contrat est tenu ; le résultat métier ne l’est pas.
Le respect du délai ne permet donc pas de distinguer une résolution durable, une expérience fluide et un résultat métier acceptable.
Pour obtenir cette lecture, il faut relier les engagements de service aux données sur le parcours utilisateur et à l’impact réel sur l’activité. Un cabinet de conseil ITSM peut aider à structurer ces indicateurs avant leur intégration dans le tableau de bord.
Le problème n’est pas de manquer de KPI, mais de mesurer sans relation de cause à effet
Un tableau de bord classique juxtapose souvent le respect des SLA, la satisfaction, le volume de tickets, le temps de résolution et l’usage du portail. Présentés côte à côte, ces indicateurs décrivent un état, mais ne répondent pas aux questions qui comptent :
- la satisfaction baisse-t-elle à cause du délai ou du nombre d’interactions ?
- les tickets sont-ils rouverts après une résolution trop rapide ?
- le portail réduit-il réellement l’effort ou déplace-t-il simplement la demande ?
- les incidents les plus fréquents sont-ils aussi ceux qui ont le plus d’impact ?
Un indicateur isolé décrit un résultat. Le croisement de plusieurs signaux commence, lui, à expliquer sa cause.
Réouvertures, réassignations et relances révèlent ce que le temps de résolution efface
Taux de réouverture — il montre si la résolution annoncée a réellement restauré le service, ou si elle n’a fait que fermer le ticket.
Nombre de réassignations — il révèle les erreurs de catégorisation, de routage ou de responsabilité qui allongent le parcours.
Nombre d’interactions — il mesure l’effort nécessaire pour obtenir une réponse, même lorsque le délai final reste correct.
Temps d’attente entre deux interventions — il distingue le temps de traitement réel du temps pendant lequel le ticket reste simplement immobilisé.
Changement de canal — un utilisateur qui commence sur le portail et termine par téléphone signale souvent un échec du parcours initial.
Ces données ne sont pas de simples KPI supplémentaires : elles servent à expliquer la différence entre le délai enregistré et l’expérience vécue.
Un XLA qui ne déclenche aucune décision devient un indicateur décoratif
Pour chaque indicateur d’expérience, trois éléments doivent être définis avant de l’afficher : le signal observé, le seuil qui justifie une investigation et l’action susceptible d’être engagée.
| ✓ Pour chaque XLA, définir :
✓ Le signal observé ✓ Le seuil qui justifie une investigation ✓ L’action susceptible d’être engagée |
| Signal | Diagnostic possible | Action |
| Réouvertures élevées | Résolution superficielle | Revoir les critères de clôture |
| Réassignations fréquentes | Mauvais routage | Corriger les catégories et règles d’affectation |
| Effort utilisateur élevé | Parcours trop complexe | Simplifier le formulaire ou les validations |
| Abandon du portail | Self-service inefficace | Revoir la recherche et la base de connaissances |
| SLA respecté, impact élevé | Engagement mal calibré | Revoir les priorités selon la criticité métier |
La règle est simple : si l’équipe ne sait pas ce qu’elle fera lorsqu’un indicateur passe au rouge, cet indicateur n’est pas encore prêt à entrer dans le tableau de bord.
Le même KPI ne doit pas raconter la même histoire au service desk et à la direction
Pour le service desk
Le tableau de bord doit indiquer où intervenir immédiatement : files bloquées, tickets réassignés, résolutions suivies d’une réouverture, demandes nécessitant trop d’interactions.
Pour le responsable de service
Il doit faire apparaître les défauts structurels : parcours défaillant, service mal catégorisé, engagement inadapté, problème récurrent, canal peu performant.
Pour la direction
Il doit répondre à trois questions : quels services affectent le plus les métiers, quelles dégradations sont récurrentes, et quelles améliorations méritent un investissement. L’enjeu n’est pas de créer trois vérités différentes, mais trois niveaux de lecture reposant sur les mêmes données.
Votre outil ITSM collecte-t-il les données nécessaires pour expliquer l’expérience ?
Un tableau de bord SLA/XLA crédible suppose que la plateforme conserve bien plus que l’état final du ticket :
- chaque changement d’affectation ;
- les ouvertures et réouvertures ;
- les périodes d’attente ;
- l’historique multicanal ;
- les articles consultés avant la création du ticket ;
- le service métier concerné et le nombre d’utilisateurs affectés ;
- le moment réel du retour à la productivité.
Selon le niveau de maturité de l’entreprise, il peut aussi être utile de suivre les articles consultés avant la création du ticket ou le moment estimé du retour à la productivité.
La difficulté n’est donc pas seulement de créer un rapport : elle consiste à structurer les services, les workflows et les données qui permettent de relier performance opérationnelle et expérience. Les plateformes de gestion des services informatiques doivent être configurées pour relier l’historique du ticket, le parcours utilisateur et l’impact réel sur l’activité.
Testez le tableau de bord sur une anomalie réelle avant de le généraliser
Plutôt que de « commencer petit » de façon vague, éprouvez le dispositif sur un cas précis. Exemple : une équipe commerciale juge le support trop lent alors que 96 % des SLA sont respectés. L’analyse croisée montre un délai de résolution correct, mais trois réassignations en moyenne, plusieurs demandes d’informations déjà fournies et un recours fréquent au téléphone après une demande créée sur le portail.
Hypothèse — la perception de lenteur ne vient pas du délai total, mais de la fragmentation du parcours.
Action : simplifier le formulaire, revoir les catégories, automatiser le routage et conserver le contexte lors du changement de canal. Puis mesurer, après intervention, la baisse des réassignations, la diminution du nombre d’interactions, la réduction des appels de relance et l’amélioration de l’effort déclaré.
Le tableau de bord démontre alors sa valeur : il ne constate pas seulement une insatisfaction, il aide à en identifier la cause.
Conclusion : le tableau de bord le plus utile n’est pas celui qui contient le plus de KPI
Les SLA restent indispensables pour vérifier la tenue des engagements opérationnels. Les XLA complètent cette lecture en révélant l’effort, la perception et l’impact vécus par les utilisateurs. Mais la maturité du pilotage ne dépend pas du nombre d’indicateurs affichées : elle dépend de la capacité de l’organisation à transformer un signal en diagnostic, puis un diagnostic en action d’amélioration.
Par l’équipe conseil de SMC Consulting — praticiens certifiés ITIL 4, spécialistes de l’implémentation et de la gouvernance des plateformes de gestion des services informatiques.
Completez votre lecture avec cet article sur tirer profit de l’intelligence artificielle pour gagner du temps, réduire les coûts et améliorer la productivité
