Dette technique : définition, principes et solutions

La dette technique est l'une des rares métaphores informatiques qui parle immédiatement à une direction générale, et c'est précisément ce qui en fait un outil utile. Elle décrit une situation banale : pour livrer plus vite, on retient une solution que l'on sait imparfaite, et l'on accepte que les modifications suivantes coûtent un peu plus cher. Le raccourci d'aujourd'hui se paie en temps de développement demain, exactement comme un emprunt se paie en intérêts. Le problème n'est presque jamais l'emprunt lui-même, qui relève d'un arbitrage légitime, mais l'absence de trace de cet emprunt et l'accumulation silencieuse des intérêts jusqu'au jour où plus rien ne bouge sans casser autre chose. Nous précisons ici ce que recouvre exactement cette notion, où elle se loge sur un site web, comment la mesurer et par quels moyens la ramener à un niveau supportable.

Ce que recouvre la notion

La métaphore est employée à tort et à travers, souvent comme un synonyme poli de mauvais code, ce qui lui fait perdre l'essentiel de son intérêt.

L'origine de la métaphore

Elle vient de Ward Cunningham, qui l'a formulée lors d'un retour d'expérience présenté en 1992 devant une conférence de développeurs. Son propos n'était pas de désigner du travail bâclé mais de décrire une pratique délibérée : livrer une première version avec une compréhension encore incomplète du domaine, puis rembourser en réécrivant à mesure que cette compréhension progresse. La dette était donc au départ un outil de pilotage, pas une accusation. Cette nuance a été largement perdue, au point que le terme sert aujourd'hui à qualifier n'importe quel morceau de code que l'on n'aime pas, ce qui le rend inutilisable dans une discussion budgétaire.

Emprunter n'est pas une faute

Une entreprise qui doit être présente sur un salon dans six semaines a de bonnes raisons de livrer une version simplifiée, quitte à reprendre le travail ensuite. Le raccourci lui achète du temps commercial, ce qui a une valeur réelle et souvent supérieure au surcoût technique. Refuser par principe tout compromis produit des projets qui ne sortent jamais, ce qui est une façon plus coûteuse encore de perdre. La question pertinente n'est donc pas de savoir si l'on emprunte, mais si l'on sait qu'on emprunte, combien, et quand on compte rembourser. Ces trois informations distinguent un arbitrage d'une négligence.

Le principal et les intérêts

Le principal est le travail nécessaire pour remettre les choses en état, par exemple réécrire proprement une fonctionnalité assemblée dans l'urgence. Les intérêts sont le surcoût payé à chaque intervention tant que ce travail n'est pas fait : le temps supplémentaire pour comprendre, les précautions à prendre, les régressions à corriger. Cette distinction est capitale parce qu'elle explique pourquoi une dette modeste sur une zone très active coûte bien plus qu'une dette importante sur une zone que personne ne touche. Le taux d'intérêt dépend de la fréquence de modification, pas de la laideur du code.

Dette délibérée et dette subie

Martin Fowler a proposé de classer la dette selon deux axes : est-elle assumée ou accidentelle, et prise avec prudence ou avec insouciance. Une dette délibérée et prudente relève du pilotage sain. Une dette accidentelle et prudente est le lot normal d'un projet dont la compréhension évolue. Une dette insouciante, qu'elle soit voulue ou non, signale un problème de compétence ou de gouvernance. Ce classement en quatre cas rend la conversation possible avec des interlocuteurs non techniques, parce qu'il déplace le sujet du jugement sur les personnes vers la qualité de la décision.

Ce qui n'en relève pas

Un défaut de fonctionnement n'est pas de la dette technique, c'est un défaut, et il se corrige. Une fonctionnalité manquante n'en est pas non plus. Un code écrit dans un style que l'on n'apprécie pas mais qui fonctionne, se lit et se modifie sans difficulté particulière ne constitue pas une dette, seulement une préférence. Ranger ces trois situations sous le même mot dilue la notion et fournit un argument commode pour réclamer une réécriture générale. La dette désigne strictement l'écart entre l'état actuel et un état qui rendrait les évolutions futures moins coûteuses.

Pourquoi le vocabulaire compte

Une équipe technique qui demande du temps pour améliorer la qualité obtient rarement gain de cause. La même équipe qui présente un montant de dette, un taux d'intérêt observé et un plan de remboursement chiffré parle un langage que la direction traite tous les jours. Ce déplacement n'est pas une astuce de communication, il oblige à quantifier ce qui restait une impression. Il impose aussi de renoncer aux demandes vagues, puisqu'une dette qui ne se chiffre ni en jours ni en surcoût observé n'a probablement pas été analysée sérieusement.

Où elle s'accumule sur un site web

Un site n'est pas un logiciel comme un autre : sa dette se loge autant dans son contenu et sa configuration que dans son code.

Les dépendances non mises à jour

