L’article en bref :
Dans un projet IT, la MOA (maîtrise d’ouvrage) représente le client et définit le périmètre fonctionnel, rédige le cahier des charges, gère les budgets et valide les étapes. La MOE (maîtrise d’œuvre) prend en charge la partie technique : construction de l’équipe, choix des technologies, pilotage du développement et respect des délais et de la qualité. L’article compare leurs rôles : la MOA se concentre sur le « quoi », la MOE sur le « comment », et insiste sur leur collaboration essentielle pour éviter les conflits ou malentendus. Il évoque aussi l’AMOA, qui assiste la MOA dans son interface avec la MOE. L’article rappelle enfin que ces rôles restent les mêmes, que l’on soit en cycle en V ou en mode agile (MOA ≈ Product Owner, MOE ≈ lead dev/tech lead).
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
🧠 Bon à savoir :
Dans certaines organisations, la frontière entre MOA et MOE peut devenir floue, et l’on observe des rôles hybrides (ex. : chef de projet technique porteur de la vision fonctionnelle). Pour garder une gouvernance claire, définissez dès le lancement du projet un accord de responsabilité précisant qui tranche sur les exigences fonctionnelles et qui sur les choix techniques — cela prévient les blocages et les ambigüités tout au long du projet.
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 !
