Dette technique ou roadmap : quoi financer ce trimestre

Un trimestre compte trois engagements produit, et le même composant de tarification doit bouger pour deux d'entre eux. Chaque changement y prend plus de temps que le précédent, les correctifs de facturation reviennent, et personne ne sait si le plus sûr est de maintenir le code en l'état, de le corriger par tranches, de le restructurer avant de livrer ou de mesurer d'abord. La question n'est pas de savoir si la dette existe. Elle porte sur ce qu'il faut financer maintenant, et sur ce qu'on reporte avec une échéance.

Cet article propose une méthode de décision plutôt qu'un inventaire des signes de dette. Il compare quatre options sur le même horizon de 26 semaines, montre où le résultat bascule, et donne le mémo qui permet de trancher en comité produit.

Ce que recouvre la dette technique, et ce qui la rend décidable

La dette technique désigne du travail de conception ou de code différé, dont le coût s'accumule tant qu'il n'est pas repris. Ward Cunningham emploie la métaphore dans un rapport de 1992 publié en addendum de la conférence OOPSLA : livrer du code de premier jet revient à contracter une dette. Il observe qu'une dette légère accélère le développement tant qu'une réécriture la rembourse rapidement, et que chaque minute passée sur du code pas tout à fait juste compte comme un intérêt versé sur cette dette.

Martin Fowler reprend l'image dans un billet publié en 2003 et réécrit en 2019. Pour lui, l'effort supplémentaire nécessaire pour ajouter des fonctionnalités est l'intérêt payé sur la dette. Il note aussi que l'estimation de ce coût reste peu précise, ce qui justifie, ici, de raisonner par fourchettes.

Ces définitions ne disent pas quoi financer. Pour décider, il faut un obstacle documenté : le système touché, le prochain changement qu'il empêche ou ralentit, les preuves disponibles et ce qui reste inconnu. Le Software Engineering Institute de Carnegie Mellon recommande d'abord un inventaire concret de la dette, avec les conséquences de son accumulation, puis d'évaluer son impact dans le temps et son coût sur tout le cycle de vie. Son billet de décembre 2019 résume la question : la dette concerne la capacité à anticiper le changement et à en comprendre l'impact.

Une ligne sans preuve n'est pas un arbitrage. Si l'équipe ne sait pas quels changements passent par le composant, la comparaison des options n'a pas de base. Un bon obstacle tient en quatre lignes : système, changement bloqué, preuve, inconnue. Le reste de l'article suppose que ces quatre lignes existent.

Maintenir, corriger par tranches, restructurer ou mesurer d'abord : quatre options sur le même horizon

Les quatre options n'ont pas la même forme de coût. Maintenir ne demande aucun effort initial, mais chaque changement paie l'intérêt complet. Corriger par tranches étale le travail avant chaque changement prévu. Restructurer engage un chantier avant tout nouvel engagement. Mesurer d'abord achète de l'information avant d'engager la capacité. Pour les comparer, il faut fixer le même horizon et la même capacité pour les quatre, et nommer la fonctionnalité qui attend pendant ce temps.

Exemple : un composant de tarification calcule le prix et la facturation de trois offres prévues aux semaines 6, 14 et 22. Ses règles de prix sont dupliquées dans plusieurs modules, sans tests de non-régression. L'équipe dispose de 150 h par semaine. La restructuration occuperait 60 h par semaine, une tranche 40 h, une investigation 20 h. Au central, la remédiation complète coûte 320 h (de 200 à 480 h), l'intérêt par changement 100 h (de 60 à 160 h), et trois changements sont confirmés.

Un calcul sur 26 semaines, à ces hypothèses publiées, donne au central :

Le résultat ne suit pas l'intuition habituelle. Au central, maintenir reste le moins coûteux, et corriger par tranches coûte plus cher que restructurer. Le modèle ne dit pas que la dette est sans importance : il montre que, pour ces trois changements, l'effort de remédiation ne se rembourse pas sur l'horizon. En état léger, maintenir coûte 128 h. En état lourd, restructurer devient le moins coûteux, à 277 h, contre 600 h pour maintenir. Le choix dépend donc de l'état réel de la dette, que l'équipe ne connaît pas encore. C'est là qu'intervient l'investigation.

