Réduire la dette technique de son application

Réduire la dette technique de son application reste inchiffrable tant que deux bornes ne sont pas posées : jusqu’où descendre, et sur quelle partie de l’outil. Sans elles, la demande revient à remettre le code au propre partout, et personne ne met un prix là-dessus. La dette technique se mesure pourtant, en jours de travail. Des outils lisent le code sans l’exécuter, relèvent les défauts un par un, et chiffrent la correction de chacun. Une distinction commande ensuite tout le reste : une partie de cette dette arrive à échéance à une date fixée par d’autres, l’autre attend que vous rouvriez le code concerné, et les deux ne se financent pas sur la même ligne. Voici comment cette mesure se lit, comment ces deux dettes se séparent, sur quelle ligne chacune se finance, et le relevé à demander avant d’engager quoi que ce soit.

Ce que réduire la dette veut dire quand il faut le chiffrer

Le mot vient d’une comparaison avec un emprunt. Il y a le travail de remise en état, que vous engagez une fois, et il y a un intérêt de la dette, que vous payez chaque fois que vos développeurs touchent au code concerné. Un chantier de réduction porte sur le premier, et c’est lui qui se chiffre avant d’être décidé. Rouvrir un module ancien pour le corriger fait aussi craindre de casser une fonction qui marche aujourd’hui : c’est pour cette raison que le refactoring, qui réorganise l’intérieur d’un module en laissant intact ce que l’utilisateur en voit, se vérifie par les mêmes tests avant et après chaque lot, plutôt que par une relecture seule.

La dette se compte en jours de travail

La documentation de Sonar, éditeur d’un de ces outils de lecture, définit la dette technique comme la somme des coûts de correction des défauts de maintenabilité relevés, chaque coût étant l’effort estimé, en minutes, pour corriger le défaut. Le total sort en heures ou en jours. C’est ce total que vous mettez en face d’un budget.

Ce total ne dit rien à lui seul de ce qu’il représente, puisque la même charge pèse autrement sur une application de cent mille lignes et sur une de dix mille. Le même outil rapporte donc la dette à ce que l’application a coûté à écrire, et publie le résultat en pourcentage. Un ratio de dette technique de 8 % veut dire que le coût de remise à niveau représente 8 % du coût de développement de l’application. La notation associée va de A pour un ratio inférieur ou égal à 5 % à E à partir de 50 %, avec B, C et D entre les deux.

Ce coût de développement, l’outil ne le relève pas sur votre projet. Il le déduit du nombre de lignes multiplié par une durée réglée dans l’outil, et cette durée vaut 30 minutes par ligne par défaut. Deux entreprises qui n’ont pas le même réglage produisent deux ratios qui ne se comparent pas. Le vôtre ne se compare qu’à lui-même, d’un relevé au suivant, et à condition que le réglage n’ait pas bougé entre les deux. Demandez ce réglage en même temps que le chiffre.

Le périmètre se pose sur ce que vous allez rouvrir

Martin Fowler, qui a repris et diffusé cette comparaison avec l’emprunt, en tire une conséquence directe sur le périmètre d’un chantier. L’effort supplémentaire dépensé pour ajouter une fonction, écrit-il, est l’intérêt payé sur la dette. Il ajoute que ce paiement ne se déclenche qu’au moment où quelqu’un doit travailler sur cette partie du logiciel. Les zones encombrées mais stables du code, écrit-il encore, peuvent être laissées telles quelles.

Un module écrit dans l’urgence, que personne n’a rouvert depuis et que rien n’oblige à rouvrir, ne vous coûte donc rien tant qu’il reste fermé. Le remettre au propre est une dépense sans contrepartie, et elle apparaîtra pourtant dans un devis établi sur le seul total de la dette. Votre cible se construit à partir de vos évolutions prévues, pas à partir du relevé. Si vous ne savez pas encore laquelle de vos difficultés vient réellement de la dette, cette question-là passe avant et se traite à part, en séparant les quatre causes qui produisent une application devenue lente à modifier.

Deux dettes, dont une seule est datée d’avance

Une partie de ce que le mot dette recouvre ne dépend pas du moment où vous rouvrez le code. Elle arrive à échéance à une date fixée par d’autres, écrite à l’avance, et que vous touchiez ou non à l’application n’y change rien. Cette dette-là échappe à la règle de l’intérêt, et c’est elle qui commande l’ordre de passage de votre chantier.

