Priorisation technique : pourquoi le code parfait ne paie pas les salaires

Il existe deux façons de tuer une entreprise avec du code. La première est de livrer vite n'importe comment jusqu'à ce que plus rien ne tienne. La seconde est de vouloir un code impeccable pendant que la trésorerie se vide. La seconde est plus rare, mais elle est tout aussi létale — et beaucoup plus difficile à combattre, parce qu'elle est portée par des gens compétents et de bonne foi.

Arbitrer entre les deux est le cœur du métier de directeur technique.

La dette technique n'est pas un problème moral

La dette technique est un instrument financier, pas une faute. On l'utilise pour aller plus vite maintenant, en acceptant de payer des intérêts plus tard. Une jeune entreprise qui cherche son marché a raison de s'endetter : à quoi bon un système parfait pour un produit que personne n'achètera ?

Le vrai problème n'est pas d'avoir de la dette, c'est de ne pas savoir combien elle coûte. Une dette non mesurée devient une dette non arbitrable, et une dette non arbitrable finit par décider à votre place.

Rendre la dette visible en trois colonnes : où elle se situe, ce qu'elle coûte par mois (temps perdu, incidents, surcoût d'infrastructure), et ce que coûterait sa résorption. Tant que ces trois chiffres ne sont pas posés, tout débat sur le refactoring est une bataille d'opinions.

La question à poser avant tout refactoring

Une seule question tranche 80 % des cas : est-ce que cette partie du système va changer dans les six prochains mois ?

• Code moche, mais stable et jamais modifié : on ne touche à rien. Il fonctionne, il ne coûte rien.
• Code moche, modifié toutes les semaines : c'est là que la dette coûte réellement de l'argent, chaque jour. Priorité haute.
• Code propre, mais sur une fonctionnalité qu'on va abandonner : ne pas l'améliorer, le supprimer.

Le refactoring se justifie par la fréquence de changement et le risque, jamais par l'esthétique. « Ce code me déplaît » n'est pas un argument recevable en comité de direction — et c'est très bien ainsi.

Une grille d'arbitrage simple

Pour chaque chantier technique candidat, notez trois dimensions de 1 à 5 :

• Impact business : ce que ça débloque en revenus, en délai de livraison ou en satisfaction client.
• Risque évité : probabilité et gravité de ce qui arrive si on ne fait rien (panne, fuite de données, blocage réglementaire).
• Coût : jours-homme, en incluant la recette et la migration.

Le score (Impact + Risque) ÷ Coût donne un classement discutable mais objectivable. Il ne remplace pas la décision, il la rend explicable — ce qui est exactement ce dont un dirigeant a besoin pour dire oui.

La règle des 20 % : sanctuariser sans bloquer

En pratique, la méthode qui tient dans la durée consiste à réserver une part fixe de la capacité de l'équipe — entre 15 % et 25 % — à la dette et à la fiabilité, sprint après sprint, sans jamais avoir à la renégocier.

Cette part n'est pas un budget de confort. Elle sert en priorité aux sujets qui touchent :

1. La sécurité et la conformité.
2. Les composants modifiés le plus souvent.
3. Ce qui ralentit le déploiement ou allonge le retour d'information (tests lents, environnements instables).

Le reste attend. Et il attend explicitement, dans une liste visible, pas dans la frustration silencieuse de l'équipe.

Les trois moments où l'on refuse de refactorer

Il y a des périodes où la bonne décision est de laisser la dette grossir en conscience :

• Avant une échéance commerciale majeure : on gèle tout ce qui n'est pas la livraison, et on planifie la remise en état pour la semaine d'après — dans le calendrier, pas dans les intentions.
• Sur un produit dont l'avenir n'est pas tranché : investir dans un système qu'on arrêtera peut-être est un pur gaspillage.
• Quand la trésorerie est tendue : la survie prime. Un système élégant dans une entreprise liquidée n'a jamais servi à personne.

Dans ces trois cas, la responsabilité du CTO est de documenter ce qui a été volontairement reporté et le risque associé. Une dette assumée et tracée est saine ; une dette subie et tue ne l'est pas.

Faire accepter les arbitrages par l'équipe

Le point le plus délicat n'est pas la décision, c'est son acceptation. Les développeurs vivent la dette au quotidien : leur dire « non » sans explication détruit la confiance.

Trois pratiques changent tout : rendre publique la liste des chantiers reportés avec la raison ; annoncer une date de réexamen ; et tenir cette date. Une équipe accepte très bien de repousser un chantier ; elle supporte mal de ne pas savoir pourquoi.

Ces arbitrages sont au centre de notre accompagnement en direction technique : rendre le coût de la dette lisible pour la direction, et rendre les décisions compréhensibles pour l'équipe.

FAQ

Quelle part du temps consacrer à la dette technique ?

Entre 15 % et 25 % de la capacité de l'équipe, de façon constante. En dessous de 10 %, la dette s'accumule plus vite qu'elle n'est résorbée. Au-dessus de 30 % de façon durable, c'est généralement le signe d'un problème d'architecture qui appelle une décision structurante plutôt qu'un nettoyage continu.

Comment expliquer la dette technique à un dirigeant non technique ?

En euros et en délais, jamais en concepts. « Cette partie du système nous fait perdre trois jours par mois et provoque un incident par trimestre ; deux semaines de travail suppriment 80 % de ce coût » est un argument qui se décide en réunion. « Le code est mal structuré » ne l'est pas.

Faut-il tout réécrire quand un système devient trop lourd ?

Presque jamais. Les réécritures complètes échouent dans une large majorité des cas parce qu'elles gèlent l'évolution du produit pendant des mois tout en reproduisant les mêmes erreurs. L'approche progressive — isoler un périmètre, le remplacer, recommencer — est plus lente sur le papier et bien plus sûre dans les faits.