Dette Technique
#Définition Dette Technique
La dette technique (en anglais technical debt) est une métaphore financière introduite par Ward Cunningham en 1992 lors d'une présentation à l'OOPSLA Conference. Elle désigne le coût additionnel — en temps de développement, en maintenabilité dégradée et en risque opérationnel — résultant de choix de conception, d'architecture ou de code délibérément ou accidentellement suboptimaux. Pour approfondir, consultez la page service Legacy Modernization Nehos.
Côté implémentation, Martin Fowler l'a formalisée dans son quadrant à deux axes : (1) délibérée vs involontaire, (2) prudente vs imprudente. On distingue quatre types : délibéré-prudent (choix conscient, plan de remboursement prévu), délibéré-imprudent (raccourci sans plan), involontaire-prudent (décision correcte à l'époque, obsolète aujourd'hui), involontaire-imprudent (ignorance des bonnes pratiques).
Indicateurs mesurables : SonarQube Technical Debt Ratio (cible <5 %), couverture de tests (cible >80 %), cyclomatic complexity, Afferent/Efferent coupling, nombre de TODO/FIXME non traités, absence de documentation. Le coût de remboursement augmente avec le temps. Stratégies de gestion : règle des 20 % du sprint, refactoring opportuniste (Boy Scout Rule), refactoring planifié, Strangler Fig Pattern pour systèmes legacy volumineux.
La compréhension fine de Dette Technique différencie les équipes qui livrent des résultats de celles qui accumulent de la dette.
#Dette Technique expliqué simplement
Imagine que tu construis une maison et que, pour gagner du temps, tu relies les tuyaux avec du scotch au lieu de souder correctement. Ça tient pour l'instant. Mais dans six mois, tu auras une fuite, et la réparer coûtera bien plus cher que si tu l'avais faite proprement dès le départ — parce qu'il faudra casser les murs pour accéder aux tuyaux.
La dette technique, c'est exactement ça en code. Tu prends un raccourci aujourd'hui (copier-coller du code, sauter les tests, choisir une solution rapide plutôt que la bonne), et tu « dois » ce temps à l'avenir. Comme une vraie dette, elle produit des intérêts : plus tu attends, plus c'est cher à corriger.
Ce n'est pas forcément un problème en soi — une startup qui doit livrer vite peut choisir d'en accumuler, puis de la rembourser plus tard. Le problème, c'est quand on l'ignore ou quand on ne prévoit jamais de la corriger. À terme, l'équipe passe plus de temps à débugguer et à contourner les problèmes qu'à produire de nouvelles fonctionnalités.
Situation classique dans les projets que Nehos accompagne.
#Cas d'usage concrets
Exemple de situation : scale-up SaaS B2B (audit avant levée de fonds Série A) — Exemple de situation : avant une levée de fonds, une scale-up fait auditer sa dette technique. SonarQube fait ressortir un Technical Debt Ratio élevé, une faible couverture de tests et des classes à forte complexité cyclomatique.
Un plan de remboursement sur quelques sprints donne la priorité aux modules paiement et authentification. L'objectif est de rassurer les investisseurs lors de la due diligence technique.
Exemple de situation : application React monolithique de six ans (migration progressive) — Exemple de situation : une base de code React de 2018, sans TypeScript, avec peu de tests unitaires et des composants de plus de 800 lignes. Application du Strangler Fig Pattern : un nouveau module Next.js 16 + TypeScript est déployé en parallèle et les routes sont migrées une à une. On suit la dette résiduelle et la vélocité de l'équipe au fil de la migration.
Exemple de situation : ETI industrielle — ERP PHP sur mesure (modernisation legacy) — Exemple de situation : un ERP PHP 5.6 développé en 2011, sans tests et très volumineux. Audit SonarQube, cartographie des dépendances et entretiens avec les équipes permettent d'identifier les modules à risque. Refactoring progressif avec la règle des 20 % du sprint, et réécriture des modules critiques en Node.js + TypeScript. On suit le nombre d'incidents de production.
#Dette Technique chez Nehos Groupe
Chez Nehos, on teste et on ajuste avant de généraliser. Notre service Legacy Modernization Nehos couvre ce périmètre de A à Z.
La méthode Nehos est documentée sur méthode audit technique Nehos™. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : service Development TypeScript Nehos.
#Termes associés
Pour aller plus loin, explorez les termes connexes.
- Refactoring Code
- Strangler Fig Pattern
- TypeScript
- Monorepo (Turborepo / Nx)
- Legacy Modernization
- SonarQube
- Test Driven Development (TDD)
Explorez chaque définition pour construire une vision complète du sujet.
Applications Concrètes
« Exemple de situation : avant une levée de fonds, une scale-up fait auditer sa dette technique. SonarQube fait ressortir un Technical Debt Ratio élevé, une faible couverture de tests et des classes à forte complexité cyclomatique. Un plan de remboursement sur quelques sprints donne la priorité aux modules paiement et authentification. L'objectif est de rassurer les investisseurs lors de la due diligence technique. »
« Exemple de situation : une base de code React de 2018, sans TypeScript, avec peu de tests unitaires et des composants de plus de 800 lignes. Application du Strangler Fig Pattern : un nouveau module Next.js 16 + TypeScript est déployé en parallèle et les routes sont migrées une à une. On suit la dette résiduelle et la vélocité de l'équipe au fil de la migration. »
« Exemple de situation : un ERP PHP 5.6 développé en 2011, sans tests et très volumineux. Audit SonarQube, cartographie des dépendances et entretiens avec les équipes permettent d'identifier les modules à risque. Refactoring progressif avec la règle des 20 % du sprint, et réécriture des modules critiques en Node.js + TypeScript. On suit le nombre d'incidents de production. »
Questions & réponses
Questions fréquentes sur la dette technique
La dette technique est une métaphore financière formulée par Ward Cunningham en 1992. Elle désigne le coût additionnel futur que génère un choix de développement rapide ou suboptimal : code dupliqué, absence de tests, architecture non scalable, documentation manquante. Comme une dette bancaire, elle produit des intérêts : corriger un problème architectural après deux ans de développement coûte nettement plus cher que de le traiter dès le départ.
Deux grandes catégories selon Martin Fowler. Dette délibérée : l'équipe choisit sciemment de prendre un raccourci pour livrer plus vite (MVP, contrainte time-to-market) avec l'intention explicite de corriger ensuite. Elle est acceptable si on planifie le remboursement. Dette accidentelle : résulte d'une ignorance des bonnes pratiques, d'un manque de compétences ou de décisions correctes à l'époque devenues obsolètes. C'est la plus coûteuse car elle n'est souvent pas identifiée. Le quadrant Fowler ajoute un deuxième axe : prudente vs imprudente, selon que l'équipe mesure ou non l'impact de son choix.
Quatre indicateurs principaux. (1) SonarQube Technical Debt Ratio : ratio entre le temps estimé pour corriger la dette et le temps de développement total. Cible saine : <5 %. (2) Couverture de tests : cible >80 % sur les modules critiques. (3) Complexity cyclomatique : nombre de chemins d'exécution dans une fonction. Seuil d'alerte : >10 par fonction, >30 = refactoring urgent. (4) Couplage Afférent/Efférent : modules fortement couplés = cascade de bugs. Autres signaux : nombre de TODO/FIXME, taux de duplication de code (cible <3 %), absence de README.
Le coût est celui du temps perdu, des incidents et des délais qui s'allongent : corriger une mauvaise décision architecturale un an après coûte nettement plus cher qu'une conception soignée initiale. Une équipe sur une codebase très endettée passe une part importante de son temps à contourner des problèmes existants plutôt qu'à produire de la valeur. Le coût humain est aussi majeur : turn-over plus élevé, motivation dégradée, difficulté à onboarder de nouveaux développeurs. Règle pratique : si une feature qui devrait prendre 3 jours en prend régulièrement 10, la dette est hors de contrôle.
Trois stratégies complémentaires. (1) Règle des 20 % du sprint : réserver systématiquement 20 % de la vélocité sprint à du refactoring et nettoyage de code. Simple à faire accepter au management si présenté comme 'maintenance des actifs'. (2) Boy Scout Rule : chaque développeur laisse le code dans un meilleur état qu'il ne l'a trouvé — refactoring opportuniste à chaque pull request. (3) Strangler Fig Pattern : pour les systèmes legacy volumineux, développer un nouveau système en parallèle qui remplace progressivement l'ancien module par module, sans grand big-bang rewrite. Voir notre définition Strangler Fig Pattern.
Le Strangler Fig Pattern (Martin Fowler, 2004) tire son nom du figuier étrangleur qui pousse autour d'un arbre hôte jusqu'à le remplacer. Appliqué au code legacy : on développe un nouveau système moderne en parallèle de l'existant, on redirigé progressivement les routes/fonctionnalités vers le nouveau système, jusqu'à ce que l'ancien soit entièrement remplacé. Avantages vs big-bang rewrite : risque réduit (l'ancien fonctionne toujours pendant la migration), livraison continue de valeur, possibilité de revenir en arrière. Nehos l'utilise pour les missions de legacy modernization impliquant un système en production critique. Voir définition Strangler Fig Pattern.
Non — et c'est important à dire clairement. La dette délibérée-prudente est un outil de product management légitime. Un MVP qui doit être validé en 6 semaines, un pivot rapide, une contrainte contractuelle de livraison : autant de situations où prendre de la dette technique consciente est la bonne décision économique. Le problème n'est pas la dette elle-même, mais la dette non gérée, non documentée, non remboursée. La clé : tracer explicitement la dette dans le backlog (issues SonarQube, Architecture Decision Records), allouer du budget sprint régulier pour la rembourser, et ne jamais laisser le Technical Debt Ratio dépasser 10 % sans plan d'action.