Les DSI sont confrontés à la dette technique depuis des décennies, mais nombre d'entre eux ont encore du mal à la gérer de manière adéquate. Et cela leur coûte cher. Selon le cabinet de conseil en management Protiviti, la dette technique absorbe 31 % des budgets IT et sa gestion mobilise 21 % des ressources informatiques.

Par ailleurs, les responsables informatiques qui parviennent à maîtriser leur dette technique sont bien mieux placés pour permettre à leur organisation d'être plus performante. Selon le cabinet d'études Gartner, les responsables des infrastructures et des opérations qui gèrent et réduisent activement la dette technique peuvent accélérer d'au moins 50 % les délais de fourniture de services à l'entreprise.

Compte tenu de ces résultats qu'ils ne peuvent ignorer, de nombreux DSI se sont attachés à trouver des moyens de réduire leur dette technique. Voici cinq approches mises en oeuvre par des responsables technologiques expérimentés.

1. Mesurer votre dette technique

Andrew Sharp, directeur de recherche pour l'infrastructure et les opérations chez Info-Tech Research Group, est un fervent partisan du catalogage de la dette technique. L'analyste conseille aux responsables IT d'établir une liste de leur dette technique critique, de connaître l'impact de cette dette sur l'entreprise et de mettre en place un processus pour y remédier. Selon lui et d'autres personnes que nous avons interrogées, de nombreux DSI ne parviennent pas à suivre correctement les trois étapes de ce cheminement. « L'un des plus grands défis consiste à comprendre l'étendue de la dette technique », explique Andrew Sharp, notant que les équipes IT ont du mal à connaître le montant et l'impact de la dette technique « parce qu'elle s'étend à différents systèmes et qu'elle a des effets d'entraînement ».

Mais, comme pour la plupart des autres éléments de l'activité économique aujourd'hui, la dette ne peut pas être gérée avec succès si elle n'est pas mesurée, selon ce dernier, ajoutant que l'informatique doit s'améliorer dans l'identification, le suivi et la mesure de la dette technique. « L'informatique a toujours une idée de l'endroit où se situent les problèmes, des placards où sont stockés les cadavres, mais sans que cela s'appuie sur une analyse formelle.

Une approche structurée de cette question pourrait permettre de réfléchir à des éléments qui n'avaient pas été pris en compte auparavant. Il ne s'agit donc pas seulement de savoir que nous avons des problèmes, mais de savoir quels sont ces problèmes et d'en comprendre l'impact. La visibilité est vraiment essentielle. » Sans toutefois entrer dans un suivi exhaustif et pointilleux de chaque élément de la dette technologique. C'est plutôt la dette destinée à être réduite ou effacée qu'il faut monitorer avec soin.

