La solution pour lutter contre le legacy informatique

Voici quelques années que le terme « legacy » « traine ses guêtres » dans de nombreuses sociétés.

64% des DSI considèrent le legacy comme une forte barrière à l’évolution vers un système d’information moderne.

IDG Reseacg

Comme dans cette statistique, le « legacy » est souvent utilisé comme excuse, ou frein à l’accélération digitale. Il me parait nécessaire d’apprendre à mieux le connaitre afin de travailler plus efficacement avec lui.

« Legacy » qui es-tu ?

Ca ne vous aura pas échappé « legacy » (héritage en anglais) appartient au passé. Tout du moins, nous aimerions que celui-ci appartienne au passé mais il est toujours là, à embêter nombre de développeurs et de DSI.

« Le therme legacy se dit de tous les logiciels, systèmes informatiques, matériels, lignes de codes… en place depuis longtemps dans l’entreprise. »

Le « legacy » apparait dès lors que nous considérons qu’il existe de nouvelles technologies meilleures capables de le remplacer.

Mais chez nous NON il est rentré ici « TRANQUILLE » à « PRENDRE LA TETE » à tout le monde. La société ne profite donc pas de ces systèmes plus modernes (plus efficaces) et nous restons avec notre « legacy » 😤

 

Alors, pourquoi ce « legacy » est resté ?

S’il nous pose autant de problèmes, pourquoi ce « legacy » n’a t-il pas déjà été jeté aux oubliettes ?

Le « legacy » est souvent resté pour de très bonnes raisons.

La plupart du temps, il cache une « brique » technique complexe, pleine de subtilités fonctionnelles que personne ne maitrise réellement.

Pourquoi personne ne le maitrise réellement ? Et bien car le temps et le turnover ont fait leur œuvre. Les personnes qui ont créé une partie des règles de gestions ne sont plus là. Elles ont été remplacées par d’autres qui ont réalisé quelques ajouts sans tenir à jour de documentation…

Voilà donc pourquoi le « legacy » est toujours là ! En quelques sorte il est la mémoire d’une partie de l’entreprise et représente une valeur pour celle-ci.

Tout le monde sait que ce système pourrait être mieux avec de nouvelles technologies, mais personne ne veut franchir le pas. Car la taille projet, la carence en documentation et le manque de compétences sur le sujet font craindre d’énormes régressions.

Ces régressions pourraient entrainer une perte de valeur, des couts non prévus, des retards de projets, de l’insatisfaction chez les utilisateurs… Bref l’horreur pour un Directeur informatique.

Finalement pourquoi le « legacy » est un problème ?

Si celui-ci a autant de valeur et est aussi important pour la société pourquoi est-ce un problème ?

Le « legacy » pose plusieurs problèmes de taille.

Le premier est le coût. Maintenir de vieux systèmes est un « trou sans fond », année après année celui-ci coûte de plus en plus cher.

Ensuite nous avons la sécurité. Plus les solutions sont obsolètes plus elles deviennent vulnérables.

Enfin il y a, les compétences. Plus votre « legacy » va prendre de l’âge moins vous arriverez à trouver des compétences capables de le maintenir et/ou de le faire évoluer.

On a tous entendu parler de ces consultants « vieux systèmes » qui gagnent des fortunes.

Et bien voilà une des conséquences de ces risques.

Parlons maintenant de la solution.

Pour résoudre notre problème de « legacy » il faut revenir sur les causes.

• Un manque de documentation.
• Des compétences perdues avec le temps.
• Les processus non documentés ou trop complexes.
• Des cahiers des charges trop denses donc impossibles à maintenir.
• Un système technologiquement dépassé.
• …

Ce qui se cache là dessous c’est le combat entre les anciennes méthodes de gestion de projets (je pense notamment aux cycles en V) et notre monde moderne (emprunt d’agilité et de flexibilité).

Si vous continuez à utiliser ces méthodes de gestion de projets, vous êtes entrain (en ce moment même) de créer un nouveau « legacy » et ainsi de suite.

Vous l’aurez peut-être compris, pour régler notre problème de « legacy » il faut d’abord sortir du cercle vicieux de l’organisation en place.

Si vous suivez ce raisonnement il ne sera pas raisonnable de vouloir « gommer » ce legacy en recodant un système intégrant les mêmes fonctionnalités pour le déployer en mode « big bang ».

La bonne démarche serait de découper le système existant en briques fonctionnelles, puis de les coder une par une avec une nouvelle méthode d’organisation de projet. Plus proche des utilisateurs, plus enclin à évoluer…

Pour aller plus loin sur ce thème je vous invite à consulter l’article ci-dessous :

https://davidlanglade.com/management/methode-agile-jedi/