Avant d'être une aventure technologique, un projet informatique est avant tout un projet humain.

 

Il rassemble des acteurs projets qui doivent travailler ensemble pour définir le besoin, la solution, pour la mettre en oeuvre et la déployer. Cet espace se propose de mettre le focus sur les principaux acteurs projets. 

 

Les projets informatiques

Les acteurs projets

 

Dans l'industrie aussi

 

Le principe est absolument identique au sein d'une entreprise. Prenons par exemple une entreprise de construction automobile. La direction du marketing va réaliser les études nécessaires pour étudier le positionnement de l'entreprise sur le marché, et surtout pour étudier les attentes des clients.

 

Elle identifiera par exemple, que les clients veulent acheter des voitures confortables, ni trop grandes, ni trop petites, mais qui roulent à l'électricité, avec une autonomie minimale de 300 km, avec une vitesse de pointe de 130 km/h (c'est ce que je recherche !!).

 

La direction du marketing se pose donc comme l'entité qui sait définir la cible qu'il faut atteindre. Elle va donc coucher sur papier la description de la voiture idéale des acheteurs.

 

Le cahier des charges par exemple de la 2CV de citroën tenait en quelques mots : " quatre roues sous un parapluie avec quatre places assises, 50 kg de bagage transportable, 2 CV fiscaux, traction avant, 60 km/h en vitesse de pointe, boîte à trois vitesses, facile d'entretien, possédant une suspension permettant de traverser un champ labouré avec un panier d'œufs sans en casser un seul, et ne consommant que 4 à 5 litres aux 100 kilomètres."

 

La direction du marketing va donc agir comme une "maîtrise d'ouvrage" auprès de la structure interne de l'entreprise qui est chargée de la conception technique de la voiture : la "maîtrise d'oeuvre".

 

Chacun a sa propre responsabilité :

 

  • La responsabilité de la maîtrise d'ouvrage est d'avoir réussi à bien cibler le désir de la clientèle, et de ne pas s'être trompé dans le cahier des charges. Si la voiture ne plait pas dans sa définition et qu'elle ne se vend pas, ce ne sera pas la faute de la maîtrise d'oeuvre

 

  • La responsabilité de la maîtrise d'oeuvre est de réussir à concevoir une voiture qui réponde en tout point au cahier des charges, dans les temps, les coûts et dans le délai. Si la voiture ne se vend pas parce qu'elle tombe systématiquement en passe, ce sera de sa responsabilité, et non celle de la maîtrise d'ouvrage

 

Ce n'est évidemment pas si simple : si la maîtrise d'oeuvre a alerté la maîtrise d'ouvrage d'une infaisabilité technique (exemple : technologies non matures) et que la maîtrise d'ouvrage n'a pas accepté d'en tenir compte, la responsabilité des problèmes techniques qui en résultent lors de la production en est partagée. Dans la théorie.

 

Il faut donc impérativement que les acteurs projets connaissent et respectent le périmètre de leurs responsabilités respectives.

Les projets informatiques n'échappent pas à la règle. Comme tout projet, qu'il s'agisse d'un projet de construction immobilier, d'un projet de route, il y a principalement deux responsabilités qui se partagent sur le projet : la responsabilité de celui qui définit ce qu'il faut faire (le quoi), et celui qui va définir comme le faire, et le réaliser le comment.

 

Au bord de nos routes

 

Un exemple tout simple que l'on voit sur le bord de nos routes, lorsque des travaux nous empêchent de circuler normalement. Profitez-en pour lire la pancarte, vous verrer ces mots : "maîtrise d'ouvrage" (encore appelée MOA) et "maîtrise d'oeuvre" (encore appelée MOE).

 

Pour les débutants et les étudiants, la différence entre les deux n'est pas toujours bien claires. Les mots se ressemblent, alors les missions doivent être les mêmes. Un jour, je parlais Gestion de projet à une personne qui se trompait en me parlant MOA, là où il fallait parler MOE. Tandis que je la rectifiais gentiment, elle m'avait dit : "oui, bon, ok, mais c'est la même chose".

 

Dans l'exemple des travaux de route, la "maîtrise d'ouvrage", c'est souvent la région et l'état. Ils gèrent le réseau routier de la région, et ils connaissent très exactement les besoins de déserte, ou de réparation des voies les plus abimées.

 

