Qu’est-ce que la dette technique et comment la gérer ?

Temps de lecture : 11 min

De plus en plus d’entreprises souhaitent une mise sur le marché rapide de leurs projets numériques. Mais cette volonté à court terme a souvent pour conséquence de générer de la dette technique. Cette dette technique n’est pas toujours une mauvaise chose, surtout si elle est prévue et volontaire. Dans cet article, nous espérons donc vous aider à y voir plus clair sur ce qu’est la dette technique, ses causes et comment la gérer au mieux.

Qu’est-ce que la dette technique ?

La « dette technique » est un concept inventé en 1992 par Ward Cunningham, un informaticien américain (aussi connu pour avoir inventé le concept de Wiki). Le concept de la dette technique est en fait une métaphore directement inspirée de la dette financière.

Par exemple, pour acheter une nouvelle voiture, vous faites un prêt à votre banque. Pour ce prêt, vous devez payer chaque mois des intérêts à la banque. Toutefois, si vous ne remboursez pas le prêt selon les échéances prévues, votre période de remboursement est rallongée et vous devez payer des frais supplémentaires. Ainsi, vous cumulez la dette de votre prêt mais aussi la dette de vos frais supplémentaires. Il vous est donc de plus en plus compliqué de rembourser vos dettes.

Dans le cas de la dette technique, c’est le même principe sauf que ce sont des bugs ou du code de mauvaise qualité qui s’accumulent. Sans correctifs réguliers, les coûts (temporels et financiers) de maintenance et d’évolutions augmentent, il devient de plus en plus compliqué de corriger les malfaçons et ainsi de rembourser votre dette technique.

Quand apparait la dette technique ?

On pense souvent que la dette technique arrive avec le temps, au fur et à mesure du développement d’un projet. Seulement, la dette technique est souvent présente dès le premier jour du projet.

Par exemple, pendant la phase de planification de votre nouveau projet, vous pouvez réaliser qu’il ne sera pas possible de répondre à une exigence particulière dans le délai imparti. Bien entendu, vous pouvez décaler cette exigence à plus tard. Aujourd’hui, vous avez la certitude que dans le futur vous aurez le temps de vous en occuper. Seulement, entre temps, vous aurez de nouveaux projets, d’autres échéances, et votre exigence de départ sera mise de côté.

Voici votre première dette technique car le jour où vous remettrez cette exigence au premier plan, votre outil ne sera plus adapté. Vous devrez alors allouer du temps et du budget supplémentaire pour intégrer des fonctionnalités qui auraient dû être implémentées dès le début.

Chaque décision, chaque intervention, chaque nouvelle ligne de code peut être source de dette technique à n’importe quel moment d’un projet.

Quelles sont les causes de la dette technique ?

Selon nous, il existe 2 grandes catégories de dettes techniques :

1.      La dette technique volontaire

La dette technique volontaire est de plus en plus fréquente car elle résulte souvent d’une volonté de lancer rapidement un projet sur le marché avec des contraintes de temps ou de coûts :

Limites temporelles

La création de tout projet numérique nécessite du temps pour arriver à un résultat de qualité. Seulement, dans un souci concurrentiel, de nombreuses entreprises considèrent qu’il est acceptable de renoncer à la qualité du code si cela leur permet d’avoir un avantage temporel sur leurs concurrents. Ainsi, les délais de développement sont raccourcis au minimum et des compromis sont faits sur les bonnes pratiques de code afin de livrer un produit fonctionnel dans les meilleurs délais. Pour être viable dans le temps, le code doit alors être amélioré dès que possible.

Limites financières

D’autres sociétés ont des contraintes budgétaires qui imposent aux développeurs d’aller à l’essentiel. La quantité de fonctionnalités prime alors sur la qualité du code. Le produit livré est fonctionnel mais doit faire l’objet de corrections et d’améliorations ultérieures pour être viable dans le temps. Les fonctionnalités secondaires sont ajoutées plus tard quand un nouveau budget est alloué au projet. Cependant, ces ajouts nécessitent souvent de revoir les anciennes briques de code pour pouvoir fonctionner convenablement.

