Piloter une direction des systèmes d’information ne consiste plus seulement à maintenir les infrastructures en fonctionnement. La DSI doit garantir la disponibilité des services, améliorer l’expérience utilisateur, maîtriser les coûts informatiques, limiter les risques cyber et démontrer sa contribution aux objectifs de l’entreprise.
Pour répondre à ces enjeux, les KPI de pilotage informatique doivent transformer les données techniques et financières en informations directement exploitables. Selon l’ISACA, les indicateurs permettent notamment aux instances de gouvernance de suivre l’atteinte des objectifs métiers et IT, puis d’orienter leurs décisions. Chaque KPI doit néanmoins être associé à un objectif, une méthode de calcul, une source de données et une fréquence de suivi clairement définis.
Voici dix indicateurs IT pour DSI permettant de construire un tableau de bord équilibré, lisible et orienté vers l’action.
Ce qu’il mesure : la proportion du temps pendant laquelle un service IT est accessible et fonctionne conformément aux conditions convenues.
Pourquoi il est important : une indisponibilité peut bloquer les collaborateurs, interrompre une activité commerciale ou dégrader l’expérience client. L’indicateur doit donc porter sur le service rendu de bout en bout, et pas uniquement sur la disponibilité de chaque composant technique. Cette approche correspond davantage à la perception réelle des utilisateurs.
Calcul :
Disponibilité (%) = (temps de service prévu − temps d’indisponibilité) / temps de service prévu × 100
Point de vigilance : définir précisément la période de service, les interruptions exclues, les fenêtres de maintenance et les services considérés comme critiques.
Ce qu’il mesure : la proportion du temps pendant laquelle un service IT est accessible et fonctionne conformément aux conditions convenues.
Pourquoi il est important : une indisponibilité peut bloquer les collaborateurs, interrompre une activité commerciale ou dégrader l’expérience client. L’indicateur doit donc porter sur le service rendu de bout en bout, et pas uniquement sur la disponibilité de chaque composant technique. Cette approche correspond davantage à la perception réelle des utilisateurs.
Calcul :
Disponibilité (%) = (temps de service prévu − temps d’indisponibilité) / temps de service prévu × 100
Point de vigilance : définir précisément la période de service, les interruptions exclues, les fenêtres de maintenance et les services considérés comme critiques.
Ce qu’il mesure : la part des incidents qui se reproduisent sur un périmètre donné après une première résolution.
Pourquoi il est important : un nombre élevé d’incidents récurrents peut révéler des corrections temporaires, une gestion des problèmes insuffisante ou une dette technique persistante.
Calcul :
Taux d’incidents récurrents = incidents récurrents / nombre total d’incidents × 100
Point de vigilance : la qualité du résultat dépend de la catégorisation des tickets et de la capacité à relier plusieurs incidents à une cause commune. Cet indicateur doit être analysé avec le volume d’incidents, leur criticité et leur impact métier.
Ce qu’il mesure : la proportion des demandes et incidents traités dans les niveaux de service convenus.
Pourquoi il est important : le respect des SLA permet de vérifier que les engagements pris auprès des métiers, des clients ou des partenaires sont tenus. Ces engagements doivent reposer sur des objectifs mesurables, par exemple en matière de disponibilité, de prise en charge ou de résolution.
Calcul :
Respect des SLA (%) = dossiers traités dans le délai convenu / dossiers soumis à un SLA × 100
Point de vigilance : une moyenne globale peut masquer des écarts importants. Il est préférable de segmenter le résultat par criticité, service, entité ou fournisseur.
Ce qu’il mesure : la part des demandes résolues dès le premier échange avec le support, sans transfert ni réouverture.
Pourquoi il est important : cet indicateur renseigne sur l’autonomie du centre de services, la qualité de la base de connaissances et la fluidité du parcours utilisateur.
Calcul :
Résolution au premier contact (%) = demandes résolues au premier contact / demandes éligibles × 100
Point de vigilance : exclure les demandes qui nécessitent structurellement une expertise de niveau supérieur. Une recherche excessive de rapidité ne doit pas conduire à fermer prématurément les tickets.
Ce qu’il mesure : la perception des utilisateurs concernant le support, les outils numériques ou un service IT particulier.
Pourquoi il est important : des indicateurs techniques satisfaisants ne garantissent pas une bonne expérience. La satisfaction utilisateur permet d’identifier les irritants que les métriques d’infrastructure ou de ticketing ne font pas apparaître.
Suivi possible : utiliser une question simple après la clôture d’un ticket, par exemple une notation de 1 à 5, puis calculer la moyenne ou la part de réponses positives.
Point de vigilance : surveiller le taux de réponse et analyser les commentaires qualitatifs. Un score obtenu sur un échantillon trop faible ne doit pas être généralisé.
Temps de réponse, résolution au premier contact et satisfaction : découvrez comment structurer des services utilisateurs plus réactifs, plus accessibles et mieux adaptés aux besoins des collaborateurs.
Ce qu’il mesure : la différence entre les dépenses informatiques budgétées et les dépenses effectivement engagées.
Pourquoi il est important : cet indicateur aide la DSI à anticiper les dépassements, ajuster ses prévisions et expliquer les variations liées aux licences, aux prestataires, au cloud ou aux projets.
Calcul :
Écart budgétaire (%) = (dépenses réelles − budget prévu) / budget prévu × 100
Point de vigilance : distinguer les dépenses récurrentes, les investissements et les coûts exceptionnels. Un budget respecté n’indique pas, à lui seul, que les ressources ont été utilisées efficacement.
Ce qu’il mesure : le coût technologique rapporté à une unité représentative de l’activité : utilisateur, transaction, client, commande, dossier traité ou produit numérique.
Pourquoi il est important : ce KPI relie les coûts informatiques au volume d’activité et facilite les comparaisons dans le temps. La FinOps Foundation recommande notamment de suivre des coûts unitaires par client, transaction, charge de travail, poste ou service lorsque ces unités correspondent au modèle économique de l’organisation.
Calcul :
Coût IT unitaire = coûts IT du périmètre / nombre d’unités produites ou consommées
Point de vigilance : choisir une unité stable et utile à la décision. Les règles d’allocation des coûts mutualisés doivent également être documentées.
Ce qu’il mesure : le temps moyen entre le début estimé d’un événement de sécurité et sa détection par l’organisation.
Pourquoi il est important : une détection plus rapide permet d’engager plus tôt les actions de réponse et de limitation de l’impact. Le NIST identifie les délais de détection, de réponse et de récupération parmi les mesures utiles au suivi des capacités de cybersécurité.
Calcul :
Délai moyen de détection = somme des délais de détection / nombre d’incidents analysés
Point de vigilance : le début réel d’un incident n’est pas toujours connu avec précision. Il faut donc documenter les hypothèses et suivre également la médiane, moins sensible aux événements exceptionnellement longs.
Centralisation des événements, détection des anomalies, suivi des KPI et réponse aux incidents : découvrez comment un SOC permet de mesurer et d’améliorer en continu les capacités de protection du système d’information.
Ce qu’il mesure : la proportion des bénéfices métier effectivement obtenus par rapport aux résultats définis lors du lancement d’un projet.
Pourquoi il est important : cet indicateur dépasse le simple respect du budget ou du calendrier. Il évalue l’alignement stratégique de la DSI à travers des résultats tels qu’un gain de productivité, une réduction des risques, une amélioration du parcours client ou une augmentation de la capacité opérationnelle. L’ISACA recommande de relier les objectifs IT aux objectifs de l’entreprise et d’associer chaque objectif prioritaire à des indicateurs et à des cibles.
Calcul :
Atteinte des bénéfices (%) = bénéfices constatés / bénéfices ciblés × 100
Lorsque plusieurs bénéfices sont attendus, une pondération peut être appliquée selon leur importance stratégique.
Point de vigilance : les bénéfices doivent être définis avant le projet, avec une valeur initiale, une cible, un responsable métier et une date de mesure. La DSI ne doit pas être seule responsable de résultats qui dépendent aussi de l’adoption et de la transformation des processus.
Un tableau de bord DSI efficace ne doit pas accumuler toutes les données disponibles. Il doit présenter un nombre limité de KPI de pilotage informatique, équilibrés entre performance opérationnelle, qualité de service, coûts, cybersécurité, satisfaction utilisateur et contribution métier.
Pour chaque indicateur, il convient de préciser la formule, le périmètre, la source, le responsable, la fréquence de mise à jour, la cible et les seuils d’alerte. Les résultats doivent également être accompagnés d’une tendance, d’une explication des écarts et d’une action corrective.
Enfin, les cibles ne doivent pas être copiées sur celles d’une autre entreprise. Elles doivent tenir compte de la criticité des services, des engagements contractuels, de l’appétence au risque et des priorités stratégiques. Ainsi conçu, le tableau de bord DSI devient un véritable outil d’arbitrage : il permet de détecter les dérives, de prioriser les investissements et de démontrer concrètement la valeur créée par l’IT.
Centralisation des demandes, automatisation des workflows et tableaux de bord dynamiques : découvrez comment Atrya s’appuie sur des indicateurs clairs pour piloter ses ressources IT et optimiser ses performances.
Sources utilisées
• [ISACA — Performance Measurement Metrics for IT Governance]
• [ISACA — COBIT 2019 et mesure de la performance IT]
• [NIST — Cybersecurity Framework et métriques de détection]
• [NIST — Incident Response Recommendations, SP 800-61 Rev. 3]
• [FinOps Foundation — Unit Economics]
• [Atlassian — Incident Management Metrics]