Tout projet informatique est jalonné de décisions permettant d’accélérer la mise à la disposition des fonctionnalités attendues par les utilisateurs. Parfois, ces décisions se transforment en compromis, qui eux-mêmes aboutissent à la mise en œuvre de solutions dégradées en matière de qualité et de couverture fonctionnelle. Les exigences et les urgences Métier sont généralement à l’origine de ces décisions. En résultent tout au long des versions successives du développement une charge (et un coût) du travail supplémentaires ; en effet, il est alors nécessaire de procéder au ré-usinage du code afin de minimiser sa complexité tout en répondant aux besoins spécifiés. Cette charge supplémentaire constitue la dette technique.
Dette technique ou pas dette technique ? Telle n’est pas la question (1/5)
La dette technique est inévitable et peut même être contractée à des fins tactiques ou stratégiques afin d’accélérer les livraisons. Il est toutefois indispensable qu’elle reste limitée et qu’elle soit apurée régulièrement. En effet, son accumulation peut la rendre extrêmement problématique car elle diminue la capacité des équipes de développement à fournir de la valeur Métier. Dans les cas extrêmes, la dette technique peut même paralyser les projets. Il est donc indispensable de la gérer pour en faire un allié plutôt qu’un ennemi.
Origine de la métaphore de dette technique
Ward Cunningham, créateur de concepts célèbres
La dette technique a été conçue initialement comme une métaphore. Ward Cunningham l’a utilisée afin d’expliquer les enjeux du « refactoring » ou « ré-usinage de code » à des parties prenantes non techniques. Cet enseignant, informaticien et consultant américain est surtout connu pour avoir inventé le concept de wiki (Wikipedia, ça vous dit quelque chose ?). Il a également formulé la « loi » qui porte son nom et selon laquelle « La meilleure façon de trouver la bonne réponse sur Internet n’est pas de poser la question, c’est de poster la mauvaise réponse » ! Il est donc aussi le père du concept de dette technique.
En effet, lors de la conférence annuelle en 1992 de l’OOPSLA (“Object-Oriented Programming, Systems, Languages & Applications”), Cunningham a rendu compte du développement d’un système de gestion de portefeuilles de liquidité. Ce système avait été développé par itérations successives à partir d’un prototype de travail. Lors de ces itérations successives, le code original avait été revu et réécrit de nombreuses fois, afin d’atteindre le niveau de qualité applicative nécessaire.
Cunningham souligna lors de son intervention qu’il est tout à fait possible de livrer du « code immature » qui fonctionnera de façon satisfaisante et répondra aux attentes utilisateur immédiates. Toutefois, ce code immature, en quantité excessive, risque de compromettre l’évolutivité et la maintenabilité des programmes.
« Bien que du code immature puisse fonctionner parfaitement et être tout à fait acceptable pour le client, en quantité excessive il rendra un programme ingérable, poussant à une spécialisation extrême des programmeurs et finalement à un produit rigide. Expédier du code pour la première fois revient à s’endetter. Une petite dette accélère le développement tant qu’elle est remboursée rapidement par une réécriture. (…) Le danger survient lorsque la dette n’est pas remboursée. Chaque minute passée sur un code pas tout à fait correct compte comme un intérêt sur cette dette. Des organisations entières d’ingénierie peuvent être paralysées sous la charge de la dette d’une implémentation non consolidée (…). »
− Ward Cunningham (1992), The WyCash Portfolio Management System
Dette technique, capital et intérêts
Ainsi, il était possible et légitime d’accélérer la livraison du code d’une application. Le périmètre et la couverture fonctionnels reflèteront alors la connaissance de la problématique (parfois partielle ou immature) qu’ont les développeurs à ce moment-là. Ceci peut s’apparenter à un endettement. La contraction d’un emprunt financier permet de réaliser plus rapidement un projet ; de même, l’acceptation d’un certain niveau d’endettement technique permet d’accélérer le développement d’une application. Cette mise en production permet également de « tester » l’application dans des conditions opérationnelles.
Le « capital emprunté » de la dette technique est constitué du coût ultérieur de remédiation du « code immature ». Les inefficacités générées par la contraction de la dette (mauvaise couverture fonctionnelle, effort de maintenance accru, ressources informatiques plus sollicitées, …), sont symbolisées par les « intérêts ». La dette technique constitue ainsi l’un des composants du coût de possession logiciel. Afin de réduire le poids de la dette (capital et intérêts), il est nécessaire de la « rembourser » le plus rapidement possible. Ceci pourra se faire par le biais d’une réécriture tirant parti de l’expérience accumulée lors l’exploitation opérationnelle de l’application.
Et oui, la dette peut être bénéfique
Il faut souligner que la dette technique n’est pas toujours préjudiciable. Elle ne l’est pas en particulier lorsqu’elle est contractée dans un but stratégique et qu’elle est bien gérée. Elle permet alors d’obtenir un avantage concurrentiel souvent décisif en accélérant la mise sur le marché. Le danger menace lorsque la dette n’est pas remboursée. Les intérêts dus qui croissent avec un remboursement trop tardif d’une dette financière mènent parfois à la faillite. De même, chaque minute passée avec du code non optimisé accroît les intérêts de la dette technique. Cet emballement peut même mener à la paralysie du système sous le poids d’une dette trop importante.
On le voit, cette métaphore s’appliquait à l’origine uniquement au code. Elle a depuis fortement évolué, pour traiter également d’autres aspects du Système d’Information : dette d’infrastructure, dette d’architecture, dette applicative… Toutefois, si ce concept est très prisé dans le monde IT, il est souvent mal compris. Les interprétations qui en sont faites feront l’objet d’un prochain article.