Ken Knapton, vice-président sénior et DSI de Progrexion (crédit à la consommation), souligne lui aussi l'importance de connaître les détails de la dette accumulée par la DSI. À cette fin, il a mis au point avec son équipe une méthode de mesure, qui évalue la dette technique en fonction d'attributs technologiques clés (supportabilité, durée de vie restante prévue, stabilité et durée de vie totale) et de deux attributs supplémentaires (criticité pour l'entreprise et alignement stratégique). Sur cette base, le DSI multiplie la somme des quatre attributs clés par la somme des deux derniers, puis normalisent les valeurs pour obtenir un ratio compris entre 0 et 1. Selon Ken Knapton, une note finale comprise entre 0 et 0,4 est acceptable ; entre 0,5 et 0,7, elle devient préoccupante. Enfin, une dette supérieure à 0,7 est classée comme critique. « Maintenant que nous disposons d'un cadre pour mesurer la dette technique, nous sommes en mesure de la suivre et de nous concentrer sur la partie à laquelle nous allons nous attaquer ou sur laquelle nous prévoyons de travailler », résume le DSI.

2. Rembourser la dette par ordre de priorité

Ken Knapton explique qu'il a pu constater de visu ce qu'il en coûte de ne pas rembourser la dette technique en temps voulu. Et de citer une équipe de développement qui a utilisé une bibliothèque Java sans aller chercher, en fin de projet, le code mis à jour pour gagner du temps et ne pas obérer le Time-to-market, une des raisons principales expliquant la croissance de l'endettement. Cette décision, bien que justifiée au moment du développement et du déploiement initial du produit, a entravé la capacité de l'équipe à effectuer des mises à jour et à apporter les modifications nécessaires à l'évolution de l'application par la suite.

Pour le DSI de Progrexion, « il n'y a rien de plus permanent qu'une décision temporaire » si cette dernière n'est pas réexaminée. « Parce que vous autorisez toutes ces micro-décisions, cette dette technique peut s'installer et vous avez alors des solutions trop difficiles, trop complexes, qui ne vous permettent pas d'être aussi agiles que vous souhaiteriez l'être. C'est à ce moment-là que la dette technique commence à devenir un passif : lorsque nous ne la remboursons pas », explique-t-il.

« Aujourd'hui, nous la mesurons, nous la gérons et nous reconnaissons que si nous acceptons une certaine dette technique pour être les premiers sur le marché, nous devons aller jusqu'au bout du processus et rembourser cette dette technique une fois la mise sur le marché effectuée », reprend Ken Knapton, qui indique que lui et son équipe savent désormais qu'il fait inscrire cette tâche à leur agenda.

Pour ce faire, la DSI de Progrexion, qui travaille de manière agile sur l'ensemble de son périmètre, a déplacé le moment où une initiative IT est déclarée achevée pour y inclure l'atténuation de la dette technique. « Un projet n'est pas terminé tant que l'on n'est pas revenu en arrière sur ce qu'on a embarqué comme dette technique ; et tout le monde est désormais d'accord pour dire que c'est ainsi que nous définissons le terme 'terminé' », tranche Ken Knapton, en précisant que la dette technique fait partie du backlog des équipes IT jusqu'à ce que le travail d'atténuation soit achevé. « Je ne veux pas qu'une solution temporaire devienne permanente, c'est pourquoi ce travail d'atténuation est officiellement inscrit sur notre feuille de route ».

D'autres préconisent également l'allocation de ressources (temps et argent) ainsi que la création d'une responsabilité pour la réduction de la dette. Andrew Sharp, par exemple, souhaite « améliorer les opérations de vérification de la valeur ajoutée d'un projet, de connaissance et de surveillance des bogues, de budgétisation de la maintenance et de tout nouvel équipement nécessaire. Un nombre surprenant d'organisations ne se penchent pas suffisamment sur ces questions. »

3. Traiter la dette technologique comme un risque métier

Spécialiste de l'innovation des applications numériques chez Microsoft, Enoche Andrade a conseillé des cadres sur la dette technique. Pour lui, il ne s'agit pas seulement d'un problème informatique ; le sujet représentant un risque pour l'entreprise toute entière, du fait des implications commerciales, financières et de sécurité de la dette technique. Donc Enoche Andrade estime que la dette technique est un sujet qui concerne tous les dirigeants et responsables métiers, et pas seulement la DSI, et que les évaluations concernant le montant de la dette technique, ainsi que le moment et la manière dont elle doit être remboursée, doivent s'aligner sur la stratégie de l'entreprise et les besoins essentiels de l'activité.

« Les DSI ont la responsabilité essentielle de sensibiliser le conseil d'administration et les équipes dirigeantes à ce sujet, explique le spécialiste de l'innovation. Pour favoriser une culture de la sensibilisation et de la responsabilisation à l'égard de la dette technique, les entreprises devraient encourager les équipes cross-fonctionnelles et fixer des objectifs et des KPI communs encourageant tous les départements à travailler ensemble pour remédier à la dette technique et favoriser l'innovation. Cela peut inclure la création d'un environnement sécurisé permettant aux développeurs d'expérimenter de nouvelles approches et technologies, favorisant l'innovation et l'amélioration continue. »

Ken Knapton reconnaît qu'il est nécessaire d'intégrer les autres parties prenantes au sein de l'entreprise lorsqu'il s'agit de décider du moment où il convient d'assumer la dette technique, de mesurer son impact ou encore d'établir un ordre de priorité pour les éléments à rembourser. Et d'affirmer que les KPI délivrés par sa DSI aident vraiment ses collègues de la direction à s'informer sur la question et à prendre conscience des enjeux : « j'ai désormais à disposition un moyen de communiquer avec mon conseil d'administration et mon équipe de direction pour dire : 'voici notre dette, et nous sommes endettés à cause de telle ou telle décision que nous avons prise par le passé'. »

4. Contracter de nouvelles dettes en connaissance de cause

Mike Huthwaite, DSI chez Hartman Executive Advisors (cabinet de conseil), compare la dette technique à la dette financière. « Pour moi, la dette est quelque chose que l'on contracte et que l'on rembourse ensuite », résume-t-il. Tout comme il est parfois judicieux de contracter une dette financière, le DSI estime qu'il est souvent plus intelligent d'accepter d'embarquer une dette technique dans un projet que de ne pas le faire. Comme d'autres, Mike Huthwaite explique que les équipes peuvent décider de contracter une dette technique pour des raisons de rapidité et d'agilité - débouchant sur des avantages commerciaux qui l'emportent sur les coûts de la dette technique.

« Il s'agit toujours d'un compromis, et si l'on poursuit l'analogie avec la dette personnelle, il y a des moments où contracter une dette a de la valeur. Mais il s'agit tout de même d'une dette. Il faut donc espérer que vous le fassiez de manière prudente », ajoute-t-il. Mike Huthwaite explique qu'il demande toujours aux équipes informatiques de faire preuve de discernement, en mettant en balance les avantages qu'elles tirent de l'utilisation, par exemple, d'un code sous-optimal et les inconvénients de cette décision. C'est ce qu'il appelle la dette technique intentionnelle, par opposition à la dette technique non intentionnelle qui est contractée sans réelle réflexion. « La dette technique intentionnelle a sa place et sa valeur ; la dette technique non intentionnelle est un problème bien plus important, souligne le DSI. Lorsque vous ne suivez pas l'ensemble de la dette contractée, vous pouvez, en effet, vous retrouver au bord de la faillite. »

Enoche Andrade (Microsoft) se retrouve sur la même ligne, affirmant que même si les organisations ne peuvent pas, de manière réaliste, éliminer toute dette technique, elles peuvent prendre des mesures pour limiter sa création (et en particulier la création de dette non intentionnelle). Et de conseiller aux équipes IT d'adopter la méthodologie de développement agile, de remanier leurs codes régulièrement, d'automatiser les tests et de rationaliser les processus. Selon lui, ces mêmes équipes devraient également utiliser des outils d'analyse de code pour identifier la dette technique et procéder à des révisions régulières du code par des pairs et des tiers afin de garantir la qualité du code et d'identifier les problèmes potentiels. Sans oublier les travaux portant sur la simplification de l'architecture, le découpage des applications en composants et la standardisation à l'échelle de l'entreprise.

5. Reconnaître qu'il s'agit d'un processus continu

Wayne McGurk, DSI et vice-président de la National Rural Electric Cooperative Association (NRECA, qui regroupe 900 coopératives d'électricité aux Etats-Unis), ne considère pas la dette technique comme une bonne ou une mauvaise chose, mais plutôt comme « le résultat naturel du processus de développement, survenant parce que quelque chose de nouveau est en train de se construire ».

« On a tendance à aller aussi vite que possible pour sortir le MVP, et on ne construit pas nécessairement une application très industrialisée au début, reprend le DSI. Les équipes font des compromis, optant pour des technologies qui fonctionnent pour le MVP mais qu'elles savent insuffisantes lorsque les solutions prendront de l'ampleur. »

Wayne McGurk tient compte de ces éléments non seulement dans son cycle de développement, mais aussi dans les opérations informatiques, en faisant appel à diverses tactiques pour créer une approche holistique de la gestion de la dette technique sur une base continue. Dans le cadre de cette approche, la DSI de la NRECA documente et détaille l'introduction de toute nouvelle dette technique, qui est ensuite suivie par le système de ticketing de l'organisation afin que les équipes IT « puissent tout rassembler, signaler les éléments essentiels et les passer en revue ».

Le DSI examine également l'impact de chaque élément de dette technique sur les opérations dans cinq domaines clés : simplicité, flexibilité, continuité, sécurité et transparence. « Lorsque la dette technique commence à entraver l'un de ces principes de fonctionnement, elle atteint un niveau tel qu'il faut s'en préoccuper », tranche-t-il. Wayne McGurk et son équipe informatique tiennent alors compte du niveau d'impact, du risque pour l'organisation et de la stratégie globale de l'organisation pour établir un ordre de priorité pour les travaux de réduction de la dette technique. Décisions qu'ils font ensuite connaître dans l'ensemble de l'organisation, créant ainsi une visibilité sur le sujet.

Ce processus est aujourd'hui intégré dans le workflow du service informatique, explique Wayne McGurk, ce qui garantit une gestion continue de la dette technique. Par exemple, les équipes Scrum sont censées identifier les nouvelles dettes et déterminer quand et comment les traiter. « C'est une culture de la responsabilité qu'il s'agit d'instaurer, pour que les équipes sachent que ce n'est pas parce qu'un projet est livré qu'il est terminé. C'est un processus, et il n'y a pas de fin à ce dernier, qui doit s'intégrer à votre stratégie de gestion de la demande - couvrant à la fois la demande de nouveaux travaux, mais aussi ceux liés au Legacy et à la dette technique », explique le DSI de NRECA.