IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La plateforme IA de CoreStory cartographie, explique et propose des chemins de modernisation pour les applications critiques
Afin de transformer la dette technique en moteur d'innovation pour les entreprises

Le , par Stéphane le calme

15PARTAGES

11  0 
Moderniser des logiciels vieux de 40 ans sans tout casser : l'IA de CoreStory cartographie, explique et propose des chemins de modernisation pour les applications critiques
la startup veut transformer la dette technique en moteur d’innovation pour les entreprises

Les entreprises croulent sous le poids de leurs systèmes hérités, véritables bombes à retardement technologiques. CoreStory, une jeune pousse ambitieuse, promet de transformer cette dette technique en opportunité grâce à une plateforme d’intelligence artificielle capable de lire, comprendre et raconter le code. Un pari audacieux qui pourrait bouleverser la manière dont les DSI abordent la modernisation logicielle.

Quand la dette technique devient insoutenable, une IA tente de transformer l’héritage logiciel en capital d’innovation

La dette technique est devenue un fardeau colossal pour les entreprises. Systèmes bancaires conçus dans les années 70, plateformes aéronautiques bâties sur des langages quasi disparus, progiciels hospitaliers tenus ensemble par des patchs et du savoir oral… Autant de reliques numériques qui tiennent encore le monde debout, mais au prix d’une fragilité extrême. Chaque mise à jour est un pari, chaque migration une opération à haut risque. C’est dans ce contexte que CoreStory, une startup émergente de la scène technologique, promet une approche radicalement nouvelle avec sa plateforme d’intelligence de code alimentée par l’IA.

L’idée n’est pas simplement d’automatiser la traduction d’un langage vers un autre, ni de produire des rapports sur l’état des applications. CoreStory affirme pouvoir révéler la « vérité cachée » dans le code, en cartographiant non seulement les dépendances techniques, mais aussi les intentions métiers et les logiques historiques qui se sont perdues au fil des décennies. Une ambition qui, si elle se concrétise, pourrait changer profondément la manière dont les grandes organisations abordent la modernisation.

Les limites des approches traditionnelles de modernisation

Depuis plus de vingt ans, le marché regorge de solutions censées « sauver » les entreprises de leurs logiciels hérités. Traduction automatique de COBOL vers Java, outils de migration cloud, refactorisation semi-automatisée… Pourtant, la plupart de ces approches échouent sur le même obstacle : l’incapacité à comprendre réellement ce que fait le code et pourquoi il le fait.

Prenons l’exemple d’un programme COBOL utilisé par une banque. Le code peut contenir des dizaines de milliers de lignes qui gèrent des opérations critiques comme la compensation de chèques ou la gestion des risques. Le traduire en un langage moderne sans comprendre la logique métier sous-jacente, c’est risquer la catastrophe. Résultat : les projets échouent, les délais explosent, et les coûts deviennent ingérables.

CoreStory affirme contourner cet écueil en allant plus loin : son IA ne se contente pas de lire le code, elle tente de l’interpréter dans son contexte fonctionnel, de reconstruire la « narration » derrière l’architecture logicielle.

La plateforme CoreStory prend également en charge le code généré par l'IA tout en traitant les risques liés aux systèmes de type « boîte noire ». En intégrant le code nouvellement généré, qu'il soit produit par des assistants IA ou par de grands modèles linguistiques, dans son modèle d'intelligence, la plateforme élimine les angles morts et préserve la clarté afin de garantir que les équipes futures puissent facilement comprendre l'intention initiale derrière le code, et pas seulement le résultat final.

« Traditionnellement, les projets de modernisation étaient menés par des experts qui examinaient le code ligne par ligne, ce qui prenait généralement 18 mois ou plus », a déclaré le fondateur et directeur général Anand Kulkarni. « Notre approche basée sur l'IA permet à ces entreprises de repenser les exigences du code et des applications, en ajoutant davantage de fonctionnalités et de caractéristiques. CoreStory réduit les barrières à l'entrée et permet aux entreprises de réaliser des économies considérables. »


L’approche de CoreStory : extraire le sens, pas seulement les lignes

CoreStory est une jeune société technologique spécialisée dans l’intelligence de code pilotée par l’IA. Fondée en 2025, elle se positionne sur un marché crucial : la modernisation des systèmes logiciels hérités. Sa mission est de transformer des millions de lignes de code obsolètes mais critiques – souvent écrites dans des langages anciens comme COBOL ou Fortran – en actifs compréhensibles, exploitables et adaptés aux environnements modernes.

