Dette technique : la comprendre, la mesurer et la rembourser avant qu’elle ne freine votre produit

La dette technique désigne le travail supplémentaire qu’un logiciel impose à l’équipe qui le fait évoluer, à cause des raccourcis pris pendant son développement : un test sauté, une solution provisoire restée en place, une architecture qui ne correspond plus au produit. Comme une dette financière, elle se rembourse en reprenant le code. Tant qu’elle n’est pas remboursée, elle coûte des intérêts : chaque nouvelle fonctionnalité prend plus de temps et casse davantage de choses.

L’étude The Developer Coefficient, publiée par Stripe en 2018 et menée auprès de plus de 1 000 développeurs, estimait qu’ils passaient 13,5 heures par semaine sur la dette technique, soit environ un tiers de leur temps de travail. En 2020, McKinsey a interrogé 50 DSI de grandes entreprises : 10 à 20 % du budget qu’ils prévoyaient pour de nouveaux produits servait en réalité à résoudre des problèmes liés à la dette.

Tout projet de développement d’application finit par accumuler de la dette technique. Cet article explique d’où elle vient, ce qu’elle coûte, comment la mesurer et comment la rembourser sans geler la roadmap. Sur une application existante, faites-la chiffrer par un audit de code avant de décider quoi corriger.

Comprendre la dette technique

Qu’est-ce que la dette technique ?

Une métaphore empruntée à la finance

La dette technique regroupe toutes les concessions faites par une équipe de développement au détriment de la qualité du code, le plus souvent pour tenir un délai serré ou un objectif commercial :

• une solution sous-optimale, par exemple moins performante

• des bonnes pratiques mises de côté

• des tests sautés.

On doit le terme à Ward Cunningham, développeur et co-auteur du Manifeste agile. En 1992, lors de la conférence OOPSLA, il prend la dette financière comme métaphore pour présenter le concept :

“Quand on sort la première itération du code, c’est pareil que s’endetter. Une petite dette permet d’avancer plus vite dans le développement, à condition qu’on la rembourse rapidement après, par une réécriture. Là où est le danger c’est quand la dette reste impayée. Chaque minute où on se sert d’un code imparfait est un intérêt sur cette dette. Des entreprises de développement peuvent se retrouver complètement entravées par le poids d’une dette due à une implémentation non consolidée[...]” (Traduit de l’anglais)

Volontaire ou involontaire : le quadrant de Fowler

Une équipe a parfois de bonnes raisons de contracter de la dette technique. Elle peut choisir un raccourci pour sortir une version avant un salon ou pour tester une hypothèse auprès des premiers clients. On parle alors de dette technique volontaire. Elle se décide de préférence pendant le cadrage du projet, avec une date de remboursement.

La dette involontaire vient des erreurs, d’une équipe qui communique mal ou d’un contrôle qualité absent. Comme personne ne l’a choisie, elle passe souvent inaperçue jusqu’à ce qu’elle ralentisse le produit.

Martin Fowler, spécialiste de l’architecture logicielle, ajoute une seconde distinction dans son quadrant de la dette technique : une dette délibérée ou involontaire peut aussi être prudente, prise en connaissance de cause, ou imprudente.

Le coût de la dette technique pour le produit et les équipes

Quand la dette s’accumule, le produit devient de plus en plus difficile à faire fonctionner et à faire évoluer. L’équipe entre alors dans un cercle vicieux :

• chaque modification est longue et génère des bugs

• pour avancer vite, l’équipe se rabat sur des solutions rapides mais sous-optimales, des « hacks »

• ces hacks ajoutent encore de la dette.

L’équipe de développement finit par passer plus de temps à contourner le code existant qu’à livrer de nouvelles fonctionnalités. Peu de développeurs aiment travailler dans ces conditions, si bien que les départs se multiplient et que les recrutements deviennent plus difficiles.

Exemples de sources de dette technique

• Les conventions du projet sont mal respectées. Quand chaque équipe a ses propres règles de nommage et de syntaxe, les développeurs jonglent entre plusieurs styles et le code devient moins lisible.

• La documentation manque. L’équipe n’a jamais eu le temps de documenter le code ni l’architecture. Chaque départ fait perdre de la connaissance, les nouveaux développeurs mettent plus longtemps à prendre le code en main et certaines évolutions deviennent très longues, voire impossibles.

• Des bugs restent à moitié réglés. Un bug corrigé à la va-vite, sans connaître sa cause réelle, en génère de nouveaux, plus difficiles à résoudre.

