Dette technique informatique : votre logiciel ralentit, faut-il la rembourser ?

Un logiciel dont chaque évolution coûte plus cher, prend plus longtemps et casse autre chose : c'est le visage le plus courant de la dette technique informatique. La plupart des guides qui la définissent parlent à des équipes de développement, avec leurs sprints et leurs outils d'analyse de code.

Cet article s’adresse au dirigeant qui paie le logiciel sans en lire le code : repérer la dette depuis son bureau, la mesurer avec le protocole en quatre étapes que nous avons suivi sur notre propre outil, savoir ce que vaut le « ratio de dette » qu’on lui présentera, choisir entre rembourser, reprendre ou réécrire. Avec deux incidents datés, relevés sur nos propres outils.

🧭 Dette technique informatique : définition et exemple concret

En développement logiciel, la dette technique est le surcoût que paie chaque évolution à cause de raccourcis pris plus tôt : code jamais consolidé, bibliothèques pas à jour, tests absents, documentation jamais écrite. Le mot vient de Ward Cunningham, dans un retour d’expérience présenté à la conférence OOPSLA en 1992 : livrer du code, c’est s’endetter ; une petite dette accélère le développement si elle est vite remboursée, et chaque minute passée sur un code « pas tout à fait juste » compte comme un intérêt.

Un exemple type : une règle de remise écrite en dur à trois endroits du logiciel. Le jour où elle change, il faut la retrouver trois fois, et la troisième est oubliée. Le raccourci n’a rien coûté à l’écriture ; il coûte à chaque modification.

Martin Fowler a précisé l’idée dans son quadrant de la dette technique : une dette peut être délibérée ou involontaire, prudente ou imprudente. Il en tire une conséquence utile à une PME : une dette prudente, logée dans une partie du code que l’on touche rarement, ne vaut pas forcément d’être remboursée si ses intérêts restent faibles. Les intérêts ne se paient que là où le logiciel évolue.

Ce n’est pas la même chose qu’un bug

Un bug est un défaut visible aujourd’hui : une facture fausse, un écran qui plante. La dette est le surcoût de la prochaine modification. Et un logiciel ancien qu’on ne modifie jamais ne paie presque pas d’intérêts, sauf ses mises à jour de sécurité.

🔦 Les signes qui ne trompent pas

Pas besoin d’ouvrir le code pour soupçonner une dette : elle se voit dans les devis, dans les incidents qui suivent chaque mise en ligne et dans les réponses du prestataire. Un voyant seul ne prouve rien ; deux ou trois allumés justifient une lecture du code par quelqu’un d’extérieur.

Le quatrième voyant touche à la sécurité. Le Top 10 OWASP 2025 consacre une catégorie aux composants logiciels : il demande de suivre la version de chaque composant, y compris ceux qu’ils embarquent, et de prévoir leur mise à jour pendant toute la vie de l’application.

Ce qui se dégrade sans alerte

Le sixième voyant, nous l’avons eu chez nous. Du 20 août au 20 septembre 2026, un module de Cockpit, notre logiciel de gestion interne, est resté en panne sans que personne le voie : la tâche planifiée qui l’alimentait répondait « ok: false » avec un code HTTP 200, celui d’une réponse réussie. Un code 500 aurait déclenché une alerte. Une supervision qui contrôle la réponse, et non le résultat, est une dette comme une autre.

📏 Comment mesurer sa dette technique : le protocole en quatre étapes

Mesurer la dette ne sert qu’à une chose : décider quoi rembourser. Voici le protocole que nous avons suivi sur notre propre outil en septembre 2026 ; il se refait sur n’importe quel logiciel, avec son prestataire, et sa première étape se tient depuis votre bureau.

Étape 1 : relever les symptômes, depuis votre bureau

Trois relevés parlent davantage à un dirigeant qu’un rapport d’analyse, et il peut les tenir lui-même : le montant et le délai des évolutions comparés aux premières, les régressions après chaque mise en ligne, le temps entre un signalement et sa correction. S’ils se dégradent, les intérêts montent. Notez aussi le symptôme tel que vos équipes le décrivent : le 20 septembre 2026, chez nous, c’était « Cockpit rame ».

Étape 2 : chronométrer le chemin du symptôme, avant de toucher au code

Le code de Cockpit avait tout d’une dette : 52 requêtes sans limite et 62 lectures select("*"), qui ramènent toutes les colonnes d’une table, sur une base de 77 Mo. Avant d’y toucher, nous avons mesuré où passait le temps.

La requête SQL s’exécutait en 0,3 ms ; le temps était dans le réseau, entre les fonctions du logiciel, hébergées à Dublin, et la base, à Falkenstein en Allemagne, à 1 300 km : 86 ms par aller-retour, 850 ms pour dix allers-retours en série, et une navigation qui enchaînait sept attentes en cascade.

Étape 3 : mesurer chaque remboursement avant de le payer

Borner les 52 requêtes et les 62 select("*") a été mesuré aussi : aucun gain, chantier écarté. La dette visible dans le code n’était pas celle qui coûtait ; le surcoût venait de la distance entre les fonctions et la base. Avant de payer un remboursement, demandez la mesure de son gain sur le chemin relevé à l’étape 2.