Contrairement aux solutions classiques qui se limitent à analyser ou traduire des programmes, CoreStory mise sur une approche “interprétative”. Son IA cherche à comprendre la logique métier et l’intention historique derrière les lignes de code. Le but n’est pas seulement de rendre visible la structure technique, mais aussi de « raconter » pourquoi le logiciel a été conçu de telle manière.

« Dans tous les secteurs, les organisations cherchent à transformer numériquement leur infrastructure, mais se rendent rapidement compte qu'elles manquent de connaissances historiques ou de contexte », explique Mike Lambert, directeur général de CoreStory. « CoreStory supprime ces obstacles grâce à une plateforme d'intelligence de code basée sur l'IA. En quelques jours, plutôt qu'en plusieurs mois, nous mettons au jour les exigences commerciales initiales cachées dans le code, puis nous fournissons des informations sur l'architecture et le code en vue de la modernisation. CoreStory transforme le code hérité en un atout stratégique afin que les entreprises puissent le comprendre à tous les niveaux. »

La promesse centrale de CoreStory repose sur trois piliers :
  1. Une analyse contextuelle profonde : L’IA est entraînée pour reconnaître non seulement des motifs techniques, mais aussi des intentions métiers. Par exemple, distinguer un module qui gère des calculs financiers d’un module qui gère des accès utilisateurs, et expliquer pourquoi ils ont été structurés de telle manière.
  2. Une cartographie « narrative » du code : Plutôt que de livrer des schémas incompréhensibles ou des milliers de pages de documentation générée, la plateforme produit une représentation intelligible de la logique interne. C’est comme si le code “racontait” enfin son histoire aux développeurs qui doivent le reprendre.
  3. Des scénarios multi-chemins de modernisation : Chaque entreprise a des contraintes différentes : certaines veulent tout migrer vers le cloud, d’autres préfèrent encapsuler des modules dans des microservices, d’autres encore veulent simplement stabiliser l’existant. CoreStory propose plusieurs routes possibles, avec une estimation des risques, des coûts et des délais.



Pourquoi cette innovation arrive au bon moment

Les chiffres parlent d’eux-mêmes : plus de 70 % des budgets IT sont encore engloutis dans la maintenance des systèmes hérités, au détriment de l’innovation. Pire encore, les experts capables de maintenir ces systèmes se raréfient. Les programmeurs COBOL partent à la retraite, et il est de plus en plus difficile de former de nouvelles générations à des technologies qui ne sont plus enseignées.

Dans le même temps, la pression concurrentielle pousse les entreprises à moderniser leurs plateformes plus vite : l’IA générative, le cloud, les architectures orientées données exigent des fondations logicielles capables de s’adapter. Or, les vieilles infrastructures freinent ces ambitions.

C’est précisément cet écart – entre urgence et impossibilité – que CoreStory veut combler. Sa plateforme se présente comme un accélérateur de transformation, permettant aux DSI d’oser des projets autrefois jugés trop risqués ou trop coûteux.


Les promesses pour les décideurs IT

Pour une direction informatique, la valeur d’un tel outil est multiple. D’abord, il réduit le temps nécessaire pour comprendre des systèmes complexes, en automatisant une partie du travail d’audit qui prenait parfois des mois. Ensuite, il offre une meilleure visibilité stratégique : plutôt que de subir les contraintes de la dette technique, les entreprises peuvent enfin envisager des choix rationnels, comparables et chiffrés.

Il y a aussi un enjeu culturel. Les développeurs qui travaillent sur du legacy ont souvent le sentiment d’évoluer dans une zone obscure, où chaque ligne modifiée peut avoir des conséquences imprévisibles. En rendant cette complexité intelligible, CoreStory peut redonner du sens et de la motivation aux équipes.

Un marché concurrentiel, mais ouvert aux ruptures

CoreStory n’arrive pas dans un désert. Les hyperscalers comme AWS, Microsoft ou Google proposent déjà des solutions de migration et de modernisation. De nombreux acteurs spécialisés existent également. Mais la plupart se concentrent sur des approches techniques, parfois utiles mais rarement complètes.

Le pari de CoreStory est donc de se différencier en proposant une couche d’intelligence supérieure. Si la plateforme réussit à tenir ses promesses, elle pourrait s’imposer comme un partenaire clé des grands projets de transformation numérique.

Cependant, la crédibilité se gagnera sur le terrain. Les clients attendront des preuves concrètes : robustesse, fiabilité, intégration avec les environnements existants, et surtout, une capacité réelle à réduire les délais et les coûts des migrations.

Entre confiance et scepticisme : les questions qui demeurent

