« On ne peut pas, c’est du legacy. » La formule finit parfois par fermer la discussion avant même qu’elle commence. Pourtant, si ce système est encore là, c’est souvent qu’il rend un service que l’entreprise ne sait pas facilement remplacer.
Le legacy m’intéresse justement pour cette raison : il porte une partie de la mémoire de l’entreprise. Avant de le jeter, je veux comprendre ce qu’il sait faire, ce qui le rend fragile et les règles métier qu’il faudrait absolument retrouver demain.
En informatique, le legacy désigne les systèmes hérités sur lesquels l’entreprise continue de s’appuyer. Il peut s’agir d’une application, d’une infrastructure ou d’un ensemble de traitements construit au fil des années. Le mot anglais signifie « héritage ». Dans un SI, cet héritage contient souvent des règles métier qui restent indispensables.
Un logiciel ancien peut rendre un service fiable. Un logiciel récent peut déjà être difficile à maintenir si personne ne comprend son fonctionnement. Pour décider, il faut donc examiner ce que le système apporte, les risques qu’il expose et les possibilités réelles de le faire évoluer.
Pourquoi le legacy reste en place
Un système survit souvent parce qu’il fait davantage que ce que sa description laisse penser. Il traite les exceptions commerciales, les formats de fichiers d’un partenaire ou une règle de clôture connue de quelques personnes. Remplacer l’écran ne suffit pas à retrouver ces comportements.
Au fil des départs et des modifications, une partie de cette connaissance peut se perdre. Les équipes continuent alors à utiliser le système sans pouvoir expliquer toutes ses règles. La difficulté du remplacement vient autant de cette mémoire dispersée que de la technologie elle-même.
Distinguer héritage et obsolescence
L’obsolescence concerne une capacité qui se dégrade ou devient insuffisante : composant qui n’est plus maintenu, environnement difficile à sécuriser, compétence devenue rare ou fonctionnalité qui bloque l’activité. La dette technique désigne, quant à elle, les compromis dont la correction ou la maintenance pèsera sur les évolutions futures. Les trois notions peuvent se recouvrir, sans être équivalentes.
Cette distinction change l’arbitrage. Un système stable et compris peut être conservé. Un composant critique sans possibilité de reprise nécessite une action, même s’il est récent. Présenter tous les systèmes anciens comme un coût incontrôlable conduit à mal prioriser les investissements.
Évaluer le risque avant de choisir la solution
Je commencerais par vérifier cinq points : les activités dépendantes, la possibilité de rétablir le service, les compétences disponibles, les limites d’évolution et le coût complet. Chaque point doit s’appuyer sur une observation. Une sauvegarde existe-t-elle seulement sur le papier ou a-t-elle été restaurée ? Une interface est-elle documentée ou dépend-elle d’une personne ?
Les métiers doivent participer à l’analyse. Ils peuvent distinguer les règles indispensables des habitudes devenues inutiles. La direction peut alors comparer le risque de rester, le risque de migrer et les autres besoins qui mobilisent déjà les équipes.
Conserver sécuriser moderniser ou remplacer
Conserver peut être une décision rationnelle si le système répond au besoin et si son exploitation est maîtrisée. Sécuriser consiste à réduire une dépendance précise : documenter une règle, tester la reprise, préparer une transmission ou corriger un point de fragilité.
Moderniser peut passer par une interface mieux maîtrisée ou l’extraction d’une fonction. Remplacer devient pertinent lorsque le besoin évolue fortement ou que les risques ne peuvent plus être réduits à un niveau acceptable. Ces options peuvent s’appliquer à des parties différentes du même ensemble.
Préparer une transition vérifiable
Une migration progressive permet, dans certains contextes, de remplacer des fonctions par étapes et de comparer leurs résultats avec l’existant. Microsoft décrit cette démarche dans le modèle Strangler Fig. Elle suppose de pouvoir isoler les fonctions et gérer la coexistence. Ce n’est pas une recette applicable à tous les systèmes.
Avant chaque bascule, il faut définir les règles à préserver, les données à réconcilier, les critères de validation et la conduite à tenir en cas d’échec. La sortie de l’ancien système fait partie du projet. Sans date ni conditions de retrait, la coexistence peut devenir durable et augmenter les coûts.
Ce que l’IA peut apporter
L’IA peut aider à explorer du code ou à produire une première documentation. Les hypothèses doivent être vérifiées avec les équipes et par des tests. Reconstituer une règle à partir du code ne prouve pas qu’elle correspond au besoin actuel. Générer un remplacement rapidement ne prouve pas non plus qu’il couvre les exceptions importantes.
Le premier travail utile consiste à identifier un système critique dont la connaissance ou la reprise est fragile. C’est sur ce point que la direction et la DSI peuvent décider d’une action concrète. Si le sujet bloque votre transformation, nous pouvons commencer par cet arbitrage plutôt que par un programme de remplacement de tout le SI.
Questions fréquentes
Un logiciel ancien est-il forcément un problème ?
Non. Il faut examiner sa valeur, son support, sa sécurité, sa reprise et les compétences disponibles. Un système ancien et maîtrisé peut être conservé. Son âge seul ne justifie pas un remplacement.
L’IA peut-elle réécrire tout le legacy ?
Elle peut aider à explorer le code et à préparer certains travaux. Il reste à vérifier les règles métier, les exceptions et le fonctionnement en production. La vitesse de génération du code ne démontre pas l’équivalence du service.
Pour approfondir
Votre entreprise a grandi plus vite que son SI, ou un choix d’outil bloque la transformation ? Je peux prendre ce sujet avec vous.
Voir mes interventions auprès des dirigeants et DSI
Ping : Transformation digitale, les racines du succès - David LANGLADE