Prise en compte des coûts cachés dans le développement logiciel : la dette technique

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 ». Lire la suite…

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]

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 ».

David Lantier
Consultant J2S