Guide modernisation legacy Strangler 2026 : la méthode 6 phases pour sortir de la dette sans casser la prod

#Chapitre 1 — Dette technique en France 2026 : cartographie d'un fardeau

La dette technique n'est pas un sujet d'ingénieur. C'est un sujet de comité exécutif. Et en 2026, en France, c'est devenu un sujet de survie pour beaucoup d'ETI. Quelques chiffres pour cadrer.

#60 à 80 % des ERP ETI ont plus de 12 ans

L'étude Apec/Syntec 2024 sur l'état des SI industriels français est sans appel. Entre 60 et 80 % des PME et ETI industrielles s'appuient sur un ERP ou un cœur de SI de plus de 12 ans. Le pic se situe sur les éditeurs disparus ou rachetés : Sage X3 ancienne génération, Cegid Y2, IBM Cognos, Microsoft Dynamics NAV 2009, des ERP propriétaires développés en interne sur les années 2000-2008 par des équipes IT internes qui n'existent plus. Côté banque, le COBOL tourne toujours sur 95 % des core banking des grandes banques françaises (BPCE, Crédit Agricole, Crédit Mutuel, BNP Paribas) — la migration mainframe est en cours depuis 15 ans, et reste majoritairement inachevée.

#5 000 milliards de dollars de coût mondial annuel — McKinsey

McKinsey a publié en 2024 une estimation chiffrée de la dette technique mondiale : 5 000 milliards de dollars cumulés, plus de 1 500 milliards annuels de coût caché (maintenance excessive, opportunités business perdues, coûts de licence inutiles, productivité dégradée). Cette dette n'est pas linéaire mais croît exponentiellement avec le temps : un système legacy de 5 ans coûte typiquement 1,5 fois son équivalent moderne ; à 10 ans, 2,5 fois ; à 15 ans, 4 à 6 fois ; à 20 ans, parfois 10 fois (en intégrant la rareté des compétences). C'est cette progression exponentielle qui rend le sujet incontournable au-delà d'un certain seuil.

#Symptômes typiques d'un SI en dette critique

Sur les 18 audits SI legacy que nous avons menés chez des ETI françaises entre 2023 et 2025, six symptômes reviennent systématiquement. Symptôme 1 : 35 % du temps de l'équipe dev est consacré à la maintenance corrective de la dette, vs 15 % attendu en équipe saine. Symptôme 2 : les bugs en production sont 3 à 5 fois plus fréquents que sur une stack moderne. Symptôme 3 : le coût d'ajout d'une nouvelle fonctionnalité métier est multiplié par 2 à 8 par rapport à une stack cible équivalente. Symptôme 4 : plus aucun développeur de l'équipe ne maîtrise l'intégralité du code (souvent on ne trouve qu'une seule personne — le dernier dev sénior arrivé en 2008 — qui sait encore où passe quel batch nocturne). Symptôme 5 : les mises à jour de sécurité sont décalées de 6 mois et plus, faute de capacité à tester sans casser. Symptôme 6 : recrutement impossible des profils maîtrisant la stack source (COBOL, VB6, Delphi, AngularJS legacy), avec des salaires en hausse de 30 à 50 % par rapport au marché.

#Pourquoi 2026 est le moment de la bascule

Trois facteurs convergent en 2026 et rendent la modernisation legacy non seulement possible mais incontournable. Premier : l'arrivée à maturité des outils de dev IA-assisté (Claude Code, Cursor, GitHub Copilot, Aider, Cline) qui divisent par 2 à 4 le temps de réécriture sur les langages bien couverts par les LLM (PHP, Java, Python, C# moderne). Deuxième : l'empilement des contraintes réglementaires (DORA pour la finance, NIS2 pour les entités essentielles, AI Act, RGPD renforcé, FIDA) qui imposent une stack auditable, observable, exploitable — incompatible avec un mainframe COBOL ou un Lotus Notes 2003. Troisième : la pénurie aiguë de profils legacy. Les développeurs COBOL ont 58 ans de moyenne d'âge selon IBM (2025), les développeurs VB6 sont devenus introuvables, les profils Delphi se monnayent à plus de à partir de 800 € HT/jour quand on en trouve. Le coût total de possession (TCO) du legacy croît plus vite que celui d'une modernisation.

Pour aller plus loin sur les fondamentaux, voir la définition complète du Strangler Fig Pattern dans le glossaire Nehos et le service Legacy Modernization Nehos.

#Chapitre 2 — Big-bang vs Strangler Fig : pourquoi 70 % des refontes échouent

#Le big bang remplacement : l'approche qui détruit

Le big bang remplacement consiste à développer en parallèle un système entièrement nouveau qui remplacera l'ancien à une date donnée. Variantes : un projet de remplacement d'ERP type SAP S/4HANA ou Oracle Fusion Cloud sur 24-36 mois, un projet de réécriture from scratch d'une application métier interne, une migration de plateforme avec passage en mode big bang à minuit le jour J. Avantage théorique : on repart d'une page blanche, donc on peut concevoir proprement. Inconvénient pratique : la complexité du legacy est presque toujours sous-estimée, et le système cible n'est jamais prêt au moment de la bascule.

