Comment maîtriser sa dette technique

La dette technique est une idée lumineuse de Ward Cunningham en 1992, qui a comparé le développement logiciel à un prêt bancaire.

Sauf que les intérêts, c’est du code bancal difficile à maintenir, des bugs récalcitrants, et des délais qu’on ne maîtrise plus.

Votre projet ressemble à une longue partie de Whac-A-Mole : vous corrigez un bug, deux autres surgissent et ça finit par rattraper l’équipe, qui s’épuise à éteindre des incendies au lieu d’innover.

Dans cet article, on fait le point : la définition de la dette technique, pourquoi elle peut être utile (si, si !), et surtout comment éviter qu’elle ne devienne un boulet.

Spoiler : ignorer la dette technique, c’est un aller simple vers des clients frustrés et des projets hors de contrôle.

In fine, l’accumulation de dette technique freine l’innovation et ralentit la mise en ligne de nouvelles fonctionnalités.

Mais pas de panique, il y a des solutions.

Qu’est-ce que la dette technique

C’est assez simple en fait, la dette technique, c’est tout ce qui rend un projet logiciel plus compliqué à maintenir, à tester ou à faire évoluer.

Un des symptômes les plus courants, c’est l’augmentation des coûts de maintenance à périmètre fonctionnel constant.

Ce coût peut s’exprimer en temps dédié à la maintenance ou comme frein à l’innovation.

Dans bien des cas, la dette technique est volontaire et rationnelle : une application ou une fonctionnalité en ligne peut être rentabilisée rapidement au prix d’une dette technique supplémentaire qu’il faudra payer en temps de travail, bugs ou régressions supplémentaires.

Mais elle peut être involontaire : certains choix technologiques douteux, une perte de compétences dans l’équipe, l’obsolescence mal anticipée des briques sous-jacentes, par exemple, peuvent contribuer à son accroissement.

Il est important de noter que la dette technique est un aspect inévitable et naturel des projets informatiques. À tel point que certains n’hésitent pas à dire que tout code est de la dette technique. Il ne s’agit donc pas de vivre sans mais de l’évaluer et la maîtriser.

Comment s’accroît la dette technique

Privilégier la vitesse à la qualité

La pression du temps, c’est le grand classique. On veut livrer vite, respecter coûte que coûte la deadline et on finit par bâcler la qualité ou la performance.

Les équipes publient des fonctionnalités incomplètes, mal testées, juste pour pouvoir dire « mission accomplie ». Et on se retrouve avec une montagne de correctifs à apporter, et votre dette technique gonfle à vitesse grand V.

L’hétérogénéité technologique

Empiler les langages, frameworks et bases de données pour expérimenter ce n’est pas de l’innovation et en pratique, c’est souvent la recette d’une stack difficile à maintenir.

Entre couches d’abstraction inutiles et systèmes qui ne communiquent pas bien entre eux, on obtient une architecture hétéroclite où chaque petite évolution peut devenir un véritable casse-tête.

Et ça ne s’arrête pas là : même les applis terminées dans les temps peuvent se retrouver obsolètes dès leur sortie. Les attentes des clients grimpent en flèche, les cyberattaques évoluent, et le turn over des développeurs fait que l’on perd régulièrement l’expertise qui faisait tourner la boutique. Résultat : on passe plus de temps à rafistoler le chantier qu’à innover.

Une conséquence fréquente de l’hétérogénéité technologique est le décalage entre les environnements de Dev, de Préprod et de Prod. Ces divergences compliquent les tests, introduisent des bugs imprévus lors des déploiements et ralentissent la résolution des incidents. Standardiser les environnements à l’aide de conteneurs ou d’outils CI/CD limite ces risques.

L’obsolescence des logiciels sous-jacents

Les frameworks, CMS, et autres bibliothèques que vous utilisez pour créer vos applications connaissent elles-mêmes un cycle de vie et finissent par devenir obsolètes.

Cette obsolescence peut avoir plusieurs nivaux de criticité, leur manque de modernité peut impacter la productivité de vos équipes ou elles peuvent tout simplement ne plus être maintenues.

D’où l’importance d’utiliser des frameworks matures, qui ne seront pas abandonnés au bout de 5 ans ou dont les sauts de version majeures ne nécessitent une réécriture quasi complète du code source de votre application.

L’importance du suivi des versions est la raison pour laquelle nous avons mis en place sur notre dashboard de pilotage multicloud un espace dédié aux versions des CMS les plus couramment utilisés.

Suivre le cycle de mise à jour des briques sous-jacentes de vos applications et bien choisir ces briques est essentiel pour maintenir votre dette technique à des seuils acceptables.

Multiplier les couches d’abstraction

Une source souvent sous-estimée d’accroissement de la dette technique, est la tendance, assez compréhensible, à empiler les couches d’abstraction.

Parce qu’elle place l’ingénieur (quel que soit son rôle) en position d’utilisateur elle aura pour impact d’aliéner l’équipe technique de son outil de travail.

Avant d’utiliser une bibliothèque ou un orchestrateur il faut évaluer le coût d’intégration et l’impact des mises à jour spécifiques nécessaires tout au long de la durée de vie de votre application.

