Votre projet logiciel a ete lance dans les delais. L'equipe a celebre. Les clients etaient satisfaits. Six mois plus tard, une fonctionnalite qui devrait prendre une semaine est estimee a six semaines. Un petit correctif introduit deux nouveaux bugs. L'equipe de developpement ne cesse de mentionner quelque chose appele "dette technique" et demande du temps pour la traiter.
Bienvenue face au probleme le plus couteux du logiciel, que la plupart des dirigeants non techniques ne comprennent pleinement que lorsqu'il leur coute deja des dizaines de milliers d'euros par an.
La dette technique est reelle, mesurable et presque entierement evitable. Cet article explique ce que c'est, ce qu'elle coute et comment eviter d'en accumuler des le tout debut d'un projet.
Qu'est-ce que la dette technique, en termes simples ?
La dette technique est le cout accumule des raccourcis pris pendant le developpement logiciel. Comme la dette financiere, elle genere des interets au fil du temps.
Voici une analogie. Imaginez que vous construisez une maison et que vous sautez les plans architecturaux pour gagner du temps. Les premieres pieces sont montees rapidement. Mais quand vous devez ajouter la plomberie, vous realisez que les murs sont au mauvais endroit. Quand vous devez ajouter un etage, vous decouvrez que les fondations n'etaient pas concues pour le supporter. Chaque modification ulterieure necessite de contourner les problemes crees par les raccourcis pris au depart.
En logiciel, cela ressemble a :
- Du code ecrit rapidement pour respecter un delai mais difficile a comprendre ou a modifier
- Des fonctionnalites construites sans tests automatises, ce qui fait que personne n'est sur que les modifications ne casseront rien
- De la logique dupliquee dispersee dans le code source au lieu de composants partages et reutilisables
- Des bibliotheques et frameworks obsoletes qui n'ont pas ete mis a jour parce que "ca marche, on n'y touche pas"
- Aucune documentation, ce qui fait que seul le developpeur d'origine comprend comment ca fonctionne
Le vrai cout : des chiffres qui comptent
La dette technique n'est pas un concept abstrait. Elle a un impact financier concret et mesurable.
La velocite de developpement diminue avec le temps
Dans un code source sain, le temps pour ajouter une nouvelle fonctionnalite reste relativement constant. La fonctionnalite un prend deux semaines. La fonctionnalite vingt prend deux semaines. La fonctionnalite cinquante prend deux semaines.
Dans un code source avec une dette technique significative, chaque nouvelle fonctionnalite prend plus de temps que la precedente. La fonctionnalite un prend deux semaines. La fonctionnalite vingt prend quatre semaines. La fonctionnalite cinquante prend huit semaines -- et c'est si rien ne casse.
Une etude de Stripe en collaboration avec Harris Poll a revele que les developpeurs passent en moyenne 33 % de leur temps a gerer la dette technique. Pour une equipe de cinq developpeurs factures aux tarifs du marche, cela represente a peu pres l'equivalent de 1,5 developpeur a temps plein ne faisant rien d'autre que nettoyer les raccourcis passes. Chaque annee.
Les taux de bugs augmentent
Quand le code est emmele et mal structure, les modifications dans un domaine creent des problemes inattendus dans un autre. Ce n'est pas de l'incompetence des developpeurs. C'est une consequence previsible de raccourcis accumules.
Un code source avec une dette technique elevee voit generalement 2 a 5 fois plus de bugs en production qu'un code bien maintenu. Chaque bug coute du temps a investiguer, corriger, tester et deployer. Plus encore, chaque bug erode la confiance des utilisateurs.
L'integration des nouveaux developpeurs prend plus de temps
Quand un nouveau developpeur rejoint un projet avec une dette technique significative, il passe des semaines ou des mois simplement a comprendre le code existant. Il n'y a pas de documentation. Le code ne suit pas de patterns coherents. Les solutions de contournement sont empilees les unes sur les autres.
Dans un code source propre, un developpeur competent peut commencer a contribuer de maniere significative en quelques jours. Dans un code source tres endette, cela peut prendre des mois. Pendant cette periode de montee en competence, vous payez un salaire complet pour une productivite partielle.
Vous ne pouvez pas reagir aux changements du marche
Le cout le plus dangereux est peut-etre le cout d'opportunite. Quand chaque modification prend trois fois plus de temps qu'elle ne le devrait, vous ne pouvez pas pivoter rapidement. Un concurrent lance une fonctionnalite que vos utilisateurs reclament. Vous savez exactement quoi construire. Mais votre equipe estime trois mois a cause de la dette technique a contourner.
C'est ainsi que les entreprises techniquement endettees perdent leur position sur le marche. Pas par manque de vision ou de talent, mais parce que leur code source est devenu un boulet.
Comment la dette technique s'accumule
Comprendre les causes aide a les prevenir. La dette technique entre generalement dans un projet par cinq portes.
Porte 1 : La pression des delais
"Il faut lancer vendredi." C'est l'origine la plus courante. L'equipe prend des raccourcis pour respecter un delai : sauter les tests, coder en dur les valeurs, copier-coller au lieu de creer une fonction partagee. Ca marche. Ca sort. Et la dette est dans les comptes.
L'ironie cruelle : le temps "economise" par ces raccourcis est toujours rembourse avec des interets. Sauter une heure d'ecriture de tests aujourd'hui cree un bug qui prend huit heures a corriger le mois prochain.
Porte 2 : Des exigences floues
Quand les exigences sont vagues, les developpeurs font des suppositions. Differents developpeurs font des suppositions differentes. Le resultat est une logique incoherente, des fonctionnalites en double et du code qui repond a des exigences que personne n'a reellement formulees.
Plus tard, quand les vraies exigences deviennent claires, l'equipe doit remanier du code construit sur de fausses hypotheses. Ce remaniement est de la dette technique sous un autre nom.
Porte 3 : Pas de standards de codage
Sans standards convenus, chaque developpeur ecrit du code dans son propre style. Ce n'est pas un probleme quand une personne travaille sur un projet. Cela devient un probleme serieux quand cinq personnes y travaillent, et un cauchemar quand ces cinq personnes partent et cinq nouvelles arrivent.
Un code inconsistant est couteux a maintenir car chaque portion de code necessite de comprendre le style et les conventions individuels de son auteur.
Porte 4 : Sauter les tests
Les tests automatises sont le filet de securite qui permet aux developpeurs de modifier le code en confiance. Sans tests, chaque modification est un pari : "Je pense que ca marche, mais je ne peux pas etre sur de n'avoir rien casse d'autre."
Le resultat est soit un developpement tres lent et tres prudent (chaque modification est testee manuellement, ce qui prend des heures), soit des bugs frequents (les modifications sont livrees sans tests approfondis).
Porte 5 : La maintenance differee
Le logiciel depend de bibliotheques et frameworks externes qui sont regulierement mis a jour. Ces mises a jour incluent des correctifs de securite, des ameliorations de performance et des corrections de bugs. Quand vous differez ces mises a jour, vous prenez de plus en plus de retard. Finalement, l'ecart entre votre version et la version actuelle est si grand que la mise a jour devient un projet en soi.
C'est une dette technique qui s'accumule meme quand personne n'ecrit de code. Votre logiciel vieillit que vous le mainteniez ou non.
Strategies de prevention : eviter la dette des le premier jour
Strategie 1 : Investir dans les fondations
Les premiers 10 a 20 % d'un projet logiciel sont les plus determinants. C'est a ce moment que l'architecture est etablie, que les standards de codage sont fixes et que les patterns sont definis. Chaque raccourci pris pendant cette phase est amplifie a travers l'ensemble du projet.
Prenez le temps de mettre en place :
- Une structure de projet claire qui passe a l'echelle
- Des standards de codage que toute l'equipe respecte
- Un framework de tests des la toute premiere fonctionnalite
- Des controles automatiques de qualite du code qui s'executent a chaque modification
Strategie 2 : Rendre les tests non negociables
Les tests automatises ne sont pas une assurance qualite optionnelle. Ils font partie integrante du processus de developpement. Une fonctionnalite n'est pas terminee tant qu'elle n'a pas de tests.
Il existe une methodologie appelee Test-Driven Development (TDD) ou les developpeurs ecrivent le test avant d'ecrire le code de la fonctionnalite. Le test decrit ce que le code doit faire. Puis le developpeur ecrit le minimum de code necessaire pour passer le test. Cette approche a un effet secondaire remarquable : elle produit un code plus propre et plus modulaire car le code est concu pour etre testable des le depart.
Que votre equipe utilise un TDD strict ou une approche moins formelle, le principe est le meme : aucune fonctionnalite ne sort sans tests. C'est la strategie de prevention de la dette la plus efficace.
Strategie 3 : Imposer les revues de code
Une revue de code, c'est quand un autre developpeur examine le code avant qu'il ne soit fusionne dans le code source principal. Il ne s'agit pas de detecter des bugs (les tests font cela). Il s'agit de detecter les raccourcis, les incoherences et les problemes de conception avant qu'ils ne deviennent permanents.
Les revues de code fonctionnent mieux quand elles font partie integrante du processus, pas une occasion speciale. Chaque modification est revisee. Sans exception.
Strategie 4 : Allouer du temps pour la maintenance
Une regle empirique courante : allouez 15 a 20 % de la capacite de developpement a la maintenance. Cela inclut la mise a jour des dependances, le refactoring du code problematique, l'amelioration de la couverture de tests et la mise a jour de la documentation.
Ce n'est pas du temps improductif. C'est la difference entre un code source qui reste sain et un qui se deteriore lentement. Voyez-le comme l'entretien d'un batiment : vous pouvez le sauter un an, peut-etre deux, mais au bout du compte le toit fuit.
Strategie 5 : Rediger des exigences claires
Vous vous souvenez de la Porte 2 ? Des exigences floues menent a des suppositions, qui menent a du remaniement, qui est de la dette. Investir du temps dans des exigences claires et specifiques est l'une des mesures de prevention de la dette les plus rentables disponibles.
Vous n'avez pas besoin d'une specification de 50 pages. Vous avez besoin de reponses claires a : Que doit faire cette fonctionnalite ? Pour qui ? A quoi ressemble le succes ? Quels sont les cas limites ?
Strategie 6 : Privilegier la qualite a la vitesse aux points de decision
Tout au long d'un projet, il y a des moments ou l'equipe fait face a un choix : bien faire (prend plus de temps) ou faire vite (livre plus rapidement). Ce sont les moments ou la dette technique nait.
La bonne reponse n'est pas toujours "bien faire". Parfois un raccourci est justifie, en particulier pour des prototypes jetables, des demos de preuve de concept ou des fonctionnalites que vous prevoyez de remplacer bientot. Mais ce devraient etre des decisions conscientes et documentees, pas des habitudes inconscientes.
Quand un raccourci est pris deliberement, documentez-le. "Nous avons code en dur les paliers de tarification parce que nous devons lancer cette semaine. Cela devrait etre deplace dans la base de donnees d'ici le Sprint 12." Cela rend la dette visible et planifiee pour le remboursement.
Que faire si vous avez deja de la dette technique
La prevention est ideale, mais vous lisez peut-etre ceci parce que vous avez deja un probleme. Voici une approche realiste.
La reconnaitre
La dette technique prospere dans le deni. La premiere etape est de reconnaitre qu'elle existe et de la traiter comme un cout reel, pas comme une excuse de developpeur pour travailler lentement.
La quantifier
Demandez a votre equipe de developpement : "Si nous n'avions pas de dette technique, a quelle vitesse le developpement de fonctionnalites serait-il ?" Si la reponse est "30 a 40 % plus rapide", ce chiffre est le cout de votre dette, exprime en productivite perdue.
La rembourser progressivement
Vous ne pouvez pas arreter tout le developpement de fonctionnalites pour traiter la dette technique. Mais vous pouvez allouer une part de chaque cycle de developpement a son remboursement. La regle des 15-20 % s'applique ici aussi.
Priorisez le remboursement de la dette par impact : corrigez d'abord les zones qui ralentissent le plus le developpement ou causent le plus de bugs.
Prevenir la nouvelle dette
Il est inutile de rembourser la dette si vous en accumulez simultanement de la nouvelle. Mettez en oeuvre les strategies de prevention ci-dessus en parallele de vos efforts de remboursement.
L'approche qualite de Turtleship
L'un des principes fondamentaux de Turtleship est que la qualite doit etre integree, pas ajoutee apres coup. Quand la plateforme construit un logiciel a partir d'un cahier des charges, elle suit un processus methodique specifiquement concu pour prevenir la dette technique :
- Chaque fonctionnalite est construite avec des tests automatises des le depart
- Le code suit des standards coherents appliques par des controles automatiques
- Les modifications passent par un workflow structure de revue et d'approbation avant le deploiement
- Le processus de construction est le meme qu'il s'agisse de la premiere ou de la cinquantieme fonctionnalite
En resume
La dette technique n'est pas un probleme technique. C'est un probleme business. Elle se manifeste par un developpement plus lent, plus de bugs, des couts plus eleves et une capacite reduite a reagir aux changements du marche.
La bonne nouvelle : elle est largement evitable. Investissez dans les fondations, rendez les tests non negociables, revisez chaque modification, maintenez votre code source et redigez des exigences claires.
Le cout de bien faire les choses des le depart est toujours, toujours inferieur au cout de corriger ce qui a ete mal fait. Ce n'est pas une lecon que vous voulez apprendre par l'experience. C'est une lecon qui vaut la peine d'etre apprise par la lecture -- pour ne plus jamais avoir a la reapprendre.