Qu'est-ce que Technical Debt ?

The term was coined by programmer Ward Cunningham, who used the financial debt metaphor intentionally: like financial debt, technical debt accrues 'interest' over time in the form of increasingly slow development velocity, higher bug rates, and greater difficulty onboarding new developers. A startup that ships features quickly by hard-coding values, skipping tests, and choosing expediency over architectural soundness builds a working product faster — but pays compound interest as that codebase grows and becomes harder to modify without breaking things.

Technical debt comes in several forms. Deliberate debt is intentional (shipping a quick fix to meet a deadline, planning to refactor later). Inadvertent debt accumulates from inexperience — architectural decisions that seemed fine at the time but didn't anticipate future scaling needs. Outdated dependencies are a form of technical debt: libraries and frameworks that were modern when the software was built and are now legacy, unmaintained, or security-vulnerable. Test coverage gaps mean that changes to one part of the system unexpectedly break another part, slowing development and increasing defect rates.

Technical debt is not inherently bad — some debt is strategically rational (an MVP should optimize for speed over perfection). The problem is when debt is untracked, not discussed with business stakeholders, and allowed to accumulate until it creates a genuine crisis: a security breach from an unpatched dependency, a system outage from fragile infrastructure, or a complete rewrite required because the original architecture cannot handle current scale.