Dette technique : comprendre, mesurer et rembourser

Mise à jour : 23/12/2025

Imaginez cette situation : vous rejoignez une équipe qui gère une application e-commerce. Le premier jour, on vous demande d’ajouter un nouveau moyen de paiement. « C’est simple », vous dit-on, « juste quelques lignes dans le module de paiement ».

Vous ouvrez le fichier PaymentService.java. Il fait 3 000 lignes. Les commentaires datent de 2019 et ne correspondent plus au code. Vous trouvez cinq méthodes différentes pour calculer les taxes, dont trois sont commentées « À supprimer après migration ». La migration date de 2021.

Vous passez trois jours à comprendre le code avant d’écrire une seule ligne. Votre modification casse les tests… qui n’avaient pas été mis à jour depuis deux ans. Le déploiement échoue car la configuration de production diverge de celle de test.

Vous venez de rencontrer la dette technique.

Qu’est-ce que la dette technique ?

Une métaphore financière que tout le monde comprend

La dette technique fonctionne exactement comme un emprunt bancaire. Quand vous prenez un raccourci dans le code pour livrer plus vite, vous « empruntez » du temps au futur. Ce temps économisé aujourd’hui devra être « remboursé » plus tard, avec des « intérêts » sous forme de complexité accrue et de maintenance difficile.

Concept financier	Équivalent technique
Emprunt	Raccourci pris pour livrer plus vite
Principal	Temps nécessaire pour corriger proprement
Intérêts	Temps perdu à chaque modification du code endetté
Faillite	Système devenu impossible à maintenir

Ward Cunningham, créateur du premier wiki, a inventé cette métaphore en 1992 pour expliquer à ses dirigeants non-techniques pourquoi le code avait besoin d’être retravaillé régulièrement.

Définition simple

La dette technique désigne l’ensemble des compromis techniques qui rendent un système plus difficile à maintenir, faire évoluer ou comprendre.

Ces compromis peuvent être :

Délibérés : « On sait que ce n’est pas idéal, mais on livre quand même pour respecter le délai »
Involontaires : « On ne savait pas qu’il existait une meilleure approche, on l’a découvert après »

Trois analogies pour bien comprendre

Imaginez une maison construite rapidement pour respecter les délais :

Les fils électriques passent au-dessus des murs au lieu d’être encastrés
La plomberie utilise des raccords temporaires
Aucun plan n’a été conservé

La maison est habitable, mais chaque rénovation devient un cauchemar. Vous passez plus de temps à comprendre l’existant qu’à faire les travaux.

Ce que la dette technique n’est PAS

Attention aux confusions courantes :

Ce n’est PAS de la dette technique	Pourquoi
Un bug	Un bug est une erreur à corriger, pas un compromis
Du code que vous n’aimez pas	La préférence personnelle n’est pas un critère
Du vieux code qui fonctionne	L’âge n’est pas un problème si le code reste maintenable
Des réunions improductives	C’est du « overhead » organisationnel, pas technique

Le quadrant de la dette technique

Martin Fowler, architecte logiciel reconnu, propose une classification en quatre quadrants selon deux axes : délibéré/inadvertant et prudent/imprudent.

Quadrant de la dette technique de Martin
Fowler

Comprendre les deux axes

Avant de détailler chaque quadrant, clarifions les termes :

Délibéré vs Inadvertant : Avez-vous consciemment choisi cette approche, ou l’avez-vous fait sans savoir qu’il existait mieux ?
Prudent vs Imprudent : Avez-vous un plan pour corriger, ou espérez-vous que le problème disparaisse tout seul ?

Délibéré + Prudent : la dette « stratégique »

L’équipe prend une décision consciente avec un plan de remboursement.

« Nous savons que cette solution n’est pas optimale, mais nous avons un délai à respecter. Nous prévoyons de refactoriser dans le prochain sprint. »

