Systèmes legacy : votre plus grand risque IT non détecté (et comment le maîtriser)

Il existe une croyance tenace dans beaucoup d'organisations : un système qui tourne depuis quinze ans sans incident majeur, c'est un système fiable. Il a fait ses preuves. On peut lui faire confiance.

C'est fréquemment le contraire. Un système qui n'a pas été modifié depuis longtemps est souvent un système dont plus personne ne comprend vraiment le fonctionnement, dont la documentation date d'une autre époque. Et les quelques personnes qui en avaient la maîtrise sont parties ou s'apprêtent à partir.

C'est ça, la dette technique silencieuse. Pas le bug spectaculaire qui fait planter un serveur en pleine nuit. Le danger invisible qui grandit doucement jusqu'à ce qu'il devienne ingérable.

Pourquoi un système legacy peut être un risque invisible

Un système legacy risqué ne se résume pas nécessairement à un ancien COBOL des années 80. Il peut s'agir d'une application Java de 2013 dont le principal architecte a quitté la société. Un logiciel pour lequel l'éditeur a arrêté le support. Une infrastructure dont personne n'ose toucher les dépendances parce qu'« on ne sait pas ce qui va se casser ».

Ce point final est le signal d'alarme le plus sous-estimé. Lorsqu'une équipe déclare « on ne touche pas à ce module », il s'agit rarement de précaution. C'est presque toujours le symptôme d'un système que plus personne ne maîtrise vraiment et donc que personne n'est en mesure de faire évoluer en sécurité.

Ce que ça change pour une direction : un système non maîtrisé, c'est un risque non chiffré. Et un risque non chiffré ne se pilote pas, il se subit.

Trois risques majeurs pour les directions

Le risque de la personne-clé

Dans beaucoup d'organisations, une ou deux personnes concentrent la connaissance réelle d'un système critique. Non pas grâce à une documentation complète, mais par accumulation de connaissance implicite au fil des années. Quand elles partent, cette connaissance part avec elles.

Le risque réglementaire

RGPD, NIS2, DORA pour le secteur financier : ces réglementations supposent une capacité à auditer, tracer et modifier les systèmes concernés. Un système legacy mal documenté rend cet exercice difficile, parfois impossible. Ce n'est plus seulement un problème technique : c'est une exposition directe pour les dirigeants.

Le danger d'un créneau manqué

La modernisation d'un système legacy se prépare. Elle ne s'improvise pas dans l'urgence d'une défaillance ou d'un audit défavorable. Les organisations qui attendent d'y être forcées paient le prix fort en délais, en coûts, et en risque opérationnel pendant la transition.

La question n'est pas « est-ce qu'on va devoir migrer ? ». C'est « est-ce qu'on choisit le moment ou est-ce qu'il s'impose à nous ? »

Quand et comment migrer un système legacy

Nous avons travaillé sur la migration des systèmes critiques de la Direction Générale des Finances Publiques : 40,7 millions de contribuables, des décennies de code COBOL, une contrainte absolue de continuité de service.

Ce qui a rendu ce projet possible, c'est d'abord la capacité à comprendre l'existant avant de toucher quoi que ce soit. Comprendre non seulement ce que le code fait mais pourquoi il le fait ainsi, quelles règles métier y sont enfouies, quels comportements implicites y sont encodés depuis des années. C'est la partie que la plupart des acteurs bâclent. Et c'est précisément là que les migrations échouent.

Évaluer et prioriser vos systèmes legacy

La révision intégrale n'est pas nécessairement la solution au risque legacy. Dans la plupart des situations, il n'y a pas d'urgence.

La première étape n'est pas technique : dresser la liste de vos systèmes legacy pour lesquels une interruption de 48h poserait un vrai problème. Pour chacun, trois informations suffisent : qui l'a développé, qui le maintient aujourd'hui, quand il a été audité de façon indépendante pour la dernière fois. Cette liste, la majorité des organisations ne l'ont pas à jour.

Vient ensuite la hiérarchisation : tous les systèmes anciens ne présentent pas le même niveau de risque. Certains méritent une intervention rapide. D'autres peuvent attendre, à condition de documenter l'existant et d'identifier les dépendances critiques.

C'est exactement ce que nous faisons chez Titagone, en lien direct avec la fiabilité logicielle de vos systèmes. Sans alarmisme, sans refonte vendue avant d'avoir compris le problème.

Questions fréquentes sur les systèmes legacy

Qu'est-ce qu'un système legacy ?

Un logiciel toujours en production, dont la technologie ou la documentation ne répond plus aux standards actuels. Il ne s'agit pas d'âge, mais de maîtrise. Un système de 20 ans soigneusement entretenu peut présenter moins de risques qu'un système de 5 ans mal documenté.

Faut-il tout reconstruire pour se débarrasser d'un système legacy ?

Non, c'est souvent la mauvaise décision à prendre. Une migration progressive, module par module, donne de meilleurs résultats qu'une refonte complète. C'est l'approche qu'on a suivie avec la DGFiP : une transformation structurée sans interruption de service.

Comment évaluer le risque d'un système legacy sans avoir de compétences techniques ?

Trois interrogations : qui a une connaissance approfondie de ce système et que se produira-t-il s'il disparaît ? Quand a eu lieu la dernière vérification indépendante ? Que se produit-il s'il s'arrête pendant 48 heures ? Si les réponses manquent de clarté, le risque est réel.

Quel est le coût de la modernisation d'un système legacy ?

Ce n'est pas la bonne question. Mieux vaut se demander : quel est le coût de l'absence de modernisation ? Maintenance d'un code que personne ne maîtrise, recrutement impossible sur des technologies obsolètes, exposition réglementaire croissante. Les coûts de l'inaction dépassent presque toujours ceux d'une migration bien conduite.

La question pertinente n'est pas « doit-on migrer ? » C'est « de quelle manière ? »

C'est le problème qu'on a résolu avec la DGFiP. Du code COBOL en production depuis des décennies, 40,7 millions de contribuables concernés et une contrainte simple : on ne coupe pas le service. La migration s'est faite progressivement, sans bruit. 37 millions de déclarations fiscales par an tournent dessus aujourd'hui.