Dans une équipe DevOps, le développement de produits nécessite des prises de décisions rapides quant aux fonctionnalités des logiciels. Mais celles-ci peuvent entraîner une dette technique qui privilégie la rapidité au détriment de la qualité. En conséquence, l'équipe doit fournir des efforts supplémentaires pour compenser les défaillances et la mauvaise qualité des livrables. Voici ce qu'est la dette technique et des conseils pour optimiser sa gestion.

Téléchargement  >> Le guide et la check-list pour rester pertinent dans le web 3.0

 

 

La notion de dette technique a été introduite en 1992 par Ward Cunningham, développeur de logiciels agiles. Elle exprime le fait que la rapidité d'un projet prime sur la qualité, ce qui demande un travail supplémentaire en aval. Par exemple, pour gagner du temps sur le développement d'un projet web ou baisser les coûts, l'équipe de développement peut faire l'impasse sur les tests unitaires ou ne pas respecter les règles de codage. Mais il peut y avoir des défauts involontaires qui peuvent compromettre la qualité du code et son maintien dans le temps.

La dette technique accumulée peut valoir la peine, mais elle peut aussi entraîner des résultats négatifs si elle est mal gérée.

 

Quels sont les types de dette technique ?

 

Il existe deux types de dettes techniques :

  • La dette technique volontaire : ici, la dette est intentionnelle. L'équipe prend volontairement la décision d'entreprendre des actions pour optimiser le présent plutôt que le futur pour privilégier la rapidité. Elle est consciente que des erreurs peuvent s'accumuler.
     
  • La dette technique involontaire : il s'agit d'une dette technique qui ne résulte pas d'une action délibérée. L'équipe se rend compte des erreurs après l'implémentation de la mise à jour du logiciel ou lorsque le projet web est terminé. Elle peut provenir d'un manque de compréhension, d'un code mal écrit ou d'erreurs accidentelles.

 

Quelles sont les causes d'une dette technique ?

 

La dette technique peut être le résultat de plusieurs facteurs. Lorsqu'une solution est développée, il est possible d'anticiper beaucoup d'éléments, mais certains échappent au contrôle de l'équipe et peuvent entraîner une dette technique. Il peut s'agir :

  • D'une technologie obsolète : développer des applications implique l'utilisation de plusieurs langages de codage, bibliothèques et frameworks, qui peuvent devenir obsolètes au fil du temps.
  • D'une pression pour tenir les délais de livraison : les équipes de développement ont tendance à lancer des applications incomplètes pour respecter les délais serrés imposés. Elles peuvent même décider de réduire la qualité et les performances pour sortir le produit plus rapidement sur le marché.
  • D'un changement constant : les applications complètes peuvent devenir obsolètes lorsqu'elles arrivent sur le marché. Cela est dû à l'évolution des attentes des clients, aux nouvelles opportunités du marché, aux cyberattaques.
  • D'une mauvaise gestion de la qualité : c'est le cas lorsque les projets n'incluent aucun mécanisme de contrôle, de test et de mesure pour assurer la qualité. Par conséquent, les dettes s'accumulent.
  • D'une externalisation du code : la dette technique survient lorsque les étapes de développement sont délocalisées. Des erreurs peuvent apparaître dans le code lorsque les sections sont rassemblées. Celles-ci peuvent être acceptées ou occultées par l'équipe.
  • D'un manque de compétences.

 

 

 

Faire un suivi des dettes techniques

La première chose à faire est de dresser une liste des dettes dans un système de suivi. Les tâches à rembourser doivent apparaître dans le système de suivi, avec le temps et les efforts associés.

Cette liste de dettes doit être intégrée à un backlog produit qui servira à suivre leur évolution. Les dettes datant de plus de 90 jours doivent être considérées comme critiques.

 

Planifier la dette dans les sprints

Il n'est pas nécessaire de consacrer un sprint entier à la gestion de la dette technique. Néanmoins, prendre en compte la dette et la prioriser dans les sprints sont des bonnes solutions pour la réduire au fil du temps.

Dans les itérations en cours, il faut inclure la dette qui impacte l'activité en production ou affecte d'autres modules.

