Nous ne le répéterons jamais assez : la mauvaise gestion de la dette technique aboutit inexorablement à des ralentissements dans les rythmes de livraison. Dans le pire des cas, une équipe peut se retrouver dans une situation où elle ne livre plus grand chose de nouveau. Que faire pour remédier à ce problème : doit-on reconstruire entièrement le logiciel de zéro (greenfield) ou bien conserver l’existant en l’améliorant (brownfield). Le développement greenfield et brownfield sont deux approches radicalement différentes lorsqu’il est question de maintenir ou faire évoluer un logiciel. La question greenfield ou brownfield est aussi vieille que le développement logiciel. Alors, laquelle de ces deux approches est la plus pertinente ?
Les pièges du greenfield
Lorsque vous êtes englué dans la maintenance d’un logiciel qui est devenu trop complexe, vous pouvez être tenté de vous dire que vous allez jeter tout ce code legacy pour repartir sur une base propre et saine. Cette approche peut sembler en effet bénéfique car elle sera également l’occasion d’utiliser facilement les dernières technologies ou une nouvelle architecture logicielle ainsi que de supprimer des éléments inutiles car caduques.
L’histoire se répète
Le problème c’est que nous oublions trop souvent que les mêmes causes produiront les mêmes conséquences. Comment êtes-vous sûre qu’au bout de quelques semaines ou quelques mois vous n’aboutirez pas au même résultat ; c’est-à-dire à de la nouvelle dette technique ? Il s’agit d’un danger potentiel enseigné par la loi de Conway : “les organisations qui conçoivent des systèmes […] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation”. Oui, une organisation – même apprenante – qui a produit de la dette technique incontrôlable risque d’en reproduire à nouveau. Le problème n’est pas ici lié à la technologie utilisée.
La complexité cachée
Les logiciels legacy sont souvent peu voire pas documentés. La dette technique va malheureusement souvent de pair avec la dette documentaire. De plus, le turnover naturel dans une entreprise aboutit à une perte des sachants. “En se lançant dans une refonte orientée greenfield, l’équipe va souvent devoir réaliser du reverse engineering qui sera coûteux. Le risque ici est de passer à côté d’une partie des règles métiers dans votre refonte. Vous livrerez alors un logiciel partiellement fonctionnel” nous explique Marc Vincent, Head Of Technology & Cloud chez Daveo.
Les vertues du brownfield
La deuxième option qui s’offre à vous lorsque vous souhaitez moderniser votre code legacy dans le développement de votre logiciel par exemple est de faire évoluer votre logiciel existant.
La maîtrise du risque
L’énorme avantage d’une approche brownfield dans le développement de votre logiciel est que vous travaillez sur un terrain connu. Votre logiciel est – à priori – fonctionnel ou à défaut vous en connaissez la liste de bugs. Vous aurez donc moins d’impact lors des changements que vous réaliserez. Vous avancerez donc avec un certain harnais de sécurité dans le développement de votre logiciel informatique.
L’apprentissage
Le deuxième avantage est celui de l’apprentissage. Travailler sur un logiciel existant permet d’identifier plus clairement les améliorations à apporter. Les contraintes existantes vous aideront également parfois à trouver des solutions qui vous permettront d’améliorer vos compétences d’architecture et de développement.
Dans la pratique, des méthodes comme le Branch by abstraction, vous permettront de réaliser des changements qui seront parfois longs à mettre en œuvre. De plus, l’avènement des architectures microservices vous aidera à refactorer plus facilement vos logiciels informatiques existants.
“Dans les premières années de ma carrière j’étais convaincu que l’approche greenfield était la plus pertinente tant certains codes legacy me semblaient coûteux et complexe à maintenir. Avec le recul, je pense que c’était certainement dû à une impression de plus grande facilité offerte par l’approche greenfield (ce qui n’était en réalité pas le cas). Je pense qu’il serait bien plus formateur et donc bénéfique de moderniser un logiciel existant. Cette approche paraît la moins risquée. Je suis conscient que l’approche brownfield n’est certes pas très séduisante et motivante pour bon nombre de développeurs mais c’est définitivement celle qui vous fera le plus progresser. Bien entendu, cette réponse ne saurait être dogmatique. Parfois, nous n’avons tout simplement pas le choix, par exemple dans le cas d’une montée de version d’un élément technique qui n’offre pas une gestion de la rétro-compatibilité ascendante” conclu Marc Vincent, Head of Technology & Cloud et rédacteur de cet article.
