SLA vs XLA pour les dirigeants : comment créer un tableau…

Temps de lecture estimé : 13 minutes

Principaux points à retenir

• SLA vs XLA n’est pas un choix binaire. Les SLA mesurent les engagements opérationnels, tandis que les XLA mesurent l’expérience utilisateur, la productivité et l’impact métier.
• Des tableaux de bord SLA au vert peuvent encore masquer une mauvaise expérience collaborateur. Un ticket peut respecter les objectifs de réponse et de résolution tout en restant frustrant, perturbant ou exigeant beaucoup d’efforts pour l’utilisateur.
• Les DSI ont besoin d’un reporting ITSM combiné. Les meilleurs tableaux de bord combinent la fiabilité des SLA, l’efficacité du service desk, les données d’expérience XLA et les métriques de résultats métier.
• Le reporting d’expérience doit conduire à l’action. Les scores de satisfaction, le sentiment et les métriques d’effort ne créent de valeur que lorsqu’ils déclenchent une prise en charge, des améliorations et un suivi.
• Le reporting ITSM à destination des dirigeants doit raconter une histoire métier. Les dirigeants doivent savoir ce qui a changé, pourquoi c’est important, et quelle décision ou quel investissement est requis ensuite.

SLA vs XLA : pourquoi la conversation compte pour les DSI

SLA vs XLA est devenu un sujet important pour les DSI, car de nombreuses organisations IT peuvent afficher 95–99 % de conformité SLA alors que les employés décrivent toujours le support IT comme lent, pénible ou perturbant.

En ITSM, un SLA mesure si l’IT a respecté des objectifs de service convenus, tels que le temps de réponse, le temps de résolution ou la disponibilité. Un XLA mesure si les utilisateurs ont vécu une expérience positive, productive et sans friction.

Par conséquent, le meilleur reporting ITSM combine les deux :

• Les SLA pour la fiabilité opérationnelle, la responsabilisation et le contrôle.
• Les XLA pour l’expérience collaborateur, la productivité et les résultats métier.

La réussite opérationnelle n’équivaut pas toujours à la réussite de l’expérience. Un service peut être techniquement « dans le SLA » et pourtant sembler défaillant aux personnes qui en dépendent.

C’est important, car les recommandations ITIL en gestion des services cadrent la gestion des services autour de la co-création de valeur. Cela signifie que les dirigeants ont besoin de métriques de performance ITSM qui montrent les résultats, pas seulement l’activité.

Dans ce guide, nous expliquons ce que signifient les SLA et les XLA, en quoi ils diffèrent, pourquoi un reporting uniquement basé sur les SLA peut induire les DSI en erreur, et comment créer un tableau de bord KPI ITSM pour le reporting ITSM à destination des dirigeants et le reporting d’expérience.

Ce que signifie un SLA en ITSM

Un Service Level Agreement, ou SLA, est un engagement formel entre un prestataire de services et un client qui définit le niveau de service attendu, généralement au moyen d’objectifs mesurables.

En ITSM, un SLA fixe les attentes sur la manière dont les services IT doivent être fournis, mesurés et revus.

Exemples courants de SLA :

• Temps de réponse à un incident : délai entre la création du ticket et la première réponse du service desk.
• Temps de résolution d’un incident : délai entre la création du ticket et la résolution, le rétablissement ou le contournement.
• Disponibilité : pourcentage de temps pendant lequel un service clé est disponible.
• Délai de traitement des demandes : temps nécessaire pour exécuter des demandes standard, comme la fourniture d’un ordinateur portable ou la mise en place d’un accès.
• Objectifs de première réponse : délai maximal avant qu’un utilisateur reçoive une mise à jour.

Les SLA restent importants. Ils créent de la responsabilisation, soutiennent la gouvernance des fournisseurs et aident les responsables IT à gérer la fiabilité, l’efficacité et la cohérence.

De plus, des référentiels tels que ISO/IEC 20000 renforcent la nécessité de contrôles structurés de gestion des services et d’une qualité de service mesurable.

Cependant, les SLA ne racontent pas toute l’histoire. Ce sont des métriques de performance ITSM importantes, mais elles décrivent généralement si l’IT a atteint une cible, pas si l’utilisateur s’est senti soutenu.