Exemple concret : Une startup lance son MVP (Minimum Viable Product) avec une base de données simple. L’équipe sait qu’elle devra migrer vers une architecture plus robuste si le produit réussit. Elle documente cette décision et prévoit la migration au trimestre suivant.

Pourquoi c’est acceptable : La dette est documentée, planifiée, et le bénéfice (time-to-market) justifie le coût futur.

Délibéré + Imprudent : la dette « négligente »

L’équipe prend un raccourci en pleine conscience, sans plan de correction.

« On n’a pas le temps pour le design. On verra plus tard. »

Exemple concret : Un développeur copie-colle du code au lieu de créer une fonction réutilisable. Il sait que c’est mal, mais « c’est plus rapide ». Aucun ticket n’est créé pour corriger. Ce « plus tard » n’arrive jamais.

Pourquoi c’est dangereux : La dette s’accumule silencieusement. Quand le code dupliqué doit être modifié, il faut le faire à dix endroits différents.

Inadvertant + Prudent : la dette « d’apprentissage »

L’équipe découvre une meilleure approche après coup.

« Maintenant qu’on comprend mieux le domaine métier, on voit comment on aurait dû structurer le code. »

Exemple concret : Après six mois de développement, l’équipe réalise que le modèle de données ne correspond pas bien aux cas d’usage réels. Ce n’est pas une erreur : au départ, personne ne connaissait assez bien le domaine.

Pourquoi c’est normal : Une équipe qui ne génère jamais ce type de dette n’apprend probablement pas assez vite. C’est le signe d’un développement itératif sain.

Inadvertant + Imprudent : la dette « invisible »

L’équipe accumule de la dette sans s’en rendre compte par manque de compétence ou d’expérience.

« C’est quoi la séparation des responsabilités ? »

Exemple concret : Un développeur junior met toute la logique métier dans les contrôleurs. Il ne connaît pas les patterns MVC ou les principes SOLID. Personne ne fait de revue de code. Le problème grandit pendant des mois.

Pourquoi c’est critique : Cette dette est invisible jusqu’à ce qu’elle explose. L’équipe ne sait même pas qu’elle a un problème.

Tableau récapitulatif

Quadrant	Reconnaissance	Action recommandée
Délibéré + Prudent	« On sait, on a un plan »	Documenter, planifier le remboursement
Délibéré + Imprudent	« On sait, on s’en fiche »	Créer immédiatement un ticket de correction
Inadvertant + Prudent	« On ne savait pas, maintenant oui »	Prioriser selon l’impact
Inadvertant + Imprudent	« On ne sait pas qu’on ne sait pas »	Former l’équipe, instaurer les revues de code

Les six types de dette technique

La dette technique ne se limite pas au code. Elle peut affecter différentes couches de votre système. Comprendre ces six types permet de mieux identifier et traiter la dette dans votre contexte.

Les 6 types de dette technique : Code, Design, Documentation, Infrastructure,
Tests et Processus disposés autour d'un
centre

Dette de code : la plus visible

C’est ce à quoi on pense spontanément quand on parle de dette technique. Elle se manifeste directement dans le code source.

Signaux d’alerte :

Signal	Ce que vous voyez	Pourquoi c’est un problème
Duplication	Le même code copié à 5 endroits	Un bug doit être corrigé 5 fois
Complexité	Fonction de 500 lignes, 10 niveaux d’indentation	Impossible à tester, à comprendre
Nommage	Variables `temp`, `data`, `x1`, `processData2`	Le code ne s’auto-documente pas
Code mort	Fonctions commentées « au cas où »	Pollue la base de code, induit en erreur

Exemple concret :

# ❌ Dette de code
def process(d):
    temp = d['a'] * 1.2
    if d['b'] > 100:
        temp = temp - 10
    return temp

# ✅ Code propre
def calculate_discounted_price(order: dict) -> float:
    base_price = order['amount'] * TAX_RATE
    if order['quantity'] > BULK_THRESHOLD:
        base_price -= BULK_DISCOUNT
    return base_price