Ils décident donc de ce qu'il faut faire et vont le décrire au travers d'un cahier des charges : nombre de kilomètres de route, caractéristiques attendues du revêtement (anti bruit, anti gel, ...), résistance particulière aux intempéries (si région chaude ou froide), nombre de croisement, de sorties, équipements particuliers à intégrer dans la route (canalisations, etc...). Ils sont responsables de leur choix : s'ils se trompent dans le nombre de kilomètres, c'est de leur responsabilité.

 

La "maîtrise d'oeuvre", c'est l'entreprise qui va réaliser. Ce sont les professionnels de la construction de routes qui savent comment répondre techniquement à une demande particulière. Pour résister à certains intempéries, ils proposeront un certain type de rêvetement. Pour chaque kilomètre de route, ils pourront dire le coût nécessaire en fonction de la situation géographique. Surtout, ils sont capables de mobiliser les équipes et les matériels pour construire la route. Ils savent le faire en respecter l'état de l'art et savent respecter les délais, la qualité, et les coûts prévus.

 

"Maîtrise d'ouvrage" et "Maîtrise d'oeuvre" travaillent donc de concert dans l'atteinte d'un même but : construire une route de qualité, qui possède des caractéristiques attendues (résistance, adhérence, bruit de roulement, ...), qui passe aux bons endroits, et qui rendent les services qu'en attend la population.

 

MOA & MOE

 

Responsabilités

L'une des clés de la réussite d'un projet tient en partie au respect des responsabilités de chacun, et surtout à la parfaite connaissance du périmètre de chacune des responsabilités que chaque acteur a dans le projet.

Qui a la responsabilité de quoi ?

 

Dans le cadre d'un projet, il est important de passer en revue toutes les actions à réaliser pour la réalisation du projet, depuis la définition du besoin, jusqu'à la formation des utilisateurs, et le déploiement au sein des utilisateurs.

 

Illustration avec cet exemple de quatre structures d'une même entreprise participant à la commercialisation d'un nouveau produit. Les responsabilités sont partagées entre les trois structures.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dans cet exemple, que constate-t-on dans ce schéma :

 

  • les structures (1) et (2) semblent ici mélanger leurs responsabilités. La structure 2 se mêle de la définition du produit, confiée à la structure 1. Si ce travail est "collaboratif" en laissant le leader ship à la structure (1), tout va bien : il s'agit alors de solidarité transverse ou d'agilité au sein de l'entreprise ! Par contre, si la structure (2) prend des décisions unilatérales sur le périmètre des responsabilités de la structrure (1) par abus d'autorité, cela aura de fâcheuses conséquences : blocage de décision, conflits de personnes, indécision, mauvaises décisions

 

  • quant à la responsabilité "définir le service après vente", on voit ici que cette responsabilité ne semble être attribuée à personne. Problème, car en pensant que tout le monde s'en occupera, personne ne s'en occupera. La preuve : envoyez un mail demandant une action à 4 personnes en destinataire directe, sans décision un responsable de l'action, et vous constaterez que l'action ne sera pas faite !

 

Un enjeu majeur

 

En reprenant l'exemple précédent, la maitrise d'ouvrage a une responsabilité : celle de définir l'outil à réaliser, et les besoins que l'outil doit couvrir. La maîtrise d'oeuvre a une responsabilité : étudier, concevoir une solution technique, la mettre en oeuvre.

 

Dans la théorie, tout est clair. Dans la pratique, ce n'est pas si simple car interviennent alors différents paramètres propres à notre chère race humaine, qui met toujours quelques grains de sables :

 

  • Les acteurs peuvent ne pas avoir compris leur rôle, et leur limite 

  • La maîtrise d'ouvrage veut imposer une solution technique, alors que ce n'est pas son rôle

  • La maîtrise d'oeuvre modifie les fonctionnalité de son propre chef, alors que ce n'est pas son rôle

  • Les "esprits forts" de l'une ou l'autre partie tentent d'imposent des points qui ne dépendent pas de leur responsabilité

 

Bien entendu, c'est dans le pire des cas. Toutes les personnes ayant participé à un projet informatique, en qualité de MOA et de MOE savent bien que ces problèmes sont extrêêêêêêmement rares (...).

 