Lorsque la dette est liée à la refactorisation du code, à l'optimisation ou à la lisibilité, elle peut être planifiée dans les sprints futurs.

 

Mettre en place des tests

La dette technique peut résulter d'un manque de tests en faveur de la rapidité. Pour mieux la gérer et l'éviter, il est conseillé d'effectuer régulièrement des tests complets. Ils permettent d'identifier les défauts présents dans le code, ce qui permet de les corriger à un stade précoce.

Il est possible, et même recommandé, d'automatiser ces tests pour éviter les erreurs humaines et supprimer les sources supplémentaires de dette technique.

 

Réécrire le code si nécessaire

Il est parfois nécessaire de réécrire le code pour réduire la dette technique. Cette solution est à prendre avec des pincettes, car il peut s'agir d'une manœuvre dangereuse. Il faut bien évaluer la situation avant d'opter pour la réécriture du code d'un module ou du paquet.

Une autre solution consiste à s'appuyer sur une POO (programmation orientée objet) qui permet de limiter les écarts d'architecture et donc la dette technique.

 

Comment rembourser la dette technique ?

 

Pour rembourser la dette technique, il s'agit d'abord de la détecter et de la mesurer, c'est-à-dire de faire un état des lieux des bugs et des défaillances existants.

Après les avoir tous recensés, il convient de les corriger par itérations sans attendre la fin du projet. Ces phases de sprints sont importantes, car elles permettent de garder les équipes motivées. Corriger les bugs pendant des jours voire des semaines a tendance à être décourageant pour les développeurs.

Il est aussi conseillé de miser sur la transparence et la communication au sein de l'équipe, qui peut accélérer le processus de remboursement.

 

Quelles sont les conséquences d'une dette technique ?

 

La dette technique peut être comparée à la dette bancaire. Lorsque les remboursements ne se font pas aux échéances ou que la période est rallongée, la dette s'accumule. Il faut néanmoins y faire face un jour.

Pour la dette technique, c'est le même cercle vicieux. Moins les bonnes pratiques sont respectées, plus le code sera de mauvaise qualité et plus il sera difficile de rembourser la dette. Cela entraîne des conséquences directes sur les évolutions du code et le coût de la maintenance.

Avec la dette technique, il est de coutume de penser faire des économies en codant de manière rapide. Mais c'est faux : dans le futur, il faudra débourser du temps et de l'argent pour corriger les failles et rembourser cette dette.

 

2 exemples de dette technique

 

La dette technique volontaire

Afin d'illustrer la dette technique volontaire, voici un exemple :

L'équipe opte pour un cadre facile à développer, ayant des capacités fonctionnelles minimales et qui est connu pour avoir des problèmes de performance. Sa solution : utiliser des applications supplémentaires qui permettent d'ajouter les fonctionnalités manquantes après l'implémentation du logiciel.

En conséquence, l'équipe devra retravailler sur les fonctionnalités manquantes après le lancement, ce qui entraînera des coûts supplémentaires.

 

La dette technique involontaire

Voici désormais un exemple de dette technique involontaire :

L'équipe est constituée d'une majorité de développeurs juniors qui participent au lancement d'une nouvelle fonctionnalité logicielle dans un délai court. Il n'y a pas assez de développeurs seniors pour vérifier et valider chaque élément du code.

Pour tenir les délais du plan de déploiement, l'équipe confie la mission à une équipe temporaire de développeurs seniors supplémentaires pour examiner le code et son bon fonctionnement.

Les problèmes ont été résolus en partie, mais le manque de communication entre l'équipe à temps plein et l'équipe supplémentaire a entraîné l'oubli de quelques bugs dans le code. L'équipe devra les corriger après le lancement.

 

Pour aller plus loin, découvrez les opportunités d'affaires liées aux évolutions du web en téléchargeant le guide et la checklist ultime du web 3.0, ou découvrez le logiciel marketing de HubSpot. Rester pertinent dans le web 3.0

Publication originale le 29 mai 2023, mise à jour le 29 mai 2023

Sujet(s):

Développement web