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.

#Beaucoup d'ETI s'appuient sur un ERP ancien

De nombreuses PME et ETI industrielles s'appuient sur un ERP ou un cœur de SI de plus de dix ans. Le problème se concentre sur les éditeurs disparus ou rachetés (versions anciennes de Sage X3, Cegid Y2, Microsoft Dynamics NAV 2009…) et sur des ERP propriétaires développés en interne dans les années 2000 par des équipes IT qui n'existent plus.

Côté banque, le COBOL tourne toujours sur de nombreux cœurs bancaires de grandes banques — la migration mainframe est en cours depuis des années, et reste majoritairement inachevée.

#La dette technique : un coût caché qui croît avec le temps

La dette technique désigne le coût cumulé des raccourcis, du vieillissement et du manque de documentation d'un système : maintenance excessive, opportunités business perdues, licences inutiles, productivité dégradée. Elle n'est pas linéaire : plus un système vieillit, plus il coûte cher à maintenir par rapport à un équivalent moderne, notamment à cause de la rareté des compétences. C'est cette progression qui rend le sujet incontournable au-delà d'un certain seuil.

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

Dans les audits de SI legacy, six symptômes reviennent systématiquement. Symptôme 1 : une part importante du temps de l'équipe dev est consacrée à la maintenance corrective de la dette. Symptôme 2 : les bugs en production sont nettement 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 rapport à une stack cible équivalente. Symptôme 4 : plus aucun développeur de l'équipe ne maîtrise l'intégralité du code (souvent une seule personne sait encore où passe quel batch nocturne).

Symptôme 5 : les mises à jour de sécurité sont décalées, faute de capacité à tester sans casser. Symptôme 6 : recrutement difficile des profils maîtrisant la stack source (COBOL, VB6, Delphi, AngularJS legacy), avec des salaires qui montent.

#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 assistés par IA (Claude Code, Cursor, GitHub Copilot, Aider, Cline) qui peuvent raccourcir nettement la 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 de 2003. Troisième : la pénurie de profils legacy.

Les développeurs COBOL vieillissent, les développeurs VB6 sont devenus introuvables, les profils Delphi se monnayent cher 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 les refontes brutales échouent souvent

#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.

#Des échecs fréquents et documentés

Le big bang échoue souvent : dépassement budgétaire, dépassement de délai, ou fonctionnalités majeures abandonnées. Dans certains cas, le projet est purement abandonné et l'entreprise retourne sur le legacy. La presse économique rapporte des cas emblématiques : Lidl a renoncé en 2018 à un projet SAP d'environ 500 M€ après sept ans d'efforts (Handelsblatt, 2018).

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 peut durer longtemps — plusieurs mois pour une ETI, plusieurs années 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 applique le Strangler Fig Pattern en six phases formalisées. Chacune a des livrables, une durée indicative et des indicateurs documentés.

#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 (généralement très faible 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 encapsulé 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 : 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 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 — très largement adopté — 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 la grande majorité des projets — y compris les projets historiquement Oracle ou SQL Server. Trois arguments. Premier : maturité et stabilité légendaires, des décennies 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 dépend de la qualité du code source et du langage : la phase de réécriture peut être nettement raccourcie, à condition de garder un développeur sénior dans la boucle.

#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 fortement réduit.

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 dans beaucoup d'organisations 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 : 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 : .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 : 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 avec un exemple de situation bancaire (détaillé au chapitre 6). Pour migrer un module COBOL vers Java 21, le workflow possible est le suivant : (1) Claude Code analyse le code COBOL et produit une documentation fonctionnelle en français des intentions du module ; (2) le lead COBOL sénior valide et corrige la documentation ; (3) Claude Code génère une première implémentation Java 21 + Spring Boot 3 ; (4) le développeur Java sénior corrige et durcit le code ; (5) Cursor génère les tests unitaires à partir du comportement legacy observé ; (6) des tests de non-régression en shadow testing valident le résultat.

L'IA accélère l'analyse et le brouillon, l'humain garde la validation. 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 exemples de situation : ETI, banque mutualiste, opérateur public

Les trois exemples ci-dessous sont des situations types construites pour illustrer la démarche, représentatives de la diversité des cas legacy en France. Ils ne décrivent pas des clients réels et ne comportent aucun résultat chiffré.

#Exemple 1 — ETI mécanique de précision : un ERP propriétaire ancien

Situation : une ETI française de mécanique de précision exploite un ERP développé en interne il y a près de vingt ans, sur une stack Java EE 5 + Oracle Forms + Oracle 10g. L'équipe IT interne est réduite et un seul développeur connaît l'intégralité du code, à quelques années de la retraite.

Déclencheurs : un audit de sécurité qui identifie des failles critiques non patchables sur la stack Java EE 5, et l'impossibilité technique de brancher l'ERP au MES Industry 4.0 que la direction industrielle veut déployer.

Démarche possible : un diagnostic de la dette technique en début de mission (niveau de dette, risque opérationnel lié au développeur unique), puis la méthode Nehos LSIA en 6 phases. Stack cible envisageable : Next.js + Payload + Postgres, avec Symfony 7 pour certains domaines métier complexes hérités de Java EE.

Ce que la démarche vise : un ERP modernisé sans interruption de production, le MES branché en cours de projet, le départ à la retraite du développeur sénior géré par un transfert de connaissance accompagné, et une équipe interne reformée à la nouvelle stack. Ce sont des objectifs, pas des résultats constatés.

#Exemple 2 — Banque mutualiste régionale : COBOL mainframe vers cloud Java microservices

