18. La dette technique : gouverner les compromis au lieu de les subir
Pourquoi ce chapitre existe
Le terme « dette technique » est utilisé pour tout ce qui déplaît dans un système : vieux framework, code peu élégant, absence de tests, outil lent, documentation obsolète. Cette généralité le rend peu actionnable. Elle favorise deux réactions opposées : tout qualifier de dette et ne rien prioriser, ou considérer toute amélioration comme un luxe opposé à la valeur produit.
Une dette utilement décrite est un compromis passé qui crée aujourd'hui un coût, un risque ou une contrainte de changement mesurable. La gouverner consiste à décider consciemment quand l'accepter, quand la rembourser et comment éviter qu'elle devienne invisible.
Les idées essentielles
- Une dette n'est pas un défaut de caractère du code ; elle est l'effet présent d'une décision prise dans un contexte donné.
- Sa priorité dépend du dommage qu'elle produit : délai, incidents, sécurité, coûts, dépendance humaine ou options perdues.
- Le remboursement doit être lié à une trajectoire et à un résultat, pas à une promesse de « nettoyage ».
- Certaines dettes doivent être acceptées explicitement parce que leur remboursement coûterait davantage que leur maintien.
Décrire le mécanisme, pas l'étiquette
« Le service est legacy » ne permet aucune décision. « Toute évolution de facturation impose trois déploiements coordonnés, allonge la correction d'incident et bloque le support hors heures ouvrées » décrit un mécanisme, des personnes touchées et des bénéfices attendus. Cette formulation rend possibles plusieurs réponses : améliorer un contrat, isoler une responsabilité, automatiser une opération, réduire une dépendance ou accepter le coût provisoirement.
| Description vague | Description qui permet d'agir |
|---|---|
| « Pas assez de tests » | « Une règle de calcul change souvent sans test de caractérisation ; les régressions ne sont détectées qu'en recette » |
| « Monolithe trop gros » | « Les déploiements de catalogue et commande sont couplés, alors que leurs changements et équipes sont distincts » |
| « Documentation absente » | « L'astreinte ne peut pas identifier la source de vérité d'un statut et escalade systématiquement » |
| « Dépendance obsolète » | « Cette version ne reçoit plus de correctifs de sécurité et bloque la mise à jour de l'environnement » |
Dette, risque et urgence
La dette ne devient pas prioritaire parce qu'elle est ancienne ou visuellement déplaisante. Elle le devient lorsqu'elle augmente le coût ou le danger d'un travail que l'organisation doit réaliser. Une vulnérabilité exposée, une migration qui bloque une obligation légale ou une zone qui retarde chaque incident mérite une action rapide. Une abstraction imparfaite mais stable peut attendre.
Cette logique évite également la fiction d'un backlog de dette exhaustif. Il vaut mieux maintenir une liste courte de compromis décrits avec leur impact, leur propriétaire et leur prochain point de décision qu'un inventaire interminable d'inconforts sans trajectoire.
Beaucoup de dettes sont traitées au meilleur moment lorsqu'un changement métier traverse déjà la zone concernée. L'équipe connaît le contexte et peut intégrer l'amélioration au chemin de livraison. Réserver des investissements dédiés reste nécessaire pour les risques transverses ou les fondations qui n'ont pas d'occasion produit naturelle.
Anti-patterns
Utiliser la dette pour contourner une priorisation difficile
Étiqueter une demande « technique » ne justifie pas automatiquement son urgence. Décrire l'impact permet au produit, à la sécurité et à l'ingénierie de faire un arbitrage explicite plutôt que de se battre sur des catégories.
Promettre une grande opération de nettoyage sans résultat intermédiaire
Les programmes de modernisation qui ne livrent aucune réduction de risque avant la fin sont fragiles : ils perdent leur financement au premier changement de priorité. Découper la trajectoire en capacités démontrables — dépendance retirée, temps de récupération réduit, contrat stabilisé — rend l'investissement gouvernable.
Accepter une dette sans date ni signal de réexamen
Un compromis rationnel peut devenir dangereux lorsque le volume, les usages ou la réglementation changent. Toute acceptation doit préciser qui la porte, ce qui déclenchera une révision et comment l'équipe saura que le seuil est atteint.
Bonnes pratiques
Relier chaque investissement à un coût évité
Un dossier de dette peut tenir en quelques lignes : contexte, mécanisme, impact observé, options, décision, propriétaire et mesure de succès. Le résultat attendu ne doit pas être « code plus propre », mais par exemple « permettre le déploiement indépendant », « éliminer une classe de doublons », ou « restaurer une dépendance supportée ».
Suivre les frictions dans le travail ordinaire
Les temps de cycle, incidents répétitifs, revues bloquées, astreintes, migrations manuelles et déploiements coordonnés révèlent des coûts réels. Les écouter transforme la dette d'une intuition d'expert en information partagée sur la santé du système.
Checklist — Une dette mérite-t-elle une décision maintenant ?
- Quel compromis passé crée quel coût ou risque concret aujourd'hui ?
- Qui subit ce coût et à quelle fréquence ?
- Que se passe-t-il si l'on ne fait rien pendant le prochain cycle de changement ?
- Quelles options de réduction existent, et quel premier incrément apporte une valeur mesurable ?
- Qui accepte ou porte le risque si l'action est reportée ?
- Quel signal déterminera que le sujet est résolu ou doit être re-priorisé ?
À retenir
La dette technique n'est pas l'ennemie de la livraison ; elle est le prix de certains compromis. Une équipe responsable la rend visible, la relie à ses conséquences et choisit consciemment où investir afin de préserver sa capacité à changer.