Comment gérez-vous la dette technique au niveau organisationnel ?

Question

Accepted Answer

Au niveau organisationnel, la dette technique est un **portefeuille à gérer**, et non un backlog à éliminer. L'objectif n'est pas zéro dette ; c'est de maintenir la dette à un niveau où elle ne menace pas la vélocité, la fiabilité ou la capacité à livrer la stratégie.

## Comment y réfléchir

```text
MAKE DEBT VISIBLE AND PRIORITIZED
- Inventory the debt that actually hurts (slows delivery, causes incidents)
- Classify: strategic (deliberate) vs accidental vs decay/rot
- Quantify impact in business terms (velocity, downtime, churn risk)
- Allocate a steady % of capacity to paydown (commonly 15-25%)
```

Toute dette ne vaut pas la peine d'être remboursée. La dette dans un système stable, rarement modifié, peut être laissée de côté ; la dette dans une zone chaude, en évolution rapide, devrait être remboursée en premier.

## Exemple concret

Un CTO institue une règle selon laquelle 20 % de la capacité de chaque équipe va à la fiabilité et à la dette, puis la cible sur les trois systèmes causant 80 % des incidents, plutôt que de la répartir finement partout.

## Compromis et pièges

- **Piège :** une « grande réécriture » pour éliminer toute la dette, qui dépasse généralement les délais et recréé de la dette.
- **Piège :** ne jamais la rembourser, jusqu'à ce que la vélocité s'effondre.
- Présenter la dette comme une préoccupation réservée aux ingénieurs échoue ; liez-la aux résultats commerciaux pour obtenir l'adhésion.

## Pourquoi c'est important

La dette technique non gérée s'accumule silencieusement jusqu'à ce que les fonctionnalités prennent des mois et que les incidents augmentent.

La gérer comme un portefeuille délibéré garde l'organisation rapide et fiable sur des années, et transforme une préoccupation abstraite d'ingénierie en un compromis commercial quantifié auquel les dirigeants peuvent réfléchir.