MOA et MOE dans un bateau

Ouh là, ben ça fait un moment que j'avais pas écrit moi !

Ceci étant, j'ai eu beaucoup de travail, un collègue absent pendant presque 3 mois, un nouveau projet à gérer dans l'urgence ... bref, pas trop le temps.

Madame et moi partons en croisière avec Costa à la fin du mois de mai, donc je ferai un post sur le déroulement de ce voyage (en Méditerranée, je précise).

A part ça, le sujet du jour : quel est le rôle d'une MOA ?

Tout d’abord, quelques définitions :

• la MOA est la "maîtrise d'ouvrage", c'est le client qui dit ce qu'il veut obtenir dans un cahier des charges, c'est-à-dire une commande
• la MOE est la "maîtrise d’œuvre", c'est l'exécutant de la commande, l'équipe (généralement, il faut être plusieurs) qui réalise le souhait de la MOA

En général, l'image de définition est celle de la construction d'une maison : la MOA, c'est vous, la MOE, ce sont l'architecte et les ouvriers.
En informatique, la MOA est souvent représentée par la direction, car c'est ici qu'on commande un nouveau logiciel. La (plutôt "les") MOE sont regroupées dans divers services informatiques.

Pour revenir à la question de départ, quel est le rôle exact d'une MOA "informatique" ? Simplement, il s'agit de fournir à la MOE concernée les demandes, informations, souhaits, exigences, contraintes, etc ... d'un projet.

C'est là ou le bât blesse : la plupart des MOA que je connais ont deux travers :

• soit elles ne rédigent pas le cahier des charges mais donne une expression des besoins (relativement flous) et la MOE doit lui proposer un cahier des charges. 

Ça peut marcher pour un plombier( "je veux une nouvelle salle de bain" --> plusieurs propositions de l'artisan) ; ça ne peut pas fonctionner dans l'informatique, pour une simple raison.

La MOE qui prend la commande ne connaît généralement pas le contexte (réglementaire, juridique ...). Un plombier connaît son environnement, mais quand on demande à un chef de projet, par exemple, une application de gestion d'une salle de sport, il faut d’abord se renseigner sur le nombre d'abonnés, l'état de l'infrastructure (réseau, matériel installé), les processus en cours, la cible, etc ...

•  soit elles veulent avoir des informations ou décider d'éléments qui ne les concernent pas.

Ainsi, que l'on utilise un type de base de données ou une autre, peu importe. La MOA doit pouvoir se contenter d'indications sur la fréquence des sauvegardes, leur type, leur stockage ... mais pas de la décision technique. Sur le même thème : j'ai eu récemment une MOA me demandant l'accès à la base de données en lecture / écriture pour procéder à des tests sur une application. Pourquoi ? La recette consiste à tester l'application, pas à vérifier l'état des données. Si les diverses interfaces permettent d'enregistrer et de lire les données, ça doit suffire à la MOA.

Au final, on se retrouve avec une MOA débordée car voulant trop s'impliquer sur des éléments qui ne sont pas de son ressort, ou à l'inverse une MOA qui donne "carte blanche" mais qui reprochera après à la MOE de ne pas fournir un produit correspondant à ses attentes.

C'est pas facile d'être chef de projet :)