Legacy et dette technique : comment éviter les crises, sans faire exploser les coûts ?

Annonces fracassantes autour de l'IA, érosion des compétences, externalisation grandissante des systèmes d’information : le legacy et la dette technique traversent les décennies, mais le contexte actuel leur donne une acuité nouvelle. Fondateur et CEO de CobolCloud, spécialiste de la remise sur trajectoire des applications historiques et de la modernisation continue des systèmes critiques, Stéphane Croce défend une thèse presque iconoclaste : la « modernisation » devrait être bannie du vocabulaire de la DSI, au profit d'une gouvernance qui anticipe au lieu de subir. Il revient sur la situation en amont de l'atelier organisé par Alliancy sur le thème : "Comment moderniser un système critique sans perdre la maîtrise de ce qui fait sa valeur ?"

Pourquoi la thématique de la transformation du legacy et de la lutte contre la dette technique est-elle toujours autant d'actualité en 2026 ?

Nous vivons dans un environnement marqué par un flot continu d'annonces technologiques. Après le cloud, l'intelligence artificielle est devenue le nouveau sujet incontournable. Les promesses sont nombreuses, les discours parfois fracassants, mais il faut prendre du recul. Notre expérience nous a appris que ces cycles se sont déjà produits plusieurs fois. De grandes avancées technologiques ont chaque fois été accompagnées de nouvelles offres, portées notamment par les grands fournisseurs et les ESN. Il faut se demander si ces évolutions servent réellement les grandes entreprises et leurs utilisateurs, ou si elles entretiennent aussi des mécanismes de captation.

Le sujet du legacy est précisément au croisement de ces interrogations. Les systèmes d'information sont vivants, mais leur évolution est trop souvent subie. On attend qu'une application devienne difficile à maintenir ou qu'une crise survienne pour intervenir. Nous devrions plutôt parler de gouvernance, de réinvention et de réarchitecture. La modernisation ne doit jamais être subie, elle doit être anticipée.

Comment distinguer la partie du legacy d'un système d'information complexe qu'il convient de moderniser, de celle qu'il vaut mieux préserver ?

Il faut d'abord sortir de l'opposition dogmatique entre « ancien » et « moderne ». Certaines applications fonctionnent parfaitement depuis des décennies. Leur valeur ne réside pas nécessairement dans leur technologie, mais dans les règles métier qu'elles portent et dans leur capacité à faire fonctionner une banque, une assurance ou une autre organisation selon ses besoins spécifiques.

La première question est donc de comprendre ce que fait réellement le système, comment ses différentes parties sont imbriquées et quelle trajectoire l'entreprise souhaite emprunter. Il faut pouvoir déterminer ce qui peut être conservé, ce qui doit être sécurisé et ce qui peut évoluer à court ou moyen terme. Une réécriture complète n'est pas systématiquement pertinente. Même lorsqu'on décide de repartir de zéro, il faut avoir compris les règles métier et les dépendances de l'existant. Sinon, on risque de reconstruire un système qui reproduira les mêmes difficultés quelques années, voire quelques mois plus tard.

Toutes les entreprises sont-elles confrontées à une érosion de leur « savoir-faire SI » aujourd'hui ?

C'est un phénomène extrêmement répandu, y compris dans les organisations les mieux structurées. On entend souvent dire qu'il n'y a plus de compétences COBOL, PL/I ou mainframe. Mais, derrière ces constats, le véritable problème est souvent que les équipes ne savent plus expliquer comment les applications fonctionnent.

Historiquement, lorsqu'une application était développée, quelques personnes en connaissaient l'ensemble du fonctionnement. Puis ces personnes sont parties, leurs connaissances ont été transmises à d'autres, qui ont elles-mêmes quitté l'organisation. À chaque changement de génération, une partie du savoir disparaît. On peut estimer cette perte à 15 à 20 % des connaissances à chaque transmission. Au fil du temps, les zones d'ombre deviennent des pans entiers d’inconnu.

C'est un cercle vicieux : moins on comprend une application, plus on risque de produire de la dette technique ; et plus cette dette augmente, moins on comprend le système. Il faut inverser cette dynamique en faisant de chaque modification et de chaque évolution une occasion d'enrichir la connaissance collective.

Comment un DSI peut-il aborder ces questionnements profondément techniques au niveau du Comex ?

Il faut justement sortir du seul discours technique pour replacer le système d'information dans la trajectoire globale de l'entreprise. Les applications sont le résultat de décennies de traduction des processus métier en programmes informatiques. Elles portent donc une partie essentielle du fonctionnement de l'organisation.

Un DSI doit pouvoir expliquer que la question n'est pas simplement de remplacer une technologie ancienne, mais de garantir la capacité de l'entreprise à faire évoluer ses activités, à innover et à assurer la continuité de ses services. C'est particulièrement important dans des secteurs où cette continuité répond à une véritable mission sociale.

Il faut également faire comprendre que l'absence de décision a un coût et accroît les risques. Plus une organisation attend, plus les interventions deviennent complexes et urgentes. L'enjeu est donc de construire une vision à long terme, plutôt que d'enchaîner les opérations de rattrapage.

