La scène se rejoue chaque année, à quelques variantes près. Une équipe explique qu’il faudrait « reprendre le socle », « sortir de cette version », « refaire la couche d’accès aux données ». Les arguments sont solides et sincères. En face, le comité d’investissement écoute poliment, puis arbitre en faveur des projets qui portent une promesse métier lisible : un nouveau parcours client, une conformité à tenir, une offre à lancer. La demande de l’équipe repart à la ligne suivante du prochain exercice. Et l’année d’après, la même demande revient — plus chère.

Il serait facile d’y voir un défaut de courage managérial. C’est rarement le cas. Le comité fait exactement ce pour quoi il existe : allouer une ressource rare à des demandes concurrentes, en comparant ce qu’elles rapportent. Le problème est que la dette technique, telle qu’elle lui est présentée, n’est pas comparable. Elle arrive formulée dans un vocabulaire technique, sans montant, sans échéance, sans conséquence datée. Elle n’est pas un dossier d’investissement : c’est une inquiétude.

C’est la thèse de cet article. La dette technique n’échoue pas à être financée parce qu’elle serait mal comprise, mais parce qu’elle est mal instruite. Tant qu’elle reste un sujet d’ingénieurs, elle restera hors budget. Le travail d’architecture consiste précisément à la faire changer de nature : d’un inconfort technique diffus à un passif identifié, rattaché à ce qu’il met en risque, et arbitrable au même titre qu’un investissement.

La métaphore est juste — on n’en tire pas les conséquences

L’image de la dette n’est pas un artifice de communication. Elle a été proposée au début des années 1990 par Ward Cunningham pour expliquer à des non-techniciens un mécanisme précis : livrer vite avec une conception imparfaite revient à emprunter. On obtient un bénéfice immédiat — la fonctionnalité arrive plus tôt — contre une charge future : chaque évolution ultérieure coûtera un peu plus cher tant que la conception n’aura pas été corrigée.

Ce qui rend la métaphore puissante, c’est qu’elle est financièrement exacte sur trois points.

Elle distingue d’abord un principal — le coût de remise en état — et des intérêts : le surcoût payé sur chaque évolution tant que le principal n’est pas remboursé. Ensuite, elle admet que s’endetter peut être rationnel : on emprunte pour saisir une opportunité qui ne se représentera pas, exactement comme une entreprise s’endette pour financer sa croissance. Enfin, elle porte un risque bien connu des financiers : quand les intérêts dépassent la capacité de remboursement, l’organisation ne rembourse plus que la charge, jamais le capital. Traduit en système d’information, c’est le moment où l’essentiel du budget passe à maintenir l’existant et où plus rien de structurant ne sort.

Le paradoxe est que la métaphore est utilisée partout, et ses conséquences nulle part. Une organisation qui parlerait de sa dette financière comme elle parle de sa dette technique n’aurait ni encours, ni échéancier, ni titulaire, ni idée du taux qu’elle paie. Elle dirait simplement, en réunion, qu’elle est « assez endettée ». Aucune direction financière ne l’accepterait. C’est pourtant l’état normal de la dette technique dans la plupart des SI.

Toutes les dettes ne se valent pas

Avant de financer quoi que ce soit, il faut savoir ce que l’on a contracté. Or « dette technique » désigne, dans l’usage courant, des réalités qui n’ont ni la même origine, ni le même traitement.

Martin Fowler a proposé une grille devenue classique, qui croise deux axes : la dette est-elle délibérée ou involontaire, et le choix était-il prudent ou imprudent ? Quatre situations en découlent, et elles n’appellent pas les mêmes réponses.

  • Délibérée et prudente : « nous savons que cette conception est simplifiée, nous acceptons le surcoût pour tenir la date. » C’est un emprunt assumé. Il se documente et se provisionne.
  • Délibérée et imprudente : « nous n’avons pas le temps de concevoir. » L’emprunt est contracté sans en connaître le taux. C’est la dette la plus dangereuse, parce qu’elle est invisible au moment où elle est prise.
  • Involontaire et prudente : « maintenant que le système tourne, nous voyons comment il aurait fallu le structurer. » C’est le coût normal de l’apprentissage ; toute conception vieillit à mesure que la compréhension du domaine progresse.
  • Involontaire et imprudente : la dette née d’un manque de maîtrise, découverte après coup.

