Dans un précédent article, j’évoquais les origine du concept de dette technique ainsi que les éléments qui la composent. Cette dette peut être de type très varié : applications présentant des recouvrements fonctionnels, logiciel obsolète (qui ne peut plus être mis à jour mais présente des failles de sécurité), ERP trop customisé (et donc trop lourd à maintenir et upgrader)… Dans ce deuxième volet, je vais traiter cette semaine de l’interprétation faite de la dette technique et de ses limites.
La dette technique, une « autorisation » de mal coder ?
De nombreuses interprétations de ce que recouvrait la dette technique ont été faites depuis sa conceptualisation. La grande majorité d’entre elles considèrent qu’il s’agit d’une « autorisation » à produire initialement du code de qualité moindre. Cette facilité a généralement pour objectif d’accélérer la livraison applicative. L’amélioration de l’écriture de ce code est alors repoussée, parfois à de nombreuses reprises et même à jamais.
Cunningham lui-même est revenu en 2009 sur ces interprétations erronées de sa pensée. Pour lui, il ne s’agit pas de ré-usiner des lignes de code une fois que du temps se dégage. Il s’agit plutôt de tirer parti de l’expérience acquise grâce à l’utilisation de l’application en production. Cette précieuse connaissance permet d’apporter à l’application des améliorations pragmatiques et adaptées. En effet, si le cycle de vie applicatif ne propose que l’ajout de nouvelles fonctionnalités (éventuellement « sous-codées »…) mais aucune amélioration de l’existant, on ne fera que rajouter de l’entropie au SI.
Ainsi, pour Cunningham, une dette technique est contractée par les équipes de développement en plein accord avec les parties prenantes non-techniques. Les développeurs acceptent de livrer des programmes ne reflétant que leur connaissance fonctionnelle du moment, et ceci afin d’accélérer la mise en production. Ils devront en retour remanier le programme lorsqu’ils en sauront plus : interaction avec l’environnement applicatif, fonctionnalités utilisées le plus ou ignorées, fonctionnalités manquantes. La possibilité de se désendetter facilement dépendra alors du fait de disposer d’un code assez propre pour pouvoir être ré-usiné sans difficulté … On le voit, il ne s’agit pas du tout ici d’une autorisation de produire du code sale !
Dette prudente et dette imprudente
Dans son célèbre quadrant, Martin Fawler introduit la notion supplémentaire de dette « prudente » et de dette « imprudente » : il ne s’agit pas de contracter ou pas une dette, il s’agit de le faire de manière calculée et réfléchie. Il rajoute une dimension supplémentaire, celle de la dette « volontaire » et de son pendant la dette « involontaire ». Une dette prudente et volontaire permettra de livrer dans les temps du code imparfait mais (facilement) améliorable. Inversement, une dette imprudente et involontaire pourrait jeter le doute sur les compétences des équipes de développement !
« TechnicalDebtQuadrant » selon Martin Fawler
La dette technique prudente et volontaire est d’ailleurs au centre des recommandations d’Eric Ries (The Lean Start-up) et de la boucle de rétroaction « Build-Measure-Learn ». Il s’agit avant tout de construire rapidement quelque chose de correct. Ceci permet d’éprouver un concept avant de s’attacher à construire correctement quelque chose.
La dette technique ne doit donc pas être une fatalité, mais le résultat de décisions et d’arbitrages. Décisions et arbitrages qui d’ailleurs ne sont pas que techniques (malgré le nom de la dette…). S’articulent dans le processus de décision choix techniques, valeurs Métier apportées et dimension temporelle. Ce n’est plus non plus un sujet ne concernant que le code informatique ; ce concept est maintenant utilisé dans le cadre plus global des projets informatiques. Il désigne l’ensemble des éléments SI devant être améliorés ultérieurement (code, mais aussi architecture, documentation, couverture incorrecte de test (et non absence de tests), infrastructure, spécifications, …).
Le paysage de la dette technique. À gauche, l’évolution ou ses défis ; à droite, les problèmes de qualité, tant internes qu’externes (Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. Ieee software, 29(6), 18-21)
Limite de la métaphore
Malgré son intérêt illustratif, la métaphore de la dette technique montre plusieurs limites :
- Contrairement à une dette financière, la dette technique n’est pas quantifiable. Les équipes de développement ne disposent pas d’outils de mesure du capital ou des intérêts de cette dette. Les développeurs n’ont donc pas d’indication sur son montant ni sur la fin du remboursement.
- Le taux d’intérêt est inconnu et variable. Il généralement plus élevé si la dette s’applique sur du code sollicité fréquemment, et plus faible voire même inexistant si la dette concerne du code peu utilisé.
- A l’inverse de la dette financière, la dette technique s’éteint lorsque l’actif informatique disparaît. Les équipes de développement sont d’ailleurs moins enclines à rembourser la dette à l’approche de la fin d’utilisation de l’application/actif informatique.
- Parfois, les équipes de développement peuvent ne pas réaliser qu’elles ont contracté une dette technique. Elles ne le réalisent que si elles réalisent un examen rétrospectif de l’application. Une dette financière, elle, procède généralement d’une décision éclairée ou en tous cas directement visible.
La dette technique est ainsi un concept intéressant si on se limite à la métaphore. Il serait trop incertain de s’attacher à calquer finement le concept avec celui de la dette financière ! L’origine et les causes d’emballement de la dette technique sont d’autres éléments intéressants à considérer. Ces sujets seront traités dans un prochain article.
Laisser un commentaire