MaintenanceMéthodeApplication métierDSI
Dette technique : l'expliquer simplement à un dirigeant
6 min de lecture
La dette technique est le coût futur des raccourcis pris dans un logiciel. Comme un emprunt, un raccourci fait gagner du temps tout de suite, puis coûte des intérêts : chaque évolution devient plus lente, plus chère et plus risquée, jusqu'à ce que le code concerné soit repris. Ce n'est pas forcément une faute, c'est une décision de gestion, qui se mesure, se pilote et se rembourse.
Cet article explique l'image à l'origine du terme, les signes visibles depuis la direction, ce que la dette coûte vraiment et les façons de la rembourser sans arrêter l'activité.
D'où vient l'expression
Le terme vient de Ward Cunningham, l'un des pionniers des méthodes agiles. En 1992, dans un retour d'expérience présenté à la conférence OOPSLA sur un logiciel de gestion de portefeuilles financiers, The WyCash Portfolio Management System, il écrit, en substance : livrer un code de premier jet, c'est comme s'endetter ; un peu de dette accélère le développement, à condition d'être remboursée rapidement par une réécriture. Le danger apparaît quand la dette n'est pas remboursée : chaque minute passée sur du code « pas tout à fait juste » compte comme un intérêt.
L'image a été choisie pour parler à des financiers, et elle fonctionne toujours avec un dirigeant, parce qu'elle remplace un débat technique par une question de gestion : combien emprunte-t-on, à quel taux, et quand rembourse-t-on ?
Le vocabulaire financier, traduit en logiciel
| Terme financier | En logiciel | Ce que vous en voyez |
|---|---|---|
| Emprunt | Un raccourci pris pour livrer plus vite | Une date tenue |
| Capital | Le travail à refaire pour corriger le raccourci | Rien, au début |
| Intérêts | Le temps perdu à chaque modification du code concerné | Des évolutions plus lentes et plus chères |
| Surendettement | Des intérêts qui absorbent tout le temps de l'équipe | Plus rien n'avance |
Le point important est le troisième : les intérêts se paient à chaque fois qu'on touche le code concerné. Une dette logée dans un module que personne ne modifie coûte peu. La même dette au cœur de la facturation, que vous faites évoluer tous les mois, coûte cher en permanence.
Toute dette n'est pas une faute
Le développeur et auteur Martin Fowler a proposé une grille utile pour classer les dettes, son quadrant de la dette technique (2009). Il croise deux questions : la dette a-t-elle été prise volontairement, et l'a-t-elle été avec prudence ?
| Délibérée | Involontaire | |
|---|---|---|
| Prudente | « Nous livrons maintenant et reprendrons ce point après le lancement. » | « Maintenant, nous savons comment nous aurions dû le concevoir. » |
| Imprudente | « Nous n'avons pas le temps de bien faire. » | Une équipe qui ignore les bonnes pratiques, sans le savoir. |
La dette prudente et délibérée est une décision saine : tenir un salon, tester un marché, livrer un MVP avant d'investir davantage. La dette prudente et involontaire est inévitable, parce qu'une équipe comprend mieux votre métier au fil du projet. Les deux autres cases sont celles qui posent problème, parce qu'elles s'accumulent sans que personne ne les ait décidées ni chiffrées.
Les signes visibles depuis la direction
Vous n'avez pas besoin de lire le code pour soupçonner une dette élevée. Les symptômes apparaissent dans le pilotage :
- les petites évolutions sont chiffrées de plus en plus cher, sans que leur contenu ait changé ;
- chaque correction en casse une autre, et les mises en production inquiètent l'équipe ;
- les mises à jour de sécurité sont repoussées, parce qu'elles « risquent de tout casser » ;
- une seule personne sait intervenir sur une partie critique, et son absence bloque tout ;
- l'équipe parle de tout réécrire à chaque nouvelle demande ;
- les délais annoncés ne sont plus jamais tenus, alors que l'équipe n'a pas changé.
Un seul de ces signes peut avoir une autre cause. Plusieurs à la fois désignent presque toujours une dette qui n'est plus pilotée.
Ce que coûte la dette
Les chiffres disponibles viennent d'enquêtes déclaratives : ils donnent un ordre de grandeur, pas une mesure de votre application.
- En 2018, l'enquête The Developer Coefficient de Stripe, menée avec Harris Poll auprès de plus de 1 000 développeurs et 1 000 dirigeants aux États-Unis, au Royaume-Uni, en France, en Allemagne et à Singapour, estime que les développeurs consacrent en moyenne 17,3 heures par semaine (sur 41,1 heures travaillées) à la maintenance : mauvais code, erreurs, débogage, reprises. La France affichait la moyenne la plus élevée, 20,9 heures.
- En 2020, une enquête de McKinsey auprès de 50 directeurs informatiques de grandes entreprises des services financiers et de la technologie, Tech debt: Reclaiming tech equity, rapporte que 10 à 20 % du budget technologique destiné aux nouveaux produits est détourné vers des problèmes liés à la dette technique.
Pour une PME, ces moyennes comptent moins que le symptôme local : si une évolution qui prenait deux jours en prend désormais dix, la différence est l'intérêt de la dette, et vous le payez à chaque demande.
Rembourser sans tout arrêter
La bonne stratégie dépend de l'endroit où se trouve la dette et du rythme auquel vous faites évoluer l'application.
- Faire l'inventaire. Lister les dettes connues, les localiser et estimer, pour chacune, ce qu'elle coûte à chaque modification. Un audit de l'application le fait de façon indépendante.
- Rembourser là où l'on travaille. Reprendre le code au moment où on le modifie, plutôt que dans un grand chantier séparé : c'est là que les intérêts sont payés, donc là que le remboursement rapporte.
- Réserver une part régulière. Une fraction fixe de chaque cycle de développement consacrée au nettoyage, aux tests et aux mises à jour évite le surendettement. Le niveau se décide avec l'équipe, selon l'état du code.
- Sécuriser avant de modifier. Des tests automatiques sur les parties critiques permettent de reprendre le code sans casser le reste.
- Tenir les dépendances à jour. Une bibliothèque laissée sans mise à jour pendant des années devient une dette, puis un risque de sécurité. C'est le cœur de la maintenance d'une application métier.
La réécriture complète reste l'exception : elle se justifie quand les intérêts dépassent le coût d'une refonte, par exemple quand la technologie n'est plus maintenue. Nous traitons ce cas dans refondre un logiciel métier qui n'est plus maintenu.
Les questions à poser à votre équipe ou à votre prestataire
- Quelles sont nos trois dettes les plus coûteuses, et où sont-elles ?
- Quelle part du temps de développement va aux intérêts plutôt qu'aux nouvelles fonctions ?
- Quelles dettes avons-nous prises volontairement, et quand prévoit-on de les rembourser ?
- Nos dépendances et notre socle technique sont-ils encore maintenus ? Notre article sur les technologies d'une application métier aide à le vérifier.
Une équipe qui répond précisément à ces questions pilote sa dette. Une équipe qui ne le peut pas la subit, et vous avec elle.
Par où commencer
Notez les trois dernières évolutions demandées sur votre application, ce qu'elles ont coûté et combien de temps elles ont pris : c'est votre premier indicateur de dette. Si une refonte devient nécessaire, chez LPR Studio, le prototype visuel de la nouvelle version est gratuit et présenté en visio sous 5 jours ouvrés, pour que vous voyiez la cible avant de décider. Notre démarche est décrite sur la page de notre approche.