2.      La dette technique involontaire

La dette technique involontaire est accidentelle. Elle résulte généralement d’erreurs de développement, de mauvais choix techniques ou de problèmes d’obsolescence :

Logiciel et matériel obsolètes

De nombreux logiciels d’entreprise ont été développés il y a plusieurs années. Conçus avec les technologies de l’époque, certains continuent de très bien fonctionner. Seulement, d’autres deviennent difficiles à utiliser, voire totalement hors d’usage suite à des dettes techniques conséquentes.

Ces dettes techniques peuvent être liées à une obsolescence du hardware. Dans ce cas, le matériel utilisé peut-être trop ancien pour faire tourner convenablement votre logiciel ou alors vous ne disposez plus des machines ou infrastructures compatibles pour le faire fonctionner.

Ces dettes techniques peuvent également résulter d’une obsolescence du software. Dans ce cas, les versions des langages de programmation et des systèmes d’exploitation ont évolués et le logiciel devient incompatible avec les nouvelles versions. Les problèmes les plus courants sont alors des soucis d’affichages, des fonctionnalités inutilisables ou encore des coupures d’interconnexion à d’autres logiciels.

Pour limiter la dette et les problèmes d’obsolescence et de compatibilité, il est recommandé de régulièrement mettre à jour vos logiciels et d’utiliser au maximum des technologies récentes et plébiscitées par la majorité des développeurs.

Technologies inadaptées

Un grand nombre de solutions techniques peuvent être envisagées avant de commencer un projet. Il convient alors de bien étudier les solutions pour s’assurer que celles retenues seront les meilleures. Il peut, en effet, être tentant de choisir celles que vos équipes métrisent déjà. Mais attention, car elles ne répondront peut-être pas exactement à vos besoins et pourront être source de lacunes techniques difficiles à compenser.

De même, certains projets, basés sur d’anciens langages, peuvent nécessiter l’utilisation de technologies moins courantes et plus difficiles à mettre en œuvre. Votre dette technique risque alors d’être très importante si ces technologies ne sont pas bien maitrisées par votre équipe.

Equipe non qualifiée

Pour assurer la réussite d’un projet, il est nécessaire d’avoir une équipe compétente mais aussi très bien organisée. Un simple déséquilibre peut créer des difficultés laborieuses à gérer. Il peut par exemple y avoir un manque de communication entre les intervenants lié à une méthode de gestion de projet chaotique. Il est aussi possible qu’un membre de l’équipe ne possède pas les compétences techniques nécessaires et nuise sans le vouloir à l’équilibre du projet.

Par exemple, les développeurs juniors peuvent manquer d’expérience et peuvent être tentés d’ignorer la dette jusqu’à ce qu’elle s’accumule. Ou bien, ils peuvent avoir du mal à identifier leurs erreurs et à les corriger.

Le pire des scénarii pourrait être qu’une partie entière de l’équipe (pourquoi pas un service entier de votre entreprise ou un prestataire externe) soit missionné pour faire partie du projet mais n’ait pas les compétences souhaitées. Dans ce cas, l’équipe peut penser bien faire mais accumuler une dette technique énorme avant que les conséquences soient visibles.

Changements importants

Comme Némésis studio, de plus en plus de sociétés utilisent les méthodes Agiles pour gérer leurs projets. Cela permet de faire évoluer l’outil développé au fur et à mesure du projet afin de répondre au mieux à vos besoins. Seulement, un logiciel est souvent développé avec une vision finale globale afin d’anticiper les besoins techniques dès le début du projet.