Comment la détecter : outils d’analyse statique (SonarQube, ESLint), revues de code, métriques de complexité cyclomatique.

Dette de design : la plus coûteuse

Concerne l’architecture et la structure globale du système. Elle est plus difficile à voir mais plus coûteuse à corriger.

Signaux d’alerte :

Signal	Ce que vous voyez	Pourquoi c’est un problème
Couplage fort	Modifier A casse B, C et D	Effet domino incontrôlable
Abstraction inadaptée	Interface avec 50 méthodes	Impossible à implémenter correctement
« Big Ball of Mud »	Aucune structure claire	Personne ne comprend le système
Dépendances circulaires	A dépend de B qui dépend de A	Impossible de tester isolément

Exemple concret : Votre module de paiement appelle directement la base de données, le service d’emails, le système de logs et l’API externe. Pour tester le calcul d’une réduction, vous devez configurer quatre systèmes.

Comment la détecter : diagrammes de dépendances, temps pour ajouter une fonctionnalité simple, nombre de fichiers modifiés par commit.

Dette de documentation : la plus négligée

Souvent considérée comme « moins importante », elle coûte pourtant très cher en temps d’onboarding et en erreurs évitables.

Signaux d’alerte :

Signal	Ce que vous voyez	Pourquoi c’est un problème
README obsolète	« Exécuter `npm start`… » mais le projet utilise yarn	Les nouveaux perdent du temps
API non documentée	Découverte par essai-erreur	Erreurs, frustration, perte de temps
Commentaires périmés	`// TODO: à supprimer après migration 2021`	Induisent en erreur, pires que rien
Absence d’ADR	Personne ne sait pourquoi on a fait ce choix	On refait les mêmes erreurs

ADR (Architecture Decision Record) : document court expliquant une décision architecturale, son contexte et ses conséquences.

Comment la détecter : temps d’onboarding des nouveaux, questions répétitives sur Slack, différence entre le README et la réalité.

Dette d’infrastructure : la plus risquée

Affecte les systèmes sous-jacents : serveurs, dépendances, configurations. Elle crée souvent des failles de sécurité.

Signaux d’alerte :

Signal	Ce que vous voyez	Pourquoi c’est un problème
OS obsolète	Ubuntu 18.04 (fin de support 2023)	Failles de sécurité non corrigées
Dépendances dépassées	`lodash@4.17.4` avec CVE connues	Vulnérabilités exploitables
Config manuelle	« Pour déployer, suivez ces 47 étapes »	Erreurs humaines, non reproductible
Environnements divergents	« Ça marche sur ma machine »	Bugs impossibles à reproduire

Exemple concret : Votre application utilise une version de Log4j vulnérable à CVE-2021-44228 (Log4Shell). Vous ne le savez pas car personne n’audite les dépendances transitives.

Comment la détecter : scanners de vulnérabilités (Trivy, Snyk), audits de dépendances, comparaison des environnements.

Dette de tests : la plus paralysante

Impacte directement la capacité à faire évoluer le système en confiance.

Signaux d’alerte :

Signal	Ce que vous voyez	Pourquoi c’est un problème
Couverture faible	20% du code testé	Les zones critiques sont peut-être dans les 80%
Tests fragiles	« Relance le build, ça va passer »	On ignore les vrais problèmes
Tests lents	CI de 45 minutes	Les développeurs contournent les tests
Tests couplés	L’ordre d’exécution compte	Résultats non reproductibles

Exemple concret : L’équipe a peur de refactoriser le module de paiement car les tests sont incomplets. Un bug en production coûte 10 000 € par heure. On préfère ne rien toucher.

Comment la détecter : métriques de couverture, taux d’échec des builds, temps de CI, questionnaire aux développeurs (« Avez-vous confiance pour modifier le code ? »).

Dette de processus : la plus insidieuse

Concerne les pratiques de l’équipe. Elle se cache derrière des habitudes acceptées comme « normales ».

Signaux d’alerte :

