Tableau de bord DSI : faites décider votre direction
Votre reporting informatique reste sans suite ? Choisissez des indicateurs utiles, montrez leurs limites et rattachez chaque écart à une décision attendue.

Construisez le tableau de bord DSI autour des décisions attendues de la direction. Retenez des mesures reliées au travail des métiers, documentez leur calcul et montrez les angles morts. Chaque écart présenté doit préciser sa conséquence, l'action proposée et le décideur attendu. Gardez les détails techniques en annexe et vérifiez au comité suivant ce que les décisions ont effectivement changé.
Votre tableau de bord est vert, mais la direction vous reproche encore une informatique qui bloque le travail. Voici comment refaire le reporting pour obtenir des décisions, sans transformer votre équipe en atelier de production de graphiques.
Partez de la décision que vous attendez
Je partirais de la dernière réunion : qu’a décidé la direction grâce au tableau présenté ? Si la réponse se limite à prendre connaissance des chiffres, reprenez le document par la fin. Écrivez d’abord ce qui doit être décidé au prochain comité.
Par exemple : autoriser une intervention sur l’application de commandes, désigner un responsable métier pour les demandes bloquées, ou accepter de reporter une livraison. Le tableau doit donner les faits nécessaires à ce choix. Il n’a pas à prouver que la DSI travaille beaucoup.
Le Service Manual britannique sur la mesure des services recommande de croiser les mesures avec les retours utilisateurs et d’autres sources, dont les données financières. Pour une ETI, j’en retiens une règle pratique : confrontez vos compteurs à une tâche que le métier doit réellement accomplir.
Demandez au directeur concerné quel travail reste impossible malgré les voyants verts. Sa réponse désigne le périmètre à examiner, pas automatiquement la cause informatique.
Remplacez le volume traité par le travail encore bloqué
Le nombre de tickets fermés renseigne sur l’activité du support. Il ne dit pas si les dossiers difficiles avancent. Une équipe peut fermer les demandes simples pendant que les mêmes utilisateurs attendent toujours une solution.
Je garderais le volume en annexe et présenterais les demandes anciennes encore bloquantes, avec leur motif d’attente. Séparez une attente fournisseur, une validation métier et une intervention DSI. Sinon, le comité attribue tout le délai à la même équipe.
Voici un modèle de remplacement, à adapter aux décisions de votre direction :
| Compteur habituel | Mesure à examiner | Décision possible |
|---|---|---|
| Tickets fermés | Demandes bloquantes encore ouvertes, par ancienneté | Faire traiter le blocage identifié |
| Connexions au portail | Parcours commencés puis terminés | Corriger une étape qui fait abandonner |
| Tâches techniques réalisées | Charge des reprises manuelles récurrentes | Réserver du temps à une correction durable |
Pour un portail, le guide GOV.UK sur le taux de complétion distingue les transactions commencées de celles terminées. Reprenez ce principe seulement si vous savez définir le début et la fin du parcours. Une connexion ne vaut pas une demande déposée, et une demande déposée ne vaut pas une demande satisfaite.
Écrivez la règle de calcul avant de colorier la case
Pour chaque indicateur retenu, notez sa source, sa période, son périmètre et ses exclusions. Ajoutez la personne qui peut expliquer le calcul. Si personne ne sait retrouver les dossiers derrière le graphique, ne le présentez pas comme une preuve.
Le piège classique est de comparer des populations différentes. Les demandes fermées ce mois-ci peuvent avoir été ouvertes bien avant. Leur délai ne décrit donc pas celui des nouvelles demandes du mois. Montrez aussi le stock restant et son ancienneté.
Astuce : gardez une fiche de calcul dans le tableur. Elle contient le filtre utilisé, la date d’extraction, la définition des statuts et les cas exclus. Conservez l’extraction source dans un espace autorisé. Un collègue doit pouvoir reproduire le résultat sans interroger son auteur.
Quand la définition change, signalez la rupture dans le graphique. Ne raccordez pas silencieusement deux séries différentes. Et affichez une donnée manquante comme telle : une case vide ne mérite jamais du vert par défaut.
Montrez ce que la moyenne cache
Une moyenne globale peut masquer un site en difficulté ou une catégorie de demandes abandonnée. Avant de présenter une amélioration, regardez sa répartition sur les périmètres qui comptent pour le métier.
Pour les délais, affichez la médiane et les dossiers les plus anciens encore ouverts. La médiane décrit le centre des délais observés ; elle ne remplace pas l’examen des attentes longues. Pour une enquête de satisfaction, montrez aussi le nombre de réponses et la population sollicitée. Une note seule raconte trop peu.
Évitez surtout le classement des techniciens au nombre de clôtures. Vous mélangez complexité, entraide et affectation des demandes. Examinez les files de travail et leurs blocages avec l’équipe, puis faites remonter les conséquences collectives.
Si le tableau porte sur un engagement de délai, reprenez la définition convenue dans vos engagements de service avec les métiers. Un délai de prise en charge et un délai de résolution ne répondent pas à la même question. N’échangez pas l’un contre l’autre pour améliorer la présentation.
Faites suivre chaque écart d’une proposition
Une flèche rouge sans suite prévue ne rend service à personne. Pour chaque écart présenté, écrivez : conséquence observée, cause confirmée ou encore inconnue, action proposée, décision attendue et échéance.
Prenons un exemple de formulation, sans résultat inventé : les reprises manuelles sur l’interface de commandes retardent le traitement métier ; la DSI demande un créneau de correction et le report d’une évolution nommée. Joignez le relevé des reprises et le planning concerné. La direction peut alors accepter, refuser ou demander une autre option.
Le chapitre Google SRE consacré au travail répétitif distingue ces tâches d’exploitation des améliorations durables. Utilisez cette distinction pour rendre la charge visible. Ne transformez pas les objectifs d’organisation de Google en norme pour votre équipe.
Le reporting doit rendre une décision possible, pas rendre la DSI irréprochable.
Si la cause reste inconnue, demandez une investigation limitée. Ne réclamez pas un achat sur la seule couleur d’une courbe.
Testez une page au prochain comité
Commencez avec un document lisible sans commentaire oral. Pour chaque sujet, le lecteur doit trouver le constat, sa limite et la décision demandée. Gardez les extractions détaillées disponibles pour répondre aux questions.
À faire cette semaine :
- Choisir un indicateur du reporting actuel que personne n’utilise pour décider.
- Le remplacer par une mesure liée à un blocage métier identifié.
- Faire vérifier sa définition et un échantillon de dossiers par un collègue.
- Ajouter la décision attendue, son destinataire et la date utile.
- Faire relire la page par un responsable métier avant le comité.
- Réserver au comité suivant le contrôle de la décision prise.
Après la réunion, consignez qui a accepté quelle action. Au point suivant, présentez son résultat ou son blocage. Si un graphique ne sert toujours à aucune décision, retirez-le du document de direction. Mesurez aussi le temps nécessaire à produire cette page : le reporting doit rester un travail que votre équipe peut tenir.
Questions fréquentes
Quels indicateurs présenter à la direction générale ?
Présentez ceux qui éclairent une décision : travail métier bloqué, demandes qui vieillissent ou capacité absorbée par des reprises récurrentes. Pour chacun, précisez le périmètre, la conséquence et l'action proposée. Le nombre de serveurs ou de tickets traités peut documenter l'activité, mais ne suffit pas à justifier un arbitrage.
Faut-il acheter un outil pour créer le tableau de bord DSI ?
Non. Commencez avec vos extractions et un tableur dont les calculs sont vérifiables. Stabilisez les définitions et testez l'utilité du document en comité. Automatisez ensuite les mesures conservées si leur préparation coûte trop de temps. Un outil ne corrige ni une donnée manquante ni un indicateur sans décision associée.
Comment présenter un indicateur dont les données sont incomplètes ?
Affichez le périmètre réellement mesuré, les éléments manquants et la date de l'extraction. Ne présentez pas l'absence de données comme une absence de problème. Si cette limite empêche une décision, proposez une collecte ciblée avec un responsable et une échéance, puis revenez avec un résultat vérifiable.