Dette technique : définition et solutions, exemples inclus

Le développement de produits nécessite souvent de prendre des décisions rapides concernant les fonctionnalités des logiciels. Si vous avez fait partie d’une équipe DevOps, vous savez mieux que quiconque le nombre incalculable de décisions à prendre pour mettre en production des fonctionnalités. 

La dette technique découle d’une série de décisions prises pour privilégier la rapidité avant tout. Ces décisions rapides, en temps réel, jouent un rôle majeur dans la mise à jour logicielle. Toutefois, il est essentiel d’assurer un équilibre entre les bonnes décisions et les décisions rapides. En fonction des choix de votre équipe, la dette technique peut avoir des résultats négatifs ou en valoir la peine. 

Dans cet article, nous nous pencherons sur la définition de la dette technique, la manière de gérer efficacement les décisions rapides au sein du processus de développement et nous donnerons des exemples pour vous permettre de mieux comprendre comment éviter de futurs incidents. 

En quoi consiste exactement la dette technique ?

On parle de « dette technique » quand la rapidité d’un projet prime sur la qualité et demande ainsi un travail de correction supplémentaire en aval. Il s’agit d’un concept inventé par le développeur de logiciels Ward Cunningham en 1992, qui a évolué depuis lors.

Aujourd’hui, on parle généralement de dette technique (également appelée dette de conception ou dette de code) lorsque les équipes de développement doivent écrire du code en un temps record tout en créant de nouvelles fonctionnalités dans le cadre d’un développement de produits. La livraison rapide du code peut aider votre équipe à respecter les délais, et la dette accumulée peut en valoir la peine, mais sa mauvaise gestion peut aussi entraîner des résultats négatifs difficilement évitables une fois la décision d’accumuler une dette technique entérinée. 

Peu importe la situation à laquelle vous devrez faire face, favorable ou non, nous allons passer en revue les fondamentaux de la dette technique afin que vous soyez prêt à prendre les bonnes décisions le moment venu. 

La dette technique est-elle à bannir ?

À l’instar de la dette financière, la dette technique a ses avantages et ses inconvénients.

Dans certains cas, la dette technique est le fruit d’une réflexion visant à la fois à respecter les délais et à livrer un code de haute qualité pendant les sprints. Dans d’autres cas, elle n’est autre que le résultat d’une erreur inévitable commise lors de la mise à jour d’un logiciel. 

Les quadrants de la dette technique

La dette technique peut relever de quatre causes distinctes, connues sous le nom de « quadrants de la dette technique ». Ces quadrants, inventés par Martin Fowler, sont divisés en plusieurs axes : prudent/imprudent et volontaire/involontaire. 

Cette méthode vous permet d’évaluer l’intention et le contexte des problèmes liés au code. Si certaines dettes peuvent être volontaires et classées dans la catégorie des bonnes dettes, d’autres éléments peuvent être involontaires et classés dans la catégorie des mauvaises dettes. 

1. Dette prudente et volontaire : résulte de la décision de livrer rapidement et de gérer les conséquences par la suite. Ce type de dette est le plus souvent utilisé lorsque les enjeux du produit sont relativement faibles et que les avantages d’une livraison rapide l’emportent sur les risques. 

2. Dette imprudente et volontaire : dette due à une équipe qui sait comment produire le meilleur code, mais qui privilégie la rapidité de livraison.

3. Dette prudente et involontaire : lorsque vous avez l’intention d’écrire un code de première qualité, mais que vous trouvez une meilleure solution après l’implémentation. 

4. Dette imprudente et involontaire : ce cas de figure survient lorsqu’une équipe essaie de produire un code de première qualité sans avoir les connaissances nécessaires pour le faire. L’équipe n’est souvent pas consciente des erreurs qu’elle commet. 

Les équipes optent pour la dette technique volontaire si elles veulent privilégier la rapidité, tandis que la dette involontaire est accidentelle ; elle survient après l’implémentation. Cette différence est parfaitement illustrée par l’ingénieur logiciel Steve McConnell lorsqu’il décrit les deux types généraux de dette technique. Penchons-nous sur ceux-ci pour mieux les comprendre.  

Les types de dettes techniques

Steve McConnell, ingénieur logiciel en chef chez Construx Software, a suggéré l’existence de deux types de dettes techniques : 

• Volontaire

• Involontaire

1. Dette technique volontaire

On parle de dette volontaire lorsqu’une organisation prend délibérément la décision d’optimiser le présent plutôt que l’avenir. 

Il existe des variantes à court et à long terme de la dette volontaire. Par exemple, une dette volontaire contractée pour rembourser une dette antérieure est une dette à court terme, tandis qu’une dette volontaire accumulée pour prévenir une dette future plus importante constitue une dette à long terme. 

