MOE et MOA sont dans un bateau
Par Olivier Azeau le 8 mars 2007, 00:57 - En français - Lien permanent
Un excellent billet de Claude Aubry sur les notions de "Maîtrise d'ouvrage" et "Maîtrise d'oeuvre" dans un monde agile me donne l'occasion de parler d'un syndrome assez fréquent dans le monde du développement logiciel : celui de l'emprunt abusif à d'autres disciplines.
Wikipédia l'explique très bien : MOA et MOE sont des termes empruntés au secteur des Travaux publics.
Alors, pourquoi ont-ils débarqués dans le logiciel ?
Wikipédia l'explique très bien : MOA et MOE sont des termes empruntés au secteur des Travaux publics.
Alors, pourquoi ont-ils débarqués dans le logiciel ?
Je n'ai pas la réponse historique à cette question mais j'ai quand même quelques intuitions. Ces termes sont donc issus du vocabulaire de l'administration française qui dans la lignée des grands chantiers publics d'urbanisme dont elle est coutumière, a adopté ces termes pour ses chantiers informatiques (dont on connait certains fleurons).
On peut comprendre que notre administration, de par la complexité de son fonctionnement ait eu besoin de clarifier avec précision les attributions des intervenants. On comprend plus difficilement pourquoi ces termes (et les rôles qui en découlent), issus des marchés publics de BTP, se sont retrouvés dans le fonctionnement interne de nombre d'entreprises privées.
Y-a-t-il une similitude entre l'organisation d'un projet de travaux publics et celle d'un projet de développement logiciel ? A priori, ce sont 2 mondes bien distincts.
Pour l'un, on se trouve face à des contraintes physiques incontournables lorsqu'il s'agit de couler du béton ou de monter des murs. Des plans relativement précis sont nécessaires pour calculer à l'avance la faisabilité de l'ensemble : on ne peut pas toujours se permettre d'attendre que l'édifice se construise pour tester sa solidité. D'ailleurs ce secteur emploie un volume non négligeable de main d'oeuvre faiblement qualifiée qui nécessite la mise en oeuvre de directives détaillées.
De l'autre côté, on a le monde du virtuel dans toute sa splendeur. Celui où les échafaudages se montent et se démontent continuellement. Celui où l'édifice produit tient sur quelques millimètres et se duplique à l'infini en moins de temps qu'il n'en faut pour le dire mais qui nécessite souvent des mois pour apprivoiser son fonctionnement. Celui où la main d'oeuvre était jadis très hiérarchisée mais où, de nos jours, le même personne change plusieurs fois de casquette dans la même journée en étant tour à tour architecte, contremaitre, maçon et contrôleur technique.
Et pourtant il faut croire que l'on trouve des gens qui pensent que les points communs justifient amplement la même organisation du travail.
La réalité, c'est que le seul point commun que l'on puisse trouver est qu'il y a, dans les deux cas, deux parties en présence : une qui demande la réalisation d'un produit dont elle a besoin et l'autre qui va réaliser le produit en question. Cela ne justifie pas pour autant un fonctionnement identique. Il arrive à toute personne qui va chez le coiffeur de ne pas être complètement satisfaite de la coupe de cheveux qu'elle a obtenue. Je n'ai pourtant jamais vu personne débarquer dans un salon de coiffure en se présentant comme MOA, avec un cahier des charges sous le bras et demandant une spec détaillée avant le début des travaux...
Plus je cherche et moins je trouve d'explication rationelle à ce phénomène. C'est un peu comme si les gens voulaient se rassurer en se disant que la réussite d'une organisation dans un contexte donné est une garantie de succès. Ils occultent complètement le fait que sur l'aspect fonctionnel, celui qui importe le plus à la MOA, un batiment peut être entièrement décrit dans un temps raisonnable sous forme de plans et que le reste, le boulot de la MOE n'est que de la technique. Cette technique demande des connaissances et un savoir faire qui est loin d'être négligeable mais, et c'est la le point clef, qui n'a que peu d'impact sur les aspects fonctionnels du produit fini.Une exigence qui dit que la température à l'intérieur d'un batiment doit rester dans une plage donnée quelle que soit la température extérieure est facilement vérifiable sans ambiguïté à l'aide d'un thermomètre. Le choix des isolants qui vont remplir cette exigence est un travail d'ingénierie qui peut être ou ne pas être simple en fonction de la plage souhaitée mais la décision qui en découle n'affecte les aspects fonctionnels qu'à la marge.
Dans le logiciel, on est exactement dans la situation inverse : la combinatoire fonctionnelle des logiciels, même parmi les plus simples, fait qu'il n'est jamais possible de décrire entièrement leur fonctionnement complet (au sens tous les états possibles) en langage humain. Il est donc tout aussi difficile de valider avec certitude que ce qui a été réalisé correspond à un souhait dont on n'a qu'une description partielle. En regard de cela, la partie technique est presque du gateau. Certes, un savoir faire technique est toujours nécessaire pour écrire sans erreur un code compréhensible par une machine mais les outils d'aujourd'hui font que les développeurs de logiciel passent bien plus de temps à être sûr qu'ils fabriquent le logiciel correspondant au besoin réel qu'ils n'en passent à toute autre activité.
L'erreur la plus grossière que l'on rencontre encore trop souvent est de faire le parallèle :
d'une part entre les plans d'une maison et la documentation de conception d'un logiciel ;
d'autre part entre la construction de la maison proprement dite et le codage du logiciel.
Le parallèle correct est que les plans de la maison, ce qui permet d'avoir une vision fonctionnelle non ambigüe du produit, c'est le logiciel lui-même et construire la maison correspondante, c'est compiler une dernière fois le code source avant de graver le CD.
Quand on a compris cela, on peut faire de la MOA/MOE en logiciel.
On peut comprendre que notre administration, de par la complexité de son fonctionnement ait eu besoin de clarifier avec précision les attributions des intervenants. On comprend plus difficilement pourquoi ces termes (et les rôles qui en découlent), issus des marchés publics de BTP, se sont retrouvés dans le fonctionnement interne de nombre d'entreprises privées.
Y-a-t-il une similitude entre l'organisation d'un projet de travaux publics et celle d'un projet de développement logiciel ? A priori, ce sont 2 mondes bien distincts.
Pour l'un, on se trouve face à des contraintes physiques incontournables lorsqu'il s'agit de couler du béton ou de monter des murs. Des plans relativement précis sont nécessaires pour calculer à l'avance la faisabilité de l'ensemble : on ne peut pas toujours se permettre d'attendre que l'édifice se construise pour tester sa solidité. D'ailleurs ce secteur emploie un volume non négligeable de main d'oeuvre faiblement qualifiée qui nécessite la mise en oeuvre de directives détaillées.
De l'autre côté, on a le monde du virtuel dans toute sa splendeur. Celui où les échafaudages se montent et se démontent continuellement. Celui où l'édifice produit tient sur quelques millimètres et se duplique à l'infini en moins de temps qu'il n'en faut pour le dire mais qui nécessite souvent des mois pour apprivoiser son fonctionnement. Celui où la main d'oeuvre était jadis très hiérarchisée mais où, de nos jours, le même personne change plusieurs fois de casquette dans la même journée en étant tour à tour architecte, contremaitre, maçon et contrôleur technique.
Et pourtant il faut croire que l'on trouve des gens qui pensent que les points communs justifient amplement la même organisation du travail.
La réalité, c'est que le seul point commun que l'on puisse trouver est qu'il y a, dans les deux cas, deux parties en présence : une qui demande la réalisation d'un produit dont elle a besoin et l'autre qui va réaliser le produit en question. Cela ne justifie pas pour autant un fonctionnement identique. Il arrive à toute personne qui va chez le coiffeur de ne pas être complètement satisfaite de la coupe de cheveux qu'elle a obtenue. Je n'ai pourtant jamais vu personne débarquer dans un salon de coiffure en se présentant comme MOA, avec un cahier des charges sous le bras et demandant une spec détaillée avant le début des travaux...
Plus je cherche et moins je trouve d'explication rationelle à ce phénomène. C'est un peu comme si les gens voulaient se rassurer en se disant que la réussite d'une organisation dans un contexte donné est une garantie de succès. Ils occultent complètement le fait que sur l'aspect fonctionnel, celui qui importe le plus à la MOA, un batiment peut être entièrement décrit dans un temps raisonnable sous forme de plans et que le reste, le boulot de la MOE n'est que de la technique. Cette technique demande des connaissances et un savoir faire qui est loin d'être négligeable mais, et c'est la le point clef, qui n'a que peu d'impact sur les aspects fonctionnels du produit fini.Une exigence qui dit que la température à l'intérieur d'un batiment doit rester dans une plage donnée quelle que soit la température extérieure est facilement vérifiable sans ambiguïté à l'aide d'un thermomètre. Le choix des isolants qui vont remplir cette exigence est un travail d'ingénierie qui peut être ou ne pas être simple en fonction de la plage souhaitée mais la décision qui en découle n'affecte les aspects fonctionnels qu'à la marge.
Dans le logiciel, on est exactement dans la situation inverse : la combinatoire fonctionnelle des logiciels, même parmi les plus simples, fait qu'il n'est jamais possible de décrire entièrement leur fonctionnement complet (au sens tous les états possibles) en langage humain. Il est donc tout aussi difficile de valider avec certitude que ce qui a été réalisé correspond à un souhait dont on n'a qu'une description partielle. En regard de cela, la partie technique est presque du gateau. Certes, un savoir faire technique est toujours nécessaire pour écrire sans erreur un code compréhensible par une machine mais les outils d'aujourd'hui font que les développeurs de logiciel passent bien plus de temps à être sûr qu'ils fabriquent le logiciel correspondant au besoin réel qu'ils n'en passent à toute autre activité.
L'erreur la plus grossière que l'on rencontre encore trop souvent est de faire le parallèle :
d'une part entre les plans d'une maison et la documentation de conception d'un logiciel ;
d'autre part entre la construction de la maison proprement dite et le codage du logiciel.
Le parallèle correct est que les plans de la maison, ce qui permet d'avoir une vision fonctionnelle non ambigüe du produit, c'est le logiciel lui-même et construire la maison correspondante, c'est compiler une dernière fois le code source avant de graver le CD.
Quand on a compris cela, on peut faire de la MOA/MOE en logiciel.
Commentaires
Le système de production de Toyota, qui est en passe de devenir le 1er constructeur mondial de voitures, est quand même une des racines principales du mouvement des méthodes agiles dans le logiciel...
http://fr.wikipedia.org/wik...
Bonjour,
Votre article n'est pas faux dans l'ambiguïté qu'il détecte dans l'utilisation des termes MOA et MOE entre un chantier de BTP et un chantier informatique.
Pourtant, si le béton nécessite un plus grand soucis de conception détaillé et d'organisation, c'est que les engagements diffèrent. Cela dit, la croissance des projets informatiques, l'escalade des budgets requis et la multiplication de prestataires spécialisés intervenant sur un même projet nécessite une organisation de même nature.
Mais je ne comprends pas en quoi l'informatique devrait se garder d'utiliser les expressions et les définitions de maîtres d'ouvrage et de maîtres d'oeuvre. Car au fond, et vous le dites trés bien, c'est de cela dont il s'agit ;
De la relation entre celui qui conçoit des services à partir de l'analyse des besoins et qui est responsable de la bonne fin des travaux (entre autre puisqu'il y a aussi la gestion des différentes parties tiers du client), et de celui qui va réaliser en concevant techniquement et en développant ou en mettant en place les outils nécessaires.
Cela ne nuit en aucun cas aux méthodes agiles, d'avoir un cahier des charges extrèmement précis, voir trés poussé techniquement et d'un autre côté des spécifications techniques intelligibles qui peuvent être validées.
Pour avoir gérer la réalisation de logiciels "on line" en l'occurence sans compilation, je ne crois pas moi que les plans de la maison soit le logiciel terminé. Car s'il s'agissait de cela alors je pourrais reconstruire cent fois par projet le même logiciel sous l'influence du client comme du prestataire ou des équipes techniques. Cela économiquement n'est pas acceptable.
Ce n'est pas une perte de temps que de faire des plans car à la différence du BTP, quand nos plans sont faits, il nous reste la capacité de les faire évoluer, de les "upgrader". Il est nécessaire qu'un "arbitre" puisse définir le sens de l'évolution pour que ce ne soit pas n'importe comment, pas à n'importe quel coût et surtout pas pour intégrer toutes les nouvelles idées glanées ici ou là au fil de l'expérience ou de la mode technologique.
L'agilité sans rentrer dans un débat de méthodes, c'est d'avoir la capacité de se remettre en question tout au long d'un projet, notamment en laissant évoluer les idées à mesure du développement et d'écouter aussi les retours de l'Utilisateur (le client dans ses différentes composantes).
Le rôle d'un MOA et notamment quand il s'agit d'un consultant externe à l'organsisation cliente (là je prêche pour ma paroisse), c'est pour moi, justement, de favoriser la souplesse en conservant la volonté du cadre défini. En somme, une main de fer dans un gant de velour, côté client, comme côté réalisateur.
NETtement votre.