De l’importance de garder votre dette technique sous contrôle
En Synthèse :
- La dette technique se définit comme le coût du travail supplémentaire que vous devrez effectuer demain si vous choisissez la solution de facilité aujourd’hui ;
- Tout comme la dette financière, la dette technique peut avoir des effets positifs pour une organisation ;
- Cependant, accumuler une dette technique excessive n’est pas recommandé car, comme toute dette, elle doit bien finir par être remboursée.
La dette technique – à savoir l’idée qu’il peut être judicieux de commencer petit et de se concentrer sur des MVP (produits minimum viables) avant de se lancer dans la réalisation de produits sophistiqués, ou de prendre des raccourcis afin d’aboutir plus rapidement à un système fonctionnel – n’est pas un concept nouveau, mais la crise liée au COVID-19 l’a remise sur le devant de la scène.
Les entreprises et institutions du monde entier ont été soudainement confrontées à la nécessité de numériser leurs modes de fonctionnement et leurs modèles du jour au lendemain. Elles ont dû privilégier le pragmatisme et la rapidité à la rigueur et l’exhaustivité afin d’assurer la continuité de leurs services à leurs clients ou leurs utilisateurs.
Mais qu’en est-il du « reste à faire » ? Quand une organisation doit-elle rembourser sa dette technique, et que se passe-t-il si elle ne le fait jamais ?
Comprendre la dette technique et ses causes
La dette technique (également appelée dette de conception ou dette de code) est un concept issu du monde du développement logiciel et désignant le travail de développement qui est remis à plus tard afin de respecter une échéance ou de prendre en compte des contraintes.
Comme de nombreux autres termes et notions relatifs au développement de logiciels, il s’applique également à d’autres secteurs et métiers.
En d’autres termes, il s’agit du travail que vous devrez fournir demain parce que vous avez choisi de prendre un raccourci aujourd’hui.
- Au nombre des causes courantes de la dette technique figurent :
- Le manque de ressources qualifiées
- Les impératifs et contraintes au niveau de l’entreprise (nécessité de commercialiser un produit ou un logiciel le plus rapidement possible)
- L’absence de définition préalable des besoins et du cahier des charges, entraînant des changements de spécifications de dernière minute.
- Le manque de vision ou de leadership technologique
- Des projets ou cycles de développement longs, et donc susceptibles d’obsolescence
- Un travail de développement effectué en silos ou en parallèle, nécessitant un travail de consolidation supplémentaire.
Il faut comprendre la dette technique comme un phénomène cumulatif. Des systèmes mal conçus ont tendance à nécessiter davantage de travail de maintenance. En outre, tout changement que vous devrez effectuer à l’avenir va nécessiter d’autres ajustements connexes afin de préserver la cohérence et la cohésion interne du système – on peut appeler cela « les intérêts techniques ».
Bonne dette ou mauvaise dette ?
Ward Cunningham, le développeur à l’origine de la métaphore de la dette technique (et qui a accessoirement coécrit le manifeste Agile), explique le parallèle dans une vidéo :
« Avec de l’argent emprunté, vous pouvez faire quelque chose plus rapidement que vous ne l’auriez pu autrement, mais, jusqu’à ce que vous remboursiez cet argent, vous paierez des intérêts (…) Je me suis dit qu’emprunter de l’argent a son intérêt, je me suis dit qu’accélérer la sortie d’un logiciel pour voir ce qu’il vaut a son intérêt, mais que, bien sûr, il faudrait bien finir par revenir dessus et par rembourser ce prêt en remaniant le programme pour refléter les connaissances et l’expérience acquises entre temps. »
Dans cette optique, il apparaît que, tout comme la dette financière, la dette technique n’est pas nécessairement un problème. Un montant raisonnable de dette technique peut en réalité être bénéfique pour l’entreprise. Construire des produits minimum viables ou des proofs-of-concept peut être considéré comme une bonne pratique, et il peut être intéressant d’accepter quelques défauts mineurs afin de sortir des logiciels ou des produits plus rapidement.
Emprunter du travail à venir présente donc son lot d’avantages, mais que se passera-t-il lorsqu’il s’agira de rembourser ?
Et si vous ne remboursiez pas votre dette technique ?
Qu’en est-il des organisations qui accumulent une dette technique importante et ont du mal à la rembourser ? Est-il possible d’annuler la dette et de ne jamais s’en acquitter ? Bien que ce soit en théorie une option, la procrastination peut en définitive s’avérer plus coûteuse encore.
Tout comme en architecture, retarder excessivement les travaux de réparation peut aboutir à des défauts structurels lourds, dans le pire des cas, à l’effondrement pur et simple.
Les systèmes mal conçus et mal entretenus imposent des contraintes supplémentaires aux équipes, réduisant leur productivité et générant du stress. Un code archaïque et mal écrit finit par devenir trop complexe à comprendre et à remanier, nuisant à l’usabilité du logiciel. Et les utilisateurs en souffrent.D’où l’importance de suivre et de garder trace de votre dette technique pour pouvoir la gérer correctement. Contrairement à la dette financière, qui peut être catégorisée, décomposée, analysée et représentée sur des feuilles de calcul, la dette technique est beaucoup plus difficile à suivre et à comprendre, à moins que les responsables technologiques ne s’emploient activement à la suivre et décident en amont quel niveau est acceptable.
Valerie Zeller
Valérie Zeller est Chief Marketing Officer de Sciforma. Ses intérêts : la transformation digitale, la gestion du changement, l'exécution des stratégies d’entreprise. Partagez et commentez sur twitter: @valeriezeller