#70 % d'échecs documentés — Standish CHAOS Report 2024

Le Standish Group publie depuis 1994 le CHAOS Report, l'étude de référence sur le taux d'échec des projets IT. L'édition 2024 documente sur 50 000+ projets que le taux d'échec des projets de refonte big bang ERP est de 70 % : dépassement budgétaire de plus de 100 %, dépassement délai de plus de 100 %, ou fonctionnalités majeures abandonnées. Plus inquiétant encore : dans environ 20 % des cas, le projet est purement abandonné et l'entreprise retourne sur le legacy. On trouve dans la presse économique française plusieurs cas emblématiques : Lidl qui a renoncé à un projet SAP 499,2 M€ après 7 ans d'efforts (Handelsblatt 2018, repris LSA Conso), des dossiers similaires chez Auchan, Carrefour, et plusieurs ETI françaises non médiatisés.

Les raisons documentées sont presque toujours les mêmes. Raison 1 : effet tunnel — 18-36 mois sans livrable utilisable par le métier, qui finit par perdre confiance. Raison 2 : underestimation de la complexité du legacy, particulièrement sur les processus métier non documentés (« tribal knowledge » des équipes opérationnelles). Raison 3 : pas de rollback possible — si quelque chose casse le jour J, on ne peut pas revenir au legacy car il a été figé voire débranché. Raison 4 : impossibilité d'iterer sur le système cible en parallèle des évolutions métier qui continuent sur le legacy (double maintenance pendant 24-36 mois, équipe épuisée).

#Le Strangler Fig Pattern : la métaphore du figuier étrangleur

Le Strangler Fig Pattern a été formalisé par Martin Fowler en 2004 dans un article devenu canonique de la littérature d'architecture logicielle. La métaphore est botanique : le figuier étrangleur (Ficus tropical) est une plante qui pousse autour d'un arbre hôte, l'enveloppe progressivement, puis finit par le remplacer entièrement quand l'hôte meurt. Appliqué au logiciel : on n'arrête jamais le système legacy, on construit le nouveau système autour, on bascule fonctionnalité par fonctionnalité, et quand 100 % des fonctionnalités sont migrées, on débranche l'ancien.

#Trois briques techniques du Strangler

Le pattern repose sur trois briques techniques claires. Brique 1 — La couche de routage : un composant (API gateway, reverse proxy, façade applicative) qui décide pour chaque appel s'il va vers l'ancien ou le nouveau système. C'est le point d'entrée unique qui permet la bascule progressive. Brique 2 — Le nouveau périmètre fonctionnel : développé en propre dans la stack cible (Next.js + Payload + Postgres dans notre stack standard, ou Symfony 7, ou .NET 9, ou Java 21 selon contexte). Brique 3 — Le plan de décommissionnement : module par module, avec coexistence assumée tant que l'ancien apporte de la valeur. Cette coexistence dure typiquement 18 à 36 mois pour une ETI, 3 à 5 ans pour un grand compte avec mainframe COBOL.

#Avantages opérationnels du Strangler

Quatre avantages décisifs par rapport au big bang. Avantage 1 : pas d'arrêt de production. Le legacy continue de tourner pendant toute la durée du projet, le métier ne subit aucune coupure. Avantage 2 : rollback à tout moment. Si la bascule d'un module pose problème, on peut router à nouveau vers le legacy via la couche de routage en quelques minutes. Avantage 3 : itération courte et livrables visibles. Chaque module migré est un livrable concret pour le CODIR, qui voit la valeur s'accumuler progressivement (vs effet tunnel du big bang). Avantage 4 : apprentissage continu. Les premiers modules migrés enseignent aux équipes les zones grises du legacy, ce qui fiabilise les suivants.

Pour le détail méthodologique, voir la Méthode Legacy Strangler IA-Assisted Nehos™ et la page glossaire dédiée.

#Chapitre 3 — Méthode Nehos Legacy Strangler IA-Assisted™ : 6 phases

Notre méthode propriétaire applique le Strangler Fig Pattern en six phases formalisées. Chacune a des livrables, une durée et des KPIs documentés. Marque déposée à l'INPI en avril 2025, validée sur 6 projets clients entre 2024 et 2026, plus de 280 000 lignes de code migrées, zéro incident de production majeur.

#Phase 1 — Cartographie legacy et dette technique (semaines 1 à 4)

