Projets informatiques : le nécessaire mea culpa des consultants

Jérôme Bouteiller
14 novembre 2003 à 00h00
0

Consultant en stratégie, Nicolas Humeau revient sur la relation à instaurer avec un client afin de réussir un projet informatique

Le paradoxe (apparent)

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 (étude 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... Nous nous bornerons ici à en étudier le volet assistance à maîtrise d'ouvrage, les dérapages relevant de la maîtrise d'œuvre étant généralement mieux identifiables. Pour ce faire, nous choisirons d'observer un projet informatique au travers du prisme des acteurs internes à l'entreprise.

A chaque acteur interne son travers...

L'influence du consultant va potentiellement s'exercer sur trois acteurs. Examinons en premier lieu quels vont être les travers naturels de chacun.

Au plus haut niveau, nous trouvons la Direction Générale, qui assure la maîtrise d'ouvrage stratégique. Elle ne peut accorder qu'une fenêtre d'attention réduite au projet, essentiellement pendant les réunions du Comité de pilotage. Ceci tend à placer une pression exacerbée sur les autres participants, qui savent qu'il leur faudra sortir de réunion en ayant impérativement obtenu soit un feu vert, soit un veto (c'est selon...). Ce phénomène biaise fréquemment les restitutions en Comité de pilotage, que l'ordre du jour soit de nature fonctionnelle (par exemple : "au regard de nos besoins, devons-nous implanter tel module de tel ERP ?") ou de nature technique (par exemple : "notre architecture informatique actuelle doit-elle évoluer sous la pression du projet ?").

Vient ensuite la Direction Métier, que l'on définira comme la Direction (des Ressources Humaines, Commerciale...) au service de laquelle le projet se place prioritairement, et qui assure la maîtrise d'ouvrage opérationnelle. Elle va quant à elle s'intéresser au volet fonctionnel du projet, les aspects techniques ne retenant son attention qu'en terme de poste budgétaire à minimiser autant que possible. Elle oubliera donc dans la plupart des cas d'aborder les questions d'intégration, de reprise de l'existant, ou bien les rejettera à plus tard, "quand on en arrivera à la boîte noire".

Enfin, la Direction Projet constitue le troisième acteur et 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ée 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 reporte, 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 pourtant "l'opérationnalité" de son projet...).

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é du temps...), le consultant :
- Conforte la Direction Générale dans une vision "high level" des enjeux, et par conséquent...
- Met la pression sur / influence la Direction Métier pour qu'elle ouvre le champ fonctionnel des possibles et fasse rêver, et par conséquent...
- 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", avant de...
- Structurer 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).

Pour un mea culpa constructif

Dès lors, si le marché du conseil ne veut plus avoir à justifier de taux d'échec dépassant les 50% sur l'ensemble des projets informatiques, un mea culpa constructif semble nécessaire. Le premier pas en serait de tenir un discours approprié à son 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 conditionne 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 meilleure efficience globale des projets informatiques n'est pas hors de portée, pour peu que les instances dirigeantes des entreprises acceptent toute leur part de responsabilité et se montrent ouvertes aux (voire curieuses des) contraintes techniques relevant de la maîtrise d'œuvre, et que 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... Pascal n'affirmait-il pas : "dire la vérité est utile à celui à qui on la dit, mais désavantageux à ceux qui la disent" ?

Nicolas HUMEAU

(initialement publié sur le site www.360journal.com)
Modifié le 01/06/2018 à 15h36
0 réponses
0 utilisateurs
Suivre la discussion

Les actualités récentes les plus commentées

Normandie : la plus grande route solaire du monde est un échec
Windows Defender obtient 3 fois le score maximum aux tests AV-Test
Sur Reddit, les développeurs d'Apex Legends dérapent et insultent leur communauté
Matrix 4 officiellement annoncé, avec Keanu Reeves et Carrie-Ann Moss
WoW Classic : Blizzard dit s’attendre à des files d’attente monstrueuses à l’ouverture
Minecraft s'offre un boost graphique... réservé aux possesseurs de cartes NVIDIA RTX
PS5 : la fuite d'un brevet révèle un design plutôt original
L'astéroïde Apophis qui frôlera la Terre en 2029 est-il vraiment dangereux ?
Starman et sa Tesla Roadster viennent d'achever leur première orbite autour du Soleil
Selon Google, 1,5% des mots de passe seraient compromis

Notre charte communautaire

1. Participez aux discussions

Nous encourageons chacun à exprimer ses idées sur les sujets qui l'intéressent, et à faire profiter l'ensemble de la communauté de son expertise sur un sujet particulier.

2. Partagez vos connaissances

Que vous soyez expert ou amateur passionné, partagez vos connaissances aux autres membres de la communauté pour enrichir le niveau d'expertise des articles.

3. Échangez vos idées

Donnez votre opinion en étayant votre propos et soyez ouverts aux idées des autres membres de la communauté, même si elles sont radicalement différentes des vôtres.

4. Faites preuve de tolérance

Qu'il s'agisse de rédacteurs professionnels ou amateurs, de lecteurs experts ou passionnés, vous devez faire preuve de tolérance et vous placer dans une démarche d'entraide.

5. Restez courtois

Particulièrement lorsque vous exprimez votre désaccord, critiquez les idées, pas les personnes. Évitez à tout prix les insultes, les attaques et autres jugements sur la forme des messages.

6. Publiez des messages utiles

Chaque participation a vocation à enrichir la discussion, aussi les partages d'humeurs personnelles ne doivent pas venir gêner le fil des échanges.

7. Soignez votre écriture

Utilisez la ponctuation, prohibez le langage SMS et les majuscules, relisez-vous afin de corriger un peu les fautes de frappe et de français : trop de fautes n’engagent ni à lire le message, ni à répondre à une question.

8. Respectez le cadre légal

Ne publiez pas de contenus irrespectueux, racistes, homophobes, obscènes ou faisant l'apologie de courants radicaux, qu'ils soient politiques ou religieux. N'utilisez pas plusieurs comptes utilisateurs.

9. Ne faites pas de promotion

Ne profitez pas d'une discussion pour faire la publicité d'un produit, d'un service ou même de votre site web personnel.

10. Ne plagiez pas

Exprimez uniquement vos opinions ou partagez des idées en citant vos sources.

scroll top