Le retour d’expérience de deux architectes d’entreprise sur la gestion de l’obsolescence et de la dette du système d’information
On parle beaucoup de “dette du SI”. Qu’est ce que c’est pour toi ?
Sébastien
Le terme “Dette” fait écho à quelque chose qui est dû avec une dimension financière. Il s’agit d’un terme inventé en 1992 par Ward Cunningham inspiré du concept existant de dette dans le domaine des finances et des entreprises, appliqué au domaine du développement logiciel.
Si on fait le parallèle avec le monde financier, pour combler le vieillissement du SI on doit mener des actions, si rien n’est fait, la dette se creuse.
“La dette c’est réel ! La métaphore se poursuit : soit on paie les intérêts, soit on la rembourse.“
La Dette du SI est la conséquence d’écarts avec différentes exigences, une forme d’obsolescence liée au vieillissement du système d’information :
- Tout d’abord un écart sur les exigences fonctionnelles (écart avec les attentes métier, éventuels bugs).
- On retrouve ensuite l’écart sur les exigences non fonctionnelles qui reprend tout ce qui est lié à l’ergonomie, à la performance, à la disponibilité, à la sécurité).
- Les lois évoluent, le SI doit s’adapter, on peut parler d’écart réglementaire dans ce cas (RGPD…)
- On retrouve également l’écart au niveau des compétences (technique et/ou fonctionnelle) et des connaissances (documentation pas à jour ou inexistante, départ de collaborateurs) requises pour maintenir et faire évoluer le SI, ses applications. Il est indispensable de disposer de façon continue de documentation et de compétences pour maintenir le SI.
- L’impact environnemental peut aussi être vu comme une facette de la dette, depuis que la sobriété numérique s’inscrit dans les stratégies des organisations.
“Ce n’est pas uniquement une dette en termes de coût mais également une obsolescence du SI qui induit des risques ! La conséquence directe, c’est que l’entreprise va prendre des risques. »
Olivier
Nous rencontrons parfois un écart au niveau du respect des standards (normes, standards techniques, standards d’architecture, …). On parle d’écart sur les standards ou principes d’architecture, de gestion des données, gestion des échanges, principes de sécurité ou socles techniques ….si les composants du système d’information ne s’y conforment pas. Exemples : Un SI non modulaire, présence d’un couplage fort entre 2 composants du SI, …
Il faut également mesurer l’écart entre le SI “connu et maîtrisé » et le SI réel : On parle ici de shadow IT, qui constitue une forme de risque pour l’entreprise.
“Le shadow IT est également un risque car on ne le maîtrise pas ».
Quel est le lien entre cette dette du Système d’information et le Legacy ?
Sébastien
Le SI historique, parfois appelé “Legacy”, est souvent un composant de la dette du SI.
Le legacy fait référence à des composants historiques “vieillissants” du SI, importants pour les métiers, qui sont devenus complexes à faire évoluer et à moderniser et dont les conséquences sont plus ou moins gênantes.
On parlera d’obsolescence ou de dette technique quand on aura des difficultés à faire évoluer des composants du système d’information. Le “legacy” est fréquemment sujet à :
- la dette technique : socles obsolescents, en limite de maintenance
- la dette d’architecture : peu modulaires, fortement couplés, peu agiles …
- la dette de compétences : connaissances non documentées et perdues, expertises introuvables sur le marché, …
Le Legacy étant complexe à maintenir, on hésite parfois à mettre la main dedans!
“Finalement le legacy c’est un cadeau empoisonné hérité de l’histoire du SI !”
L’entreprise est tiraillée entre le besoin de moderniser et la difficulté à le faire évoluer car il englobe des fonctionnalités critiques.
Olivier
Effectivement, on remarque généralement une forme de procrastination du traitement du Legacy.
En effet, transformer un composant obsolescent ne génère pas toujours de valeur visible pour les métiers donc ne suscite pas l’intérêt des actionnaires . Ces projets de modernisation sont souvent retardés au profit d’autres projets qui seront générateurs de valeur business.
Les projets de modernisation du SI sont généralement acceptés :
- Soit lorsque la situation est bloquée : impossible d’exploiter ou de faire évoluer un composant.
- Soit lorsque l’entreprise lance une transformation en profondeur permettant de combiner apport de valeur métier et transformation du legacy.
- Soit lorsque l’éditeur / fournisseur matériel tire la sonnette d’alarme.
Pourquoi en tant que DSI ou même Direction Générale, je ne peux pas me contenter d’ignorer cette dette ? Pourquoi faut-il en tenir compte ?
Sébastien
Tous ces écarts font prendre des risques au sein de la DSI mais également au niveau de l’entreprise. La dette n’a pas seulement des impacts sur le système d’information, il y a des conséquences métiers : insatisfactions clients, manque de productivité, indisponibilité des outils de travail, CyberAttaques, …. L’impact sur les activités de l’entreprise peut être fort !
Le risque lié à la maintenabilité évolutive et corrective est fort également. De nouveaux besoins émergent, et les équipes rencontrent parfois des difficultés dans la mise en œuvre car les solutions concernées ne sont plus supportées et maintenables : perte de compétences, manque de cadre et de process pour les analyses d’impact, failles de sécurité, …
“Une autre conséquence, c’est que je ne maîtrise plus les impacts des modifications du SI, et j’engendre des cascades d’événements, des régressions applicatives et des impacts métier”.
La qualité globale du service diminue et ce sont finalement les utilisateurs qui sont impactés.
Olivier
Plus la dette se cumule, plus l’énergie requise et le temps nécessaire pour réaliser un changement métier et le tester augmente. On paye de plus en plus cher, on constate de plus en plus de délai dans la mise en oeuvre, et pour une qualité en sortie de moins en moins bonne”.
Cette incapacité à faire évoluer le SI peut induire un retard concurrentiel : si je ne peux pas utiliser de nouveaux services, si je mets plus de temps, si cela me coûte plus cher, mes concurrents vont creuser l’écart.
Rester concurrentiel nécessite de faire évoluer son SI!
Comment faire passer le message à la DSI et à la Direction Générale quand travailler sur la dette ne semble pas créer directement de valeur business ?
Olivier
Il faut considérer la dette du SI comme un risque pour l’entreprise. Il faut donc rendre compte de la dette en mettant en avant des facettes intelligibles pour la Direction: dégradation de l’écart concurrentiel , perte de productivité, perte financière, risque légal, risque de sécurité, blocage métier … La vraie valeur pour l’entreprise c’est de diminuer le risque !
La dette a un impact sur la marque employeur et la capacité à recruter : disposer de bons outils, modernes, ergonomiques, qui marchent bien, qui facilitent le travail quotidien et favorisent le confort des métiers… Les SI modernes, adaptables et souples suscitent plus l’intérêt des nouveaux collaborateurs.
Sébastien
Les entreprises adoptent généralement un comportement d’évitement. Elles attendent et la dette du SI s’amplifie . Plus on attend, plus la situation est grave: La dette non maîtrisée est un véritable danger à moyen / long terme.. Il serait préférable de réfléchir au plan de décommissionnement très en amont pour avoir une feuille de route permettant d’aborder le changement de façon plus progressive et sereine .
Pour autant, la dette est acceptable lorsqu’elle est choisie avec discernement, permet de gagner en agilité à court terme et lorsqu’elle est tracée pour traitement ultérieur.
Il est de la responsabilité des directions métiers, de la DSI de poser un cadre de gestion (gouvernance) de la dette afin de détecter, gérer, décider de créer ou de supprimer de la dette en conscience. Pour pérenniser cette gestion, il semble pertinent de définir un nouveau rôle au sein de la DSI : “responsable de l’obsolescence du SI”.
Il faut se donner un cadre pour traiter les bons sujets d’obsolescence, prioriser leur traitement en fonction de la probabilité d’occurrence et l’impact du risque détecté. La matrice d’aide à la prise de décision est importante pour impliquer la DG sur ces sujets de dette du SI.
A l’échelle de l’entreprise la direction des risques pourrait être en charge de la dette du SI par le prisme des “Risques du SI” et se poser en “porte parole” auprès de la direction générale.
Concrètement, quelle est la démarche à suivre, étape par étape pour réduire ou supprimer cette dette du SI ?
Olivier
Le prérequis nécessaire est d’avoir la connaissance de son SI ( inventaire des applications, capacités fonctionnelles, propriété des données, conformité réglementaire, échanges de données, composants techniques …) pour analyser et mesurer les écarts.
Il faut ensuite évaluer sa dette sur différents aspects : fonctionnels, réglementaires, applicatifs, ergonomiques, performance, sécurité, infrastructures, compétences, processus…
Cette évaluation doit se faire au regard d’objectifs fonctionnels et non fonctionnels, et au regard de standards définis (de développement, de sécurité, de performance, …). Les référentiels d’architectures sont de précieux outils pour aider l’entreprise à mesurer sa dette (ex : CMDB, outils de modélisations d’EA)
Dans le processus de gestion des changements du SI, il faut se poser la question : est-ce que j’engendre de la dette ? Au moment où la dette devient consciente il faut prendre en compte la dette générée pour limiter l’expansion d’une dette déjà existante. On peut accepter de générer de la dette si cette décision est prise en connaissance de cause et qu’elle est sous contrôle (détection, décision, suivi, gestion de sa résorption …).
Il est donc nécessaire d’établir une matrice de choix des sujets à traiter intégrant à la fois les risques mais aussi la capacité de création de valeur afin d’engager la DSI et les Directions métiers dans les processus de décision. Puis il faut communiquer, aligner les directions métier, la DSI et la direction générale sur le plan de gestion de la dette.
Par ailleurs, il est important de piloter l’écart entre l’architecture du système d’information et les standards, les préconisations éditeurs, constructeurs et sécurité (fin de support, niveau de patch, de version, failles de sécurité, absence de supervision …). Le risque est parfois de devoir migrer en urgence d’une version à une autre.
La dette identifiée doit également faire l’objet d’une décision de traitement par la transformation. Gérer la dette, cela ne fait pas rêver, cela ne crée pas de valeur directement. Contrairement aux projets créateurs de valeur métier, la dette ne séduit pas. Mais pendant ce temps là on génère de la dette.
Parfois, attendre que la surface fonctionnelle de la dette soit plus importante est nécessaire pour réussir à faire bouger les choses, avec un terrain de jeu métier plus large. Un programme de transformation métier/digital est souvent une opportunité pour combiner apport de valeur pour l’entreprise et traitement de la dette.
Sébastien
J’ajouterai qu’il ne faut pas oublier l’ensemble des acteurs, qui doivent être intégrés dans la gestion globale de la dette: partenaires, éditeurs, utilisateurs finaux,… Le partenaire a une responsabilité en termes de qualité de livrables, et il doit également y avoir un alignement sur les standards techniques, le cadre et les principes d’architecture. On va ainsi partager avec eux le cadre d’architecture de l’entreprise.
Engager un plan de formation continue des équipes permettra de prendre en compte la dette: il ne faut pas rester sur ses acquis. Favoriser la rotation des équipes permet aussi de limiter le risque.
Olivier
La dette fait partie du “paysage” : il ne faut pas chercher à l’éviter ou la supprimer à tout prix. On doit accepter de vivre avec elle, mais de manière maîtrisée en corrigeant les éléments les plus critiques. C’est un élément à prendre en compte dans la vie de la DSI et de l’entreprise. Ce qui fait souvent défaut, c’est souvent le cadre de sa prise en compte.
Quelles sont les principales difficultés / freins pour supprimer de la dette du SI ? Les facteurs aggravant ?
Sebastien
Il existe plusieurs difficultés dans la gestion de la dette.
Tout d’abord, si la DSI ne dispose pas de cadre d’architecture , il est difficile de donner un cadre aux partenaires et donc le risque est de créer encore plus de dette. Il est donc important de disposer de standards partagés , documentés, cartographiés.
Un autre facteur générateur de dette est le manque d’analyse d’impact en amont de projets. car on ne maîtrise pas la dette engendrée dans ce contexte.
Olivier
Le manque de plan de formation, de mise à niveau des collaborateurs au sein de la DSI est un frein à la gestion de la dette. Si l’entreprise n’a pas conscience des nouvelles technologies et de ce qu’elles peuvent apporter, on va creuser l’écart au niveau du SI legacy .
“Ne pas faire l’effort de cartographier son système d’information est un facteur aggravant”
La direction des risques devrait imposer de faire des audits du vieillissement du SI, une auto-évaluation pour évaluer la dette et ainsi en favoriser la gestion. Le fait d’en avoir conscience permet de limiter l’impact et le risque de la dette .
Quels sont les impacts des méthodes agiles sur la dette du SI, et réciproquement ?
Sebastien
Si l’on prend un peu de recul, l’objectif des méthodes Agiles est de créer rapidement de la valeur. Il y a cette notion d’aller vite, d’augmenter la fréquence de livraison de fonctionnalités, d’applications. Si ces pratiques sont faites sans cadre, si la dette n’est pas gérée, cette accélération des changements engendre plus de risques.
“Si l’entreprise n’a pas cette culture de la gestion de l’obsolescence dans le processus agile, le risque est de prendre des raccourcis et de faire des choix qui engendreront plus de dette”.
On revient toujours sur l’importance d’avoir un cadre : on peut accepter de créer de la dette pour apporter plus vite de la valeur métier, si on la pilote ! Parfois la pression de calendrier de mise en production oblige les équipes projet à choisir des raccourcis techniques générateurs de dette : pas facile de choisir entre la création d’une dette et éviter un retard de livraison d’une fonctionnalité qui apporte une forte valeur aux métiers. Il faudrait pouvoir l’annoncer pour que son traitement soit par la suite pris en charge dans une « backlog de la dette “.
Dans la relation entre DSI et partenaires de l’évolution du SI (ESN …), on utilise souvent des KPI de productivité (Jours / homme face à une fonctionnalité) , il faudrait pouvoir en mettre en place des KPIs de suivi de la dette.
Olivier
La finalité du Devops n’est pas uniquement la rapidité mais aussi la qualité de ce qui est produit. En intégrant des pratiques DevOps et cette notion de qualité dans la manière de produire, il est possible de traiter le sujet de la gestion de dette. On améliore les livraisons et on limite donc la génération de dette du SI sur certains aspects. Par la sensibilisation au RUN, on prend plus conscience des écarts que l’on a évoqué.
“ La somme des freins induits par la dette s’oppose à la démarche d’agilité !”
La dette du SI freine l’agilité des entreprises.
Si la dette est bien gérée dans le cadre de méthodes agiles, on peut effacer progressivement la dette de l’entreprise au fur et à mesure des sprints. Mais globalement la dette freine la mise en place des pratiques agiles . Elle engendre en effet une augmentation globale de l’effort à fournir (analyse d’impact, conception, développements, tests, …) car les composants sont plus complexes et les impacts sur les différents composants sont décuplés,…
Une simple fonctionnalité peut parfois coûter très cher à cause de la dette . La surface fonctionnelle du SI legacy peut être parfois tellement étendue que le coût et le délai d’une mise à jour devient prohibitif.
Le legacy concentre souvent la majorité de la dette d’un système d’information !
C’est souvent, lorsque le coût des évolutions devient insupportable, que les organisations décident de lancer un Appel d’Offres pour changer et faire évoluer le SI legacy. C’est la problématique de l’inertie de maintenance, il est indispensable de jouer la carte de la modularité pour rendre agile le SI.
Avez-vous d’autres retours d’expérience à partager autour de ces enjeux de SI historique ?
Sébastien
Parfois la vision de la direction générale sur la cause de leur problème n’est pas bonne. “Il faut changer de site e-commerce ». Quand on creuse, le problème ne vient pas du site e-commerce mais d’une brique plus centrale et ancienne du SI. Cette brique marche très bien mais que la connaissance de son architecture est perdue on ne peut plus la faire évoluer… La méconnaissance du SI au global, devient un risque : on croit connaître l’origine du problème mais c’est plus profond. C’est un bon exemple de dette lié à une érosion des connaissances/compétences.
Olivier
J’ai de nombreux exemples de grands comptes, ayant un SI historique, qui n’étaient pas rentrés dans des démarches agiles. La refonte complète du SI a duré plusieurs années, et le nouveau composant proposé ne répondait plus aux nouveaux besoins des métiers !
J’ai également connu un client qui est à la 4ème tentative de remplacement de son SI Legacy tant l’exercice est complexe.
Il faudrait créer un KPI sur la dette : le taux d’obsolescence du SI ; Ce serait un marqueur de la bonne santé du SI dans l’entreprise.
Le danger est de cacher la dette sous le tapis sous prétexte d’apporter de la valeur au métier. Il faut savoir se mettre en pause pour traiter la dette créée et limiter les risques pris par la DSI et donc par l’entreprise.
Si je suis DSI et que j’ai conscience de l’obsolescence de mon SI, en quoi Projexion peut m’accompagner ?
Projexion peut intervenir à deux niveaux dans l’accompagnement de la gestion de la dette.
Un premier niveau sur la prise de conscience de la dette : mener un cadrage projet, cartographier la situation initiale du SI, évaluer l’état de la dette. Cette évaluation initiale permettra par la suite de proposer des mesures correctives.
“Mieux vaut commencer à réfléchir au sujet et se mettre en mouvement quand les métiers ne sont pas encore impactés pour le faire correctement et avoir la prise de recul nécessaire !”
Un second niveau par la mise en œuvre d’un cadre méthodologique de gestion de la dette .
Parallèlement nous avons beaucoup de retours d’expérience sur ces sujets et pouvons donc également partager avec nos clients les bonnes pratiques qui en découlent et les écueils à éviter.
En conclusion, c’est quoi une bonne gestion de la dette du Système d’Information ?
C’est une dette connue, décidée et assumée, suivie et associée à un plan de réduction identifié et piloté!
Projexion est un cabinet de conseil en transformation et en architecture des systèmes d’information. Nous mettons à votre disposition un collectif d’expertises qui regroupe des consultants avec des profils variés, en particulier autour de l’architecture IT, de la gestion de projets et de l’accompagnement au changement.Envie de découvrir nos offres pour intégrer les technologies comme leviers de transformation ?
Soyez averti(e) de nos prochains évènements et publications via LinkedIn !
