Dette technique
La dette technique est le coût futur créé quand une équipe choisit aujourd'hui une solution plus rapide ou plus simple plutôt qu'une meilleure qui demanderait plus de temps. Comme une dette financière, elle génère des intérêts : chaque modification dans la zone concernée prend plus de temps et comporte plus de risques, jusqu'à ce que la dette soit remboursée par une refonte. Ward Cunningham a forgé la métaphore en 1992.
Pourquoi c’est important pour un PM
La dette n'est pas un échec en soi : la contracter volontairement peut être le bon choix pour apprendre vite ou tenir une échéance. Le problème, c'est la dette que personne ne suit, qui se manifeste par des livraisons plus lentes, des bugs récurrents et des estimations qui gonflent. Comme son remboursement entre en concurrence avec les fonctionnalités, la décision a sa place sur la roadmap, et le PM doit y prendre part.
Exemple
Pour tenir sa date de lancement, une équipe code en dur les règles fiscales d'un seul pays. Un an plus tard, chaque nouveau pays demande six semaines au lieu d'une. La PM apporte ce coût mesuré à la planification de la roadmap, et l'équipe programme la refonte avant les deux lancements suivants.
Points clés
- Un quadrant connu de Martin Fowler croise deux questions : la dette a-t-elle été contractée volontairement, et était-ce prudent ou imprudent ?
- Les intérêts se paient là où le code change souvent ; la dette dans une zone stable peut attendre.
- Rendre la dette visible avec des coûts concrets : retards, incidents, temps perdu à chaque modification.
- Quand on contracte une dette exprès, consigner la décision et un plan de remboursement.
Erreurs fréquentes
- Traiter les demandes de refonte comme des préférences d'ingénieurs plutôt que comme un risque produit.
- Promettre un « sprint dette » qui n'arrive jamais.
- Appeler « dette technique » chaque bug ou chaque technologie ancienne.
Pour aller plus loin dans Module
Les formations et les leçons qui traitent cette notion :