Glossaire
Dette technique
La dette technique est le coût futur des raccourcis pris aujourd’hui dans un logiciel : correctifs rapides, tests sautés ou code obsolète qui rendent chaque modification ultérieure plus lente, plus risquée et plus chère jusqu’à ce que quelqu’un les corrige.
Un exemple de dette technique
Pour tenir une date de lancement, un développeur copie la même logique de prix à trois endroits au lieu de la construire une seule fois. Cela fonctionne. Quelques mois plus tard, les prix changent, quelqu’un met à jour deux des trois copies et les clients voient des totaux faux. Le raccourci a fait gagner une journée ; les « intérêts » sont chaque bogue et chaque modification lente qui suivent.
Les signaux d’alerte de la dette technique
- De petites modifications prennent des semaines et cassent souvent autre chose.
- Un seul développeur comprend le fonctionnement d’une partie clé.
- Les bibliothèques et frameworks ont des années de retard et ne peuvent pas être mis à jour sans risque.
- Des bogues réapparaissent après avoir été corrigés.
La dette technique est-elle toujours mauvaise ?
Non. Comme un prêt professionnel, une certaine dette est un choix raisonnable, par exemple un MVP rapide pour tester une idée. Le vrai problème, c’est la dette que personne ne suit. Tenez une liste des raccourcis connus, réservez régulièrement du temps pour corriger les pires et remboursez-les avant de construire de grosses fonctionnalités par-dessus.
Questions fréquentes
Comment savoir si mon logiciel a de la dette technique ?
Demandez à vos développeurs quelles parties ils redoutent de toucher et observez le temps que prennent les demandes simples. Une revue de code indépendante peut aussi dresser la liste des zones les plus risquées et de ce que leur correction impliquerait.
Faut-il réécrire le logiciel pour se débarrasser de la dette technique ?
Rarement en premier lieu. Une réécriture complète est coûteuse et risquée, et corriger les pires zones une par une apporte généralement de la valeur plus tôt. Une réécriture ou une migration se justifie quand la plateforme elle-même n’est plus maintenue ou ne peut plus faire ce dont l’entreprise a besoin.
Tous les termes du glossaire
- Produit minimum viable (MVP)
- Adéquation produit-marché (product-market fit)
- Phase de cadrage (discovery)
- Dérive du périmètre (scope creep)
- Logiciel sur mesure
- Stack technique (tech stack)
- CMS headless
- Progiciel de gestion intégré (ERP)
- Gestion de la relation client (CRM)
- CRM de téléprospection (telecalling)
- Logiciel en marque blanche