Chaque version de retard sur un langage, une base de données ou une bibliothèque augmente le coût de la mise à jour suivante, et ce coût ne croît pas linéairement. Passer deux versions majeures d'un coup demande souvent plus de travail que les deux migrations menées séparément, parce que les changements incompatibles s'additionnent et que la documentation de transition se raréfie. Le cas extrême est celui d'une version qui ne reçoit plus de correctifs de sécurité, situation où la dette technique devient un risque juridique. Le remboursement s'organise alors dans l'urgence, au pire tarif.

Les extensions accumulées

Sur un site géré par un système de gestion de contenu, chaque extension installée pour un besoin ponctuel reste en place longtemps après que ce besoin a disparu. Elle continue de charger du code, d'ouvrir une surface d'attaque et de contraindre les mises à jour. La nature de ces systèmes et les compromis qu'ils imposent sont détaillés dans notre article sur ce qu'est un CMS. Un inventaire annuel des extensions, avec pour chacune la question de savoir ce qui casse si on la retire, ramène régulièrement la liste à la moitié de sa taille.

Le contenu et les adresses

Un site vit plus longtemps que son architecture initiale, et les rubriques créées au fil des années finissent par se recouvrir. Les redirections empilées, les pages qui ne reçoivent plus aucune visite, les catégories créées pour un contenu unique constituent une dette éditoriale dont les effets se mesurent en exploration gaspillée et en visiteurs perdus. Cette dette est particulièrement pernicieuse parce qu'elle ne provoque aucune erreur : le site fonctionne parfaitement, il devient seulement moins lisible pour le lecteur comme pour le moteur, un peu plus chaque année.

Les contournements laissés en place

Un correctif appliqué pour passer un incident se transforme presque toujours en installation permanente. Une valeur codée en dur, une exception ajoutée dans un fichier de configuration, une tâche relancée manuellement chaque lundi : chacun de ces contournements a résolu un problème réel et chacun ajoute une règle non écrite que le prochain intervenant devra deviner. Le remède connu consiste à les inscrire dans un registre au moment où on les pose, avec une date de réexamen. Sans ce registre, ils deviennent indiscernables du fonctionnement normal du site en moins de deux ans.

L'absence de documentation

La documentation manquante est une dette dont les intérêts se paient uniquement lors des changements d'équipe, ce qui la rend invisible tant que les mêmes personnes restent en place. Le jour où elles partent, le montant apparaît d'un coup. Cette dette est la moins coûteuse à rembourser au moment où elle se crée, quelques minutes d'écriture après chaque décision structurante, et la plus coûteuse à reconstituer après coup. C'est aussi celle que les prestations de maintenance externalisées font apparaître le plus brutalement, comme le montre notre article sur la tierce maintenance applicative.

Le sur-mesure sans discipline

Développer sans système de gestion de contenu ni cadre logiciel supprime la dette imposée par ces outils et la remplace par une autre, celle d'un code dont la documentation universelle n'existe pas. Cet arbitrage est parfaitement défendable lorsqu'il s'accompagne de conventions écrites, d'une structure de dossiers stable et d'un registre des décisions. Il devient un piège lorsqu'il repose sur la mémoire d'une seule personne. La leçon vaut dans les deux sens : aucune pile technique ne supprime la dette, chacune déplace simplement l'endroit où elle s'accumule et la nature des intérêts qu'elle réclame.

La mesurer plutôt que la ressentir

Tant que la dette reste une impression partagée en réunion, elle ne se traite pas. Quelques indicateurs simples suffisent à la rendre discutable.

Le délai d'une modification simple

La mesure la plus parlante consiste à chronométrer une demande banale, par exemple ajouter un champ à un formulaire ou modifier un libellé sur toutes les pages concernées. Ce délai, relevé deux ou trois fois par an sur des demandes comparables, dessine une tendance sans exiger d'outillage. Un délai qui double en dix-huit mois sur des tâches équivalentes signale une dette qui progresse plus vite que le projet. C'est également l'indicateur le plus facile à présenter à une direction, parce qu'il porte sur une demande qu'elle a elle-même formulée.

Le nombre de versions de retard

Compter, pour chaque brique du site, l'écart entre la version installée et la version courante donne un chiffre immédiat. Trois briques à deux versions de retard constituent une situation ordinaire. Une brique à six versions de retard constitue un projet à part entière qu'il vaut mieux inscrire au budget que découvrir un vendredi soir. Ce relevé prend un quart d'heure et il se refait chaque trimestre. Il a l'avantage rare de produire une valeur objective, non discutable, que personne n'a besoin d'interpréter.

La part du temps passé en correction

Sur une période donnée, la proportion du temps consacré à réparer plutôt qu'à construire indique assez fidèlement le niveau d'intérêts payés. En dessous de quinze pour cent, la situation est saine. Au-delà de trente pour cent, l'équipe ne fait plus avancer le projet, elle l'entretient. Cette mesure suppose de distinguer les deux catégories dans le suivi du temps, discipline légère qui se met en place en une réunion. Elle révèle souvent que le sentiment de lenteur ressenti par la direction correspond à une réalité chiffrable.

Le nombre de personnes capables d'intervenir

