Dette technique

La dette technique est un concept utilisé en informatique pour décrire le coût à long terme de solutions rapides ou temporaires adoptées lors du développement logiciel. Cela se produit lorsque les développeurs choisissent des solutions qui permettent de répondre rapidement à un besoin immédiat, mais qui peuvent entraîner des problèmes ou des coûts plus importants à long terme.

C'est un concept du développement logiciel inventé par Ward Cunningham en 1992^[1]. Le terme vient d'une métaphore, inspirée du concept existant de dette dans le domaine des finances et des entreprises, appliquée au domaine du développement logiciel.

Historique

Le terme est utilisé en mars 1925 dans le domaine littéraire pour décrire l'influence des romanciers français sur la technique des biographes et essayistes anglais^[2].

Dans le contexte de l'Informatique, Cunningham trace pour la première fois en 1992 un parallèle entre dette économique et dette technique :

« Sortir une première itération de code, c'est comme 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 peuvent être paralysées sous la charge de la dette d'une implémentation non consolidée, qu'elle soit orientée objet ou autre^[3]... »

— Ward Cunningham, 1992

Explications

Un projet de développement logiciel inclut souvent une conception logicielle, formalisée ou non. L'écriture du code source, selon la conception définie, assure la cohérence du projet et facilite sa maintenance :

• maintenance corrective : corriger les bugs informatiques ;
• maintenance évolutive : ajouter de nouvelles fonctionnalités au logiciel.

La dette technique peut se manifester de différentes manières :

• Code de mauvaise qualité et documentation manquante : le code est mal structuré, difficile à comprendre, mal documenté, ou ne respecte pas les règles de codage, ce qui rend la maintenance plus difficile. Un manque de documentation appropriée rend difficile la compréhension du fonctionnement du logiciel pour les nouveaux développeurs ou ceux qui doivent effectuer des modifications.
• Conception ou architecture inadéquate ou négligée : une architecture bâclée ou qui ne prend pas en compte les besoins d'évolution future peut entrainer des contraintes techniques et des coûts de développement supplémentaires^[4].
• Dépendances externes (bibliothèques, API, modèles, architectures, etc.) : les éléments externes évoluent en parallèle, ce qui provoque l'obsolescence de certaines parties du code, donc la nécessité de créer des mises à jour. Ne pas mettre à jour ces parties de code, c'est-à-dire utiliser une version obsolète d'un élément externe, peut notamment rendre le logiciel vulnérable aux failles de sécurité, limiter ses performances, etc.

La dette technique doit être remboursée rapidement pour éviter l'accumulation de ses intérêts, d'où l'analogie avec le concept de dette financière.

La dette technique est inévitable dans le développement logiciel et perdure tout au long de la vie du produit. Elle peut cependant être contrôlée, notamment avec l'extreme programming, une méthode axée sur la productivité et la réduction des coûts en informatique et en génie logiciel^[5].

Junade Ali écrit à propos du développement PHP en 2014 :

« Le coût lié au non-remboursement de cette dette technique est clair : à terme, la livraison de nouvelles fonctionnalités deviendra si lente qu'il sera facile pour un logiciel concurrent bien conçu de dépasser le logiciel mal conçu en termes de fonctionnalités. D'après mon expérience, un logiciel mal conçu peut également conduire à une main-d'œuvre plus stressée, ce qui conduit à un taux de renouvellement du personnel plus élevé (ce qui affecte à son tour les coûts et la productivité lors de la livraison des fonctionnalités). »

— Junade Ali, Mastering PHP Design Patterns^[6]

Intentionnalité et durée (court terme et long terme)

Une dette technique peut être intentionnelle ou non.

Une dette technique non intentionnelle est due à des malfaçons : non-respect de la conception, non-respect des règles de codage, etc. Il n'y a aucun bénéfice à retirer de ce type de dette.

Une dette technique intentionnelle est quant à elle calculée à l'avance. Puisque favoriser la qualité de la conception augmente la charge de travail, les développeurs d'un logiciel peuvent choisir de sacrifier la qualité pour en retirer un bénéfice. Par exemple, s'il faut livrer rapidement une nouvelle version du logiciel, respecter la conception idéale peut mettre en péril la livraison du produit, causer des répercussions financières ou même légales dans le cas de service-level agreements (SLA). Dans cette situation, l'objectif (la sortie de la nouvelle version) est prioritaire. L'intentionnalité de la dette technique serait donc de contracter une dette à court terme pour favoriser l'évolution du projet à long terme. L'essentiel serait alors de rembourser cette dette rapidement, une fois l'objectif atteint, pour éviter l'accumulation des intérêts.

La dette technique était estimée par le cabinet Gartner à 500 milliards de dollars en 2010^[7].