Dette technique : les 7 erreurs qu’on voit dès le premier projet (et comment les éviter)
La dette technique ne commence pas « plus tard ». Elle commence souvent dès le premier projet, au moment où l’on choisit la vitesse au détriment de la structure.
Ce n’est pas forcément une erreur. Parfois, aller vite est le bon choix. Le problème, c’est quand on ne sait plus ce qu’on a sacrifié.
Les erreurs les plus courantes
Les erreurs les plus courantes sont :
- Vouloir tout prévoir dès le début.
- Mélanger logique métier et logique d’affichage.
- Multiplier les solutions temporaires sans les documenter.
- Négliger les accès, les sauvegardes et la reprise.
- Choisir une stack trop lourde pour le besoin réel.
- Ne pas préparer le projet à évoluer.
- Oublier que la maintenance coûte toujours quelque chose.
Quand la dette devient dangereuse
La dette technique devient dangereuse quand elle empêche de livrer la suite. Un projet qui « marche » mais que personne n’ose toucher est déjà en difficulté.
Pour l’éviter : souvent faire moins, mais mieux
Pour l’éviter, il faut souvent faire moins, mais mieux : un périmètre net, des composants ou modules clairs, une base propre, des conventions écrites, et des choix assumés.
Nommer la dette
La dette technique n’est pas une fatalité. Elle devient un problème quand elle est invisible. Dès qu’on la nomme, elle devient plus simple à arbitrer.
La bonne question pour un fondateur
Pour un fondateur, la bonne question n’est pas « comment éviter toute dette ? ». La bonne question est : « quelle dette est acceptable maintenant, et combien me coûtera-t-elle ensuite ? »