Par Stephanie Nicholls-Dempsey, conseillère Analytique des données
Le concept de la dette technique a été introduit par Ward Cunningham en 1992. Il a défini l’introduction intentionnelle d’un code immature dans un système comme une dette technique. Dans l’immédiat, c’est une solution rapide qui convient au client pour accélérer le développement, mais si la situation n’est pas rectifiée dans un délai approprié, les risques associés à la dette technique augmentent. Pour chaque minute que le code immature n’est pas corrigé, le système accumule de l’intérêt (Cunningham, 1992). Avec le temps, la définition a été élargie pour comprendre plus que du code immature dans un système.
Le périmètre de la dette technique
À son introduction, la dette technique, selon Cunningham (1992), est accumulée de manière intentionnelle. Par exemple, une équipe de développement peut délibérément choisir de contracter une dette de code afin de pouvoir livrer en itération selon les principes de l’agilité (livraison en itération plutôt qu’à la complétion de l’ensemble du développement). Le périmètre autour du concept de dette technique a depuis été élargi pour inclure la dette technique créée de manière non intentionnelle (Ciolkowski et al., 2021).
Les conséquences de la dette technique
Comme Cunningham (1992) l’a présenté, il est correct d’accumuler de la dette technique à condition qu’elle soit remboursée rapidement. Malheureusement, ceci ne représente pas la réalité puisqu’en moyenne 30% des ressources de développement sont gaspillées à cause de la dette technique (Ciolkowski et al., 2021).
À première vue, la conséquence de ne pas rembourser une dette technique est l’accumulation d’intérêt. En réalité, cet intérêt peut être associé à plusieurs conséquences : coûts élevés d’entretien des logiciels legacy, impact négatif sur la performance, coûts de remplacement important d’un logiciel une fois qu’il n’est plus possible de rembourser la dette technique. Dans certains cas, les conséquences peuvent être irréparables; il est donc nécessaire de traiter la dette technique comme une partie intégrante d’un projet TI (Wiese et al, 2023).
Le remboursement de la dette technique
Deux éléments ressortent dans les solutions proposées dans la littérature sur le remboursement de la dette technique : la sensibilisation et l’inclusion du remboursement au sein de la gestion du projet.
- Ciolkowski et al. (2021) ont trouvé que la sensibilisation de la dette technique dans les organisations est cruciale pour développer des outils et des processus pour identifier la dette.
- Wiese et al. (2021) partagent l’importance d’inclure le remboursement de la dette technique dans la gestion de projet à travers ce qu’ils appellent des billets de dette technique. La création de ces billets présente de manière explicite la dette technique à toute l’équipe, ce qui est une forme efficace de sensibilisation pour tenter de la prévenir. À l’aide de ce processus, la dette technique du projet est identifiée lors de son déroulement, ce qui augmente les chances que l’équipe de projet rembourse la dette technique dans un délai opportun puisqu’elle pourra planifier du temps pour le faire.
Ce premier article de blogue servait à introduire la dette technique. Il sera suivi d’autres articles qui plongera plus en profondeur dans ce sujet.
Références
· Cunningham, 1992
· Ampatzoglou et al., 2015
· Ciolkowski et al., 2021
· Wiese et al., 2021
· Wiese et al, 2023