• Les choix d’architecture ne correspondent plus au produit. Quand le produit change de cible ou de taille, chaque nouvelle fonctionnalité doit composer avec une structure pensée pour un autre produit.

• Du code mort ou obsolète reste dans le logiciel. Il ne sert plus, mais personne ne l’a retiré. Il est difficile à repérer, il peut dégrader les performances et il complique la maintenance.

• Les dépendances ne sont jamais mises à jour. Un framework ou une bibliothèque resté plusieurs versions en arrière finit par ne plus recevoir de correctifs de sécurité, alors que sa mise à jour est devenue un chantier en soi.

• Du code généré par un assistant IA est intégré sans relecture. Les assistants de code font gagner beaucoup de temps, à condition qu’un développeur expérimenté relise ce qu’ils produisent. Sans cette relecture, du code dupliqué et des patterns que personne dans l’équipe ne maîtrise entrent dans le projet.

Pourquoi gérer la dette technique ?

Pour reprendre les mots de Cunningham, la dette doit rester au stade de la « petite dette ». Au-delà, elle coûte de plus en plus cher.

Conséquences d’une gestion trop tardive

Plus la dette s’accumule, plus elle est longue et coûteuse à rembourser. C’est pour cela qu’il vaut mieux la gérer en continu, en lui réservant du temps à chaque cycle de développement.

Un code devenu complexe ralentit aussi le développement des fonctionnalités à venir. Les coûts de maintenance augmentent, car corriger les bugs et régler les problèmes de performance prend de plus en plus de temps.

Ces ralentissements repoussent les livraisons. Les clients attendent plus longtemps les fonctionnalités promises, ce qui peut nuire à la réputation de l’entreprise.

Bénéfices d’une gestion proactive

Une équipe qui améliore la qualité de son code en continu :

• réduit les bugs et les problèmes de performance

• livre des produits plus stables et plus performants

• facilite la maintenance du code

• réduit les coûts de développement à long terme

• peut changer de direction plus vite quand le produit l’exige.

Comment gérer la dette technique ?

En créer le moins possible : sensibiliser et former

Quand on code, on est concentré sur un objectif précis, avec un temps toujours compté. Dans ces conditions, il est difficile de prendre du recul sur la dette qu’on est en train de créer.

Formez donc les équipes de développement à repérer la dette technique et à soigner la qualité du code.

Les équipes produit et les managers ont besoin de la même sensibilisation. Ils fixent les plannings, donc c’est à eux de laisser aux développeurs le temps de garder la dette à un niveau raisonnable.

En créer le moins possible : outils et méthodes

Les outils d’analyse de code vérifient que les conventions sont respectées. Les linters et les formateurs de code uniformisent l’écriture du code. Les tests automatisés repèrent les régressions avant la mise en production. Une équipe qui pratique le développement piloté par les tests (TDD) écrit le test avant le code, si bien que chaque fonctionnalité arrive avec ses tests.

La revue de code et la programmation en binôme complètent ces outils : un deuxième développeur repère les raccourcis avant qu’ils n’entrent dans le code.

Mesurer la dette technique : outils et KPI

L’analyse statique du code est la méthode de suivi la plus utilisée. Un outil comme SonarQube relit le code sans l’exécuter et relève les erreurs, les règles non respectées, les mauvais patterns et le code mort. Il estime ensuite le temps nécessaire pour tout corriger.

Rapporté au coût estimé de développement du code, ce temps donne le ratio de dette technique, un indicateur inspiré de la méthode d’évaluation SQALE. SonarQube attribue la meilleure note de maintenabilité, A, aux projets dont le ratio reste sous 5 %.

Choisissez ensuite les KPI adaptés à votre projet et à votre équipe, par exemple :

• la complexité cyclomatique des fonctions les plus modifiées

• la couverture de tests

• le taux de code dupliqué

• le nombre de bugs et de régressions par livraison

• le délai moyen de livraison d’une fonctionnalité, suivi d’un mois sur l’autre

• l’âge des dépendances principales.

Ces outils mesurent la dette visible dans le code. Les choix d’architecture qui ne correspondent plus au produit leur échappent, tout comme les zones que l’équipe n’ose plus toucher. Pour les repérer, faites relire le code par des développeurs qui n’ont pas travaillé dessus, en interne ou avec un audit de code externe.

Réduire : intégrer la dette aux cycles de développement

Si personne ne réserve de temps à la dette dans les cycles de développement, elle s’accumule. Un créneau fixe, une heure par jour ou un jour par semaine, suffit souvent à la contenir.

