5 conseils pour lutter contre la dette technique

Les DSI sont confrontés à la dette technique depuis des décennies, mais beaucoup ont encore du mal à la gérer de manière adéquate. Et cela leur coûte.

La société de conseil en gestion Protiviti a interrogé plus de 1 000 dirigeants de la technologie dans le cadre de son enquête mondiale sur les cadres technologiques de 2023 et a constaté que la dette technique est un obstacle majeur à l’innovation pour près de 70 % des organisations. Les dirigeants ont également signalé que la dette technologique consomme 31 % des budgets informatiques et nécessite 21 % des ressources informatiques pour être gérée.

L’enquête LeanIX sur l’optimisation des coûts informatiques 2023 a abouti à un résultat similaire, puisque 56 % des personnes interrogées ont déclaré que les technologies obsolètes et la dette technique sont des contributeurs particulièrement élevés aux budgets informatiques gaspillés.

Pendant ce temps, les responsables informatiques qui gèrent avec succès la dette technique sont bien mieux placés pour permettre à leurs organisations d’être plus performantes. Selon le cabinet de recherche et de conseil Gartner, les responsables des infrastructures et des opérations qui gèrent et réduisent activement la dette technique peuvent atteindre des délais de prestation de services au moins 50 % plus rapides pour l’entreprise.

Compte tenu de ces résultats, de nombreux DSI se sont concentrés sur la recherche de moyens de réduire leur dette technique. Des leaders technologiques expérimentés partagent cinq stratégies qu’ils utilisent pour contrôler la dette technologique.

1. Soyez analytique sur la mesure de votre dette technique

Andrew Sharp, directeur de recherche pour la pratique de l’infrastructure et des opérations chez Info-Tech Research Group, est un fervent partisan du catalogage de la dette technique. L’analyste conseille aux responsables informatiques d’établir une liste de leur dette technique critique, de connaître l’impact commercial de cette dette et d’avoir un processus pour y remédier.

De nombreux DSI, selon lui et d’autres, échouent trop souvent sur ces trois questions fondamentales.

L’un des plus grands défis consiste simplement à comprendre et à organiser l’étendue de la dette technique, explique Sharp, expliquant comment les équipes informatiques ont du mal à connaître le montant et l’impact de la dette technique, car elle s’étend sur différents systèmes. Il a des effets d’entraînement.

Mais comme presque tout le reste dans les affaires aujourd’hui, la dette ne peut pas être gérée avec succès si elle n’est pas mesurée, dit Sharp, ajoutant que l’informatique doit s’améliorer pour identifier, suivre et mesurer la dette technologique.

L’informatique a toujours une idée de l’endroit où se situent les problèmes, des placards qui contiennent des squelettes, mais il n’y a souvent pas d’analyse formelle, dit-il. Je pense qu’une approche structurée pour examiner cela pourrait être l’occasion de réfléchir à des choses qui n’ont pas été envisagées auparavant. Il ne s’agit donc pas seulement de savoir que nous avons des problèmes, mais de savoir quels sont les problèmes et d’en comprendre l’impact. La visibilité est vraiment essentielle.

Sharp met en garde contre le suivi de chaque dette technologique, soulignant plutôt la nécessité de suivre la dette destinée à être réparée.

Ken Knapton, vice-président senior et CIO chez Progrexion, souligne également l’importance de connaître les détails de la dette accumulée par son service informatique.

À cette fin, lui et son équipe informatique ont développé une méthode pour mesurer leur dette. Ils évaluent la dette sur des attributs technologiques clés (supportabilité, durée de vie restante prévue, stabilité et durée), puis sur deux attributs supplémentaires (criticité commerciale et alignement stratégique). Ils multiplient la somme des quatre attributs clés par la somme des deux derniers, puis normalisent les valeurs à un rapport entre 0 et 1.

Knapton dit que toute dette technologique dont le taux est compris entre 0 et 0,4 est acceptable, tout ce qui se situe entre 0,5 et 0,7 est préoccupant et tout ce qui dépasse 0,7 est critique.

Maintenant que j’ai un cadre pour mesurer la dette technique, j’ai pu la suivre. Nous avons pu nous concentrer sur la partie de notre dette technique sur laquelle nous allons nous attaquer et sur ce sur quoi nous allions travailler maintenant, ajoute-t-il.

2. Remboursez votre dette en la priorisant sur les feuilles de route