Dette à court terme : elle est contractée de façon rétroactive, pour des raisons tactiques telles que l’utilisation des ressources existantes. En outre, la dette à court terme peut être ciblée ou non ciblée.

• Dette à court terme ciblée : inclut les raccourcis identifiables individuellement. 

• Dette à court terme non ciblée : inclut de nombreux petits raccourcis.

Dette à long terme : elle est contractée de façon prospective, pour des raisons stratégiques telles que le respect d’une échéance. 

Comme vous pouvez le constater, le type de dette accumulée déterminera le temps nécessaire pour la rembourser.

2. Dette technique involontaire

Par ailleurs, la dette technique involontaire provient d’un manque de compréhension, d’erreurs accidentelles ou, dans certains cas, d’un code mal écrit. Par exemple, une approche de conception qui s’avère être sujette aux erreurs constitue une dette technique involontaire. Il s’agit du résultat non stratégique d’une erreur inévitable.

On peut considérer la dette technique involontaire comme accidentelle, car il ne s’agit pas d’une action délibérée. Le plus souvent, vous ne vous rendrez compte de votre erreur qu’après avoir implémenté la mise à jour du logiciel ou terminé le projet. 

Comment venir à bout de la dette technique ?

Bien qu’il soit possible d’accumuler volontairement une certaine quantité de dette technique, de nombreuses équipes produit ont du mal à la suivre et à communiquer à son sujet, engendrant ainsi un travail supplémentaire à l’heure de corriger le code logiciel. 

Il existe deux grandes façons de gérer la dette technique et de garantir une plus grande transparence sur le lieu de travail au regard de cette dette.

1. Dressez une liste de dettes au sein d’un système de suivi : chaque fois que vous contractez une dette, inscrivez dans votre système de suivi les tâches nécessaires pour la rembourser, sans oublier l’estimation des efforts et du temps associés. Utilisez le backlog de dettes pour suivre l’évolution de ces dernières. Toute dette non résolue datant de plus de 90 jours doit être considérée comme critique.

2. Intégrez la liste de dettes à un backlog produit Scrum : traitez chaque dette comme une « story » Scrum et estimez les efforts et le temps requis pour rembourser chacune d’entre elles (de la même manière que vous estimez les autres stories dans Scrum au sein d’un backlog produit).

Grâce à ces deux méthodes, vous gérez au mieux les dettes techniques et les remboursez aussi rapidement et efficacement que possible. Comme pour le remboursement d’un crédit, les deux approches vous permettent de vous acquitter de petites tranches de dettes jusqu’à en atteindre le montant total. 

Exemples de dettes techniques et solutions

Maintenant que vous avez une meilleure compréhension de la dette technique et de certaines des causes de la dette volontaire et involontaire, passons en revue quelques exemples concrets. 

Exemple 1 : dette technique volontaire

• Description : l’équipe choisit un cadre facile à développer, avec des problèmes de performance connus et des capacités fonctionnelles minimales.

• Solution : l’équipe utilise des applications supplémentaires qui entreront en jeu après l’implémentation du logiciel et comportent les fonctionnalités manquantes.

• Dette : bien qu’elle ait respecté l’échéance du produit, l’équipe devra retravailler les fonctionnalités après le lancement et aura besoin de fonds supplémentaires.  

Exemple 2 : dette technique involontaire

• Description : l’équipe compte de nombreux développeurs juniors qui participent au lancement d’une nouvelle fonctionnalité logicielle dans un délai serré, mais il n’y a pas suffisamment de développeurs seniors pour réviser chaque élément du code. 

• Solution : l’équipe fait temporairement appel à des développeurs seniors supplémentaires dans le but d’examiner le code et de vérifier son bon fonctionnement. 

• Dette : bien que l’équipe ait résolu la plupart des problèmes, le manque de communication entre le personnel à temps plein et l’équipe supplémentaire temporaire a entraîné l’oubli de certains bugs dans le code. L’équipe devra donc corriger ces bugs après le lancement. 

Comme vous pouvez le constater, bien que différentes, les dettes volontaires et involontaires devront être remboursées au fil du temps. Essayez de réfléchir en amont à cette dette technique pour trouver des solutions et vous assurer que vos mises à jour logicielles sont lancées à temps, tout en limitant l’accumulation de dettes.

Remboursez votre dette technique en toute transparence

Éviter une dette n’est pas toujours possible lorsque vous travaillez au lancement d’un produit logiciel. Qu’il s’agisse de décisions difficiles ou d’erreurs dans le code, les équipes Agile sont conscientes des répercussions que peut avoir l’accumulation de dettes techniques sur les mises à jour logicielles. 

Le suivi des tranches de paiement est primordial lors du remboursement des dettes. Bien que le type de remboursement soit différent pour chaque scénario, la transparence et la communication au sein de l’équipe peuvent accélérer le processus de remboursement. En effet, des projets Agile plus clairs permettent de trouver une solution collective au problème posé.