La méthode Shape Up de Basecamp prévoit un « cool-down » de deux semaines après chaque cycle de six semaines. Pendant ce temps, l’équipe souffle, corrige des bugs et rembourse de la dette technique.

Avec Scrum, les tâches de dette rejoignent le backlog produit et sont priorisées au même titre que les fonctionnalités, au moment de planifier chaque sprint.

Un budget pour rembourser la dette

Toutes ces méthodes n’ont de sens que si l’entreprise donne des moyens concrets, donc du temps et du budget, pour rembourser sa dette technique.

Les équipes techniques connaissent en général le poids de la dette. Les équipes produit, elles, peuvent avoir l’impression que tout tourne bien et ne pas voir l’intérêt d’y consacrer du temps.

Les jours réservés dans les sprints disparaissent alors au profit de nouvelles fonctionnalités, si bien que les refactorings attendus prennent du retard. Pour défendre ce budget, chiffrez la dette avec le ratio de dette technique et vos KPI de qualité. La discussion porte alors sur des heures perdues et des bugs mesurés.

Audit, refactoring ou refonte : décider avec un regard extérieur

Quand la dette ralentit déjà chaque livraison, l’équipe qui travaille sur le code au quotidien a du mal à juger s’il faut le reprendre par morceaux ou le réécrire. Un audit de code aide à trancher. Des développeurs extérieurs au projet passent le code au crible, listent les problèmes, les classent par priorité et recommandent un plan d’action.

L’audit recommande en général l’une de ces trois suites :

• un refactoring progressif, quand l’architecture tient encore et que la dette est localisée

• une reprise ciblée, quand un ou deux modules concentrent l’essentiel des problèmes

• une refonte de l’application, quand l’architecture ne correspond plus du tout au produit.

Chez Lonestone, l’audit de code dure de 1 à 5 jours. Des audits du design, des fonctionnalités d’IA et de la cybersécurité de l’application peuvent le compléter.

Pratiques de réduction de la dette technique

Pour former les équipes, donnez-leur aussi quelques bonnes pratiques à appliquer chaque jour.

Encourager l’amélioration progressive

L’amélioration progressive est une affaire de culture d’équipe : chaque développeur améliore le code chaque fois qu’il travaille dessus, même par petites touches. Il renomme une variable mal nommée, il supprime une ligne de code obsolète.

Dans le même esprit, discutez régulièrement en équipe :

• de l’état du code

• des moyens de l’améliorer

• de la façon d’affiner la stratégie produit déjà en place.

Ces petites améliorations quotidiennes sont moins risquées et plus faciles à corriger qu’un gros refactoring, qui peut introduire de nombreux bugs d’un coup.

Écrire un code lisible, documenté et testé

Choisissez des noms de variables, de fonctions et de classes aussi clairs que possible, pour que n’importe quel membre de l’équipe s’y retrouve rapidement. Une fonction nommée calculerTotalFacture est beaucoup plus explicite que ctf. Fixez aussi des règles d’indentation et de formatage communes, qu’un formateur automatique applique à tout le monde.

Documentez le code dès le départ. Les développeurs qui arrivent comprennent alors le code existant et le modifient sans créer de nouvelle dette.

Les tests restent le passage obligé pour garantir la qualité du code et du produit, car ils signalent dès qu’une modification casse quelque chose.

Respecter le principe DRY

Le principe DRY, pour « Don’t Repeat Yourself », demande de créer des abstractions, comme des classes ou des fonctions, plutôt que de dupliquer des lignes de code. Le code reste plus court. Surtout, une correction faite à un endroit s’applique partout, alors qu’un code dupliqué multiplie les risques d’erreurs et de problèmes de performance.

Supprimer le code obsolète

Le code obsolète est souvent noyé dans le reste du code, ce qui le rend fastidieux à retrouver. Des outils spécialisés repèrent les blocs inutilisés. Les revues de code régulières aident aussi à identifier les zones problématiques. Comme le reste de la dette, ce ménage est plus facile petit à petit que d’un seul coup, dans l’urgence.

La dette technique se gère en continu. Les développeurs y reviennent régulièrement pour protéger la qualité du code, le bon fonctionnement du produit et le moral de l’équipe.

Lonestone a développé des produits sur mesure pour plus de 200 clients depuis 2014, avec des ingénieurs qui ont pour la plupart entre 10 et 25 ans d’expérience. Pour mesurer la dette de votre application, ou pour faire évoluer votre produit sur une base saine, contactez-nous.