Dette technique

La dette technique est l’ensemble des raccourcis pris dans un logiciel (code non testé, dépendances obsolètes, structures bricolées) qui rendent chaque évolution future plus lente et plus risquée. Comme une dette financière, elle se rembourse avec intérêts : plus on attend, plus la correction coûte.

Elle s’accumule surtout quand on ajoute des fonctions sans jamais consolider, ou quand on empile des outils no-code au-delà de ce pour quoi ils sont faits.

Dette technique : définition simple

La dette technique, c’est quoi ? C’est ce qu’un logiciel doit encore « payer » pour avoir été construit vite : chaque nouvelle fonctionnalité coûte plus cher qu’elle ne devrait, en temps, en risque et en dépendance à la personne qui a écrit le code.

Le mot vient d’une métaphore financière proposée par Ward Cunningham en 1992 : emprunter de la vitesse aujourd’hui, la rembourser avec des intérêts plus tard. En développement logiciel, la dette technique ne se voit pas à l’écran ; elle se voit dans les délais.

Comment ça marche en pratique

Toute dette n’est pas une faute. Martin Fowler la classe sur deux axes : délibérée ou involontaire, prudente ou imprudente. Livrer vite une version simple, en notant ce qui reste à consolider, peut être un bon choix ; un raccourci que personne ne note devient un problème.

Elle se loge à quatre endroits : le code (duplications, fonctions trop longues), les tests (absents ou périmés), la documentation (le savoir vit dans une seule tête) et les dépendances (bibliothèques obsolètes).

Pour la reconnaître, trois indices suffisent : une modification simple qui traîne, une seule personne capable de faire évoluer le logiciel, une mise à jour que personne n’ose lancer.

Un exemple type : une bibliothèque de paiement laissée plusieurs versions en retard. Tout fonctionne, jusqu’au jour où le service de paiement retire l’ancienne version : la mise à jour devient urgente et touche tout ce qui en dépend.

Les limites de la notion. Tout code ancien n’est pas endetté : un module stable, testé et compris peut rester en place des années. La dette n’est pas non plus la seule cause de lenteur : un serveur mal situé produit les mêmes symptômes. Et ce n’est pas un bug : un bug casse, la dette ralentit.

La dette technique dans un projet de logiciel sur mesure

Elle change trois choses. Le délai : chaque évolution demande plus de temps qu’estimé. Le budget : une part de chaque devis paie la remise en état de l’existant. Le risque : la dépendance à une personne ou à un prestataire augmente, jusqu’au vendor lock-in.

Trois réponses sont possibles : la rembourser au fil des évolutions, faire reprendre le logiciel, ou le réécrire par lots, c’est-à-dire une refonte. Le choix dépend de l’état du code et des accès, pas de son âge : c’est ce que nous vérifions avant d’accepter une reprise et maintenance applicative. Pour trancher, voyez notre article dette technique informatique : signes, coût et décision.