Développer un logiciel, ce n’est pas construire un bâtiment

Photo d’All Bong

« Release early. Release often. […] » (Eric S. Raymond)

La première fois que j’ai assisté à une réunion concernant un projet informatique dans l’administration, j’ai cru que je m’étais trompé de salle. Tout le monde parlait d’AMOA (assistance à maîtrise d’ouvrage), de MOE (maîtrise d’œuvre) et de CCTP (cahier des clauses techniques particulières)… Moi qui avait justement bifurqué du génie civil vers la data science, le destin m’avait rattrapé.

Pour construire un bâtiment, les architectes et les ingénieurs conçoivent des plans détaillant précisément ce qui doit être ensuite réalisé par les ouvriers. Il y a toujours des imprévus, mais globalement tout bien rodé et les bâtiments finissent par être construits, pour des siècles et des siècles.

Malheureusement, cette méthode a été calquée pour le développement des logiciels, notamment dans les grandes organisations, alors qu’il existe quand même de sacrées différences entre une tour de bureau et un site web :

1/ Le coût du changement. Si quelqu’un se rend compte qu’il n’y a pas de toilettes dans les étages 12 à 25 une fois votre immeuble fini, vous avez un gros problème. À l’inverse, le coût nécessaire pour modifier une fonctionnalité d’un logiciel est plutôt faible s’il a été conçu de manière suffisamment modulaire. De plus, il est possible de commencer petit et de faire grossir le projet ensuite, alors que si le constructeur de votre maison neuve vous explique qu’il n’y a que les chambres, mais rassurez-vous, la salle de bain arrivera dans trois mois, vous avez encore une fois un gros problème.

2/ La séparation des rôles. Dans le bâtiment, les ingénieurs prennent les décisions et les ouvriers réalisent les travaux. Dans le logiciel, ce sont les ingénieurs qui ont les mains dans le cambouis numérique, ce sont eux qui construisent. Séparer les rôles et ne considérer les équipes techniques que comme des petites mains est un gâchis énorme. Mieux vaut donc intégrer tout le monde lors des moments de conception des produits numériques.

3/ L’effet levier. Pour construire dix bâtiments, il faut environ dix fois plus d’employés que pour construire un bâtiment. Dans le numérique cependant, il est possible de construire une application utilisée par des millions de personnes avec une dizaine de personnes. L’équipe d’Instagram comptait par exemple treize salariés au moment du rachat de l’entreprise par Facebook en 2012, et leur application avait été téléchargée plus de vingt millions de fois.

4/ La tenue dans le temps. Les cathédrales sont construites en pierre et non en bois car elles sont prévues pour durer (il y a aussi une question de résistance des matériaux, mais vous comprenez l’idée). Côté informatique, les langages de programmation, le matériel, les besoins et même les goûts des utilisateurs changent tellement souvent qu’il est illusoire de penser qu’un produit numérique peut continuer à rendre service durant des décennies sans intervention. Il faut donc voir ces produits comme des éléments vivants, évoluants sans cesse pour s’adapter aux changements constants.

Développer un logiciel s’apparente plus à bricoler dans un bazar qu’à construire une cathédrale. Il serait donc peut-être temps de faire évoluer notre vocabulaire, afin de transformer aussi petit à petit notre culture.