Une demande de fonctionnalité qui prenait deux jours en prend maintenant deux semaines, et personne ne sait vraiment dire pourquoi. La réponse honnête ressemble en général à "c'est compliqué là-dedans." Cette complication a un nom : la dette technique. Ce n'est pas une plainte de développeur. C'est un coût bien réel sur vos comptes, vous ne l'avez simplement jamais vu détaillé sur une ligne.
La dette technique, c'est ce qui s'accumule quand un logiciel est construit avec des raccourcis, sous la pression d'un délai, avec l'intention de nettoyer plus tard. L'analogie, c'est un emprunt : vous gagnez du temps maintenant en sautant un vrai correctif, un test, un petit nettoyage, et vous le remboursez plus tard avec intérêts, sous forme de travail plus lent et de plus de bugs. Emprunter n'est pas toujours une erreur. Livrer une version fonctionnelle deux semaines plus tôt pour commencer à avoir des clients payants est souvent la bonne décision. Le problème, c'est que presque personne ne revient rembourser, parce qu'il y a toujours une prochaine échéance.
Ça se manifeste de façon banale. La même logique copiée dans trois endroits différents parce que personne n'a eu le temps de la construire une fois, proprement, et de la réutiliser. Une bibliothèque en retard de trois versions majeures parce qu'une mise à jour risque de casser quelque chose et que personne ne veut être celui qui le découvre. Un contournement pour un bug censé être temporaire, écrit il y a deux ans, dont la moitié du code dépend désormais discrètement. Rien de tout ça n'a l'air dramatique pris isolément. Ça s'accumule.
Le coût, c'est ce que ça fait à tout ce qui vient ensuite. Des changements qui devraient être simples obligent quelqu'un à d'abord comprendre un enchevêtrement de code que personne ne se souvient vraiment avoir écrit. Les bugs deviennent plus difficiles à traquer parce qu'un correctif à un endroit a des effets de bord trois fichiers plus loin que personne n'avait prévus. Les estimations finissent par ne plus rien vouloir dire, parce que "combien de temps ça va prendre" devient discrètement "combien de temps ça va prendre, plus le temps qu'il faudra pour démêler la partie qu'on touche." Et chaque dépendance obsolète qui traîne est aussi une faille de sécurité que personne ne surveille activement.
-
Ce n'est pas la même chose que du mauvais code. Un système bien construit qui prend volontairement de la dette, pour tenir un vrai délai, avec l'intention d'y revenir, c'est une décision commerciale normale et souvent judicieuse. La dette qui fait vraiment mal, c'est celle que personne n'a décidé de prendre, elle s'est juste accumulée parce que personne ne regardait.
-
Elle s'accumule avec intérêts. Un raccourci qui vous coûte une heure de plus aujourd'hui coûte davantage plus il reste en place, parce que davantage de code se construit par-dessus, et le démêler plus tard veut dire démêler aussi tout ce qui en dépend désormais. Le même correctif est toujours moins cher maintenant que dans un an.
-
Il y a des signes qui ne trompent pas. Si les estimations pour des changements qui semblent simples reviennent toujours élevées, s'il y a des fichiers ou des fonctionnalités que votre équipe évite visiblement de toucher, si des demandes de "correctif rapide" se transforment systématiquement en enquêtes de plusieurs jours, vous portez plus de dette que vous ne le pensez, que quelqu'un l'ait formulé ainsi ou non.
-
La rembourser ne veut pas dire tout arrêter pour réécrire le système. Les entreprises qui gèrent bien ça traitent le nettoyage comme une part normale du travail, pas comme un projet à part : quand vous touchez déjà une portion de code en désordre pour ajouter une fonctionnalité, vous nettoyez le désordre pendant que vous y êtes, au lieu d'empiler un raccourci de plus. Un peu, régulièrement, vaut mieux qu'une grande réécriture qui finit toujours repoussée dès qu'un sujet urgent arrive.
-
Une réécriture complète est rarement la bonne réponse, et méfiez-vous de qui la propose comme premier réflexe. Les réécritures coûtent cher, prennent du temps, sont systématiquement sous-estimées, et mettent tout le système en danger d'un coup plutôt que de l'améliorer progressivement. Un nettoyage ciblé des parties qui posent réellement problème bat presque toujours le fait de tout recommencer.
Si votre équipe répète qu'une demande qui a l'air simple "n'est pas si simple," prenez ça au sérieux, pas comme une plainte sur le code mais comme une information sur où va vraiment votre argent. Nous regardons ce qui ralentit vraiment les choses avant de recommander quoi que ce soit, un nettoyage, une réécriture partielle, ou simplement laisser tranquille une partie du système qui fonctionne, et vous obtenez une réponse franche de la personne qui a regardé le code, pas un argumentaire pour un projet plus gros que ce dont vous avez besoin.
La dette technique et le choix entre logiciel sur étagère et sur mesure sont les deux faces d'une même pièce : il s'agit dans les deux cas de combien vous êtes prêt à payer plus tard pour ce qui est pratique maintenant. Logiciel sur étagère ou sur mesure ? Voici comment trancher si vous êtes face à ce choix dès le départ. Et si le symptôme que vous observez est plutôt un site lent qu'un développement lent, voici un vrai diagnostic étape par étape. Dans tous les cas, c'est exactement ce à quoi sert notre service Support & Maintenance.
Un projet en tête ?
Démarrer un projet