Signal	Ce que vous voyez	Pourquoi c’est un problème
Déploiement manuel	Procédure de 47 étapes	Erreurs, stress, temps perdu
Pas de revue de code	Merge direct sur main	Bugs non détectés, pas de partage de connaissances
Workflows incohérents	Chacun fait à sa manière	Impossible de s’entraider
Incidents chaotiques	Pas de procédure, improvisation	Temps de résolution long, stress

Exemple concret : Pour déployer, il faut se connecter en SSH à trois serveurs, exécuter des scripts dans un ordre précis, vérifier manuellement les logs, et envoyer un email à l’équipe. Un vendredi soir, la personne qui connaît la procédure est en vacances…

Comment la détecter : temps de déploiement, fréquence des incidents liés au processus, stress de l’équipe, dépendance à des individus.

Comment mesurer la dette technique ?

Ce qui ne se mesure pas ne s’améliore pas. La mesure permet aussi de convaincre le management d’investir dans le remboursement.

Le ratio de dette technique (TDR)

Le TDR (Technical Debt Ratio) est la métrique la plus utilisée. Elle compare le coût de correction au coût de développement :

TDR = (Coût de remédiation / Coût de développement) × 100

Comment l’interpréter :

TDR	Interprétation	Action recommandée
0-5%	Excellent, dette maîtrisée	Maintenir les bonnes pratiques
5-10%	Acceptable, surveillance nécessaire	Planifier du remboursement régulier
10-20%	Préoccupant, plan d’action requis	Allouer 20-30% du temps au remboursement
>20%	Critique, intervention urgente	Arrêter les nouvelles fonctionnalités

Exemple concret : SonarQube estime que corriger tous les problèmes de votre projet prendrait 45 jours-homme. Le projet a nécessité 300 jours-homme. TDR = (45/300) × 100 = 15% → Préoccupant.

Le temps de cycle (Cycle Time)

Mesure le temps entre le début du travail sur une tâche et sa mise en production.

Pourquoi c’est révélateur : une dette élevée rallonge ce temps car :

Plus de temps à comprendre le code existant
Plus de bugs à corriger avant le merge
Plus de tests manuels nécessaires
Plus de conflits avec d’autres modifications

Exemple concret :

Équipe	Temps de cycle moyen	Interprétation
A	2 jours	Code sain, processus fluide
B	2 semaines	Probable dette de code ou processus
C	1 mois	Dette critique, investigation urgente

Le code churn

Pourcentage de code modifié peu après son écriture (généralement < 3 semaines).

Comment le calculer :

# Avec git, voir les fichiers modifiés plusieurs fois récemment
git log --since="3 weeks ago" --name-only --pretty=format: | \
  sort | uniq -c | sort -rn | head -20

Ce qu’un churn élevé révèle :

Du code écrit trop vite, sans réflexion
Des exigences mal comprises au départ
Une architecture qui ne correspond pas au besoin
Des revues de code inefficaces

La complexité cyclomatique

Mesure le nombre de chemins indépendants dans le code. Concrètement, c’est le nombre de décisions (if, while, for, case) + 1.

Seuils recommandés :

Complexité	Risque	Action
1-10	Faible	Code maintenable
11-20	Modéré	Envisager de découper
21-50	Élevé	Refactoring recommandé
>50	Très élevé	Refactoring urgent

Exemple : une fonction avec 3 if et 2 for a une complexité de 6 (3 + 2 + 1). Testable et compréhensible.

Les indicateurs qualitatifs : ce que disent vos équipes

Au-delà des chiffres, certains signaux humains sont très révélateurs :

Vélocité en baisse

L’équipe livre moins malgré le même effort. Les estimations sont de plus en plus fausses car le code est de plus en plus imprévisible.
Incidents récurrents

Les mêmes problèmes reviennent. « Encore le service de paiement ? » C’est le signe d’une zone non traitée.
Onboarding long

Un nouveau membre met 3 mois à être productif au lieu de 3 semaines. Il passe son temps à demander « pourquoi c’est fait comme ça ? ».
Peur du refactoring