On audite l'ensemble du SI legacy avec une grille propriétaire Nehos : langages et versions (COBOL, VB6, PHP 4/5/7, Java 7/8, .NET Framework, Oracle Forms, Delphi, ASP Classic, Lotus Notes), frameworks et dépendances avec scoring de la criticité des CVE non patchées, couverture de tests automatisés (typiquement moins de 5 % sur un legacy), documentation existante, profil de l'équipe interne. On chiffre la dette en jours/homme de retard, en coûts annuels de maintenance, en risque opérationnel. Pour accélérer, on utilise Claude Code en mode analyse statique du code legacy : le LLM lit le code, identifie les modules, génère la documentation manquante, repère les dépendances cachées. Livrables : note de cadrage 20-30 pages, matrice de risques techniques par module (rouge/orange/vert), benchmark coût maintenance actuel vs projeté.

#Phase 2 — Encapsulation par micro-services (semaines 5 à 10)

Once les candidats identifiés, on découpe le legacy en domaines fonctionnels et on encapsule les modules ciblés par des micro-services modernes — sans toucher au cœur legacy à ce stade. Concrètement : pour chaque module candidat, on développe un wrapper de service qui expose ses fonctionnalités via une API REST ou GraphQL moderne, en lisant et écrivant dans la base legacy. C'est un investissement qui paraît contre-intuitif (on ajoute de la complexité avant d'en retirer) mais c'est la clé du dual-run. Le wrapper devient le point d'entrée unique pour ce module, et permettra plus tard la bascule transparente vers la nouvelle implémentation. Livrables : 3 à 8 micro-services wrappers déployés, specs OpenAPI 3.1, environnement de pré-production isolé.

#Phase 3 — Façade API gateway (semaines 11 à 14)

Mise en place de la couche d'abstraction qui pilote le trafic. Nous utilisons typiquement Kong Gateway en self-hosted (OVHcloud) ou Tyk selon le contexte client. La gateway expose un endpoint unifié au reste du SI, et route en interne soit vers le micro-service wrapper (lui-même appelant le legacy), soit directement vers la nouvelle implémentation quand elle sera prête. Observabilité au cœur du dispositif : OpenTelemetry, Prometheus, Grafana, Loki pour les logs. Chaque requête est traçée bout en bout. À ce stade, 100 % du trafic passe encore par le legacy via les wrappers, mais l'infrastructure de bascule est en place. Livrables : Kong configuré, dashboards observabilité, plan de bascule par feature flag.

#Phase 4 — Migration incrémentale fonctionnalité par fonctionnalité (mois 4 à 18)

La phase la plus longue, et celle où l'IA-assisted refactoring fait la différence. Pour chaque module à migrer, on suit un cycle court : le développeur sénior cadre les specs avec le métier, Claude Code génère la première implémentation Next.js + Payload à partir du code legacy et des specs OpenAPI, le sénior corrige et durcit le code, on génère les tests automatisés via Cursor à partir du comportement legacy observé. La bascule de trafic se fait par feature flag progressif : 1 %, 5 %, 25 %, 50 %, 100 % sur des fenêtres de quelques jours à quelques semaines selon la criticité du module. On mesure activement la non-régression via shadow testing (les deux implémentations reçoivent la même requête, on compare les résultats). Livrables : modules migrés un par un, rapport de non-régression par module, mise à jour continue du dashboard de migration.

#Phase 5 — Dévalidation du legacy par modules migrés (mois 12 à 22)

Une fois la bascule à 100 % validée pour un module, on entre en phase de dévalidation. Trois étapes : gel des évolutions sur le module legacy correspondant (toute évolution business va désormais sur la nouvelle implémentation), période de validation de la non-régression sur 3 à 6 mois (la donnée historique reste accessible via les wrappers en lecture seule), certification métier formelle du domaine. À ce stade, le module legacy est encore physiquement présent mais ne reçoit plus de trafic d'écriture. C'est l'étape psychologique la plus difficile : les équipes opérationnelles ont du mal à lâcher la version qu'elles connaissaient. Communication interne et formation sont indispensables. Livrables : PV de certification métier par module, plan de gel évolutions, archivage des données historiques.

#Phase 6 — Suppression définitive du legacy (mois 18 à 24)

Décommissionnement module par module : arrêt des serveurs anciens, désinstallation des composants, archivage froid des données dans un format pérenne (Parquet sur stockage objet OVHcloud typiquement), mise à jour de la documentation finale, capitalisation des apprentissages dans le retour d'expérience interne. Formation des équipes internes sur la nouvelle stack si elles vont reprendre la maintenance. La phase 6 démarre dès que le premier module est certifié en phase 5 — on n'attend pas que tout soit migré pour commencer à décommissionner ce qui peut l'être. Livrables : ordre de décommissionnement signé, archivage froid validé conforme RGPD, formation interne réalisée, retour d'expérience capitalisé.

Pour le détail complet pas-à-pas de chaque phase, voir la Méthode Legacy Strangler IA-Assisted Nehos™.

#Chapitre 4 — Stack moderne cible recommandée : Next.js 16 + Payload + Postgres + Mistral

#Le choix de stack n'est pas neutre

