AILES : MOE

Définitions [TLFI]
Dans le domaine de l'industrie, on appellera :
- Maître d'Ouvrage (MOA) la personne physique ou morale qui commande l'exécution d'un ouvrage et en assure le financement.
[en très gros, c'est le "client", "celui qui paie".
Aujourd'hui, il représente l'utilisateur qui devient concepteur. Il détermine les fonctions, leurs priorités et impose la "dynamique applicative".]
    - Maître d'œuvre (MOE) la personne physique ou morale, mandataire du maître d'ouvrage et responsable de l'exécution des travaux.
[par analogie, celui qui assure la conception, la direction, la réalisation des travaux.
Il représente une force de solution et de proposition technique. Sous la double pression des nouveaux types d'applications et des contraintes économiques, il fusionne en un seul profil de concepteur-développeur les rôles de l'analyste et du programmeur.]

Où est le problème ?
En 1995, une étude du Standish Group dressait un tableau accablant de la conduite des projets informatiques.
    Reposant sur un échantillon représentatif de 365 entreprises, totalisant 8 380 applications, cette étude établissait que 16,2 % seulement des projets étaient conformes aux prévisions initiales, 52,7 % avaient subi des dépassements en coût et délai d’un facteur 2 à 3 avec diminution du nombre des fonctions offertes, 31,1% ont été purement abandonnés durant leur développement.
    Pour les grandes compagnies, le taux de succès tombait à 9 % alors que seulement 42 % des fonctionnalités commandées ont été effectivement livrées.
    Ces statistiques peuvent être interprétées de différentes façons selon qu’on les considère avec le point de vue du maître d’ouvrage (MOA) ou avec celui du maître d’œuvre (MOE).
    Du point de vue du maître d’ouvrage, elles indiquent une incapacité à sélectionner le maître d’œuvre qui saura réaliser le système souhaité, aux conditions économiques de coût, qualité, fonctionnalité et délai.
    Du point de vue du maître d’œuvre, elles indiquent :
- soit une incapacité à faire un devis sérieux des travaux à réaliser pour livrer le système commandé aux conditions fixées par le contrat puis à diriger la réalisation
- soit une incapacité à dialoguer avec le MOA, ne serait-ce que pour lui expliquer que le système commandé est infaisable aux conditions fixées par le contrat ou, encore, que l’expression de besoin est trop instable ou économiquement mal fondée pour développer quoi que ce soit de solide.
    Très souvent, le deuxième facteur est présent et vous entendrez souvent : « De toutes façons, ils ne savent pas ce qu'ils veulent, ces MOA! ».
On retombe dans les travers du cahier des charges qui peut changer trop souvent..

Évolution des relations MOA - MOE
[Longepe] nous en indique 4 phases :
1/ Règne de l'informatique (1960-1970).
    On y trouve des SI de gestion et de production.
=> La MOA n'est pas encore vraiment présente. C'est le règne de l'informatique et de ces techniciens.
=> la MOE analyse les données a posteriori. Il s'agit d'informatiser des tâches administratives répétitives, sans véritable réflexion stratégique.
2/ Vision utilisateur (1980)
    On y trouve encore des SI de gestion et de production, mais devant les échecs de certains projets informatiques, les directions métier ne peuvent plus uniquement la responsabilité des échec sur l'informatique.
=> la MOA apparaît et rédige essentiellement un cahier des charges afin d'expliquer à la MOE ce qu'elle veut.
=> la MOE écoute la MOA pour formaliser spécifier les fonctionnalités attendues. Mais souvent, c'est lui qui propose sur la base des possibilités techniques, et la MOA se prononce par écart.
3/ Vision métier (1990)
    On y trouve des SI décisionnel et surtout une prise de conscience du besoin d'une vision globale et non plus projet par projet de la maîtrise d'ouvrage. Cette prise de conscience a été pour l'essentiel provoqué par l'informatisation de l'ensemble des domaines des entreprises ou organismes. C'est à cette époque que les Directions des Systèmes d'Informations (DSI) succèdent aux Directions Informatiques (DI).