Comme toute technologie émergente, l’approche de CoreStory soulève des interrogations. Peut-on vraiment faire confiance à une IA pour interpréter correctement la logique métier d’un code écrit il y a 30 ou 40 ans ? Comment valider la justesse des “narrations” produites par la plateforme ? Et que se passe-t-il si l’IA commet une erreur d’interprétation dans un système critique, par exemple dans la gestion des transactions financières ou des systèmes médicaux ?

Ces doutes sont légitimes, et ils devront être dissipés par des tests rigoureux, des partenariats pilotes et des retours d’expérience vérifiables.

Vers une nouvelle ère de la modernisation logicielle ?

Il est encore trop tôt pour dire si CoreStory réussira son pari. Mais une chose est sûre : le besoin est immense, et les entreprises n’ont plus le luxe d’attendre. Le code hérité n’est pas seulement un problème technique, c’est un enjeu économique, stratégique et même sociétal. Sans solutions innovantes, une partie du monde numérique risque de rester prisonnière de ses fondations obsolètes.

CoreStory se présente comme un pont entre le passé et l’avenir du logiciel. Si sa promesse se confirme, cette startup pourrait bien marquer une étape décisive dans la manière dont nous pensons et transformons notre patrimoine numérique.

Source : CoreStory

Et vous ?

L’IA doit-elle être considérée comme un assistant pour comprendre le code, ou peut-elle devenir un arbitre de décisions stratégiques en matière de modernisation ?

Les grandes entreprises doivent-elles encore investir dans la modernisation du legacy, ou serait-il plus rentable de repartir de zéro ?

Quels risques juridiques et sécuritaires peut entraîner une interprétation erronée de la logique métier par une IA ?

Peut-on imaginer un futur où les DSI n’auront plus besoin d’équipes spécialisées legacy, parce qu’une IA comme CoreStory rendra ce savoir obsolète ?
Vous avez lu gratuitement 208 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 23/09/2025 à 23:48
L'automatisation du refacto est un de mes objectifs long terme. Donc autant dire que ce genre de chose vole très près des questions que je me pose en permanence... Et je dois dire que je suis assez dubitatif.

Quand je vois ce schéma :
Citation Envoyé par Stéphane le calme Voir le message
[/CENTER]
Qu'y a t'il de nouveau ? Le code repo est le point de départ. Static code analysis et quality checking, on en fait depuis des années. Ce qui est nouveau c'est le LLM inference based analysis et le intelligence model.

Le LLM inference based analysis, si son nom ne trompe pas, est un LLM. Ce qui veut dire qu'il est voué à avoir des hallucinations. Si c'est juste pour donner un sens au code, pourquoi pas. Le soucis est que ça semble ensuite alimenter le quality checking. Mais dans quelle mesure ? Car si on compte beaucoup dessus... et bien on compte beaucoup sur un processus non fiable par nature. Donc déjà, ça ne donne pas envie. Si au contraire l'influence est superficielle, alors est-ce vraiment une valeur ajoutée ? Il semble difficile de se positionner en faveur de cette partie du schéma, donc.

L'intelligence model... et bien je ne sais pas ce que c'est. Si c'est du propriétaire, je ne sais pas quoi en attendre. Notamment, pourquoi devrais-je lui faire confiance pour me sortir un réel équivalent (ou de bonnes instructions pour que je produise un équivalent) de mon système legacy ? À moins de l'utiliser et de le constater, je ne le saurais pas.

Enfin, j'ai regardé la vidéo... Et ça ne m'a rien dit d'intéressant. Surtout quand le graphe le plus compliqué qu'elle montre est ça :

Je sais pas pour d'autres qui ont du faire face à du legacy qui fait s'arracher les cheveux, mais moi, une archi aussi simple, je ne suis pas convaincu que ça vaille le coup de perdre du temps à se former à ou nouvel outil juste pour en faire la migration.

Pour comparatif, pour ma mission actuelle, le diagramme d'architecture haut niveau (pas un niveau tellement bas qu'on parlerait d'un simple "merchant name and city input" comme ci-dessus) c'est :
- 5 users
- 10+ interfaces d'accès
- 10+ points d'entrée (APIs, protocoles, formats)
- 3 sources de données (DB & cie)
- 20+ services
- certains éléments uniques sont des abstractions représentant un ensemble d'éléments propriétaires spécifiques

Pour se ramener au même niveau d'abstraction que le schéma ci-dessus, on ne parlerait que d'un seul service qui pour le coup se décomposerait en une bonne centaine de blocs à lui tout seul.