Dans le meilleur des cas, nous avons donc une relation de la collaboration sympathique entre les deux entités qui se gardent bien, l'une et l'autre, d'empiéter sur la responsabilité du voisin.

 

 

 

 

 

 

 

 

 

 

 

 

 

Mais il peut arriver que cette frontière ne soit pas si franche. La MOA propose des solutions techniques (alors que ce n'est pas son rôle), ou la MOE intervient sur les choix fonctionnels, autrement que pour raison d'infaisabilité technique ou d'optimisation.

 

Ce mélange des genres ne peut être possible que dans le cas d'une démarche de projet agile, impliquant une forte interactivité entre les deux entités. Dans tout autre cas, les ennuis se dessinent à l'horizon.

 

 

 

Maître d'ouvrage

Définition et description du besoin

 

La maîtrise d'ouvrage est l'entité responsable de la description du QUOI. Autrement dit, la maîtrise d'ouvrage doit pouvoir expliquer clairement et sans ambiguité le résultat qu'ils souhaitent obtenir sur un plan purement fonctionnel.

 

Pour cela, l'équipe MOA rédigera un document appelé expression du besoin ; il s'agit d'un document purement descriptif sur les services attendus par le nouveau produit. On ne doit pas y trouver de termes techniques informatiques (base de données, tables, SQL, ...) mais uniquement des descriptions écrites en français courant.

 

Identification du budget & ROI

 

C'est la maîtrise d'ouvrage qui détient les cordons de la bourse. La MOA a un budget dans l'année qu'elle peut consommer sur des projets informatiques. Ce budget aura été défini dans le cadre d'un plan stratégique défini pour l'année, en concertation avec la maîtrise d'oeuvre. C'est donc la maîtrise d'ouvrage qui connaît les budgets à utiliser pour réaliser le projet demandé.

 

En qualité d'expert métier, seule la maîtrise d'ouvrage peut juger de l'intérêt de son projet, en calculant un retour sur investissement positif. Si un conflit apparaît sur la pertinence du projet, c'est la maîtrise d'ouvrage qui doit se battre pour le défendre auprès de la Direction Générale parce qu'ils sont, comme l'on dit, "porteurs du projet". 

 

Un rôle décisionnaire

 

La maîtrise d'ouvrage détient l'entière responsabilité de la définition fonctionnelle. Toute décision relative à la définition fonctionnelle du projet (règle de gestion, ...) est de la seule et unique responsabilité de la maîtrise d'ouvrage qui doit avoir le dernier mot (même si la décision est mauvaise).

 

La maîtrise d'ouvrage ( MOA ) est composée d'un chef de projet MOA, pouvant éventuellement encadrer une équipe de collaborateurs chargés de participer au projet jusqu'à sa mise en oeuvre.

 

Les acteurs de la maîtrise d'ouvrage ne doivent pas être informaticiens, et ne doivent surtout pas être rattachés à la direction informatique de l'entreprise (pour ne pas brouiller les responsabilités). Ce sont plutôt des experts métier, dans le domaine professionnel pour lequel un projet est monté (paie, comptabilité, ...). 

A ce titre, la maîtrise d'ouvrage doit valider toutes les descriptions fonctionnelles touchant son outil. En particulier, la maîtrise d'ouvrage doit participer activement à la validation du cahier des charges détaillé, rédigé par la maîtrise d'oeuvre à partir de l'expression de besoins brute fournie. Le cahier des charges a pour but d'approfondir chaque fonctionnalité demandée.

 

La maîtrise d'ouvrage doit intervenir aussi dans chaque décision fonctionnelle à prendre sur le projet. Par exemple, sur certains projets informatiques, des compromis doivent souvent être faits. Par manque de budget, il arrive que l'on soit obligé de "restreindre le périmètre fonctionnel" du projet, c'est à dire que certaines fonctionnalités ne seront pas réalisées. Il revient à la maîtrise d'ouvrage de prendre la responsabilité du choix de ces fonctionnalités.

 

Validation de la conformité

 

En qualité de responsable de la description du projet, la maîtrise d'ouvrage a la responsabilité de valider la conformité de l'outil avec les besoins qu'elle a énoncés, avant sa mise en oeuvre. Auparavant, la maîtrise d'oeuvre aura réalisé ses propres tests. Ces tests correspondent à la phase de recette.

 

Cette conformité se vérifie en réalisant des tests fonctionnels menés par l'équipe de la maîtrise d'ouvrage. Pour les réaliser, les membres de l'équipe MOA dérouleront les fonctionnalités demandées, et vérifieront une par une que ce qui a été développé correspond bien à ce qui a été décrit dans le cahier des charges détaillé, et validé par la maîtrise d'ouvrage. Il s'agit par exemple de vérifier les règles de calcul pour un projet d'application de paie.

 

L'accompagnement au changement

 

C'est à la maîtrise d'ouvrage que revient la lourde charge d'accompagner le changement auprès des utilisateurs du projet. Cette étape est cruciale, car de la bonne réalisation de cette accompagnement dépend la réussite globale du projet. Car un projet informatique développé dans les règles de l'art et sans aucun bug peut s'avérer être un échec si l'outil est rejeté au final par l'utilisateur qui aura été mal préparé.

 

Cette étape comprend les formations aux utilisateurs, les informations, les préparations auprès des équipes, les modifications des procédures de travail, etc...

 

Maître d'ouvrage déléguée

 

Pourquoi une MOAD ?

 

Toutes les structures de l'entreprise (les RH, les juristes, ...) n'ont pas forcément une grande expérience des projets informatiques. Des collaborateurs se retrouvent dans la peau d'une maître d'ouvrage par obligation juste parce qu'ils ont un besoin d'outil informatique mais pour autant, ils n'ont pas forcément ni la compétence interne ni la formalisation suffisante pour mener à bien la phase projet qui leur incombe.

 

Pour une maîtrise d'oeuvre, mener un projet avec ce type d'interlocuteurs est très difficile. La culture projet fait défaut. Il faut les accompagner à chaque étape du projet, réexpliquer ce qu'est une application, ce qu'on peut faire / ne pas faire. Il faut expliquer ce qu'on attend d'eux, en termes de validation, ou d'expression de besoins. Il faut expliquer ce qu'est une recette et les accompagner fortement.

 

Cette situation est source de conflits et d'agacement de part et autre, entre la MOE qui a l'impression d'avancer au ralenti, et la MOA qui a l'impression d'être pris par la main comme un enfant.

 

 

Pour remplir le rôle de maîtrise d'ouvrage, il faut maîtriser un minimum le contexte d'un projet informatique, en avoir la culture, et connaître le périmètre de ses responsabilités.

 

Tous les collaborateurs n'en ont pas la compétence ou tout simplement, n'en ont pas le temps ; dans ce cas, le recours à une maîtrise d'ouvrage déléguée (MOAD) s'impose.

La mission de la MOAD

 

Dans ce cas intervient une équipe intermédiaire, souvent transverse à l'entreprise, plus rompue à la gestion de projet : la maîtrise d'ouvrage déléguée encore appelée MOAd.

 

Cette équipe, composée de collaborateurs habitués à la conduite de projets, intervient en renfort méthodologique et épaule la maîtrise d'ouvrage à la fois dans la démarche projet et dans l'expression de son besoin.

 

Souvent composées de quelques "anciens" informaticiens ou de collaborateurs ayant une bonne idée des contraintes informatiques et des besoins en formalisation, les maîtres d'ouvrage déléguées savent faire l'interface entre la maîtrise d'ouvrage et la maîtrise d'oeuvre.

Maître d'oeuvre

La compréhension du besoin

 

La première responsabilité de la maîtrise d'oeuvre est de comprendre le besoin de la maîtrise d'ouvrage. Comprendre le besoin, c'est lever toutes les ambiguïtés qui pourraient subsister. C'est donc interroger la maîtrise d'ouvrage, et l'aider à exprimer tous les détails utiles de son besoin, même (surtout) si la maîtrise d'ouvrage a quelques difficultés pour le faire.

 

La compréhension se concrétise par la rédaction du cahier des charges détaillé : ce document reprend chaque besoin exprimé par la maîtrise d'ouvrage dans son expression de besoin, et le décrit en détail.

 

Le devoir de conseil

 

La maîtrise d'oeuvre a un devoir de conseil vis à vis de la maîtrise d'ouvrage. Le devoir de conseil, c'est expliquer les points de risque identifiés dans les besoins énoncés par la maîtrise d'ouvrage. Ces risques peuvent être des fonctionnalités qui peuvent être dangereuses pour la cohérence globale, ou visiblement inadaptées.

 

En dernier lieu, la maîtrise d'ouvrage a le dernier mot sur les choix fonctionnels. Il arrive que les mises en garde énoncées par la maîtrise d'oeuvre soient ignorées par la maîtrise d'ouvrage. Qu'importe, le devoir de conseil de la maîtrise d'oeuvre est de lever les alertes, si possibles au travers de documents formalisés (notes, ...).

 

L'adaptation aux métiers

 

La maîtrise d'oeuvre travaille souvent sur plusieurs projets issus de métiers différents. Elle travaille donc pour plusieurs maîtrises d'ouvrages pour des projets informatiques de paie, comptabilité, ... même si bien souvent, dans les sociétés de taille important, les MOE sont spécialisées par systèmes d'information.

 

La maîtrise d'oeuvre a donc une obligation d'adaptation à chaque maîtrise d'ouvrage. Les informaticiens doivent s'adapter au nouveau métier, au nouveau vocabulaire, etc... La maîtrise d'oeuvre doit donc être capable d'adapter son vocabulaire et son langage au nouveau domaine.

 

La maîtrise d'oeuvre (MOE) est composée d'un chef de projets MOE qui pilote une équipe d'informaticiens chargés de concrétiser ce qui n'était juste là qu'une simple idée. Alors que la maîtrise d'ouvrage est responsable du "QUOI", la maîtrise d'oeuvre est responsable du "COMMENT".

 

Les acteurs de la maîtrise d'oeuvre sont des informaticiens. Ils appartiennent à tous les corps de métier de l'informatique si nécessaire : le développement, réseau, base de données, serveurs, etc... Voici ci-dessous les principales responsabilités de la maîtrise d'oeuvre.

 

Les choix technologiques

 

La maîtrise d'oeuvre a la difficile et grosse responsabilité des choix techniques. Ces choix vont impacter le projet tout au long de sa vie. Les choix à réaliser sont nombreux :

 

  • choix du langage de programmation,

  • dimensionnement des machines,

  • architectures,

  • réseau,

  • bases de données,

  • structure des programmes,

  • structure des bases de données,

  • etc...

  •  

 

Un mauvais choix peut s'avérer désastreux pour le projet, et aboutir à des blocages du système, ou à des ralentissements rendant l'utilisation impossible.

 

La mise en oeuvre technique

 

Seconde responsabilité importante de la maîtrise d'oeuvre : concrétiser sur le plan informatique ce qui n'était jusqu'alors qu'une simple expression de besoins. La mise en oeuvre technique, c'est la mise en oeuvre de tous les moyens technologiques nécessaires pour qu'un outil informatique rende les services demandés par la maîtrise d'ouvrage :

 

  • développement de l'application (code informatique)

  • mise en oeuvre des bases de données

  • mise en oeuvre des échanges informatiques entre les systèmes

  • etc... 

 

La qualité et la conformité

 

La maîtrise d'oeuvre a la responsabilité de la qualité des réalisations. Elle garantit, par les tests que son équipe réalise, que les applications livrées sont conformes aux spécifications validées au début du projet. La maîtrise d'oeuvre garantit aussi la bonne qualité de fonctionnement, sans bug.

 

La pérennité et
la continuité de service

 

La maîtrise d'oeuvre est responsable de la pérennité des applications et de la continuité de service. La pérennité des applications, c'est de faire en sorte que l'application puisse évoluer au fil du temps, et qu'il soit facile d'intervenir en cas d'incident. Cette pérennité passe par des développements de qualité, et par une documentation technique et de production adéquates.

 

La continuité de service correspond à la capacité du système de ne jamais être indisponible. Pour cela, de nombreux moyens techniques doivent être mis en oeuvre : serveurs de secours, doublement des serveurs, sauvegardes / restauration, etc...

 

Chef de projet

 

Le Chef de projet est celui qui fait avancer le projet. Il joue un rôle primordial pour faire en sorte que le projet soit une réussite.

 

La description de cet acteur essentiel du projet mérite une rubrique dédiée : cliquez ici