Concept Modernisation du legacy
Reconstruire sans big bang une application dont la connaissance s'est perdue, avec des agents de code qui écrivent d'abord la spec de l'ancien code.
SFEIR AI · Publié le 20 octobre 2026
De quoi on parle
Une application legacy est un logiciel en production dont personne ne sait plus exactement ce qu'il fait. Ses auteurs sont partis, ses règles de gestion vivent dans le code et nulle part ailleurs, et aucun test ne dit si une modification a cassé quelque chose. Michael Feathers (Working Effectively with Legacy Code) définit le legacy comme du code sans tests ; Hamadi Jabloun le reformule sur sfeir.dev en « code sans feedback ». La difficulté monte d'un cran quand le langage ou la plateforme sont rares : COBOL sur mainframe, RPG, ABAP, PL/I, ou un atelier de génie logiciel propriétaire comme WinDev et son WLangage.
Martin Fowler décrit la trajectoire habituelle : des systèmes construits sur des décennies, entretenus par couches de correctifs, chacune rendant la suivante plus difficile, jusqu'au jour où l'on ne peut plus rafistoler. Le réflexe est alors de reconstruire à l'identique dans une technologie neuve. Fowler écrit avoir vu ce plan échouer la plupart du temps : le remplacement prend des années, les utilisateurs n'attendent pas les nouvelles fonctions, le comportement existant est difficile à retrouver dans le détail, et une bonne part de ce comportement n'est plus souhaitée. Moderniser le legacy, c'est donc retrouver ce que fait l'application, décider ce qu'on en garde, et le reconstruire par morceaux en prouvant à chaque pas que rien n'a changé pour l'utilisateur.
Ce que les agents de code changent
Jusqu'ici, réécrire coûtait si cher qu'on maintenait l'application sous perfusion. Les modèles à grande fenêtre de contexte lisent du code ancien plus vite et plus patiemment qu'un humain, et c'est cette lecture, avant toute écriture, qui change l'économie du chantier. Hamadi Jabloun (sfeir.dev, 20 septembre 2026) fixe l'ordre : « L'IA ne doit pas commencer par écrire le nouveau code. Elle doit commencer par écrire la spécification de l'ancien. » Cette rétro-spécification, dite « spec first », demande au modèle des livrables structurés et non une paraphrase : règles de gestion en langage métier avec le numéro de ligne d'origine, critères d'acceptation Gherkin (un scénario par branche d'exécution), valeurs en dur porteuses de sens métier, incohérences entre ce que le code fait et ce qu'il annonce, zones d'ombre que le modèle déclare ne pas comprendre. Le même article conseille d'exécuter ce prompt deux fois dans deux sessions distinctes : les règles présentes dans les deux sorties sont fiables, les autres passent en relecture humaine.
Deux chiffres cadrent l'exercice, tirés du même article. Sur un monolithe mature, 20 à 40 % du code est mort (endpoints sans client, branches rendues inatteignables par un flag figé, batchs dont le cron a été commenté) ; croiser l'analyse statique du graphe d'appels avec douze mois de logs de production, puis faire trier le modèle en actif, suspect ou probablement mort, évite de documenter, tester et réécrire ce qu'on va effacer. Et sur COBOL, RPG, ABAP ou PL/I, la qualité des réponses chute nettement, faute de données d'entraînement : plus d'inventions plausibles, donc plus de relecture par un sachant. Le pilier Migration WinDev range le WLangage, encore moins présent dans le code public, dans le même cas. L'approche naïve, coller quelques milliers de lignes dans un chat et demander la version moderne, produit du code qui compile, a l'air neuf, et dans lequel trois règles de gestion ont disparu sans bruit.
Le motif Strangler Fig et la bascule progressive
Le motif porte le nom des figuiers étrangleurs que Martin Fowler a observés dans les forêts du Queensland en 2001 : la liane germe dans une anfractuosité de l'arbre, s'en nourrit jusqu'à atteindre le sol et la canopée, puis devient autonome tandis que l'arbre hôte meurt, laissant le figuier en écho de sa forme. Fowler en a tiré quelques années plus tard un bref billet intitulé « Strangler Application », qu'il a rebaptisé « Strangler Fig Application » pour rappeler l'origine botanique du terme, dont la connotation de violence le gênait ; la page actuelle de martinfowler.com date du 22 août 2024. Le principe : commencer par de petits ajouts construits à côté du code legacy, puis déplacer des morceaux de comportement de l'ancien système vers le nouveau, en acceptant une architecture transitoire qui disparaîtra à la fin. Fowler reprend les quatre activités définies par Ian Cartwright, Rob Horn et James Lewis : clarifier les résultats attendus, découper le problème (trouver les coutures, seams, qui permettent d'isoler un composant), livrer les morceaux, et changer l'organisation pour que cela dure, en référence à la loi de Conway.
Sur le terrain, la bascule d'un module suit une séquence que décrit l'article de sfeir.dev. Une façade de routage se place devant l'ancien système ; chaque composant migré est débranché de l'ancien, jamais dupliqué. Avant de couper, le shadow traffic envoie la production aux deux implémentations en parallèle, ne renvoie que la réponse de l'ancienne et journalise les divergences : une semaine de trafic réel vaut mille tests générés, et le jour où le taux de divergence tombe à zéro, la bascule derrière un feature flag devient un non-événement. Une règle ne se négocie pas : aucune nouvelle fonctionnalité pendant la migration d'un composant, sinon on perd le référentiel de comparaison et la capacité de dire qui a cassé quoi.
Prouver la non-régression
Une application migrée qui tourne ne prouve rien. Il faut montrer qu'elle produit les mêmes sorties que l'ancienne, bugs compris : c'est le rôle des tests de caractérisation, qui figent le comportement actuel au lieu de vérifier qu'il est juste. Le piège, documenté par Hamadi Jabloun avec un exemple de remise de volume (le commentaire dit « à partir de 10 articles », le code dit > 10), est de laisser le modèle écrire aussi les valeurs attendues : il lit le nom de la méthode et le commentaire, affirme une remise pour dix articles, le test passe au rouge sur le legacy, et un développeur pressé « corrige » une règle de facturation en production avant même d'avoir commencé la migration. Personne ne sait si ce comportement est un bug ou un seuil négocié avec le métier il y a dix ans ; cette question se tranche en exécutant le code puis en allant voir le métier, jamais par lecture.
D'où l'inversion que SFEIR nomme golden master inversé : le LLM propose les jeux d'entrées (il est bon pour repérer qu'une quantité de dix est une frontière à tester), le code legacy seul produit les sorties attendues, et le nouveau code est jugé contre ce référentiel. Les écarts où le nouveau code semble plus juste que l'ancien ne se corrigent pas en silence : ils sont consignés dans un registre d'écarts à arbitrer et remontent au métier, parce que ce sont des décisions produit. Deux compléments de l'article : mesurer le filet au score de mutation (PIT, mutmut) plutôt qu'au taux de couverture, et préférer l'enregistrement du trafic de production réel aux cas imaginés. L'application à WinDev est détaillée dans la méthode du golden master inversé.
La pratique SFEIR
SFEIR mène ces chantiers sur son SDLC piloté par l'IA à onze phases (0 Setup, 1 Define, 2 Plan, 3 Build, 4 Verify, 5 Review, 6 Compound-1, 7 Ship, 8 Ops, 9 Compound-2, 10 Deprecation), où des humains tiennent trois gates, Define, Plan et Ship, et où les agents Claude Code exécutent le reste sous contrôle. L'article qui décrit ce cycle range la modernisation du legacy parmi les terrains où il excelle, avec les back-offices, les API et les portails : le contexte métier y est explicitable, la règle de gestion existe, et le résultat se prouve automatiquement. La Software Factory 10x y met environ 80 % de l'effort humain sur la planification et la revue, 20 % sur l'exécution ; sur une migration, le code s'écrit vite et le risque est d'écrire le mauvais.
Déclinée sur WinDev dans la méthode en six étapes, la démarche enchaîne l'audit du patrimoine (inventaire, code mort), l'extraction des règles métier (gate Define, franchie quand le métier a validé le référentiel), les spécifications par module (gate Plan), la réécriture par agents module par module sans nouvelle fonctionnalité, les tests de non-régression par golden master inversé (gate Ship, à divergence nulle), puis la bascule des données et du module. Le pilotage se compte en livrables (règles validées, modules spécifiés, modules basculés), jamais en jours-homme, avec le Rework Rate et le nombre d'itérations de correction par module comme indicateurs ; l'article sur le SDLC rapporte environ 30 % d'itérations de correction en moins après dix cycles. Parmi les références publiées, une entreprise de services a confié à SFEIR la refonte d'une application .NET legacy au workflow peu clair et aux règles de gestion non visibles, avec reverse engineering et documentation technique avant la réécriture en microservices Java, et un établissement bancaire fait moderniser un moteur d'affectation sur mainframe COBOL.
Questions fréquentes
Faut-il réécrire une application legacy d'un bloc ?
Martin Fowler écrit avoir vu le remplacement à l'identique échouer la plupart du temps : trop long, comportement existant difficile à retrouver, et une part de ce comportement qui n'est plus souhaitée. Le motif Strangler Fig procède par morceaux : on construit le nouveau à côté de l'ancien, on déplace les comportements module par module derrière une façade de routage, et l'ancien s'éteint quand il ne reçoit plus de trafic.
L'IA peut-elle convertir automatiquement un code ancien vers un langage moderne ?
Coller le code dans un chat et demander la version moderne donne du code qui compile et dans lequel des règles de gestion ont disparu sans bruit. La méthode publiée sur sfeir.dev inverse l'ordre : l'IA écrit d'abord la spécification de l'ancien code (règles de gestion, scénarios Gherkin, valeurs en dur, incohérences, zones d'ombre), le métier valide, et la réécriture vient après, module par module, jugée contre un golden master.
Comment prouver que la nouvelle application fait la même chose que l'ancienne ?
Avec un golden master inversé : le LLM propose les jeux d'entrées, l'application legacy seule produit les sorties attendues, bugs compris, et le nouveau code est comparé à ce référentiel. Les écarts où le nouveau code paraît plus juste remontent au métier au lieu d'être corrigés en silence. Avant la coupure, le shadow traffic fait tourner les deux implémentations sur le trafic réel et journalise les divergences.
Par où commence une modernisation du legacy chez SFEIR ?
Par l'audit du patrimoine et le tri du code mort (20 à 40 % d'un monolithe mature selon sfeir.dev), puis par l'extraction des règles métier, qui constitue la première gate humaine du SDLC à onze phases. Ce référentiel de règles validé par le métier garde sa valeur même si la migration s'arrête là. Les étapes suivantes (spécifications, réécriture par agents, non-régression, bascule) se font module par module.
Sources
- sfeir.dev, Hamadi Jabloun, « Du Legacy à l'état de l'art : moderniser avec l'IA sans rejouer le Big Bang » (spec first, 20 à 40 % de code mort, chute de qualité sur COBOL, RPG, ABAP, PL/I, golden master inversé, Strangler Fig, shadow traffic, gel fonctionnel) · 2026-09-20
L'IA ne doit pas commencer par écrire le nouveau code. Elle doit commencer par écrire la spécification de l'ancien.
- Martin Fowler, « Strangler Fig » (bliki) : origine du nom (Queensland, 2001), renommage de « Strangler Application », échec du remplacement à l'identique, quatre activités de Cartwright, Horn et Lewis · 2024-08-22
Like the fig, it begins with small additions, often new features, that are built on top of, yet separate to the legacy code base. As we do this we move bits of behavior from the legacy system into the new code base.
- SFEIR, « Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases » (onze phases, trois gates humains, modernisation de legacy parmi les terrains d'application, −30 % d'itérations de correction après dix cycles) · 2026-06-16
- SFEIR, « Migration WinDev : réécrire vos applications PC SOFT avec l'IA, sans big bang » (rétro-spécification spec first, méthode en six étapes, WLangage et langages rares) · 2026-10-07
- SFEIR, « Migrer WinDev avec la Software Factory 10x : la méthode SFEIR en six étapes » (cadre SDLC, gates Define, Plan, Ship, pilotage en livrables) · 2026-10-15
Modernisation du legacy dans vos projets
Échanger avec SFEIRArticles liés
Migration WinDev : réécrire vos applications PC SOFT avec l'IA, sans big bang
Une migration WinDev se joue sur deux chantiers : retrouver les règles métier enfouies dans vingt ans de fenêtres, puis prouver que la nouvelle application fait la même chose que l'ancienne. Méthode SFEIR en six étapes, stack cible, ordres de grandeur et grille rester, geler ou migrer.
Migrer WinDev avec la Software Factory 10x : la méthode SFEIR en six étapes, de l'audit à la bascule
Six étapes, un livrable vérifiable au bout de chacune, trois gates tenues par des humains et l'exécution confiée aux agents Claude Code : comment SFEIR mène une migration WinDev sur son SDLC à onze phases, de l'audit du patrimoine à la bascule.
Extraire les règles métier d'une application WinDev avec l'IA : la rétro-documentation spec first
Les règles de gestion d'une application WinDev vivent dans son WLangage et nulle part ailleurs. Comment les extraire avec l'IA : export en mode texte, prompt d'archéologie à cinq sections, double exécution, Gherkin, ADR rétroactifs et validation métier.
Tests de non-régression d'une migration WinDev : la méthode du golden master inversé
Une application migrée qui tourne ne prouve rien. Il faut montrer qu'elle produit les mêmes écritures, états et exports que l'application WinDev, bugs compris. Notre méthode : le LLM propose les entrées, WinDev seul produit les sorties, et le nouveau code est jugé contre ce golden master.
Migration WinDev : les 10 risques qui font échouer un projet, et comment les maîtriser
Big bang, règles oubliées, états découverts en recette, lots invisibles, tests écrits par le LLM : les migrations WinDev échouent rarement pour une raison technique. Les dix risques que nous rencontrons le plus, et l'étape de la méthode qui neutralise chacun.
Combien coûte une migration WinDev en 2026 ? Coût, délais et ROI avec l'IA
Le prix d'une migration WinDev ne se lit pas au nombre de fenêtres. Il se calcule : ce que vous cesserez de payer chaque année, ce que coûte la sortie, et le temps qu'il faut pour que l'un rembourse l'autre. Le modèle, les ordres de grandeur publiés en 2026 et notre chiffrage en livrables.
WinDev vers Java, .NET, TypeScript ou Flutter : comment choisir sa stack cible
Nous sommes sous Windows, donc .NET : le réflexe tombe parfois juste, mais il saute l'examen. SI existant, desktop imposé, mobile terrain, trajectoire SaaS, volumétrie : notre grille pour choisir entre Java/Spring + Angular, .NET, TypeScript et Flutter, avec PostgreSQL comme socle commun.
HFSQL vers PostgreSQL : migrer les données d'une application WinDev sans perte
Migrer une base HFSQL vers PostgreSQL sans perte : transposer le schéma, déclarer les clés que le code gardait implicites, nettoyer avant de migrer, répéter les migrations à blanc jusqu'à deux rapports de conformité sans écart, faire tourner WinDev sur PostgreSQL, puis basculer.
Migrer WebDev et WinDev Mobile : sites, applications SaaS et applications terrain
WebDev et WinDev Mobile partagent le WLangage avec WinDev, mais leurs migrations ont leurs questions propres : serveur d'application facturé par cœurs et mémoire, référencement, sessions d'un côté ; hors ligne, synchronisation, terminaux et Flutter de l'autre. Ce qui change, ce qui ne change pas.
Redevance WinDev, rachat de PC SOFT : faut-il quitter WinDev maintenant ?
Rachat de PC SOFT fin 2024, abonnement depuis février 2025, facturation à la session en 2026, référé à Marseille en octobre : la chronologie sourcée, le calcul de votre exposition et trois options (négocier, geler, migrer) pour décider sans se précipiter.
OpenSpec : le spec-driven taillé pour le code que vous avez déjà
OpenSpec, édité par Fission AI sous licence MIT depuis août 2025, décrit chaque changement comme un delta de spécification (ADDED, MODIFIED, REMOVED) fusionné à l'archivage. Lecture du cycle propose, apply, archive dans la grille SFEIR : le seul cadre de la série sans gate formel.
Agentic coding sur de grandes bases de code : le vrai problème n'est pas l'agent, c'est la mémoire
Agentic coding sur de grandes bases de code : le vrai goulot, c'est lire le code existant — donnez le contexte du dépôt à l'agent.
Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)
Greffer l'IA sur un cycle pensé pour des humains ne donne pas un facteur 10, juste un goulot qui produit ses erreurs dix fois plus vite. Le SDLC augmenté : 11 phases, 3 gates humains, 2 capitalisations, et la convergence des cadres qui le valident.
Les limites du SDLC piloté par l'IA : où l'on n'y va pas (encore)
64 % des dirigeants tech veulent déployer des agents, 17 % l'ont fait. L'écart n'est pas un problème de modèle, mais de périmètre. La carte des bons cas — et des trois frontières assumées : l'inédit sans spec, le safety-critical certifiable, les données non gouvernées.
API-First vs AI-First : transformer ses applications via MCP
De l'API-First à l'AI-First : une rupture qui redéfinit les fondations du logiciel Pendant près d'une décennie, le paradigme API-First a structuré la façon dont les équipes conçoivent leurs systèmes d'information. Le principe était simple et puissant : penser l'interface avant l...