Donc ils se vendent, apparemment (à confirmer), sur des illustrations montrant des projets de l'ordre de grandeur d'un prototype. Or on a déjà échangé ici à ce sujet, et on sait que l'IA aide bien sur les tâches de protoypage, mais quand il s'agit de travailler sur des choses plus poussées, on attend encore l'exemple à succès... en s'occupant avec les nombreux exemples d'échecs et retours en arrière.

Suis-je pessmiste pour autant ? Pas tout à fait. Car s'il y a effectivement une chose qui est primordiale pour refactorer correctement, c'est de comprendre le métier. Et ça, ce n'est pas l'analyse statique de code qui le fournit. Par contre, un LLM peut effectivement aider dans ce sens, justement car il permet de faire le lien entre les mots, et donc entre les langages... y compris entre un langage de programmation et un langage naturel. Donc l'utilisation d'un LLM est tout à fait pertinente, mais son insertion dans le diagramme convainc difficilement car trop simpliste. Il faudrait plus de détails sur comment ils s'y prennent, car on n'aurait trop vite fait de mettre un LLM dans la boucle juste parce que ça peut générer des trucs qui ressemblent à ce qu'on veut, mais sans réelle validation du résultat autre que "test and see".

Maintenant comment j'approcherai le problème.

Le contexte :
- refactorer du code veut dire changer sa structure sans changer son comportement
- pour confirmer que le comportement ne change pas, il faut une bonne batterie de tests
- pour écrire une bonne batterie de tests, il faut une bonne compréhension du besoin
- pour avoir une bonne compréhension du besoin dans un cadre legacy, il faut un paquet de sachants ou de documentation encore là (turnover minimal et changement de plateformes au cours du temps sans pertes... un challenge).

Manque de bol, dans ma mission, on manque à tous les niveaux. Je dois donc repasser à travers chaque strate ci-dessus et c'est pas de la tarte. Mais c'est pas le sujet.

L'approche :
- commencer par mesurer la couverture de test pour se rendre compte des dommages (et encore, la couverture dit seulement ce qui est exécuté pendant les tests, pas ce qui est effectivement testé, il faut faire du mutation testing pour challenger cette couverture, mais c'est moins fréquent)
- il faut ensuite analyser le code pour savoir ce qu'il fait, notamment quoi mettre dans les assertions des tests
- à défaut de connaître le besoin, on peut tenter de lui trouver une approximation sur la base du code, mais certainement pas pour le prendre comme référence, uniquement pour tenter de trouver un fil conducteur, une cohérence entre toutes les pièces (en effet le besoin a probablement changé depuis)
- là où le code peut vraiment aider au niveau besoin, c'est de fournir tout les concepts (via les nommages) et leurs relations (e.g. les arguments communs d'une fonction), les plus volontaires pourront documenter tout ça, voir construire une ontologie
- ensuite, monter la couverture à un niveau raisonnable en créant des tests fonctionnels... mais quand on ne connaît pas le besoin, faire des tests de caractérisation, c'est à dire des tests jetables (à remplacer par des tests fonctionnels dès qu'on clarifie le besoin), qui écrivent dans le marbre le comportement actuel, indépendamment du besoin
- une fois le filet de sécurité obtenu (qui peut nécessiter, comme souvent dans le legacy, d'abstraire d'abord les dépendances pour réduire le coût d'exécution des tests, donc déjà une étape de refacto, à garder minimale), on peut alors refactorer le code, en gardant en tête qu'on a potentiellement des tests de caractérisations qui ne collent pas aux besoins actuels, uniquement au code actuel, certains choix de refacto doivent donc être challengés

Tout au long du processus, la moindre opportunité de clarifier le besoin doit être prise, de façon à remplacer les tests de caractérisation par des tests fonctionnels validés.

Pour des pratiques de refacto classiques, c'est ce que je recommande de faire. C'est en tout cas le schéma que je suis actuellement. Mais une autre façon de faire, c'est de faire ce que j'appelle du "refacto agile", c'est à dire des micro-étapes de refacto livrables immédiatement, donc non cassantes (ça compile toujours et les tests sont toujours verts, à chaque étape). Cela demande un paquet de rigueur quand fait manuellement, mais elles ont l'avantage d'être systématiques, et donc scriptables. Ajouter à ça de l'IA (au sens général, pas forcément LLM) pour clarifier la cible à atteindre et identifier la séquence d'étapes de refacto agile, et on a de quoi l'automatiser. C'est ce que je bosse actuellement depuis quelques années (quand j'en ai l'opportunité). Au moins, chaque étape peut être démontrée correcte pour les matheux (spoiler alert: la réflexion est son pire ennemi), et pour les moins matheux en exécutant la suite de tests à chaque étape pour s'en convaincre.
0  0