Dette technique logicielle le vrai coût caché de l'inaction

En bref. La dette technique est l'écart entre l'état d'une application et ce qu'il faudrait pour continuer à la faire évoluer à coût normal. Elle n'apparaît dans aucun compte mais se paie en jours de développement, en délais et en incidents. Trois mesures suffisent à la chiffrer sans audit externe : la part des jours passés à contourner l'existant, l'évolution du délai entre demande métier et mise en production, et le nombre de composants qui ne reçoivent plus de correctif de sécurité. Traitée par tranches sur le budget courant, elle coûte moins cher que reprise en urgence lors d'une mise en conformité.

Quand une application métier commence à coûter cher à faire évoluer, personne ne sait dire depuis quand. Aucune alerte, aucune ligne sur un bilan. Juste un jour où l'équipe annonce que la prochaine évolution prendra cinq mois, alors que six mois plus tôt elle en aurait pris deux.

Ce ralentissement porte un nom : la dette technique. Elle se paie sur chaque déploiement, sur chaque évolution et sur les premiers mois de chaque développeur qui arrive et doit déchiffrer le code avant de produire. Comme elle ne figure dans aucun compte, elle est difficile à défendre en CODIR.

Le vrai coût, c'est le ralentissement

Avant chaque évolution, il faut comprendre du code écrit par quelqu'un d'autre, trois ans plus tôt, sans documentation, sur une version de framework que personne ne maintient plus. Chaque ajout demande du temps pour contourner l'existant au lieu d'avancer sur ce qui est demandé. Les développeurs ne s'en plaignent pas toujours, parce que ça ressemble à du travail normal.

Une bonne équipe sur un socle dégradé livre lentement, et ça n'a rien à voir avec son niveau. Côté DAF, on voit des délais qui glissent et des devis qui montent, sans ligne comptable qui porte le nom du problème. Au bout de quelques années, la dette coûte plus cher que les nouvelles fonctionnalités.

L'ordre de grandeur se mesure en temps humain. Dans l'industrie, une intervention manuelle imposée par un logiciel dépassé peut représenter jusqu'à 150 000 euros par an de temps perdu pour une équipe de dix techniciens, un calcul que nous détaillons dans notre intervention sur l'obsolescence numérique et son coût pour la croissance, publiée par Le Figaro.

Trois chiffres qu'un DAF peut obtenir cette semaine

Aucun des trois ne demande d'audit technique. Ils suffisent à sortir la discussion du registre de l'opinion.

La part du budget de développement qui sert à contourner l'existant. Reprenez vos trois derniers chantiers et demandez à l'équipe de répartir les jours consommés entre deux colonnes : ce qui a produit une fonctionnalité visible par un utilisateur, et ce qui a servi à travailler malgré le code en place. Pas une estimation au doigt mouillé, une répartition sur des projets réels. Au-delà de 30 %, la dette est devenue votre principal poste d'investissement sans que personne l'ait décidé.

Le délai entre la demande métier et la mise en production. Mesurez-le sur les dix dernières demandes, de la date d'arbitrage à la date de livraison. C'est le chiffre que vos directions métier ressentent sans qu'on le leur explique. S'il a doublé en dix-huit mois à effectif constant, le problème est dans le socle et pas dans l'équipe.

Le nombre de composants hors support. Framework, bibliothèques, version du système sur le serveur : combien ne reçoivent plus de correctif de sécurité de leur éditeur ? La réponse s'obtient en une demi-journée et elle est publique. Chaque composant hors support est à la fois un risque de sécurité et une marche supplémentaire à franchir le jour de la migration.

Quand un correctif de trois semaines devient un chantier de fond

Un opérateur de services aux salariés nous a sollicités pour ce qui semblait être une mise à jour de conformité sur son application mobile, utilisée quotidiennement par des dizaines de milliers d'adhérents. L'estimation initiale : deux à trois semaines.

Le diagnostic a donné autre chose. Le système d'authentification avait été construit pour répondre aux exigences de son époque et n'avait pas été significativement retouché depuis, alors que les stores mobiles avaient durci entre-temps leurs critères sur les bibliothèques de chiffrement. Le correctif ciblé est devenu un chantier de socle.

Ce n'est pas la décision d'aller vite au départ qui a posé problème. C'est l'accumulation : des dépendances non mises à jour, un SDK tiers abandonné par son éditeur, des choix pragmatiques jamais réexaminés. Des décisions raisonnables à l'époque, qui forment un blocage précisément au moment où on n'a plus le temps de les traiter.

La migration a été menée et le socle stabilisé. Le chantier n'aurait pas eu cette ampleur si la dette avait été absorbée au fil des évolutions.

Réduire la dette au bon moment, pas n'importe comment

Le grand projet de réécriture finit dans le mur plus souvent qu'il n'aboutit. L'intention n'est pas en cause : une refonte totale demande d'arrêter le compteur, et peu d'équipes ont ce luxe. En général elle prend deux fois plus de temps qu'annoncé et réintroduit de la dette sous une autre forme. Il arrive qu'on recommande quand même de repartir de zéro, quand le code en place est trop dégradé pour être sauvé, mais c'est l'exception et non la règle.

