La dette technique est le poste de dépense le plus coûteux qui n’apparaît jamais sur votre bilan.
Nous avons sauvé plus de 15 codebases au cours des sept dernières années. Certaines étaient récupérables. Certaines nécessitaient une démolition contrôlée. La leçon coûteuse que la plupart des entreprises apprennent trop tard : la décision de quoi faire de la dette technique compte plus que le comment.
Voici le framework que nous utilisons réellement.
D’abord, quantifier le coût
Avant de décider quoi que ce soit, mesurez les dégâts. La dette technique a quatre coûts que la plupart des équipes ne suivent que partiellement :
Coût de vélocité. À quel point votre équipe livre-t-elle plus lentement qu’il y a 12 mois ? Si une fonctionnalité qui prenait une semaine en prend maintenant trois, ce delta est votre taxe de vélocité. Nous constatons typiquement une dégradation de 30 à 60 % de la vélocité dans les codebases avec une dette significative.
Coût des incidents. Comptez les incidents de production des 90 derniers jours. Multipliez par le nombre moyen d’heures passées à répondre. Multipliez par le coût chargé d’un ingénieur. Ce chiffre est généralement plus élevé que ce que quiconque attendait.
Coût de recrutement. Les ingénieurs parlent entre eux. Si votre codebase a une réputation, votre pipeline de recrutement est plus étroit et vos offres doivent être plus élevées. Nous avons vu des entreprises payer des primes salariales de 15 à 20 % parce que leur réputation technique les précédait.
Coût d’opportunité. Les fonctionnalités que vous n’avez pas construites parce que votre équipe éteignait des incendies. Le marché que vous n’avez pas pénétré parce que la livraison était trop lente. C’est le plus difficile à mesurer et généralement le plus important.
La matrice de décision
Une fois que vous avez les chiffres, vous avez trois options. Voici comment choisir :
REFACTORER quand :
- L’architecture de base est saine mais l’exécution est désordonnée
- Moins de 40 % du codebase nécessite des modifications significatives
- Votre équipe peut maintenir sa vélocité tout en refactorant de manière incrémentale
- Le modèle de domaine correspond encore à votre activité
Le refactoring est de la chirurgie, pas de la démolition. Vous corrigez des modules spécifiques, extrayez des responsabilités, ajoutez des tests et nettoyez les interfaces — pendant que le produit continue à livrer des fonctionnalités. C’est la bonne décision dans 60 % des cas.
RÉÉCRIRE quand :
- L’architecture ne peut pas supporter vos 2 prochaines années de croissance
- La stack technique est fondamentalement inadaptée au problème
- Plus de 60 % du codebase devrait de toute façon être réécrit
- Vous avez le budget pour 3 à 6 mois de développement en parallèle
Les réécritures sont coûteuses et risquées. L’erreur classique est de supposer qu’une réécriture prendra la moitié du temps qu’elle prend réellement. Budgétez le double de votre estimation.
NE RIEN FAIRE quand :
- Le système est stable et répond aux besoins business
- La dette est cosmétique, pas structurelle
- Le produit approche de sa fin de vie
- Vous n’avez pas le budget ou la bande passante pour le faire correctement
Parfois, la bonne réponse est « pas maintenant ».
Le pattern Strangler Fig
Notre approche préférée pour la plupart des sauvetages est le Strangler Fig : envelopper l’ancien système dans de nouvelles interfaces, migrer les fonctionnalités pièce par pièce, et finalement éteindre le code legacy. Pas de big bang. Pas de six mois de silence suivis d’un jour de lancement effrayant.
Voici comment ça fonctionne en pratique :
- Identifier le module le plus douloureux dans le système legacy
- Construire un remplacement derrière une frontière d’API propre
- Router le trafic vers le nouveau module
- Valider, monitorer, confirmer
- Répéter avec le module suivant
Chaque cycle prend 2 à 4 semaines. Chaque cycle délivre une valeur mesurable.
Ce que les investisseurs regardent vraiment
Si vous levez des fonds ou préparez une sortie, votre dette technique est sous examen. Voici ce qu’ils signalent :
Pas de tests : signal d’alarme immédiat. Pas de documentation : risque de dépendance à une personne clé. Dépendances obsolètes : risque de sécurité. Pas de CI/CD : les déploiements sont manuels et terrifiants.
La bonne nouvelle : tout cela est réparable. La mauvaise nouvelle : le réparer prend du temps.
Commencez par l’audit
Ne commencez pas à refactorer au hasard. Commencez par un audit structuré. Nous examinons les graphes de dépendances, la couverture de tests, les goulots d’étranglement de performance, les vulnérabilités de sécurité, le pipeline de déploiement et la documentation. Le livrable est un plan priorisé.
Chaque sauvetage que nous avons réalisé a commencé par 40 heures de travail d’audit. C’est l’investissement avec le meilleur ROI que vous puissiez faire avant d’écrire une seule ligne de nouveau code.
La dette technique est un problème business, pas un problème d’ingénierie. Quantifiez le coût, choisissez la bonne stratégie, et commencez par un audit. Chaque semaine que vous attendez, les intérêts composés augmentent.