Il n'existe pas de stack moderne universellement supérieure. Mais il existe des combinaisons éprouvées qui maximisent la productivité avec IA-assistance, minimisent le risque d'obsolescence prochaine, et restent compatibles souveraineté française quand pertinent. Notre stack standard 2026, validée sur 6 projets de modernisation, combine quatre couches.

#Couche front et BFF : Next.js 16 (App Router, RSC, Server Actions)

Next.js 16 sorti fin 2025 a stabilisé l'App Router et les React Server Components. Notre choix s'appuie sur trois arguments. Premier : la maturité du framework — utilisé par Vercel, Netflix, TikTok, Linear, Anthropic — garantit une obsolescence très lente. Deuxième : l'écosystème massif autour de React Native, ce qui permet une stratégie multi-plateformes (web, mobile, desktop via Electron) avec un investissement raisonnable. Troisième : la qualité du support IA-assisted — Claude Code et Cursor connaissent parfaitement Next.js, ce qui accélère la phase de migration. Alternative envisagée puis écartée : Remix (trop niche depuis le rachat Shopify), SvelteKit (écosystème moins dense), Astro (mieux pour le contenu pur, moins pour l'applicatif). Voir le service Migration Symfony Next.js Nehos pour le cas spécifique PHP legacy.

#Couche CMS et BFF : Payload CMS

Payload est un CMS headless TypeScript open-source qui s'est imposé en 2024-2025 comme le standard alternatif à Strapi. Notre choix s'explique. Un : Payload est nativement intégré à Next.js (déploiement combiné), ce qui simplifie l'infrastructure. Deux : il fournit out-of-the-box des fonctionnalités critiques pour la modernisation legacy — auth multi-tenant, rôles fins, audit log immuable (utile DORA Article 12), workflow de publication, internationalisation, custom fields. Trois : la stack TypeScript bout-en-bout réduit drastiquement le coût mental du switch entre couches (typage partagé entre back et front). Quatre : la communauté open-source est dynamique et le modèle économique de l'éditeur est sain.

#Couche base de données : Postgres 16+

Postgres est devenu le choix par défaut en 2026 pour 95 % des projets — y compris les projets historiquement Oracle ou SQL Server. Trois arguments. Premier : maturité et stabilité légendaires, plus de 30 ans de production. Deuxième : richesse fonctionnelle qui couvre la plupart des besoins (JSON natif, search full-text, extensions PostGIS, TimescaleDB, pgvector pour les embeddings IA). Troisième : disponibilité managée sur tous les clouds souverains (OVHcloud, Scaleway, Outscale, 3DS Outscale). Alternative envisagée : MariaDB (moins riche), SQL Server (lock-in Microsoft, coût licence), MongoDB (pertinent uniquement sur cas spécifiques de schéma très flexible).

#Couche IA : Mistral Large 2 + Claude pour le développement

Deux LLM se complètent dans la stack cible Nehos. Mistral Large 2 (sorti 2024, mise à jour 2025) est notre LLM de production pour les charges sensibles : juridiction européenne, hébergement souverain possible, qualité linguistique française excellente, licence commerciale claire. Nous l'utilisons pour les agents IA internes, l'analyse documentaire, la génération de contenu en production. Claude (Anthropic) est notre LLM de développement : Claude Code pour le refactor legacy, Claude Sonnet pour les revues de code, Claude Opus pour les tâches d'architecture complexes. Le combo Mistral pour la prod + Claude pour le dev nous donne le meilleur ratio souveraineté/qualité. Voir la définition Mistral Large 2 dans le glossaire et la définition Claude Anthropic.

#Couche infrastructure : OVHcloud + GitOps

Déploiement standard sur OVHcloud (Public Cloud Gravelines ou Roubaix), juridiction française, conformité SecNumCloud accessible. Pipeline GitOps via GitLab CI/CD avec ArgoCD pour Kubernetes. Observabilité OpenTelemetry + Grafana Cloud. Backup avec rétention configurable selon politique RGPD client.

Pour les variantes spécifiques (Symfony 7 pour les écosystèmes PHP historiques, .NET 9 pour les ETI Microsoft-centric, Java 21 pour les banques mainframe), voir le service Development Nehos.

#Chapitre 5 — IA-assisted refactoring : Claude Code, Cursor, GitHub Copilot

#Ce qui a changé entre 2022 et 2026

En 2022, l'IA dans le développement logiciel se résumait à GitHub Copilot V1 — un autocomplete amélioré qui aidait sur le code boilerplate, sans transformer profondément le workflow. En 2026, c'est radicalement différent. Trois outils ont mûri suffisamment pour transformer économiquement le refactor legacy : Claude Code (Anthropic, mode agentique), Cursor (IDE complet), GitHub Copilot (devenu agent-mode), plus quelques outsiders matures (Aider, Cline). Le gain mesuré sur nos 6 projets 2024-2025 : +47 % de productivité moyenne sur les chantiers de refactor, soit phase de réécriture divisée par 2 à 4 selon la qualité du code source.