Personne n’ose toucher certaines zones. On entend : « Ne touche surtout pas à ce fichier, la dernière fois quelqu’un l’a modifié, tout a cassé ».
Dépendance à des individus

« Attends que Marie revienne de vacances, elle seule comprend ce module ». C’est de la dette de documentation et de design combinées.

Questionnaire rapide pour votre équipe

Posez ces questions en rétrospective :

Sur une échelle de 1 à 5, à quel point avez-vous confiance pour modifier le code existant ?
Combien de temps passez-vous à comprendre le code vs à l’écrire ?
Quelles zones du code évitez-vous de toucher ?
Combien de fois avez-vous dit « ça marche, on ne touche plus » ce mois-ci ?

Des réponses négatives révèlent une dette à investiguer.

Le cycle de gestion de la dette

Gérer la dette technique n’est pas un projet ponctuel mais un processus continu, comme l’entretien d’une maison ou d’un jardin.

Cycle de gestion de la dette technique en 5 étapes : Identifier, Mesurer,
Prioriser, Rembourser,
Prévenir

Étape 1 : Identifier — Où se cache la dette ?

La dette se cache partout. Utilisez plusieurs sources pour la débusquer :

Revues de code : quand un reviewer dit « on devrait refactoriser ça », créez un ticket. Ne laissez pas ces observations se perdre.

Rétrospectives : posez la question « Qu’est-ce qui vous a ralenti ce sprint ? ». Les réponses révèlent souvent de la dette cachée.

Onboarding : les questions des nouveaux sont précieuses. Si quelqu’un demande « pourquoi c’est fait comme ça ? », c’est probablement de la dette.

Étape 2 : Mesurer — Quelle est la gravité ?

Chaque élément de dette identifié doit être quantifié selon trois axes :

Axe	Question à poser	Exemple de réponse
Impact	Que se passe-t-il si on ne fait rien ?	« Les déploiements prendront 2h au lieu de 30min »
Effort	Combien de temps pour corriger ?	« 3 jours-homme pour refactoriser »
Risque	Quelles conséquences si on échoue ?	« Module critique, risque de régression »

Astuce : utilisez une échelle simple (S, M, L, XL) plutôt que des estimations précises. La précision viendra plus tard.

Étape 3 : Prioriser — Par où commencer ?

Tous les éléments de dette ne méritent pas le même traitement. Utilisez cette matrice :

	Impact faible	Impact élevé
Effort faible	Faire si le temps le permet	Priorité haute : quick wins à fort impact
Effort élevé	Ignorer ou reporter	Planifier soigneusement

Critères supplémentaires :

Fréquence de contact : une zone modifiée chaque semaine mérite plus d’attention qu’une zone touchée une fois par an
Criticité métier : le module de paiement passe avant la page « À propos »
Effet motivant : quelques quick wins au début motivent l’équipe

Étape 4 : Rembourser — Comment corriger ?

Plusieurs stratégies existent, choisissez selon votre contexte :

Stratégie	Comment ça marche	Quand l’utiliser
Sprints dédiés	1 sprint sur 4 pour la dette	Dette importante accumulée
Règle du scout	Améliorer chaque fichier touché	Dette diffuse, équipe disciplinée
Budget temps	20% de chaque sprint pour la dette	Équilibre features/dette
Équipe dédiée	« Debt Busters » à temps plein	Dette critique, urgence

Étape 5 : Prévenir — Comment éviter de recréer ?

Le meilleur remboursement est celui qu’on n’a pas à faire. Mettez en place des gardes-fous :

Standards de code automatisés

Linters et formatters configurés dans la CI. Le code qui ne respecte pas les standards ne peut pas être mergé.
Revues de code systématiques

Pas de merge sans au moins une approbation. Les revues détectent la dette avant qu’elle n’entre dans le code.
Tests obligatoires

Couverture minimale requise (ex: 80%). La CI bloque si le seuil n’est pas atteint.
Documentation continue

