@DOMAINE:SOLUTIONS

@ST OUV:

@T RUB1:Les nouveaux outils du "maître d'ouvrage"

@CHAPO:

@TEXTE:L'annonce récente du produit Skipper (Assent Technology) montre que les informaticiens commencent à s'approprier de la bureautique. Exploitant les fonctions de Lotus Notes et la logistique de l'intranet, ce nouvel outil intègre notamment la messagerie, l'agenda et la gestion documentaire pour offrir un outil de dialogue entre maîtrise d'oeuvre et maîtrise d'ouvrage.

D'autres logiciels de gestion de projet sous Notes pourraient s'adapter à cette fonction: SDP/1 (Abakus), Groupe Projet (RCom), Project Manager Officer (LGS Europe), ou encore les grands classiques de la gestion de projet (Artemis notamment). Mais ils restent plutôt axés sur la planification et la comptabilisation des ressources.

Il s'agit, au fond, d'une méthode "douce" (pour ne pas dire "soft"), alors que le génie logiciel a jusqu'à présent cherché son inspiration des des formalismes rigides. Cobol exprimait le désir d'un langage commun de conception, utilisable par les utilisateurs. A l'image de Fortran, qui continue de jouer ce rôle pour les applications scientifiques. Mais la gestion fait coopérer des acteurs trop différents et construit des systèmes trop compliqués pour qu'un langage de programmation suffise à l'expression de leurs besoins. D'où le développement des "méthodes". Malgré les charmes de leur "boxologie" (expression due à Henri Habrias), peu d'utilisateurs s'en servent directement. Même (et surtout?) si le génie logiciel amont ("upper case") facilite la création et la navigation de ces univers formalisés.

@INTER:Structurer le dialogue

