blog.bressure.net

La division du travail en informatique en 2 parties distinctes qui séparent la technique du fonctionnel semble relever d’une approche simpliste. En effet l’organisation des projets informatiques fait apparaitre 2 forces aussi légitimes l’une que l’autre qui sont : les besoins fonctionnelles et les moyens techniques pour y parvenir. Ainsi on entend parler d’une part de Matrise de d’ouvrage (MOA) qui détient le savoir du quoi et d’autre part de Maitrise d’oeuvre (MOE) qui détient le savoir du comment. Cette conception tirée du domaine des projets du bâtiments propose ainsi de façon implicite une hiérarchisation des rôles. La MOA est ainsi le donneur d’ordre et la MOE l’executant. D’ailleurs on voit bien que les métiers de la MOA sont plus valorisés que ceux de la MOE.

Cette vision est hélas typiquement française. Chez nous de nombreux informaticiens en quête de reconnaissances (pécuniaires) se tournent vers la MOA et finissent par oublier les fondement de leur métier: la technique. La technique n’est pas péjorative sauf en France. La technique informatique met en Å“uvre des idées et de concepts très abstraits. Bien sûr je veux parler de l’informatique d’un niveau assez élevé, que ceux qui considère la technique comme un passe-temps d’ados bouteunneux ne connaissent pas. L’informatique sont en vérité des mathématique avec une application pratique. Redonnons ses lettres de noblesse à cette sciences !

Cependant les applications pratiques de l’informatique sont souvent d’un niveau scientifique assez faible voir inexistant notamment en informatique de gestion. Néanmoins les techniques récentes de génie logicielles offrent des champs d’investigation qui peuvent abreuver la soif de technicité de l’informaticien. Mais la encore la vision française de l’informatique mettra l’informaticien encore dans une position inférieure à celle du fonctionnel si bien que les prérogatives de la MOE ‘effaceront devant celles de la MOA. Par exemple si un programme fait ce qu’on attend de lui c’est-à-dire qu’il satisfait les utilisateurs, on ne se souciera pas de comment il est fait. N’est-ce pas ? C’est normal somme toute. Mais est-ce toujours le cas ?

Dans certains projets au forfait, la répartition des rôles jouent clairement en défaveur de la MOE. Le donneur d’ordre ayant acheté un logiciel final, le comment n’a que peu d’importance devant le quoi. Cependant des raisons de maintenance peuvent tempérer ce raisonnement.Ou bien des question de sécurité. Ainsi le but d’une compagnie aérienne est de transporter des personnes et la sécurité et la maintenance des appareils sont des postes budgétaires qui ne sont pas directement lié au métier qui sont pourtant placées comme priorité « numéro un » avant tout exercice réel. Il y a donc bien des cas où la technique passe avant le fonctionnel. Est-ce que les domaines sensibles comme le militaire ou la sécurité des personnes ou la santé sont les seuls où les techniciens (au sens noble) ne sont pas soumis au dictat du fonctionnel ?

Avant toute chose essayons de comprendre pourquoi il y a cette opposition entre technique et fonctionnel. Est-elle justifiée ? A mon sens cette opposition viens d’une incompréhension historique qui nous a fait passé de l’ère de l’informaticien dans sa tour d’ivoire à l’informaticien-technicien sans pouvoir. Dans les 2 cas nous avons une organisation inefficaces puisque dans le premier cas, le logiciel ne correspond pas au besoin et dans le second le logiciel ne sort pas en temps en heure avec des coûts de maintenances accrus puisque pauvre techniquement. Un analogie avec la compagnie aérienne illustre mon discours. La technique seule ne transporte personne et sans la technique les avions s’écrasent. Je prône donc une juste répartition des rôles sans hiérarchisation des pouvoirs. Le fonctionnel et tout aussi important que la technique et vice-versa.

Alors pourquoi le titre de ce billet met-il la technique avant le fonctionnel ? Il s’agit simplement résultat d’un constat empirique. Lorsque que vous devez faire 2 tâches, vous avez intéret à commencer par celle qui est ou parait la moins importante in-finé parce si vous commencez par celle qui constituent le but final vous ne reviendrez jamais sur l’autre. Les développeurs vous diront tous: les rustines que l’on met dans le code pour contourner un problème ne sont jamais enlevées du code final. Aussi je prône de toujours commencer par la moins prioritaire du point de vue fonctionnel mais qui est la plus prioritaire d’un point de vue technique. Rentrent dans cette catégorie toutes les tâches liés à l’infrastructure constituant l’échafaudage par lequel le logiciel va pouvoir être construit. Ainsi il faut toujours commencer par mettre en place les outils de builds, définir les processus de livraisons… Cela veut dire aussi avoir le courage de repousser les livraisons fonctionnelles quand la qualité technique n’est pas au rendez-vous dès le début.

Ces principes sont bien connus des tenants de méthodes telles que le développement guidé par les tests gagnent à être connus et pratiqués réellement.