Dette technique : définition et exemples
Ensemble des raccourcis pris dans le code pour aller vite, qui rendent ensuite chaque évolution plus lente et plus chère. Comme une dette d'argent, elle se rembourse, ou ses intérêts grossissent.
- Conduite du projet
Mis à jour le
La dette technique en clair
La dette technique désigne les raccourcis pris dans le code d'un logiciel pour aller plus vite : une solution provisoire jamais reprise, une partie copiée plutôt que bien rangée, une mise à jour repoussée. Sur le moment, on gagne du temps. Ensuite, chaque modification coûte un peu plus, comme les intérêts d'un emprunt.
L'image vient du développeur américain Ward Cunningham, en 1992. Elle a l'avantage de parler aux dirigeants : une dette n'est pas forcément une faute, tant qu'on la choisit et qu'on la rembourse.
Des exemples de dette technique
- Le provisoire qui dure : un calcul codé en dur pour une démonstration, toujours là trois ans plus tard.
- Le copier-coller : la même règle écrite à cinq endroits, qu'il faut corriger cinq fois, et qu'on oublie à un endroit.
- Les mises à jour repoussées : des briques logicielles vieilles de plusieurs versions, avec leurs failles de sécurité connues.
- Pas de tests automatiques : chaque changement peut casser autre chose sans que personne ne le voie.
- Une technique abandonnée : un outil ou une plateforme qui n'est plus maintenu, et que plus personne ne veut reprendre.
- Pas de documentation : seul le développeur d'origine sait comment tout tient.
Les signes qui doivent alerter
- une petite évolution demande des semaines, et son prix ne cesse de monter ;
- les mêmes bugs reviennent après avoir été corrigés ;
- les développeurs disent qu'ils ont peur de toucher à certaines parties ;
- une mise à jour d'iOS, d'Android ou du navigateur casse l'application ;
- personne d'autre que le prestataire actuel ne peut reprendre le projet.
Comment la réduire
Rarement en refaisant tout : une refonte complète coûte cher et recrée souvent sa propre dette. La voie habituelle est de mesurer d'abord, par un audit du code, puis de rembourser par priorité : la sécurité et les mises à jour en premier, ensuite les parties que l'on modifie le plus souvent. Le reste se rembourse au fil des évolutions, en réservant une part de chaque chantier au nettoyage.
Ce que ça change pour votre projet
Beaspo réalise l'audit de code des applications existantes, sur devis, et remet un diagnostic écrit : ce qui tient, ce qui se répare, ce qui se refait. La reprise d'application prend ensuite le relais si vous le souhaitez.
Un projet en tête ? Parlons-en, sans jargon.
Un appel de 30 minutes avec Clément, puis une proposition écrite avec le périmètre, le prix et la date de mise en ligne.
Sur demande, vous signez un accord de confidentialité avant l'appel.
Questions fréquentes : Dette technique
Comment mesurer la dette technique d'une application ?
Par un audit du code : des outils repèrent les répétitions, la complexité, les briques périmées et les failles connues, puis un développeur expérimenté lit les parties sensibles et juge ce qui pèse vraiment. Le résultat utile n'est pas une note, mais une liste chiffrée de ce qu'il faut corriger, dans quel ordre.
Une application neuve peut-elle avoir de la dette technique ?
Oui, dès sa livraison, si elle a été faite dans l'urgence, sans tests ni documentation, ou sur une technique déjà en fin de vie. C'est pourquoi la qualité du code se vérifie avant d'accepter une livraison, et pas seulement au moment où les évolutions deviennent difficiles.
Une autre question ?
Clément vous répond en moins de 2 h.