1. Technical Debt en 30 secondes
La Technical Debt (dette technique) est le coût futur des raccourcis techniques pris aujourd'hui. Comme une dette financière, elle produit des intérêts : chaque évolution coûte plus cher, chaque bug prend plus de temps à corriger.
2. Qu'est-ce que la Technical Debt ?
La dette technique désigne l'ensemble des compromis techniques — conscients ou non — qui rendent le logiciel plus coûteux à maintenir et à faire évoluer. Elle ne se limite pas au code : elle touche l'architecture, les tests, la documentation, l'infrastructure, la sécurité et les processus.
Origine du terme
La métaphore a été proposée à la fin des années 1990 par un pionnier du développement logiciel pour expliquer pourquoi livrer vite mais mal génère un remboursement futur. L'idée a ensuite été popularisée par plusieurs auteurs de référence en architecture logicielle, qui ont enrichi la métaphore d'un cadran distinguant dette délibérée, involontaire, prudente et imprudente.
Pourquoi la métaphore de la dette
La comparaison financière est puissante : on peut contracter une dette volontairement pour livrer plus vite, à condition de la rembourser. Sans remboursement, les intérêts s'accumulent et rendent tout changement lent et risqué.
Lien avec Scrum
Scrum ne nomme pas la dette technique dans ses artefacts officiels, mais son cadre la rend inévitablement visible : une Definition of Done stricte, un Product Backlog transparent et une vélocité observée dans le temps révèlent la dette.
3. Le cycle de la dette technique
Sans gestion active, la dette suit un cycle prévisible : livrer vite, accumuler, ralentir, refactorer, retrouver de la vitesse.
4. Pourquoi la dette apparaît-elle ?
La dette technique n'est pas le signe d'une équipe médiocre. Elle est la conséquence logique d'arbitrages entre vitesse, périmètre et qualité, dans un contexte souvent incertain.
Livrer vite écrase les décisions techniques : la solution rapide gagne, la solution propre attend.
Un socle mal pensé impose des contournements à chaque évolution.
Sans filet, chaque changement est un pari. La peur de casser gèle le code.
Copier-coller crée des variantes divergentes que personne n'ose plus fusionner.
Sans doc à jour, la connaissance vit dans quelques têtes. Turnover = perte sèche.
OS obsolètes, dépendances non patchées, CI branlante : la plateforme freine la delivery.
Sans code review, les mauvaises pratiques s'installent silencieusement.
Un produit qui pivote génère mécaniquement du code non pertinent à nettoyer.
5. Les différents types de dette
La dette technique se décline en plusieurs familles. Les nommer précisément permet de les prioriser et de les traiter avec les bons outils.
6. Conséquences : court terme vs long terme
La dette produit peu d'effets visibles à court terme — c'est ce qui la rend dangereuse. Les conséquences se cumulent silencieusement.
| Dimension | Court terme | Long terme |
|---|---|---|
| Bugs | Peu visibles, contenus | Récurrents, difficiles à reproduire |
| Maintenance | Coût acceptable | Explosive, effets de bord permanents |
| Performance | Suffisante | Dégradée à mesure de la charge |
| Qualité perçue | Neutre | En baisse, plaintes utilisateurs |
| Motivation équipe | Léger inconfort | Turnover, désengagement |
| Time-to-market | Rapide | En hausse constante, effet ciseau |
| Coûts | Faibles apparents | Multipliés par 5 à 10 sur 2 ans |
7. Impact sur la vélocité
Suivre la vélocité sur plusieurs Sprints est l'un des moyens les plus fiables de détecter une dette technique croissante. La courbe descend progressivement, indépendamment des efforts de l'équipe.
Le refactoring ciblé (bande bleue) est un investissement : la vélocité repart, et durablement, si les causes racines sont traitées.
8. Technical Debt et Scrum
La dette technique n'a pas d'artefact dédié dans Scrum, mais elle touche presque tous les éléments du framework.
| Élément Scrum | Lien avec la dette technique |
|---|---|
| Increment | Un Increment livré avec de la dette n'est plus vraiment « Done ». |
| Definition of Done | La DoD est le meilleur rempart contre l'accumulation de nouvelle dette. |
| Sprint Backlog | Les tâches de remboursement de dette s'y intègrent comme les autres. |
| Sprint Planning | Les Developers y intègrent des items de dette à chaque Sprint. |
| Sprint Review | L'impact de la dette sur l'Increment doit y être discuté. |
| Sprint Retrospective | Événement idéal pour analyser les causes systémiques de la dette. |
| Empiricism | Transparence sur la dette, inspection de son impact, adaptation continue. |
9. Qui est responsable ?
La dette technique n'est pas la seule affaire des Developers. Chaque acteur du Scrum Team et de son organisation contribue à son apparition ou à sa maîtrise.
| Acteur | Responsabilité principale | Comportement à éviter |
|---|---|---|
| Product Owner | Arbitrer la valeur en intégrant la dette au backlog | Ignorer les items techniques |
| Scrum Master | Rendre la dette visible, coacher, protéger la DoD | Décider seul du plan technique |
| Developers | Éviter d'en créer, mesurer, rembourser en continu | Cacher la dette au reste de l'équipe |
| Management | Financer les remboursements, protéger la qualité | Réclamer une vélocité maximale sans arbitrage |
| Stakeholders | Comprendre les arbitrages, accepter les compromis | Exiger sans négociation |
10. Comment réduire la dette technique ?
Le remboursement n'est pas une opération ponctuelle. C'est une discipline quotidienne appuyée sur neuf leviers complémentaires.
- ✔Refactoring ciblé, intégré dans chaque story
- ✔Tests automatisés (unitaires, intégration, E2E)
- ✔Pair Programming ou mob programming sur les zones sensibles
- ✔Code Review systématique et bienveillante
- ✔CI/CD rapide, feedback loop < 15 minutes
- ✔Application des principes Clean Code et SOLID
- ✔Décisions d'architecture tracées (ADR)
- ✔Definition of Done stricte, non négociable
- ✔Temps explicite dédié à la dette dans chaque Sprint
11. Tableaux comparatifs
La dette technique est souvent confondue avec d'autres notions proches. Ces tableaux font le tri.
Technical Debt vs Bug
| Critère | Technical Debt | Bug |
|---|---|---|
| Nature | Coût futur d'un choix technique | Défaut fonctionnel avéré |
| Visible pour l'utilisateur ? | Rarement à court terme | Souvent immédiat |
| Priorisation | Product Backlog | Product Backlog (souvent haut de pile) |
| Impact principal | Ralentit les évolutions | Dégrade l'expérience |
Technical Debt vs Refactoring
| Critère | Technical Debt | Refactoring |
|---|---|---|
| Nature | Problème | Solution |
| Relation | Ce que l'on doit | Ce que l'on rembourse |
| Déclencheur | Compromis passé | Décision d'améliorer sans changer le comportement |
| Fréquence | S'accumule | S'exerce en continu, petit à petit |
Technical Debt vs Legacy Code
| Critère | Technical Debt | Legacy Code |
|---|---|---|
| Définition | Coût futur d'un choix | Code hérité, souvent sans tests |
| Origine | Décision consciente ou non | Ancienneté, absence de refactoring |
| Chevauchement | Le legacy en contient souvent | Peut être exempt de dette moderne |
| Traitement | Priorisation continue | Reprise structurée, tests d'abord |
Technical Debt vs Code Smell
| Critère | Technical Debt | Code Smell |
|---|---|---|
| Nature | Concept économique | Signal qualité local |
| Portée | Système entier | Fonction, classe, module |
| Détection | Vélocité, MTTR, bugs récurrents | Revue, outils statiques |
| Traitement | Priorisation backlog | Refactoring immédiat |
Technical Debt vs Défaut logiciel
| Critère | Technical Debt | Défaut logiciel |
|---|---|---|
| Type | Coût futur | Écart entre spécification et comportement |
| Visibilité | Interne à l'équipe | Souvent externe |
| Impact | Économique et organisationnel | Fonctionnel et utilisateur |
| Correction | Refactoring, réarchitecture | Bug fix ciblé |
12. Bonnes et mauvaises pratiques
- Rendre la dette visible dans le Product Backlog.
- Estimer l'intérêt payé chaque Sprint (temps perdu, bugs).
- Consacrer une part fixe de capacité au remboursement (10-20 %).
- Refactorer en même temps qu'une évolution fonctionnelle proche.
- Automatiser tests, linting, sécurité, build.
- Documenter les décisions structurantes (ADR).
- Discuter la dette en Sprint Review avec les stakeholders.
- Analyser les causes en Sprint Retrospective.
- Cacher la dette pour préserver la vélocité affichée.
- Attendre une « v2 » ou une réécriture hypothétique.
- Négliger la Definition of Done pour tenir une deadline.
- Traiter la dette uniquement lors de crises.
- Créer un backlog technique parallèle sans arbitrage PO.
- Confier le refactoring uniquement aux « seniors ».
- Ignorer les métriques (MTTR, lead time, taux de bugs).
- Considérer la dette comme un problème purement technique.
13. 8 exemples industriels
Ces cas concrets illustrent comment la dette technique se manifeste selon le secteur — et comment elle se rembourse.
🎬 Contexte — Core banking construit dans les années 2000, ajout continu de canaux digitaux.
🚧 Problème — Chaque évolution mobile impose un contournement côté mainframe.
💸 Dette — Couches d'adaptation empilées, tests d'intégration inexistants.
📉 Conséquences — Chaque release exige 2 semaines de tests manuels et un rollback plan complet.
🛠️ Solution — Introduire une couche d'API modernes, tester par contrat, migrer progressivement.
🎬 Contexte — Moteur de tarification unique, alimenté par 12 produits.
🚧 Problème — Un changement de règle affecte tous les produits.
💸 Dette — Règles métier embarquées dans le code, sans configuration.
📉 Conséquences — Time-to-market > 3 mois pour un nouveau produit.
🛠️ Solution — Extraire un moteur de règles, versionner les tarifs, isoler par produit.
🎬 Contexte — Application patient étendue au fil des besoins réglementaires.
🚧 Problème — Sécurité et conformité rétro-installées après coup.
💸 Dette — Contrôles d'accès dispersés, journalisation partielle.
📉 Conséquences — Audits fréquents, écarts HDS, coûts de mise en conformité.
🛠️ Solution — Refonte du domaine sécurité, journalisation centralisée, tests de conformité automatisés.
🎬 Contexte — Supervision d'atelier connectée à des automates hétérogènes.
🚧 Problème — Couplage direct entre l'interface et chaque protocole.
💸 Dette — Absence de couche d'abstraction, drivers dupliqués.
📉 Conséquences — Un nouvel automate = 4 semaines de dev.
🛠️ Solution — Introduire un bus applicatif, isoler les drivers, tests d'intégration matériels.
🎬 Contexte — Produit multi-tenant lancé rapidement pour valider le marché.
🚧 Problème — Isolation par convention (pas par contrainte).
💸 Dette — Requêtes non filtrées par tenant, migrations partagées.
📉 Conséquences — Risque de fuite de données, migrations bloquantes.
🛠️ Solution — Row-level security, tenant-aware ORM, migrations testées par tenant.
🎬 Contexte — Plateforme d'inférence IA scalée en urgence.
🚧 Problème — Provisioning manuel des GPU.
💸 Dette — Infra as Code partielle, capacité surdimensionnée.
📉 Conséquences — Facture cloud x3, incidents lors des pics.
🛠️ Solution — IaC complet, autoscaling piloté par SLO, FinOps hebdomadaire.
🎬 Contexte — Portail client héritant de 3 fusions successives.
🚧 Problème — 3 systèmes d'authentification distincts.
💸 Dette — Absence de SSO, sessions incohérentes.
📉 Conséquences — Taux d'appel au support en hausse constante.
🛠️ Solution — Migration progressive vers un IDP unique, décommissionner les silos.
🎬 Contexte — Catalogue passé de 500 à 50 000 SKUs en 18 mois.
🚧 Problème — Recherche interne basée sur SQL non indexé.
💸 Dette — Absence de moteur de recherche dédié.
📉 Conséquences — Temps de réponse > 3s, taux de rebond en hausse.
🛠️ Solution — Extraire un moteur de recherche (OpenSearch), indexation asynchrone.
14. 8 erreurs fréquentes
Ces huit erreurs représentent la majorité des mauvaises réponses PSM I et des pratiques contre-productives observées sur le terrain.
Un bug est un défaut fonctionnel avéré. La dette est un coût futur d'évolution ou de maintenance.
Sans temps dédié, la dette n'est jamais remboursée. Elle grossit avec les intérêts.
Une vélocité stable peut masquer une dette qui explose. Corréler avec bugs, MTTR, lead time.
Sans tests, refactorer devient trop risqué. La dette se fige.
Le code non exécuté doit être supprimé, pas maintenu 'au cas où'.
Livrer sale coûte plus cher que livrer proche, sauf accord explicite du Product Owner.
Réparer du code sans traiter l'architecture, c'est repeindre un mur fissuré.
PO, Scrum Master, management et stakeholders influent tous sur la dette et sur sa gestion.
15. Checklist : notre dette technique est-elle maîtrisée ?
Passez chaque case en revue avec l'équipe. Un « non » = un sujet à mettre au prochain backlog.
- ☐Backlog de dette identifié et intégré au Product Backlog
- ☐Transparence : chaque acteur connaît les zones à risque
- ☐Refactoring planifié à chaque Sprint
- ☐Definition of Done respectée sans exception
- ☐Tests automatisés couvrant les zones critiques
- ☐Architecture cible connue et suivie
- ☐Revues de code régulières et systématiques
- ☐Dette rendue visible dans les Sprint Reviews
16. 7 questions PSM I corrigées
Ces sept questions couvrent les formulations les plus fréquentes du PSM I sur la qualité, la Definition of Done et la gestion de la dette technique.
17. Conclusion
La dette technique n'est pas un échec — c'est un mécanisme économique inévitable dès qu'une équipe livre du logiciel. Ce qui distingue les équipes performantes n'est pas l'absence de dette, mais leur capacité à la rendre visible, à la prioriser et à la rembourser en continu. Scrum fournit toutes les briques nécessaires : Definition of Done, transparence du Product Backlog, empirisme, Sprint Retrospective.