Ainsi, dans le débat SLA vs XLA, les SLA restent essentiels pour le contrôle, tandis que les XLA apportent la vision d’expérience manquante.

Ce que signifie un XLA en ITSM

Un Experience Level Agreement, ou XLA, est un engagement à mesurer et améliorer la qualité de l’expérience utilisateur, et pas seulement à vérifier si l’IT a atteint un objectif opérationnel.

Là où les SLA demandent « L’IT a-t-elle atteint l’objectif ? », les XLA demandent « L’expérience a-t-elle été bonne pour l’employé, le client ou l’utilisateur métier ? »

Les XLA combinent souvent données et retours. Par exemple, ils peuvent inclure :

• Satisfaction client.
• Satisfaction des employés.
• Score d’effort client.
• Sentiment.
• Impact sur la productivité.
• Fiabilité perçue.

Ils sont aussi souvent basés sur des parcours plutôt que sur les seuls tickets. Des parcours utiles incluent : obtenir de l’aide de l’IT, intégrer un nouvel employé, demander un accès à une application, travailler à distance ou se remettre d’un incident majeur.

Pour des métriques XLA pratiques dans le reporting d’expérience ITSM, les équipes doivent relier les signaux de feedback à des parcours de service spécifiques et à des actions d’amélioration.

Le reporting d’expérience consiste à transformer les mesures XLA, les retours utilisateurs et les données de sentiment en rapports et tableaux de bord structurés qui rendent l’expérience collaborateur visible, comparable et actionnable.

C’est particulièrement important alors que le travail numérique devient central pour la performance de l’entreprise. Le hub de recherche IT de Gartner souligne comment les leaders technologiques se concentrent de plus en plus sur l’expérience du digital workplace, la productivité et la valeur.

Par conséquent, SLA vs XLA n’est pas seulement un sujet de reporting. C’est un sujet de leadership : l’IT permet-elle aux personnes de faire leur meilleur travail ?

Principales différences entre SLA et XLA

SLA vs XLA se comprend le mieux comme une comparaison entre le contrôle opérationnel et l’expérience utilisateur. Les deux sont utiles, mais répondent à des questions différentes.

Il est important que le XLA ne remplace pas le SLA. Les SLA restent nécessaires pour maintenir des services stables et responsables. Cependant, les XLA sont nécessaires pour comprendre si ces services aident réellement les utilisateurs à travailler efficacement.

Forrester relie régulièrement l’expérience technologique aux résultats des employés et de l’entreprise.

Ainsi, un reporting ITSM mature combine les deux : les SLA fournissent des indicateurs de fiabilité et d’efficacité, tandis que les XLA fournissent des indicateurs d’expérience collaborateur et d’impact métier.

Pourquoi un reporting uniquement basé sur les SLA peut induire les DSI en erreur

De nombreux DSI voient des tableaux de bord SLA au vert, alors que les retours des employés, le sentiment métier ou le volume d’escalades racontent une tout autre histoire.

Cela arrive parce qu’un reporting uniquement basé sur les SLA peut créer un faux sentiment de sécurité.

Par exemple, un ticket peut être résolu dans les délais, mais demander trop d’efforts à l’utilisateur. L’utilisateur peut répéter les mêmes informations à trois agents. De même, la communication peut être mauvaise. Le ticket reste dans le SLA, mais l’utilisateur ne reçoit aucune mise à jour claire et perd confiance.

Les problèmes récurrents sont un autre problème fréquent. Un service desk peut clôturer rapidement le même incident applicatif à chaque fois, mais la gestion des problèmes ne supprime jamais la cause racine.

De plus, des interruptions courtes mais fréquentes peuvent ne pas dépasser les objectifs de disponibilité, tout en dégradant la productivité et la confiance des utilisateurs.

C’est important pour les DSI, car un reporting ITSM exécutif uniquement basé sur les SLA peut sous-estimer le risque métier. Il peut aussi masquer les frictions qui alimentent le shadow IT, une faible adoption et de mauvais résultats du digital workplace.

