La notion de dette technique, formulée par Ward Cunningham en 1992 , s’applique tant au logiciel qu’à d’autres disciplines, et reste d’actualité en 2014. L’analogie avec le logiciel consiste à voir dans toute « approximation technique» une dette qu’il faudra rembourser dont le taux d’intérêt sera déterminé par le « degré d’approximation ».
En d’autres termes, ne pas respecter les règles de l’art conduit à générer un coût caché, lequel devra être payé d’une manière ou d’une autre, dès lors qu’une intervention sera nécessaire.
Un logiciel à « faible dette» est un logiciel parfaitement conçu, simple et parfaitement étagé, avec un code relu, parfaitement documenté, disposant d’outils d’intégration et de tests automatisés. Bref, un logiciel aisé à corriger et à faire évoluer. À l’opposé, un logiciel à « forte dette» est écrit aussi vite que possible, sans aucune documentation, sans aucun souci d’étagement ou d’architecture, ni de test… par exemple dans le cadre d’un prototype ou un test. Il ne s’agit donc pas d’émettre un jugement de valeur car il est parfois légitime de produire un logiciel à « forte dette » ; on comprendra aisément qu’il n’est pas pertinent de documenter un logiciel « jetable » destiné à un usage très limité dans le temps.
Une corrélation entre la durée de vie d’un logiciel et sa dette
Avec le temps, le montant accumulé des intérêts d’une dette augmente. Si le logiciel a une durée de vie éphémère, sa « dette » n’a aucune importance. Inversement, la dette prend d’autant plus d’importance que la durée de vie d’un logiciel est longue, puisque ses intérêts augmentent avec le temps. Au point que certaines équipes de développement rechignent à travailler sur certaines parties ou certains aspects d’un logiciel, parce qu’elles sont mal conçues ou devenues piégeuses.
Dette naturelle, dette intentionnelle
En fait, le problème n’est pas tant la dette : il est normal d’en générer. « La dette naturelle est quasiment inévitable sur un projet qui regroupe souvent des développeurs d’expériences et de sensibilités différentes. » [1] Ce qui importe, c’est qu’elle soit « mise sur la table », en tant que travail à faire, qui augmente le coût futur de toute correction ou évolution tant qu’il n’est pas réalisé. L’essentiel, c’est que les personnes qui prennent des décisions impactant le logiciel aient conscience de l’état de cette dette. « La dette intentionnelle est le résultat de décisions de livrer une ou des fonctionnalité(s) rapidement. Cette dernière représente ici un investissement et est effectivement justifiable. »[ 2 []](#_ftn2)
Il n’existe aucune méthode comptable pour inscrire cette dette au bilan des entreprises, et elle n’y est d’ailleurs jamais inscrite – à notre connaissance. De même, cet aspect des choses est rarement abordé au niveau commercial : lorsqu’on parle d’un logiciel, on fait référence à sa stabilité, à la complétude de ses fonctionnalités, à son look & feel, mais jamais à la dette inhérente.
La dette technique chez J2S
Pour J2S, cette notion est fondamentale. C’est une préoccupation majeure de l’équipe R&D que de prendre ses décisions en fonction de la « dette », et la direction de l’entreprise gère cette contrainte en toute connaissance de cause. Avec pour résultat une équipe sereine, et des clients satisfaits qui nous disent : « les logiciels J2S sont industriels, ils fonctionnent et se font oublier ».
| La dette technique en image Imaginez la scène suivante : vous avez fait des efforts considérables pour vous offrir une belle voiture, une Rolls par exemple, qui répond parfaitement à vos besoins. Vous oubliez de la nettoyer et de l’entretenir régulièrement (changer les pneus, mettre de l’antigel, enlever les papiers qui traînent, etc.) ; au fil du temps, elle est devenue une voiture banale si bien qu’un jour, vous vous dites qu’elle n’est plus adaptée, qu’il faut en changer et vous commencez à regarder les autres marques. Vous l’aurez compris, une bonne gestion de la dette technique consiste à effectuer les opérations d’entretien pour préserver la valeur de son outil. |
|---|
D. Lantier
Business Developer
[1] Document édité par la société Xebia, qui détaille très bien le concept : http://blog.xebia.fr/wp-content/uploads/2011/09/Xebia-Maitrisez-votre-dette-technique.pdf
[2] idem