Dette technique des entreprises : le spleen des DSI, la gangrène de l'agilité

Le sujet est d'autant plus important car, d'après les estimations d'un certain nombre d'experts, le coût de la dette technique représente à peu près 15% des budgets totaux annuels informatiques.

La dette technique est devenue un sujet clé pour les directions informatiques et métiers, qui s’appuient sur l’IT pour faire tourner leurs processus et leurs services auprès des clients. Selon le dernier rapport du spécialiste de la dette technique Stepsize, les équipes IT consacreraient en moyenne 33% de leur temps à la maintenance et à la gestion de systèmes hérités, dont 50% dédiés exclusivement à la gestion de la dette technique. Il ressort en outre que plus de 60% des professionnels interrogés estiment que la dette technique est à l'origine d'incidents qui ralentissent le processus de développement.

Le sujet est d’autant plus important car, d’après les estimations d’un certain nombre d’experts, le coût de la dette technique représente à peu près 15% des budgets totaux annuels informatiques. Si l’on remet ce pourcentage au niveau de grandes entreprises du Cac 40, dont un grand nombre dépensent un milliard d’euros dans leurs infrastructures informatiques IT, cela signifie que près de 150 millions d’euros seraient dépensés pour résoudre ou atténuer les conséquences néfastes de la dette technique.

Comprendre la dette technique

La dette technique est un concept issu du monde du développement logiciel, et inventé en 1992 par l’informaticien américain, Ward Cunningham. Ce dernier a repris la notion de dette financière, en l’appliquant au domaine technologique. Il existe deux types majeurs de dettes techniques : le code legacy ou code hérité, d’une part et les applications et services digitaux de mauvaise qualité, d’autre part.

Lorsqu’on parle de code legacy, on entend les applications développées par le passé et qui peinent à évoluer et se moderniser au même rythme que l’écosystème moderne. Ce dernier étant notamment utilisé par les équipes DevOps lors de leur développement (build) et sont ensuite déployées (run).

Autre source de dette, les applications et services développés et de mauvaise qualité. Leur existence est liée au fait que souvent les équipes doivent travailler avec des contraintes de temps, de budget, et développent ainsi sans spécifications et cahiers des charges suffisamment précis. Cela conduit à du code qui génère des erreurs, qui est difficilement malléable, et est peu évolutif.

Dans ces deux cas de figure, le manque d’interopérabilité et d’évolutivité génère d’importants coûts de mise à niveau, ou encore de gestion et peut se révéler chronophage pour les équipes, ce qui contribue à la dette technique.

Surcoûts de maintenance

Lorsqu’une entreprise possède l’un de ces deux éléments dans ses assets digitaux, cela génère alors des surcoûts à deux niveaux : la maintenance corrective et la maintenance évolutive.

Dans le cas de la maintenance corrective, le code hérité et les applications de mauvaise qualité vont générer un nombre anormalement élevé d’incidents, allant des problèmes de fonctionnement, aux erreurs, jusqu’au manque d’agilité. Cela va nécessiter l’intervention d’experts informatiques qui travaillent sur la maintenance applicative afin d’identifier la source de ces problèmes, erreurs, et indisponibilités de services. Ils devront ensuite trouver une stratégie de remédiation optimale, puis la déployer pour éliminer la cause racine du problème et faire en sorte que l’application problématique soit de nouveau disponible sans erreur. Sachant que les budgets maintenance de la SI représentent entre 20 et 30% du budget total de la DSI, le coût d’une telle mobilisation sur une application est élevé et se multiplie selon le nombre d’applications et services – souvent nombreux – à maintenir.

En ce qui concerne la maintenance évolutive, les problèmes sont principalement dus à l’interopérabilité, c’est-à-dire à la difficulté d’intégrer ces services digitaux au sein des écosystèmes modernes qui utilisent des technologies nouvelles. Ces applications et services nécessiteront ainsi la mobilisation d’experts spécialisés qui passeront plus de temps à les intégrer dans l’écosystème de l’entreprise.

Par ailleurs, le développement de nouvelles fonctionnalités applicatives contribue également à la dette technique. En effet, les applications évoluent dans le temps, pour offrir de nouvelles fonctionnalités aux utilisateurs, et mobilisent ainsi les équipes DevOps. Or, si ces dernières utilisent des environnements de DevSecOps trop anciens ou obsolètes, ajouter ces nouvelles fonctionnalités devient alors plus coûteux.

L’une des causes principales de ces développements applicatifs moins qualitatifs repose sur le fait que les ressources IT se font rares, sont chères, ce qui pousse les équipes à bricoler leurs applications, créant ainsi des problèmes à moyen-long terme.

Réduire le coût de la dette technique

Trois bonnes pratiques peuvent être adoptées par les entreprises pour aider à réduire ce coût de la dette technique :

1. S’équiper d’outils adaptés

Déployer des outils adéquats, pour gérer le quotidien, permet aux équipes opérationnelles d’avoir une visibilité et d’une observabilité complètes de tout ce qu’il se passe sur le réseau IT. Elles sont ainsi à même d’identifier rapidement les causes racines des problèmes émergents, tels que la latence, les ralentissements de bande passante, les pannes et incidents, ou encore les activités inhabituelles. Grâce à cela, les équipes peuvent remédier ou éliminer ces problèmes plus rapidement et contribuer ainsi à réduire la dette technique.

