Dette technique : la mesurer, la chiffrer, décider quoi rembourser
« Il faudrait refactoriser. » Vous entendez cette phrase depuis deux ans et vous ne savez pas si c'est un caprice d'ingénieur ou une urgence. Voici comment trancher — avec des chiffres, pas des impressions.
Sommaire
La phrase que vous entendez depuis deux ans
« Il faudrait refactoriser. »
Vous l’entendez à chaque réunion. Vous ne savez pas si c’est un caprice d’ingénieur qui voudrait du code plus joli, ou une alerte sérieuse que vous êtes en train d’ignorer.
Le problème, c’est que la personne qui vous le dit ne sait généralement pas vous l’expliquer autrement — parce qu’elle le ressent, mais qu’elle ne l’a jamais mesuré.
Alors mesurons.
Ce qu’est vraiment la dette technique
C’est l’écart entre la façon dont votre logiciel est construit et la façon dont il devrait l’être compte tenu de ce qu’on lui demande aujourd’hui.
La métaphore financière est juste, et il faut la prendre au sérieux : une dette n’est pas une faute. On la contracte pour aller plus vite, et c’est souvent la bonne décision — livrer six mois plus tôt vaut parfois bien mieux qu’un code impeccable arrivé trop tard.
Ce qui coûte, ce n’est pas le capital. Ce sont les intérêts. C’est-à-dire le temps supplémentaire que chaque évolution demande désormais, tous les mois, jusqu’à ce que vous remboursiez.
Et c’est exactement ce qu’il faut mesurer.
Les trois signaux que vous pouvez observer sans lire une ligne de code
1. Le temps pour livrer une modification simple
Prenez une évolution vraiment banale — changer un libellé, ajouter un champ dans un formulaire. Combien de temps s’écoule entre la demande et la mise en production ?
Puis posez la question qui compte : combien de temps cela prenait-il il y a deux ans ?
Si la réponse est « beaucoup moins », vous avez votre mesure. Ce n’est pas une impression, c’est un fait.
2. La proportion de correctifs
Sur les trois derniers mois, quelle part de l’effort de l’équipe est partie en corrections plutôt qu’en nouveautés ?
Il n’existe pas de seuil universel, et méfiez-vous de qui vous en donnerait un. Ce qui compte est la tendance : si cette proportion augmente trimestre après trimestre, votre système consomme une part croissante de votre budget rien que pour rester debout.
3. La fréquence et la nature des incidents
Combien de fois par mois quelque chose casse en production ? Et surtout : est-ce que ça casse à des endroits où on n’avait rien touché ?
Ce dernier point est le signal le plus grave. Il signifie que le système est couplé — que tout tient à tout — et qu’il est devenu impossible de prévoir les conséquences d’un changement. À ce stade, l’équipe n’ose plus rien toucher, et la vitesse s’effondre.
Le chiffrage, en une opération
Une fois ces signaux relevés, le calcul est à la portée de n’importe quel dirigeant.
| Ce qu’on mesure | Exemple |
|---|---|
| Temps moyen d’une évolution, aujourd’hui | 30 jours |
| Ce que ça prendrait sur une base saine | 10 jours |
| L’intérêt | 20 jours par évolution |
| Nombre d’évolutions par an | 12 |
| Coût annuel de la dette | 240 jours — soit environ un an de développeur |
Le chiffre du bas est celui qu’il faut mettre sur la table. Pas « le code est sale ». « Cette dette nous coûte un développeur à temps plein, tous les ans, et personne ne le voit sur aucune ligne du budget. »
Là, on peut décider. Avant, on discutait.
Ce qu’il ne faut surtout pas rembourser
C’est la partie que les développeurs n’aiment pas entendre, et elle est essentielle.
Une dette qui ne ralentit rien ne coûte rien.
Le code d’un module qu’on ne touche jamais peut être affreux : il fonctionne, il ne bouge pas, il ne vous coûte pas un centime. Le réécrire consommerait du budget et n’apporterait strictement rien — sinon la satisfaction de savoir que c’est propre.
On ne rembourse que là où le code change souvent. Croisez deux informations : quelles zones du code sont les plus modifiées, et lesquelles font le plus mal. L’intersection est votre feuille de route. Tout le reste attend, éventuellement pour toujours.
Vouloir tout nettoyer est le plus sûr moyen de dépenser un budget considérable sans que personne, dans l’entreprise, ne voie la moindre différence.
La réécriture complète : la question n’est pas « faut-il ? », c’est « combien de temps ? »
On présente souvent la réécriture comme l’erreur à ne jamais commettre. C’est faux, et c’est même paresseux.
Une réécriture n’est pas dangereuse par nature. Ce qui est dangereux, c’est sa durée — et ce qui rend cette durée imprévisible, c’est l’absence de cadrage.
Voici la mécanique. Pendant toute la réécriture, vous payez deux systèmes : l’ancien, qu’il faut continuer à maintenir parce que vos clients s’en servent, et le nouveau, qu’il faut construire. Et pendant tout ce temps, vous ne livrez rien de nouveau.
Ce n’est pas grave sur trois mois. C’est mortel sur deux ans.
| Réécriture cadrée | Réécriture à l’aveugle | |
|---|---|---|
| Durée | Quelques mois, avec une fin datée | « On verra bien » |
| Périmètre | Défini, et ce qui est exclu est écrit | Tout, plus ce qu’on découvrira |
| Règles métier | Inventoriées avant de commencer | Redécouvertes une par une, dans la douleur |
| Chiffrage | Fait, avec ses hypothèses | « À peu près comme l’ancien » |
| Risque | Réel mais maîtrisé | Le projet peut ne jamais finir |
La colonne de gauche est un projet raisonnable. Si la réécriture est cadrée, chiffrée, préparée, et qu’elle tient sur quelques mois, le risque est parfaitement acceptable — souvent plus faible, d’ailleurs, que celui de continuer à empiler des correctifs sur un système que plus personne ne comprend.
La colonne de droite est un gouffre. Et l’écart entre les deux ne se joue pas sur la technique : il se joue avant la première ligne de code.
Le vrai danger : ce que vous ne savez plus faire
Ce qui fait exploser la durée d’une réécriture, ce n’est presque jamais la difficulté de reconstruire. C’est de découvrir, en chemin, tout ce que l’ancien système faisait et que personne n’avait documenté.
La règle de facturation particulière pour ce client historique. Le traitement du samedi qui n’existe nulle part sauf dans le code. Le contournement mis en place il y a six ans pour un cas qui se produit deux fois par an — et qui, ces deux fois-là, est vital.
Ces règles ne sont pas dans les spécifications : elles sont dans le code, et nulle part ailleurs. On les redécouvre une par une, en production, quand un utilisateur signale que « ça ne marche plus comme avant ».
D’où la seule question qui décide vraiment :
Savez-vous, aujourd’hui, tout ce que fait votre système actuel ?
Si la réponse est non, ce n’est pas une réécriture qu’il faut lancer. C’est un inventaire — et c’est exactement ce qu’un audit technique produit. Réécrire sans cet inventaire, c’est signer un chèque en blanc sur une durée qu’on ne connaît pas.
L’alternative, quand le cadrage n’est pas possible
Si vous ne pouvez pas borner la durée — parce que le système est trop opaque, parce que personne ne sait plus ce qu’il fait, parce que l’activité ne peut pas s’arrêter — alors la réécriture n’est pas la bonne option.
Il reste le remboursement progressif : on modernise ce qu’on touche, au moment où on le touche. Chaque évolution laisse la zone concernée un peu plus propre qu’elle ne l’était. C’est lent, c’est invisible, ça ne fait rêver personne, et ça marche.
C’est ce que nous appelons la modernisation du code legacy — sans big-bang, sans interruption de service, et sans pari sur une durée qu’on serait incapable de tenir.
Comment en parler à votre direction
Arrêtez de présenter la dette comme un sujet technique. Personne ne finance de la beauté de code, et c’est normal.
Présentez-la comme ce qu’elle est : une charge financière récurrente et invisible. Une fonctionnalité qui prenait dix jours en prend trente. Ces vingt jours supplémentaires se paient tous les mois, ils ne figurent nulle part, et ils augmentent.
Chiffrez l’intérêt, jamais le capital. Personne ne veut savoir combien il faudrait pour tout réparer. Tout le monde veut savoir combien ça coûte de ne rien faire.
Nous chiffrons la dette avant de proposer quoi que ce soit — c’est le rôle de notre audit technique, et parfois d’un économiste technique quand l’arbitrage engage plusieurs années. Si vous entendez « il faudrait refactoriser » depuis trop longtemps, parlons-en.
Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.
Ajouter aux sources préférées
