Technologies

Comprendre et maîtriser la dette technique logicielle

Le développement trop rapide du code crée différents types de dettes techniques que les organisations ne doivent pas négliger. (Photo : G.Altmann/Pixabay)

La course à la réalisation dans l'urgence de certains développements logiciels risque de laisser, demain, un lourd fardeau aux équipes informatiques. Voici un aperçu des différentes causes, différents types, des risques, mais aussi des avantages de la dette technique, et des stratégies pour la maîtriser.

PublicitéLa dette technique logicielle est le coût accumulé au fil du temps en raison de décisions de mise en oeuvre technologique qui privilégient la rapidité au détriment de la qualité et de la maintenance à long terme. Elle repose sur l'idée qu'en prenant des raccourcis pour accélérer l'écriture du code ou la mise en place de l'infrastructure, on s'expose à un surcroît de travail en matière de maintenance, de sécurité ou de gestion pour l'avenir. Par exemple, si le code d'une application rapidement mise en production est alambiqué et difficile à mettre à jour et à entretenir, le temps ou les ressources économisés au moment de l'écriture seront payés plus tard en frustration et en travail supplémentaire.

C'est Ward Cunningham, développeur, inventeur du wiki et un des auteurs du Manifeste agile, qui a formalisé l'idée de dette technique. Il l'a exposée succinctement lors de la conférence Oopsla (object-oriented programming, systems, languages and applications) de Vancouver (Canada) en 1992 : « Livrer un code pour la première fois, c'est comme s'endetter. Bien qu'un certain niveau de dette puisse accélérer le développement, il est crucial de la rembourser rapidement en restructurant le code. C'est lorsque la dette n'est pas remboursée que le danger survient. Chaque minute passée sur du code qui n'est pas tout à fait adapté à la tâche demandée s'apparente à l'application d'intérêts sur cette dette. Des équipes entières d'ingénierie peuvent se retrouver paralysées par la dette liée à l'implémentation d'un code qui n'a pas été retravaillé ».

Le parallèle avec un prêt bancaire

La dette technique est souvent considérée de la même façon qu'un outil financier sans lequel on ne pourrait pas réaliser quelque chose aujourd'hui. Comme un prêt aidera un acheteur à tirer parti d'une opportunité immobilière sans disposer de la totalité du prix demandé au moment de l'achat, une entreprise peut rester en phase avec ses concurrents et saisir des opportunités de marché en lançant un produit logiciel ou un service web avant que le code n'ait été perfectionné en vue d'une maintenance à long terme.

Mais, d'un autre côté, accepter une dette technique de cette manière vous impose des charges que vous devrez gérer pendant des années, ce qui risque de paralyser l'innovation IT. Tout comme le remboursement d'un prêt sur 30 ans signifie que vous avez payé beaucoup plus que le prix de vente de votre maison - du fait des intérêts -, le déploiement précipité d'un produit logiciel pour être parmi les « premiers arrivés » peut engendrer plus tard de nombreux jours-homme consommés au sein de vos équipes de développement, d'assurance qualité et de service client.

Trouver le bon compromis

Dans l'absolu, une dette financière n'est ni bonne ni mauvaise, et il existe des principes, tels que la valeur temporelle de l'argent, qui aident à déterminer si la souscription d'un prêt spécifique est une bonne idée ou non. De la même façon, le concept de dette technique permet de réfléchir (et même de quantifier) les compromis nécessaires pour le développement de logiciels sous la pression des marchés dans le monde réel.

PublicitéEt, pour continuer de filer la métaphore, il existe différentes façons de traiter une dette technique, tout comme il existe différentes façons de s'occuper de ses dettes financières. Vous pouvez effectuer de petits paiements réguliers gérables à court terme, mais qui finissent par coûter cher au fil du temps, ou vous pouvez rassembler les ressources nécessaires pour rembourser la totalité ou la majeure partie de la dette en une seule fois. Dans le cas d'une dette technique, cela peut signifier accepter un travail quotidien afin de la réduire couplé à la perte d'efficacité liée à l'utilisation d'un code de mauvaise qualité ; élaborer un plan effectif de réduction de la dette ; réécrire le code et résoudre les problèmes au fil du temps ; ou encore, supprimer complètement le code initial et le remplacer par une version entièrement remaniée.

Par ailleurs, le fait que l'expression "dette technique" ait été créée par l'un des inventeurs de la gestion de projet agile n'est pas une coïncidence. Les méthodes de travail agile sont souvent conçues pour la prendre en compte et encourager les équipes à prévoir des périodes régulières dans leur emploi du temps pour réviser le code existant. Cela fait partie de la philosophie d'amélioration continue de ces méthodologies.

Quatre façons de gérer la dette logicielle

En 2009, un essai publié par Martin Fowler détaille une façon d'envisager les différents types de dette technique. Le développeur et auteur a popularisé le concept de remaniement du code qui revient à traiter une grande partie de la dette technique logicielle. Son essai propose deux axes différents pour catégoriser celle-ci. Le premier consiste à opposer ce qui est planifié et ce qui ne l'est pas, le second, à choisir entre témérité et prudence. Une gestion prudente de la dette technique consiste à la prendre en compte dès qu'elle est contractée ou évaluée ultérieurement dans le cadre d'une stratégie spécifique, tandis qu'une gestion téméraire consiste à la laisser s'accumuler sans trop y penser. Les deux axes combinés créent un tableau comportant 4 approches de la gestion de la dette.