ADR (Architecture Decision Records) pour documenter les choix importants. « On a choisi X parce que Y, en acceptant Z comme inconvénient. »
Alertes sur les métriques

Notification quand le TDR dépasse un seuil, quand le temps de build augmente de plus de 20%, etc.

Stratégies de remboursement : comment convaincre et agir

Le plus dur n’est pas de savoir quoi faire, mais d’obtenir le temps et les ressources pour le faire. Voici des stratégies éprouvées.

La règle des 20% : intégrer la dette au quotidien

Google applique cette règle : 20% du temps des développeurs est consacré à des projets personnels ou de maintenance. Cela inclut le remboursement de dette.

Comment la vendre au management :

« On ne demande pas de temps supplémentaire. On utilise 20% du temps existant pour éviter que les 80% restants ne ralentissent de 50% dans 6 mois. »

Avantages :

Intégré au quotidien, pas de sprint « spécial » à justifier
Les développeurs choisissent ce qu’ils améliorent (motivation)
Amélioration continue sans à-coups

Inconvénients :

Difficile de traiter des chantiers importants
Nécessite de la discipline individuelle

Les sprints techniques : focus total

Certaines équipes dédient des sprints entiers à la dette : 1 sprint sur 4, ou 1 semaine par mois.

Comment la vendre au management :

« On fait une pause de 2 semaines sur les fonctionnalités pour que les 6 prochains mois soient 30% plus rapides. C’est un investissement, pas une perte. »

Avantages :

Permet de traiter des chantiers importants (migrations, refactorisations majeures)
Visible et mesurable

Inconvénients :

Peut créer une mentalité « on nettoie une fois par trimestre »
Difficile à maintenir si le business pousse

La règle du scout : améliorer en passant

« Laissez le campement plus propre que vous ne l’avez trouvé. »

Chaque développeur qui touche un fichier l’améliore un peu : renommer une variable, extraire une fonction, ajouter un commentaire.

Comment l’appliquer :

Checklist avant merge :
- [ ] Le code ajouté respecte les standards
- [ ] J'ai amélioré au moins une chose dans les fichiers touchés
- [ ] Je n'ai pas ajouté de nouvelle dette (ou je l'ai documentée)

Avantages :

Aucun temps dédié à négocier
Amélioration continue et progressive
Chaque développeur contribue

Inconvénients :

Peut ralentir les livraisons si mal dosé
Ne traite pas les gros chantiers

Le programme Debt Busters : l’équipe dédiée

Etsy, confrontée à une dette massive, a créé une équipe dédiée à la réduction de dette technique.

Fonctionnement :

L’équipe identifie les zones les plus problématiques (données + interviews)
Elle propose des plans de remédiation chiffrés
Elle accompagne les équipes produit dans le refactoring
Elle mesure les résultats et communique les gains

Quand l’envisager :

Dette critique accumulée sur plusieurs années
Équipes produit incapables de livrer à cause de la dette
Budget disponible pour une équipe dédiée (temporaire ou permanente)

Convaincre le management : parler leur langue

Le management ne comprend pas « dette technique ». Traduisez en termes business :

Vous dites…	Ils entendent…	Dites plutôt…
« On a de la dette technique »	« Les développeurs veulent s’amuser »	« Chaque fonctionnalité coûte 30% de plus qu’il y a 1 an »
« Il faut refactoriser »	« On va tout réécrire pour rien »	« On peut réduire le temps de livraison de 40% »
« Le code est sale »	« C’est subjectif »	« On a eu 3 bugs critiques ce mois liés à cette zone »
« On a besoin de temps »	« On perd de l’argent »	« Investir 2 semaines maintenant économise 2 mois sur l’année »

Les pièges à éviter

Piège 1 : Vouloir tout rembourser d’un coup

Le « grand projet de nettoyage » est séduisant mais voué à l’échec :