Étape 4 : corriger ce qui est sur le chemin, puis remesurer

Une fois les fonctions déplacées à Francfort, près de la base, l’aller-retour est tombé à 28 ms et la navigation est passée de sept attentes en cascade à trois. Remboursez la dette qui se trouve sur ce chemin, et celle-là seulement, puis refaites les mesures des étapes 1 et 2. Et surveillez le résultat, pas seulement la réponse : c’est la leçon de la panne d’un mois racontée plus haut.

Le ratio de dette des outils d’analyse : une tendance, pas une facture

Plusieurs guides présentent le ratio de dette technique, coût de correction divisé par coût de développement, parfois avec un seuil « sain » sous 5 %. Dans la documentation de SonarQube, outil d’analyse de code très répandu, le calcul se lit ainsi.

Le ratio rapporte donc un effort estimé à un coût fictif, pas à votre facture, et le « 5 % » est un réglage par défaut, pas une norme. Bien employé, il sert à suivre un même code dans le temps. Il ne dit ni ce que la dette vous coûte en euros, ni si elle vaut d’être remboursée. Et une partie de la dette n’est pas dans le code du tout.

🧠 La dette que les outils ne voient pas : le savoir d’une seule personne

Les réglages du serveur, les tâches qui tournent la nuit, les mots de passe, la façon de remettre le logiciel en route : rien de tout cela n’est dans le code, et aucun outil d’analyse ne le mesure. Tant que la personne qui le sait est là, personne ne le voit. Le jour où le développeur qui a tout construit s’en va, ou que le prestataire ferme, le code se récupère souvent ; ce savoir-là, beaucoup moins.

Les développeurs parlent de facteur d’autobus : le nombre de personnes dont le départ suffirait à bloquer un projet. Quand il vaut un, la dette est là, même dans un code impeccable. Elle se rembourse tant que la personne est joignable, par un entretien de passation noté par écrit : les sept questions à lui poser sont dans notre article sur le changement de prestataire informatique.

💶 Ce que coûte la dette technique, et ce qu’on ne sait pas chiffrer

Nous n’avons trouvé aucune étude publiée qui chiffre la dette technique d’une PME. Les chiffres qui circulent sont des totaux nationaux ou des enquêtes auprès de grandes directions informatiques : ils ne disent rien de votre logiciel, et nous n’en citons aucun.

Le coût qui compte est le vôtre, et il se lit dans vos devis : demandez que chacun chiffre sur une ligne distincte la remise en état de la zone touchée. Ne rien faire a aussi un prix, en trois postes : les intérêts payés à chaque évolution, les mises à jour repoussées qu’une faille ou une fin de support finit par imposer, et le savoir parti avec une personne, à reconstituer avant toute modification.

⚖️ Rembourser, reprendre ou réécrire

Trois chantiers sont possibles, et ils ne coûtent pas la même chose. L’ordre des questions compte : on ne décide pas de réécrire un logiciel dont on ne détient pas les clés.

Rembourser : quand ça suffit

Le chantier le moins visible, et souvent le plus rentable : sans budget à part ni gel des nouveautés, chaque évolution remet en état la zone qu’elle touche. Il suffit tant que le socle tient et que les clés sont chez vous.

Reprendre : changer de prestataire sans repartir de zéro

Quand le prestataire ne répond plus, ou que le développeur qui savait tout est parti, le premier chantier n’est pas le code. La reprise et maintenance d’un logiciel existant commence par les comptes transférés à votre nom, la documentation écrite et une sauvegarde restaurée une fois, avant de modifier la moindre ligne. La remise à niveau entre ensuite dans le devis, avant les évolutions.

Réécrire : le seul cas où c’est justifié

« Il faut tout refaire » est la réponse la plus lourde à une dette. Elle se justifie quand le socle ne peut plus porter ce que fait l’entreprise : un modèle de données qui ignore une notion devenue centrale, un cadre de développement abandonné. Même alors, la réécriture se mène par lots, avec une migration des données vérifiée et l’ancien logiciel en service jusqu’à la bascule : c’est la démarche d’un logiciel métier sur mesure, pas une copie de l’ancien. Pour un site, voyez les signes qu’une refonte s’impose.

🛡️ Ne pas en recréer : ce que le contrat doit prévoir

La dette se contracte surtout quand personne ne regarde : à la livraison. Cinq lignes dans un contrat ou un cahier des charges logiciel en évitent l’essentiel.

Sans la dernière ligne, le prestataire reste titulaire des droits sur le code écrit pour vous, et confier le logiciel à quelqu’un d’autre devient une négociation. Chez OTTOPILOTE, le code source est transféré à la livraison, une fois le projet réglé. Et la recette d’un logiciel métier est le bon moment pour vérifier ces cinq lignes, avant de signer le procès-verbal.

🎯 En résumé

Plusieurs voyants allumés, et vous ne savez plus qui détient les clés ? Commencez par faire relire votre logiciel : un relevé de ce qui bloque, de ce qui se corrige et de ce qui peut attendre, avant le moindre devis. Réponse humaine sous 24 h ouvrées, devis gratuit et plafonné.