On parle de dette technique quand un projet dérape, rarement avant. Pourtant, dans une application métier en production, l'essentiel de cette dette ne vient pas du code écrit par vos développeurs : il vient des briques tierces que ce code assemble. Voici comment la rendre visible, la chiffrer et la réduire sans lancer une réécriture.

La dette technique n'est pas là où on la cherche

La dette technique, c'est l'écart entre l'état réel de votre application et l'état qu'il faudrait pour la faire évoluer sereinement. Le réflexe habituel consiste à la chercher dans la qualité du code maison : cette part existe, mais elle est minoritaire.

Une application métier moderne est un assemblage. Le code spécifique à votre activité ne représente souvent qu'une fraction de ce qui tourne en production : le reste vient de bibliothèques, de cadres applicatifs et de connecteurs repris de l'écosystème open source. Selon le rapport OSSRA 2026 de Black Duck, publié le 27 août 2026, 98 % des bases de code auditées contiennent des composants open source. Votre dette technique est donc en grande partie une dette héritée, que vous n'avez ni écrite ni choisie ligne à ligne.

Cette distinction change tout : refactoriser du code maison est un arbitrage interne que l'on peut reporter, tandis que laisser vieillir des dépendances revient à accumuler un passif dont le calendrier est fixé par d'autres.

Ce que les chiffres de 2026 ont changé

Le même rapport documente une accélération nette. Le nombre moyen de vulnérabilités open source par base de code a plus que doublé en un an, avec une hausse de 107 %, pour atteindre une moyenne de 581 vulnérabilités. Le nombre de composants par base de code a progressé de 30 % sur la même période, et 87 % des bases auditées comportaient au moins une vulnérabilité.

Black Duck attribue une part de cette progression aux assistants de génération de code, qui accélèrent l'entrée de nouvelles dépendances dans les projets. Dernier point souvent ignoré : deux tiers des bases auditées présentent des conflits de licence, le taux le plus élevé relevé par ce rapport. La dette technique a donc aussi une dimension juridique, qui se révèle au pire moment, lors d'une cession.

Les quatre formes de dette dans une application métier

Pour arbitrer, il faut séparer ce que l'on met trop souvent dans le même sac.

  • La dette de version. Vos dépendances ont plusieurs versions majeures de retard. Chaque montée devient un chantier, parce qu'elle en cumule cinq.
  • La dette de socle. Le langage ou le moteur d'exécution arrive en fin de support. Node.js 20 n'est plus maintenu depuis le 30 avril 2026, PHP 8.2 arrive en fin de vie le 31 décembre 2026. Ces dates ne se négocient pas.
  • La dette de connaissance. La procédure de construction et de livraison tient dans la tête d'une seule personne, ou dans un poste de travail qu'il ne faut surtout pas réinstaller.
  • La dette de licence. Un composant a changé de licence entre deux versions, ou impose des obligations incompatibles avec votre usage.

Traiter la dette de socle est une obligation datée. Traiter la dette de version est un investissement qui réduit le coût de toutes les suivantes.

Mesurer avant de budgéter : l'inventaire des composants

On ne pilote pas ce que l'on ne voit pas. Le point de départ est un inventaire des composants, la nomenclature logicielle plus connue sous le nom de SBOM, généré automatiquement à chaque construction de l'application plutôt que rédigé à la main une fois par an. Ce document n'est plus seulement une bonne pratique : le règlement européen sur la cyberrésilience impose dans son annexe I, partie II, une nomenclature dans un format courant et lisible par machine, couvrant au minimum les dépendances de premier niveau, pour les produits mis sur le marché. Les formats normalisés CycloneDX et SPDX répondent à cette exigence, et les chaînes de construction courantes savent les produire sans développement spécifique.

Un inventaire utile tient en quatre colonnes : le composant et sa version, la version disponible, la date de fin de support annoncée, et le responsable de la montée. La quatrième est celle que l'on oublie, et c'est pourtant elle qui transforme une liste en plan d'action.

Le rythme de mise à jour qui tient dans la durée

La grande erreur de méthode consiste à traiter les mises à jour comme un projet exceptionnel, tous les trois ans, avec un budget à défendre. Ce rythme garantit que chaque montée sera douloureuse et risquée. Le bon modèle est l'inverse : une charge régulière, petite, inscrite au budget de fonctionnement, avec trois fenêtres distinctes. Les correctifs de sécurité sont appliqués sous un délai fixé à l'avance, en jours, sans attendre la prochaine livraison fonctionnelle. Les montées mineures sont regroupées mensuellement, en un lot que l'on peut relire et annuler d'un bloc. Les montées majeures sont planifiées, une ou deux par an, avec du temps de test dédié.

