La dette technique : explication, causes et solutions
- Digital
Votre site met de plus en plus de temps à évoluer, chaque mise à jour fait craindre une régression et personne n'ose toucher à certains modules ? Il y a de fortes chances que vous soyez face à une dette technique. Voici ce que recouvre cette notion, d'où elle vient et comment la garder sous contrôle.
Le code source d'un programme doit être conçu de manière à être le plus cohérent possible et à respecter les normes en vigueur, pour faciliter les maintenances correctives et évolutives. Car aucun projet de développement ne se termine à sa mise en service : des corrections, des adaptations et des mises à jour de sécurité arrivent ensuite, pendant des années parfois.
On parle de dette technique lorsque des choix passés rendent ces interventions futures plus longues et plus coûteuses. Comme pour un emprunt, le surcoût ressemble à des « intérêts » : on les paie à chaque évolution, tant que la dette n'est pas remboursée. L'image n'est pas nouvelle : elle a été proposée par le développeur Ward Cunningham au début des années 1990.
Donc, les écarts à la conception, intentionnels ou non, introduisent des difficultés pour les développements futurs.
Toutes les dettes techniques ne se ressemblent pas. On en distingue généralement 2 types.
Une dette technique non intentionnelle est liée à des malfaçons, souvent dues au non-respect de la conception et des règles de codage, ou à un manque d'expérience sur une technologie. Elle n'apporte aucun bénéfice au projet.
Une dette technique peut aussi être intentionnelle. Respecter toutes les règles de conception demande du temps, et pour tenir un délai de livraison (la sortie d'une nouvelle version, une opération commerciale, un salon…), l'équipe peut choisir un raccourci. Ce choix permet d'atteindre l'objectif prioritaire à court terme, mais il sacrifie une partie de la qualité sur le long terme.
Ce n'est pas forcément une mauvaise décision, à condition qu'elle soit consciente et notée quelque part. Il est ensuite conseillé de reprendre le code concerné une fois l'échéance passée, pour éviter que la dette ne devienne trop importante.
Elle s'accumule un peu chaque jour, parfois avant même l'écriture de la première ligne de code. Les technologies évoluent vite : une version de PHP cesse d'être maintenue, un framework change de version majeure, un module n'est plus mis à jour par son éditeur. Un code parfaitement correct il y a 5 ans peut ainsi devenir une source de dette sans que personne ne l'ait modifié.
La taille du projet joue aussi. Plus une application contient de code, de fonctionnalités et de connexions avec d'autres outils, plus sa maintenance demande de rigueur. Sur un site e-commerce, l'accumulation de modules tiers est un grand classique : chacun répond à un besoin ponctuel, mais l'ensemble devient difficile à mettre à jour.
Enfin, d'autres facteurs ont un impact encore plus important : l'absence de tests automatisés, une documentation inexistante, les changements d'équipe ou de prestataire. Tous sont liés à notre capacité à faire évoluer rapidement une base de code, c'est-à-dire à notre agilité.
Ou, à l'inverse, que se passe-t-il si l'on ne s'en occupe pas ? Inévitablement, la dette technique se forme et augmente, de manière peu visible mais bien réelle. Au début, elle a peu d'impact ; puis, avec le temps, elle grossit de plus en plus vite.
Au quotidien, voici comment elle se manifeste :
Le cas de Magento 1 l'a bien montré : à la fin de son support, en juin 2020, de nombreux e-commerçants se sont retrouvés avec une plateforme qui ne recevait plus de correctifs de sécurité, et une migration d'autant plus lourde qu'ils l'avaient repoussée. Les ralentissements sont un autre symptôme fréquent, comme sur ce site Magento devenu lent dont nous avons repris le code, le cache et le chargement des scripts.
Si vous vous retrouvez dans l'un de ces cas, il est temps de vous préoccuper de votre dette technique.
Pour éviter une dette technique trop coûteuse, il est conseillé de suivre quelques règles :
Le respect de ces règles apporte de la lisibilité au code source et facilite la reprise du développement par d'autres experts. Par ailleurs, un cahier des charges précis et clair permet d'éviter certains problèmes dès le lancement du projet.
Avant d'écrire la première ligne de code, il faut aussi savoir pour combien de temps l'application est conçue. Pour un projet à long terme, investir dès le départ dans une architecture solide évite des frais bien plus élevés par la suite. Pour un outil temporaire ou un prototype, accepter un peu de dette peut être un choix raisonnable, à condition de ne pas oublier qu'elle existe.
Pas de panique : une dette technique se rembourse, comme un emprunt. La première étape consiste à faire un état des lieux du code, des versions utilisées et des modules installés. Il devient alors possible de prioriser : ce qui pose un risque de sécurité d'abord, ce qui freine les évolutions ensuite.
Dans beaucoup de cas, une reprise progressive suffit, en intégrant la réduction de la dette à la maintenance et à l'évolution de l'application. Lorsque la dette est trop lourde, une refonte peut être plus raisonnable : nous en parlons dans notre comparatif de plateformes e-commerce, à propos du choix entre moderniser l'existant et changer de technologie.
👉 Un projet ou une question sur le sujet ?
Présentez-nous votre besoin et discutons des solutions que nous pouvons mettre en place.