Sur un projet, deux sigles reviennent sans cesse : la MOA et la MOE. La maîtrise d’ouvrage et la maîtrise d’œuvre sont les deux camps de tout projet, du chantier d’une école à la refonte d’un logiciel. On les résume souvent en une phrase : « la MOA, c’est le client, la MOE, c’est le prestataire ». Ce n’est pas faux, mais c’est trompeur. Les deux camps travaillent parfois dans la même entreprise, à quelques bureaux d’écart. Ce qui les sépare n’est pas un contrat, c’est une responsabilité, et le droit français la définit précisément depuis la loi MOP de 1985.
Dans ce guide, nous partons de la différence de fond entre les deux rôles, puis de leur origine dans le bâtiment. Nous voyons ensuite qui décide quoi, quels livrables produit chaque camp jusqu’à la recette, ce que fait l’AMOA, ce que deviennent ces rôles en mode agile, et les 5 erreurs qui reviennent sur les projets.
Vous préférez la vidéo ? Tout ce guide est expliqué en un peu plus de 11 minutes, schémas à l’appui.
MOA et MOE : la différence en deux questions
Toute la distinction tient en deux questions. La maîtrise d’ouvrage (MOA) répond à la question quoi : quel besoin, pour quel budget, pour quelle date. La maîtrise d’œuvre (MOE) répond à la question comment : quelle solution, avec quelles étapes, avec quels moyens.
Le maître d’ouvrage, celui pour qui l’ouvrage est réalisé
Le maître d’ouvrage est la personne, ou l’organisation, pour qui l’ouvrage est réalisé. Il le commande, il le paie, et il l’utilisera ou le fera utiliser. Sur un projet informatique, c’est le plus souvent un service métier : la direction commerciale qui veut un nouvel outil de suivi des ventes, ou la direction financière qui change de logiciel comptable.
On distingue parfois le maître d’ouvrage, la personne ou l’entité qui porte la responsabilité, et la maîtrise d’ouvrage, l’ensemble de ceux qui travaillent pour lui. La même nuance existe entre maître d’œuvre et maîtrise d’œuvre.
Le maître d’œuvre, celui qui conçoit et dirige la réalisation
Le maître d’œuvre, lui, conçoit la réponse au besoin et dirige sa réalisation. Dans le bâtiment, c’est l’architecte, souvent accompagné de bureaux d’études. En informatique, c’est l’équipe ou le prestataire qui conçoit et construit la solution : une direction des systèmes d’information, une entreprise de services numériques (ESN) ou une agence.
Un aller-retour, et une décision
Entre les deux, le projet circule dans les deux sens. Le besoin part de la maîtrise d’ouvrage vers la maîtrise d’œuvre, puis la solution revient vers la maîtrise d’ouvrage, qui décide si elle convient. C’est ce retour qui compte le plus : la maîtrise d’œuvre propose et construit, mais c’est la maîtrise d’ouvrage qui accepte ou refuse.
Voici les deux rôles côte à côte, avant d’entrer dans le détail.
| Maîtrise d’ouvrage (MOA) | Maîtrise d’œuvre (MOE) | |
|---|---|---|
| Question | Quoi : le besoin, le budget, la date | Comment : la solution, les étapes, les moyens |
| Rôle | Commande, finance et utilise l’ouvrage | Conçoit la réponse et dirige la réalisation |
| Dans le bâtiment | La commune, l’entreprise ou le particulier qui fait construire | L’architecte et les bureaux d’études |
| En informatique | Le service métier qui a le besoin | La DSI, l’ESN ou l’agence qui construit |
| Ce qu’elle valide | Le besoin, puis le résultat lors de la recette | Les choix techniques et la qualité de fabrication |
D’où viennent ces deux expressions un peu solennelles ? Du bâtiment, et plus précisément du droit des marchés publics.
D’où viennent ces termes : le bâtiment et la loi MOP
Maîtrise d’ouvrage et maîtrise d’œuvre viennent du bâtiment et des travaux publics. En France, elles ont même une définition juridique pour les ouvrages publics. La loi MOP du 12 juillet 1985, relative à la maîtrise d’ouvrage publique et à ses rapports avec la maîtrise d’œuvre privée, l’a fixée. Depuis le 1er avril 2019, ses règles figurent dans le Code de la commande publique.
Ce que le Code de la commande publique dit du maître d’ouvrage
L’article L2411-1 le dit en une phrase : les maîtres d’ouvrage sont « les responsables principaux de l’ouvrage ». Il précise qu’ils ne peuvent pas déléguer cette fonction d’intérêt général, sauf dans les cas prévus par le code, comme le mandat ou le transfert de maîtrise d’ouvrage.
L’article L2421-1 détaille ensuite ses attributions. Après s’être assuré que l’opération est faisable et opportune, le maître d’ouvrage :
- détermine sa localisation ;
- élabore le programme, c’est-à-dire le besoin ;
- fixe l’enveloppe financière prévisionnelle ;
- assure le financement de l’opération ;
- choisit le processus selon lequel l’ouvrage sera réalisé ;
- conclut les marchés d’études et de travaux.
La mission de maîtrise d’œuvre et ses 7 éléments
Côté maîtrise d’œuvre, l’article L2431-1 parle d’une mission qui apporte une réponse architecturale, technique et économique au programme du maître d’ouvrage. Pour la construction d’un bâtiment neuf, l’article R2431-4 fixe une mission de base en 7 éléments. Les voici dans l’ordre où ils interviennent sur une opération :
| Élément de mission | Ce que fait le maître d’œuvre |
|---|---|
| Études d’esquisse | Propose une ou plusieurs solutions d’ensemble qui traduisent le programme |
| Études d’avant-projet | Précise la solution retenue, ses dimensions et son coût prévisionnel |
| Études de projet | Fixe les choix techniques et les plans détaillés |
| Assistance à la passation des marchés de travaux | Aide le maître d’ouvrage à consulter et à choisir les entreprises |
| Visa des études d’exécution | Vérifie que les plans d’exécution des entreprises sont conformes au projet |
| Direction de l’exécution des travaux | Dirige l’exécution des marchés de travaux et contrôle leur conformité |
| Assistance aux opérations de réception | Accompagne le maître d’ouvrage à la réception, puis pendant la garantie de parfait achèvement |
Un exemple : une commune construit une école
Prenons une commune qui construit une école. La commune est le maître d’ouvrage : elle définit le programme, comme le nombre de classes ou la cantine, fixe le budget et signe les marchés. L’architecte et les bureaux d’études forment la maîtrise d’œuvre. Les entreprises de travaux construisent sous la direction du maître d’œuvre, mais leurs marchés sont signés avec la commune.
Ce dernier point surprend souvent : l’architecte dirige les entreprises sans être leur client. Le contrat, et donc le pouvoir de payer ou de refuser, reste du côté du maître d’ouvrage. Voyons maintenant comment ce vocabulaire a traversé jusqu’aux projets informatiques.
MOA et MOE en informatique : client et prestataire ?
Les projets informatiques ont repris ce vocabulaire. En France, on parle couramment de MOA et de MOE dans les directions des systèmes d’information. En anglais, il n’existe pas d’équivalent exact : on parle plutôt de client et de prestataire.
Le cas le plus courant
L’idée reçue du départ est vraie dans le cas le plus courant : une entreprise confie son projet à une agence, à une ESN ou à un cabinet d’architectes. L’entreprise est maîtrise d’ouvrage, le prestataire est maîtrise d’œuvre, et un contrat les lie.
Quand les deux camps sont dans la même entreprise
Mais les deux camps peuvent appartenir à la même organisation. Quand la direction commerciale demande un nouvel outil à sa propre direction informatique, la direction commerciale est maîtrise d’ouvrage, et la direction informatique est maîtrise d’œuvre. Il n’y a aucun contrat entre elles, et pourtant les rôles sont les mêmes.
Une même équipe peut aussi changer de camp d’un projet à l’autre. La direction informatique est maîtrise d’œuvre quand elle développe un outil pour un service métier. Elle devient maîtrise d’ouvrage quand elle achète un nouveau logiciel de messagerie à un éditeur. Le camp ne dépend donc pas de l’organigramme : il dépend de votre place dans ce projet-là.
Qui décide quoi entre la MOA et la MOE ?
Sur un projet, les désaccords viennent rarement des tâches. Ils viennent des décisions. Qui fixe le budget ? Qui choisit la technologie ? Qui dit que c’est terminé ? Voici la répartition habituelle.
| La maîtrise d’ouvrage décide | La maîtrise d’œuvre décide |
|---|---|
| Le besoin et les objectifs | La solution technique |
| Le budget | L’architecture |
| Les délais attendus | Le calendrier de réalisation |
| Les priorités | Le choix des moyens |
| L’acceptation finale | La qualité de fabrication |
Une règle simple pour trancher
Face à une décision qui n’entre dans aucune case, une règle aide à trancher. Une décision qui change ce que l’on obtient appartient à la maîtrise d’ouvrage. Une décision qui change la manière de l’obtenir appartient à la maîtrise d’œuvre. Ajouter un écran, c’est la maîtrise d’ouvrage. Changer de base de données sans rien changer pour l’utilisateur, c’est la maîtrise d’œuvre.
Les arbitrages qui se jouent à deux
Certains sujets se jouent à deux. Si le délai est trop court ou le budget trop serré, la maîtrise d’œuvre a le devoir d’alerter. Mais c’est la maîtrise d’ouvrage qui arbitre, entre trois options : réduire le périmètre, accorder plus de temps, ou augmenter le budget. Ces leviers rappellent le triangle d’or de la gestion de projet : toucher à l’un oblige à ajuster les autres. Sur les projets importants, ces arbitrages se prennent souvent en comité de pilotage.
Les livrables de la MOA et de la MOE, jusqu’à la recette
Chaque camp produit ses propres documents, et l’on peut suivre un projet en les regardant passer de l’un à l’autre. Prenons un projet informatique.
Côté maîtrise d’ouvrage : du besoin aux spécifications
La maîtrise d’ouvrage commence par l’expression du besoin. Elle en tire le cahier des charges fonctionnel, qui décrit ce que l’outil doit permettre, avec ses contraintes de budget et de délai. Viennent ensuite les spécifications fonctionnelles : les règles métier, les écrans attendus, les résultats à obtenir. Pour partir d’une base, vous pouvez utiliser notre modèle gratuit de cahier des charges.
Côté maîtrise d’œuvre : de la proposition à la livraison
La maîtrise d’œuvre reçoit ce dossier. Elle répond par une proposition chiffrée, puis elle rédige les spécifications techniques, conçoit l’architecture, développe, et mène ses propres tests avant de livrer.
La frontière la plus discutée : les spécifications détaillées
La frontière la plus discutée se trouve au milieu, sur les spécifications fonctionnelles détaillées. Selon les organisations, elles sont écrites par la maîtrise d’ouvrage, par son assistance ou par la maîtrise d’œuvre. Ce qui ne change jamais, c’est la validation : elle revient au métier.
Retenez une règle : un document qui décrit le besoin se valide côté maîtrise d’ouvrage, un document qui décrit la solution se valide côté maîtrise d’œuvre.
La recette, là où les deux camps se rencontrent
La fin du projet est le moment où les deux camps se retrouvent face à face. Dans le bâtiment, elle porte un nom précis : la réception. L’article 1792-6 du Code civil la définit comme « l’acte par lequel le maître de l’ouvrage déclare accepter l’ouvrage avec ou sans réserves ». Les réserves sont les défauts constatés, que l’entreprise doit corriger. Pendant 1 an après la réception, la garantie de parfait achèvement l’oblige à réparer les désordres signalés.
En informatique, aucun article de loi ne l’encadre, mais la logique est la même. On parle de recette. La maîtrise d’ouvrage prépare les scénarios de test, les utilisateurs les déroulent, et chaque anomalie part vers la maîtrise d’œuvre, qui la corrige. Quand le résultat est conforme, la maîtrise d’ouvrage signe le procès-verbal de recette. Le cahier de recette rassemble ces scénarios et leurs résultats.
C’est le moment où la maîtrise d’ouvrage exerce vraiment son pouvoir. Une recette bâclée, c’est un ouvrage accepté sans avoir été vérifié. Et après la signature, chaque correction devient beaucoup plus difficile à obtenir. Entre ces deux camps, un troisième rôle a pris de l’importance ces dernières années : voyons lequel.
L’AMOA : l’assistance à maîtrise d’ouvrage
Entre les deux camps, un troisième rôle s’est installé : l’assistance à maîtrise d’ouvrage, ou AMOA. Son rôle est d’aider la maîtrise d’ouvrage à tenir le sien. Elle peut être assurée par une équipe interne ou par un cabinet de conseil. Ses missions les plus courantes :
- recueillir les besoins auprès des utilisateurs ;
- rédiger ou formaliser les spécifications ;
- préparer les arbitrages ;
- suivre les livrables de la maîtrise d’œuvre ;
- organiser la recette.
L’assistance conseille, elle ne décide pas
Mais l’assistance ne décide pas. Elle conseille, elle prépare, elle alerte : les choix restent ceux de la maîtrise d’ouvrage. Pour les ouvrages publics, le code est clair, le maître d’ouvrage reste le responsable principal, même quand il se fait assister.
AMOE et maîtrise d’ouvrage déléguée
Le pendant existe côté technique : l’assistance à maîtrise d’œuvre (AMOE) vient en renfort de la maîtrise d’œuvre, pour une expertise pointue comme la sécurité ou l’architecture, ou pour coordonner plusieurs prestataires. Sur les ouvrages publics, le maître d’ouvrage peut aussi confier une partie de ses attributions à un mandataire, qui agit en son nom et pour son compte : on parle de maîtrise d’ouvrage déléguée. Là encore, la responsabilité principale ne change pas de camp.
Chef de projet MOA et chef de projet MOE
Cette frontière sépare aussi deux métiers proches. Le chef de projet MOA porte le besoin du métier, le chef de projet MOE porte la réalisation. Ils travaillent ensemble tous les jours, mais ils ne défendent pas les mêmes intérêts, et c’est précisément ce qui rend leur duo utile. Leurs compétences, leurs formations et leurs salaires sont détaillés dans ces deux fiches métiers.
MOA et MOE en mode agile
Scrum ne parle ni de maîtrise d’ouvrage ni de maîtrise d’œuvre. Pourtant, les deux questions restent posées. Le rôle le plus proche de la maîtrise d’ouvrage est celui du Product Owner : c’est lui qui ordonne le backlog, c’est-à-dire qui décide de ce qui sera fait, et dans quel ordre. Les développeurs, eux, décident de la manière de le faire, ce qui les rapproche de la maîtrise d’œuvre.
Le rapprochement a ses limites, et il faut le voir comme une analogie plutôt qu’une équivalence :
- le Product Owner fait partie de l’équipe Scrum, au lieu de lui adresser un cahier des charges ;
- la recette n’attend pas la fin du projet, puisque la revue de chaque sprint vérifie ce qui a été produit ;
- le besoin n’est pas figé au départ, il s’affine sprint après sprint.
Le vocabulaire change et la frontière se rapproche, mais la question de fond reste la même : qui décide du quoi, et qui décide du comment ? Pour le détail des rôles et des événements, voyez notre guide de la méthode Scrum.
Les 5 erreurs classiques entre MOA et MOE
Ces erreurs reviennent sur tous les types de projets. Elles ont un point commun : un camp qui sort de son rôle, ou un rôle que personne ne tient.
| Erreur | Ce qui se passe | Conséquence |
|---|---|---|
| La MOA impose la solution technique | Elle écrit qu’elle veut tel logiciel ou telle base de données, au lieu d’exprimer son besoin | Si la solution déçoit, plus personne n’est responsable |
| La MOE écrit le besoin à la place du métier | L’équipe technique devine ce que veulent les utilisateurs | Un résultat techniquement réussi, mais inutilisable |
| La recette est confiée à la MOE | Celui qui a construit vérifie son propre travail | Il devient juge et partie |
| L’AMOA finit par décider | L’assistance tranche à la place de la maîtrise d’ouvrage | Le jour où un arbitrage pose problème, personne ne l’assume |
| Aucune MOA identifiée | Tout le monde donne son avis | Personne ne tranche |
La dernière est la plus fréquente sur les projets internes. Quand personne n’est désigné comme maîtrise d’ouvrage, les décisions traînent, et le projet avance au rythme du dernier avis entendu.
En bref : MOA ou MOE, dans quel camp êtes-vous ?
Pour savoir dans quel camp vous êtes, une question suffit : décidez-vous de ce que l’on obtient, ou de la manière de l’obtenir ? Dans le premier cas, vous êtes côté maîtrise d’ouvrage. Dans le second, côté maîtrise d’œuvre. Retenez trois points :
- la maîtrise d’ouvrage porte le besoin, le budget et l’acceptation finale ;
- la maîtrise d’œuvre porte la solution, sa réalisation et sa qualité ;
- le camp dépend de votre place dans le projet, pas de votre contrat ni de votre organigramme.
Notre conseil : dès le cadrage, écrivez noir sur blanc qui valide le besoin, et qui prononce la recette. Ces deux noms ont leur place dans la note de cadrage, et ils évitent la plupart des conflits de fin de projet. Et vous, sur votre projet actuel, êtes-vous côté maîtrise d’ouvrage ou côté maîtrise d’œuvre ?