Le traitement par tranches donne de meilleurs résultats. On cible ce qui bloque les évolutions déjà prévues au planning, pas ce qu'on aimerait améliorer en théorie, et on laisse tranquille le code qui fait son travail. Chaque tranche se chiffre et se planifie comme une évolution ordinaire, donc elle passe sur le budget courant au lieu de remonter en comité.

Une application de scan de billets événementiels illustre le principe. Reprise en maintenance après plusieurs cycles sans intervention, elle avait accumulé des couches laissées en place release après release. Le rattrapage a été étalé sur quatre cycles d'évolutions, sans arrêt de service. Le résultat, mesuré sur plusieurs semaines de production normale : +30 % de rapidité de scan et -50 % de temps de traitement, sans toucher aux algorithmes métier.

Décider tôt coûte moins cher que décider sous contrainte

Un éditeur gérant plusieurs applications mobiles liées a tranché en amont. Plutôt que de repartir de zéro à chaque nouvelle application, une base technique commune a été construite à partir de la première. Le cadrage, comprendre les contraintes métier partagées avant d'écrire la première ligne, a compté autant que le travail de code qui a suivi. Les applications suivantes se sont appuyées sur ce socle : une correction profite aux trois plateformes à la fois, sans chantier d'urgence entre deux versions.

Dans les deux cas, les équipes étaient compétentes. Ce qui a changé, c'est le moment où la question est arrivée sur la table : pour l'opérateur de services, sous la pression d'une date de conformité ; pour cet éditeur, pendant la construction de sa première application, quand poser une base commune ne coûtait presque rien.

Ce que ça change pour le DAF

Toute entreprise qui exploite une application depuis plus de trois ans porte de la dette technique, y compris quand le logiciel tourne correctement. Elle finira par arriver au budget. Soit vous l'y mettez vous-même, étalée en tranches que vous arbitrez ; soit elle y arrive seule, le jour où une mise en conformité vous impose un chantier que vous n'avez pas provisionné.

Une application métier se déprécie comme un véhicule : sans entretien, la facture de remise en état arrive d'un coup. Chaque année sans traitement rend la reprise plus lourde, les incidents plus fréquents et les délais plus difficiles à tenir. Reprenez les trois mesures du début, vous saurez où vous en êtes.

Questions fréquentes

Qu'est-ce que la dette technique en gestion ?

C'est l'écart entre l'état d'une application et l'état qu'elle devrait avoir pour continuer à évoluer à coût normal. Elle ne se lit pas au bilan mais se paie en jours de développement, en délais de livraison et en incidents. Elle vient de choix rationnels à court terme que personne n'a réexaminés ensuite.

Comment chiffrer la dette technique de son application ?

Trois indicateurs suffisent pour commencer : la part des jours de développement consacrée à contourner l'existant sur vos derniers projets, l'évolution du délai entre demande métier et mise en production, et le nombre de composants qui ne reçoivent plus de correctif de sécurité. Les trois s'obtiennent sans audit externe.

Faut-il réécrire une application qui a trop de dette technique ?

Rarement. La réécriture complète dépasse presque toujours son budget et réintroduit de la dette ailleurs. Le traitement par tranches, ciblé sur ce qui bloque les évolutions prévues, donne des résultats mesurables sans arrêter le service. La réécriture se justifie quand le code en place ne permet plus de livrer en sécurité.

Comment justifier un budget de dette technique en CODIR ?

Avec les trois mesures ci-dessus, rapportées à des projets réels de l'entreprise plutôt qu'à des moyennes de marché. Un comité refuse un budget de « refactoring » et accepte une ligne qui dit : 40 % de nos jours de développement passent à contourner l'existant, voici les trois tranches qui ramènent ce chiffre sous 15 %, voici leur coût et leur calendrier.

À quel moment traiter la dette technique ?

Pendant que l'application fonctionne encore. Une dette traitée au fil des évolutions se finance sur le budget courant. La même dette traitée sous contrainte, à l'occasion d'une mise en conformité ou d'un incident, devient un projet imprévu à arbitrer en urgence.

Qui doit porter le sujet dans l'entreprise ?

La direction financière, avec la direction technique. La cause est technique, la facture est financière. Tant que le sujet reste côté technique, il vit dans un backlog que personne ne finance. Porté par le DAF, il devient une ligne d'investissement avec un calendrier.

Si vos applications métier coûtent de plus en plus cher à faire évoluer sans que vous puissiez dire pourquoi, on peut faire un premier état des lieux en 30 minutes. Pas de présentation commerciale, pas d'engagement : une lecture de votre situation et des options disponibles. Contactez-nous.

Connexia développe et maintient des applications métier sur mesure depuis la Saône-et-Loire, pour des PME et ETI d'Auvergne-Rhône-Alpes et de toute la France. Nos interventions couvrent la reprise d'applications web existantes, le maintien en condition opérationnelle et l'infrastructure de déploiement.