Une zone du site que seule une personne sait modifier constitue une dette majeure, indépendamment de la qualité du code qui s'y trouve. L'indicateur se relève en listant les composants et en notant en face de chacun combien de personnes ont effectivement travaillé dessus dans l'année. Un composant à une seule personne appelle soit une documentation, soit un transfert de compétence, soit une simplification. Cet indicateur est celui qui parle le plus directement aux dirigeants, parce qu'il traduit la dette en risque de continuité d'activité.

La fréquence des régressions

Un même défaut qui réapparaît après avoir été corrigé signale une dette structurelle plutôt qu'une erreur ponctuelle. Tenir la liste des incidents avec leur date et leur cause fait apparaître ces répétitions en quelques mois. Trois occurrences du même symptôme justifient de traiter la cause plutôt que le symptôme, arbitrage que l'on repousse habituellement faute de trace écrite. Ce relevé ne demande qu'un tableau à trois colonnes et il se remplit au moment de l'incident, jamais après.

Tenir un registre daté

Ces indicateurs ne valent que comparés dans le temps, ce qui suppose de les conserver. Un simple tableau, une ligne par relevé trimestriel, remplit parfaitement ce rôle et survit aux changements d'outil. Il permet de répondre à la seule question qui compte réellement au moment d'arbitrer un budget : la situation s'améliore-t-elle ou se dégrade-t-elle. Sans historique, chaque discussion repart des impressions du moment, et la décision suit l'humeur du dernier incident plutôt que la tendance de fond.

Rembourser sans tout réécrire

La réponse instinctive à une dette importante est la réécriture complète. C'est presque toujours la plus coûteuse et la plus risquée des options disponibles.

Cesser d'emprunter d'abord

Avant tout remboursement, il faut arrêter la progression, faute de quoi l'effort consenti est absorbé par les nouveaux emprunts. Concrètement, cela signifie qu'aucune nouvelle fonctionnalité ne part sans sa documentation minimale et sans le retrait des contournements qu'elle rend inutiles. Cette règle coûte quelques heures par livraison et elle change la trajectoire en quelques mois. Elle a également un effet politique utile : elle démontre que l'équipe traite le sujet, ce qui rend beaucoup plus facile l'obtention d'un budget pour le stock existant.

Rembourser au fil de l'eau

La méthode la plus efficace consiste à améliorer ce que l'on touche, au moment où on le touche, plutôt que de programmer de grands chantiers séparés. Chaque intervention sur une zone est l'occasion de la remettre légèrement en état, pour un coût marginal faible puisque le contexte est déjà chargé. Cette approche concentre naturellement l'effort là où les intérêts sont les plus élevés, c'est-à-dire sur les zones les plus modifiées. Elle ne demande aucune ligne budgétaire distincte, ce qui explique en grande partie qu'elle fonctionne là où les plans de remise à niveau échouent.

Isoler avant de remplacer

Lorsqu'un composant doit disparaître, le remplacer d'un bloc expose à un basculement risqué. La méthode consistant à l'entourer d'une frontière claire, puis à faire passer les nouveaux usages par le remplaçant tout en laissant l'ancien servir les usages existants, permet une transition progressive et réversible. Le composant ancien s'éteint de lui-même lorsque plus rien ne l'appelle. Cette progression demande davantage de temps calendaire et beaucoup moins de risque, arbitrage presque toujours favorable sur un site en production qui doit continuer de fonctionner pendant l'opération.

Traiter la dette de contenu séparément

La dette éditoriale se rembourse avec des compétences différentes et selon un rythme différent de la dette de code. Fusionner deux rubriques qui se recouvrent, retirer les pages sans audience, remettre à plat le maillage interne relèvent d'un chantier éditorial qui n'a pas besoin d'attendre la disponibilité des développeurs. Mener les deux en parallèle plutôt qu'en séquence raccourcit considérablement le délai global. Cela suppose seulement de s'accorder en amont sur les adresses qui disparaissent, afin que les redirections soient posées une seule fois et correctement.

Quand la refonte devient la bonne réponse

La réécriture complète se justifie lorsque le coût cumulé des remboursements progressifs dépasse celui d'une reconstruction, ce qui arrive réellement dans deux cas : une brique fondamentale n'est plus maintenue, ou le besoin métier a tellement changé que la structure d'origine ne le décrit plus. En dehors de ces situations, la refonte relève souvent du confort de l'équipe technique plutôt que de l'intérêt du projet. Les critères de déclenchement et les précautions à prendre sont développés dans notre article sur les raisons de faire une refonte de site.

Rendre la dette visible dans le budget

Le seul dispositif qui tienne dans la durée consiste à réserver une part fixe de la capacité de production au remboursement, de l'ordre de dix à vingt pour cent, inscrite au budget comme n'importe quelle autre ligne. Cette part se défend d'autant mieux qu'elle s'appuie sur les indicateurs relevés plus haut et qu'elle produit des résultats mesurables sur ces mêmes indicateurs. Pour ceux qui souhaitent approfondir la métaphore et sa classification en quatre cas, la référence la plus citée reste l'article de Martin Fowler consacré à la dette technique, qui en donne la formulation la plus opérationnelle.