Le véritable coût de la dette technique : comment elle a causé la perte de trois start-ups financées

En tant que fondateur ou directeur technique, vous avez sûrement déjà entendu des ingénieurs se plaindre de la « dette technique ». Cela semble abstrait — comme quelque chose qui ralentit les développeurs sans pour autant avoir d'impact réel sur l'entreprise. Jusqu'à ce que ce soit le cas.

La dette technique correspond à l'écart entre le code dont vous disposez et celui dont vous avez besoin. À l'instar de la dette financière, elle s'accumule. Un raccourci qui vous fait gagner deux semaines aujourd'hui vous coûtera deux mois l'année prochaine. Voici trois entreprises réelles qui l'ont compris trop tard.

Une entreprise de SaaS B2B a levé 18 millions de dollars lors d'un tour de table de série B. Son produit présentait un excellent PMF. Mais après deux ans passés à « aller vite et casser des choses », l'ajout de la moindre nouvelle fonctionnalité nécessitait de modifier plus de 15 fichiers ; chaque modification causait un autre dysfonctionnement, et les déploiements prenaient trois heures, tests manuels compris.

Les chiffres : avant le rachat, ils lançaient 4 fonctionnalités par mois. Après le rachat, 0,5 fonctionnalité par mois. Leur concurrent (qui avait investi très tôt dans l'architecture) en lançait 6 par mois. En l'espace de 18 mois, ce concurrent s'était emparé du marché.

Une start-up spécialisée dans le commerce électronique disposait d'un backend monolithique sans mise en cache ni tests de charge, dont les requêtes de base de données fonctionnaient correctement pour 1 000 utilisateurs, mais s'effondraient dès qu'on atteignait les 50 000. Elle était au courant du problème depuis un an. « Nous y remédierons après avoir lancé la prochaine fonctionnalité », telle était la décision qui revenait sans cesse.

Le Black Friday a frappé fort. Le site a été hors service pendant 9 heures. L'entreprise a perdu environ 2,3 millions de dollars de chiffre d'affaires et la confiance de 40 000 clients qui ne sont jamais revenus. Cette mentalité consistant à « s'en occuper plus tard » a coûté plus cher que la refonte complète du système.

Une start-up spécialisée dans les technologies financières devait se mettre en conformité avec la norme SOC 2 pour décrocher des clients professionnels. L'audit a révélé que les clés API étaient codées en dur dans le code source, qu'il n'y avait aucun chiffrement au repos, que les mots de passe des utilisateurs étaient hachés avec l'algorithme MD5 et qu'il n'y avait pas de journalisation des audits. La résolution de ces problèmes a nécessité la réécriture de 60 % du backend. Les six mois consacrés à ces mesures correctives ont épuisé leurs dernières réserves financières.

Les contrats avec les grandes entreprises sur lesquels ils comptaient n'ont jamais abouti, car l'audit n'a pas pu être achevé à temps.

Pas besoin de savoir lire du code pour repérer la dette technique. Posez ces questions à votre équipe d'ingénieurs :

Les équipes d'ingénieurs les plus performantes avec lesquelles nous avons travaillé appliquent la règle des 20 % : elles consacrent 20 % de chaque sprint à la réduction de la dette technique. Ni 100 % (ce qui ralentirait l'activité), ni 0 % (ce qui garantirait des difficultés à l'avenir). Vingt pour cent.

Pour un sprint de deux semaines avec cinq développeurs, cela représente deux jours-développeur consacrés à : la mise à jour des dépendances, la rédaction de tests pour le code non testé, la refactorisation du module le plus désorganisé, l'amélioration des délais de déploiement ou la documentation des connaissances tacites.

Ce n'est pas un coût. C'est une assurance. Les entreprises qui survivent au-delà de la série B sont celles qui considèrent la qualité du code comme un indicateur de performance, et non comme une simple préférence technique.