Le vrai coût de la dette technique (et comment la rembourser)

Il y a trois ans, un client nous a demandé d'ajouter une fonctionnalité simple à sa plateforme : permettre aux utilisateurs d'exporter leurs données en CSV. Dans tout codebase moderne, c'est un travail de deux jours. Dans le leur, ça a pris trois semaines.

Pourquoi ? Parce que les données utilisateur étaient éparpillées dans quatre tables de base de données avec des schémas incohérents. La couche ORM avait été partiellement remplacée deux fois mais jamais complètement. Il n'y avait pas de tests d'intégration. Et le processus de déploiement impliquait de se connecter en SSH sur un serveur de production et de lancer un script shell.

C'est la dette technique. Pas une seule décision, mais le coût accumulé de décisions différées — chacune individuellement raisonnable, collectivement paralysante.

Ce qu'est vraiment la dette technique

Ward Cunningham, qui a inventé la métaphore en 1992, était délibéré avec l'analogie. La dette financière n'est pas intrinsèquement mauvaise — les prêts immobiliers vous permettent d'habiter une maison pendant que vous payez encore. La dette technique, de même, vous permet de livrer du logiciel avant que l'architecture ne soit parfaite.

Le problème, comme avec la dette financière, c'est quand vous arrêtez de rembourser. Les intérêts se composent :

• Livraison de fonctionnalités plus lente. Chaque nouvelle fonctionnalité prend plus longtemps parce que les développeurs naviguent dans des contournements et des patterns désuets.
• Taux de défauts plus élevé. Du code fragile produit plus de bugs, et ces bugs sont plus durs à diagnostiquer.
• Attrition des développeurs. Les bons ingénieurs quittent les codebases qui les rendent malheureux.
• Complexité composée. Le nouveau code construit sur de la dette hérite de cette dette.

Les quatre types de dette technique

Délibérée et prudente

« On sait que ce n'est pas l'architecture idéale, mais on choisit de livrer maintenant et de refactorer une fois le marché validé. »

C'est de la dette saine. L'essentiel est de suivre le plan de remboursement.

Délibérée et imprudente

« On n'a pas le temps pour les tests. Livrez. »

C'est la dette qui tue les projets. Elle est contractée sans plan de remboursement et se compose rapidement.

Inadvertante et prudente

« Maintenant qu'on a construit le système, on comprend comment il aurait dû être conçu. »

C'est inévitable. On apprend en construisant.

Inadvertante et imprudente

« C'est quoi un design pattern ? »

Ça vient de l'inexpérience ou du manque de mentorat. Le correctif n'est pas juste du code — c'est de l'éducation et de la revue de code.

Comment quantifier la dette

Voici la conversation qui ne marche jamais : « On a besoin de trois sprints pour refactorer parce que le code est sale. »

Voici celle qui marche : « Ajouter la fonctionnalité de paiement devrait prendre 1 semaine mais en prendra 4 à cause de la dette architecturale. Investir 3 semaines maintenant réduira tout le travail futur de facturation d'environ 60 %. »

Suivez ces métriques au fil du temps :

Temps de livraison. Combien de temps de « code terminé » à « en production » ?

Temps de cycle. Temps moyen du début à la complétion d'un ticket.

Taux de bugs par fonctionnalité. Bugs introduits par fonctionnalité livrée.

Temps sur le travail non planifié. Si plus de 30 % de la capacité sprint va aux bugs et correctifs urgents, la dette consomme votre capacité.

Le guide de remboursement

La règle des 20 %

Allouez 20 % de chaque sprint à la réduction de dette. Pas comme une initiative séparée — dans votre flux normal. Chaque sprint a de la capacité pour le refactoring, l'amélioration des tests et les mises à jour d'infrastructure.

La règle du Boy-Scout

« Laissez le code en meilleur état que vous l'avez trouvé. » Quand vous touchez un fichier pour implémenter une fonctionnalité, améliorez-le. Clarifiez un nom de variable. Ajoutez un test manquant. Extrayez une fonction utilitaire.

Les réécritures stratégiques (avec parcimonie)

Parfois un module est si fondamentalement cassé que l'amélioration incrémentale n'aidera pas. Mais seulement avec ces conditions :

1. Le module a des frontières claires
2. Vous avez des tests qui spécifient le comportement attendu
3. La réécriture peut être complétée en 2-4 semaines
4. Vous pouvez échanger le nouveau module derrière un feature flag

Ne réécrivez jamais un système entier. Réécrivez le pire module, prouvez que ça marche, et passez au suivant.

L'inventaire de dette

Maintenez un document vivant de la dette technique connue. Chaque entrée devrait inclure :

• Description : La dette et où elle vit
• Impact : Comment ça ralentit l'équipe
• Taux d'intérêt : Ça s'aggrave avec le temps ou c'est stable ?
• Coût à corriger : Estimation en jours-développeur
• Risque : Qu'est-ce qui casse si on ne corrige pas ?

Ce qu'il ne faut pas refactorer

Pas tout le vieux code est de la dette. Du code laid mais stable, bien testé et rarement touché ne devrait pas être refactoré. Ça n'apporte aucune valeur métier et risque d'introduire des bugs.

La réduction de dette technique devrait toujours être guidée par l'impact, pas par l'esthétique. L'objectif n'est pas du beau code — c'est un codebase qui permet à votre équipe d'aller à la vitesse dont le business a besoin.

Le long terme

Chaque codebase a de la dette technique. La différence entre les projets sains et malsains n'est pas la présence de dette — c'est si l'équipe la reconnaît, la suit et la réduit systématiquement.

Votre codebase est un système vivant. Nourrissez-le de discipline, et il vous récompense avec de la vélocité. Privez-le de maintenance, et il finit par vous priver de la capacité à livrer.