Les recommandations de HDI rappellent souvent que la performance d’un centre de support doit inclure la satisfaction et l’expérience de service, pas seulement l’activité de traitement des tickets.

Des métriques opérationnelles au vert peuvent encore masquer une expérience utilisateur au rouge.

Ainsi, SLA vs XLA est un avertissement pratique : si les dirigeants ne mesurent que les objectifs de service, ils peuvent passer à côté de ce que l’IT fait réellement ressentir au métier.

Pourquoi les XLA comptent pour l’ITSM moderne

Les XLA donnent aux responsables IT de la visibilité sur la manière dont les services affectent les personnes, la productivité et la performance de l’entreprise. Ils aident ainsi l’IT à passer d’une fonction de clôture de tickets à un facilitateur de l’expérience métier.

Les principaux bénéfices sont clairs :

• Meilleure visibilité sur le sentiment des utilisateurs à travers les services, les canaux et les parcours.
• Alignement renforcé avec les résultats métier tels que la productivité, l’adoption et la continuité.
• Amélioration continue plus pertinente, car les équipes se concentrent sur les frictions réellement ressenties par les utilisateurs.
• Confiance renforcée entre l’IT et le métier, car le feedback est mesuré et pris en compte.
• Meilleures décisions d’investissement pour l’automatisation, le self-service, la gestion des connaissances et la conception de services.
• Conversations exécutives plus pertinentes sur le risque, la productivité et les tendances d’expérience.

Cependant, les XLA ne fonctionnent que s’ils déclenchent des actions. Un score de satisfaction n’est pas utile si personne ne porte l’amélioration. De même, les données d’effort sont faibles si elles ne sont pas liées à une refonte des parcours.

Les métriques de performance ITSM modernes doivent donc montrer à la fois le contrôle et l’expérience. Les SLA expliquent si les services ont respecté leurs engagements. Le reporting d’expérience, lui, explique si les utilisateurs ont pu travailler facilement, en confiance et de manière productive.

Métriques de performance ITSM clés à suivre

Les métriques de performance ITSM modernes doivent combiner des SLA opérationnels et des XLA orientés expérience. Cependant, le bon ensemble dépend du public, de l’objectif du reporting, de la maturité des services, de la criticité métier et de la qualité des données.

Métriques opérationnelles traditionnelles

• Volume d’incidents.
• Mean Time to Resolve, ou MTTR.
• First Contact Resolution, ou FCR.
• Conformité SLA.
• Volume de backlog et ancienneté du backlog.
• Taux de réouverture.
• Fréquence et durée des incidents majeurs.
• Taux de réussite des changements ou taux d’échec des changements.
• Délai de traitement des demandes.

Ces métriques aident à gérer la capacité, la stabilité, la qualité de service et la performance des fournisseurs. Les recommandations ITSM d’Atlassian montrent également comment les équipes de gestion des services utilisent des métriques opérationnelles pour améliorer la prestation de services et les workflows.

Métriques orientées expérience

• Satisfaction client ou satisfaction des employés.
• Score d’effort des employés ou score d’effort client.
• Sentiment utilisateur issu des commentaires et retours.
• Score d’expérience pour un service ou un parcours.
• Perte de productivité due aux incidents ou à des processus inefficaces.
• Expérience par canal (téléphone, chat, portail, e-mail et self-service).
• Adoption du self-service.
• Utilité des articles de connaissance.

Pour éviter la surcharge de métriques, les dirigeants devraient voir un petit nombre d’indicateurs stratégiques. Les équipes opérationnelles, elles, peuvent utiliser des données plus granulaires.

De plus, toute métrique qui ne soutient pas une décision devrait être supprimée.

Métriques de service desk pour le reporting DSI

Les métriques de service desk les plus utiles pour le reporting DSI ne sont pas les mêmes que celles dont un responsable d’équipe a besoin pour gérer les files en temps réel. Les DSI ont besoin de moins de métriques, mais de plus de contexte.

Le reporting de service desk au niveau DSI doit se concentrer sur l’impact métier, le risque, l’expérience utilisateur, l’efficience des coûts, la fiabilité des services, la performance des tendances et les opportunités d’amélioration.

