Quels KPI pour piloter une DSI ? (et lesquels éviter)

Beaucoup de tableaux de bord DSI ont le même défaut : ils mesurent tout, et ne décident rien. On y empile des dizaines de courbes — disponibilité, tickets, charge serveur — parce qu’elles sont faciles à produire, pas parce qu’elles éclairent une décision. Résultat : un document que personne ne lit vraiment, et une DSI qui reste incapable de dire, en une phrase, si elle va bien ou non. Piloter, ce n’est pas mesurer plus. C’est mesurer ce qui compte, et savoir qu’en faire.

Un KPI ne sert qu’une décision

Le meilleur filtre pour trier ses indicateurs tient en une question : « quelle action si cet indicateur bouge ? ». Si la réponse est « aucune », ce n’est pas un KPI, c’est une statistique. Un bon indicateur est rattaché à un objectif, doté d’une cible, et déclenche quelque chose quand il s’en écarte — une alerte, un arbitrage, un investissement.

Cette discipline élimine d’emblée la moitié des courbes d’un tableau de bord classique. Ce qui reste est court, et c’est justement pour ça que c’est utile.

Trois niveaux, trois audiences

L’erreur suivante, c’est de montrer les mêmes indicateurs à tout le monde. Or un COMEX, un responsable de la DSI et une équipe d’exploitation ne pilotent pas les mêmes choses.

Au niveau COMEX, on parle valeur, risque et budget : la DSI est-elle alignée sur la stratégie, les risques majeurs sont-ils maîtrisés, la trajectoire budgétaire est-elle tenue ? Peu d’indicateurs, très synthétiques. Au niveau pilotage de la DSI, on suit la performance des services et l’avancement des projets : qualité de service, respect des engagements, tenue des délais et des budgets projets. Au niveau opérationnel, on entre dans la mécanique : délais de résolution, volumétrie des incidents, taux de changements réussis — précieux pour l’équipe, illisible pour un COMEX.

Un bon dispositif de pilotage, c’est cette pyramide : chaque niveau reçoit les indicateurs qu’il peut actionner, et pas les autres.

Les familles qui comptent vraiment

En pratique, quelques familles suffisent à couvrir l’essentiel :

• Création de valeur et alignement — la part du budget consacrée au « build » vs au « run », la contribution des projets aux objectifs métier.
• Qualité de service — disponibilité des applications critiques, respect des engagements de service, satisfaction des utilisateurs.
• Maîtrise des risques et sécurité — couverture des vulnérabilités critiques, avancement des plans de remédiation, conformité aux exigences applicables.
• Tenue des budgets — écart entre budget prévu et réalisé, dérive des coûts récurrents.
• Avancement des projets — respect des jalons, taux de projets tenant leurs délais.

Cinq familles, quelques indicateurs chacune : c’est largement suffisant pour piloter, et déjà exigeant à tenir correctement.

Les KPI à éviter

Autant que choisir les bons, il faut écarter les mauvais. Trois pièges reviennent. Les vanity metrics d’abord — le nombre de tickets traités, les lignes de code, le volume de données : impressionnants sur un slide, muets sur la performance réelle. Les indicateurs sans cible ensuite : une courbe sans seuil ni objectif ne dit pas si la valeur est bonne ou mauvaise. Enfin, les indicateurs qu’on ne pilote pas : mesurer quelque chose sur lequel on n’a aucun levier, c’est se donner l’illusion du contrôle. Un tableau de bord n’est pas jugé au nombre de ses indicateurs, mais à sa capacité à provoquer des décisions.

Du KPI au pilotage

Reste une question de fond : d’où viennent les bons indicateurs ? Ils ne se choisissent pas dans un catalogue, ils se déduisent de la maturité de la DSI et de ses enjeux. Une DSI fragile sur la sécurité pilotera d’abord ses risques ; une DSI en transformation suivra d’abord l’avancement de ses projets. Les KPI pertinents découlent du diagnostic, pas l’inverse.

C’est la logique d’un audit de maturité : évaluer où l’on en est, dimension par dimension, puis en tirer la trajectoire — et les indicateurs qui permettront de la suivre. Ces indicateurs alimentent ensuite le schéma directeur : ils mesurent si les initiatives priorisées produisent l’effet attendu. Le pilotage suppose aussi une organisation qui le porte : sans responsable clairement identifié, un indicateur n’est suivi par personne. Pour la logique d’évaluation, voir comment j’évalue le niveau d’une DSI, ancrée sur des référentiels reconnus.

Piloter une DSI ne demande pas un tableau de bord exhaustif, mais un jeu d’indicateurs court, rattaché à des décisions, réparti par niveau d’audience, et débarrassé des métriques qui flattent sans éclairer. Le bon réflexe n’est jamais « quel indicateur puis-je produire ? », mais « quelle décision dois-je éclairer, et qu’est-ce qui me le dira ? ». Des KPI bien choisis ne décrivent pas seulement l’état d’une DSI : ils orientent son cap.