La dette technique, c'est quoi ?

Qu'est-ce que la dette technique ? Est-il possible de l'éviter ? Comment la rembourser ? On répond à toutes vos questions !

Si vous intervenez sur des projets de développement web, vous avez certainement déjà entendu parler de dette technique. Ce concept évoque la pérennité et l'évolution des développements informatiques sur la durée. Anaelle, développeuse web, répond à nos questions sur la dette technique.

Pour commencer, c'est quoi au juste la dette technique ?

Lorsqu'on démarre un projet web, on décrit les bonnes pratiques : les tests à réaliser, les librairies à utiliser... On réfléchit aux meilleurs choix techniques à un instant T pour répondre aux attentes du client. Et on s'imagine toujours qu'on évitera ainsi les "couacs". Mais ce n'est évidemment pas si simple !

La réalité est en effet bien différente. Même sur un nouveau projet, on démarre très rarement à partir d'une feuille blanche. On doit souvent faire face à un existant et il faut bien faire avec !

Le code source du site ou de l'application peut présenter des défauts qui incombent parfois aux développeurs ou autres techs intervenants sur le projet. Pour gagner du temps sur le développement ou diminuer les coûts on fait l'impasse sur les tests unitaires, on ne commente pas le code, on en respecte pas les règles de codage, etc.

Il arrive aussi que ces défauts ne soient pas intentionnels. Une librairie obsolète ou simplement des erreurs de codage ou de compréhension entre les équipes intervenant sur le projet peuvent aussi compromettre la qualité du code et son maintien sur la durée. 

La dette technique est en fait le résultat de ce qu'on n'a pas voulu faire correctement et ce qu'on a pas pu faire correctement.

Source : commitstrip.com

Pourquoi faut-il rembourser la dette technique ?

Je compare souvent la dette technique à un prêt bancaire.

Pour acheter une maison vous souscrivez un prêt bancaire pour lequel vous devrez régler des intérêts à la banque. Si vous ne respectez pas les mensualités prévues au contrat de prêt et que vous ne remboursez pas les échéances du prêt, la période de remboursement est rallongée, les intérêts augmentent, vous devez en plus régler des agios si vous êtes à découvert... Vous cumulez ainsi de la dette qu'il faudra un jour payer et il devient de plus en plus difficile de faire face à cette dette. Vous rentrez alors dans une sorte de cercle vicieux.

La dette technique, c'est pareil ! Moins vous respectez les bonnes pratiques, plus le code sera de mauvaise qualité et difficile à maintenir. Et plus la dette sera difficile à rembourser... 

Une dette technique qu'on tarde à rembourser aura une conséquence directe sur le coût de la maintenance et des évolutions du code. On pense faire des économies en codant plus rapidement aujourd'hui et on oublie qu'il va falloir débourser beaucoup d'argent, de temps et d'énergie demain pour redonner de la qualité au code et rembourser cette dette.

Comment réduire la dette technique ?

On peut maîtriser la dette technique en partie :

• En choisissant une solution qui répond aux besoins et aux spécifications du projet. On ne choisit pas une technologie parce qu'elle est "à la mode".
• En limitant le nombre de technologies utilisées : plus elles sont nombreuses, plus la maintenance est complexe. Privilégiez des technologies qui ont fait leurs preuves, maintenues et mises à jour régulièrement.
• En mettant en place des tests unitaires. Ils permettent de s'assurer que le comportement du code est bien celui attendu et qu'il n'y a pas de régression à chaque nouvelle livraison. 
• En établissant des règles de codage strictes. Partagez-les avec vos équipes. Ecrivez du code maintenable, lisible par vous et par les autres.
• En écrivant de la documentation technique.
• En faisant du code review au fur et à mesure de l'avancée du projet notamment afin de s'assurer que les règles  établies en amont ont bien été respectées.

Comment rembourse t-on la dette technique ?

Malgré tous vos efforts, vous ne pourrez pas éviter la dette technique.

Pour réparer les pots cassés, la première étape consiste à faire un état des lieux des problèmes et bugs.

Une fois qu'on les a tous recensés, on ne se lance pas dans une grosse chasse à la dette technique. Demander à une équipe de développeurs de passer des heures, des journées, voire des semaines entières à corriger des bugs est le meilleur moyen pour les décourager (ce n'est pas le plus passionnant dans un projet web...)

Il faut procéder par itérations (ou sprints), commencer par des petits bouts de code et essayer de les améliorer, même juste un peu.

Une règle d'or : on n'attend pas la fin du projet pour s'y mettre ! En fin de planning, on a toujours quelque chose de plus urgent à faire... 

Comment rendre visible et prioriser la dette technique ?

C'est souvent le chef de projet ou le product owner qui remonte les bugs et les régressions. Plus le produit est instable, plus la dette technique est importante. 

Il arrive aussi qu'on entende les développeurs dire "je ne touche pas à cette partie du code, sinon ça va casser", 'il n'y a que lui qui connait ce morceau de code, nous on n'y touche pas". Ces comportements et expressions doivent vous mettre la puce à l'oreille.

Sur les projets web, la maintenance et la modernisation du code existant sont rarement une priorité. On met plutôt l'accent sur le développement de nouvelles fonctionnalités et on laisse pour plus tard ces "corrections".

C'est justement au moment de l'ajout (ou de la mise à jour) de ces fonctionnalités qu'on se retrouve confronté à la dette technique. S'il vous faut plus de temps pour corriger les effets de bord de cet ajout que ce qu'il vous a fallu pour développer la fonctionnalité au départ, c'est mauvais signe !

Alors par où commencer ?

On commence en général par les chemins de code qui sont les plus souvent modifiés ou ceux qui compromettent réellement la "vie du projet".

Si la dette technique sur un bout de code ou une fonctionnalité ne gêne pas les activités de développement courantes, laissez-la de côté. Vous pourrez vous en occuper plus tard.