« Il faut supprimer la dette technique » sonne bien. En pratique, en MVP, la moitié de la dette est un investissement, pas un problème. Le tri est le vrai enjeu.

Principe : une dette qui coûte peu à porter est un signal d'efficacité, pas de mauvaise pratique. Une dette qui ralentit chaque nouvelle feature doit être traitée.

Les 4 types de dette

  • Prudente et délibérée : « on livre, on saura mieux après »
  • Imprudente et délibérée : « on n'a pas le temps de bien faire »
  • Prudente et involontaire : « maintenant qu'on sait, on ferait différemment »
  • Imprudente et involontaire : « on ne savait pas ce qu'on faisait »

À rembourser avant lancement

  • Sécurité (permissions, RLS, secrets)
  • Data model qui a des inconsistances irréversibles
  • Auth mal isolée

À laisser vivre pour l'instant

  • Code dupliqué (moins de 3 fois)
  • Tests unitaires manquants sur du code isolé
  • UI un peu bricolée sur des pages secondaires
La meilleure dette technique est celle qu'on choisit consciemment et qu'on rembourse quand elle commence à peser.

On audite votre codebase ?

En 30 minutes on peut identifier les 3 zones de dette à traiter en priorité. Réservez un appel. À lire : Tests unitaires pendant un MVP.

A project to launch or to rescue?

30-minute free call. We look together at what's blocking you and where to start.

Book a discovery call
Dette technique d'un MVP : quand rembourser, quand ignorer · Perrine Honoré