La dette sans échéance se règle au fil de vos évolutions

Le code écrit trop vite, les contournements laissés en place, les règles de calcul recopiées à plusieurs endroits : cette dette-là suit la règle de l’intérêt, et son coût se répartit sur vos évolutions au lieu de se présenter en une fois. Elle ne justifie donc pas une ligne budgétaire à part.

Hiérarchisez-la sur un croisement : le relevé par module d’un côté, vos modifications prévues sur les douze mois à venir de l’autre. Un module chargé de défauts et absent de cette liste attend. Un module moins chargé qui porte trois de vos évolutions passe devant. Ce tri module par module est le même que celui qui s’applique quand vous héritez d’un travail dont vous n’avez pas suivi l’écriture, détaillé dans le tri d’un développement reçu d’une équipe précédente.

La dette à échéance arrive à sa date, que vous y touchiez ou non

Sous vos écrans tourne un ensemble de composants que votre prestataire n’a pas écrits, le socle technique, et chacun porte une date au-delà de laquelle son équipe cesse de le corriger. PHP en donne un exemple daté au jour près. Chaque branche reçoit deux ans de support actif, pendant lesquels les anomalies et les failles signalées sont corrigées, puis deux ans supplémentaires de corrections de sécurité critiques seulement. Ces durées ne se comptent pas au jour près depuis la sortie, car le calendrier publié fixe à chaque branche sa propre date de fin. PHP 8.2, paru le 8 décembre 2022, cesse de recevoir la moindre correction le 31 décembre 2026, sans qu’aucune décision de votre part n’intervienne. Ce mécanisme et ses effets sur un chiffrage sont détaillés dans ce qui expire sur un projet pendant qu’il dort.

Ce que devient un outil dont plus personne ne corrige le socle, le CERT-FR l’a écrit à propos d’un cas précis. Dans un bulletin d’actualité du 18 janvier 2023, le centre de veille de l’agence nationale de la sécurité des systèmes d’information revient sur la fin du support de Windows 8.1, arrêté huit jours plus tôt, et sur celle annoncée pour Windows Server 2012 et 2012 R2. Il y rappelle que, pour les versions de Windows qui ne sont plus couvertes par un support étendu ou une extension de mise à jour de sécurité, Microsoft ne communique plus sur la découverte de vulnérabilités pouvant les affecter et qu’elles demeureront donc méconnues et potentiellement exploitables. En cas d’impossibilité de migrer, ajoute le même bulletin, l’isolation du système vis-à-vis du système d’information constitue une mesure compensatoire visant à limiter les impacts en cas de compromission. Ce rappel porte sur des produits Microsoft et sur eux seuls. Ce qui se transpose à votre socle, c’est le mécanisme : une échéance décidée ailleurs, un outil qui continue de tourner, et plus personne pour corriger ce que d’autres y trouveront.

Cette dette-là se relève sans ouvrir une ligne de code, et elle se planifie sur un calendrier. Quand elle est le seul point à traiter et que vos écrans et vos règles de calcul tiennent, le chantier se limite à changer la base technique sous des fonctions qui ne bougent pas, sans rouvrir le reste.

Ce que vous financez, et sur quelle ligne

Réserver une part fixe du temps de l’équipe à la réduction de la dette est la réponse la plus simple à écrire dans un contrat, et c’est celle qui tient le moins. Sans cible mesurée ni périmètre, ce quota produit un travail que personne ne peut vérifier, et c’est le premier poste que vous retirerez quand le trimestre se remplira. Les deux dettes ne se financent pas de la même façon, et cette séparation rend la dépense défendable.

La dette à échéance, celle que les devis rangent sous le mot obsolescence, se traite en remise à niveau par lots, chaque lot chiffré, daté, et mis en service avant la date de fin de support qu’il vise. Ce travail ne produit aucune fonction visible par vos utilisateurs, et c’est pour cette raison qu’il a besoin de sa propre ligne budgétaire : rattaché à un projet fonctionnel, il se fait couper au moment où le projet dérape.

La dette sans échéance relève d’une règle permanente attachée aux évolutions, que la documentation de Sonar appelle Clean as You Code. Chaque contribution y respecte les standards de qualité retenus, et le développeur répond de la qualité du code neuf qu’il écrit aujourd’hui, sans avoir à répondre du code que d’autres ont laissé avant lui. Les défauts anciens qui remontent pendant qu’il modifie une zone entrent malgré tout dans ce qu’il traite, et l’ensemble du code progresse ainsi sans chantier dédié.