Ainsi, un tableau de bord DSI ne doit pas ressembler à une console de service desk.

Les métriques de service desk recommandées pour le reporting DSI incluent :

• Tendances de satisfaction des utilisateurs par service, région ou unité métier.
• Volume de tickets par unité métier, service ou site.
• Principaux problèmes récurrents et leur statut d’amélioration.
• Conformité SLA et scores XLA côte à côte.
• Tendances d’escalade, y compris les plaintes des managers et les taux de réaffectation.
• Coût par ticket et coût par canal.
• Adoption de l’automatisation et du self-service.
• Impact des incidents sur la productivité.
• Impact des incidents majeurs, y compris les utilisateurs affectés et la qualité de rétablissement.
• Risque lié au backlog, y compris les tickets anciens et critiques pour le métier.

Chaque métrique DSI doit répondre à trois questions : Qu’est-ce qui a changé ? Pourquoi est-ce important ? Quelle action est requise ?

Par conséquent, les métriques de service desk pour le reporting DSI doivent relier les données opérationnelles au reporting d’expérience et au reporting ITSM exécutif.

Pour un cadre KPI de service desk plus large, du SLA au time-to-value, les dirigeants peuvent relier les mesures opérationnelles à l’impact métier plutôt que de revoir l’activité des tickets de manière isolée.

Sans ce contexte, les chiffres peuvent être exacts mais rester inutiles.

Ce qu’un tableau de bord KPI ITSM doit inclure

Un tableau de bord KPI ITSM est un outil de reporting visuel qui rassemble les principales métriques de gestion des services afin que les équipes et les dirigeants puissent comprendre la santé des services, la performance, le risque et l’expérience utilisateur.

Cependant, la conception d’un tableau de bord doit toujours commencer par le public.

Vue tableau de bord opérationnelle

Les équipes opérationnelles ont besoin de détails en temps réel. Leur tableau de bord peut inclure :

• Tickets ouverts par priorité.
• SLA non respectés.
• SLA à risque.
• Statut des files.
• Charge de travail des agents.
• Temps d’attente.
• Chronologies des incidents prioritaires.
• Volumes par canal.
• Utilisation de la base de connaissances.
• Ancienneté du backlog.

Vue tableau de bord exécutive

Les dirigeants ont besoin de tendances, de contexte et d’insights prêts à la décision. Leur tableau de bord doit inclure :

• Indice global de santé des services.
• Score d’expérience utilisateur par service ou unité métier.
• Comparaison de performance SLA vs XLA.
• Satisfaction et demande par unité métier.
• Impact des incidents majeurs.
• Initiatives d’amélioration et suivi des bénéfices.
• Risques et tendances des services.

ServiceNow positionne l’analytique et le reporting ITSM comme importants pour la visibilité, l’amélioration des workflows et une meilleure prise de décision.

Ainsi, un tableau de bord KPI ITSM ne doit pas seulement montrer ce qui s’est passé. Il doit aussi expliquer ce qui compte ensuite.

Les bons tableaux de bord utilisent une hiérarchie visuelle claire, montrent des tendances sur 3, 6 et 12 mois, ajoutent des commentaires, évitent les vanity metrics et relient la performance à des résultats métier tels que la productivité, le risque, le coût, la conformité et l’expérience collaborateur.

Les équipes qui construisent un modèle de tableau de bord ITSM pratique devraient commencer par des vues prêtes à la décision avant d’ajouter des drill-downs opérationnels détaillés.

Le reporting ITSM exécutif dont les dirigeants ont réellement besoin

Le reporting ITSM exécutif consiste à présenter la performance de la gestion des services IT dans un format concis et orienté métier, qui aide les dirigeants à comprendre la santé des services, le risque, l’expérience utilisateur, les coûts et les décisions requises.

Un reporting exécutif solide raconte une histoire métier. Il doit répondre à :

• Les services IT soutiennent-ils la productivité métier ?
• Où les utilisateurs rencontrent-ils des frictions ?
• Les niveaux de service s’améliorent-ils ou se dégradent-ils ?
• Quels services ou unités métier sont à risque ?
• Quels problèmes récurrents nécessitent un investissement ou un soutien exécutif ?
• Quelles améliorations ont été livrées ?
• Quelles décisions sont requises de la part de la direction ?

