6 MOA, MOE, AMOA… pourquoi pas MoEU ?

MOA, MOE, PS, PO

Dans le système d’information (SI) naissant du futur RTE, une problématique a très vite surgi : le pilotage des projets SI et les rôles respectifs de la maîtrise d’ouvrage et de la maîtrise d’œuvre.

Pour les projets d’infrastructure ou plus généralement les projets dont la maîtrise d’ouvrage est dans le SI, il n’y a guère de problème car les notions de maîtrise d’ouvrage (MOA) et de maîtrise d’œuvre (MOE) y sont définies depuis longtemps (les années 80 ?), même si certaines ambiguïtés subsistent sur la maîtrise d’œuvre quand la réalisation effective du projet est confiée à une SSII. Dans ce texte, quand on parlera de MOE, on fera toujours référence à la partie de la MOE interne à la même entreprise que la MOA.

Il faut reconnaître que si l’on ne vient pas d’un domaine où rôles de maîtrise d’ouvrage et de maîtrise d’œuvre sont bien repérés, comme dans le bâtiment et les travaux publics, le fait qu’œuvre et ouvrage soient quasiment synonymes rend la compréhension et la mémorisation des rôles sous-jacents délicats.

Je n’ai pas l’intention d’ajouter une définition propre : le lecteur curieux pourra se référer aux articles de Wikipédia ou à l’article plus succinct de « comment ça marche .com » : « On appelle maître d'ouvrage (ou maîtrise d’ouvrage, MOA) l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet. Le résultat attendu du projet est la réalisation d'un produit, appelé ouvrage. La maîtrise d'ouvrage (en anglais Project Owner) maîtrise l'idée de base du projet, et représente à ce titre les utilisateurs finaux à qui l'ouvrage est destiné. »

« Le maître d'œuvre (ou maîtrise d'œuvre, MOE) est l'entité retenue par le maître d'ouvrage pour réaliser l'ouvrage, dans les conditions de délais, de qualité et de coût fixées par ce dernier conformément à un contrat. La maîtrise d'œuvre est donc responsable des choix techniques inhérents à la réalisation de l'ouvrage conformément aux exigences de la maîtrise d'ouvrage. » (En anglais, la traduction la plus proche de maître d’œuvre est « Project manager »).

Mais où donc est le PO ?

Toujours est-il qu’à EDF, il existait une note qui tentait de préciser les concepts en matière de projets : « le management par projets ». 3 rôles essentiels y étaient définis : commanditaire, pilote stratégique et pilote opérationnel.

