Le mur de la dette
Il faut aller vite, prouver qu'il y a un marché, acquérir des premiers utilisateurs, les garder, lever des fonds, délivrer. Alors forcément, on ne va jamais assez vite. Alors on a passé le POC en prod. Aïe. On a beaucoup de spécifique client dans le code, le rendre générique demanderait de poser le stylo vraiment. Et le modèle qui ne tient plus… on n'a pas les bons objets métier, mais le refacto est titanesque. C'est d'autant plus embêtant qu'on est comment dire… un peu faibles sur la partie tests. Alors on a monté une équipe de QA pour limiter les dégâts, c'est de la non-régression à la main, ce n'est pas pérenne, mais on n'a pas le choix : il faut délivrer.
Cela vous paraît familier ?
La dette technique, un sujet de compétence
Disons-le crûment : la dette technique est avant tout un sujet de compétence des équipes techniques : si écrire du code qui fonctionne est à la portée du premier développeur venu, écrire du code que l'on pourra faire évoluer pour soutenir la croissance de l'entreprise représente un vrai défi : l'entreprise s'adapte constamment au marché, à ses utilisateurs, le besoin émerge au fur et à mesure et le code se retrouve en tension.
Tout l'enjeu, quand on pose les fondations d'un produit, est de faire simple sans tomber dans le simplisme. Ne pas anticiper des besoins par nature hypothétiques tout en permettant au code d'évoluer vers ces besoins s'ils adviennent, c'est-à-dire laisser des portes ouvertes. Il y a donc une tension permanente entre court et long termes, une ligne de crête sur laquelle on peut tout de même avancer à condition d'en avoir la compétence, en particulier en termes de modularité et de tests .
Autant de choses que l'on ne saurait légitimement demander à des développeurs tout juste sortis d'école. En tant que CEO, vous gagnerez toujours à mobiliser le plus tôt possible des développeurs expérimentés pour poser des fondations techniques solides, un squelette applicatif minimal , qui permettra ensuite de faire monter à bord des développeurs plus juniors pour aller rapidement au MVP en limitant la dette technique.
La dette technique est insidieuse
Cela dit, on fait au mieux. Une entreprise se construit tel qu'elle le peut, chacune a son histoire et ses raisons. Les personnes en place cherchent généralement à bien faire, ont fait plein de choses utiles pour l'entreprise, mais, c'est un fait, la dette s'est accumulée. D'ailleurs, on peut en limiter l'apparition, mais la dette technique est pour ainsi dire inévitable : écrire du code, c'est déjà créer de la dette. Bienvenue dans la vie 🥲
La difficulté, c'est que la dette possède 2 caractéristiques, qui la rendent dangereuse :
- La dette appelle la dette : foutu pour foutu, pourquoi ferais-je un travail d'orfèvre alors que la codebase est un champ de ruines ? Un biais psychologique connu sous le nom de théorie de la vitre brisée , qu'il faut contrer dès le début sous peine de voir la dette s'installer durablement. Et puis, même avec la meilleure volonté du monde, il est difficile de construire proprement sur des bases qui ne sont pas saines.
- La dette est invisible pour le dirigeant non technique : de son point de vue, l'application fonctionne, et c'est vrai ! Ainsi, la dette peut s'accumuler pendant des années dans un silence relatif, jusqu'au moment où elle éclate au grand jour, à cause d'une fonctionnalité un peu trop structurante ou du départ d'un développeur-clé. Et là, vous frappez le mur.
Le mur de la dette, c'est comme le mur du marathon : vous fournissez 2 fois plus d'effort et vous allez 2 fois moins vite. Le réflexe consistant à embaucher de nouveaux développeurs pour fournir plus d'effort se révèle contre-productif, parce que c'est la méthode qui fait défaut. Vous patinez dans la semoule.
Dur, dur.
Comment résorber la dette ?
Alors, que faire quand la dette s'est installée durablement ? Eh bien il faut agir avec raison :
- Arrêter d'en créer, autant que possible, dès que possible. Cela veut dire former vos équipes et les inciter à mettre en place de nouveaux standards de travail. C'est un ensemble de bonnes pratiques (Clean Code, Test-driven development, Domain-driven design…), que vous gagnerez à aborder progressivement . Avant les pratiques, c'est même un état d'esprit, celui de l'Artisanat Logiciel, qui se caractérise par l'amour du travail bien fait et l'envie de progresser autant que de transmettre. Ce sujet touche donc à la culture de votre entreprise.
- Résorber la dette existante. C'est un travail de longue haleine, qui demande une bonne priorisation, des compétences de refactoring et avant cela une très bonne compréhension du métier. En effet, une des causes premières de la dette technique est la mauvaise modularité du système dans son ensemble. Il est donc très fréquent de devoir le re-modulariser , ce qui se fait en premier lieu sur base de considérations fonctionnelles.
Conclusion
La dette technique est la grande problématique des scale-up, parce que l'industrialisation met en lumière les problèmes qui étaient restés tapis dans l'ombre depuis le début. Quelques développeurs ayant tout l'historique en tête peuvent compenser les défauts d'une petite codebase mal modularisée, mal architecturée ou mal testée. Mais ce qui fonctionne à 2 ne fonctionne plus à 20 et encore moins à 200. Un seul mot d'ordre : prenez les devants et challengez vos développeurs !
Signalons enfin ce qu'il aurait peut-être fallu dire avant toute chose : la dette n'est pas mauvaise en soi. Face à un impératif de calendrier, il est légitime de prendre quelques raccourcis dans le code si cela permet à l'équipe de livrer dans les délais. Encore faut-il qu'il s'agisse d'une démarche consciente, occasionnelle et que la dette soit remboursée rapidement en procédant aux refactorings nécessaires. Souvenez-vous : "Un crédit vous engage et doit être remboursé. Vérifiez vos capacités de remboursement avant de vous engager".
Bien utilisée, la dette technique permet donc à l'entreprise de réaliser un effet levier bénéfique. Le tout est de savoir la maîtriser.