Knapton dit qu’il a vu de ses propres yeux le coût de ne pas rembourser la dette technique en temps opportun.

Il souligne un incident passé où une équipe de développement a utilisé une bibliothèque Java mais n’est pas revenue pour le code mis à jour dans l’intérêt du temps et de la vitesse de mise sur le marché, comme c’est souvent la principale raison de s’endetter. Cette décision, bien que justifiée au moment du développement et du déploiement initiaux des produits, a entravé la capacité des équipes à ajouter des mises à jour ou à apporter les modifications nécessaires ultérieurement.

Knapton dit qu’il a appris qu’il n’y a rien de plus permanent qu’une décision temporaire si ces décisions temporaires ne sont pas revisitées.

Parce que vous autorisez toutes ces petites décisions, cette dette technique peut rester en place et vous avez alors des solutions trop difficiles, des solutions trop complexes, qui ne vous permettent pas d’être aussi agile que vous pouvez l’être en tant qu’entreprise. C’est alors que la dette technique commence à être un handicap, lorsque nous ne la remboursons pas, dit-il.

Maintenant, nous le mesurons, le gérons et reconnaissons que si nous devions contracter une dette technique pour être les premiers sur le marché, nous devons suivre et rembourser cette dette technique après la sortie.

Pour s’assurer que ces paiements sont effectués, Knapton dit que lui et son équipe savent que nous devons ajouter à notre calendrier la capacité de le gérer et de le résoudre.

Pour soutenir cela, les équipes de Knaptons, qui travaillent de manière agile sur l’ensemble de l’informatique, ont déplacé la barre d’objectif pour définir quand elles sont terminées afin d’inclure l’atténuation de la dette technique.

Un projet n’est pas terminé tant que vous ne revenez pas en arrière et n’ajustez pas ce que vous avez accepté comme dette technique ; et tout le monde convient que c’est ainsi que nous définissons le fait, dit Knapton, notant que la dette technique fait partie du carnet de commandes des équipes jusqu’à ce que les travaux d’atténuation soient terminés.

Il ajoute : Je ne veux pas qu’une solution temporaire devienne permanente, nous l’avons donc officiellement inscrite 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 le traitement de la dette.

Sharp, par exemple, parle d’améliorer la vérification de la valeur d’un projet, de connaître et de garder un œil sur les bogues, de budgétiser la maintenance et tout nouvel équipement nécessaire.

Il ajoute : Un nombre surprenant d’organisations ne font pas cela.

3. Traitez la dette technologique comme le risque commercial qu’elle représente

Enoche Andrade, qui, en tant que spécialiste de l’innovation des applications numériques chez Microsoft, a conseillé des dirigeants sur la dette technique, affirme que la dette technique n’est pas seulement un problème pour l’informatique ; c’est aussi un risque commercial, soulignant que la dette technique a des implications commerciales, financières et de sécurité.

En tant que tel, Andrade affirme que la dette technique est un sujet pour tous les cadres et responsables de fonctions commerciales, pas seulement pour l’informatique, et les décisions concernant le moment et le montant de la dette technique à contracter et 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 de l’entreprise.

Les DSI ont la responsabilité essentielle de sensibiliser le conseil d’administration et les équipes de direction à la dette technique, dit-il. Pour favoriser une culture de sensibilisation et de responsabilité autour de la dette technique, les entreprises doivent encourager les équipes interfonctionnelles et établir des objectifs et des mesures partagés qui encouragent tous les groupes à travailler ensemble pour résoudre la dette technique et favoriser l’innovation. Cela peut inclure la création d’un environnement sûr permettant aux développeurs d’expérimenter de nouvelles approches et technologies, menant à l’innovation et à l’amélioration continue.

Knapton est d’accord avec la nécessité de faire le tour de l’entreprise lorsqu’il s’agit de décider quand contracter une dette technique, de mesurer son impact et de prioriser ce qu’il faut rembourser.

Il dit que les mesures de ses équipes informatiques aident vraiment à informer ses collègues de la suite C sur la question, en disant : Maintenant, j’ai un moyen de communiquer avec mon conseil d’administration et mon équipe de direction pour dire : C’est notre dette, et nous sommes mis à profit en raison des décisions que nous faites dans le passé.

4. Soyez intentionnel lorsque vous contractez de nouvelles dettes