Pour cela, combinez plusieurs composantes de reporting.

• D’abord, incluez la performance SLA comme la disponibilité, le MTTR, les tendances d’incidents, la conformité SLA et la réussite des changements.
• Ensuite, ajoutez des insights XLA comme la satisfaction, l’effort, le sentiment et la perte de productivité.
• Puis, ajoutez un contexte financier comme le coût par ticket, le coût par canal, les économies d’automatisation et le ROI des améliorations.
• Enfin, ajoutez des indicateurs de risque et des commentaires en langage clair sur l’impact métier.

Une structure simple aide : What, So What, Now What.

Qu’est-ce qui a changé dans les données ? Qu’est-ce que cela signifie pour le métier ? Quelle action, décision ou quel investissement est recommandé maintenant ?

Ainsi, le reporting ITSM exécutif devient un outil de décision, pas un dump de données.

Comment passer du reporting SLA au reporting d’expérience

Le passage d’un reporting uniquement basé sur les SLA à un reporting XLA et d’expérience doit être traité comme un parcours de maturité, et non comme un changement « big bang ».

Un chemin de transition pratique est :

1. Auditer les SLA et métriques ITSM actuels. Identifier ce qui est mesuré, qui utilise chaque rapport et quelle décision chaque métrique soutient.
2. Comparer la performance opérationnelle avec la satisfaction. Rechercher des résultats SLA au vert avec une faible satisfaction ou un effort élevé.
3. Définir les expériences les plus importantes. Commencer par des parcours comme l’onboarding, l’obtention d’aide, la demande d’accès, le travail à distance et la reprise après incident majeur.
4. Sélectionner des mesures XLA pertinentes. Utiliser la satisfaction, l’effort, le temps jusqu’à la productivité, l’adoption, le sentiment et la fiabilité perçue.
5. Ajouter des mécanismes de feedback. Utiliser des enquêtes courtes, des enquêtes par parcours et l’analyse des retours en texte libre.
6. Intégrer le reporting d’expérience dans le tableau de bord KPI ITSM. Afficher les métriques XLA à côté des métriques SLA.
7. Aligner le reporting ITSM exécutif sur les résultats métier. Mettre en avant la santé des services, l’expérience utilisateur, le risque et l’impact métier.
8. Revoir et affiner les métriques régulièrement. Retirer les KPI à faible valeur et ajuster les seuils à mesure que la maturité progresse.

Commencer petit. Choisir un ou deux parcours à forte valeur, prouver la valeur, puis étendre.

Ainsi, les équipes renforcent la confiance dans les données et la confiance dans le modèle SLA/XLA combiné.

Erreurs courantes lors de l’adoption des XLA

Plusieurs erreurs peuvent affaiblir l’adoption des XLA. Heureusement, elles sont évitables.

• Mesurer trop de KPI. Trop de métriques diluent la focalisation et rendent le reporting plus difficile à mettre en action. À la place, commencez par un ensemble concis de mesures à fort impact.
• Traiter les XLA comme un remplacement des SLA. Les SLA restent nécessaires pour la stabilité opérationnelle, la responsabilisation et la gestion des fournisseurs. L’objectif est un reporting SLA et XLA équilibré.
• Reporter des métriques sans contexte métier. Les chiffres seuls ne disent pas aux dirigeants quoi faire. Ajoutez une interprétation, l’impact et l’action recommandée.
• Collecter des données d’enquête sans agir. Si les utilisateurs ne voient aucune amélioration, la confiance dans les enquêtes et les taux de réponse chutent. Fermez la boucle de feedback en montrant ce qui a changé.
• Concevoir un tableau de bord exécutif pour des équipes IT. Un tableau de bord DSI doit se concentrer sur les résultats, le risque et les décisions, pas sur la gestion des files.
• Se concentrer uniquement sur la clôture des tickets. Une clôture rapide ne garantit pas une bonne expérience. Un meilleur reporting d’expérience équilibre le débit avec la satisfaction, l’effort, la communication et la qualité de résolution.

