Dette technique :
la mesurer, la rembourser.

La métaphore de Ward Cunningham est financière, et il faut la prendre au sérieux : on emprunte du temps aujourd'hui, on paie des intérêts à chaque livraison. Une dette bien choisie est un bon investissement. Une dette qu'on ne mesure pas finit par consommer toute la capacité de l'équipe.

La métaphore, correctement

Ward Cunningham a introduit le terme en 1992, et il est presque toujours mal cité. Sa formulation d'origine ne parlait pas de code bâclé. Elle parlait de l'écart entre votre compréhension du domaine au moment où vous avez écrit le code et votre compréhension aujourd'hui. Livrer vite pour apprendre est légitime ; ne pas mettre le code à jour quand la compréhension progresse, voilà la dette.

Le principal, c'est ce que coûterait la remise en état. Les intérêts, c'est le surcoût payé sur chaque changement tant qu'elle est là. Une dette dans du code jamais modifié ne produit aucun intérêt : elle est théorique. Une dette au cœur du système que vous touchez chaque semaine produit des intérêts composés.

Les quatre types (le quadrant de Fowler)

Martin Fowler distingue deux axes — délibérée ou involontaire, prudente ou imprudente — ce qui donne quatre cas très différents :

• Délibérée et prudente : « On sait que la bonne structure serait celle-là, mais on livre pour la démo de vendredi, et on revient. » Un vrai emprunt, avec un plan de remboursement. Parfaitement défendable.
• Délibérée et imprudente : « On n'a pas le temps de faire de la conception. » Un emprunt sans intention de rembourser, à taux variable.
• Involontaire et prudente : « Maintenant qu'on a livré, on comprend ce qu'il aurait fallu faire. » Inévitable, saine, et c'est exactement le cas d'origine de Cunningham. C'est le prix de l'apprentissage.
• Involontaire et imprudente : « C'était quoi, la conception ? » L'équipe ne savait pas ce qu'elle ne savait pas. Le seul remède est la montée en compétence.

L'intérêt du quadrant est managérial : la seule case qui relève d'un problème de processus est la deuxième. Traiter les quatre de la même façon revient à reprocher à une équipe d'avoir appris.

La mesurer avec des chiffres qui parlent

« Le code est sale » ne débloque aucun budget. Les mesures suivantes, oui, parce qu'elles se traduisent en argent et en dates :

• Délai de livraison — temps entre un commit et sa mise en production. S'il passe de deux jours à deux semaines, votre capacité de réaction commerciale a été divisée par cinq.
• Taux d'échec des changements — proportion des déploiements qui provoquent un incident ou un retour arrière. Au-dessus de quinze pour cent, l'équipe passe son temps à réparer.
• Répartition de l'effort — pourcentage du temps consacré aux correctifs et au support par rapport aux fonctionnalités neuves. La courbe de cette répartition sur douze mois est le graphique le plus convaincant que vous puissiez montrer à une direction.
• Zones à haut risque — croisez la fréquence de modification de chaque fichier avec sa complexité. Les fichiers en haut à droite sont votre dette réelle ; le reste est de la dette théorique.
• Délai d'intégration d'un nouvel arrivant — combien de semaines avant qu'une nouvelle personne livre en autonomie. C'est un excellent indicateur de la clarté de votre architecture.

Les outils qui affichent une dette en « jours-homme » à partir d'une analyse statique donnent un chiffre rassurant et largement fictif. Ils sont utiles pour suivre une tendance, pas pour bâtir un dossier d'affaires.

Une stratégie de remboursement qui tient

Trois approches, à combiner :

1. L'amélioration opportuniste. Chaque fonctionnalité inclut le nettoyage du code qu'elle traverse. Ce n'est pas une ligne budgétaire séparée, c'est le coût normal du travail. C'est la seule approche qui survit à un trimestre difficile.
2. Une capacité réservée. Dix à vingt pour cent de chaque sprint pour la dette, protégés comme du travail de fonctionnalité — dans le backlog, estimés, visibles. Ce qui n'est pas dans le sprint n'existe pas.
3. Le chantier ciblé. Pour les gros blocages structurels, un projet nommé avec un résultat mesurable : « ramener le temps de build de 40 à 5 minutes », « supprimer la dépendance à la base partagée ». Jamais « refactorer le module de facturation », qui n'a ni fin ni preuve de succès.

Et la règle de survie : ne laissez jamais entrer de nouvelle dette imprudente pendant que vous remboursez l'ancienne. Une définition de « fini » sérieuse est ce qui tient cette ligne.

Quand la dette est trop grosse

Il existe un point où le remboursement progressif ne suffit plus : quand la plateforme n'est plus supportée, quand plus personne dans l'organisation ne comprend le système, ou quand le modèle de données interdit ce que le métier demande maintenant. Là, la question devient refactorer ou remplacer — et la réponse est presque toujours le remplacement progressif par le motif de l'étrangleur, pas la réécriture d'un bloc.

Notre position

On mesure votre situation de départ avant de bâtir quoi que ce soit, et on remesure après le déploiement. La dette technique fait partie de cette mesure : si votre système coûte trois fois trop cher à faire évoluer, c'est un chiffre, pas une opinion. Et si la bonne réponse est de garder ce que vous avez plutôt que de tout remplacer, on vous le dira — même si ça réduit le mandat.

Questions fréquentes

Qu'est-ce que la dette technique ?

C'est le coût futur des raccourcis pris dans la conception ou le code. Comme une dette financière, elle a un principal — le coût de la remise en état — et des intérêts — le surcoût payé sur chaque changement tant qu'elle est là.

La dette technique est-elle toujours mauvaise ?

Non. Une dette délibérée et assumée, contractée pour livrer plus tôt et apprendre du marché, est un investissement rationnel — à condition qu'elle soit inscrite quelque part et remboursée. La dette dangereuse est celle qu'on ne mesure pas et qu'on ne rembourse jamais.

Comment mesurer la dette technique ?

Avec des indicateurs qui se traduisent en argent : délai entre un commit et sa mise en production, taux d'échec des changements, part du temps consacrée aux correctifs plutôt qu'aux fonctionnalités, et croisement entre fréquence de modification et complexité des fichiers.

Quel pourcentage du temps consacrer à la dette technique ?

Dix à vingt pour cent de la capacité de chaque sprint est un point de départ courant, à condition que ce travail soit dans le backlog, estimé et visible. Le reste doit se faire de façon opportuniste, en nettoyant le code que les fonctionnalités traversent.

À lire ensuite

• Refactoring : changer sans casser
• Code smells : le catalogue utile
• Agile : c'est quoi, vraiment ?
• Développement logiciel sur mesure

Parlons de votre projet

Vous soupçonnez que votre système vous coûte plus cher qu'il ne devrait, sans pouvoir le chiffrer ? C'est exactement ce que la séance de direction IA met en chiffres.