Aller au contenu / Skip to content
Toute la boîte à outils

PiloterTableau de bord≈ 10 min d’utilisation

Tableau de bord — Les indicateurs IT utiles à un dirigeant

Huit indicateurs suffisent. Chacun doit pouvoir déclencher une décision, sinon il sort du tableau.

Mis à jour le Decide · Manage

Comment l’utiliserCet outil s’utilise directement sur cette page : parcourez-le à l’écran ou imprimez-la pour la réunion. Aucun fichier à télécharger.

Un tableau de bord IT n’a qu’une fonction : permettre à un comité de direction de repérer en quelques minutes ce qui mérite une décision, et de laisser tranquille ce qui n’en mérite pas. Il ne sert ni à mesurer la technique, ni à occuper une réunion. Onze à quatorze indicateurs, regroupés en quatre familles, suffisent à couvrir le sujet sans le noyer.

Les quatre familles d’indicateurs

Chaque famille répond à une question de dirigeant distincte : peut-on travailler aujourd’hui, sommes-nous exposés, pourrait-on repartir après un incident, dépensons-nous ce que nous avons décidé, et les décisions prises avancent-elles réellement.

1. Disponibilité et service

Indisponibilité des applications critiques
Part du temps ouvré pendant laquelle une application jugée critique n’était pas utilisable. Produite à partir des tickets d’incident et, si possible, d’une supervision technique. Cadence mensuelle. Responsable : direction des systèmes ou prestataire infogéreur, validée par le dirigeant référent métier. Une dégradation signifie que l’architecture ou le contrat de service ne tient plus ses engagements.
Délai moyen de prise en charge du support
Temps écoulé entre l’ouverture d’un ticket et la première réponse humaine. Produit par extraction de l’outil de tickets. Cadence mensuelle. Responsable : prestataire ou service support interne. Une dégradation signale un sous-dimensionnement de l’équipe ou un engagement contractuel mal calibré.
Taux de tickets résolus au délai convenu
Part des demandes closes dans le délai contractuel. Produit par l’outil de ticketing, recoupé trimestriellement avec un échantillon vérifié à la main. Cadence mensuelle. Responsable : prestataire, contrôlé par le dirigeant référent. Une baisse répétée indique un contrat à renégocier, pas seulement une équipe à relancer.
Postes hors support ou hors garantie
Nombre de postes de travail ou serveurs pour lesquels aucun contrat de maintenance actif n’existe. Produit par un inventaire annuel confronté aux contrats en cours. Cadence trimestrielle. Responsable : direction des systèmes. Une hausse impose une décision budgétaire de renouvellement, pas une relance technique.

2. Sécurité et exposition

Comptes actifs d’anciens collaborateurs
Nombre de comptes encore ouverts pour des personnes parties depuis plus de trente jours. Produit par croisement entre l’annuaire technique et le registre RH des départs. Cadence trimestrielle. Responsable : gestionnaire des identités et accès. Toute présence d’un compte est une exposition, indépendamment de la tendance.
Postes non couverts par une détection active
Nombre de postes sans agent de détection installé ou fonctionnel. Produit par extraction de la console de sécurité. Cadence mensuelle. Responsable : prestataire de sécurité. Une hausse signifie une zone aveugle à combler avant, et non après, un incident.
Correctifs de sécurité critiques en attente
Nombre de vulnérabilités critiques identifiées et non corrigées au-delà du délai fixé en interne. Produit par l’outil de gestion des correctifs. Cadence mensuelle. Responsable : équipe infrastructure. Un stock qui grossit indique un processus de mise à jour qui ne suit plus le rythme des menaces.

3. Continuité

Dernière restauration de sauvegarde testée
Date du dernier test réel de restauration, distinct d’une simple vérification que la sauvegarde s’est exécutée. Produit par un rapport de test signé. Cadence trimestrielle. Responsable : direction des systèmes. Un test qui recule dans le temps annule la valeur de toute la politique de sauvegarde.
Écart entre RTO/RPO cibles et constatés
Différence entre le délai de reprise et la perte de données visés, et ceux effectivement observés au dernier test. Produit par comparaison du plan de reprise et du rapport de test. Cadence semestrielle. Responsable : direction des systèmes, validé par le dirigeant référent. Un écart qui se creuse signifie que le plan écrit ne correspond plus à la réalité du système.

4. Coûts et engagements

Écart budget IT réalisé vs voté
Différence entre la dépense IT constatée et le budget approuvé, en valeur et en proportion. Produit par la comptabilité analytique. Cadence trimestrielle. Responsable : direction financière. Un écart croissant appelle une explication ligne par ligne avant le trimestre suivant.
Contrats arrivant à échéance sous 90 jours
Nombre et valeur des contrats IT dont le renouvellement ou la reconduction tacite intervient dans les trois mois. Produit par le registre des contrats. Cadence mensuelle. Responsable : direction administrative. Une échéance non anticipée transforme un choix en fait accompli.

5. Avancement des décisions

Décisions du comité non encore exécutées
Nombre de décisions actées en comité de direction dont l’action correspondante n’a pas été close au-delà de l’échéance fixée. Produit par le registre de décisions. Cadence mensuelle. Responsable : dirigeant référent. Un stock qui ne diminue jamais signifie que le comité décide sans que rien ne se passe ensuite.