#Claude Code : l'agent de refactor de référence

Claude Code est notre outil principal pour le refactor legacy. Le mode agentique permet de confier à l'IA une mission complète : « lis ce module COBOL, comprends sa logique métier, produis l'équivalent en Java moderne avec tests unitaires couvrant les cas observés ». Le développeur sénior reste dans la boucle (review obligatoire), mais le coût mental et temporel de la première traduction est divisé par 3 à 5. Trois forces de Claude Code en refactor : qualité de compréhension du code legacy même obscur (Claude 4.5 et 4.6 ont vu beaucoup de code source historique en pré-training), capacité à raisonner sur des fichiers de 5 000+ lignes (contexte long 200K tokens, plus en mode 1M), génération de tests cohérents avec le comportement observé. Voir la définition Claude Anthropic complète.

#Cursor : l'IDE complet pour modernisation

Cursor (fork d'éditeur VS Code adapté IA) reste notre IDE quotidien sur les projets de modernisation. Trois fonctionnalités structurantes. Premier : le mode Composer multi-fichiers, qui permet de demander une modification cohérente sur un ensemble de fichiers (utile pour appliquer un changement de pattern architectural). Deuxième : l'intégration native des LLM de plusieurs providers (Claude, GPT, Mistral), avec routage selon le type de tâche. Troisième : la qualité du diff visualisé et de l'acceptation/rejet morceau par morceau, ce qui change le rapport au code généré (on n'accepte plus tout en bloc).

#GitHub Copilot agent-mode

GitHub Copilot a évolué en 2024-2025 vers un mode agent capable de prendre des tickets GitHub Issues, de produire des Pull Requests complètes avec tests, et de répondre aux commentaires de review. Sur les projets de modernisation où l'équipe interne reprend la maintenance ensuite, c'est un atout fort : Copilot s'intègre nativement dans le workflow GitHub Enterprise déjà en place chez nos clients banque et grand compte.

#Migrations IA-assistées : ce qui marche, ce qui marche moins

