«Tout est une question de dose », dit-on souvent, en faisant référence aux poisons. On peut aussi faire le même constat avec la dette technique, qui, si elle n’est pas connue et gérée, s’apparente à un poison pour n’importe quel système d’information. Qui peut conduire à des catastrophes : une étude du cabinet Computer Economics, publiée en 2019, avait estimé qu’une entreprise sur cinq présentait un risque de faillite technologique, en raison de l’ancienneté de son ERP et, surtout, de la date de l’installation des derniers upgrades. Une perspective qui s’applique également aux environnements mainframes.
Selon Gartner, la dette technique maintient des coûts de fonctionnement élevés, compromet la sécurité, augmente le coût et le temps pour le changement, impacte négativement la perception des utilisateurs, accroît le nombre d’incidents, réduit la durée de vie d’une application et allonge la durée des indisponibilités. Le Cigref s’est penché sur cette question et observe que « la dette et l’obsolescence IT concernent toutes les organisations, quels que soient leur taille, leur secteur d’activité, leur ancienneté ou leurs histoires. »
Comment se forme-t-elle ? Là encore, plusieurs facteurs entrent en jeu : une obsolescence des matériels et du langage de développement utilisé, une évolution du besoin fonctionnel, les conséquences des roadmaps des fournisseurs, des contraintes réglementaires, une pénurie de compétences, ainsi que des évolutions technologiques. Pour la réduire, selon le Cigref, il convient d’agir à la fois sur l’évolution des composants du SI vers une cible plus récente, la réalisation d’une revue du code incompatible avec les standards et les pratiques de développement (coût de non-qualité) et la mise à niveau des équipes techniques tout au long du cycle de vie du SI.
On distingue plusieurs types de dettes. D’abord, la dette technique qui, pour le Cigref, « se caractérise par un retard technologique sur l’environnement technique et sur les montées de versions (au niveau serveurs, OS, middlewares, etc.). Ce retard peut engendrer des coûts et efforts de plus en plus importants, causer des dysfonctionnements sur les applicatifs métiers sans correction possible, et ainsi obliger à effectuer des changements de matériel et de nombreux tests de non-régression. »
Ensuite, la dette applicative, davantage liée « à un langage informatique de moins en moins utilisé ou une architecture obsolète incompatible avec des montées de versions d’outils (qui peut obliger par exemple à conserver d’anciennes versions de navigateurs ou autres produits sur les postes de travail). » Enfin, la dette fonctionnelle, « constituée de systèmes aux fonctionnalités complexes, inutilisées ou qui ne sont plus adaptées pour répondre à de nouveaux besoins métiers. Avec l’évolution du SI, certaines fonctions peuvent notamment être dédoublées. La cartographie fonctionnelle ne respecte plus l’urbanisation, qui tente d’évoluer vers la simplification. »
Selon une étude de Flexera, 10 % des entreprises considèrent la réduction de la dette technique comme une priorité en 2021. Mais ce n’est pas une tâche facile. Le Cigref estime en effet que traiter cette problématique s’apparente à une « démarche pavée de challenges », parmi lesquels la décentralisation des organisations, le manque d’outillage pertinent, la dilution des responsabilités (en particulier entre la DSI et les métiers), la diversité des fournisseurs, le poids du shadow IT, ainsi que le manque de temps face aux exigences de livrer des projets toujours plus rapidement. Sans oublier ce qui est probablement le frein le plus important : « Le manque de vision de l’architecture d’entreprise par la direction générale et les directions métiers, l’absence d’une cible SI partagée et le manque de sensibilisation. »
Pilotage de la dette et de l’obsolescence IT, préserver l’agilité, la sécurité et la capacité d’innovation des SI, Cigref, 37 pages.
Les recommandations du Cigref
- Adopter une approche présentant les risques business associés à la dette IT.
- S’appuyer sur les enjeux de cybersécurité et de continuité de services.
- Formaliser une cartographie du SI et mettre en exergue la dette et l’obsolescence IT.
- Mettre en place des indicateurs de suivi de l’évolution de la dette IT.
- Construire une grille de référence ou une matrice d’obsolescence des logiciels.
- Développer un discours pédagogique ancré dans la réalité de son organisation.
- Sensibiliser la direction générale et les directions métiers aux enjeux d’une maîtrise partagée du patrimoine IT.
- Sanctuariser un budget pour la gestion de la dette IT.
- Décommissionner les applications les moins utilisées.
- Intégrer le décommissionnement des éléments du SI dans les projets de transformation.
- Utiliser tous les projets de transformation numérique comme leviers de maîtrise de la dette IT.
- S’appuyer sur la migration dans le cloud et sur les outils d’automatisation à disposition.
- Trouver un équilibre entre le maintien des compétences nécessaires sur le SI patrimonial (legacy) et l’évolution des compétences indispensables pour maîtriser les nouvelles technologies.