![[logo] Exxan](http://www.exxan.net/pics/logo.gif){kind=logo}
Conseil et solutions informatiques
Forum Logiciel de gestion Open Source
Logiciel de gestion mais pourquoi ?
Forum Réseau et développement
|
Maîtrise d'ouvrage vs maîtrise d'oeuvre, un même lit pour deux rêves ?
Edité le 19/06/2008 Tiré de Le blog d'Olivier Jacquemont Adresse de l'article : http://ojacquemont.blogspot.com/2008/02/matrise-douvrage-vs-matrise-doeuvre-un.html |
||
|
Technologie et société de la connaissance - 24 avril 2006 Faut-il repenser la relation désormais bien ancrée dans les entreprises entre la maîtrise d'ouvrage et la maîtrise d'oeuvre des systèmes d'information ? Cette fracture, que l'on croyait réduite, tend en effet à se rouvrir ! Quel est l'état actuel de la question ? Transformer des idées de changement, des processus nouveaux, des organisations en code informatique et faire tourner sans problème ces programmes sur des ordinateurs est un exercice technique dont la maîtrise a nécessité un investissement méthodologique considérable. Le processus de projet demeure complexe et aléatoire : à partir du concept initial, souvent flou, et de l'analyse des processus, il s'agit de fabriquer le code informatique qui tournera sans faille sur des serveurs pour être diffusé sur un réseau. Bien entendu, le but ultime est de faire en sorte qu?à partir d?épures initiales très théoriques les utilisateurs travaillent plus efficacement avec le nouveau système d'information mis à leur disposition ! Ce chemin est long et semé d?embûches, les risques d?échec sont fréquents et? avérés. C?est pour structurer cette activité qu?a été formalisée, sur le modèle de l?ingénierie du bâtiment, la répartition des rôles entre maîtrise d?ouvrage et maîtrise d??uvre. La littérature sur le sujet est abondante ! Le CIGREF a publié en 1998 un premier document, « Pour un pilotage efficace du système d?information », qui fait référence, enrichi et revisité par un nouveau rapport daté de 2003 sur « Les parties prenantes du système d?information ». L?excellent site de Michel Volle propose une analyse complète de ce sujet (www.volle.com). Aborder à nouveau l?approche de ce sujet bien balisé par des études et publications nombreuses présente un risque évident de manque d?originalité ou de superficialité? Révisons nos classiques ! L?encyclopédie informatique (www.commentcamarche. net) les synthétise clairement. On appelle maître d'ouvrage (ou maîtrise d'ouvrage) 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 définit l'idée de base du projet et représente les utilisateurs finaux à qui l'ouvrage est destiné. Si le maître d'ouvrage est bien le seul responsable de l'expression fonctionnelle des besoins, il n'a pas, par construction, les compétences liées à la réalisation de l'ouvrage, tant sur le plan du pilotage de projet que sur le plan strict de la technique informatique. Le maître d'ouvrage peut ainsi faire appel à une maîtrise d'ouvrage déléguée, dont la gestion de projet est le métier. On parle ainsi d'assistance à maîtrise d'ouvrage. Sa mission est double : aider le maître d'ouvrage à définir clairement ses besoins et vérifier auprès du maître d'oeuvre si l'objectif est techniquement réalisable pour atteindre l?objectif métier visé par la MOA. La maîtrise d'ouvrage déléguée ne substitue pas pour autant, en principe, à la maîtrise d'ouvrage et n'a donc pas de responsabilité directe vis-à -vis du maître d'oeuvre. Le maître d'oeuvre (ou maîtrise d'oeuvre, 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'oeuvre est donc responsable des choix techniques inhérents à la réalisation de l'ouvrage conformément aux exigences de la maîtrise d'ouvrage. Le maître d'oeuvre a ainsi la responsabilité dans le cadre de sa mission de désigner une personne physique chargée du bon déroulement du projet, il s'agit du chef de projet. Si l?on suit à la lettre ces préceptes couramment admis dans la profession, les rôles sont alors bien définis, chacun est responsable de ses livrables et il n?y a pas de risque de dilution de responsabilité entre les différents acteurs. On optimise les chances d?obtenir à l?issue du projet un système répondant aux besoins. Toutefois, cette organisation, même si elle est bien conçue et éprouvée, génère souvent frustrations et critiques mutuelles. Pourquoi ? Quel grain de sable s'est inséré dans cette mécanique ? Des rôles brouillés mais enrichis Ce modèle s?appuie, historiquement, sur des préalables organisationnels qui ont été bouleversés par le développement massif des techniques de l?information et par un intense changement du rythme et du champ d?action géographique des entreprises. Les rôles et misisons ne sont plus figés, et le temps presse ! La compétence des acteurs a ainsi changé, les frontières se sont estompées, rendant une répartition rigide des rôles de plus en plus improbable. Construire un système d?information dans un univers concurrentiel et un contexte organisationnel instables implique désormais une réactivité et une souplesse que les méthodes classiques semblent impuissantes à livrer sans heurts. Chacun souhaite y contribuer. En effet, par rapport au modèle classique MOA/MOE, basé sur une réelle séparation des savoirs, les acteurs sont chacun devenus plus compétents sur le métier de l?autre et comprennent mieux l?enjeu des technologies de l?information. On ne peut plus dire aujourd?hui que les maîtrises d?ouvrage découvrent l?informatique. Elles en ont une expérience vécue à travers près de trente années de projets et d?usage des systèmes opérationnels. Elles peuvent formuler des avis compétents tant sur leurs besoins réels que sur leurs attentes techniques. De ce fait elles entrent beaucoup plus dans les détails, sont plus exigeantes en matière d?ergonomie des interfaces et de qualité du service. Cette évolution est d?autant plus sensible dans les grandes entreprises que les maîtrises d?ouvrage s?y sont souvent organisées de façon permanente, constituant des structures pérennes avec des « transfuges » de l?informatique, au-delà du rythme des projets, et font appel directement à des sous-traitants du monde informatique pour spécifier leurs besoins de façon très analytique. Par ailleurs, les managers des métiers de l?entreprise n?ignorent plus l?organisation par projet, dont ils sont devenus mêmes experts dans certains domaines. Aussi ils n?hésitent plus à proposer des solutions et parfois même à les préconiser avec force, au risque de heurter les équipes informatiques. Cette nouvelle compétence n?a pas échappé aux acteurs du marché informatique qui ont bien compris les enjeux d?une intervention le plus en amont possible auprès des maîtres d?ouvrage. Consultants, éditeurs et même intégrateurs ont donc pris pour cible les maîtrises d?ouvrage, et au plus haut niveau les dirigeants eux-mêmes, pour vendre leurs solutions en négligeant, de fait, aussi bien les contraintes de cohérence inter-applicatives que les choix techniques d?entreprise. Les maîtrises d??uvre, qui traditionnellement constituent le front-office des directions informatiques, ont également développé une expérience nouvelle par leur connaissance de plus en plus aigue des métiers de l?entreprise. Les directions informatiques sont devenues « systèmes d?information » et les solutions qu?elles mettent en ?uvre ne sont plus issues d?une seule lecture technique des problèmes, mais nourries par une approche plus globale, d?ailleurs elle-même structurée par une démarche d?urbanisme et d?architecture des systèmes d?information. Quant aux chefs de projet, ils n?ignorent plus les contraintes économiques ni les nécessités d?une exploitation continue et sans faille au service des métiers de l?entreprise. Enfin, les utilisateurs eux-mêmes ont changé ! Internet a transformé leur relation avec l?informatique. Mieux éduqués, grâce à leur pratique domestique, ils sont devenus moins respectueux envers les directives et les choix des équipes informatiques, qu?ils n?hésitent plus à contester ou même à contourner, grâce aux stagiaires notamment. Concevoir, communiquer, échanger, faire ses achats sur internet conduit les utilisateurs naguère passifs à devenir des acteurs exigeants. Chacun a maintenant son point de vue sur l?informatique et développe une approche consumériste, souvent stimulante, parfois exaspérante pour les équipes informatiques chargées de garantir fiabilité, cohérence et pérennité des solutions dans un cadre économique contraint. Enfin, le champ informatique n?est plus un espace clos. Il est ouvert aux influences du marketing des éditeurs, aux poussées des pratiques issues du monde domestique conquis par la numérisation, au désir crée par les solutions du monde de l?internet dans tous les domaines. L?informatique a également dépassé le cadre strict de la seule entreprise pour s?ouvrir à l?entreprise étendue, aux réseaux complexes d?interdépendance entre les acteurs de la chaîne de valeur. Ces influences multiples tissent un tissu relationnel riche et complexe face auquel le modèle classique MOA/MOE apparaît réducteur. Une nouvelle rigueur coopérative Dépasser le modèle est nécessaire. L?abandonner serait totalement dangereux pour l?entreprise et les acteurs. En effet, il est clair pour tous que les métiers ne doivent pas se diluer au profit d?une organisation univoque soit dirigée par les utilisateurs, soit aux mains des seuls informaticiens. La coopération des compétences, désormais de bien meilleur niveau, est nécessaire pour atteindre un bénéfice durable et insérer les systèmes de façon robuste dans l?architecture d?entreprise. Tous les acteurs doivent être animés par le même volonté de contribuer à la création de valeur, chacun en fonction de sa place dans l?organisation. Cet engagement est essentiel pendant la durée du projet, il est encore plus important après le projet quand la dynamique d?équipe n?existe plus et qu?il faut aller vraiment récupérer les bénéfices escomptés par l?investissement. Le choix des équipes est donc essentiel et doit être assuré avec soin par les dirigeants eux-mêmes. C?est un acte de management majeur qui ne peut être délégué. Plus que les méthodes, c?est la cohérence du casting de projet qui en fera le succès ! Mais il faut désormais intégrer dans la conception de systèmes d?autres regards indispensables au succès de l?ouvrage. Resituer clairement l?utilisateur final dans le processus d?élaboration du système est indispensable pour donner aux systèmes construits la capacité de faire évoluer les pratiques réelles des acteurs du terrain dont certains maîtres d?ouvrage n?ont plus qu?une vision distante. Intégrer les attentes très différentes des utilisateurs d?un même système est également essentiel. Les modes d?utilisation se sont complexifiés. L?opérateur qui pratique toute la journée des interventions en ligne au centre d?appel ou le dirigeant qui en consulte les statistiques d?activités n?ont clairement pas les mêmes besoins et les mêmes attentes. C?est parce que ces besoins sont trop souvent ignorés qu?Excel est devenu le plus utilisé des systèmes d?entreprise ! Enfin, il faut admettre que le déploiement systématique et linéaire de toutes les étapes définies par les méthodes de projet ne répond plus à l?attente de vitesse et de réactivité de l?époque. Partir d?une feuille blanche pour construire une analyse des « besoins » des utilisateurs et construire en chambre un système qui est ensuite imposé à ces mêmes utilisateurs, longtemps après les travaux initiaux au terme d?un interminable effet tunnel, relève aujourd?hui, dans la grande majorité des cas, d?une approche désormais dogmatique des systèmes d?information. Rendre plus réaliste l'attribution des rôles Il faut intégrer ces nouvelles données pour donner plus de réalisme et d?efficacité à la construction des systèmes. L?approche projet, structurée, reste incontournable. Elle doit toutefois être sérieusement dépoussiérée. Le CIGREF, conscient de ce décalage croissant entre la théorie et la pratique, a identifié dans une étude publiée en 2003 huit macro-rôles qui répondent à des positions différentes dans l?organisation, et donc à un exercice plus fin et plus réaliste de la décision et de la responsabilité : ? arbitre ? conduite du changement ? maîtrise d??uvre stratégique ? maîtrise d??uvre technique ? maîtrise d?ouvrage opérationnelle ? maîtrise d?ouvrage stratégique ? utilisateurs externes ? utilisateurs internes. Cette classification cerne mieux les rôles et illustre bien la complexité organisationnelle auquel un système doit répondre. Elle introduit la diversité des usages des systèmes, chaque groupe d?acteur devant être représenté, et engagé, dans le processus de conception et de validation. Il va de soi que ces rôles n?impliquent pas nécessairement qu?ils soient confiés à autant d?acteurs différents. L?innovation consiste à prendre acte du fait que les utilisateurs et la maîtrise d?ouvrage ne constituent plus une entité unique, leurs attentes pouvant être très différentes. De même l?introduction explicite d?un rôle d?arbitre, qui peut être confié à l?un des acteurs, pour gérer les éventuels conflits entre MOA et MOE répond au besoin d?éviter tout blocage institutionnel qui conduit au ralentissement du projet, ou pire à des compromis souvent coûteux et finalement non satisfaisants en mode opérationnel. Au delà des jeux d?acteurs, il est impératif que les méthodologies de construction de système évoluent. On n?opère plus dans un terrain vierge. Les fonctions opérationnelles sont désormais toutes couvertes par des systèmes actifs. Les changements doivent être justifiés économiquement et se faire dans un contexte d?interopérabilité entre systèmes où le résultat doit réellement se traduire par une meilleure efficacité opérationnelle et un confort supérieur pour les utilisateurs. Partir du problème se révèle long et complexe, alors que l?on peut désormais, grâce au prototypage et aux progiciels, partir de la solution. Le choix d?un progiciel ne doit pas être imposé des mois après le début d?un projet, mais faire partie des hypothèses initiales. Transformer la relation maîtrise d?ouvrage/maîtrise d??uvre, c'est dynamiser le tissu relationnel entre les différents métiers de l?entreprise pour tirer le meilleur parti des technologies de l?information en construisant, et déployant, des systèmes attractifs et mobilisateurs. Ce n?est pas sans effort de compréhension mutuelle, de formation et de méthode. Penser que l?informatique d?entreprise est simple parce que chacun désormais utilise Internet serait réducteur. La différence tient dans le poids de la base installée et des contraintes d?interfaces, comme dans la continuité de service qui requiert de lourds investissements. C?est cette compréhension qu?il faut développer en intégrant le plus grand nombre d?acteurs dans l?action à travers une méthodologie rigoureuse de tri des projets, d?analyse de la valeur de chaque projet, et même de chaque livrable. Elle implique aussi la prise en compte par les acteurs des contraintes d?interopérabilité et d?exploitabilité qui introduisent des normes perçues comme limitatives. Un projet soit être également un espace de pédagogie offrant l?opportunité de renforcer les compétences de chacun. MOA/MOE, un même lit pour deux rêves ? Cette coupure rivale doit être vigoureusement dépassée. Les systèmes d?information, pour être efficaces, ne peuvent qu?être le fruit d?un travail coopératif, engageant tous les acteurs. Les entreprises en ont besoin ! Nota : cette note reprend des éléments d'un article publié dans la revue "Information & Systèmes" (http://www.soc-infos.com/) du mois de mai 2006, qui consacre un dossier au sujet. |