Une évaluation de la dette technique permet de transformer le sentiment selon lequel « nous ralentissons » en données concrètes sur lesquelles le comité de direction peut s'appuyer pour agir : quelle dette vous fait perdre en rapidité de livraison, laquelle génère des risques, et laquelle peut être laissée telle quelle sans danger. La plupart des équipes savent qu’elles ont une dette. Dans l’enquête Stack Overflow 2024 auprès des développeurs, la dernière édition à avoir posé la question aux développeurs, le « montant de la dette technique » était la frustration la plus souvent citée par les professionnels, mentionnée par 62,4 % des personnes interrogées, les contributeurs individuels et les responsables étant presque parfaitement d’accord sur ce point. La difficulté principale pour la plupart des équipes réside dans la compréhension du coût réel de cette dette et dans la décision de savoir par où commencer. Cet article propose un cadre permettant de combler ce fossé : mettre en évidence la dette dans l’ensemble de votre système, la quantifier par rapport aux indicateurs déjà suivis par l’entreprise, et établir des priorités en fonction du coût, et non de ce qui dérange un ingénieur.
Il s’adresse au directeur technique, au responsable d’ingénierie ou au fondateur technique qui gère un système de production existant, constate que les livraisons deviennent plus lentes et plus coûteuses, et doit défendre un plan de réduction de la dette auprès de personnes qui ne lisent pas le code. L’approche est délibérément indépendante des fournisseurs, ce qui vous permet de la mettre en œuvre avec n’importe quelle équipe d’ingénieurs connaissant déjà le système. Elle repose également sur un postulat honnête : certaines dettes constituent un choix rationnel, et l’objectif d’une évaluation est la gouvernance, et non un solde nul.
À retenir
- La dette technique est un travail différé qui achète de la vitesse de livraison aujourd'hui au prix d'un coût plus tard, et une partie est un compromis délibéré et sensé.
- Une évaluation suit trois étapes : recenser la dette, la quantifier au regard de signaux que l'entreprise mesure déjà, et la prioriser selon le coût et le risque.
- Mesurez le coût, pas le code. Les lignes, le pourcentage de couverture et un score unique décrivent le code, tandis que le délai de livraison, le taux d'échec des changements et l'âge des dépendances décrivent le coût.
- Remboursez en priorité la dette à fort intérêt dans le code que vous modifiez activement. Laissez tranquille la dette à faible intérêt, logée là où personne n'a touché au code depuis un an.
Ce qu'est vraiment la dette technique
La dette technique est un travail d'ingénierie différé qui achète de la vitesse de livraison aujourd'hui au prix d'un changement plus lent ou plus risqué demain. La métaphore vient de Ward Cunningham : livrer du code qui n'est pas tout à fait juste revient à emprunter de l'argent. Vous avancez plus vite aujourd'hui, et vous payez des intérêts sur chaque changement futur jusqu'à rembourser le principal en faisant le travail correctement. Le principal, c'est l'effort pour ramener une partie du système à un niveau maintenable. Les intérêts, c'est la taxe récurrente que paie chaque fonctionnalité ultérieure parce que ce travail a été sauté.
Le mot « dette » évoque l'échec aux yeux d'un conseil d'administration ; il est donc utile de le recadrer en termes de financement. S'endetter peut être la bonne décision. Le quadrant de la dette technique de Martin Fowler classe la dette selon deux axes : délibérée ou involontaire, et prudente ou imprudente. Le cas « délibéré et prudent » (lancer volontairement une conception plus simple pour saisir une opportunité de marché, avec l’intention de la revoir ultérieurement) constitue une stratégie commerciale légitime. Le problème ne réside pas dans la dette technique en soi, mais dans la dette qui n’est ni délibérée ni maîtrisée et qui s’accumule discrètement au fil du temps.
Un point de référence aide à nommer l'écart. La norme internationale ISO/IEC 25010:2023 définit la maintenabilité du logiciel à travers cinq propriétés : modularité, réutilisabilité, analysabilité, modifiabilité et testabilité. Un code maintenable, en clair, est un code qu'un nouveau développeur peut comprendre et modifier sans crainte. La dette technique est la distance entre le système que vous avez et ce point de référence, mesurée là où elle vous coûte vraiment.
Pourquoi la dette technique est difficile à voir
La dette n'apparaît jamais sur une feuille de route, et c'est pour cela qu'elle est facile à sous-financer. Elle se manifeste dans la pente de la livraison : le même type de changement qui prenait trois jours l'an dernier en prend maintenant deux semaines, et personne ne peut désigner la ligne de code responsable. Quand le symptôme devient indéniable, les intérêts s'accumulent depuis des mois.
La réaction courante consiste à se tourner vers une métrique de code. Les équipes comptent les lignes, suivent la couverture de tests, ou achètent un outil qui affiche un unique « ratio de dette technique », un pourcentage censé résumer la santé de tout le système. Ces chiffres ont l'air objectifs, et ce sont les mauvaises cibles. Une couverture de 90 % sur un module que personne ne modifie ne vous apprend rien d'utile, alors que la partie du système que vous touchez chaque semaine n'a peut-être aucun test. Un score composite unique masque quelle dette est coûteuse et laquelle est inoffensive, et il pousse les équipes à optimiser le chiffre plutôt que le résultat. La vraie question n'est pas combien de dette existe dans l'absolu, mais combien elle vous facture sur le travail que vous faites réellement.
L'intuition et le signal
Une évaluation fonctionne en traduisant ce que ressent un CTO en signaux que la direction peut lire. Chaque symptôme ci-dessous repose sur une mesure observable, et chacun pointe vers l'un des six endroits où la dette se loge.
| Ce que vous ressentez | Le signal observable | Où loge la dette |
|---|---|---|
| « Les livraisons glissent sans cesse » | Le délai de livraison d'un changement typique augmente d'année en année | Code, architecture |
| « Chaque changement semble risqué » | Le taux d'échec des changements et le temps de rétablissement grimpent | Tests |
| « Une petite fonctionnalité touche à tout » | Un seul changement s'étend sur plusieurs services ou équipes | Architecture |
| « On éteint plus d'incendies qu'on ne construit » | Part du temps d'ingénierie passée sur le travail non planifié et les incidents | Infrastructure et exploitation |
| « Une mise à niveau forcée approche » | Composants en fin de vie, nombre de vulnérabilités connues | Dépendances et fin de vie |
| « Une seule personne comprend ça » | Temps d'intégration jusqu'à un changement sûr, concentration de la propriété | Connaissance et bus factor |
Étape 1 : recenser
Recenser la dette commence par un inventaire de l'endroit où elle se trouve. Les outils d'analyse statique ont un rôle, mais ils sont un plancher, pas la réponse. Ils repèrent la duplication et la complexité dans le code, et ils sont totalement aveugles à la dette d'architecture, de connaissance et d'exploitation. La source la plus riche, ce sont les développeurs eux-mêmes, capables de vous dire en un après-midi quelles parties du système ils redoutent de toucher, et pourquoi. La dette se regroupe en six catégories reconnaissables.
- Dette de code : duplication, code mort et modules enchevêtrés que tout le monde a peur de modifier. C'est l'écart par rapport aux propriétés de maintenabilité d'ISO/IEC 25010 vues plus haut.
- Dette d'architecture : des choix de structure qui ne correspondent plus à la charge ou à la feuille de route, comme de mauvaises frontières entre services, une base de données partagée que deux équipes se disputent, ou un couplage qui transforme une fonctionnalité en projet multi-équipes.
- Dette de dépendances et de fin de vie : frameworks et bibliothèques en retard de plusieurs années, paquets qui ne sont plus maintenus, un runtime ou un système d'exploitation au-delà de sa durée de support et filant vers une mise à niveau forcée.
- Dette de tests : tests manquants, lents ou instables, et la faible confiance au moment de livrer qui s'ensuit, ce qui ramène les équipes vers des tests de non-régression manuels.
- Dette d'infrastructure et d'exploitation : déploiements manuels, serveurs que personne ne sait reproduire, absence d'infrastructure as code, et supervision manquante qui vous laisse aveugle jusqu'à ce qu'un client signale la panne.
- Dette de connaissance et de bus factor : systèmes non documentés et sous-systèmes à propriétaire unique, où la livraison se bloque dès qu'un développeur est absent.
Le résultat de cette étape est une liste simple, groupée par catégorie, des parties du système qui portent de la dette, avec une note d'une ligne sur la façon dont chacune fait mal. Rien n'est encore noté à ce stade, car il s'agit seulement de dessiner la carte.
Étape 2 : quantifier
Quantifier la dette revient à associer à chaque élément de la carte un chiffre que l'entreprise comprend déjà ou qu'elle peut commencer à mesurer. Pour aborder cette étape de manière honnête, il faut s'appuyer sur un ensemble de signaux opérationnels réels et éviter de les regrouper en un seul indice inventé. Un comité de direction ne prend pas de décision sur la base d'affirmations telles que « le code est désordonné », mais plutôt sur la base de données telles que « le délai de mise en œuvre d'une modification type a doublé en douze mois ».
Pour le coût de livraison, les signaux les plus établis sont les métriques de livraison logicielle DORA, maintenues par le programme de recherche DORA chez Google Cloud. Trois d'entre elles mesurent le débit (délai de livraison des changements, fréquence de déploiement, temps de rétablissement après un déploiement en échec) et deux l'instabilité (taux d'échec des changements, taux de reprise des déploiements) : ensemble, elles disent à quelle vitesse vous livrez et avec quelle sûreté. Suivies dans le temps, elles transforment « on se sent plus lents » en une courbe de tendance. Ajoutez-y la part du temps d'ingénierie consacrée au travail non planifié et aux reprises, l'expression la plus claire des intérêts payés, et la fréquence des incidents dans les zones que votre inventaire a signalées.
Pour la dette de dépendances et de fin de vie, le risque est concret et dénombrable. Le rapport Open Source Security and Risk Analysis 2026 de Black Duck a constaté que 92 % des bases de code contenaient des composants en retard de quatre ans ou plus, et que 87 % contenaient une vulnérabilité connue. La communauté de la sécurité a relevé le rang de ce risque. Dans le Top 10 de l'OWASP édition 2025, l'ancienne catégorie « Composants vulnérables et obsolètes » a été élargie en A03, « Défaillances de la chaîne d'approvisionnement logicielle », qui arrive en troisième position, la moitié des praticiens interrogés la plaçant même en tête. Le signal, ici, est un décompte : combien de vos dépendances sont en fin de vie, non maintenues, ou porteuses d'une vulnérabilité publiée. Une plateforme qui atteint sa fin de vie en est la forme la plus tranchante, et notre guide sur la migration depuis Drupal 10 déroule un cas actuel.
Pour la dette de connaissance, deux mesures fonctionnent bien : le temps qu'il faut à une nouvelle recrue pour livrer un changement sûr en production, et le degré de concentration de l'historique des commits et de la propriété sur une seule personne. Toutes deux convertissent le « savoir tribal » en quelque chose que la direction peut voir.
Une mise en garde tient cette étape ensemble. Ce sont des indicateurs directionnels, pas un chiffre précis, et les présenter comme exacts répéterait l'erreur du score de dette unique. Leur rôle est de rendre la dette lisible et comparable, pour que la direction puisse la mettre en balance avec tout ce qui se dispute le même budget.
Étape 3 : prioriser
Une fois la dette recensée et quantifiée, la priorisation est une question de taux d'intérêt, pas de propreté. L'objectif n'est pas d'éliminer la dette, mais d'identifier les dettes qui facturent les intérêts les plus élevés et de refinancer celles-là en premier.
La dette technique la plus coûteuse se trouve au cœur du développement actif et sur le chemin critique : le code que votre équipe modifie chaque semaine, le service par lequel chaque fonctionnalité doit passer, la dépendance dont la mise à jour obligatoire est prévue dans quelques mois plutôt que dans plusieurs années. Cette dette est constamment mise à rude épreuve, son remboursement est donc rapidement rentable. La dette à faible taux d’intérêt se trouve dans les recoins du système que personne ne touche. Un module mal structuré qui n’a pas changé depuis deux ans et qui se cache derrière une interface stable ne vous coûte probablement que très peu, et le réécrire uniquement par souci d’élégance constitue en soi une forme de gaspillage.
Cela règle aussi la question du remboursement. Un gel complet des fonctionnalités pour rembourser toute la dette n'est presque jamais la bonne décision. Il fige l'entreprise, et sans priorisation une équipe ne peut pas dire quand le travail est « terminé », si bien que le gel s'éternise. Le modèle durable consiste à allouer une part régulière de la capacité, souvent exprimée en pourcentage de chaque cycle, aux éléments au coût et au risque les plus élevés, et à rembourser de façon incrémentale pendant que l'entreprise continue de livrer. Les grandes réécritures méritent une méfiance particulière. Elles jettent un savoir durement acquis, s'étirent en longueur, et tendent à reproduire la dette d'origine en plus d'une dette neuve bien à elles. Une refactorisation incrémentale des zones à plus fort intérêt l'emporte presque toujours sur une réécriture intégrale.
Dette technique et développement assisté par IA
Il y a une raison plus récente de prendre une évaluation au sérieux : votre niveau de dette devient un filtre sur la sûreté avec laquelle vous pouvez adopter le développement assisté par IA. Les assistants de code fonctionnent mieux sur des systèmes bien structurés, documentés et couverts par des tests, parce que ce sont ceux où un changement généré peut être vérifié vite et avec confiance. C'est à peu de chose près le constat central du rapport DORA de septembre 2025, qui a interrogé près de 5 000 professionnels de la technologie et conclut que l'IA ne répare pas une équipe mais amplifie ce qui s'y trouve déjà : les équipes solides se renforcent, celles qui peinent voient leurs problèmes existants s'intensifier. Le même rapport associe l'adoption de l'IA à un débit de livraison plus élevé, inversant la relation négative mesurée en 2024, tandis que la relation négative avec la stabilité de livraison se maintient, et il enregistre 30 % de développeurs déclarant peu ou pas de confiance dans le code généré par IA.
Les mesures faites au niveau du code vont dans le même sens. L'analyse par GitClear de 623 millions de modifications de code entre 2023 et 2026 (chiffres 2026 arrêtés en cours d'année) relève des blocs dupliqués en hausse de 81 %, du copier-coller au sein d'un même commit en hausse de 41 % et des constructions masquant les erreurs en hausse de 47 %, pendant que les déplacements de lignes liés à la refactorisation chutent de 70 % et la maintenance de code existant de 74 %. Les données sont corrélationnelles et proviennent d'un éditeur d'analyse de code : c'est une tendance à surveiller, pas une preuve que l'IA cause la dette. En pratique, rembourser la dette structurelle et de tests est désormais un prérequis pour tirer de la valeur des outils d'IA, pas un projet à part.
Questions fréquentes
Qu'est-ce qu'une évaluation de la dette technique ?
Une évaluation de la dette technique est une revue structurée qui recense où vit le travail d'ingénierie différé dans un système, quantifie son coût continu au regard de signaux observables de livraison et de risque, et le classe pour que la direction puisse décider quoi rembourser et quand. Elle regarde l'ensemble du système dans le temps plutôt qu'un changement isolé, et son résultat est un plan de remboursement priorisé et lisible par la direction.
Comment mesure-t-on la dette technique ?
Pas par les lignes de code, la couverture de tests ou un score composite unique, qui mesurent le code plutôt que son coût. Mesurez-la par les intérêts qu'elle facture. Des métriques de livraison comme le délai de livraison, la fréquence de déploiement, le taux d'échec des changements et le temps de rétablissement montrent comment la vitesse et la stabilité évoluent. Ajoutez-y la part du temps d'ingénierie perdue en travail non planifié, l'âge de vos dépendances et leurs vulnérabilités connues, et le temps qu'il faut à une nouvelle recrue pour livrer en toute sûreté. Suivez ces signaux sur les parties du système que vous modifiez vraiment.
Quel niveau de dette technique est acceptable ?
Il n'y a pas de cible à zéro, et viser zéro signifie généralement de la sur-ingénierie et des délais manqués. Une dette acceptable est une dette que vous avez prise délibérément, que vous pouvez expliquer, et dont les intérêts n'étranglent pas la livraison et ne créent pas de risque inacceptable. Le chiffre qui compte est la tendance, pas le solde : une dette qui croît plus vite que vous ne la remboursez est le signal d'alarme.
Faut-il suspendre les fonctionnalités pour corriger la dette technique ?
Presque jamais par un gel complet. Un arrêt dédié uniquement à la dette fige l'entreprise et se termine rarement proprement. Allouez une part régulière de chaque cycle aux éléments au coût et au risque les plus élevés et remboursez de façon incrémentale, pour que l'entreprise continue de livrer pendant que le taux d'intérêt baisse.
En quoi une évaluation de la dette technique diffère-t-elle d'une revue de code ?
Une revue de code vérifie un changement précis par rapport à des standards, ligne par ligne. Une évaluation de la dette technique regarde l'ensemble du système dans le temps, relie ses constats au coût et au risque pour l'entreprise, et produit un plan priorisé qu'une direction non technique peut appliquer. L'une est tactique et locale, l'autre stratégique.
D'une intuition à un chiffre que vous pouvez défendre
Une évaluation ne fait pas disparaître la dette technique, et ce n'est d'ailleurs pas son objectif. Elle remplace des inquiétudes vagues par une liste classée des dettes qui vous coûtent le plus cher, exprimée à l'aide d'indicateurs auxquels votre conseil d'administration accorde déjà sa confiance, afin que la prochaine discussion budgétaire s'appuie sur des données concrètes plutôt que sur l'intuition. Notre cadre pour cadrer et défendre un budget de plateforme web montre comment apporter cette liste à la discussion. La même discipline d'évaluation honnête d'un système est celle qu'applique un audit de plateforme avant de vous engager sur un CMS. Votre niveau de dette décide aussi de la sûreté avec laquelle vous adoptez les outils d'IA, le sujet de notre guide sur les sites prêts pour les agents IA. Si vous voulez un regard indépendant sur ce que votre système vous coûte réellement et sur ce qu'il faut rembourser d'abord, notre service de conseil et accompagnement est fait pour cela. Pour en discuter, contactez-nous.
Keroberos est un cabinet de conseil en technologies web qui accompagne les entreprises dans le choix de leur plateforme, livre des projets WordPress et Drupal, et fournit des prestations en régie pour les équipes de développement. Pour échanger sur votre dette technique et la santé de votre plateforme, contactez-nous.