Dette technique : refondre ou faire évoluer ? Décider avec des faits
La dette technique est le coût accumulé des raccourcis pris dans un logiciel, payé en temps perdu à chaque évolution. Pour les dirigeants qui hésitent entre refonte et évolution : les signaux qui montrent où elle coûte, une grille réparer, rembourser, remplacer, et comment la rembourser sans arrêter de livrer.
Votre produit a trois ans. Chaque nouvelle fonctionnalité prend plus de temps que la précédente, les corrections en cassent d'autres, et le développeur qui le connaît vraiment est parti. Quelqu'un prononce le mot « refonte ». Quelqu'un d'autre évoque le budget. Vous êtes au milieu, sans les éléments pour trancher.
La dette technique est le coût accumulé des raccourcis pris dans un logiciel : code écrit vite, bibliothèques jamais mises à jour, tests remis à plus tard. Comme une dette financière, elle a un principal (ce qu'il faudrait pour remettre à niveau) et des intérêts (le temps perdu à chaque évolution tant qu'on ne l'a pas fait).
02
Quels signaux montrent où sont les intérêts ?
La dette ne se voit pas dans le code depuis un bureau de dirigeant. Elle se voit dans les symptômes. Quatre signaux fiables, que vous pouvez observer sans ouvrir un fichier.
01
Le même module revient dans chaque incident
Regardez les corrections des six derniers mois. Si un tiers concernent la même zone (le paiement, l'export, la synchronisation), c'est là que la dette coûte. Le reste tient.
02
Une petite demande prend un temps déraisonnable
« Ajouter un champ dans le formulaire » ne devrait pas prendre une semaine. Quand c'est le cas, ce n'est pas le champ qui coûte, c'est tout ce qu'il faut démêler pour l'ajouter sans casser.
03
L'équipe a peur de toucher à une zone
Quand un ingénieur dit « on ne touche pas à ça », il ne parle pas de goût. Il parle d'une zone sans tests, sans documentation, où chaque modification est un pari. C'est un signal d'intérêts élevés.
04
Une évolution attendue est bloquée par la structure
Vos utilisateurs veulent du multi-comptes, du temps réel, un export massif, et la réponse est « pas avec l'architecture actuelle ». C'est le seul cas où la refonte d'un module devient une évolution, pas un remboursement.
03
Refondre ou faire évoluer : comment décider ?
La question n'est jamais « refondre le produit ». C'est « pour ce module, cette semaine, est-ce qu'on répare, on rembourse, ou on remplace ? ». Trois réponses, et une grille pour choisir.
Trois réponses pour un module qui coûte
Situation
Réparer
Rembourser
Remplacer
Ce qu'on fait
Corriger le symptôme, sans toucher à la structure
Ajouter des tests, mettre à jour, simplifier, documenter
Réécrire le module, en gardant ses interfaces
Quand
Le module est rarement touché et les incidents sont isolés
Le module est touché souvent et chaque intervention coûte trop
La structure bloque une évolution attendue, ou plus rien ne peut être testé
Coût
Une demande
Quelques demandes, étalées
Un chantier, découpé en demandes livrables
Risque
Faible, mais la dette reste
Faible, chaque pas est testé
Élevé à la bascule, à réduire par étapes
Dans la pratique, chez Figue, la répartition sur un produit repris est à peu près celle-ci : la plupart des modules se réparent, une poignée se rembourse sur quelques mois, et zéro ou un se remplace. Un produit entier à refondre est l'exception, réservée à une stack morte ou à un code impossible à faire tourner.
“Une refonte complète, c'est payer le logiciel une seconde fois pour retrouver, au mieux, ce qu'on avait. Avec les bugs qu'on connaissait remplacés par des bugs qu'on ne connaît pas encore.”
04
Comment rembourser sans arrêter de livrer ?
Le remboursement de la dette n'est pas un projet. C'est une habitude : une part de la file consacrée à ce qui rend la suite moins chère. Voici comment ça se passe dans une file traitée une demande à la fois.
Le bon rythme se lit dans la file : si les demandes de fonctionnalités reprennent une vitesse normale, le remboursement fait son travail. Si elles restent lentes sur un module malgré plusieurs passes, c'est le signal qu'il faut le remplacer, et cette fois avec des faits pour le justifier.
Il reste des cas où remplacer un module, ou plus rarement un produit, est la bonne décision. Ils ont un point commun : ce ne sont pas des questions de qualité de code, mais des questions de capacité.
La stack est morte : le langage ou le framework n'est plus maintenu, plus personne ne sait ou ne veut y travailler, les failles ne seront jamais corrigées. L'architecture bloque : ce que vos utilisateurs attendent ne peut pas être construit sur la structure actuelle, et le contournement coûterait plus que le remplacement. Ou plus rien ne peut être testé : chaque changement est un pari, et le module porte du chiffre d'affaires.
Même dans ces cas, la refonte se fait par étapes, module par module, en gardant l'ancien en marche jusqu'à ce que le nouveau soit validé. Une bascule unique, un vendredi soir, est le meilleur moyen de transformer une dette en incident.
Le modèle qui permet de mener ce chantier une demande à la fois, en continuant de livrer, est décrit sur la page développement illimité.
Questions fréquentes
La dette technique, en questions
Ce qu'on nous demande quand le mot « refonte » a été prononcé.
Comment savoir si mon produit a de la dette technique ?
Il en a, comme tous les produits qui ont des utilisateurs. La question utile est où elle coûte : regardez quels modules reviennent dans les incidents, quelles petites demandes prennent un temps déraisonnable, et quelles zones l'équipe n'ose pas toucher.
Un prestataire me recommande de tout refaire. Que lui demander ?
Des faits : quels modules, quels incidents, quel temps perdu, et pourquoi une reprise progressive ne suffirait pas. S'il répond en termes de technologie plutôt qu'en termes de symptômes, la recommandation est pour lui, pas pour vous.
Combien coûte de rembourser la dette ?
Ça dépend de son taux d'intérêt. Dans un abonnement, ce sont des demandes ordinaires dans la file, étalées entre les fonctionnalités ; vous en voyez le coût sous forme de place dans la file, pas sous forme de devis. Le vrai coût est celui de ne pas la rembourser : chaque évolution plus lente que la précédente.
Faut-il arrêter les évolutions pendant le remboursement ?
Non, et c'est le contraire qu'il faut faire : rembourser sur les modules qu'on est en train de faire évoluer, là où les intérêts se paient. Un « gel des fonctionnalités » de trois mois est un signal de refonte déguisée.
L'IA aide-t-elle à rembourser la dette ?
Beaucoup, pour écrire des tests, mettre à jour, simplifier. C'est même l'un des usages où elle est le plus rentable, parce que le travail est répétitif et vérifiable. À condition qu'un ingénieur relise : une simplification automatique non relue est une nouvelle dette.
