Vous êtes dans : Accueil > Tribunes libres >

Prendre le pouls d’une DSI : le dilemme du nouveau directeur

Cédric Cartau , MARDI 26 JANVIER 2021

C’est une question qui revient souvent dans les formations, les séminaires ou les appels de l’ami d’un ami : comment le directeur fraîchement nommé à la tête d’une DSI, petite ou grande, peut-il se faire une idée de l’état général de sa direction ? La tâche n’est pas simple : il existe différentes méthodes, toutes valables, où l’absence de connaissance informatique n’est nullement un handicap (et les connaissances informatiques pointues nullement un atout). J’ai vu des informaticiens confirmés se faire balader comme des bleus et a contrario des décideurs totalement novices en la matière faire un état général avec une acuité redoutable en peu de temps.

Chaque méthode se vaut. Nous allons en examiner deux, mais qui partagent trois éléments communs, sortes de mantras qu’il faudra toujours garder à l’esprit :

  • La dynamique compte au moins autant que l’état : constater que les deux tiers du parc des PC sont obsolètes (l’état) n’est pas une bonne nouvelle, se rendre compte qu’aucun projet chiffré et planifié n’est lancé pour régler la question (la dynamique) est encore pire ;
  • Le manque de moyens est un argument qui ne vaut pas tripette : si tout le monde manque de moyens, c’est que le problème n’est justement pas les moyens disponibles, et donc paradoxalement cela signifie que personne n’en manque ; ce qui compte n’est pas le nombre d’euros, d’ETP, de mètres carrés de salle informatique que la DSI est capable d’aligner, mais si elle est en mesure de mettre un coût (ses moyens) en face d’une demande (de ses clients) ; autrement dit d’en donner pour leur argent, tout leur argent et rien que leur argent à ses clients ;
  • Et surtout : tout le monde ment. Les utilisateurs mentent en prétendant que « ça plante tout le temps » (sans analyse factuelle des tickets d’incident ouverts à la hot line, cette affirmation ne vaut rien). Les directions clientes mentent en affirmant que les projets sont en retard (la belle affaire ! vous connaissez un truc en avance à l’hôpital ?). Et, pires de tous, les informaticiens mentent en déclarant qu’ils n’ont pas assez de moyens : demandez les plannings prévisionnels, la saisie des temps passés, l’analyse de l’utilisation des ressources RH : la plupart du temps, rien ne vient objectiver cette information.

Tout le monde ment, mais pas tout à fait quand même.

La méthode classique

Elle consiste à calculer trois indicateurs : l’état des stocks (la vision statique), les charges financières prévisionnelles de renouvellement, les charges RH prévisionnelles induites.

Et ces trois indicateurs doivent être calculés pour les six domaines suivants :

  • L’infrastructure, qui comprend les serveurs, le stockage, les middlewares, les OS, les éléments actifs réseau ;
  • Le parc de terminaux : les PC, les portables, la téléphonie ;
  • La protection périmétrique : pare-feu et équipements annexes ;
  • Les logiciels métiers : cartographie, domaines fonctionnels couverts, etc. ;
  • Les RH de la DSI : état des formations, moyenne d’âge, répartition des métiers/grades/diplômes ;
  • Le portefeuille projets, à la fois techniques et métiers.

Par exemple :

  • Infrastructure : les serveurs matériels ont une moyenne d’âge de quatre ans, pour un renouvellement prévu au bout de six ans. La connaissance du coût unitaire d’un serveur permet de calculer avec une simple formule la charge financière de remise en état du parc pour obtenir un âge moyen de trois années ;
  • RH : un bilan des connaissances permet de construire un plan de formation sur trois ans et d’évaluer la charge RH induite (absence des agents, impact sur les projets en cours) ; la pyramide des âges permet de prévoir les recrutements sur les cinq prochaines années ;
  • Etc.

Au final, la méthode produit 18 indicateurs factuels. C’est assez fastidieux (le calcul du taux d’obsolescence des équipements prend plusieurs jours et mobilise à la fois le responsable de l’infrastructure et les personnels de la cellule marché), mais le résultat est redoutable.

Il faut de plus ajouter des éléments non financiers tels que :

  • La qualité de service : taux de disponibilité de l’infrastructure, nombre d’appels à la hotline, etc. ;
  • Une appréciation du Shadow IT (les utilisateurs qui s’équipent eux-mêmes du fait des non-réponses de la DSI à leurs demandes, éléments très complexes à mesurer) ;
  • Etc.

La liste peut s’allonger sans fin. Pour une prise de poste, se limiter dans un premier temps aux six domaines susnommés semble être une bonne pratique. Un bilan devrait idéalement tenir sur une feuille A4 recto. L’objectif est de compter les « cadavres dans les placards » (il y en a toujours) et de bien garder à l’esprit que le bilan de plusieurs années de management se mesure uniquement au critère suivant : quelle était la situation de la DSI à l’arrivée et dans quel état sera-t-elle quand on donnera les clés au suivant ?

La méthode d’analyse de la maturité des processus

Elle est basée sur une approche totalement différente, qui consiste à ne pas soulever le capot pour aller voir le taux d’obsolescence des serveurs, des PC…, mais à simplement se demander si quelqu’un s’occupe de piloter ce processus.
Cette méthode est basée sur l’échelle Cobit qui se découpe en six niveaux cumulatifs (pour atteindre le niveau 4, il faut d’abord avoir franchi les niveaux 1, 2 et 3) :

  • Niveau 0 : l’organisation (ici la DSI) n’est pas consciente du besoin ;
  • Niveau 1 : l’organisation est consciente du besoin, mais rien n’existe pour le satisfaire ;
  • Niveau 2 : le besoin est satisfait, mais grâce aux compétences de quelques personnes, sans procédure ni transfert de connaissances pour assurer la continuité de service ;
  • Niveau 3 : le domaine est procéduré, mais il n’y a pas d’indicateurs ni de suivi de la qualité ;
  • Niveau 4 : la qualité est suivie, mais il n’y a pas de veille permanente ;
  • Niveau 5 : il existe une veille permanente.

Par exemple :

  • Si le taux d’obsolescence du parc PC est un sujet que la DSI connaît mais qui ne fait l’objet d’aucun projet, ce processus est au niveau 1 ;
  • Si la hotline a totalement procéduré son catalogue de réponses, mais que les statistiques des appels ne sont pas collectées ni analysées, le processus est au niveau 3 ;

Généralement, dans les DSI, les processus se situent au niveau 2 ou 3, et l’objectif de tout DSI consiste à les conduire progressivement au niveau 4, ce qui, dans certains cas, peut prendre des années et constitue, au demeurant, l’un des principaux apports d’une démarche de certification ISO 27001.

En guise de conclusion

Les deux méthodes ne sont pas mutuellement exclusives : rien n’empêche de les mener en parallèle, d’autant que la seconde est très peu coûteuse. Et redoutablement efficace : il faut voir la tête du responsable micro qui pense être le dieu de la gestion de parc se déliter quand vous lui demandez l’état des OS et des patches, la liste des équipements en dehors de ses outils de recensement (il y en a toujours, genre PC biomédicaux ou PC en Shadow IT, comptez entre 3 % et 7 % en moyenne).
Et, encore une fois, tout le monde ment : « Notre infrastructure est totalement redondée. – Je peux voir le plan de continuité d’activité ? » « Les OS de nos serveurs sont à jour. – Je peux avoir l’état général OS et patches en deux lignes ? » « Notre DMZ est robuste. – Je peux voir le dernier résultat du scan de ports ? »

#dsi