Qu'apporte concrètement l'IA à cette réflexion en 2026 ?

L'IA ouvre des perspectives considérables. Elle pourra analyser des systèmes complexes, reconstituer les règles métier, comprendre les dépendances et, à terme, proposer de redévelopper certains modules dans d'autres langages. Mais il faut distinguer ce qui est annoncé de ce qui est réellement démontré. Aujourd'hui, beaucoup d'acteurs promettent des résultats, mais les références concrètes restent encore limitées. C'est probablement une question de temps avant que ces capacités progressent fortement.

Notre conviction est que l'IA doit notamment permettre de reconstituer la mémoire applicative. Chez CobolCloud, nous travaillons à récupérer et à centraliser les informations qui racontent la vie d'une application : les tickets de bugs, les évolutions, les mises en production, les données issues des environnements CI/CD, mais aussi les documents historiques, parfois archivés depuis plusieurs décennies.

Nous constituons ainsi un « evidence store », un ensemble de connaissances qui pourra ensuite être exploité par l'IA. Celle-ci n'est pas considérée comme une génératrice de vérité : elle doit s'appuyer sur des éléments factuels, documentés et des preuves vérifiables. L'objectif est de ne plus perdre les informations essentielles au fil de la vie des applications.

Quelles méthodes fonctionnent le mieux pour éviter de recréer en permanence de la dette technique ? Est-ce un sujet de plateforme ou de gouvernance ?

Il n'existe pas aujourd'hui de modèle universellement établi. Les dispositifs doivent donc rester modulaires, adaptables et réversibles, afin de ne pas enfermer les organisations dans de nouvelles impasses. Nous défendons notamment l'idée d'une sorte de boîte noire pour chaque application, capable d'enregistrer automatiquement les événements importants de son existence. Il faut pouvoir retrouver ce qui s'est passé à une date donnée, comprendre pourquoi une évolution a été réalisée et disposer de la mémoire des décisions prises. Cette collecte doit être la plus automatisée et la moins contraignante possible pour les équipes.

La plateforme technique est un moyen, mais elle ne suffit pas. Il faut surtout organiser durablement la conservation et la transmission des connaissances. Car une application développée aujourd'hui en Java, Go ou C# peut devenir un nouveau legacy dans quelques années si personne n'organise son évolution et son avenir.

Quelles sont les implications pour la gestion des prestataires technologiques, après quinze ans de forte externalisation des systèmes d'information ?

Nous assistons à un télescopage de plusieurs cycles technologiques et commerciaux. Avant l'IA, le cloud occupait le devant de la scène. À chaque fois, certains acteurs expliquent aux entreprises qu'elles sont dépassées et qu'elles doivent absolument changer de modèle. Mais ces discours répondent aussi à des objectifs économiques. Les grandes migrations sont coûteuses et les promesses ne sont pas toujours tenues.

La question de la maîtrise devient donc centrale, y compris sous l'angle de la souveraineté. Nous avons longtemps accepté une forte dépendance à des fournisseurs technologiques extérieurs, en considérant que les solutions proposées ailleurs étaient nécessairement meilleures. Il est aujourd'hui légitime de réexaminer ces choix.

Notre approche consiste à travailler en coopération avec les clients, avec un objectif assez paradoxal pour un prestataire : les rendre autonomes. Ils doivent pouvoir décider eux-mêmes de la trajectoire technologique qu'ils souhaitent suivre sur les dix, quinze ou trente prochaines années.

Une entreprise peut-elle anticiper ces changements plutôt que de seulement réagir à une crise liée à sa dette technique ? Et à quel coût ?

C'est précisément ce qu'il faut organiser. Nous sommes souvent sollicités lorsque les difficultés sont déjà devenues urgentes. Les métiers sont sous pression, les équipes manquent de temps et de ressources, et il devient difficile de les mobiliser sur des travaux de fond dont elles ne perçoivent pas toujours immédiatement la criticité. Pour répondre à cette situation, nous proposons des petites équipes commando de trois à cinq personnes, qui travaillent avec les ressources du client. Leur rôle est de comprendre l'existant, de définir plusieurs trajectoires possibles et de préparer les sous-projets nécessaires. Cela permet de travailler en avance de phase, tout en tenant compte des urgences opérationnelles.

Cela ne signifie pas nécessairement engager immédiatement de grands programmes de transformation, avec des budgets considérables. On peut commencer progressivement, avec des équipes réduites et un dispositif opérationnel rapidement. D’ailleurs, notre plateforme se nourrit au fur et à mesure des informations collectées. Nous disposons notamment d'un système miroir de l'architecture du client, qui permet de travailler à distance et de rester très réactifs. Nous cherchons aussi à mobiliser le moins possible les experts internes, dont le temps est déjà très contraint, tout en nous appuyant sur les personnes qui connaissent le mieux les applications. L'enjeu est de construire progressivement un patrimoine de connaissances exploitable et de donner aux entreprises les moyens de piloter elles-mêmes leur avenir technologique.