Previous month:
mars 2006
Next month:
mai 2006

Maîtrise d'ouvrage vs maîtrise d'oeuvre, un même lit pour deux rêves ?

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.


La révolution applicative est en marche

Le monde de l’informatique professionnelle d’entreprise est confronté, une fois encore, à l'émergence de nouveaux vecteurs de transformation de nature à bouleverser son évolution. Certes, ce n'est pas une situation nouvelle pour un milieu qui a su affronter de multiples ruptures. Mais, si d'habitude les transformations étaient impulsées par l'innovation technique, il s'agit cette fois d'une remise en cause qui touche le champ applicatif sous la poussée des solutions mises en oeuvre dans le monde grand public de l'internet.

Les évolutions matérielles ont été généralement bien intégrées par l'informatique d'entreprise. La transformation régulière des capacités du matériel a été alimentée par la loi de Moore. Elle est prédictible et apporte des performances de plus en plus élevées. Les professionnels s’entendent désormais pour reconnaître que la production de "l’énergie informatique" n’est plus désormais leur principal motif de préoccupation. Puissance machine, capacités de stockage, bande passante, généralisation de l'IP, poste de travail individuel sont disponibles à grande échelle, pour un coût maîtrisable, et ces infrastructures peuvent sans problème majeur, être exploitées par des firmes spécialisées. Certes des progrès - virtualisation, rationalisation, haute disponibilité, mobilité - peuvent encore être accomplis, mais ils seront, dans un horizon visible, incrémentaux. Il resterait bien entendu à mieux intégrer dan sle système d'information d'entreprise les outils de la mobilité qui proliférent aux marches de l'informatique "sérieuse", plus tolérés encore qu'exploités pleinement. Cette évolution se fera naturellement, comme le PC a bien su trouver sa place "professionnelle" après des débuts timides.

Le cœur des préoccupations  des DSI se situe désormais dans les applications. L’édifice applicatif construit depuis maintenant plusieurs décades est fragilisé par le poids des couches historiques qui s’entassent sans que jamais les entreprises n’aient eu le temps et les moyens de faire le nettoyage qui s’imposait. Ce chaos est le résultat des pratiques managériales et des processus, souvent contradictoires au gré des évolution des organisations, figés dans le code des applications. Les informaticiens ne repartent jamais à la base mais réexploitent les couches antérieures. Ce mode d'évolution a déja été ébranlé dans les années quatre-vingt dix par la "crise" des progiciels, mais les outils d'ERP, SCM et autres CRM n’ont pas fait disparaître les systèmes spécifiques et l'informatique d'entreprise a su les intégrer, renforçant encore la complexité de l'édifice. Il est fréquent de dénombrer dans les grandes entreprises des portefeuilles applicatifs "riches" de plusieurs milliers d'applications, lacis inextricable de connexions et d'interfaces de nature et d'âge hétérogènes.

Le phénomène réellement révolutionnaire, et donc déstabilisant pour tous les acteurs de l’écosystème informatique, résulte de la nature même de la nouvelle menace : le débat est sorti du cénacle des professionnels pour être porté par l'utilisateur final lui-même.

Les utilisateurs sont désormais une grande majorité à utiliser chez eux une informatique attractive, multimédia, efficace et disponible, celle du web. Leur tolérance envers l’informatique qu’ils utilisent dans leur milieu de travail est de plus en plus réduite, d’autant plus que les jeunes générations, qui sont nées dans ce monde de liberté, de mobilité, d’échange multimédia et de fluidité, ne comprennent pas que subsiste une autre informatique, qu’ils perçoivent comme contraignante et sommaire,…

