Migration SI legacy : les erreurs à éviter en tant que DSI

Il y a quelques temps, la team AXOPEN a pris le temps de réfléchir au sujet de l'architecture SILe SI désigne le système d'informations d'une organisation. à l'ère de l'IA. Si c'est un sujet que vous souhaitez creuser (ou que vous préférez nous écouter plutôt que de nous lire) n'hésitez pas à aller voir l'épisode ! En attendant, c'est parti pour quelques conseils sur la migration d'un SI legacy.

Le mythe du legacy "intouchable"

En tant que DSILa DSI est la direction des systèmes d'informations d'une organisation., quand on arrive dans une organisation avec un gros legacy sur les bras, il se passe quelque chose de prévisible : cinquante personnes vont vous expliquer que c'est impossible à changer. Que c'est trop vieux, trop complexe et surtout trop critique. Même si on peut comprendre qu'il y a parfois des peurs et des réticences quand on parle de migration SI legacy, le problème ici, c'est que ce discours finit par s'auto-réaliser...

Au fil des années, il est même intégré à la culture d'entreprise, et le phénomène est amplifié. Le legacy devient alors un monument que personne ne touche, entouré d'une sorte de vénération du passé, comme si le fait qu'il soit vieux le rendait magique ! C'est cette illusion qu'il faut déconstruire en premier :)

Dette technique et migration SI legacy : de quoi parle-t-on vraiment ?

Un legacy, dans la réalité d'une DSI, c'est une application et des données dans une base de données, pas une entité mystique. Ce qui rend un legacy difficile à manipuler, c'est rarement sa complexité intrinsèque. C'est la dette technique accumulée au fil des années : des dizaines de développeurs successifs, des rustines empilées les unes sur les autres, des règles métier enfouies dans le code que plus personne ne sait expliquer. Un sac de nœuds oui, mais un sac de nœuds qu'on peut défaire, on vous le promet (Même un As/400!) !

Un système de gestion de commandes, une chaîne de facturation ou encore une gestion des stocks : ces domaines fonctionnels sont connus et ont déjà été migré des centaines de fois. Ça peut représenter plusieurs applications de tailles différentes et prendre plusieurs années, mais c'est loin d'être infaisable.

Pour prendre une métaphore : migrer un legacy, c'est comme arracher un pansement. Ça fait mal, c'est inconfortable, mais après on repart sur des bases saines. La nuance, c'est qu'on n'arrache pas un SI d'un seul coup, mais ça, on y reviendra plus loin dans l'article !

L'erreur à éviter n°1 : vouloir de l'iso-fonctionnel parfait

C'est la demande la plus fréquente en migration d'un SI legacy : "On veut de l'iso-fonctionnel, refaire exactement ce qu'on avait." En théorie, c'est rassurant, mais dans la réalité : grosse erreur !

Dès les deux premiers écrans, le métier commence à corriger le tir : ce processus était trop lourd, on enlève cette étape ; il nous faut deux champs supplémentaires qu'on n'avait pas avant. L'iso-fonctionnel parfait est une fiction, et courir après cette fiction revient à reproduire fidèlement les problèmes du passé dans un système neuf.

C'est là qu'est le vrai danger : si demain l'IA devenait capable de réécrire automatiquement un legacy dans un nouveau langage (et on en est peut-être pas si loin), elle produirait exactement le même résultat fonctionnel : les mêmes nœuds, les mêmes logiques simplement transposés dans une technologie moderne. Oui, ce code serait neuf, le problème resterait entier, mais ce n'est pas ce qu'on veut. Migrer, c'est l'occasion de repenser, pas de recopier !

L'erreur à éviter n°2 : vouloir tout refaire d'un coup

L'autre grand classique, c'est le projet de refonte totale. On a identifié le problème, on a l'énergie, on a (parfois) le budget, alors on décide de tout remettre à plat en une seule fois. Nouvelle architecture et nouvelle stack : sur le papier, ça fait envie ! Mais c'est rarement ce qui se passe dans la réalité.

Ces grands projets de transformation ont tendance à s'étirer dans le temps et à se complexifier, tout ça en accumulant les compromis au fil des mois. Et pendant ce temps, le legacy tourne toujours, les équipes jonglent entre l'ancien et le nouveau, et la dette technique s'accumule des deux côtés à la fois. Souvent ce n'est pas un problème d'ambition mais plutôt de périmètre. Vouloir tout traiter en même temps, c'est souvent ne rien terminer pour de bon.

La bonne approche pour moderniser son SI legacy : converger, pas tout refaire

Refaire tout d'un coup est une illusion. Par contre, on peut converger ! Une application a un cycle de vie : conception, développement, maintenance, et à terme, fin de vie. L'idée est de planifier cette convergence sur l'ensemble du parc applicatif, en définissant un cap : des bonnes pratiques communes, des standards d'organisation, une vision partagée, en laissant chaque brique évoluer naturellement vers ce cap au fil de son cycle.

On vous l'accorde, c'est un peu moins spectaculaire et ça fait moins effet en comité de direction. Mais c'est ce qui fonctionne vraiment : avancer un peu tout le temps, plutôt que de tout geler pendant trois ans dans l'attente d'une refonte totale qui ne viendra jamais tout à fait comme on l'avait imaginée.

Il faut accepter que ce ne soit pas parfait. Si on n'accepte pas l'imperfection, on n'avance pas. On reste bloqué, à se répéter que c'est encore plus compliqué, encore plus compliqué, encore plus compliqué.

Migration SI legacy et perte de connaissance métier : le vrai risque oublié

Il y a une raison profonde pour laquelle les migrations font peur, au-delà de la complexité technique : on a souvent perdu la connaissance des vraies règles métier encodées dans le logiciel. La réalité du terrain est passée par là et les équipes ont tourné, certains développeurs sont partis, et personne ne sait plus vraiment pourquoi tel calcul fonctionne ainsi ou pourquoi telle étape existe dans ce processus. Faire un migration de son SI legacy dans ce contexte, c'est un peu avancer à l'aveugle !

Encore une fois, la réponse n'est pas de documenter en urgence avec l'IA, et ce n'est pas non plus de s'en remettre à la mémoire imparfaite de ceux qui restent.

La vraie réponse, c'est de repartir du métier. Posez la question directement :

• Qu'est-ce que vos équipes ont besoin pour travailler ?
• Quels processus sont indispensables ? \n

Quand une partie de la connaissance est perdue, on reconstruit à partir du besoin réel, pas à partir de ce qui existait avant. Et souvent, on réalise qu'on n'avait pas besoin de tout ce qu'il y avait avant ;)

Pour aller plus loin dans votre migration SI legacy

La migration legacy, c'est rarement le chantier le plus glamour d'une DSI, mais c'est souvent celui qui débloque tout le reste. Le pansement doit être arraché un jour, alors autant que ce soit avec méthode plutôt que dans la panique !

Et si vous voulez aller plus loin sur le sujet, ou que vous préférez écouter plutôt que lire, la team AXOPEN a consacré un épisode entier à l'architecture SI à l'ère de l'IA, c'est par ici !