Evaluer et réduire sa dette technique

Calcul de la dette technique

Il existe des outils qui se proposent d’évaluer votre dette technique. Cette évaluation s’appuie sur des données concrètes.

Chez Bearstech, nous avons fait le choix d’intégrer Sonarqube à notre workflow DevOps

Pour évaluer la dette technique, il est essentiel de disposer d’indicateurs objectifs.

C’est exactement ce que propose SonarQube grâce à son ensemble de métriques et de rapports d’analyse continue.

Voici les principales mesures disponibles, telles que décrites dans la documentation officielle de SonarQube :

Lignes de code (Lines of code / LOC)

Nombre total de lignes de code analysées. Cette donnée permet de suivre la taille d’un projet et d’orienter les efforts d’optimisation.

Complexité

Mesure la complexité du code, généralement à travers la complexité cyclomatique, qui indique le nombre de chemins logiques possibles dans le code. Un score de complexité élevé peut signaler une base de code plus difficile à comprendre, à tester et à maintenir.

Coverage

Évalue le pourcentage de code couvert par les tests unitaires. Un taux de couverture élevé aide à prévenir les régressions et facilite la maintenance du projet sur le long terme.

Duplication de code

Détecte les portions de code copiées-collées (clones) dans le projet. La duplication de code peut augmenter la dette technique car chaque modification nécessite d’être reportée dans plusieurs endroits.

Fiabilité

Mesure la propension du code à produire des bugs. SonarQube attribue un rating (A, B, C, etc.) basé sur la présence et la sévérité des bugs détectés.

Maintenabilité

Regroupe l’ensemble des code smells et autres défauts de conception ou d’implémentation qui rendent le code plus complexe à faire évoluer.

Sécurité

Identifie les vulnérabilités potentielles et les points sensibles (Hotspots). Avoir un bon rating en sécurité est indispensable pour réduire la dette technique liée à la correction de failles critiques.

Grâce à ces indicateurs, SonarQube fournit une vision claire de la qualité du code et met en évidence les zones qui requièrent une attention particulière.

L’intégration de SonarQube dans votre workflow DevOps, vous permet de suivre votre dette technique en temps réel et agir rapidement pour empêcher qu’elle ne s’accumule de manière incontrôlée.

Pour en savoir plus sur le calcul de la dette technique de Sonarqube.

Maîtriser et réduire sa dette technique

Rembourser sa dette technique passe par des bonnes pratiques qu’il convient de mettre en place le plus tôt possible.

Réduire sa dépendance aux dépendances …

Chaque dépendance ajoutée à votre projet doit être soigneusement évaluée.

Pesez toujours le pour et le contre : apporte-t-elle une vraie valeur ajoutée ou complique-t-elle inutilement l’écosystème technique ?

En effet, les dépendances c’est du code écrit par d’autres qui devient votre problème. Cela inclut des risques de sécurité, des mises à jour complexes ou des dysfonctionnements imprévisibles.

De plus, évitez les dépendances qui en tirent d’autres en cascade, et qui augmente la complexité globale de votre code source.

Mettre en place une revue de code systématique

Les revues de code permettent de détecter tôt les mauvaises pratiques, les duplications de code susceptibles d’engendrer de la dette technique. En prime, cela améliore le partage de connaissances entre développeurs.

Tester, tester et… retester

Des tests unitaires et d’intégration solides sont la meilleure parade contre la régression. Plus votre couverture de test est élevée, plus vous évitez les effets de bord qui font s’accumuler les correctifs et la dette technique.

Maintenir un backlog dédié à la dette technique

La dette technique ne doit pas être traitée en mode pompier. Créez un backlog spécifique, priorisez les points critiques et planifiez régulièrement des itérations consacrées à la dette.

Normaliser la stack technologique

Résistez à la tentation de multiplier frameworks et bibliothèques “dernier cri” sans réelle stratégie.

La cohérence technologique réduit le nombre de briques à maintenir et facilite la mutualisation des compétences dans l’équipe.

Surveiller en continu

Utiliser SonarQube et d’autres outils d’analyse de code en intégration continue permet de repérer, dès le stade du pull request, les problèmes qui alourdissent la dette.

Mieux vaut prévenir que guérir !

Garder un œil sur l’obsolescence

Mettez en place une veille sur les cycles de vie des langages, frameworks et bibliothèques que vous utilisez.

Tester les versions récentes, prévoir à l’avance les migrations, et profiter des fonctionnalités plus modernes et sécurisées.

Conclusion

Il faut accepter la dette technique comme un paramètre naturel de tout projet logiciel, l’essentiel, c’est de la garder sous contrôle.

Reconnaître qu’elle existe et la mesurer régulièrement avec des outils comme SonarQube. Pour la gérer de façon proactive plutôt que de subir ses effets.

N’oubliez pas qu’il peut être stratégique d’accroître la dette technique pour livrer rapidement et tester un marché.

Mais si vous faites l’autruche trop longtemps, c’est la spirale infernale : bugs qui s’accumulent, temps de maintenance qui explose et innovations mises en veille.

Bref, il faut trouver le bon équilibre pour que votre projet reste performant sur le long terme tout en répondant aux exigences du marché !