Tous les gestionnaires TI ont vécu cette scène : on demande pourquoi une modification apparemment simple prend des semaines, et la réponse commence par « c’est compliqué, le système est vieux ». La dette technique est probablement le concept le plus important — et le plus mal communiqué — des conversations entre les équipes TI et la direction. Les développeurs la ressentent quotidiennement ; les directions n’en voient que les symptômes : des livraisons lentes, des pannes récurrentes, des estimations qui gonflent.
Pourtant, la dette technique est un concept profondément financier, et c’est précisément ce qui la rend explicable à une direction. Encore faut-il la mesurer avec des indicateurs simples et en parler dans un langage de risque et de coût, pas de refactorisation et de frameworks. Voici comment nous suggérons d’aborder la conversation.
La métaphore fondatrice est limpide : chaque fois qu’une équipe choisit une solution rapide plutôt qu’une solution propre — pour tenir une échéance, faute de temps ou de compétences —, elle contracte un emprunt. Le capital, c’est le travail de correction qu’il faudra faire un jour. Les intérêts, c’est le surcoût payé sur chaque changement d’ici là : plus de temps pour comprendre le code, plus de précautions pour ne rien casser, plus de tests manuels, plus d’incidents.
Comme un emprunt, la dette technique n’est pas mauvaise en soi. S’endetter pour livrer un produit à temps et prendre un marché peut être une excellente décision d’affaires — à condition de savoir qu’on s’endette, de connaître le taux d’intérêt et d’avoir un plan de remboursement. Le problème des organisations n’est presque jamais d’avoir de la dette : c’est de l’avoir contractée sans le savoir, de ne pas la mesurer et de payer des intérêts croissants sans jamais rembourser le capital.
Avant même de mesurer quoi que ce soit, il est utile de nommer les intérêts que l’organisation paie déjà, parce qu’ils sont souvent invisibles dans les budgets. Il y a la lenteur : des changements qui prendraient quelques jours dans un système sain en prennent des semaines dans un système endetté, et ce surcoût se répète sur chaque demande, année après année. Il y a le risque d’incident : les systèmes fragiles tombent plus souvent, au pire moment, et mobilisent les meilleures ressources en mode pompier plutôt qu’en création de valeur.
Il y a enfin des coûts plus sournois : la difficulté à recruter et à retenir des développeurs quand la pile technologique est obsolète, la dépendance à une poignée d’experts qui sont les seuls à comprendre certains modules, et l’incapacité à saisir des occasions d’affaires parce que le système ne peut tout simplement pas suivre. Aucun de ces coûts ne figure dans une ligne budgétaire nommée « dette technique » — et c’est exactement pourquoi la direction ne la voit pas.
Inutile d’acheter une plateforme d’analyse sophistiquée pour objectiver la dette : quatre familles de signaux, mesurables avec les outils que vous avez déjà, suffisent à dresser un portrait crédible.
L’important n’est pas la précision de chaque mesure, mais la tendance et la comparaison entre systèmes. Un tableau simple, tenu à jour trimestriellement, vaut mieux qu’un audit exhaustif réalisé une fois puis oublié.
Armé de ces signaux, le piège serait de les présenter en jargon : couverture de tests, refactorisation, montée de version. Une direction n’arbitre pas entre des concepts techniques ; elle arbitre entre des risques et des rendements. La traduction est donc essentielle : « ce système génère une part disproportionnée de nos incidents et chaque évolution y coûte plusieurs fois plus cher qu’ailleurs » ; « cette composante ne sera plus soutenue par son éditeur à telle date, ce qui nous exposera à des vulnérabilités sans correctif » ; « trois personnes seulement peuvent intervenir sur ce module qui traite notre facturation ».
Formulée ainsi, la dette technique devient une conversation de gestion des risques tout à fait ordinaire, du même ordre qu’une couverture d’assurance ou un renouvellement d’équipement. Notre expérience est constante sur ce point : les directions ne refusent pas d’investir dans l’assainissement technique — elles refusent d’investir dans ce qu’elles ne comprennent pas. La qualité de la traduction fait toute la différence entre un budget accordé et un dossier reporté d’année en année.
La tentation, une fois la dette reconnue, est de proposer le grand remplacement : tout réécrire, repartir à neuf. C’est presque toujours une erreur — les projets de réécriture intégrale, le fameux « rip and replace », cumulent les risques et privent l’organisation de capacité d’évolution pendant des années. Nous en parlions dans notre article sur la modernisation des applications legacy : les approches progressives, comme le motif du « strangler fig » qui remplace un système morceau par morceau, donnent de bien meilleurs résultats.
Côté budget, deux mécanismes complémentaires fonctionnent bien. D’abord, réserver une portion récurrente de la capacité des équipes à l’assainissement, sanctuarisée au même titre que l’exploitation — la proportion exacte se négocie selon le contexte, mais c’est la récurrence qui compte, pas le pourcentage. Ensuite, attacher le remboursement de la dette aux projets d’affaires : chaque initiative qui touche un système endetté inclut une part d’assainissement de la zone traversée. On rembourse le capital là où on circule déjà, ce qui est bien plus efficace que des chantiers d’assainissement isolés, sans valeur d’affaires visible.
La dette technique ne disparaîtra jamais complètement, et ce n’est pas l’objectif : une organisation qui livre vite contractera toujours des emprunts techniques. L’objectif est de passer d’une dette subie — invisible, croissante, découverte au pire moment — à une dette gérée : mesurée par des signaux simples, traduite en langage de risque, remboursée méthodiquement là où les intérêts font le plus mal.
Si cette conversation avec votre direction reste difficile à amorcer, ou si vos équipes manquent de bras pour mener de front l’évolution et l’assainissement, c’est exactement le genre de mandat où un regard externe et des renforts ciblés changent la donne. Chez Dempton, nous aimons ces problèmes concrets où la technique rencontre la gestion. Créer de la valeur, ensemble — parfois, ça commence par rembourser ses dettes.