Qu’est-ce que la dette technique (et en avez-vous trop ?)
Au début de ma carrière, en tant que jeune chef de produit associé, lorsque j'ai entendu parler pour la première fois de la dette technique (également appelée tech debt), je ne comprenais pas vraiment ce que cela signifiait. De façon assez drôle, je croyais que cela faisait référence à un prêt contracté pour acheter un logiciel tiers, et j'ai utilisé ce terme avec assurance durant deux ou trois semaines. Imaginez ma gêne quand mes ingénieurs m'ont prise à part après un stand-up pour me corriger gentiment !
Pour nous éviter à tous de rougir au travail, et pour renforcer notre crédibilité auprès des ingénieurs, plongeons dans ce qu'est la dette technique et pourquoi, en tant que chefs de produit, nous devrions nous en préoccuper.
Qu’est-ce que la dette technique et quand devient-elle un problème ?
Le développement logiciel consiste à équilibrer l’étendue des fonctionnalités du produit et la qualité du code. Il arrive parfois que nous prenions des raccourcis pour accélérer le processus de développement ; ces raccourcis sont appelés dette technique ou tech debt.
Vous voulez plus de The CPO Club ?
Inscrivez-vous gratuitement pour terminer la lecture de cet article :
Have an account? Log In
Quand est-il judicieux de contracter de la dette technique, et quand cela devient-il une bombe à retardement ? Pour répondre à cette question, examinons d'abord l'histoire de la dette technique.
Qu’est-ce que la dette technique ?
Ward Cunningham, la personne à l’origine de ce terme, compare la dette technique à une dette financière : il est acceptable d’emprunter sur la vélocité future et la stabilité, mais il faut finir par rembourser cette dette. C’est un concept que toute équipe de développement devrait comprendre, et que chaque chef de produit devrait prendre en compte au moment de prendre des décisions produit.
La dette technique nous aide à sortir les produits plus tôt que prévu et à les mettre plus rapidement entre les mains des clients. Mais, nous devons, tôt ou tard, "rembourser la dette" en investissant dans la qualité de notre base de code.
Idéalement, nous devrions décider activement si nous voulons recourir à la dette technique ou si nous souhaitons l’éviter. Tout comme pour une dette financière, il ne faut pas être pris au dépourvu par un coût imprévu !
Une définition simplifiée de la dette technique
La dette technique (appelée parfois dette de code dans certaines équipes) fait référence au coût implicite de futurs travaux de reprise nécessaires lorsqu'on choisit un raccourci temporaire au lieu d’une meilleure approche, plus longue à mettre en œuvre. C’est comme payer des intérêts sur un prêt : le coût de la dette technique augmente avec le temps.
J’utilise souvent l’analogie du rasage de barbe. Si je suis pressé et que je me rase rapidement, ce ne sera probablement pas le rasage le plus propre, et je devrai revenir plus tard pour rattraper les imperfections.
Le temps et l’effort consacrés aux deux rasages : le rasage initial puis la retouche, seront au final supérieurs à ceux d’un rasage soigné dès le départ.
Mais parfois, quand nous sommes vraiment à court de temps, il faut accepter le rasage express !
Comparer la dette financière à la dette technique
Pour mieux illustrer ce concept, analysons un peu plus en profondeur la comparaison entre la dette financière et la dette technique. Après tout, les chefs de produit doivent comprendre à la fois les notions financières et les concepts liés au code technique !
Avantages de la dette financière : La dette financière permet de bénéficier de l’effet de levier. Emprunter de l’argent offre le capital nécessaire pour investir dans des opportunités de croissance. De plus, la dette financière permet un accès immédiat à des ressources ou à des biens sans paiement initial.
Inconvénients de la dette financière : La dette financière s’accompagne de nombreux types de coûts. Les intérêts liés à la dette peuvent s’accumuler et réduire la rentabilité globale. Par ailleurs, une mauvaise gestion de la dette financière peut entraîner une instabilité financière.
En outre, une dette importante peut restreindre la flexibilité et empêcher d’explorer certaines options à l’avenir. Enfin, faire défaut sur ses obligations financières peut nuire à la réputation d’une organisation.
Avantages de la dette technique : La dette technique permet un développement produit initial plus rapide, ce qui aide à respecter des délais serrés ou à saisir des opportunités de marché. Et, tout comme l’effet de levier financier, la prise de dette technique peut réduire les coûts initiaux de développement.
Inconvénients de la dette technique : A l’instar des intérêts qui s’accumulent sur la dette financière, la dette technique se multiplie au fur et à mesure que de nouvelles fonctionnalités ou changements s’appuient sur des raccourcis existants, rendant le développement futur plus complexe et coûteux. De plus, la dette technique entraîne souvent une qualité de code sous-optimale, ce qui génère des coûts de maintenance accrus sur le long terme.
La dette technique peut freiner la capacité d’un produit à s’adapter à l’évolution du marché ou à intégrer de nouvelles fonctionnalités. Et, une dette technique non traitée peut provoquer des défaillances système, des vulnérabilités de sécurité ou des problèmes de performance, ce qui peut menacer la viabilité du produit.
Qu’est-ce que cela signifie pour nous ? Eh bien, tant pour la dette financière que pour la dette technique, le but n’est pas d’éviter toute dette. Une gestion prudente est la clé.
Bien qu’un certain niveau de dette soit stratégique pour la croissance, nous devons garder un œil attentif et bien gérer la dette afin d’en limiter les conséquences négatives sur le long terme.
Exemples de dette technique
Dans le domaine de l’ingénierie logicielle, les équipes de développement sont régulièrement confrontées à la dette technique. Voici quelques-uns des exemples les plus courants.
Code hérité
Certaines équipes peuvent utiliser du code hérité obsolète pour sortir rapidement une fonctionnalité. Cela peut offrir une fonctionnalité immédiate mais pourrait nécessiter une refonte substantielle plus tard, surtout à mesure que de nouvelles fonctionnalités sont ajoutées. À l’image d’un manuscrit ancien, le code hérité a été transmis à travers des générations de développeurs, accumulant le poids de l’histoire.
Bien qu'il ait pu remplir admirablement son rôle à son apogée, le temps finit par éroder son adaptabilité et sa maintenabilité. Les pannes et bogues en production ont tendance à apparaître lorsque nous comptons trop sur le code hérité !
Codage en dur
Le codage en dur fait référence à la pratique consistant à intégrer des valeurs ou constantes spécifiques directement dans le code au lieu d’utiliser des paramètres configurables.
Bien que cette approche puisse offrir un développement accéléré à court terme, elle mène souvent à des complications par la suite. Imaginez un scénario où une valeur codée en dur, comme un chemin de fichier ou un seuil de délai d'attente, doit être modifiée dans une base de code volumineuse. Cela peut rapidement devenir une tâche longue et sujette aux erreurs, compromettant la maintenabilité et la flexibilité du logiciel.
Pour éviter cet écueil, les développeurs devraient privilégier les options configurables, ce qui améliore l’adaptabilité de leur code.
Duplication de code
La duplication de code survient lorsque des extraits de code similaires ou identiques apparaissent à plusieurs endroits dans le projet. Au début, cela peut sembler être un raccourci pratique, permettant de gagner du temps lors du développement. Cependant, à mesure que le logiciel évolue et que les besoins changent, maintenir la cohérence et effectuer des mises à jour devient une danse complexe.
La duplication de code augmente non seulement le risque d’introduire des bogues mais multiplie aussi les efforts nécessaires pour de futures améliorations et corrections. La recherche de la réutilisabilité du code et l’élimination du code redondant sont des principes fondamentaux pour contrer ce problème.
Manque de documentation
La documentation sert de fil conducteur qui éclaire le chemin pour les développeurs actuels et futurs. L’absence d’une documentation complète revient à entreprendre un voyage complexe sans carte. Cela peut commencer par un manque de commentaires en ligne expliquant le raisonnement de certains choix de code ou aller jusqu’à l’absence de guides utilisateurs et de documentation de l’architecture système.
Si la phase de développement initiale peut bien se dérouler, les conséquences à long terme peuvent être sévères. Le débogage devient une aventure cryptique, le transfert de connaissances entre membres de l’équipe devient difficile, et l’évolution du projet ressemble souvent à la navigation dans un labyrinthe obscur. Adopter une documentation exhaustive est le phare qui éclaire l’avenir du développement logiciel.
Manque de tests automatisés
L’absence de tests automatisés équivaut à naviguer un bateau sans vérifier d’abord s’il prend l’eau. Les tests automatisés (y compris unitaires, d’intégration et de non-régression) sont les gardiens vigilants de la qualité et de la stabilité du code.
Lorsqu’ils sont omis, les conséquences peuvent ne pas être immédiatement visibles. Au début, le développement semble avancer rapidement et le logiciel paraît fonctionnel. Cependant, à mesure que la base de code s’agrandit et évolue, des problèmes imprévus commencent à apparaître. Les bugs de régression, où des fonctionnalités qui fonctionnaient auparavant sont cassées par de nouveaux changements, deviennent monnaie courante.
Sans tests automatisés pour servir de filet de sécurité, l’équipe de développement doit s’appuyer sur des tests manuels, un processus long et sujet aux erreurs. Adopter les tests automatisés dès le départ permet d’assurer une trajectoire stable dans la mer agitée du développement logiciel.
Quel est le rôle de la dette technique en Agile ?
Ah, le développement Agile ! Ses méthodologies scrum et les principes du manifeste Agile favorisent le changement et la rapidité. Mais où se situe la dette technique ? Après tout, la dette technique n’est pas spécifiquement abordée dans les documents fondateurs de l’Agilité.
Eh bien, voici une analogie tirée de Star Wars — le Faucon Millenium subissait un entretien continu par Han Solo et Chewbacca pour rester en parfait état pour leurs aventures. De même, une équipe produit Agile gère la dette technique pour maintenir la qualité logicielle et permettre de véritables exploits à leurs clients !
Comment utiliser et gérer la dette technique
Dans les équipes Agile, on comprend parfois qu’il faudra contracter un peu de dette technique pour répondre rapidement aux besoins business. Souvenez-vous, encourir cette dette n’est pas toujours une mauvaise chose. Martin Fowler, figure de proue du développement logiciel Agile, précise qu’il s’agit de compromis. On peut accepter un peu de dette au début du cycle de vie d’un produit logiciel pour valider un concept ou arriver plus vite sur le marché.
La clé c’est de gérer la dette technique. Celle-ci doit être documentée dans le backlog, priorisée et traitée dans les prochains sprints. Pour que cela se fasse, les chefs de produit doivent s’appuyer sur une gestion de projet solide et avoir une bonne compréhension du volume de dette contracté à ce jour.
Quand la dette technique devient-elle un problème ?
Lorsque les parties prenantes ignorent la dette technique ou que le processus de développement repose fortement sur des solutions de contournement, il est temps de tirer la sonnette d’alarme. Pourquoi ?
- Elle est invisible : Sans indicateurs ni revues de code régulières, des vulnérabilités cachées peuvent apparaître.
- Elle impacte l’expérience utilisateur : Si des problèmes sous-jacents commencent à affecter la fonctionnalité, ce n’est plus seulement un problème de développeur ; c’est un problème d’entreprise.
- Elle freine l’ajout de nouvelles fonctionnalités : Les programmeurs englués dans du mauvais code sont moins productifs et ont moins de créativité.
- Elle n’est pas sur la feuille de route : Les équipes doivent être conscientes de la dette technique et avoir une stratégie en place. N’hésitez pas à vous appuyer sur des webinaires externes et des ressources pour établir un plan d’action.
Comment mesurer la dette technique
À l’aide d’outils comme les pratiques DevOps et l’automatisation, les équipes peuvent surveiller leur base de code et garder le contrôle sur la dette technique accumulée jusqu’à présent. Ci-dessous, j’ai rassemblé douze façons différentes de suivre la dette technique.
Vous n’êtes pas obligé de tout utiliser ! Considérez plutôt cette liste comme un point de départ. Choisissez-en une ou deux à mettre en place dans le mois à venir, puis augmentez progressivement le niveau de maturité de votre équipe pour suivre et résoudre la dette technique.
1) Analyse statique du code : Des outils comme SonarQube, ESLint ou FindBugs peuvent analyser automatiquement le code pour détecter divers problèmes, tels que la complexité, les mauvaises pratiques et les bugs potentiels. Ils fournissent des métriques quantitatives sur la qualité du code et la dette technique basées sur des règles et seuils prédéfinis.
2) Couverture du code : On peut évaluer la proportion du code couverte par des tests automatisés en mesurant la couverture grâce à des outils tels que JaCoCo ou Istanbul. Une couverture faible peut signaler un manque de tests et une dette technique potentielle.
3) Revues de code entre pairs : Réaliser des revues de code entre développeurs permet d’identifier et de discuter des éléments de dette technique potentielle. Deux cerveaux valent mieux qu’un : c’est une excellente manière d’éviter les mauvaises habitudes de code ! Les équipes peuvent utiliser des check-lists ou des référentiels pour évaluer la qualité et documenter les problèmes détectés. Le nombre et la gravité des points relevés lors des revues constituent une mesure qualitative de la dette technique.
4) Inspections manuelles du code : Les développeurs et équipes peuvent réaliser des inspections manuelles ou des walkthroughs pour identifier les zones du code qui pourraient nécessiter un refactoring. Ce processus implique souvent des développeurs expérimentés qui examinent le code et documentent les problèmes, car ils ont généralement une bonne perception de la conception technique.
5) Backlog de dette technique : Maintenir un backlog produit ou une liste des éléments de dette technique identifiés est une pratique courante. Chaque élément doit comporter une description, une évaluation de son impact et une priorité. Le volume et la priorité des éléments offrent une mesure qualitative de la dette technique.
6) Suivi des bugs et incidents : L’analyse du processus de tri des bugs peut révéler la fréquence et la gravité des problèmes liés à la dette technique. Un nombre élevé de rapports de bugs ou la récurrence des mêmes problèmes indiquent souvent une dette sous-jacente.
7) Estimation et points d’histoire : Lors de la planification de nouveaux travaux ou récits utilisateurs, les équipes de développement peuvent estimer l’effort requis pour adresser la dette technique. Cette estimation d’effort, souvent sous forme de points d’histoire en Agile, quantifie le travail nécessaire pour résorber la dette technique.
8) Métriques de complexité du code : Les métriques comme la complexité cyclomatique, le nombre de lignes de code ou le taux de modification apportent un éclairage sur la complexité et la maintenabilité. Une forte complexité ou des modifications excessives d’un même secteur sont souvent signes de dette technique.
9) Retour utilisateur : Les retours des utilisateurs et les demandes au support peuvent indirectement mettre en évidence la dette technique. La fréquence des plaintes concernant la performance, la fiabilité ou les comportements inattendus peut révéler des soucis sous-jacents à résoudre.
10) Métriques liées aux tests automatisés : Surveiller les métriques liées aux tests automatisés comme le temps d’exécution, le taux d’échec ou la non-fiabilité des tests permet d’évaluer l’état de l’infrastructure de tests et de détecter les impacts de la dette technique.
11) Sondages et entretiens : Les sondages et entretiens menés auprès des équipes de développement apportent des éclairages qualitatifs sur la perception de la dette technique et son impact sur la productivité et la qualité du code. Recueillir le ressenti des parties prenantes aide aussi à identifier les zones où du rework pourrait s’avérer nécessaire.
12) Quadrant de la dette technique : Un outil particulièrement utile est le quadrant de la dette technique introduit par Martin Fowler. Il catégorise les causes de la dette technique en anticipée ou non et imprudente/prudente, ce qui aide les équipes à mieux comprendre les arbitrages.
Au-delà de ces douze façons de mesurer la dette technique, n’hésitez pas à utiliser des outils de gestion de produit pour aider à suivre et à résoudre la dette technique de votre équipe !
Rembourser la dette technique
Nous avons beaucoup parlé de contracter de la dette technique, mais nous n’avons pas encore abordé comment la rembourser. En tant que chefs de produit, c’est notre responsabilité de guider nos équipes pour décider quand il faut rembourser la dette et quand il est acceptable d’en contracter davantage.
Nous remboursons la dette technique lorsque les ingénieurs mettent à jour la base de code pour traiter des éléments de dette technique identifiés précédemment. Cela peut inclure la refonte de fonctionnalités pour les rendre plus efficaces, l’implémentation de tests automatisés ou la rédaction d’une documentation approfondie sur le code.
L’une des meilleures façons de s’en acquitter est de réserver du temps à chaque sprint pour renforcer la base de code et réduire la dette. Pensez-y comme à un remboursement mensuel de crédit immobilier : plus vite nous remboursons l’emprunt, moins nous avons d’intérêts à payer au total !
Une bonne règle empirique est la règle des 80/20. Autrement dit, consacrez environ 80 % du temps de chaque sprint à la création de nouvelles fonctionnalités, et 20 % à la priorisation des investissements et améliorations techniques.
Lorsque vous planifiez le remboursement de la dette technique, songez à l’intégrer à votre feuille de route produit en conséquence.
Dernières réflexions sur la dette technique
Pour conclure, la gestion de la dette technique n’est pas seulement le travail des développeurs. Les chefs de produit, les équipes Agile, et les parties prenantes métiers ont tous un rôle à jouer.
L’objectif final ? Offrir un produit logiciel de haute qualité, qui réponde aux objectifs métier sans générer une dette insoutenable.
Alors, que vous plongiez dans l’océan du développement logiciel ou que vous essayiez simplement de comprendre pourquoi votre équipe de développement parle sans cesse de refactoring, comprendre et gérer la dette technique est la boussole qu’il vous faut.
Et que vous soyez en début de carrière produit ou déjà un expert aguerri de la gestion de produit, vous tirerez presque toujours profit d’un approfondissement de votre compréhension du jargon technique.
J’espère que vous éviterez de commettre la même erreur que j’ai faite au début de ma carrière : ne vous contentez pas d’indices contextuels pour deviner les concepts techniques inconnus !
À la place, prenez le temps de faire des recherches, de consulter des guides externes comme celui-ci, et de passer du temps avec vos ingénieurs pour acquérir des connaissances précieuses.
Pour encore plus d’idées et de guides sur le product management, n’oubliez pas de vous abonner à notre newsletter !
