Communiqué de presse,
actualité et interview...

Le projet est avant tout une aventure humaine qui peut durer dans certains cas 1 à 3 ans (entre la prise de décision, la mise en production et l'accompagnement des utilisateurs) et qui mobilise un ensemble d'acteurs pour atteindre un but. Chaque acteur assume, dans le projet, une responsabilité propre : planifier, réaliser, développer, recetter, valider...

Parmi cette somme d'acteurs, on peut identifier deux entités principales de l'organisation : la MOA, maîtrise d'ouvrage (le client du projet) (mais pas forcément l'utilisateur) et la MOE, maîtrise d'oeuvre, l'organe réalisateur du projet, représenté par le chef de projet.

Le maître d’ouvrage (MOA) est la personne ou le groupe qui exprime le besoin. Il précise les objectifs,les moyens, les délais et le budget alloué. Dans « ouvrage » il faut entendre le produit qui sera livré à la fin du projet.

Le maître d’œuvre (MOE) est la personne ou le groupe qui assure la production du projet dans le respect des délais, du budget et de la qualité attendue.Il s’agit souvent de la direction technique, du chef de projet technique, du lead developper ou encore, du développeur directement dans le cas de projets plus petits.

A savoir qu’il est fréquent de faire appel à un AMOA (ou AMO) – Assistance à Maîtrise d’Ouvrage. Il s’agit de la personne qui possède les compétences nécessaires au pilotage du projet. Il est très fréquent que ce rôle soit pris par un chef de projet ou un consultant fonctionnel. L’AMOA fait l’interface entre le MOA et le MOE, il s’assure que les besoins sont clairement exprimés auprès du MOE. Pour cela, il transforme un besoin en fonctionnalité grâce à la conception d’interfaces et à la rédaction d’un cahier des charges avec spécifications fonctionnelles. L’AMOA est également le soutien du MOE d’un point de vue technique, en l’assistant dans les choix techniques, l’apport d’informations au sujet des fonctionnalités à réaliser et les phases de recette.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.

Cette distinction figée est elle encore d'actualité?

Construire un système d’information dans un univers concurrentiel et un contexte organisationnel instables implique désormais une réactivité et une souplesse auxquels les méthodes classiques ne peuvent totalement répondre. Vis à vis du modèle classique MOA/MOE, basé sur une réelle séparation des compétences, les acteurs sont chacun devenus plus compétents sur le métier de l’autre et comprennent mieux l’enjeu du développement des technologies de l’information. Aujourd'hui, les maîtrises d’ouvrage ne découvrent  plus l’informatique. Elles en ont une expérience engrangée par des années de projets et d’usage des systèmes opérationnels. Elles peuvent formuler des avis pertinents 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.

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 directions informatiques sont devenues « systèmes d’information » (DSI) et les solutions qu’elles mettent en œuvre ne sont plus limitée à une approche technique mais nourries par une réflexion plus globale,  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.

Les utilisateurs eux-mêmes ont également leur mot à dire ! 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. 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 avec des budgets de plus en plus serrés.

Un nouvel modèle de gestion de projet à définir?

La coopération des compétences (techniques et fonctionnelles), 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 pérenne 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 la place qui lui est allouée 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 recenser les bénéfices escomptés par l’investissement. Le choix des équipes "projet" est donc essentiel.

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. Ce n'est qu'à ce prix que le projet peut emporter adhésion. Intégrer les attentes très différentes des utilisateurs d’un même système est également essentiel.

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.

Hans SAMSON, consultant SIRH spécialiste Domaines Paie et Gestion des temps Gérant de l’EURL EMSA CONSEIL