En principe les choses sont claires. Dans le cas d’un projet SI métier, le commanditaire qui est en quelque sorte la tête de la MOA (en tout cas il a un pouvoir d'engagement) désigne un PS. En général ce sera au sein du métier, et le PS sera garant du bon aboutissement du projet et du respect des objectifs fixés.

Ce PS charge un PO de piloter la réalisation : c’est lui qui est en interface avec les équipes de réalisation internes et/ou externes. Dans le cas d’un projet SI, il paraît évident que ledit pilote doit savoir piloter un projet de réalisation mais qu’en plus il doit avoir des compétences en SI, même s’il peut s’entourer d’experts pour les compléter.

Premier sujet de discorde entre SI et métier : où doit être le PO ? Dans l’organisation du métier ? ou dans celle du SI ? Il est plus que recommandé de prendre un chef de projet qui a de l’expérience et en particulier celle du SI. Dans ces conditions, faut-il prendre quelqu’un du SI et le rattacher au moins temporairement au métier, voire créer une entité métier-SI chargée de la maîtrise d’œuvre des projets SI du métier ? Ou au contraire le laisser le PO dans une structure SI ? La réponse de normand est probablement la meilleure : tout dépend de l’importance du SI métier, des modes d’évaluation pour les PO, des habitudes de l’entreprise. Ce qui est sûr en revanche c’est que le PO est lié au PS par un contrat au moins moral : il lui doit des comptes et l’évaluation du PO par le PS doit faire partie de l’évaluation du PO par sa structure hiérarchique.

Par ailleurs, la réalisation de prototypes fonctionnels, ou les méthodes Rapid And Dirty imposent une forte proximité (« un plateau projet ») entre MOA du métier, et réalisateurs. Ceci plaide pour un rattachement au moins provisoire du PO.    

((RAD : Rapid Application Development, pas toujours si crade, voire indispensable dans des contextes où les besoins doivent être raffinés et pour bien prendre en compte ce qu’on appelle « l’expérience utilisateur »)).

À moi AMOA !

Bien souvent le pilote stratégique s’appuie sur une assistance à maîtrise d’ouvrage.

Son rôle est d’abord d’aider à la définition du besoin métier et à l’élaboration du cahier des charges, puis à lé recette métier et à l’insertion.

Mais très souvent cette AMOA est piochée dans une société de services qui outre le conseil, développe du SI. D’où bien souvent des conflits entre AMOA et PO sur l’élaboration des contrats de réalisation avec les éventuels prestataires externes, sur des choix techniques, voire sur la conduite du projet, et, in fine sur les procédures de recette.

Je passe sur les conflits d’intérêts qui peuvent exister côté AMOA.

Quoi qu’il en soit, l’’AMOA, qui a l’oreille du PS, peut outrepasser son rôle. Il arrive aussi que ce soit le PO. Si le PS a de l’expérience, il saura régler les conflits, sinon ce sont des empoisonnements à n’en plus finir et une bonne probabilité d’échec. Ne pas oublier que l’on fait du SI avec des humains…

Gare aux frontières !

CDC

En principe les choses sont claires, le cahier des charges est l’œuvre de la MOA, les spécifications sont l’œuvre du réalisateur. Oui, mais bien souvent le réalisateur est une SSII. Le PO n’a pas de rôle à jouer ? Si, il doit travailler de concert avec la MOA pour finaliser un appel d’offres qui se tienne, et rajouter les prescriptions techniques qui permettront de garantir une bonne continuité avec le reste du SI et une maintenance économique.

Mais la MOA ne peut être écartée de certains choix techniques : et en particulier quand l’utilisation d’un progiciel est envisagée. On ne discutera pas ici des avantages comparés de solutions à base de progiciels ou de logiciels spécifiquement développés. Ce qui est sûr c’est que le choix a à la fois des incidences techniques et des incidences fonctionnelles : les processus métier doivent être compatibles ou adaptés aux contraintes dures du progiciel.

Le contrat

Qui contractualise ? La MOA ou la MOE ? À l’évidence la MOE qui va suivre le contrat et la réalisation au jour le jour doit être dans le coup. De plus, elle est sensée avoir l’expérience de ce type de d'appels d'offre et de contractualisation. Mais vu que les sous viennent de la MOA et que c’est quand même un point clé du projet, la MOA aussi doit être impliquée !

En clair c’est une œuvre conjointe.

Recette

Souvent on distingue la recette technique à la charge de la MOE et la recette fonctionnelles où la MOA doit s’impliquer.  La recette est donc fatalement une œuvre conjointe. (Ne pas oublier non plus d'impliquer des représentants des utilisateurs finals.)

Déploiement insertion

Le déploiement est une vision technique : donner aux utilisateurs l’accès aux applications.

L’insertion est une vision processus métier ; insérer l’usage de l’application dans les activités métier. À l’évidence les 2 actions doivent être soigneusement coordonnées. De plus la MOE est souvent chargée de monter avec le métier les formations à l’outil.

2 PO pour 1  PS !?!?

J’ai gardé pour la fin une source de conflits, qui avec du recul paraît parfaitement ridicule.

2 PO dans un projet, à savoir un PO métier + un PO SI.

Ça donne des boutons aussi bien côté métier que côté SI.

2 PO pour un même projet ! Quel est le bon ? Quel est le chef ?

Mais j’ai déjà eu l’occasion de l’affirmer : il n’y a pas de projet SI métier !

Il n’y a que des projets métier avec une composante SI : il y a toujours une ré-ingénierie des processus à faire, une insertion métier à préparer... Ces tâches constituent un sous-projet en soi et il est donc logique qu’il ait son PO. Et il y aura également un PO pour le sous-projet SI du projet métier. Sans rentrer dans les détails, il faudra bien que ces deux-là coopèrent puisque les utilisateurs métiers vont subir les applications développées, et que faire une application et la tester sans tenir compte des besoins du métier (qui vont bouger) et des utilisateurs (qui vont changer) est une absurdité.

D’où mon MoEU plaisantin du titre : maîtrise d’œuvre Expérience Utilisateur.

Dans le temps on parlait d’ergonomie des applications. Quoi qu’il en soit il est indispensable de prendre en compte le ressenti des utilisateurs (traduction de user experience ;  en franglais maqué : expérience utilisateur). Le PO métier est probablement le mieux placé pour cela, mais s’il n’y a pas dialogue avec le pilote de la réalisation informatique, on risque d’avoir des surprises à l’arrivée  …