La dette technique en startup, c’est grave ?
Est-ce un problème pour les développeurs ou les entrepreneurs ? Comment s’y prendre ? Voyons ça ensemble.
Vous vous dites peut-être que le concept de “dette technique” est une blague, ou du jargon de développeur. Ce n’est pas le cas ! Au contraire, c’est une métaphore qui permet aux profils non techniques de saisir un principe bien connu de tout développeur expérimenté.
Explications en vidéo:
La dette technique, pourquoi ?
Créer une startup est une course contre la montre. Le but est de conquérir un marché de manière exponentielle, en testant plusieurs propositions de valeur auprès d’une ou plusieurs cibles. Avec des ressources financières souvent très limitées, les startups n’ont alors que très peu de temps à perdre.
Une startup est donc pressée de sortir chaque itération de son produit, afin d’obtenir l’avis des utilisateurs, et de s’adapter progressivement, en espérant atteindre le fameux “product-market fit”. (produit qui trouve son marché)
Pour aller vite, il est tentant de prendre des raccourcis. Après tout, une startup se doit d’être rusée, de prendre des risques, et donc accepter que 99% de ce qu’elle produit est provisoire.
“ On aura le temps d’arrondir les angles plus tard, quand on aura atteint le product-market fit ! ”
Si votre produit est une app (web ou mobile), ou un logiciel de manière plus générale, ce genre de raccourci est souvent appelé “hack” ou “quick fix”. Ce qu’on peut traduire en français par “bricolage”. Et c’est l’accumulation des ces hacks qui constituent la dette technique.
Quelle différence avec une dette bancaire ?
Comme vous le savez, une dette financière (aussi appelé prêt bancaire) permet de jouir d’une somme d’argent à l’instant T, contre le paiement d’intérêts à la banque jusqu’à ce que l’argent soit intégralement remboursé.
De la même façon, la dette “technique” engendrée par l’accumulation de “hacks” dans le code source de votre produit (pour aller plus vite) a elle aussi tout intérêt à être “remboursée” au plus vite.
Rembourser la dette technique consiste à “refactoriser” (ou ré-usiner). C’est à dire laisser du temps aux développeurs pour nettoyer le code source du produit et en solidifier les fondations.
Le but du refactoring est de rendre le code source du produit plus robuste, simple, prévisible, et donc maintenable.
Tant que votre dette technique n’est pas remboursée, les “intérêts” de cette dette se manifesteront sous forme de bugs, de lenteurs, et de fonctionnalités sur lesquelles aucun développeur ne veut se risquer à travailler à nouveau, de peur que “ça casse tout”.
S’endetter ou ne pas s’endetter ?
Comme tout dette financière, la dette technique a bien son utilité. Surtout pour une startup “lean” qui a besoin de produire beaucoup de code provisoire pour tester ses hypothèses.
Néanmoins, gardez toujours en tête que ces raccourcis ont un coût pour la startup, et qu’il faut donc régulièrement accorder du temps aux développeurs de votre produit pour rembourser la dette correspondante.
Il en va de la bonne hygiène du développement de votre produit au sein de votre équipe. Et donc de la santé de votre startup. Ne négligez pas ce point !
Vous voulez d’autres conseils pratiques ?
David Wise et moi avons enregistré 3 heures de contenu vidéo pour partager tous nos conseils, et donner toutes les chances de succès à votre projet de startup: Startup Tour. (cliquez sur le lien pour bénéficier d’une réduction)
On y présente notamment l’usage du service Zapier pour développer un MVP de startup sans écrire la moindre ligne de code. Et donc tester votre proposition de valeur sans accumuler de dette technique !