À cette grille, l’architecte doit ajouter deux catégories que la seule perspective du code ignore, et qui pèsent souvent plus lourd.

L’obsolescence d’abord : elle n’est pas une dette qu’on a contractée, mais une dette qui s’accumule sans qu’on décide quoi que ce soit. Une version qui sort du support de son éditeur, un composant dont la communauté se tarit, une compétence qui disparaît du marché. Le temps travaille seul, et le principal augmente sans qu’aucune ligne de code n’ait été écrite.

La dette d’architecture ensuite, qui est d’une autre nature que la dette de code. Un module mal écrit coûte cher à celui qui le modifie. Un découpage inadéquat, un couplage structurel entre domaines, un modèle de données commun à ce qui aurait dû rester séparé : cela coûte cher à tout le monde, tout le temps, et sur des projets qui n’ont rien demandé. C’est la dette dont les intérêts se composent — parce que chaque nouveau système construit sur une fondation bancale hérite du défaut et le propage.

Cette distinction a une conséquence pratique directe : les instruments de mesure du code (analyse statique, indicateurs de qualité, ratios de couverture) sont utiles, mais ils ne voient presque rien de la dette la plus coûteuse. Une base de code impeccable peut parfaitement recouvrir une architecture qui immobilise l’organisation.

Rattacher la dette à ce qu’elle met en risque

Une organisation ne finance pas une remise en état ; elle finance la protection ou la libération d’une capacité. C’est le pivot du raisonnement, et l’endroit exact où la plupart des dossiers échouent.

Comparons deux formulations de la même situation. « Le socle de facturation repose sur une version dont le support s’arrête, et le code n’est plus testé. » Personne ne sait quoi en faire : c’est un constat technique, adressé à un comité qui ne parle pas cette langue. Reformulons : « Toute évolution tarifaire demande aujourd’hui plusieurs mois et mobilise les rares personnes qui connaissent ce socle ; à l’arrêt du support, nous perdons la capacité de corriger une anomalie de facturation dans un délai acceptable. » Rien n’a changé dans les faits. Tout a changé dans la décision : la seconde formulation nomme une capacité métier fragilisée, une conséquence, et un horizon.

Ce déplacement demande de relier explicitement chaque poste de dette aux capacités métier qu’il supporte — c’est là que la carte des capacités devient un instrument financier autant qu’un outil d’architecture. Une fois ce lien posé, la hiérarchisation cesse d’être un débat d’opinion : une dette lourde sur une capacité différenciante ne se traite pas comme la même dette sur une capacité en fin de vie, dont le sort est de disparaître.

Trois questions suffisent à instruire un poste de dette. Qu’est-ce que cette dette nous empêche de faire ? — pas « qu’est-ce qui est laid », mais quelle évolution devient lente, chère ou impossible. Que se passe-t-il si nous ne faisons rien ? — et à quelle échéance, sachant qu’une échéance externe (fin de support, exigence réglementaire, dépendance qui disparaît) est infiniment plus mobilisatrice qu’une inquiétude interne. Que coûte l’attente ? — car une dette dont le principal augmente avec le temps ne se compare pas à une dette stable.

Trois façons de financer, une façon de ne pas le faire

Une fois la dette instruite, elle devient finançable. Trois modes existent, et le choix entre eux est lui-même une décision d’architecture.

Le remboursement dédié est un chantier identifié, budgété, avec un début et une fin : refonte d’un composant, migration d’une version, extraction d’un domaine. C’est le seul mode qui traite réellement une dette structurelle importante, et le seul qui exige un arbitrage explicite. Son défaut : il entre en concurrence frontale avec les projets métier, ce qui suppose un dossier solide.

L’amortissement dans les projets consiste à faire porter la remise en état par les évolutions fonctionnelles qui traversent la zone concernée : on ne finance pas un chantier de dette, on finance un projet qui exige, pour être bien fait, de nettoyer ce qu’il touche. C’est le mode le plus fluide politiquement, et le plus efficace pour la dette locale. Sa limite est stricte : il ne traite jamais la dette structurelle, parce qu’aucun projet ne traverse à lui seul une fondation.

