Par Nicolas Humeau

Les projets informatiques au sens large (mise en place d'ERP, projets EAI, projets Inter-/intra/extranets...) sont traditionnellement consommateurs de conseil, que ce soit en amont (études d'opportunité), durant le projet lui-même (assistance à maîtrise d'ouvrage, à maîtrise d'œuvre), ou en aval de celui-ci (formation des utilisateurs et, plus généralement, "mise en tension" organisationnelle). Or, le paradoxe apparent réside en ceci que ce sont précisément ces projets fortement encadrés qui connaissent le taux d'insatisfaction, voire d'échec, le plus élevé. De là à y voir une relation de cause à effet...

Ce paradoxe sera analysé dans le cadre d’une assistance à maîtrise d'ouvrage en adoptant successivement le point de vue de chaque acteur.

A chaque acteur son travers...

L'influence du consultant s'exerce uniformément sur trois types d’acteurs dont les travers naturels sont pourtant très différents :

1. Au plus haut niveau, la Direction Générale assure la maîtrise d'ouvrage stratégique. Elle ne peut accorder qu'une attention limitée au projet, essentiellement pendant les réunions des Comités de pilotage. Les participants, sous pression, cherchent à y obtenir impérativement soit un feu vert, soit un veto. Ce phénomène biaise fréquemment les restitutions en Comité de pilotage, que l'ordre du jour soit fonctionnel (par exemple : "au regard de nos besoins, devons-nous implanter tel module ERP ?") ou technique (par exemple : "notre architecture informatique actuelle doit-elle évoluer sous la pression du projet") ?

2. Vient ensuite la Direction "Métier", définie comme la Direction (des Ressources Humaines, Commerciale...) que le projet sert prioritairement, et assurant la maîtrise d'ouvrage opérationnelle. Elle s’intéresse au volet fonctionnel du projet - seuls les aspects budgétaires retiennent son attention sur le plan technique. Elle omettra donc, dans la plupart des cas, d'aborder les questions d’intégration, la reprise de l’existant, ou bien les remettra à plus tard ("quand on en arrivera à la boîte noire").

3. Le troisième acteur est la Direction "Projet", qui assure pour sa part la maîtrise d'ouvrage opérationnelle déléguée par la Direction Métier. Traditionnellement, elle est physiquement incarnée par un cadre de confiance choisi au sein de la Direction Métier et chargé d'assurer l'interface entre les instances hiérarchiques supérieures de maîtrise d'ouvrage déjà citées et la Direction Projet côté maîtrise d'œuvre. L'expérience montre que la Direction Projet maîtrise d'ouvrage est de facto l’acteur le plus "réaliste", qui apprend à manager un projet informatique sous contraintes (puisque la Direction Métier, à qui il rend compte, le presse ou l’ignore, tandis que son homologue côté maîtrise d'œuvre, dont il ne sait si ses contraintes alléguées sont réelles ou non, conditionne la mise en œuvre du projet).


(Cliquer pour élargir)

Quel rôle pour le consultant?

Partant de ce constat, quel devrait être le rôle du consultant côté maîtrise d'ouvrage et qu'en est-il en réalité ?

Idéalement (mais, en pratique, seulement dans la moitié des cas), le consultant devrait donc :

- Sensibiliser la Direction Générale aux contraintes et craintes de ses acteurs internes, afin qu’elle aborde d’elle-même en séance les sujets anxiogènes, en dédramatisant les "zones grises" existantes : oui au droit à l’erreur, non au droit au silence… ;

- Sensibiliser très tôt la Direction Métier aux opportunités et contraintes connues de l’architecture informatique existante : pour que le fonctionnel ne soit plus parallèle au technique, mais orthogonal (c'est-à-dire "lié", sans pour autant être "dépendant de") ;

- Professionnaliser et soutenir la Direction Projet : à savoir mettre à sa disposition des outils et méthodes de pilotage, la former aux enjeux fonctionnels et techniques, créer un binôme avec elle.

Or, trop souvent (l'autre moitié des cas), le consultant conforte la Direction Générale dans une vision "high level" des enjeux, et par conséquent:

- Met sous pression / influence la Direction Métier pour qu’elle ouvre le champ fonctionnel des possibles et fasse rêver ;

- Structure un cahier des charges ne répondant que partiellement aux enjeux fonctionnels (ils étaient trop beaux) et plus ou moins bien articulé à l’architecture technique existante (on s’en est préoccupé trop tard) ;

- Place la Direction Projet sous le feu croisé des exigences fonctionnelles et techniques, en ayant beau jeu de lui fournir outils, méthodes et coaching pour l’aider dans "son rôle décidément ingrat".

Pour un mea culpa constructif

Dès lors, pour ne plus avoir à justifier de taux d'échecs supérieurs à 50%, un mea culpa constructif du conseil semble nécessaire. Le premier pas serait de tenir un discours approprié au client :
- Accepter de reprendre de la hauteur sur une thématique dont il pensait avoir fait le tour ;

- Ne négliger aucun acteur du projet, ce qui suppose de les identifier et de connaître leurs besoins et contraintes spécifiques ;

- Travailler en mode projet : le management du projet détermine la pertinence du contenu qui s’y produit ;

- Demander à son conseil de lui donner les éléments pour arbitrer, plutôt que la solution elle-même : la responsabilité ne se délègue pas.

Au total, une efficience accrue des projets informatiques est possible, pour peu que :
- Les instances dirigeantes des entreprises acceptent leur part de responsabilité et se montrent ouvertes et curieuses des contraintes techniques relevant de la maîtrise d'œuvre ;

- Les consultants qui les accompagnent ne cherchent pas à les conforter dans leurs travers, mais bien à remettre en question ces mauvaises habitudes, quitte à risquer de déplaire au prince...

Car Pascal n'affirmait-il pas : "dire la vérité est utile à celui à qui on la dit, mais désavantageux à ceux qui la disent" ?