Les programmes XLA les plus solides ne sont pas seulement des programmes de mesure. Ce sont des systèmes d’amélioration.

Exemple pratique de service desk : SLA vs XLA

Considérez un utilisateur qui ouvre un ticket parce qu’il ne peut pas accéder à une application finance clé pendant le reporting de fin de mois.

Du point de vue SLA uniquement, la performance semble bonne :

• La première réponse a été donnée en moins de 30 minutes.
• Le ticket a été résolu en moins de 4 heures.
• Le statut SLA est au vert.

Cependant, la vue XLA raconte une autre histoire :

• L’utilisateur a dû appeler deux fois pour obtenir une mise à jour.
• Le formulaire du portail était confus.
• Le problème a bloqué le reporting de fin de mois.
• La correction a fonctionné, mais l’utilisateur a perdu une demi-journée de productivité.
• Le score d’effort utilisateur était mauvais.

L’interprétation combinée est plus utile. Le SLA montre que le service desk a atteint son objectif. Cependant, le XLA montre que l’expérience était très frictionnelle et perturbante pour le métier.

C’est pourquoi les métriques de service desk pour le reporting DSI doivent inclure à la fois des mesures opérationnelles et des mesures d’expérience.

L’opportunité d’amélioration peut inclure une communication plus claire, de meilleurs formulaires de demande, de meilleurs articles de connaissance, de l’automatisation ou une analyse des causes racines.

Ainsi, SLA vs XLA aide les dirigeants à voir non seulement si l’IT a performé, mais si l’IT a aidé le métier à continuer à travailler.

Un cadre de reporting DSI pour SLA et XLA

Un cadre de reporting SLA/XLA pratique comporte quatre couches.

Couche 1 : fiabilité opérationnelle

Les métriques incluent la disponibilité, la conformité SLA, le MTTR, les incidents majeurs et le taux de réussite des changements. Cela confirme si les services IT sont stables et prévisibles.

Couche 2 : efficacité du service desk

Les métriques incluent le volume de tickets, la résolution au premier contact, le backlog, le coût par ticket et l’adoption du self-service. Cela montre si le support est efficace et scalable.

Couche 3 : expérience utilisateur

Les métriques incluent la satisfaction, le score d’effort, le sentiment, l’expérience par canal et le score d’expérience par parcours. Cela montre si les utilisateurs ont une expérience positive et sans friction.

Couche 4 : impact métier

Les métriques incluent la perte de productivité, l’impact par unité métier, l’exposition au risque, les bénéfices des améliorations, l’évitement de coûts et le ROI. Cela relie les métriques de performance ITSM à la valeur métier.

Un tableau de bord KPI ITSM peut montrer les quatre couches, mais les différentes parties prenantes doivent voir des niveaux de détail différents. Les responsables opérationnels ont besoin de profondeur. Les DSI, eux, ont besoin de tendances, d’exceptions, de risques et de décisions.

Revu mensuellement ou trimestriellement, ce cadre soutient un meilleur reporting ITSM exécutif, des métriques de service desk plus claires pour la prise de décision DSI, et une vision équilibrée de la performance SLA vs XLA.

Conclusion

La conversation SLA vs XLA ne consiste pas à choisir l’un plutôt que l’autre.

Les SLA mesurent si l’IT a respecté les objectifs de service convenus. Les XLA mesurent si les utilisateurs ont eu une expérience positive, productive et sans friction. Par conséquent, le reporting ITSM moderne a besoin à la fois de performance opérationnelle et d’insights d’expérience.

Les DSI ont besoin de métriques de performance ITSM équilibrées, d’un reporting d’expérience clair, de métriques de service desk pertinentes pour la prise de décision DSI, d’un tableau de bord KPI ITSM bien conçu et d’un reporting ITSM exécutif concis.

Pour les organisations qui cherchent à moderniser le reporting ITSM, SMC Consulting peut aider à évaluer les métriques actuelles, identifier les écarts SLA/XLA, repenser les tableaux de bord et construire un reporting qui parle le langage des résultats métier.

À propos de l’auteur

Questions fréquemment posées