Face à une exigence forte de modernisation et d’attractivité, les professionnels doivent donc intégrer dans leur stratégie deux évolutions contrastées :
- d’une part, un mouvement de rationalisation du portefeuille d’application qui passe à la fois par une optimisation de l’existant et par l’introduction de nouvelles méthodes de travail, tant en architecture qu’en développement, pour construire des applications plus flexibles et moins coûteuses : ce sont, hélas, des actions lentes et difficiles, et qui impliquent des invetissements majeurs
- d’autre part, l’explosion d’innovations de logiciel dans le monde du consommateur et, dans une certaine mesure, celui des PME, alimentée par l’essor du mouvement « Open source », et qui doivent trouver leur place dans les systèmes d'entreprise : ceci implique une dynamique de développement centrée sur l'utilisateur final et exploitant toutes les ressources des technologies du web

Si la mission des DSI est bien d’irriguer les métiers par les processus et l’information qui les alimentent, ils ne peuvent ignorer que les « consommateurs » informatiques de leurs entreprises ne peuvent indéfiniment attendre la lente transformation de leurs applications "historiques" pour disposer de la réactivité et de la capacité d'innovation dont ils ont besoin. Ils sont ainsi confrontés à une demande immédiate de "bouquets de services", à la fois fiables et attractifs, pour permettre à ces utilisateurs d'exploiter pleinement les outils séduisants de la société numérique.

Aussi, comment peut-on aller plus vite, avec qui, quels sont les vecteurs de transformation dans les méthodes et dans les produits ? La tâche est complexe et implique la construction d'un vaste programme de transformation de l'informatique d'entreprise, plus Plan Marshall que plan ORSEC...

Il faut sans aucun doute s'inspirer des modèles émergents de l'informatique de l'internet, attractifs, efficaces mais très éloignés des pratiques habituelles des entreprises. C'est celui des communautés de l'open source. Mais ce modèle aussi novateur qu'exigeant implique de la discipline et un nouveau management et de compétences.

Les produits qui en sont issus atteignent désormais l'âge de la maturité et peuvent être intégrés dans les systèmes d'entreprise avec la même rigueur que les composants propriétaires. Apache, Linux, Eclipse, Open Office, Ingres sont désormais des solutions effectives et admises dans les entreprises, et le monde LAMP (Linux, Apache, MySQL, Perl ou PHP) n'est plus considéré comme obscur. Mais, plus que les outils, ce sont les méthodes de travail qui sont intéressantes car elles permettent de générer des communautés de savoir, stimulantes et exigeantes... Wikipedia est le modèle d'un savoir en mode "open source" !

Il faut aussi que ces nouvelles équipes exploitent le potentiel et les exemples du monde du "Web 2.0" et en tirent profit pour les adapter au monde classique de l'entreprise.
A titre d'exemple, pour comprendre la puissance de ces outils, visitez le site BaeBO (http://baebo.francisshanahan.com/) qui permet d'exploiter simultanément ebay, Amazon et Yahoo, mais aussi de chercher dans les blogs de Technorati l'opinion des utilisateurs.. Il faut aussi comprendre, par exemple, la puissance de Google maps ou de la base image de flickr pour en tirer des applications métier. Il faut aussi sûrement évaluer le potentiel collaboratif de la suite Zimbra... parmi d'autres exemples de systèmes innovants.

Ces outils sont méconnus, perçus comme marginaux et peu fiables par les informaticiens "classiques" alors qu'ils font le miel des nouvelles générations. Il y a là bien sûr un risque de conflit générationnel, comme on l'a vécu avec l'avénement du modèle client/serveur, mais cette fois c'est la génération Linux contre la génération Microsoft, IBM étant, habilement, passé du côté des rénovateurs...

C'est un monde nouveau, qu'il faut explorer avec intérêt même si dans beaucoup de situations encore les solutions peuvent apparaître immatures et difficiles à exploiter à grande échelle. Il y a bien sûr des risques. Et l'inertie des outils d'entreprise rendra toute évolution majeure délicate tant pour faire bouger les outils que les utilisateurs. C'est pourquoi il faut aborder dès maintenant ce "nouveau monde" et commencer à s'y préparer, d'abord par la veille, puis par l'expérimentation. Cela prendra des années. Raison de plus pour commencer maintenant !