Le projet prend du retard (la dette est toujours plus profonde que prévu)
Le métier perd patience et coupe le budget
L’équipe s’épuise et se démotive
Pendant ce temps, nouvelle dette s’accumule ailleurs

À faire plutôt : traitez la dette comme un flux continu, pas un projet. 20% du temps, chaque sprint, pour toujours.

Piège 2 : Ne mesurer que le code

SonarQube ne voit que la dette de code. Mais la dette de processus (déploiement manuel) ou de documentation (onboarding de 3 mois) peut coûter bien plus cher.

À faire plutôt : évaluez les 6 types de dette régulièrement. Incluez des métriques humaines (temps d’onboarding, fréquence des « c’est comme ça »).

Piège 3 : Ignorer le contexte métier

Refactoriser un module abandonné est du temps perdu. Refactoriser le module de paiement qui génère 80% du chiffre d’affaires est critique.

À faire plutôt : priorisez selon l’impact business, pas selon la « propreté » technique. Un code « laid » mais stable et non modifié peut attendre.

Piège 4 : Blâmer les développeurs précédents

« Qui a écrit cette horreur ? » est contre-productif. La dette technique résulte presque toujours de :

Contraintes de délais imposées par le business
Évolution des exigences (le code était adapté à l’époque)
Apprentissage progressif (on ne savait pas mieux)
Départs sans transmission de connaissances

À faire plutôt : documentez sans juger. « Ce module a été créé sous contrainte de temps en 2020. Il nécessite une refonte pour supporter les nouveaux cas d’usage. »

Piège 5 : Attendre la « refonte totale »

Le mythe du « on va tout réécrire proprement » est dangereux :

Le projet de refonte prend 2x plus de temps que prévu
Pendant ce temps, il faut maintenir l’ancien ET développer le nouveau
Le nouveau système accumule sa propre dette (pression pour livrer)
Souvent, la refonte est abandonnée avant la fin

À faire plutôt : refactorisez progressivement. Remplacez module par module, en gardant le système fonctionnel à chaque étape.

À retenir

La dette technique est inévitable

Le vrai problème n’est pas d’en avoir, c’est de ne pas la gérer. Même les meilleures équipes en génèrent.
Six dimensions à surveiller

Code, design, documentation, infrastructure, tests, processus. Ne vous focalisez pas uniquement sur le code.
Mesurez pour convaincre

TDR, temps de cycle, complexité cyclomatique. Des chiffres valent mieux que des opinions pour obtenir du budget.
Priorisez par impact métier

Un module critique avec peu de dette est plus important qu’un module abandonné avec beaucoup de dette.
Remboursez régulièrement

20% du temps, règle du scout, sprints dédiés. Choisissez une approche et tenez-la dans la durée.
Prévenez plutôt que guérir

Standards automatisés, revues de code, tests obligatoires. La meilleure dette est celle qu’on ne crée pas.
Parlez business, pas technique

« Coût par fonctionnalité », « temps de livraison », « risque d’incident » convainquent mieux que « code propre ».

Références externes

Articles fondateurs

Technical Debt ↗ — Martin Fowler explique la métaphore originale et le quadrant
The WyCash Portfolio Management System ↗ — Ward Cunningham, créateur du concept, présente la dette technique (vidéo OOPSLA 1992)
Managing Technical Debt ↗ — Software Engineering Institute (SEI/CMU), recherche académique sur la gestion de la dette

Guides pratiques

Technical Debt: Everything You Need to Know ↗ — SonarSource, guide complet avec métriques et outils
A Taxonomy of Technical Debt ↗ — Classification académique des types de dette (IEEE)
Measuring and Managing Technical Debt ↗ — GitLab, intégration dans les pipelines CI/CD

Études de cas

How Etsy Manages Technical Debt ↗ — Programme Debt Busters chez Etsy
Paying Down Technical Debt at Spotify ↗ — Taxonomie et sprints dédiés chez Spotify
Technical Debt at Google ↗ — Chapitre du livre « Software Engineering at Google »