Comment expliquez-vous la dette technique à un public non technique ?

Question

Accepted Answer

**Je traduis la tech debt dans le langage que le public utilise déjà : l'argent, la vitesse et le risque.** Un stakeholder non technique ne se soucie pas du couplage ou de la couverture de tests ; il se soucie que les fonctionnalités deviennent plus lentes et plus chères à livrer. Donc je présente la dette comme un problème financier et de livraison, pas comme un problème de code.

## Le cadrage que j'utilise

- **La métaphore financière, utilisée avec soin.** « On a pris un raccourci pour livrer vite, comme contracter un prêt. Ça a marché, et maintenant on paie des intérêts dessus à chaque sprint. Chaque nouvelle fonctionnalité dans cette zone coûte plus cher à cause de ces intérêts. » Ça fait mouche parce que tout le monde comprend la dette et les intérêts.
- **La rendre concrète avec leurs métriques.** Pas « le code est désordonné » mais « cette fonctionnalité a pris trois semaines ; il y a deux ans, la même taille en prenait une. La différence, c'est le coût de maintenance qu'on a accumulé. »
- **La relier aux résultats qui les concernent.** Livraison plus lente, plus de bugs atteignant les clients, onboarding plus difficile pour les nouveaux, risque croissant de panne. Connecter la dette au revenu, à la réputation et à la vitesse de la roadmap.

## Comment j'en fais une décision, pas une plainte

- La présenter comme un **arbitrage avec des options**, pas comme une exigence : « On peut continuer à livrer des fonctionnalités au rythme ralenti actuel, ou investir deux sprints maintenant pour réduire d'environ un tiers le coût futur des fonctionnalités. »
- Quantifier quand je peux : temps perdu par sprint, fréquence des incidents, le pourcentage de capacité passé à éteindre des feux.
- Être honnête sur le fait qu'**une certaine dette est acceptable.** Toute la dette ne doit pas être remboursée ; le but est de rembourser celle qui taxe activement la livraison.

## Pièges

- **Utiliser du jargon** (« refactor », « couplage », « l'architecture est mauvaise »). Cela donne l'impression que vous voulez peaufiner le code à l'excès.
- Présenter cela comme des ingénieurs voulant du code propre pour lui-même ; cela se lit comme de l'auto-complaisance.
- Crier au loup — qualifier tout de dette érode votre crédibilité quand quelque chose de vraiment urgent survient.

## Pourquoi c'est important

Si vous ne pouvez pas expliquer la tech debt en termes business, elle n'est jamais financée, et l'équipe ralentit lentement jusqu'à l'arrêt pendant que la direction se demande pourquoi la vélocité baisse. La présenter comme du coût, de la vitesse et du risque est ce qui vous obtient le temps de la corriger avant qu'elle ne devienne une crise.