@TEXTE:Or les utilisateurs veulent de moins en moins s'en remettre aux informaticiens pour résoudre leurs problèmes, a fortiori pour concevoir à leur place les nouveaux processus de gestion dont ils sont responsables. Ils demandent de l'aide, des médiateurs en quelque sorte. Les organisateurs, qui jouaient ce rôle il y a longtemps (des années 30 jusqu'au début des années 60) se sont laissés absorber par les directions informatiques, devenues souvant DOI avant de céder aux charmes de la systémique et de préférer le sigle DSI. Mais sans répondre aux frustrations des utilisateurs.

En attendant les logiciels, il fallait au moins un concept. Celui de maîtrise d'ouvrage" permet aujourd'hui de combler ce vide. Soit en spécialisant des équipes au sein des directions utilisatrices (ou opérationnelles), soit en faisant appel à des prestataires externes. Chose rare, il s'agit d'une innovation bien française. Le mot n'a pas de vraie traduction américaine. Vincent Guillot (Bossard Consultants) le voit d'ailleurs figurer "en français dans le texte" de contrats internationaux. Le mot vient de deux secteurs appelés à commander des ouvrages coûteux, complexes et associant des spécialités diverses: la Défense (où l'on trouve le terme de "procurement agency" (*)) et le Bâtiment, où l'on parle tout simplement de propriétaire (owner). Ce dernier terme a d'ailleurs été repris par les gourous du Business process reengineering, Hammer et Champy, qui parlent de "proces owners".

En revanche, pas de difficulté pour la partie correspondante, le "maître d'oeuvre" avec son équivalent américain "contractor", qui devient "prime contractor" si les responsabilités se décomposent en aval du contrat principal. Ce rôle se définit en effet plus facilement, puisque son intervention même découle d'un contrat. Plus ou moins précis selon les phases d'avancement du projet (d'une première conception d'ensemble à la réalisation clés en mains). Mais en tous cas formellement défini, dans ses objectifs comme dans son tarif, sinon dans les moyens à employer. Ce qui explique assez qu'il puisse ensuite se décomposer en "lots".

En revanche, une fois déléguée, sous-traitée, extenalisée une partie bien définie de l'activité de l'entreprise, il reste le flou et la responsabilité fondamentale de l'entreprise: vivre avec toutes les indéterminations de la vie, de la survie. C'est dans cet ensemble flou que l'on va chercher à formaliser un peu le travail, la démarche, les rôles. Car l'expérience montre qu'on ne peut se contenter de déléguer à un maitre d'oeuvre, externe ou interne. Il faut savoir dialoguer avec lui et garder la maîtrise de son métier. De l'expression des besoins au contrôle des produits et des prestations fournies, cela exige des compétences et une disponibilité qui définissent un rôle particulier, que nous appelons en France "maître d'ouvrage".

En fait, d'autres outils et d'autres formalisations viennent modifier le dialogue entre informaticiens et utilisateurs. Des batteries d'outils facilitent les diagnostics, l'étude des risques (Amdec, alyse des modes de défaillance, de leurs effets et de leur criticité). Le benchmarking et les audits.apportent aussi bien une évaluation de l'existant que des idées d'amélioration et dinnovation. Le mouvement pour la "qualité" et les normes ISO 9000 banalisent la descrition standardisée des activités.

Mais une grande part du travail de conception et de spécification des activités "métier" se trouve désormais sur étagère, avec les bibliothèques de composants (domaines techniques et scientifiques surtout) ou les progiciels. Et plus spécialement aujourd'hui dans les progiciels intégrés de gestion (ERP, Enterprise resource planning, en américain). En principe, ces produits ne présentent plus au maître d'ouvrage que des interfaces en "langage métier", et le problème de spécifications détaillées ne se pose que pour l'adaptation ou l'ajout de fonctionnalités. Parallèlement, l'externalisation de l'informatique (outsourcing, facilities management) radicalise séparation des utilisateurs et des maîtres d'oeuvre.

A la limite, il ne reste plus dans l'entreprise qu'une maîtrise d'ouvrage, éventuellement assistée voire déléguée à des consultants et firmes spécialisés. Les nouveaux outils visent à répondre à leurs besoins. Ils devraient peu à peu s'étoffer du point de vue juridique (contrats types, pointeurs sur des serveurs spécialiés d'experts) et comptable, pour offrir à la maîtrise d'ouvrage des tableux de bords bien intégrés. L'outil bureautique contribuerait ainsi à couper le cordon ombilical entre l'entreprise et ce qui était hier "son" informatique.@SIGNATURE:PIERRE BERGER

@LEGENDE:Le maître d'ouvrage respecte les objectifs, désigne le maître d'oeuvre, maîtrise le processus, conduit le changement et rend compte au client (Vincent Guillot, Bossard Consultants).

/////////sous-papier

@T RUB2:Les responsabilités du maître d'ouvrage

@TEXTE:Le maître d'ouvrage est, à la base, responsable des coûts, des délais et de la qualité. Mais aussi des points suivants, relevés par Jean-Michel Touratier (Bossard Consultants)

- Expression des besoins. Différentes normes décrivent les tâches d la maîtrise d'ouvrage, surtout dans l'optique de la qualité. Des "justificatifs" notamment le cahier des charges (mot d'ailleurs un peu inadéquat) ou la "spécification technique de besoins" (terme issu du vocabulaire militaire) . En cas de modification, venant par exemple de problèmes détectés par le maître d'oeuvre, ou de nouveaux besoins fonctionnels) une procédure doit permettre de se mettre d'accord. Le maître d'ouvrage explicite son accord sur les modifications fonctionnelles, le maître d'oeuvre sur les solutions techniques correspondantes.

- Organisation du projet, que le maître d'oeuvre doit au moins catalyser. Il faut prévoir aussi bien les organigrammes que les étapes de développement, les revues, les "points qualité".

- Logistique du projet. La tendance actuelle consiste à regrouper les acteurs du projet sur un "plateau" qui facilite la communication rapide entre eux. Mais cela n'exclut pas d'autre méthodes.

- Accompagnement du changement. En particulier de la communication avec les personnels concernés. Il faut les informer de l'état d'avancement du projet, valoriser ceux qui jouent un rôle moteur et faire preuve de diplomatie.

- Documentation du projet (de l'exposé des besoins jusqu'aux manuels utilisateurs en passant par les plans de management et les dossiers d'exploitation)

- Aspects juridiques relatifs à sa responsabilité, notamment en matière de sécurité et de confidentialité.

///////////:encadré

@T ENCA 1:LE COUT DE LA MAITRISE D'OUVRAGE

@TEXTE ENCA:Les experts convergent sur le chiffre de 10% du budget pour la conduite de projet logiciels (en excluant les achats de matériel). Pour le reste, Vincent Guillot (Bossard Consultants) propose la ventilation suivante:

- respect des objectifs, 20%

- produit informatique 40%

- accompagnement du changement 30%.

De son côté, Marc Frédéric (IBM-Cimad), indique:

- ré-ingénierie 30%

- conduite du changement 30%

- technique informatique 30%.

Le coût de la maîtrise d'oeuvre représente en moyenne 15% du prix d'un projet (achats de matériel et dépenses spécifiques d'organisation exclues). Actuellement, hélas, on voit de très grands projets se lancer sans prévoir ce poste. Alors que les petites entreprises et le monde industriel y est accoutumé, les grands administrations, en particulier, ont tendance à penser que leur mode hiérarchique de fonctionnement résoudra toutes ces questions.

///////

La compétitivité exige aujourd'hui de réaliser les projets en 18 mois, et parfois en une année seulement.

Le parallélisme intervient par exemple pour des entreprises qui veulent se mettre au niveau par rapport au marché mondial. Le système d'information est une des facettes du dispositif de reprise, qui peut porter sur plusieurs domaines fonctionnels, plusieurs processus. C'est d'ailleurs sur l' "inter-processus" que se situent aujourd'hui les grands enjeux.

Bruno Fontaine

L'approche du prototype itératif ne conduit pas à de bons résultats.

On nous fait intervenir pour les évaluer,

mais en fait on ne nous livre rien, car les gens savent que c'est d la merde

1. Qui est le maître d'oufrae?

- la direction utilisatrice

- un opérateur lambal

- quel contre-pouvoir à la maîtrise d'ouvrage: le contrôle de gestion

Le rôle du MU

simplifier les problèmes

évaluer les contraintes

design to cost (en en fait pour 5 MF)

2. Si on ne sait pas spécifier, il ne faut pas faire d'informatique

si pas de cadre de gestion écrit en français

avec des règles

une bible

c'st pour cela que les projets scientifiques et techniques ne merdent pas

un bon contrôle de gestion est capable de spécifier

Qui a le droit de le contrôler?

implémentation budgétaire annuelle

pas de culture de gestion

ils pensent qu'en prenant SAP ils sauront compter

mais ce sera encore bien pire

3. L'informaticien peut apporter au MU une assistance très importante

ils se sont fait blouser pendant dse décennies par les constructeurs

les DSI connaissent les pièges

dommanque que les utilisateurs à leur tour se fassent escroquer par les acteurs du marché

4. Les infrastructures communes sont définies de manière irréversible

si on laisse les MU définir de gros projets prioritaires, chacun avec leur infrastructure

on va de le bordel

il faut de la rigueur et du professionalisme

une plate-forme de référence, livrée par l'informatique, y compris le middleware et l'AGL

5. L'informatique met en place un processus de qualitication et de déploiement

intégration

en un lieu central

6. Il faut que la MU soit faite par les Dons opérationnells

notamment informatique stratégieue, services en ligne

on ne peut pas la responsabiliser

et la mettre sous contrainte extérieur

7. Management par objectif de s projets

contractualiser

avoir des objectifs quantitatifs, pas forcément économiques, mais mesurables

8. avoir une vision à 2 ou 3 ans

mais un livrable tous les 5 mois

Administration: Biont, Ahria implémentation du modèle

9. Pas forcément le maître d'oeuvre qui réalise

Si la maîtrise d'ouvrage prend le pouvoir. Si elle dispose des budgets et dispose de l'informatique interne et des sous-traitants comme de simples fournisseurs... n'ira-t-elle pas trop loin. Bruno Fontaine (Sycomore) pense qu'il faut prévoir un contre pouvoir. C'est tout naturellement, dans une grande entreprise, le contrôle de gestion.

........

Guillot

On fait concevoir de l'organisation par une DOI. Ce concept est erroné aujourd'hui.

La maîtrise d'ouvrage va définir le processus, et notamment son rythme. Autrefois, elle laissant la maîtrise d'oeuvre choisir le cycle de développement. Aujourd'hui, elle exige de voir des résultats tous les six mois, ce qui influe sur l'architecture même.

La maîtrise d'ouvrage élabore d'abord un modèle rustique de l'application. Un pré-modèle qui donne l'essentiel sans introduire trop de rigidités. Elle choisit si l'on gère par stocks ou par flux tendus par exemple. Et, au plus haut niveau, si la stratégie de l'entreprise est orientée client ou orientée produit.

La réussite du projet s'exprime avec les "trois U". Il doit être

- utile (respecter ses objectifs)

- utilisable (bonne qualité, notamment dans son ergonomie)

- utilisé (le changement doit être accepté, donc il faut le conduire)

La maîtrise d'ouvrage s'arrête aux spécifications fonctionnelles générales.

Le maître d'ouvrage conçoit les grandes lignes. Il doit avoir le pouvoir de changer l'organisation, qui ne relève pas de la maîtrise d'oeuvre.

Les coûts (matériels exclus) se répartissent ainsi:

20% pour le respect des objectifs

40% pour le produit lui-même, recette comprise

30% pour la conduite du changement

10% pour la conduite du projet proprement dite.

Le concept de maîtrise d'ouvrage a beaucoup évolué par rapport à ses origines, dans le secteur du bâtiment.

Donner le pouvoir de réorganiser l'entreprise à quelqu'un qui a intérêt à faire croître la dépense informatique, c'est risquer d'arriver à un monstre. A l'inverse, la maîtrise d'ouvrage a intérêt à ce que l'informatique ne coûte rien.

Le cycle de vie (innovation, conception, fabrication intégration) doit être défini par la maîtrise d'ouvrage. Non seulement dans sa durée globale, mais dans l'organisation de cycles itératifs. Ils peuvent viser soit à un perfectionnement progressif de l'application (par exemple l'ergonomie de l'interface homme-machine) soit un élargissement des fonctions par ajouts successifs.

La coopération entre maîtrise d'ouvrage et maîtrise d'oeuvre peut prendre la forme d'un partenariat. Elle implique, contrairement à la simple relation client/fournisseur, que la maîtrise d'ouvrage fournit elle aussi des prestations à la maîtrise d'oeuvre.

@NOTES:(*)Voir par exemple le classique "Méthodes de managemnet de programme", de Jean Cavaillès, Délégation générale pour l'armement, Editions Teknea, 1995).