Qu’est-ce que la dette technique et quels sont ses impacts ?

Constituée par les coûts cachés d’une application ou d’un logiciel, la dette technique n’est toutefois pas identifiable par une perte de capital directe. Néanmoins, elle engendre de nombreux dysfonctionnements qui peuvent représenter des coûts considérables et avoir un impact direct sur le business de votre entreprise.

Dette technique : définitions et analogies

D’après Wikipedia, la dette technique apparaît «quand on code au plus vite et de manière non optimale». Dans ces conditions «on contracte une dette technique que l’on rembourse tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents». Cette méthode entraîne des malfaçons, et la dette technique sera remboursée par des délais plus longs et de fréquentes corrections de bugs.

Bastien Jaillot explique quant à lui que la dette technique est «l’accumulation des risques pris lors des différentes phases techniques tout au long de la vie d’un projet». Le lien est fait, ici, avec la prise de risques, volontaire ou non, sur laquelle nous reviendrons plus tard.

Enfin, on peut comparer la dette technique avec la dette financière : dans les deux cas, il faut rembourser la dette, additionnée d’intérêts (en temps, en argent, en mobilisation de ressources humaines, etc.).

D’où provient la dette technique ?

La dette technique volontaire

Elle est la conséquence de décisions prises tout au long de la vie d’un projet digital. Pour raccourcir les délais (time-to-market), pour innover ou réaliser rapidement les tests (fail-fast), on décide de livrer du code en sachant qu’il comporte des défauts : ceci génère de la dette technique volontaire.

Par exemple :

• Le Quick Fix permet de corriger un bug rapidement mais sans prendre en compte tous les cas : les corrections ultérieures seront encore plus longues.
• Le Proof of Concept (PoC) devient le Minimum Viable Product (MVP) qui devient la 1ère version (V1), puis la V2… et au final, se maintient indéfiniment.
• On traite uniquement les bugs bloquants, c’est-à-dire ceux qui ont de la valeur business… mais ils sont difficiles à connaître à l’avance.
• On élabore des fonctionnalités « pour demain » en comptant sur la méthode agile pour y parvenir.
• On débranche les tests fonctionnels ou unitaires, pour livrer dans l’immédiat.

La dette technique involontaire

La dette technique involontaire se développe à notre insu et s’avère difficile à évaluer, en raison notamment de la complexité métier des applications, du turnover des équipes, de l’empilement des changements de métiers et d’un manque de compétences ou de méthode. Différents aléas peuvent se produire au cours d’un projet :

• Au niveau du produit : le besoin n’est pas clairement défini, ou des breaking news entraînent des changements de dernière minute.
• Au niveau de la technique : des ajouts de micro-services parfois complexes et peu adaptés, ou des problèmes de désorganisation (comme plusieurs développements non coordonnés d’une même fonctionnalité…).

L’impact de la dette technique

L’impact de la dette technique sur les projets IT

D’après Élodie Micoulet, l’impact de la dette technique peut être représenté par les itérations du projet. À chaque itération se crée une dette constante, à laquelle s’ajoute un intérêt à l’itération suivante. Ceci réduit le volume de fonctionnalités nouvelles pouvant être livrées. La vélocité diminue et la dernière itération peut consister à corriger des bugs.

L’impact de la dette technique sur les équipes

La dette technique pèse sur la motivation des équipes et génère ainsi du stress. Celui-ci entraîne un turnover élevé, que le management et le DSI ne savent plus redresser. Ces dysfonctionnements génèrent également une régression de la vélocité – notamment en raison du temps nécessaire à l’intégration des nouveaux venus dans l’équipe – et, à terme, une insatisfaction croissante des sponsors devant les ralentissements, les changements fréquents d’interlocuteurs, le retard pris par les projets, etc. S’enclenche alors une spirale infernale qu’il faut savoir stopper dès le début !

Les indicateurs clés d’une dette technique trop lourde

Pour mieux percevoir la dette technique d’un projet IT, il est possible de déceler plusieurs indices :

• La motivation et la vélocité des équipes s’effondrent, les délais de corrections de bugs sont imprévisibles, générant du stress et un important turnover.
• Les sponsors perdent confiance en raison de retards ou de baisses de qualité.
• Les budgets explosent, par exemple pour l’hébergement ou les audits de sécurité.
• Les livraisons deviennent instables et les performances business comme techniques se dégradent (temps d’affichage ou de réponse par exemple).
• La scalabilité devient impossible et la sécurité n’est plus assurée (hacks).

Comme dans le jeu Tetris, il est impossible de rester l’écran vide, mais on ne doit pas monter trop haut non plus : rester au premier tiers est un bon compromis pour ne pas risquer d’être débordé. Il en va de même en développement : une application produira toujours de la dette technique, mais celle-ci doit rester maîtrisée pour limiter les coûts et surtout, éviter le Game over.

Conclusion

Pour conclure, nous rappellerons que la dette technique est présente dans tout projet IT : il ne s’agit pas de la supprimer mais de la maîtriser. Laisser dériver sa dette technique entraîne des coûts humains, techniques et financiers tels que la démotivation des équipes, une stack technique obsolète et des coûts de correction des bugs. Pensez à évaluer la dette technique dès le début de votre projet afin de l’anticiper et la maîtriser.