La dette technique désigne l'ensemble des compromis accumulés dans un projet logiciel (absence de tests, architecture rigide) qui, comme une dette financière, génère des « intérêts » sous forme de lenteur et de bugs.
Le Risque
Une dette non gérée rend les évolutions lentes et risquées. Les développeurs perdent en productivité et, à terme, la refonte complète devient la seule option coûteuse.
La Maîtrise
Elle passe par des revues de code, des tests automatisés et un refactoring continu. L'objectif n'est pas de l'éliminer, mais de la maintenir à un niveau acceptable.
Dette volontaire, dette subie
Toute dette n'est pas un problème. Prendre un raccourci conscient pour valider une hypothèse produit ou tenir une échéance est un choix rationnel, à condition qu'il soit documenté et qu'une date de remboursement existe. La dette qui pose problème est celle que personne n'a décidée : accumulée sprint après sprint, faute de cadrage, de temps ou de relecture, et découverte le jour où une évolution simple prend trois semaines.
Les intérêts se paient rarement là où on les attend. Ils se voient dans des indicateurs que tout le monde peut suivre :
- Le temps de cycle — le délai entre l'écriture d'une ligne et sa mise en production s'allonge.
- Le taux de régressions — chaque livraison casse quelque chose ailleurs.
- La part du temps consacrée à contourner l'existant plutôt qu'à créer de la valeur.
- Les montées de version reportées — une version de PHP ou de framework hors support est une dette dont les intérêts sont aussi des failles de sécurité.
Comment je la traite sans geler les développements
Je ne propose presque jamais un « sprint de dette » isolé, qui finit sacrifié à la première urgence. La dette se rembourse dans le flux :
- Prioriser par la fréquence de modification — un module touché chaque semaine coûte cher en continu ; un module stable depuis deux ans avec du code imparfait ne coûte rien. L'historique Git donne la réponse.
- Rendre la dette mesurable — une baseline PHPStan versionnée, avec l'option qui fait échouer la CI quand une erreur ignorée disparaît, devient un compteur qui ne peut que baisser.
- Réserver une part fixe de la capacité à l'amélioration de l'existant, plutôt que d'attendre un incident pour s'y intéresser.
- Améliorer ce qu'on touche — un renommage, une méthode extraite, un test ajouté à chaque intervention.
Un exemple concret
Sur les cinq applications Symfony que je maintiens pour Orange, la dette se traite au fil de l'eau : les dépendances sont mises à jour régulièrement, les versions majeures de Symfony ont été franchies une par une. En préparant le passage de PHP 8.4 à 8.5, l'étude des contraintes paquet par paquet dans les cinq composer.lock a montré qu'une seule application était bloquée — par un paquet OAuth tiré par un bundle qu'elle ne chargeait plus. La dette n'était pas dans le code applicatif, mais dans une dépendance morte. Le remède a été de désinstaller d'abord ce qui ne servait plus, puis de monter le reste par un composer update ciblé.
Ce genre de dette est invisible tant qu'on ne la cherche pas, et bloquante le jour où une version de PHP sort du support.
Les pièges
- Confondre dette et code « pas à mon goût » — un nommage discutable dans un module figé n'est pas une priorité.
- Attendre qu'elle justifie une refonte — c'est la stratégie la plus chère, et la plus risquée.
- Ne pas l'expliquer aux décideurs — traduite en délais et en régressions, la dette devient un sujet de pilotage, plus une plainte d'équipe technique.
La dette technique n'est pas un défaut, c'est un choix. Elle devient un poison uniquement lorsqu'on oublie de la rembourser régulièrement.
Réduire la dette d'une application en production sans tout réécrire est au cœur de ma prestation de refonte et modernisation d'application web. La méthode est détaillée dans comment réduire sa dette technique sans arrêter les développements.