De petites évolutions fonctionnelles peuvent alors être facilement prise en charge mais cela se complique quand les changements demandés sont aux antipodes des fonctionnalités initiales. En effet, l’outil global n’ayant pas été prévu à la base pour répondre à ces nouvelles problématiques, de nombreuses adaptations sont nécessaires. Dans ce cas, des bugs et malfaçons peuvent résulter de ces adaptations.

Il en va de même pour les petits changements constants. Ils ont beau avoir peu d’impact sur le projet global, plus ces changements sont nombreux, plus le risque de bugs est grand. Cela peut alors entrainer une dette technique importante.

Quelles sont les différents types de dette technique ?

La dette technique n’est pas la même d’un projet à un autre. Pour certains, seule une catégorie de problèmes seront référencés alors que pour d’autres, la dette technique s’étendra à plusieurs catégories de problèmes :

Problème de fiabilité

Les problèmes de fiabilité d’une application résultent d’anomalies évidentes du code qui créent des bugs.

Problème de sécurité

Les problèmes de sécurités d’une application sont directement liés à des faiblesses du code qui peuvent nuire au système.

Problème de maintenabilité

Les problèmes de maintenabilité sont dus aux « code smell » qui sont des mauvaises pratiques de code qui complexifient la maintenance.

Problème de couverture de code par les tests

Les problèmes de couverture de code par les tests résultent généralement de mauvaises utilisations des systèmes de tests automatisés.

Problème de duplication de code

Les problèmes de duplication de code sont souvent liés à des copier-coller de code (antipattern) qui entraînent des incohérences.

Problème de taille des fichiers, des fonctions, du nombre de classes par projets

Les problèmes de taille de code créent de gros blocs et une profusion d’informations qu’il est difficile de comprendre et de maintenir.

Problème de complexité

Les problèmes de complexité résultent d’un trop grand nombre de fonctions, d’appels de méthodes et d’affectations de variables qui rendent le code très complexe.

Comment trouver le bon équilibre entre vitesse et qualité ?

Premièrement, il faut savoir que la dette technique n’est pas toujours mauvaise. Elle fait partie de chaque projet de développement logiciel car les compromis entre vitesse, coût et qualité sont impossibles à éviter. La dette technique devient principalement un problème lorsqu’elle est ignorée ou accumulée involontairement à cause de mauvaises décisions.

Il est donc nécessaire de trouver un équilibre entre qualité et rapidité pour pouvoir répondre à vos attentes tout en gérant la dette technique. Vous pouvez pour cela continuer à utiliser des solutions de contournement rapides pour respecter vos délais, mais assurez-vous au préalable de connaître les conséquences engendrées par ces choix. La dette technique peut sembler inoffensive, mais si elle n’est pas contrôlée, vous devrez tôt ou tard en assumer les conséquences.

Quoi qu’il en soit, il existe des moyens de réduire et de gérer la dette technique.

Comment minimiser la création de dette technique ?

Divers moyens techniques et organisationnels permettent de minimiser la création de dette technique :

Garder votre équipe motivée

Ce premier point peut vous sembler tout bête mais il est primordial car c’est votre équipe qui a le pouvoir de minimiser la création de la dette technique.

Pour garder votre équipe motivée, rien de mieux que de reconnaitre son travail. La majorité des gens aiment fournir un travail de qualité et que ce dernier soit reconnu à sa juste valeur. En cas de manque de reconnaissance, votre équipe pourrait être démotivée et ne plus voir l’intérêt de faire du bon travail.

Utiliser des technologies adaptées

Le marché du numérique regorge de technologies et il peut être compliqué à première vue d’en sélectionner pour réaliser votre projet. Seulement, chacune à ses spécificités et vous ne devez pas vous arrêter sur la première venue sous prétexte qu’elle est en vogue ou que vos concurrents l’utilisent. Vous devez, avant tout, vous assurer qu’elle répond à vos besoins spécifiques, qu’elle a fait ses preuves et qu’elle fait encore l’objet de mises à jour régulières.

