Beaucoup de mes clients ne savent pas qu'ils ont de la dette technique. Le mot ne leur dit rien, et ils ne comprennent pas pourquoi je leur parle de migration ou de refonte alors que leur site fonctionne très bien.
C'est normal : la dette technique ne se voit pas à l'écran. Elle se voit le jour où un module cesse de fonctionner, où une faille de sécurité apparaît, ou où l'on veut ajouter une fonctionnalité que la technologie en place ne permet pas.
Voici ce que c'est, des exemples tirés de mes projets, et la façon dont j'aide mes clients à décider quoi en faire.
La dette technique, en clair
La dette technique, ce sont les raccourcis et les technologies vieillissantes d'un site ou d'une application qui rendent chaque modification future plus chère et plus risquée.
Une comparaison : votre site est comme une voiture qui roule très bien, mais dont le constructeur ne fabrique plus les pièces. Tant que rien ne casse, tout va bien. Le jour où une pièce lâche, il faut en trouver une d'occasion, l'adapter, ou changer une partie du moteur pour remplacer une simple courroie.
Et comme une dette financière, elle produit des intérêts : plus on attend, plus le remboursement coûte cher.
Trois exemples tirés de mes projets
Une version de PHP qui n'est plus maintenue
C'est le cas que je rencontre le plus souvent. Un serveur héberge plusieurs projets, et tous tournent avec une version de PHP qui ne reçoit plus de mises à jour de sécurité. Impossible de la changer : il faudrait mettre à jour tous les projets en même temps, avec un risque d'incompatibilité pour chacun de leurs modules.
Deux solutions ont fonctionné :
- Isoler les projets anciens sur un serveur dédié qui garde la vieille version, le temps de les faire évoluer un par un.
- Passer chaque projet dans un conteneur Docker : chaque projet embarque sa propre version de PHP et ne dépend plus du serveur. On peut alors les mettre à jour un par un, sans risquer de casser les autres.
Des modules WordPress abandonnés
Sur les sites WordPress, la dette technique prend souvent la forme de modules qui ne sont plus maintenus par leurs auteurs. Ils fonctionnent encore, mais ne reçoivent plus de correctifs : ce sont des failles de sécurité en attente.
Il faut alors trouver un équivalent, le configurer, et vérifier qu'il est compatible avec le thème et les autres modules. Et c'est souvent là que le client découvre le problème : pour remplacer un seul module, il faut d'abord mettre à jour WordPress, le thème et une partie des autres modules. Une intervention qui devait être simple devient une mise à jour lourde et coûteuse.
Une plateforme PHP qui ne pouvait plus évoluer
La seule fois où j'ai repris entièrement un projet pour cette raison, c'était une plateforme de mise en relation développée en PHP natif. Elle fonctionnait, mais le client voulait un site plus dynamique, avec du temps réel : appels, messagerie, paiement.
Pour cela, j'avais besoin de bibliothèques modernes qui n'étaient pas compatibles avec le code en place. La dette technique ne posait pas de problème au quotidien ; elle bloquait l'évolution dont le client avait besoin. La refonte s'est faite progressivement, sans interruption pour les utilisateurs.
Pourquoi on ne la voit pas
Un site chargé de dette technique fonctionne, souvent depuis des années. Rien à l'écran ne dit que la version de PHP n'est plus maintenue, ou qu'un module a été abandonné il y a deux ans.
Dans mon expérience, les clients la comprennent à deux moments :
- Quand un module ne fonctionne plus, et que sa réparation impose une mise à jour bien plus large que prévu.
- Quand ils veulent une expérience proche d'une application mobile (temps réel, interface fluide), et que la technologie en place ne le permet pas sans changer d'outil.
Avant ces moments-là, mes deux arguments sont la sécurité (une technologie qui n'est plus maintenue ne reçoit plus de correctifs) et la maintenabilité (chaque nouveau module ou nouvelle fonctionnalité devient plus difficile et plus cher à ajouter).
Dette technique et IA
Je n'ai vu qu'un seul site entièrement généré par l'IA, donc je ne généraliserai pas. Mais ce cas illustre bien la question.
Tout tenait dans un seul fichier : le HTML, le CSS, le JavaScript, les appels à une API externe, et la clé d'accès à cette API, écrite en clair dans le code. Le site fonctionnait comme une application d'une seule page, et pour un visiteur, tout avait l'air correct.
Deux problèmes pourtant :
- La moindre modification touche tout le reste. Sans organisation du code, il est difficile de changer une partie sans risquer d'en casser une autre. C'est exactement ce qu'est la dette technique : un raccourci pris au départ qui rend chaque évolution plus chère.
- La clé d'API est visible par n'importe quel visiteur, qui peut la lire depuis son navigateur et s'en servir à sa place. C'est plus grave que de la dette : c'est une faille de sécurité, à corriger avant toute mise en ligne.
L'IA est un très bon outil pour tester une idée rapidement. Mais un prototype généré par IA doit être relu et réorganisé avant d'accueillir de vrais utilisateurs.
Refaire, corriger ou vivre avec ?
C'est souvent la partie la plus délicate. Pour un client, il est difficile d'accepter de remettre de l'argent dans une plateforme qui fonctionne bien. Je le comprends, et c'est pourquoi je cherche d'abord la solution la moins chère qui règle le vrai risque.
Trois questions m'aident à trancher :
- Y a-t-il un risque de sécurité ? Une technologie qui n'est plus maintenue, un module abandonné, une clé exposée : il faut corriger rapidement. Souvent sans tout refaire (isoler l'ancien projet, le mettre dans un conteneur, remplacer un module).
- La dette bloque-t-elle une évolution dont vous avez besoin ? Si la technologie en place empêche une fonctionnalité importante pour votre activité, une refonte progressive peut se justifier. C'est le seul cas où j'ai repris entièrement un projet.
- Sinon, peut-on vivre avec ? Oui, à condition de le savoir et de prévoir chaque année un budget de mise à jour, plutôt que de tout découvrir le jour où quelque chose casse.
Si vous ne savez pas où en est votre site ou votre plateforme, c'est l'objet d'un audit : faire l'inventaire de la dette technique, distinguer ce qui est urgent de ce qui peut attendre, et chiffrer chaque option.
Questions fréquentes
Qu'est-ce que la dette technique ?
La dette technique, ce sont les raccourcis et les technologies vieillissantes d'un site ou d'une application qui rendent chaque modification future plus chère et plus risquée. Comme une dette financière, elle produit des intérêts : plus on attend, plus il coûte cher de la rembourser.
Comment savoir si mon site a de la dette technique ?
Les signes les plus courants sont une version de langage (PHP par exemple) qui n'est plus maintenue, des modules abandonnés par leurs auteurs, et des évolutions simples qui demandent des mises à jour lourdes. Un audit technique permet d'en faire l'inventaire et de chiffrer ce qui est urgent.
Faut-il refaire un site qui fonctionne encore ?
Pas forcément. S'il y a un risque de sécurité, il faut le corriger rapidement, souvent sans tout refaire. Une refonte se justifie surtout quand la technologie en place empêche une évolution dont vous avez besoin, comme le temps réel ou une expérience proche d'une application mobile.
Le code généré par IA crée-t-il de la dette technique ?
Il peut en créer, comme n'importe quel code écrit trop vite. Un prototype généré par IA est utile pour valider une idée, mais il doit être relu et réorganisé avant d'accueillir de vrais utilisateurs, notamment pour ne laisser aucune clé d'accès visible dans le code.