Dette technique: comment la mesurer avant qu'elle ne coûte trop cher ?

« On verra plus tard » est la phrase la plus chère du développement logiciel. Elle finance presque toujours une fonctionnalité livrée un peu plus vite aujourd’hui, contre un peu plus de temps perdu demain. Ce mécanisme a un nom depuis plus de trente ans, une façon de le mesurer, et une vraie réponse à la question qui suit toujours : faut-il la rembourser, ou reconstruire ?

La plupart des dirigeants de PME découvrent la dette technique par ses symptômes, jamais par son nom : un budget de développement qui produit de moins en moins de résultat visible, des délais qui s’allongent sans raison apparente, un prestataire qui parle de « nettoyer le code » sans jamais donner de chiffre précis. Ce flou profite rarement au client. Voici de quoi remplacer l’impression par la mesure.

Qu’est-ce que la dette technique, exactement ?

La dette technique désigne le coût futur d’un raccourci pris aujourd’hui en développement : une fonctionnalité livrée vite, sans la structure ni les tests qui la rendraient facile à faire évoluer plus tard. Le concept a été formulé par le développeur Ward Cunningham en 1992, à travers une métaphore financière volontairement simple : comme une dette d’argent, elle porte intérêt tant qu’elle n’est pas remboursée, et ces intérêts se paient en temps de développement supplémentaire à chaque évolution future (dette technique, Wikipédia).

Cette nuance compte. Prendre un raccourci délibéré pour tester une hypothèse avant d’investir davantage est souvent une bonne décision, à condition de savoir qu’on l’a prise et de prévoir de la rembourser si l’hypothèse se confirme. Le vrai problème arrive quand la dette s’accumule sans que personne ne la nomme, jusqu’à ce que chaque nouvelle fonctionnalité coûte plus cher que la précédente pour un résultat comparable.

Pourquoi la dette technique coûte-t-elle si cher ?

Parce qu’elle se paie en continu, pas une seule fois. Une étude de référence menée par Stripe en 2018 auprès de plus de 1 000 développeurs et 1 000 dirigeants dans cinq pays a mesuré ce coût avec précision : le développeur moyen consacre plus de 17 heures par semaine à de la maintenance liée à du code existant, débogage et remaniement compris, dont environ 4 heures à corriger spécifiquement du code de mauvaise qualité. Ramené à l’échelle mondiale, ce temps représente un manque à gagner estimé à 85 milliards de dollars par an (Stripe, Le coefficient développeur). Ces chiffres datent de 2018, mais la mécanique qu’ils décrivent n’a pas changé : une dette non remboursée continue de prélever son intérêt à chaque cycle de développement, indépendamment de l’année.

Sur une PME avec un seul logiciel métier et un budget de développement serré, ce mécanisme se traduit très concrètement : une évolution qui prenait deux jours en prend cinq un an plus tard, pour le même niveau de complexité apparente. Personne n’a rien changé au périmètre demandé ; c’est le code sous-jacent qui est devenu plus coûteux à faire évoluer, un euro de développement à la fois.

Prenons un cas type pour rendre ça concret. Un logiciel sur mesure de suivi de production, développé en 2023 pour une PME industrielle, ajoute chaque trimestre une ou deux fonctionnalités. La première année, chaque ajout prend environ trois jours. La deuxième année, un ajout comparable en prend sept, sans que le périmètre demandé ait changé de nature. L’explication tient en une phrase : les premières fonctionnalités ont été codées sans tests, chaque nouvel ajout doit composer avec des dépendances jamais nettoyées, et personne n’a jamais consacré de temps dédié au remboursement. Le budget de développement n’a pas doublé, c’est le rendement de chaque euro dépensé qui s’est effondré.

Comment mesurer la dette technique de son logiciel ?

Quatre indicateurs suffisent à sortir du ressenti, sans outillage complexe ni audit de plusieurs semaines :

1. Le temps moyen pour livrer une évolution comparable, suivi dans le temps. Comparez le temps pris par des demandes de complexité équivalente à six mois d’intervalle. Un allongement sans changement de complexité est le signal le plus direct de dette qui s’aggrave.
2. La proportion du code couverte par des tests automatisés. Un code sans tests n’est pas nécessairement mauvais, mais chaque modification y devient un pari : personne ne peut garantir qu’un correctif n’a rien cassé ailleurs sans tout vérifier à la main.
3. La fréquence des correctifs qui en déclenchent un autre. Si corriger un bug en révèle régulièrement un second, non lié au premier, c’est le signe d’un code où les responsabilités ne sont pas clairement séparées.
4. Le temps qu’un nouveau développeur met à devenir autonome. Un code bien structuré se comprend en quelques jours par quelqu’un d’extérieur. Un code qui demande plusieurs semaines avant la première contribution autonome cache généralement une dette importante, même si l’équipe en place ne la perçoit plus.

Une dégradation sur deux de ces quatre indicateurs mérite un audit plus poussé. Sur trois ou quatre, la dette n’est plus un sujet théorique : c’est déjà un poste de coût actif, qu’il vaut mieux quantifier avant qu’un incident ne force la décision dans l’urgence.