Ce rythme n'est tenable qu'à une condition : disposer d'un jeu de tests automatisés suffisant pour valider une montée de version sans recette manuelle complète. C'est le vrai prérequis, et souvent le premier investissement à consentir.

La chaîne d'approvisionnement logicielle est devenue un sujet en soi

Mettre à jour rapidement est nécessaire, mais mettre à jour aveuglément est devenu dangereux. Depuis septembre 2025, la campagne dite Shai-Hulud a compromis plus de 1 300 versions de paquets sur le registre npm, avec du code malveillant exécuté dès la phase d'installation, avant tout test ou contrôle, et destiné à dérober les jetons et clés présents dans l'environnement de construction. Microsoft a identifié le 11 mai 2026 une résurgence de cette campagne touchant plus de 170 paquets npm.

La réponse de l'écosystème a été rapide : les jetons dits classiques de npm ont été définitivement révoqués le 9 décembre 2025, les jetons granulaires sont désormais plafonnés à 90 jours et exigent une double authentification. Votre chaîne de construction peut donc s'arrêter du jour au lendemain si elle repose encore sur un jeton de longue durée.

Quatre gestes limitent l'exposition sans ralentir les équipes : figer les versions exactes dans un fichier de verrouillage versionné, désactiver l'exécution automatique des scripts d'installation, s'imposer un délai de quarantaine avant d'adopter une version tout juste publiée, et faire tourner la chaîne de construction sous une identité applicative dédiée.

Trois indicateurs et cinq erreurs fréquentes

Trois mesures suffisent à suivre la dette technique en comité de direction : le retard médian de vos dépendances exprimé en versions majeures, le délai médian de correction d'une vulnérabilité qualifiée de critique, et le nombre de composants sans mainteneur actif depuis douze mois. Ces trois nombres se calculent à partir de l'inventaire.

Les erreurs les plus fréquentes : lancer un grand chantier trois semaines avant une échéance réglementaire ; ne traiter la dette qu'après une panne ; confondre l'audit du code maison et l'inventaire des composants tiers, qui ne répondent pas à la même question ; laisser le prestataire seul détenteur des comptes et des secrets de la chaîne de construction ; produire des rapports de 400 alertes sans jamais décider lesquelles sont exploitables. Un outil qui alerte sans priorisation ne réduit pas la dette, il la rend seulement visible.

Réduire la dette technique n'est presque jamais un argument pour tout réécrire. Si le sujet se pose vraiment, la modernisation progressive reste préférable à la table rase, et elle commence de toute façon par le même inventaire.

Questions fréquentes

Qu'est-ce que la dette technique, concrètement ?

C'est l'écart entre l'état actuel d'une application et l'état qui permettrait de la faire évoluer sans surcoût ni risque. Elle se matérialise par des dépendances en retard, un socle en fin de support, une documentation absente ou des licences incompatibles.

Comment chiffrer la dette technique de mon application ?

Partez de l'inventaire, puis estimez la charge de remise à niveau dépendance par dépendance, en distinguant les montées obligatoires des montées souhaitables. Le chiffrage devient exploitable quand il est comparé au coût d'un arrêt de service.

Faut-il un SBOM si mon application est purement interne ?

L'obligation du règlement sur la cyberrésilience vise les produits mis sur le marché, pas les applications développées pour votre seul usage. L'inventaire reste l'outil le plus rentable pour savoir en quelques minutes si une vulnérabilité annoncée vous concerne.

Comment savoir si j'ai été touché par une compromission de paquet ?

Deux questions suffisent : quelles versions exactes étaient présentes dans vos constructions à la date concernée, et quels secrets étaient accessibles depuis cet environnement. Sans inventaire versionné ni journal de construction, on ne peut pas répondre.

Mise à jour ou réécriture : comment trancher ?

La réécriture ne se justifie que si la remise à niveau coûte plus cher que la reconstruction, ou si le besoin métier a changé. Sinon, une trajectoire de mises à jour étalée sur douze mois coûte moins cher et concentre moins de risque.

Vous ne savez pas dans quel état sont les dépendances de votre application métier ? Nous réalisons l'inventaire, chiffrons la remise à niveau et vous proposons un rythme de mise à jour tenable. Parlons de votre projet.