Une vérité opérationnelle qu'on documente honnêtement dans nos devis : tous les langages ne se valent pas en IA-assistance. Migrations à très fort gain (×3 à ×5) : PHP 4/5/7 vers PHP 8 + Symfony 7 (Claude excellent sur PHP), Java 7/8 vers Java 21 (corpus massif), Python 2 vers Python 3 (cas d'école), ASP Classic vers ASP.NET Core. Migrations à gain moyen (×1,5 à ×2,5) : .NET Framework vers .NET 9 (Claude bon mais corpus C# vieillot moins dense), AngularJS vers React/Vue/Next.js (refactor partiel viable), Oracle Forms vers web (templates de mapping à constituer). Migrations à gain faible voire risquées (×1 à ×1,3) : COBOL vers Java (corpus COBOL rare dans le pré-training LLM, lead sénior COBOL impératif), VB6 vers .NET 9 (corpus très rare), Delphi vers web (corpus quasi inexistant). Pour ces cas, on combine IA-assistance partielle (sur les fonctions standard) et expertise humaine sénior obligatoire (sur la logique métier complexe).

#Concrètement, un chantier IA-assisted de COBOL vers Java

Illustration sur le cas banque mutualiste (détaillé chapitre 6). Pour migrer un module COBOL de 8 000 lignes vers Java 21, l'équipe Nehos a appliqué le workflow suivant : (1) Claude Code analyse le code COBOL et produit une documentation fonctionnelle en français des intentions du module (4 heures de travail combiné dev sénior + LLM, vs 4 jours estimés en pure expertise humaine) ; (2) Le lead COBOL sénior valide et corrige la documentation (1 jour) ; (3) Claude Code génère une première implémentation Java 21 + Spring Boot 3 (2 jours) ; (4) Le dev Java sénior corrige et durcit (5 jours, vs 18 jours estimés sans IA) ; (5) Cursor génère les tests unitaires à partir du comportement legacy observé (1 jour) ; (6) Tests de non-régression en shadow testing (3 jours). Total : 12 jours travaillés vs 35 jours estimés sans IA-assistance. Gain : 65 % de réduction de durée sur le module. Pour le détail Cobol mainframe, voir le service Migration COBOL mainframe.

Voir aussi le service Vibe Coding Dev IA-Assisté Nehos pour la doctrine complète développement IA-assisté.

#Chapitre 6 — Trois cas concrets : ETI, banque mutualiste, opérateur public

Trois cas Nehos anonymisés selon NDA, représentatifs de la diversité des situations legacy en France 2026.

#Cas 1 — ETI mécanique de précision : ERP propriétaire 18 ans modernisé en 24 mois

Contexte client : ETI française mécanique de précision, 380 collaborateurs, CA 88 M€, ERP développé en interne en 2007 sur stack Java EE 5 + Oracle Forms + Oracle 10g. Codebase 420 000 lignes, équipe IT interne de 4 personnes dont 1 seul connaît l'intégralité du code (Christophe, 56 ans, projet retraite à 5 ans). Trigger projet : audit de sécurité 2024 ayant identifié 18 CVE critiques non patchables sur la stack Java EE 5 obsolète, et incapacité technique à brancher l'ERP au nouveau MES Industry 4.0 que la direction industrielle voulait déployer.

Diagnostic Nehos semaine 1 : niveau de dette technique critique (rouge), risque opérationnel élevé (Christophe = single point of failure), réécriture impérative sous 24-30 mois. Méthode appliquée : Nehos Legacy Strangler IA-Assisted™ 6 phases sur 24 mois. Stack cible : Next.js 16 + Payload + Postgres 16 + Symfony 7 pour certains domaines métier complexes héritage Java EE. Effort total : 1 850 jours-homme cumulés équipe Nehos + équipe cliente, budget 1400 k€ HT forfait fixe sur 24 mois (incluant licence Payload Enterprise, infrastructure OVHcloud Gravelines, formation équipe interne). Résultat : ERP modernisé sans interruption de production, branchement MES réussi mois 14, départ retraite Christophe gérée sereinement à mois 20 (transfert de connaissance accompagné), équipe interne reformée à 3 développeurs full-stack TypeScript + 1 lead sénior. ROI 36 mois : -42 % coût maintenance annuel (de 720 k€ 419 k€), +60 % vélocité dev mesurée par story points livrés, plus de 12 nouvelles fonctionnalités business livrées la première année post-modernisation. Voir le cas client détaillé ETI mécanique (page dédiée).

#Cas 2 — Banque mutualiste régionale : COBOL mainframe vers cloud Java microservices en 36 mois

Contexte client : banque mutualiste régionale française, 1 200 conseillers, 380 000 sociétaires, core banking COBOL sur mainframe IBM Z, environ 5 millions de lignes de code accumulées depuis 1987, équipe COBOL interne de 12 personnes (moyenne d'âge 54 ans, 4 départs retraite programmés 2026-2028). Trigger projet : pression réglementaire DORA (Article 28 registre fournisseurs critiques difficile à tenir avec mainframe), pression coûts licence IBM (en hausse continue), pression compétitive sur les API ouvertes (DSP3 à venir).

Diagnostic Nehos semestre 1 : modernisation impérative mais complète impossible sur moins de 5 ans, approche Strangler progressive obligatoire. Méthode appliquée : Nehos Legacy Strangler IA-Assisted™ adaptée mainframe, 36 mois pour cycle 1 (couvrant 40 % du périmètre core banking, modules les plus stables et les mieux documentés). Cycle 2 prévu pour 36 mois supplémentaires sur les 60 % restants. Stack cible : Java 21 + Spring Boot 3 + microservices déployés sur Kubernetes OVHcloud SecNumCloud, Postgres 16 (migration progressive depuis DB2 mainframe), Kafka pour l'événementiel, observabilité OpenTelemetry. IA-assistance : Claude Code pour la phase analyse COBOL et génération doc, mais lead COBOL sénior (Jean-Marc, 30 ans d'expérience COBOL) obligatoire sur toutes les phases de traduction (corpus COBOL trop rare dans pré-training LLM pour autonomie totale). Effort total cycle 1 : 8 200 jours-homme cumulés (équipe Nehos + équipe cliente + cabinet partenaire COBOL), budget 1699 k€ HT forfait étalé 36 mois. Résultat à 36 mois : 40 % du périmètre core banking migré vers Java + microservices, zéro incident de production majeur (un incident mineur en mois 18 sur module crédit consommation, rollback en 12 minutes via API gateway Kong), DORA Article 28 facilité par stack cloud auditable, API ouvertes prêtes pour DSP3. Voir le secteur Banque-Assurance-Finance Nehos.

#Cas 3 — Opérateur public : Lotus Notes vers Next.js + Payload en 18 mois

Contexte client : opérateur de service public sous tutelle ministérielle, environ 1 800 collaborateurs, 12 applications métier critiques développées en Lotus Notes (versions 6 à 8.5, mises en production entre 2003 et 2011). Au total 4 200 fonctionnalités identifiées, 78 000 utilisateurs internes, équipe IBM Domino interne réduite à 3 personnes (l'éditeur HCL Software ne fait quasi plus évoluer la stack, support déclinant). Trigger projet : décision politique d'abandon Lotus Notes à horizon 2027, contrainte budgétaire forte, nécessité de souveraineté numérique (hébergement français impératif).

Diagnostic Nehos mois 1 : 6 des 12 applications sont vraiment critiques, les 6 autres peuvent être consolidées dans une seule plateforme. Méthode appliquée : Strangler accéléré IA-assisted sur 18 mois pour les 6 applications critiques, consolidation parallèle des 6 secondaires. Stack cible : Next.js 16 + Payload CMS + Postgres 16 + Mistral Large 2 pour fonctionnalités IA (résumé automatique des dossiers métier), hébergement OVHcloud SecNumCloud Gravelines. IA-assistance : Claude Code particulièrement efficace sur le langage Lotus Script (proche de Visual Basic, mieux couvert que pur Lotus Notes), gain de productivité +45 % mesuré. Effort total : 2 400 jours-homme cumulés, budget 2099 k€ HT forfait fixe étalé 18 mois. Résultat : 6 applications critiques migrées en 18 mois sans interruption (Strangler complet appliqué), 6 secondaires consolidées dans une plateforme unique en parallèle (réduction de 50 % du parc applicatif), licence Lotus / HCL Domino arrêtée mois 20, économie annuelle récurrente 579 k€. Voir le cas client détaillé opérateur public (page dédiée).

#Chapitre 7 — ROI mesurable : -42 % maintenance, +60 % vélocité

#Le ROI d'une modernisation legacy n'est pas seulement technique

Quand on défend un projet de modernisation legacy devant un comité exécutif ou un conseil d'administration, la question revient toujours : « combien ça nous rapporte ? ». Mauvaise question — la bonne, c'est « combien ça nous coûte de ne rien faire ? ». Mais répondre proprement aux deux. Voici les KPIs financiers et opérationnels que nous mesurons systématiquement sur 24-36 mois post-modernisation, agrégés sur nos 6 projets délivrés 2024-2025.

#KPI 1 — Coût de maintenance annuel : -42 % moyenne, jusqu'à -55 %

La baisse du coût de maintenance est le KPI le plus directement chiffrable et le plus reproductible. Sur nos 6 projets, on mesure entre -28 % et -55 % de réduction du coût annuel de maintenance corrective et évolutive, médiane à -42 %. Trois composantes. Composante A : réduction du temps passé sur les bugs en production (stack moderne = 3 à 5 fois moins de bugs). Composante B : suppression des coûts de licence sur stack propriétaire obsolète (Oracle Forms, IBM Domino, Sage X3 ancienne génération, .NET Framework Enterprise). Composante C : réduction des coûts de recrutement et de rétention des profils legacy rares (salaires en hausse continue sur COBOL, VB6, Delphi).

#KPI 2 — Vélocité de développement nouvelles fonctionnalités : +60 % moyenne

La vélocité est l'autre KPI structurant. Mesurée en story points livrés par sprint ou en lead time feature-to-production, on observe systématiquement +40 % à +80 % d'augmentation sur les 12 mois suivant la fin de modernisation, médiane à +60 %. Trois drivers. Driver 1 : stack moderne plus productive (TypeScript bout-en-bout, frameworks à forte productivité native, écosystème open-source riche). Driver 2 : outils IA-assisted utilisables (impossible ou très peu efficace sur le legacy). Driver 3 : équipe interne plus motivée et plus capable de recruter (la stack cible attire des profils que le legacy ne pouvait plus attirer).

#KPI 3 — Conformité réglementaire facilitée

KPI moins quantitatif mais critique. La modernisation legacy facilite drastiquement la mise en conformité avec les régimes 2025-2027. DORA : registre Article 28 plus simple sur stack cloud auditable que sur mainframe. NIS2 : observabilité native vs collecte manuelle de logs sur legacy. RGPD : gestion des droits utilisateurs facilitée par stack moderne. AI Act : intégration de fonctionnalités IA conformes par design impossible sur la plupart des legacy. Sur nos 6 projets, 100 % des clients ont eu un audit de conformité validé sans réserve post-modernisation, vs 60 % de pré-conformité initiale moyenne.

#KPI 4 — Recrutement et rétention équipe IT

KPI souvent sous-estimé. La modernisation transforme la capacité de l'entreprise à recruter et retenir les développeurs. Sur nos 6 projets, on a mesuré : -65 % de turn-over équipe IT dans les 18 mois post-modernisation, +180 % de taux de réussite des recrutements (candidats acceptant l'offre vs prospects approchés), +35 % d'engagement collaborateur IT mesuré par enquête interne. Le legacy avait fait fuir les talents — la stack moderne les fait revenir.

#KPI 5 — TCO sur 5 ans : généralement positif à 24-36 mois

Le TCO (Total Cost of Ownership) cumulé sur 5 ans est le KPI synthétique. Sur les 6 projets, le break-even (point où la modernisation devient moins chère que le scénario « ne rien faire ») est atteint entre 24 et 42 mois post-démarrage, médiane à 30 mois. Au-delà, la modernisation génère un gain financier net cumulé. Sur 5 ans, on mesure typiquement 1,8 à 3,2 fois le coût initial de modernisation récupéré, ratio ROI 1:2 à 1:3.

#Modèle économique vs scénario « ne rien faire »

L'erreur classique des comités exécutifs est de comparer le coût de la modernisation au budget actuel de maintenance, sans intégrer la trajectoire croissante du legacy. La bonne comparaison : coût modernisation cumulé sur 5 ans vs coût legacy cumulé sur 5 ans en intégrant l'inflation des coûts (licence, recrutement, incidents). Sur ce calcul, 100 % de nos clients ont eu une décision favorable à la modernisation. Voir le secteur Énergie & Industrie Nehos pour les benchmarks sectoriels.

#Chapitre 8 — Risques et mitigations : régressions, savoir tacite, dette nouvelle

La modernisation legacy est puissante mais pas sans risque. Trois risques majeurs, et leurs mitigations éprouvées.

#Risque 1 — Régressions fonctionnelles silencieuses

Le risque le plus fréquent. Le legacy a 15-20 ans de comportements métier accumulés, dont une partie n'est pas documentée et n'est connue que par les utilisateurs opérationnels. Quand on réécrit, on risque d'introduire des régressions silencieuses : un calcul qui change de quelques centimes, une règle métier qui ne s'applique plus, un comportement de bordure qui disparaît. Ces régressions peuvent passer inaperçues pendant des mois avant d'éclater (typiquement à la clôture annuelle).

Mitigation Nehos. Mitigation A : shadow testing systématique pendant les phases 4 et 5. Les deux implémentations (legacy et moderne) reçoivent en parallèle les mêmes requêtes en production, on compare les résultats, on documente les divergences avant de basculer. Mitigation B : tests de non-régression automatisés générés à partir du comportement legacy observé (Cursor + Claude génèrent les tests à partir de s traces de production). Mitigation C : feature flag progressif (1 %, 5 %, 25 %, 50 %, 100 % de trafic) qui permet de détecter les divergences tôt sur un échantillon limité.

#Risque 2 — Perte du savoir tacite des collaborateurs sortants

Le deuxième risque majeur. Le legacy ne tient souvent que par le savoir d'un ou deux développeurs séniors qui connaissent l'historique des décisions techniques et les zones obscures du code. Quand ces personnes partent (retraite, départ volontaire, malheureusement parfois maladie), le risque est de perdre définitivement la capacité à comprendre certains modules.

Mitigation Nehos. Mitigation A : capter le savoir au plus tôt — dès la phase 1, on organise des sessions d'interview structurées avec les développeurs sénior pour documenter leur connaissance, on enregistre les sessions (audio + screenshots) pour archivage. Mitigation B : appliquer Claude Code en mode analyse pour extraire la documentation latente du code legacy (la doc est en partie dans le code, et le LLM la rend explicite). Mitigation C : associer activement les développeurs sénior à la migration (validation des modules réécrits, mentoring des juniors), ce qui valorise leur expertise et facilite leur transition. Mitigation D : sur les cas critiques, contractualiser un appui externe long terme avec l'expert sénior (consultant externe après son départ retraite, par exemple).

#Risque 3 — Dette technique nouvelle si la modernisation est mal menée

Le risque le plus pervers. Une modernisation mal pilotée peut accoucher d'un nouveau système qui devient à son tour un legacy en 8-10 ans. Symptômes : choix de stack à la mode mais sans maturité, architecture trop complexe pour les besoins métier, dépendances commerciales (SaaS lock-in), absence de tests automatisés, dette documentaire dès le départ.

Mitigation Nehos. Mitigation A : choix de stack maturité-first (Next.js + Payload + Postgres = combinaisons à très faible risque d'obsolescence sur 8-12 ans). Mitigation B : architecture simple par défaut, complexité ajoutée seulement quand nécessaire (microservices uniquement si le besoin le justifie, sinon monolithe modulaire). Mitigation C : objectif de couverture de tests automatisés supérieur à 70 % dès le go-live. Mitigation D : documentation continue intégrée au workflow de dev (chaque PR documente sa décision architecturale, archivée dans un ADR repository — Architecture Decision Records). Mitigation E : transfert de compétence systématique à l'équipe interne (formation, pair programming, code review), pour qu'elle puisse maintenir l'évolution sans dépendance Nehos à long terme.

#Risque 4 — Dépassement budgétaire et délais

Risque classique de tout projet IT. Sur les projets de modernisation, il est aggravé par l'incertitude initiale sur la complexité réelle du legacy. Notre réponse : forfait fixe garanti par phase (pas par projet entier), revue de scope à chaque fin de phase, droit de sortie client à chaque fin de phase. Le client n'est pas piégé dans un engagement long terme — il décide à chaque jalon de continuer.

#Risque 5 — Désengagement métier en cours de projet

Risque organisationnel. 18-36 mois de projet, c'est long. Les sponsors initiaux peuvent partir, les priorités métier peuvent changer, le projet peut perdre de la visibilité. Mitigation : livrables visibles tous les 3-4 mois (modules migrés concrets), reporting CODIR mensuel, communication interne régulière, association des opérationnels via démos en direct.

Pour cadrer votre situation, voir le service Legacy Modernization Nehos et la Méthode Legacy Strangler IA-Assisted complète.