Tant qu'aucun changement n'arrive, maintenir ne coûte que les défauts, soit environ 1,4 h par semaine. La courbe de restructuration démarre plus haut, car le chantier de 320 h s'achève vers la sixième semaine, puis elle ne croît plus que de l'intérêt résiduel. Pour choisir par où commencer un chantier de ce type, l'article Platform engineering pour une scale-up : par où commencer sans sur-ingénierie présente une démarche de départ.

Chiffrer le coût du report sans fausse précision

La fourchette d'effort compte plus que le point central. Dans l'exemple, la remédiation complète va de 200 à 480 h, et l'intérêt par changement de 60 à 160 h. Pour choisir ce qu'il faut mesurer avant de trancher, le SEI propose de s'appuyer sur des signaux observés : le nombre de modifications de chaque élément de code (bug churn et change churn), la taille des unités de code touchées et le retour des développeurs. Ses auteurs présentent aussi la corrélation entre changements fréquents et défauts de conception comme une question de recherche, et non comme un résultat établi.

Le coût du report se lit donc comme une pente. Chaque changement prévu sur le composant ajoute son intérêt au statu quo. Avec 100 h par changement, maintenir coûte 336 h avec trois changements, et chaque changement confirmé en ajoute 100 de plus. La restructuration commence plus haut, à 331 h même sans aucun changement, mais sa pente est plus faible : après le chantier, un changement ne paie plus que 10 % de son intérêt.

Le seuil dépend des hypothèses, et le classement tient à peu de chose. Une remédiation de 296 h au lieu de 320 h, ou un intérêt de 164 h par changement au lieu de 100 h, suffit à faire basculer la décision vers la restructuration. Il ne faut que 24 h de moins sur la remédiation, soit 7 %, pour changer le classement. Les défauts et les heures par défaut, eux, ne font basculer la décision à aucune valeur testée jusqu'à quatre fois le central.

Libérer des heures ne revient pas à les gagner. Au central, la restructuration libère potentiellement 204,9 h sur l'horizon, mais elle consomme 320 h de remédiation : le net est nul, rien n'est redéployé et la colonne de dépense reste à zéro. Trois colonnes distinctes sont donc nécessaires : les heures libérées, la capacité redéployée sur la roadmap, et la réduction de dépense. Ces trois colonnes ne se confondent pas. Des heures nettes n'apparaissent qu'en état lourd, et ne se répartissent alors entre roadmap et dépense qu'à l'aide de parts fixées à l'avance.

Le mémo d'investissement et le seuil qui fait basculer la décision

Le livrable est un mémo de deux pages, pas un tableur. Il répond à dix-sept champs, toujours dans le même ordre, pour que le comité compare des dettes comparables. Voici le mémo rempli pour le composant de tarification, avec les valeurs du central et les fourchettes entre parenthèses.

Le mémo ne se limite pas au central. Le modèle calcule aussi le regret, c'est-à-dire l'écart entre le coût d'une option et le meilleur coût possible dans l'état de la dette qui se réalise. Quand on ne sait pas dans quel état on se trouve, l'option qui limite le regret maximal est la plus robuste.

Heures totales sur 26 semaines, par état de la dette. Le regret maximal est le plus grand écart, dans un état, avec le meilleur total de cet état.

Autre cas : un ancien export inchangé depuis plusieurs cycles, sans changement prévu, prend le sens inverse. Maintenir coûte 12 h sur 26 semaines, corriger par tranches la même chose puisqu'aucune tranche ne se déclenche, et restructurer 203 h. Mesurer d'abord coûte 36 h, dont 24 h d'investigation pour une dette qui en coûte 12 : l'investigation n'a de sens qu'à l'arrivée d'un changement. Restructurer ne redevient compétitif qu'à 15 changements confirmés. Le mémo conclut donc à maintenir, avec un budget nul et un réexamen dès qu'un changement est confirmé sur l'export. Une amélioration esthétique seule ne justifie pas de consommer la capacité.

