BodySplash.fr

Bon, me voilà devant un billet bien difficile à écrire. Critiquer une conférence de Sami Jaber est un exercice périlleux, mais bon, je suis fou je tente ma chance.

Au détour d'un coin de web, je suis tombé sur un article intéressant de Patrick Smacchia

Ça y est, c'est (presque) officiel, me voici embarqué pour les TechDays 2008

J'ai pas mal de billets un peu trop ambitieux qui trainent à l'état de brouillon, donc pour donner une illusion d'activité, je vais donner rapidement les problèmes que j'ai pu croiser en utilisant quotidiennement depuis mal de temps ASP.NET.

Non je ne vais pas parler de moi mais de moa. Gni? MOA veut donc dire maîtrise d'ouvrage, terme assez connu normalement dans la bâtiment, mais qui a également fait son chemin dans le milieu informatique (faut dire qu'on le pille pas mal le vocabulaire du bâtiment).
Théoriquement donc, la MOA désigne le client, celui donc qui nous commande une magnifique application pour répondre à son besoin. Par extension, on parle de maîtrise d'oeuvre(MOE) pour celui qui va réaliser le projet. Cette relation n'implique pas nécessairement deux sociétés différentes. On trouve au sein d'une même entreprise et la maîtrise d'ouvrage, et la maîtrise d'oeuvre. Typiquement, le service informatique représente les maîtres d'oeuvre, et tous les services à côté qui expriment des besoins font office de maîtrise d'ouvrage (ie: service marketing, service client, achats etc etc).

Dans une société à la taille conséquente, il est évident que n'importe qui ne peut pas se pointer au service informatique et demander un développement. On se retrouverait à avoir des développements différents pour des besoins similaires; avec un nombre incroyable de micro projet à développer et maintenir; bref l'anarchie la plus complète.
Dans ce genre de situation, il apparait donc le besoin d'avoir un interlocuteur par service qui va centralier les demandes, et rédiger les expressions de besoin, puis les cahiers de charge en collaboration avec la maîtrise d'oeuvre. Cette nouvelle espèce de cadre s'appel donc les maîtres d'ouvrage.
Pour que la MOA et la MOE puissent communiquer et se comprendre, il faut bien évidemment avoir un langage commun clair et bien défini. La solution de facilité adoptée par la majorité des sociétés actuellement est de mettre à la MOA des gens provenant de l'informatique. Personnellement, je trouve que c'est un très mauvaise idée, et je vais tenter d'expliquer pourquoi.

- Premièrement, quelqu'un venant de l'informatique ne connait pas nécessairement aussi bien le métier que quelqu'un d'inculte en technique, mais ayant travaillé un certain temps dans le service concerné. On pourrait se retrouver donc plus facilement aves des oublis dans la définition des besoins.
- Deuxièmement, un informaticien à la MOA va nécessairement voir le métier avec ses oeillères d'informaticien. Il va faire en quelque sorte en amont le travail de la maîtrise d'oeuvre en préformattant ses analyses en fonction de ce qu'il connaît de la technique. Cette couche d'abstraction je trouve peut faire perdre du sens au métier avant même qu'il ait commencé à faire son chemin au sein du service informatique.
- Troisièmement, un maître d'ouvrage provenant de l'informatique, en cas de conflit d'intérêt entre la MOA et la MOE, va plus ou moins prendre le partie de la MOE (question d'affinités). Normalement, c'est tout de même le besoin du client qui est censé primer non?
- Quatrièmement, mettre un informaticien à la MOA c'est prendre le problème à l'envers. On cherche à définir un langage commun entre la MOA et la MOE; mais ce n'est pas au client de tenter de convertir son savoir en termes intelligibles pour l'informatique. Bien au contraire c'est au client d'imposer ses termes métiers, car ils sont riches de sens dans leur contexte; et ils ne doivent pas tenter des les appauvrir en les traduisants. C'est donc à l'informatique de comprendre tout le sens du langage métier, et de tenter ensuite de réprésenter la réalité de ce métier en le modélisant de la manière qui lui convient (par exemple à travert des diagrammes UML).

Je me permet de souligner l'importance de cette notion de langage commun. Eric Evans parle justement d'"Ubiquitous language" dans son livre "Domain driven design" (traductible par "langage omniprésent"). Ce langage omniprésent doit être la clef de voute de la communication MOE/MOA; et c'est clairement la MOA qui l'impose, et à l'informatique de bien vérifier que chaques termes est clairement défini et compris. Par exemple, dans le cadre de mon travail dans le milieu pharmaceutique; quand on me parle de "libération d'un médicament", à première vue ça ne me parle pas du tout, donc il faut bien que je demande la définition; et si cette notion est importante, alors il faut qu'elle apparaisse quelque part dans mon design. Ainsi mon code et mon design même se retrouve noyauté par des termes riches de sens provenant du domaine.
La définition de ce langage commun provenant des experts du domaine doit clairement venir en toute première partie d'un projet pour éviter toute ambiguité future.

Je terminerai par une petite anecdote. J'ai travaillé avec un certain de nombre de MOA au cours de ma jeune carrière; et les meilleurs bizarement ne venaient jamais de la technique, mais toujours du métier... Je vous laisse méditer.


PS: Merci à la personne qui m'a inspirée ce billet. Elle se reconnaîtra

Pour différentes raisons, pour le projet en cours j'ai du écrire la mapping à la main plutôt que d'utiliser une solution comme nhibernate.
Au final, la dll contenant mon domaine pèse 100ko, et la dll contenant le mapping quant à elle pèse 800ko. 8 fois plus de code donc nécessaire pour faire persister un domaine. Je dois dire que j'écris ce message à la manière d'une dépêche AFP car finalement, je ne sais pas trop comment commenter ce ratio si ce n'est en disant "ah ouais, quand même".

PS: ceci n'est pas une remise en question de l'approche par domaine, mais juste un constat assez amusant que je voulais partager avec un très hypothétique lecteur... qui d'ailleurs ne peut même pas répondre car j'ai coupé les commentaires et les trackbacks pour stoper l'hémoragie des spams qui pourrissaient ce blog.

Vous en avez marre d'écrire vos fichiers de mapping nhibernate à la main?

tout le monde en parle depuis des années, mais mon maigre constat est que finalement, dans le monde de l'entreprise, le combat est loin d'être gagné.