Mise en page du tableau

Le tableau tient sur une page, découpée en trois blocs lisibles en réunion. Chaque ligne doit pouvoir être vérifiée à sa source en moins d’une minute.

IndicateurSourceCadenceResponsable
Indisponibilité des applications critiquesTickets d’incident, supervisionMensuellePrestataire / direction des systèmes
Délai moyen de prise en charge du supportOutil de ticketingMensuellePrestataire ou support interne
Taux de tickets résolus au délai convenuOutil de ticketingMensuellePrestataire, contrôlé par le dirigeant référent
Postes hors support ou hors garantieInventaire vs contratsTrimestrielleDirection des systèmes
IndicateurSourceCadenceResponsable
Comptes actifs d’anciens collaborateursAnnuaire vs registre RHTrimestrielleGestionnaire identités et accès
Postes non couverts par une détection activeConsole de sécuritéMensuellePrestataire de sécurité
Correctifs critiques en attenteOutil de gestion des correctifsMensuelleÉquipe infrastructure
Dernière restauration testéeRapport de test signéTrimestrielleDirection des systèmes
Écart RTO/RPO cible vs constatéPlan de reprise vs rapport de testSemestrielleDirection des systèmes
IndicateurSourceCadenceResponsable
Écart budget IT réalisé vs votéComptabilité analytiqueTrimestrielleDirection financière
Contrats arrivant à échéance sous 90 joursRegistre des contratsMensuelleDirection administrative
Décisions du comité non encore exécutéesRegistre de décisionsMensuelleDirigeant référent

Pourquoi moins d’indicateurs est préférable

Un tableau de bord qui grossit chaque trimestre finit par ne plus être lu. Chaque indicateur ajouté doit remplacer une ligne existante, jamais s’empiler dessus. Un indicateur qui ne peut pas déclencher de décision différente selon qu’il est vert ou rouge n’a rien à faire sur cette page : il appartient à un rapport technique, pas à un comité de direction.

Comment refuser un indicateur

  • Il mesure une activité technique et non un résultat pour l’entreprise.
  • Aucune décision différente ne serait prise selon sa valeur.
  • Sa source n’est pas identifiable ou change d’une fois sur l’autre.
  • Il fait doublon avec un indicateur déjà suivi ailleurs.
  • Il vise à rassurer plutôt qu’à informer.

Rituel de lecture mensuel et trimestriel

  1. Chaque mois : passer les indicateurs disponibilité, sécurité et coûts en revue en dix minutes, ne s’arrêter que sur ceux hors cible.
  2. Pour chaque indicateur hors cible, demander la cause identifiée et l’action déjà engagée, pas une nouvelle promesse générale.
  3. Chaque trimestre : ajouter les indicateurs de continuité et l’écart budgétaire consolidé, avec le registre de décisions en vis-à-vis.
  4. Consigner par écrit toute décision prise en réaction à un indicateur, avec un responsable et une échéance.
  5. Revoir une fois par an la liste des indicateurs elle-même : retirer ce qui n’a déclenché aucune décision en douze mois.

Que faire quand un indicateur est rouge deux fois de suite

Un indicateur rouge une fois peut être un incident isolé. Rouge deux fois de suite, il cesse d’être un événement pour devenir un signal structurel. La réaction attendue n’est pas de redemander un plan d’action au même responsable qui l’a déjà fourni sans effet : c’est de remettre en question l’hypothèse de départ — la charge de l’équipe, la pertinence du contrat, ou l’architecture elle-même. Le comité doit alors acter une décision explicite, avec échéance, et non simplement noter le rouge pour la troisième fois.

Vérifier la fiabilité du tableau

Un tableau de bord fiable

  • Chaque indicateur a une source unique et identifiable, pas une estimation orale.
  • Chaque indicateur a un responsable nommé, pas une équipe collective.
  • La définition de chaque indicateur est stable d’une période à l’autre : personne ne peut la modifier sans le signaler au comité.
  • Chaque valeur peut être recontrôlée en moins d’une minute par quelqu’un d’autre que celui qui l’a produite.
  • Le tableau tient sur une page ; s’il en faut deux, c’est qu’il reste des indicateurs à retirer.

À retenir

  • Quatre familles, onze à quatorze indicateurs : disponibilité, sécurité, continuité, coûts, avancement des décisions.
  • Chaque indicateur doit avoir une source, un producteur, une cadence et un responsable clairement identifiables.
  • Un rouge répété deux fois change de nature : il exige une décision, pas un nouveau plan d’action du même responsable.
  • Un tableau plus court et vérifiable vaut mieux qu’un tableau exhaustif que plus personne ne lit.

OAKTEAM Score

Situer votre entreprise sur ce sujet

L’évaluation OAKTEAM Score situe votre entreprise en vingt questions et vous rend des priorités écrites.

Outils complémentaires

Trois outils qui prolongent celui que vous venez d’utiliser.

Commencer par une lecture claire

Avant tout projet, il s’agit de comprendre où en est réellement votre système d’information. C’est le rôle de l’OAKTEAM Score.

Un point de départ structuré, sans engagement.

Sur votre situation, pas sur le cas général.