Cette règle a un coût que vous devez entendre avant de la retenir : elle rallonge chaque évolution, puisque chaque demande porte désormais une part de remise en état en plus de son contenu. Elle laisse aussi de côté les zones que personne n’ouvre, ce qui va dans le sens du périmètre posé plus haut mais ne règle rien pour un composant dont la date approche. Quand ce travail continu se poursuit après le chantier, il relève d’un engagement de suivi signé à part du forfait, avec le périmètre écrit dedans.

Le relevé à demander avant d’engager le chantier

Quatre demandes suffisent à transformer une intention en périmètre chiffrable, et aucune n’oblige à engager le chantier. Adressez-les à qui détient le code aujourd’hui.

La première est l’inventaire des dépendances : les composants du socle, chacun avec sa version installée et l’échéance de support annoncée par son éditeur. Cette liste se lit sans compétence technique, en remontant en tête ce qui tombe dans les douze mois.

Vient ensuite la mesure, avec ce qui la rend lisible : la dette en jours, le ratio, le réglage du coût par ligne qui a servi au calcul, et la date du relevé. Un pourcentage livré seul ne se compare à rien au relevé suivant.

La répartition arrive en troisième, module par module. Sans elle, le croisement avec vos évolutions prévues n’a pas de matière, et le total en jours ne vous dit pas par où commencer.

Reste le contrôle : la même mesure, refaite à date fixe, avec le même réglage. Elle vous dit ce que le chantier a produit.

Cette dernière demande porte un piège de lecture. Le ratio compare la dette à la taille du code, il mesure donc une densité et non un montant. Une équipe qui ajoute vingt mille lignes de fonctions propres fait baisser le ratio sans avoir corrigé un seul défaut, et votre tableau de bord affiche une amélioration. Lisez donc la dette en jours et le nombre de lignes à côté du ratio, parce que c’est le nombre de jours qui répond à votre question de budget.

Quand ces quatre demandes reviennent sans réponse, ou avec des réponses qui ne concordent pas, le point de départ n’est plus le chantier mais une lecture commandée à part. Un examen commandé seul, sur le code et l’hébergement tels qu’ils sont chiffre chaque correction relevée, y compris celles qu’il vous déconseille d’engager, et son rapport reste votre propriété même si le chantier ne se fait jamais.

Quand la réduction devient un chantier de modernisation

Tant que la dette se concentre sur quelques modules et que les dates de fin de support restent lointaines, la réduction tient dans vos évolutions courantes et ne demande aucun projet. Deux situations font basculer le sujet. La première est une échéance rapprochée sur une brique que toute l’application utilise, parce qu’aucune règle attachée aux évolutions ne rattrape une date. La seconde est un relevé où les modules les plus chargés sont ceux qui portent votre volume de saisie quotidien. L’intérêt y est payé sur chaque évolution, et la remise en état déborde alors ce qu’une demande ordinaire peut absorber au passage.

Dans ces deux cas, le travail se découpe en lots avec un ordre de passage, et il consiste à remettre à niveau un outil que vos équipes continuent d’utiliser pendant ce temps, sans rouvrir ce qu’il fait. Vous pouvez préparer la discussion en une page : vos composants avec leurs échéances de support d’un côté, vos évolutions prévues sur douze mois de l’autre. Envoyez-nous ces deux listes. Nous vous répondons par l’ordre de passage que le croisement des deux fait apparaître, et par les évolutions que vous avez inscrites sur des modules dont le socle expire avant elles, sans que vous ayez à engager la suite.

Sources

Understanding measures and metrics, documentation SonarQube Server 2025.1, Sonar, consultée le 10 septembre 2026, https://docs.sonarsource.com/sonarqube-server/2025.1/user-guide/code-metrics/metrics-definition

Clean as You Code, documentation SonarQube Server 10.5, Sonar, consultée le 10 septembre 2026, https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/clean-as-you-code

Technical Debt, Martin Fowler, 21 mai 2019, https://martinfowler.com/bliki/TechnicalDebt.html

Supported Versions, The PHP Group, consultée le 10 septembre 2026, https://www.php.net/supported-versions.php

Bulletin d’actualité CERTFR-2023-ACT-004, CERT-FR, ANSSI, 18 janvier 2023, https://www.cert.ssi.gouv.fr/actualite/CERTFR-2023-ACT-004/