MOA - MOE : un phénomène typiquement français ?

MOA - MOE : un phénomène typiquement français ? par Christophe Thiry

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. 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 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, 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".

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 donc 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)
• 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 !

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 !