Dette technique : la mesurer, la chiffrer et la négocier avec le business

Il y a deux façons de parler de dette technique. La première : « le code est sale, il faut tout refaire. » C'est celle qui ne mène nulle part, parce qu'aucun dirigeant n'a jamais signé un chèque pour du code « plus propre ».

La seconde : « voici combien cette dette nous coûte chaque mois, et voici le retour sur investissement si on la rembourse. » Celle-là fait bouger les lignes, parce qu'elle parle le langage de ceux qui décident du budget.

La différence entre les deux, c'est tout ce qui sépare un développeur d'un développeur qu'on écoute. Voyons comment passer de la première à la seconde.

La dette technique n'est pas un gros mot

La métaphore de la dette est excellente, à condition de la prendre au sérieux. S'endetter n'est pas une faute : parfois c'est même la meilleure décision possible. On contracte une dette technique pour livrer plus vite, tester une idée, prendre un marché avant un concurrent. C'est un choix rationnel.

Le problème n'est pas la dette. Le problème, ce sont les intérêts qu'on paie sans s'en rendre compte, et la dette qu'on a contractée sans le décider.

Pourquoi « il faut tout réécrire » ne marche jamais

Quand un développeur demande trois mois pour réécrire un système qui fonctionne, voici ce que le business entend : « trois mois sans nouvelle fonctionnalité, sans valeur pour le client, avec un risque de tout casser, pour arriver au même endroit. »

Vu comme ça, le refus est logique. Le tort n'est pas côté business : il est dans la façon de présenter le sujet. On a demandé un budget sans montrer ni le coût du problème, ni le retour attendu. Personne n'investit à l'aveugle.

Étape 1 : mesurer, rendre visible l'invisible

Le vrai obstacle, c'est que la dette technique est invisible dans un tableau de bord classique. Elle ne se voit ni dans le chiffre d'affaires, ni dans le nombre de tickets fermés. Il faut donc la faire remonter à la surface avec des indicateurs concrets :

• Lead time : combien de temps entre « on décide de faire cette feature » et « elle est en production » ? S'il augmente à périmètre constant, la dette te ralentit.
• Taux d'échec des déploiements : combien de mises en production provoquent un incident ou un rollback ?
• Temps de contournement : combien d'heures par semaine l'équipe passe-t-elle à contourner un problème connu plutôt qu'à créer de la valeur ?
• Zones à peur : les parties du code que personne ne veut toucher. Demande à l'équipe, elle les connaît par cœur.

Ces chiffres transforment une intuition (« c'est le bazar ») en fait mesurable (« notre lead time a doublé en un an »).

Étape 2 : chiffrer, traduire en euros et en temps

Une fois la dette mesurée, il faut la convertir dans la seule unité que tout le monde comprend : le coût.

Prenons un exemple simple. Une équipe de cinq développeurs passe, disons, 20 % de son temps à lutter contre une dette identifiée : contournements, bugs récurrents, features qui prennent trois fois plus de temps que prévu.

• 20 % de cinq développeurs, c'est l'équivalent d'un développeur à plein temps.
• Sur une année, c'est un salaire chargé complet englouti dans le remboursement d'intérêts, sans jamais toucher au capital.

Soudain, la conversation change. On ne parle plus de « code sale », on parle d'un poste de dépense annuel bien réel. Et face à un coût annuel, un investissement ponctuel pour le réduire devient une décision d'affaires comme une autre.

Étape 3 : négocier, parler risque et coût d'opportunité

Avec des chiffres en main, la négociation change de nature. Trois leviers fonctionnent particulièrement bien :

Le coût d'opportunité. « Tant qu'on ne traite pas ça, chaque nouvelle feature coûte 30 % de plus. Investir maintenant, c'est accélérer tout ce qui vient après. »

Le risque. Certaines dettes ne ralentissent pas seulement, elles menacent. Une dépendance non maintenue, une faille de sécurité, un point unique de défaillance. Là, l'argument n'est plus la vitesse mais la probabilité d'un incident coûteux.

L'incrément, pas le big bang. Plutôt que de réclamer trois mois d'arrêt, propose un budget récurrent : par exemple 15 à 20 % de la capacité de l'équipe consacrés en continu à la réduction de dette. C'est infiniment plus facile à accepter, et bien moins risqué, qu'une grande réécriture.

Un cadre simple pour prioriser

Toutes les dettes ne se valent pas. Je les classe sur deux axes : l'impact (combien ça nous coûte ou nous menace) et l'effort (combien ça coûte à corriger).

Le quadrant le plus important est le dernier : décider de ne pas rembourser une dette est une décision parfaitement valable, à condition qu'elle soit consciente et assumée. La dette dangereuse, c'est celle qu'on subit sans l'avoir choisie.

Quand la dette est le bon choix

Pour finir, un contre-pied. Vouloir zéro dette technique est aussi naïf que de vouloir zéro dette financière dans une entreprise. Une startup qui cherche son marché a raison de s'endetter techniquement pour aller vite : personne ne se soucie de la qualité du code d'un produit que personne n'utilise.

La maturité, ce n'est pas d'éviter la dette. C'est de savoir quand la contracter, de la rendre visible, et de la rembourser au bon moment. Exactement comme une dette financière.

C'est précisément ce déplacement, de « le code est sale » vers « voici notre stratégie de dette », qui fait la différence entre un développeur et un partenaire de confiance pour le business.