Mike Huthwaite, directeur informatique chez Hartman Executive Advisors, qui fournit un leadership exécutif partiel aux clients, compare la dette technique à la dette financière. La dette envers moi est quelque chose que vous contractez, que vous résolvez ensuite, ajoute-t-il.

Tout comme il est parfois avisé de contracter une dette financière, Huthwaite dit qu’il est souvent plus intelligent d’opter pour une dette technique que de ne pas le faire. Comme d’autres, il dit que les équipes peuvent décider de contracter une dette technique pour des avantages de vitesse et d’agilité du marché qui l’emportent sur les coûts de la dette technique.

C’est toujours un compromis, et si vous continuez sur l’analogie de la dette personnelle, il y a des points ou des décisions où s’endetter a de la valeur. Mais sa dette reste tout de même. Alors j’espère que vous le faites de manière prudente, dit-il.

Huthwaite dit qu’il demande aux équipes informatiques d’assumer délibérément la dette technique, en évaluant les avantages qu’elles obtiennent en utilisant, par exemple, un code sous-optimal par rapport aux inconvénients de cette décision. Il appelle ça intentionnel dette technique, contrairement à involontaire dette technique contractée sans cette délibération.

La dette technique intentionnelle a sa place et sa valeur ; la dette technique non intentionnelle est un problème plus important, dit-il. Lorsque nous ne suivons pas toutes les dettes, vous pouvez vous retrouver au bord de la faillite.

Andrade a des conseils similaires, disant que bien que les organisations ne puissent pas éliminer de manière réaliste toute dette technique, elles peuvent prendre des mesures pour limiter sa création (et en particulier la création de dette non intentionnelle).

Il conseille aux équipes d’adopter la méthodologie de développement agile, de refactoriser, d’automatiser les tests et de rationaliser les processus. Les équipes doivent également utiliser des outils d’analyse de code pour identifier la dette technique et faire réviser régulièrement le code par les pairs et les parties prenantes pour garantir la qualité du code et identifier les problèmes potentiels. Ils doivent également adopter la simplification architecturale, la composition et la normalisation.

5. Reconnaître que la gestion de la dette est un processus continu

Wayne F. McGurk, directeur informatique et vice-président directeur de l’informatique de la National Rural Electric Cooperative Association, ne considère pas la dette technique comme une bonne ou une mauvaise chose, mais plutôt comme un résultat naturel du processus de développement, se produisant parce que quelque chose de nouveau est en cours de construction.

Il y a une tendance à aller aussi vite que possible pour obtenir le MVP, et vous ne construisez pas nécessairement une application trop industrialisée au début, dit-il. Les équipes font des compromis, optant pour des technologies qui fonctionnent pour le MVP dont elles savent qu’elles seront insuffisantes à mesure que les solutions évoluent.

McGurk prend donc cela en compte non seulement dans son cycle de développement, mais aussi dans ses opérations informatiques, en utilisant diverses tactiques pour créer une approche holistique de la gestion continue de la dette technique. Dans le cadre de cette approche, l’équipe de McGurks documente et détaille l’introduction de toute nouvelle dette technique, qui est ensuite suivie via le système de billetterie de l’organisation afin que les équipes informatiques puissent tout récupérer, le signaler et l’examiner.

McGurk examine également l’impact de chaque 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 le niveau où nous voulons y remédier, explique-t-il.

McGurk et son équipe informatique tiennent compte du niveau d’impact, du risque pour l’organisation et de la stratégie globale de l’organisation pour ensuite hiérarchiser ce qui nécessite une attention particulière. Ils font ensuite connaître ces déterminations, créant ainsi une visibilité sur le sujet dans toute l’organisation.

Tout cela est intégré dans le flux de travail de son service informatique, explique McGurk, ce qui garantit que la gestion de la dette technique n’est pas traitée comme un projet ponctuel, mais plutôt gérée de manière continue. Par exemple, ses équipes Scrum doivent identifier une nouvelle dette technique et déterminer quand et comment y remédier.

Vous devez créer une culture de responsabilité afin que vos équipes sachent que ce n’est pas parce qu’un projet est livré qu’il n’est pas terminé. C’est un voyage, et il n’y a pas de fin, alors cela fait partie de votre stratégie de gestion de la demande en gérant à la fois la demande de nouveaux travaux, mais aussi les travaux hérités et la dette technique, dit-il.