- La gestion planifiée, mais téméraire : « nous savons que nous prenons beaucoup de raccourcis, mais nous n'avons pas le temps d'y penser ou de nous en préoccuper - passons tout simplement la ligne d'arrivée ! »

- La gestion planifiée et prudente : « nous avons évalué les risques de cette conception avant de la mettre en oeuvre. Nous connaissons les conséquences auxquelles nous devrons faire face et nous avons un plan pour y remédier ». C'est le moyen de lancer rapidement un produit minimum viable (MVP) et d'anticiper un remaniement ultérieur du code, une fois que la solution aura gagné des utilisateurs et des parts de marché.

- La gestion non planifiée et téméraire : « bous avons une équipe de superstars et tout le processus va probablement bien se passer ! » Ce n'est en général pas le cas.

- La gestion planifiée, mais prudente : « nous avons découvert quelques problèmes liés à notre processus de développement initial, mais nous les suivons de près, nous apprenons de nos erreurs et nous avons un plan pour y remédier ».

Cinq sources de dette technique logicielle

La dette technique vient de nombreux domaines de l'infrastructure technique, et pas uniquement du logiciel. Un précédent article publié ici décrivait ainsi 7 formes de dette technologique qui freinent la transformation des entreprises dont la dette de données, la dépendance à l'égard de l'Open Source ou la dette d'architecture. Mais avec la dette technique logicielle, le diable se cache dans les détails. Voici 5 facteurs spécifiques qui conduisent à contracter de la dette technique :

- La course aux délais : les contraintes de temps obligent souvent les équipes à prendre des raccourcis, qui conduisent à un code de mauvaise qualité, qui doit être retraité ultérieurement. Dans ce cas, l'équipe technique doit hiérarchiser les tâches de manière efficace et suivre les travaux reportés pour s'assurer qu'ils seront effectivement réalisés.

- Des exigences trop floues : lorsque les objectifs sont vagues ou mal définis, les équipes peuvent produire un code qui ne correspond pas vraiment aux besoins. Le travail effectué en amont pour définir des exigences claires peut s'avérer payant par la suite grâce à un code plus propre.

- Du code mal écrit : une des principales sources de dette technologique vient d'un code mal écrit qui rend le développement futur et la refonte lents et inefficaces ; un code bien structuré, en revanche, est plus facile à maintenir et à intégrer avec de nouvelles fonctions.

- Une documentation inadéquate : s'il est mal documenté, un code, même bien écrit, coûtera à votre équipe de développeurs et à leurs successeurs du temps et des efforts inutiles. La mise en place d'une documentation solide dès le départ prend du temps, mais elle permettra en fin de compte de réduire les efforts ultérieurs.

- L'inévitable évolution des besoins : même les bases de code bien conçues nécessitent une maintenance continue en raison de l'évolution des besoins de l'entreprise, des menaces de sécurité ou de l'obsolescence des technologies. Le code peut « dériver » en raison de dépendances avec d'autres lots applicatifs ou de modifications mineures qui ont des conséquences inattendues. D'une certaine manière, il s'agit de la cause la plus insidieuse de la dette technique, et il convient de s'en prémunir.

Mesurer et gérer la dette

Dans le cas d'une dette financière, il est possible de quantifier la somme d'argent que l'on doit. En revanche, il est très difficile pour une organisation de déterminer le niveau exact de sa dette technique. Certains experts suggèrent, par exemple, de mesurer le travail non planifié de l'équipe de développement, qui serait un équivalent acceptable d'une mesure du temps passé à nettoyer la dette technique dont elle a hérité.

Même si vous ne pouvez pas chiffrer votre dette, vous devez tout de même la maîtriser. Andrew Sharp, directeur de recherche à l'Info-Tech Research Group, société d'analyse de la performance des services IT, conseille aux responsables informatiques de documenter leur dette technique la plus critique, de comprendre son impact sur l'entreprise et d'établir un processus clair pour la résoudre. Comprendre sa dette technique est déjà une première étape dans sa gestion. Il faut lui donner la priorité dans les feuilles de route, la considérer comme un risque métier et s'assurer que, lorsque l'on contracte une nouvelle dette, elle entre dans la catégorie dette « planifiée et prudente ».

Trois façons de convaincre les dirigeants de l'importance du sujet

Malheureusement, il peut être difficile de convaincre la direction de l'organisation d'investir les ressources et le personnel nécessaires pour traiter correctement la dette technique, car ce n'est pas un sujet « sexy ». La réduction de la dette technique ne contribue pas de manière directe au chiffre d'affaires et, en fin de compte, elle ne s'accompagne que rarement du déploiement de nouvelles solutions à mettre en avant. Il existe cependant des moyens de mieux « vendre » cette démarche aux dirigeants.

- Mieux vaut utiliser un vocabulaire business que technique. On parlera par exemple de « goulets d'étranglement pour les revenus » plutôt que de « systèmes Legacy ».

- Présenter la dette technique comme un risque business - un risque de manquer des opportunités futures à cause du temps perdu sur les problèmes actuels - constitue une autre façon de faire évoluer la conversation dans le bon sens.

- Associer la dette technique à des projets innovants, la placer au même niveau que d'autres priorités informatiques et même l'intégrer dans un plan stratégique à long terme qui en montre le retour sur investissement.

Vous ne pourrez jamais supprimer complètement votre dette technique. Mais avec la bonne approche, vous devriez être en mesure de la minimiser et de la gérer - et ainsi d'en contracter davantage lorsque cela se justifie d'un point de vue technique et que cela peut faire avancer vos objectifs organisationnels.