[VIDÉO] Chronique d’une mort annoncée, par Fabrice DEGROOTE

Bonjour à toutes, bonjour à tous !

Je suis Fabrice DEGROOTE, avocat associé au sein du Cabinet SIMON, en charge du département Propriété Intellectuelle / Technologies de l’Information, et je vais vous présenter une bien étrange histoire.

Pour ce faire, j’ai intitulé mon intervention « Chronique d’une mort annoncée » ; titre que j’ai emprunté au nouvelliste et romancier Gabriel GARCIA MARQUEZ, parce qu’il illustre bien le message que j’entends vous faire passer en quelques minutes concernant la chronique d’un échec de projet annoncé.

Tout comme les habitants de ce village d’Amérique du sud qui connaissaient le dénouement du drame qui va se jouer mais sans y croire, les acteurs du projet d’intégration informatique vont assister voire favoriser l’échec qui s’annonce par la présence de 3 symptômes qui le caractérisent.

Quels sont ces 3 symptômes ?

• Le premier de ces symptômes est la complexité du projet qui engendre son instabilité ;
• Le deuxième de ces symptômes est une gouvernance d’un projet mal maitrisée ;
• Enfin, le troisième de ces symptômes – et non des moindres – est la résistance au changement.

L’objectif de cette « Chronique d’une mort annoncée du projet informatique » est de faire prendre conscience que les causes de l’échec sont inhérentes au projet lui-même.

Voyons donc dans un premier temps un projet trop ambitieux avec une expression de besoin mal cadrée.

La première raison de l’échec provient de la complexité du projet lui-même. Les projets sont trop gros, trop compliqués, trop ambitieux.

La mise en œuvre d’un progiciel intégré du type ERP ou la gestion de la relation client type CRM sont des exemples de projets technologiques complexes (pour ne pas dire très complexes).

Il n’est pas toujours aisé d’exprimer concrètement des besoins et de fixer des objectifs précis. Plutôt que de se laisser flotter dans un flou artistique de l’avant-projet, le chef de projet a plutôt intérêt à s’accorder le temps de préciser, éclaircir et focaliser les besoins exprimés.

Voyons maintenant le deuxième symptôme : un projet mal gouverné voire pas gouverné du tout.

Lorsque les exécutifs et décideurs ne s’investissent pas et refusent de voir la réalité, l’échec est assuré.

Plutôt que de s’investir au cœur du projet et essayer de comprendre les subtilités des solutions proposées, les exécutifs préfèrent se réfugier dans une forme archaïque de délégation : « Vous avez carte blanche ».

Impliquer les exécutifs ne doit pas rester une vaine parole.

Les responsables, les vrais, sont tenus de s’impliquer plus en avant au cœur du projet afin de s’assurer la cohérence, d’autres diront de l’alignement des technologies sur la stratégie.

Enfin, troisième symptôme : la résistance au changement, engendré par le projet, est le symptôme le plus grave.

Beaucoup de projets informatiques négligent trop souvent l’aspect humain.

Lorsque les membres de l’équipe projet s’enferment dans leur tour d’ivoire et ne cherchent pas à établir des liens avec les utilisateurs, on ne sera pas surpris si ces derniers sont un peu réticents à réceptionner un système qui ne correspond pas à leurs attentes.

Le projet n’a pas pour finalité de demeurer dans un laboratoire. Le système conçu devra à terme rencontrer l’adhésion de ses utilisateurs afin de remplir sa fonction première de création de valeurs.

Comme pour le deuxième symptôme, les cadres dirigeants sont réticents à prendre des décisions difficiles et les comités de pilotage des projets n’ont pas toujours les expertises nécessaires.

En conclusion, pour ne pas avoir cru au meurtre qui s’annonçait et ainsi l’éviter, les villageois vont perdre un des leurs de la même manière parce que chaque projet est unique, et parce que l’un des symptômes peut apparaître, il faut – dès son apparition – savoir arrêter de manière anticipée le projet pour limiter les conséquences d’un échec annoncé.