Le refinancement revient à ne pas rembourser du tout : remplacer, décommissionner, ou faire porter la capacité par une solution du marché. C’est souvent l’option la plus rationnelle pour une dette ancienne sur une capacité non différenciante — encore faut-il l’instruire comme une option, et non l’écarter par habitude.

À côté de ces trois modes, une pratique courante mérite d’être regardée sans complaisance : la règle des 20 % — consacrer une fraction fixe de la capacité des équipes à la dette. Elle a un mérite réel, celui de rendre l’entretien continu au lieu d’attendre la crise, et elle traite bien la dette locale. Mais elle produit deux effets pervers quand elle tient lieu de politique. Elle donne l’impression que le sujet est traité, alors qu’elle ne touche que ce qu’une équipe peut réparer seule — jamais la dette d’architecture, qui est précisément celle qui traverse les équipes. Et faute de critères de priorisation, cette fraction se dépense là où c’est le plus visible pour l’équipe, pas là où le risque est le plus élevé pour l’organisation. Un pourcentage n’est pas un arbitrage ; c’est une provision que personne n’affecte.

La dette qu’on choisit de ne jamais rembourser

Il faut le dire nettement, parce que c’est contre-intuitif dans un article qui plaide pour financer la dette : une part de la dette ne doit pas être remboursée. Vouloir tout corriger est aussi irrationnel que ne rien corriger, et c’est une source de discrédit pour la fonction d’architecture, qui apparaît alors comme réclamant un budget infini pour un idéal esthétique.

Une dette portée par une application en fin de vie, sur une capacité que l’organisation ne compte plus faire évoluer, est une dette qu’il faut assumer et geler. La décision consiste alors à arrêter d’y investir, à documenter le risque résiduel, à contenir la zone — et à ne plus jamais rouvrir le débat en comité. C’est une décision d’architecture à part entière, qui se consigne comme les autres.

Ce tri a une vertu que l’on sous-estime : il rend crédible tout le reste. Une fonction d’architecture qui déclare explicitement quelle dette elle renonce à traiter gagne le droit d’être entendue sur celle qu’elle demande de financer.

Ce qui fait échouer les registres de dette

La démarche décrite ici a un mode d’échec dominant, et il est utile de le nommer parce qu’il est très répandu : le registre qui ne sert à rien. On recense la dette, on obtient une liste de plusieurs centaines de lignes, on la classe par sévérité technique, on la présente — et elle ne déclenche aucune décision. Trois causes se combinent presque toujours.

La liste est trop fine : elle inventorie des symptômes de code là où le comité attend des enjeux de capacité. Elle est sans titulaire : une dette sans propriétaire identifié n’est arbitrable par personne. Et elle est sans échéance : rien ne distingue ce qui devient critique dans six mois de ce qui pourra attendre trois ans, ce qui revient à ne rien hiérarchiser du tout.

Un registre utile est court, formulé en conséquences, daté, et rattaché à des capacités. Il tient sur une page pour un comité, avec le détail technique disponible en dessous pour ceux qui veulent y descendre. Il ressemble davantage à un tableau d’engagements qu’à un rapport d’audit.

Rendre la dette décidable

Rien de ce qui précède ne relève de la technique. La dette technique est un objet de gestion qui a été confié, par défaut, à ceux qui en subissent les effets plutôt qu’à ceux qui peuvent l’arbitrer. Le travail de l’architecte n’est pas de la réparer — c’est de la rendre décidable : nommée, chiffrée autant que possible, rattachée à une capacité, dotée d’une échéance et d’un titulaire, et accompagnée d’une recommandation claire, y compris celle de ne rien faire.

Une organisation mature ne se reconnaît pas à l’absence de dette. Elle se reconnaît à ceci qu’elle sait, à tout moment, quelle dette elle porte, ce qu’elle lui coûte, ce qu’elle a décidé d’en faire — et quelle part elle a délibérément choisi de garder au bilan.