De même, limitez au maximum le nombre de technologies que vous allez utiliser. Plus vous en aurez et plus il sera compliqué de les maintenir.

Mettre en place de tests unitaires performants

En mettant en place des tests unitaires, vous vous assurez que le comportement du code est bien celui attendu et qu’il n’y a pas de régression à chaque nouvelle livraison.

Vous pouvez être réticents à les utiliser car écrire les tests unitaires accapare les développeurs qui ne peuvent pas développer les fonctionnalités que vous attendez pendant ce temps-là. Seulement, ils permettent de tester le code source pour voir s’il réagit bien comme prévu. En cas d’erreur, il est alors facile de déterminer la source du problème et d’effectuer les corrections nécessaires.

Ces tests sont d’autant plus utiles quand le développement est découpé en sprints et implique plusieurs développeurs. Ils permettent par exemple de tester régulièrement que les nouvelles fonctionnalités n’altèrent pas les anciennes.

Définir des méthodes strictes

Pour limiter la dette technique, vous devez au maximum définir des règles de codages et des bonnes pratiques que votre équipe sera tenue de respecter. Ces règles doivent permettre d’écrire du code de façon structurée pour que toute l’équipe soit en mesure de le comprendre et de le maintenir.

Ajouté à cela, il est important d’écrire régulièrement de la doc technique et de la maintenir à jour. Si cette tâche s’avère chronophage, privilégiez en priorité les fonctionnalités complexes et celles pour lesquelles la connaissance n’est détenue que par une seule personne.

Pour finir, effectuez régulièrement des revues de code pour vous assurer que les règles et bonnes pratiques sont bien respectées.

Comment payer la dette existante de manière efficace ?

Vous l’aurez certainement compris, il est très difficile de développer un projet digital sans dette technique. Heureusement, de nombreuses solutions permettent de réduire, voire de rembourser totalement votre dette technique.

Faire un état des lieux de la dette technique

De nombreux outils permettent de recenser les problèmes présents dans votre code et d’estimer votre dette technique.

« Chez Némésis studio, nous utilisons SonarLint en local sur nos postes. Cet outil permet d’analyser notre code au fur et à mesure du développement. Les éventuels problèmes sont recensés et corrigés avant d’être commit. Une fois commit sur l’environnement de démonstration, le code est analysé par Sonarqube qui va détecter s’il y a du code dupliqué, des bonnes pratiques non respectées, de potentielles vulnérabilités, etc. »

Arsène – Développeur Némésis studio

Cet outil est très visuel et donne une estimation plus ou moins précise de la dette technique en jours d’intervention nécessaires.

Planifier les corrections pour réduire la dette

Une fois que les problèmes sont recensés, il n’est pas recommandé de vous lancer dans une grosse phase de correction. Il s’agit du meilleur moyen pour décourager votre équipe.

Privilégiez plutôt de petites phases de corrections intégrées à vos sprints d’évolutions et n’attendez surtout pas la fin du projet pour vous y mettre ! Vous trouverez forcément quelque chose de plus intéressant à faire que corriger des bugs quand le projet sera presque terminé.

Profitez de l’ajout de fonctionnalités pour corriger, même un peu, les fichiers impactés. Une petite correction peut avoir un grand impact quand on parle de dette technique !

Conclusion

Tout développement web induit le risque de dette technique. Dans notre métier, nous faisons souvent face à la difficulté de faire prendre conscience à nos interlocuteurs que la dette technique est présente et qu’il faudra un jour la rembourser. Nous faisons tout pour ralentir sa progression mais il n’est pas toujours simple de prendre le temps de bien faire les choses. Nous espérons ainsi que cet article vous en aura appris d’avantage sur la dette technique et les problématiques qu’elle soulève. Comme d’habitude, nous restons à votre écoute pour toute question ou projet digital. Alors n’hésitez pas à contacter vos experts Némésis studio !