Situation : une banque mutualiste régionale dont le core banking est en COBOL sur mainframe IBM Z, avec des millions de lignes de code accumulées depuis des décennies. L'équipe COBOL interne vieillit et plusieurs départs à la retraite sont programmés. Déclencheurs : la pression réglementaire DORA (le registre des fournisseurs critiques de l'article 28 est difficile à tenir avec un mainframe), la hausse continue des coûts de licence IBM, et la pression concurrentielle sur les API ouvertes (DSP3 à venir).

Démarche possible : une approche Strangler progressive, découpée en cycles successifs. Le premier cycle couvre les modules les plus stables et les mieux documentés ; les suivants traitent le reste. Stack cible envisageable : Java 21 + Spring Boot 3 + microservices sur Kubernetes chez un hébergeur qualifié SecNumCloud, Postgres (migration progressive depuis DB2 mainframe), Kafka pour l'événementiel, observabilité OpenTelemetry.

IA-assistance : Claude Code pour l'analyse du COBOL et la génération de documentation, avec un lead COBOL sénior obligatoire sur toutes les phases de traduction, le corpus COBOL étant trop rare dans le pré-entraînement des LLM pour une autonomie totale. Ce que la démarche vise : une migration par cycles sans incident de production majeur, un rollback rapide via l'API gateway en cas de problème, et une conformité DORA facilitée par une stack cloud auditable. Voir le secteur Banque-Assurance-Finance Nehos.

#Exemple 3 — Opérateur public : Lotus Notes vers Next.js + Payload

Situation : un opérateur de service public sous tutelle ministérielle exploite une douzaine d'applications métier critiques développées en Lotus Notes, mises en production entre 2003 et 2011. L'équipe IBM Domino interne est réduite et l'éditeur HCL Software fait peu évoluer la stack. Déclencheurs : une décision politique d'abandon de Lotus Notes à moyen terme, une contrainte budgétaire forte, et une exigence de souveraineté numérique (hébergement français).

Démarche possible : un diagnostic pour distinguer les applications vraiment critiques de celles qui peuvent être consolidées dans une seule plateforme, puis un Strangler accéléré assisté par IA pour les applications critiques. Stack cible envisageable : Next.js + Payload CMS + Postgres, Mistral Large 2 pour les fonctionnalités IA (résumé automatique des dossiers métier), hébergement chez un hébergeur qualifié SecNumCloud.

IA-assistance : Claude Code est particulièrement efficace sur le langage LotusScript, proche de Visual Basic et mieux couvert que le Lotus Notes pur. Ce que la démarche vise : des applications critiques migrées sans interruption, un parc applicatif réduit par consolidation, et l'arrêt des licences Lotus / HCL Domino. Ce sont des objectifs, pas des résultats constatés.

#Chapitre 7 — Mesurer le retour sur investissement : quels indicateurs suivre

#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 il faut répondre proprement aux deux. Nous ne promettons pas de gain chiffré à l'avance : voici les indicateurs financiers et opérationnels à fixer au démarrage et à suivre pendant et après la modernisation.

#Indicateur 1 — Coût de maintenance annuel

La baisse du coût de maintenance est l'indicateur le plus directement chiffrable. Trois composantes. Composante A : réduction du temps passé sur les bugs en production (une stack moderne en génère moins). Composante B : suppression des coûts de licence sur stack propriétaire obsolète (Oracle Forms, IBM Domino, anciennes versions de Sage X3, .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). On mesure le point de départ en phase 1, puis l'évolution à intervalles réguliers.

#Indicateur 2 — Vélocité de développement des nouvelles fonctionnalités

La vélocité est l'autre indicateur structurant. Elle se mesure en story points livrés par sprint ou en lead time entre l'idée et la mise en production. Trois facteurs jouent. Facteur 1 : une stack moderne plus productive (TypeScript bout-en-bout, frameworks à forte productivité native, écosystème open-source riche).

Facteur 2 : des outils assistés par IA utilisables (peu efficaces sur le legacy). Facteur 3 : une équipe interne plus motivée et plus capable de recruter, car la stack cible attire des profils que le legacy ne pouvait plus attirer.

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

Indicateur moins quantitatif mais critique. La modernisation legacy facilite la mise en conformité avec les régimes 2025-2027. DORA : registre de l'article 28 plus simple sur une stack cloud auditable que sur un mainframe. NIS2 : observabilité native plutôt que collecte manuelle de logs sur legacy.

RGPD : gestion des droits des utilisateurs facilitée par une stack moderne. AI Act : intégration de fonctionnalités IA conformes par design, impossible sur la plupart des legacy. L'indicateur à suivre : les audits de conformité validés, comparés à la situation avant modernisation.

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

Indicateur souvent sous-estimé. La modernisation transforme la capacité de l'entreprise à recruter et retenir les développeurs. On suit le turn-over de l'équipe IT, le taux de réussite des recrutements (candidats acceptant l'offre vs prospects approchés) et l'engagement mesuré par enquête interne. Le legacy fait fuir les talents ; une stack moderne peut les faire revenir.

#Indicateur 5 — Coût total de possession sur 5 ans

Le TCO (Total Cost of Ownership) cumulé sur 5 ans est l'indicateur synthétique. Il permet de situer le point de bascule (break-even) à partir duquel la modernisation devient moins chère que le scénario « ne rien faire ». Ce point dépend de chaque situation : il se calcule en phase 1, sur vos coûts réels de licence, de maintenance et d'incidents.

#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 de modernisation cumulé sur 5 ans vs coût du legacy cumulé sur 5 ans en intégrant l'inflation des coûts (licence, recrutement, incidents). Voir le secteur Énergie & Industrie Nehos.

#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.

Photos : Yan Krukau, ThisIsEngineering, pipop kunachon sur Pexels.