2. Tenir un inventaire détaillé

Disposer d’un inventaire automatisé de l’ensemble des actifs informatiques, des infrastructures aux applications, permet aux équipes IT d’avoir une visibilité claire sur ce qu’elles doivent gérer et maintenir. Ces informations doivent être stockées dans une base de données de gestion de configuration (CMDB pour Configuration Management DataBase en anglais) qui permet d’identifier tout ce qui est ancien et de lancer des programmes, afin d’éliminer cette dette technique dans le temps. Cette action est essentielle pour les équipes IT qui ont besoin d’avoir une vision claire des actifs à gérer, et pourront de cette manière, réduire la dette technique.

3. Déployer des processus DevSecOps

L’action la plus importante se situe sans conteste au niveau des processus de DevSecOps. En effet, il y a dix ans encore, le build représentait 30% des process IT, contre 50 à 60% aujourd’hui, soit quasiment le double ; les entreprises investissent de plus en plus dans le développement de nouvelles capacités digitales. Ainsi, si les logiciels sont de bonne qualité, cela va mathématiquement réduire, voire éliminer, la dette technique. Par ce biais, les coûts de maintenance s’en trouveront réduits, la satisfaction des utilisateurs sera quant à elle maximisée puisque ces derniers disposeront d’applications à la fois fonctionnelles, toujours disponibles et ergonomiques. La qualité des processus DevSecOps est donc absolument clé pour réduire et maitriser la dette technique.

Dans ce contexte, l’observabilité est essentielle pour les entreprises qui souhaitent gérer plus efficacement leurs différentes initiatives d’optimisation des coûts, des systèmes, apporter des améliorations, augmenter leur agilité, maximiser la satisfaction client et éliminer la dette technique.

Shadow IT : "utile mal-aimé" de la DSI

Le shadow IT qui consiste en l'utilisation de systèmes, d'appareils, de logiciels, d'applications et de services informatiques qui n'ont pas reçu l'approbation explicite du service informatique contribue également à la dette technique. Si certaines entreprises sont parvenues à l’éliminer complétement, d’autres entreprises choisissent de l’ignorer pour des raisons matérielles ou politiques, et voient par conséquent le taux d’applications et d’instances en shadow IT augmenter. C’est particulièrement problématique car cela coûte très cher et cela constitue également un risque de sécurité pour l’entreprise. En effet, en déployant des outils en parallèle des systèmes officiels, les standards de sécurité sont réduits, et les équipes informatiques perdent l’observabilité et le contrôle des actifs de leurs systèmes, qui se trouvent ainsi vulnérabilisés. D’un point de vue opérationnel, il devient alors impossible de déployer des référentiels communs, partagés par l’ensemble des membres de l’entreprise, ce qui conduit alors à une perte de valeur et complexifie la gestion pour la DSI.

Cette pratique est principalement imputable aux développeurs et au personnel technique qui vont plus naturellement se tourner vers le shadow IT en déployant des outils cloud, IaaS, ou PaaS utiles à leurs activités et vont créer alors des circuits parallèles, hors du périmètre de la DSI, générant ainsi des coûts supplémentaires. Cela contribue à l’accroissement de la dette technique notamment car la DSI perd le contrôle sur les standards, et donc sur la qualité.

Toutefois, le shadow IT a également un impact non négligeable sur l’agilité des entreprises. C’est pour cette raison que certaines directions informatiques sont laxistes sur le sujet et tolèrent ces pratiques. C’est notamment le cas avec celles possédant des bureaux distants sur d’autres continents. Souvent, ils laissent les équipes utiliser les applications et services dont ils ont besoin, pour permettre à celles-ci de mener leur mission à bien. N’ayant pas nécessairement les ressources financières pour soutenir ces besoins ponctuels, ils estiment plus simple de créer du lien avec les outils en place pour assurer le fonctionnement plutôt que d’investir ou de bloquer le recours à des applications en dehors de l’écosystème.

En s’équipant d’outils de découverte automatisée (CMDB), les équipes seront plus à même d’identifier l’ensemble des instances (CI pour configuration items), serveurs ou détails des machines présentes dans les systèmes de l’entreprise. Ils devront également établir des cartographies précises de ce qui existe au niveau de la topologie informatique, et pourront ainsi créer des liens de dépendance entre l’ensemble de ces CI. En effet, les outils de monitoring sont indispensables pour identifier où se trouvent les problèmes, leur raison d’être et la manière de les résoudre ; ces bonnes pratiques, si elles n’annuleront pas la dette technique du jour au lendemain, aideront à identifier les applications et services vieillissants et coûteux et permettront de trouver des solutions pour réduire, et à terme, annuler cette dette.

La question de la dette technique est complexe et n’est pas près de disparaitre, notamment face aux innovations technologiques qui sont développées quotidiennement et à l’accélération de la transformation digitale des entreprises. Les dirigeants et les DSI devront au contraire faire preuve de vigilance et adopter des pratiques leur permettant de suivre attentivement leurs systèmes en place. Ajouter cette question à l’agenda des comités de direction en démontrant l’impact de cette dette sur les performances, contribuera très certainement à renforcer la collaboration entre les directions et les DSI pour résoudre ce problème.