Le même mémo sert aussi à situer la décision dans le budget. Un même choix se lit différemment selon le scénario de croissance retenu, comme le montre Budget cloud d'un SaaS en croissance : prévoir trois scénarios.

Financer une première tranche, fixer son arrêt et revoir la décision

Le modèle désigne l'investigation de 40 h comme l'option qui limite le regret maximal ; au central, maintenir reste le moins coûteux (336 h contre 376 h). Elle affiche un regret maximal de 192 h, contre 323 h pour maintenir, 240 h pour corriger par tranches et 421 h pour restructurer. Elle suppose toutefois une information parfaite au terme de l'investigation, ce qui surestime sa valeur.

La première tranche a donc un budget plafonné, un critère mesurable et une condition d'arrêt. Dans l'exemple, l'investigation mesure le surtravail observé sur les trois dernières évolutions du composant et cartographie ses dépendances. Aucune tranche de code n'est engagée avant ce relevé. La décision se prend sur le chiffre : au-delà de 164 h de surtravail par changement, ou à cinq changements confirmés, on passe à la restructuration ; sinon on maintient.

Une tranche se lit aussi au regard de la suivante. Dans l'exemple, la première tranche de 96 h évite environ 82 h de dette sur l'horizon, la deuxième environ 55 h pour le même coût, et la troisième environ 27 h. Chaque tranche rapporte moins que la précédente. Étaler sans fin le travail n'est donc pas une stratégie gratuite, et la tranche suivante doit être réexaminée avec les mesures de la précédente.

Après les premiers changements, la revue compare le prévu et l'observé sur le même composant. Pour lire l'écoulement des livraisons, le programme DORA (DevOps Research and Assessment) propose cinq mesures, qui s'appellent officiellement Change lead time, Deployment frequency, Failed deployment recovery time, Change fail rate et Deployment rework rate. Elles se mesurent de préférence application par application ou service par service. Il s'agit d'un programme de recherche sur la livraison logicielle, qui ne dit pas quelle dette financer : il permet seulement de vérifier si la livraison ralentit.

Le calendrier externe peut aussi forcer une tranche. Une échéance de support, comme celles décrites dans Support étendu EKS et RDS : calendrier de fin 2026, tarifs et calcul de l'exposition, transforme une dette différée en date à tenir. Pour faire qualifier les obstacles de votre plateforme avant d'engager le prochain trimestre, la page Audit d'infrastructure cloud : savoir quoi corriger en premier décrit la démarche.

Sources officielles et limites de lecture

Le modèle suppose une source de dette par cas, un intérêt constant par changement, une réduction linéaire par tranche et des défauts répartis uniformément. Il ne valorise ni le retard de la fonctionnalité déplacée ni le risque d'incident majeur, et ne calcule rien au-delà de 26 semaines. Remplacez ces hypothèses par les relevés de votre équipe avant de décider.

Sources

1. Ward Cunningham, rapport d'expérience sur le système WyCash Portfolio Management System, addendum OOPSLA '92, copie en ligne, http://c2.com/doc/oopsla92.html, lue le 9 novembre 2026.
2. Martin Fowler, « Technical Debt », billet publié le 21 mai 2019, https://martinfowler.com/bliki/TechnicalDebt.html, lu le 9 novembre 2026.
3. Software Engineering Institute, Carnegie Mellon, « Managing Technical Debt: Identify Technical Debt Items », fiche du 22 septembre 2022, https://www.sei.cmu.edu/library/managing-technical-debt-identify-technical-debt-items/, lue le 9 novembre 2026.
4. Software Engineering Institute, « Data-Driven Management of Technical Debt », billet du 16 décembre 2019, https://www.sei.cmu.edu/blog/data-driven-management-of-technical-debt/, lu le 9 novembre 2026.
5. DORA, « Software delivery performance metrics », page mise à jour le 5 janvier 2026, https://dora.dev/guides/dora-metrics/, lue le 9 novembre 2026.