=> La MOA explique et analyse des données du passé pour formaliser des décisions métiers. le pouvoir concernant le système d'information bascule souvent du côté métier.
=> La MOE est de plus en plus à l'écoute, avec peu de force de proposition. Techniquement, tout est de plus en plus accessible, mais aussi en constante évolution, et la MOE a du mal a faire entendre raison à la MOA : les besoins de cette dernière (MOA) changent trop souvent... et les moyens technique du premier (MOE) n'arrêtent pas de changer!
4/ Vraie collaboration MOA-MOE (2000 et plus)
    On y voit le développement des SI stratégiques, ce qui requiert toutes les compétences nécessaires, à savoir à la fois des compétences métier et des compétences en organisation, en conduite de changement et en informatique.
=> La MOA doit maintenant spécifier la mise en oeuvre du futur (donc tenir compte du métier et de ses évolutions)
=> La MOE formalise mais également prototype ces connaissances métiers évolutives au sein d'un cycle Itératif.

    On le voit, les relations MOA-MOE doivent passer par une vraie collaboration. C'est encore loin d'être toujours le cas !...

Un phénomène typiquement français ?
    J'ai commencé à avoir des doutes sur l'existence "internationale" du concept de maîtrise (d'œuvre et d'ouvrage) lorsque j'ai cherché une traduction de ces termes en anglais. Et là, surprise : j'ai eu un mal de chien à trouver une seule traduction.
    Le seul document qui fait clairement référence à ces maîtres ne concerne même pas l'informatique, mais la construction [PDF] ou FASP. Il traduit :
- maîtrise d'ouvrage par project owner ou client (presse francophone), plus rarement sponsor;
- maîtrise d'œuvre par project supervisor ou project manager (presse francophone) ou lead contractor (lexiquegtr).
Ces traductions (client - manager) sont également confirmées par nos collègues belges cfwb.
    Ces traductions mettent bien en valeur une relation client-fournisseur, "celui qui paie" et "celui qui fait". Or cette façon de faire n'a pas vraiment cours dans la culture anglo-saxonne. Fait révélateur, le CIGREF (Club informatique des grandes entreprises françaises, qui existe depuis 1970 et dont la finalité est la promotion de l’usage des systèmes d’information comme facteur de création de valeurs pour l’entreprise) traduit bien, dans sa nomenclature 2001 [PDF], maître d'œuvre,... mais pas maître d'ouvrage.
    Un consultant d'une grande boite de conseil me le confirme : après avoir fait plusieurs missions en Belgique et au Luxembourg, de culture plus anglo-saxonne dans la conduite de leurs projets informatiques, il rentre à regret en France.
    En effet, me dit-il, cette distinction est plus une séparation de pouvoir qu'autre chose. Il s'agit de deux savoirs (le client et son métier face au fournisseur et sa technique) qui s'opposent. Le problème, c'est que ces deux savoirs s'affrontent sans proposer de réel savoir-faire.
    La culture anglo-saxonne est beaucoup plus basée sur le savoir-faire ou "process" (avec les steps, milestones, ...), dirigé par un team leader, et comprenant des gens aussi bien fonctionnel (bonne connaissance métier) que technique. Leur process se base souvent sur des "streams" architecturaux, tels que ces sphères architecturales : des équipes "business", "fonctionnelles", "applicative" et "technique" qui se réorganisent ensuite par projet applicatif, avec dans chaque projet, des gens "business", "fonctionnel", "applicatif" et "technique".
Cf. Informaticien et Français ? - Verticalement - Dur!.
    Certes, la vision du client MOA qui dirige le fournisseur MOE peut marcher... mais engendre surtout des organigrammes de collaborateurs excessivement compliqués surtout quand :
- la MOA décide de se faire assister (on a dont une assistance à maîtrise d'ouvrage qui dirige et conseille une maîtrise d'ouvrage qui elle-même dirige une maîtrise d'œuvre ! Cela peut d'ailleurs se révéler dangereux en cas de régie de régie) ;
- l'organigramme du projet devient virtuel, parce qu'un "vrai" organigramme montrerait telle personne au dessus de tel autre alors qu'il s'agit, dans la hiérarchie de l'entreprise, de son subordonné ! Du coup, on préfère publier de "faux" organigrammes pour ménager les susceptibilités de chacun !... pffff....
    Cette "division" (pour mieux régner ?) permet sans doute aussi de mieux diluer la responsabilité en cas d'échec, à l'opposé du "process" anglo-saxon où les "leaders" (ou "managers") sont clairement identifiés et sont les premiers à sauter !
    Cf. aussi