Lors du développement d’un projet informatique, il y a deux parties prenantes : on les appelle MOA et MOE. Ces termes, originellement utilisés dans le domaine des travaux et de la construction, ont vite été adoptés dans d’autres milieux, y compris l’informatique. Ils sont devenus en effet très courants dans les équipes de développement.
Cependant, ils ne sont pas toujours correctement utilisés. Ils méritent qu’on s’y attarde pour expliquer les différences, les rôles et les liens qui unissent ces deux entités. Et c’est ce que nous allons voir en détail dans cet article !
MOA, définition
La MOA, ou maitrise d’ouvrage, est la personne ou le groupe qui va représenter les intérêts du client. C’est le commanditaire du projet, le décideur ; et en quelque sorte le donneur d’ordre.
Étant responsable du cadre fonctionnel du produit, il a théoriquement la responsabilité d’écrire le cahier des charges, bien que cela soit souvent fait en collaboration avec le responsable MOE.
Garant du cadre fonctionnel côté client, il doit également veiller à ce que ce cadre soit respecté par la MOE.
Si on devait l’intégrer dans une équipe agile, type Scrum, le maître d’ouvrage serait le Product Owner : il représente le client et valide le produit et ses évolutions.
Les rôles du MOA, en détail
De par son statut de référent client, la MOA a un ensemble de rôles essentiels au développement d’un projet informatique :
- Définir le cahier des charges, déjà, bien que cela soit souvent fait en collaboration avec la MOE ;
- Estimer les ressources financières à allouer au projet ;
- Définir une deadline, un délai pour les livraisons, finales et intermédiaires ;
- Participer aux diverses réunions ;
- Valider les différentes étapes de développement et les releases effectuées par la MOE ;
- Participer activement au recettage du produit une fois celui-ci en production ou pré-production.
Les principales responsabilités du maître d’ouvrage sont donc la définition précise du périmètre du projet (deadline, budgets, etc.) ainsi que la validation du bon déroulement de celui-ci. Il est redevable de ces tâches auprès du client, s’il exerce son rôle auprès de la MOE, ou directement auprès de ses propres responsables.
Le AMOA
Lorsque le maître d’ouvrage ne peut pas s’occuper du projet auprès de la MOE (manque de temps, connaissances, autres responsabilités, etc.), il peut être nommé par son entreprise un AMOA : assistant à la maitrise d’ouvrage.
Cette personne, qui a souvent de bonnes connaissances techniques, est chargée de représenter la maitrise d’ouvrage auprès de la MOE, et d’ainsi être totalement impliqué dans la création du projet.
MOE, définition
De l’autre côté du projet se trouve la MOE, ou maitrise d’oeuvre. La maitrise d’oeuvre, ou maitre d’oeuvre, et la personne ou le groupe qui va concevoir le projet commandé par la MOA.
Dans une équipe de développement, le maître d’œuvre sera un chef de projet (technique) ou un lead developper.
Il a évidemment un rôle technique très fort dans la bonne réalisation du projet, mais il est également responsable de l’équipe de développement qui va réaliser le projet. Il lui faut donc avoir certains soft skills en management.
Les rôles du MOE, en détail
Tout comme le maître d’ouvrage, le maître d’œuvre a des rôles qui lui sont propres :
- Aider la MOA dans la rédaction du cahier des charges grâce à ses connaissances techniques ;
- Construire son équipe, en sélectionner les membres et prestataires ;
- Manager cette équipe, techniquement et humainement ;
- Choisir les technologies adéquates pour la réalisation du projet ;
- Veiller à la bonne réalisation du projet dans les temps impartis ;
- S’assurer de la bonne qualité du produit lors des phases de releases ;
- Rendre compte, faire des points d’avancement, avec la MOA ou le AMOA.
On le voit, le maître d’œuvre n’est pas dénué de responsabilités. Devant souvent diriger une équipe complète de développement, ça sera lui le responsable, face au maître d’ouvrage, si le projet vient à prendre du retard ou à ne pas répondre aux exigences.
MOA et MOE, deux rôles qui vont de pair
Si ces deux parties ont des métiers complètement différents, on l’a vu, leurs rôles sont intrinsèquement liés. Ils ont en effet le même objectif : que le projet sur lequel ils travaillent arrive à son terme, dans le temps imparti et en respectant le cahier des charges établi.
Mais s’ils dépendent fortement l’un de l’autre, ils possèdent des rôles clairs et bien distincts.
Si la MOA a à sa charge la définition du périmètre fonctionnel et est le décisionnaire du projet ; la MOE a elle pour rôle de mener à bien le développement dans ce périmètre fonctionnel.
Et il est essentiel que MOA et MOE comprennent eux-mêmes leurs rôles. Il n’est en effet pas concevable que le maitre d’ouvrage impose une solution technique à l’équipe de développement, ni que le maitre d’oeuvre modifie le périmètre fonctionnel sans en parler au maitre d’ouvrage.
Il est donc nécessaire qu’une bonne communication existe entre ces deux parties, que l’information circule bien et de façon précise. Sinon, il y a des risques d’incompréhension, à la fois dans les rôles, mais aussi dans les demandes, et c’est le projet et sa bonne exécution qui en pâtiront.
On l’a vu, la MOA et MOE sont deux rôles essentiels au bon fonctionnement d’un projet de développement. Bien qu’ils ne portent pas toujours ces noms, ces deux parties existent dans chaque projet.
Suivant les méthodologies de travail et la culture d’entreprise, on pourra parler de Product Owner pour le maître d’ouvrage, et de lead developper pour le maître d’œuvre. Mais seuls les noms changent ; les rôles en restent les mêmes, que l’on fonctionne en agilité ou en développement type cycle en V.
Et vous, quelles sont vos expériences au contact ou en tant que MOA/MOE ? Dites-le nous en commentaire !