Ces quatre indicateurs ont un avantage décisif sur un audit qualitatif classique : ils ne demandent pas d’expertise technique pour être suivis dans le temps par un dirigeant non technique. Un tableau de suivi trimestriel, quatre lignes, quelques minutes à remplir avec l’équipe de développement, suffit à transformer une impression diffuse (« ça devient long ») en une donnée de pilotage aussi concrète qu’un indicateur financier.

Quels signes indiquent une dette technique qui s’aggrave, au quotidien ?

Au-delà des quatre indicateurs mesurables, quelques signaux se ressentent directement dans le travail de tous les jours :

• Les développeurs évitent certaines parties du code. Une zone que personne ne veut toucher, par crainte de casser quelque chose sans comprendre pourquoi, est un aveu collectif de dette non documentée.
• Les estimations deviennent systématiquement fausses, dans le même sens. Si les demandes prennent régulièrement plus de temps que prévu, et toujours plus, l’écart n’est pas un problème d’estimation : c’est la dette qui grossit sous l’estimation.
• Les mêmes bugs reviennent après correction. Un correctif qui traite le symptôme sans toucher la cause profonde laisse la dette intacte, prête à se manifester à nouveau sous une autre forme.
• La documentation n’existe plus, ou ne correspond plus au code réel. Une documentation qui ment est souvent pire que son absence : elle donne une fausse confiance à qui s’y fie.
• Les mises à jour de sécurité prennent du retard. Faire évoluer une dépendance devient risqué quand personne ne peut garantir que rien d’autre ne va casser en même temps : la dette technique et la dette de sécurité s’alimentent l’une l’autre.

Ces signaux ne s’excluent pas mutuellement, et se cumulent presque toujours dans la pratique : un code que les développeurs évitent est aussi, la plupart du temps, un code dont la documentation ne correspond plus à la réalité et dont les mises à jour de sécurité traînent depuis des mois.

Faut-il rembourser la dette, ou reconstruire ?

Ça dépend de son ampleur, jamais d’un principe général appliqué par défaut. Une dette modérée sur une architecture globalement saine se rembourse par petites touches, au fil des évolutions normales : on refactore la zone qu’on touche déjà, sans chantier dédié. C’est le remboursement le moins coûteux, parce qu’il se confond avec le travail courant.

Une dette massive, accumulée sur un code sans structure depuis l’origine, change le calcul. À ce niveau, rembourser revient souvent à reconstruire une bonne partie du logiciel, morceau par morceau, avec tous les risques de régression d’une chirurgie sur un système qui continue de tourner pendant l’opération. Dans ce cas précis, une reconstruction assumée et bien menée coûte fréquemment moins cher qu’un remboursement étalé sur des mois, en particulier depuis que l’IA permet d’aller vite sur la reconstruction tout en extrayant fidèlement la logique métier du code existant, plutôt que de repartir d’une page blanche. Nous avons détaillé ce calcul en détail, avec les critères précis pour trancher, dans notre article sur la reprise d’un logiciel sans développeur.

Le vrai risque n’est ni de rembourser ni de reconstruire : c’est de ne jamais choisir, et de laisser la dette grossir jusqu’à ce qu’elle dicte la décision à votre place, généralement au pire moment. C’est exactement le même principe de diagnostic avant décision que nous appliquons à tout projet, détaillé dans notre méthode : mesurer avant d’agir, plutôt que de trancher sur une impression.

Comment éviter d’accumuler une nouvelle dette technique ?

Trois pratiques limitent l’accumulation, sans ralentir excessivement le rythme de développement :

1. Écrire les tests en même temps que le code, jamais après. Un test ajouté après coup documente ce que le code fait déjà, bugs compris. Un test écrit avec le code garantit que ce qui est livré fait ce qui était prévu.
2. Systématiser la revue de code par un second développeur. Un regard extérieur avant chaque mise en production détecte les raccourcis avant qu’ils ne deviennent invisibles à force d’habitude, et diffuse la compréhension du code au-delà d’une seule personne, ce qui limite au passage le risque évoqué dans notre article sur les logiciels sans développeur.
3. Budgéter explicitement du temps pour le remboursement. Une dette jamais inscrite dans la roadmap grossit par construction, parce qu’elle n’est jamais prioritaire face à une nouvelle fonctionnalité visible. Réserver 10 à 15 % du temps de développement au remboursement régulier coûte nettement moins cher qu’un chantier de refonte forcé deux ans plus tard.

Sur nos projets comme sur nos propres produits, cette discipline n’est pas une option : c’est ce qui permet à Melimelo, Trottr, Kascade et Smashr de continuer à évoluer chaque semaine sans que chaque nouvelle version prenne plus de temps que la précédente. C’est aussi le même principe qui structure notre tierce maintenance applicative quand nous reprenons un logiciel existant.

Un point mérite d’être précisé pour un dirigeant qui n’a pas la main sur le code : ces trois pratiques ne se décrètent pas, elles se vérifient. Un prestataire qui affirme écrire des tests et pratiquer la revue de code sans jamais montrer les chiffres qui le prouvent (taux de couverture, nombre de pull requests revues) donne une réponse rassurante, pas une garantie. Demander ces chiffres une fois par trimestre coûte cinq minutes et évite de découvrir la dette accumulée le jour où elle devient un problème.

Si vous voulez un état des lieux honnête de la dette technique de votre logiciel, sans engagement, parlons-en : un audit de quelques jours suffit à remplacer le ressenti par des chiffres.