Succintement, et sans prétendre être exhaustif, les arguments en faveur de l’établissement d’un plan directeur informatique (PDI) peuvent se résumer comme suit :
1. acquérir, au travers de la démarche as-is:
– une connaissance et une compréhension exhaustive des assets IT
– un inventaire des forces et faiblesses
– un aperçu des risques majeurs
2. réfléchir, au travers de la démarche to-be:
– aux objectifs métiers de l’organisation
– aux potentiels d’amélioration non exploités à ce jour
– aux réductions de coûts possibles
3. aligner, au travers de la trajectoire as-is => to-be:
– les investissements IT sur les besoins métier
– défendre un dossier d’investissement IT auprès des sponsors
– sur base d’un dossier circonstancié et étoffé

En bref:
préparer l’avenir de l’IT en fonction :
– d’une connaissance affinée de la situation actuelle de l’IT
– d’une réflexion pertinente sur les besoins métiers dans l’horizon concerné

Mais…

Comme le laisse supposer le 3ème item du point 1, la démarche as-is ne doit évidemment pas se limiter à un simple effort d’inventorisation et de cartographie de l’existant.
C’est ici qu’intervient très utilement la démarche d’analyse des risques, dans sa partie relative à l’IT.

A dire vrai, je n’imagine tout simplement pas établir un PDI sans y inclure un volet analyse des risques IT.

Celui-ci peut être à géométrie variable, selon le budget et le temps disponibles.

Des méthodes simples existent, basées sur des fils conducteurs pour des interviews avec les acteurs de terrains, responsables et opérationnels, personnel métier et personnel IT réunis. Idéalement sous l’égide d’un externe, qui amène un éclairage neuf et garantit une approche sans à priori.
Et, autant que faire se peut, qui permettra aussi de dépasser les éventuelles difficultés relationnelles entre le métier et l’IT.
Elles offrent l’avantage d’impliquer concrètement les personnes de terrain (et donc d’éviter que le PDI ne reste l'”apanage” de la hiérarchie), et de rassembler deux populations qui, certes, sont amenées à se concerter régulièrement, mais ici avec un focus inhabituel.

Vous pouvez m’en croire : l’IT apprend beaucoup de cette démarche, obligée qu’elle est de sortir de ses cadres de perception et de raisonnement habituels.

Un effet bénéfique est souvent de rapprocher le métier et l’IT, en les faisant s’entretenir sur les pourquois (les justifications et priorités métiers, l’identification des gisements de productivité les plus importants, … ) davantage que sur les comments.
Et, but premier s’il en est, de disposer d’informations essentielles pour fixer les priorités du plan directeur.

Sachant que l’IT intervient aujourd’hui en support de la totalité ou presque des fonctions de l’organisation, la question se pose de savoir si une analyse de risques complète (donc au delà des aspects IT) ne devrait pas systématiquement précéder l’élaboration d’un PDI. J’incline en ce sens.

Faut-il vous dire, pour conclure, que la personne responsable du projet PDI doit avoir des compétences IT étendues (à tout le moins en tant que généraliste), une solide capacité à poser les questions qui dérangent (pour faire remonter les risques) et un sens certain de la diplomatie (pour, lors des interviews, faire remonter les [vrais] problèmes dans la transparence espérée, sans nourrir des conflits avérés ou potentiels)?

Et une recommandation qui va de soi (mais qui ne correspond malheureusement pas toujours aux constats de terrain) : auditeur interne (s’il existe) et CIO doivent travailler de concert. Si cette condition est satisfaite, l’analyse de risques sera un important facteur d’alignement de l’IT sur le métier.

Peut-être un prochain post sur les façons de procéder à de l’analyse de risques dans le cadre d’un PDI.