De la maîtrise d’œuvre et de la maîtrise d’ouvrage.

Cela faisait pas mal de temps que je ne m’étais plus posé de questions au sujet du modèle français d’organisation des projets autour d’une maîtrise d’œuvre et d’une maîtrise d’ouvrage.

Pour rappel, ce modèle d’organisation, emprunté au secteur du bâtiment, fait partie de l’exception culturelle française. Tous ceux qui, comme moi, ont utilisé ces termes pour présenter leur parcours professionnel dans leur CV ont dû s’en rendre compte au moment de la traduction en anglais. La traduction est impossible, le concept n’existe même pas. Il faut donc rédiger autrement la version anglaise. (Note: Pour ceux qui souhaitent aller plus loin dans cette problématique de traduction vers l'anglais, je recommande de suivre le lien suivant qui est, et de loin, ce que j'ai rencontré de mieux sur ce sujet: http://anglais-pratique.fr/rubriques/gestion-projets/92-maitre-ouvrage-oeuvre).

Deux épisodes récents m’ont amené à réfléchir à nouveau sur ce sujet.

Le premier d’entre eux était un article dans un forum. Celui-ci relatait les difficultés rencontrées par un projet. L’équipe de maîtrise d’ouvrage avait réalisé des spécifications détaillées à l’aide d’un AGL et il avait fallu énormément de temps aux développeurs pour prendre en main ces spécifications et arriver à travailler en bonne intelligence avec la maîtrise d’ouvrage.

Le second épisode est la lecture d’un article sur un site anglo-saxon qui est une pépite en matière de gestion de projet : « The Project Management Hut ». Cet article est intitulé « The Yin and Yang Of Project Management and Business Analysis ». Dans cet article, l’auteur présente deux rôles complémentaires, souvent attribués à une même personne : le chef de projet et l’analyste métier. Il reconnait le bien fondé de cette approche pour de petits projets mais regrette la confusion ainsi créée. Selon lui, il s’agit de métiers distincts même s’ils demandent de nombreuses compétences communes. Il plaide donc pour la séparation de ces rôles. L’analyste métier réalise alors un certain nombre de tâches et produit un certain nombre de livrables qui doivent faire partie du plan de projet géré par le chef de projet. A ce titre, l’analyste métier répond au chef de projet et lui rend compte de son activité. Tout ceci est parfaitement en ligne avec les meilleures pratiques anglo-saxonnes.

Ces deux épisodes m’ont rappelé plusieurs éléments fondamentaux pour que notre système français fonctionne bien.

Tout d’abord, pour que le modèle fonctionne, les responsabilités doivent être clairement identifiées et attribuées à chacune des équipes. La maîtrise d’ouvrage est en charge des besoins et des exigences du métier vis-à-vis du produit. Elle est centrée sur l’atteinte des résultats qui ont été définis et sur l’utilisation du produit. La maîtrise d’œuvre est centrée sur le produit. Elle en fait les spécifications, la conception et la réalisation. Elle s’assure également d’en assurer la qualité.

Ensuite, les tâches de maîtrise d’ouvrage peuvent-elles être dissociées des activités du projet ? Bien sur que non ! Une gestion de projet efficace doit donc prendre en considération l’ensemble des tâches. Sur ce point, je suis parfaitement en phase avec nos amis anglo-saxons. Non seulement les tâches de maîtrise d’ouvrage et de maîtrise d’œuvre se doivent d’être intégrées dans un unique plan de projet, mais je prétends en plus qu’elles ne sont pas séquentielles mais concourantes. Elles se déroulent en même temps et s’influencent mutuellement.

Le problème est que trop souvent, chaque équipe souhaite gérer son propre prisme du projet et à sa manière. C’est ainsi que l’on voit surgir des notions bizarres de chef de projet utilisateur et de chef de projet de maîtrise d’œuvre. Un projet, deux chefs, cherchez l’erreur ! On peut comprendre un intégrateur qui nomme un chef de projet pour gérer ses équipes et ses engagements sur le projet de son client. Mais qu’elle est la valeur de ce plan de projet pour le client ? Et si j’ai plus d’un intégrateur ? Décidément, le chef de projet doit embrasser l’ensemble de l’équipe projet, maîtrise d’ouvrage et maîtrise d’œuvre confondue. Le chef de projet n’est donc pas le maître d’œuvre.

Les notions de maîtrise d’œuvre et de maîtrise d’ouvrage ont le mérite de permettre l’attribution de rôles précis réclamant des compétences distinctes. Il est seulement regrettable que, parfois, on veuille les mettre dans une relation client-fournisseur là où une relation de collaboration est tellement plus efficace.

Au vu de ces quelques réflexions, y a-t-il encore un problème pour un analyste métier de rendre compte de ses activités sur un projet au … chef de projet ? Peut-on également s’étonner qu’un dossier de spécifications détaillées, réalisé par la maîtrise d’ouvrage, pose d’énormes problèmes de prise en charge par les développeurs. Un simple cahier des charges, précisant les besoins et les attentes aurait été plus simple à produire et aurait probablement abouti à une solution plus simple, moins couteuse et peut-être même livrée dans les temps.

Finalement, vu comme cela, notre exception française n’est en rien incompatible avec les meilleures pratiques qui sont bien souvent, n’en déplaise à certains, anglo-saxonnes. Il s’agit juste d’une contribution additionnelle : The French Touch.

Comments

[Neil MINKLEY]

Merci de noter la nouvelle adresse de l'article du site "Anglais pratique" mentionné au début de cet article-ci de Marc Bauwens ("De la maîtrise d’œuvre et de la maîtrise d’ouvrage") :



>> http://anglais-pratique.fr/index.php/rubriques/gestion-projets/92-maitre-ouvrage-oeuvre

[Eric]

Le constat est souvent le même, dans la construction d'un système d'information, il arrive fréquement que la MOE est souvent MOE et à la fois MOA.
Il s'avére important de traduire le besoin du client en langage compréhensible par les équipes informatiques. Cela ne peut se réaliser qu'à travers des personnes connaissant à la fois le contexte métier du client et le langage des informaticiens. Le cahier des charges est un bon point de départ pour commencer les analyses.
Dans la conception d'applications en langage objet, les cas d'utilisation, diagrammes d'activité et d'état ainsi que les diagrammes de classes sont souvent suffisants pour collaborer avec la MOA en parlant leur langage (objet métiers, processus métiers) il s'avére important de valider les hypothéses du métier au fur et à mesure de l'avancé des analyses et en particulier de définir des étapes dans l'avancé du projet. (Maquetage, capture d'écran, versions intermédiaires)
Dans certaines méthode de développement (l'extrême programming) une personne de la MOA fait partie intégrante de l'équipe construisant le SI. Dans ce cas précis, le projet est sûr de répondre à la MOA... Enfin à la personne représentant la MOA!