Legacy Modernization — Refactor IA-assisté de COBOL, Java, PHP, .NET, Oracle Forms

#Modernisation logiciel legacy -- Refactor IA-assiste de COBOL, Java, PHP, .NET, Oracle Forms

Votre ERP tourne sur du COBOL depuis 1997. Votre CRM est un monolithe PHP 5 que plus personne dans l'equipe ne maitrise entierement. Votre application Oracle Forms fait tourner la production, mais le dernier developpeur qui comprenait le code est parti il y a trois ans. Vous le savez : ca tient, mais ca ne tiendra plus longtemps.

Chez Nehos Groupe, on modernise des logiciels legacy depuis 2017. On a commence avec des methodes classiques -- rewrite manuel, migration progressive. Depuis 2024, on integre Claude Code et Cursor dans le workflow de refactor. Le resultat mesure sur 5 projets entre 2024 et 2025 : le temps de reecriture est divise par 2 a 4 selon le langage source, sans degrader la qualite du code livre.

On ne promet pas de miracles. On promet une methode structuree, des resultats mesurables et une transparence totale sur ce que l'IA sait faire -- et sur ce qu'elle ne sait pas faire. Ce guide detaille notre approche complete : diagnostic, strategie de migration, stack cible, role de l'IA-assistance, gestion du changement et retour sur investissement.

#La dette technique : pourquoi vous ne pouvez plus la repousser

Tous les DSI grands comptes le savent : la dette technique se paie. Plus on attend, plus elle coute. On a observe sur 18 audits de SI legacy chez des ETI francaises entre 2023 et 2025 trois constats recurrents.

35 % du temps de l'equipe dev est consacre a la maintenance de la dette -- contre 15 % attendu en equipe saine. Autrement dit, un tiers de votre budget dev part dans du colmatage, pas dans de la creation de valeur.

Les bugs production sont 3 a 5 fois plus frequents que sur une stack moderne equivalente. Chaque incident coute du temps de diagnostic, de correction et de deploiement -- sans compter l'impact business sur vos utilisateurs.

Le cout d'ajout d'une fonctionnalite metier est multiplie par 2 a 8 par rapport a la stack cible equivalente. Quand il faut 6 mois pour ajouter un champ dans un formulaire parce que le code est tellement imbriqué que personne n'ose toucher a la logique metier, le calcul devient deraisonnable.

A un moment, payer la modernisation coute moins cher que continuer a entretenir le legacy. La question n'est plus "faut-il moderniser" mais "quand et comment". Pour chiffrer votre situation, notre Observatoire de la dette technique des ETI francaises 2026 documente les benchmarks par secteur.

#Six signes que votre SI legacy est en zone critique

1. Vos developpeurs preferent ajouter une couche au lieu de modifier l'existant. C'est le symptome classique du code spaghetti accumule sur 15 ou 20 ans. Chaque nouvelle couche ajoute de la complexite sans resoudre le probleme de fond.

2. Plus aucun developpeur de l'equipe ne maitrise l'integralite du code. Le developpeur historique est parti, la documentation est inexistante ou obsolete. Le risque operationnel sur le turnover est critique : si votre dernier expert COBOL part, vous etes bloque.

3. Les mises a jour de securite sont decalees de 6 mois ou plus. Chaque faille CVE non corrigee est une porte ouverte. Et sur un systeme legacy, appliquer un patch de securite peut casser des dependances en cascade.

4. Le langage source n'a plus de support communautaire. PHP 5 est en fin de vie depuis 2018. Java 7 depuis 2015. .NET Framework est en maintenance etendue. COBOL n'a jamais eu de communaute open source significative. Le recrutement devient difficile et les salaires montent -- quand vous trouvez quelqu'un.

5. Le delai d'ajout d'une fonctionnalite metier depasse 6 mois. Votre metier evolue, la reglementation change, vos clients demandent de nouvelles fonctionnalites. Si votre SI ne peut pas suivre, c'est votre competitivite business qui est compromise.

6. Le cout de licence de votre stack proprietaire augmente chaque annee. Oracle, IBM, Microsoft : les editeurs de solutions proprietaires augmentent regulierement leurs tarifs. Une migration vers une stack open source (Postgres, Linux, Java Spring Boot) peut diviser le cout de licence par 5 a 10.

#Les trois strategies de modernisation : refactor, replatform, rebuild

Avant de coder une seule ligne, il faut choisir la bonne strategie. Trois approches existent, chacune avec ses avantages et ses limites. Le choix depend de l'etat du code existant, du budget disponible et de la criticite metier du systeme.

#Refactoring -- moderniser sans reecrire

Le refactoring consiste a ameliorer le code existant sans changer son comportement externe. On restructure, on nettoie, on extrait des modules, on ajoute des tests. Le systeme reste fonctionnellement identique, mais le code devient maintenable et evolutif.

Quand choisir le refactoring : quand le code existant est de qualite acceptable et que la logique metier est solide. Quand le cout d'une reecriture complete n'est pas justifie. Quand les equipes internes connaissent le code et peuvent accompagner la transformation.

Limites : le refactoring ne change pas la stack technique. Si vous etes sur PHP 5 et que vous refactorisez du PHP 5, vous restez sur PHP 5 -- avec tous les problemes de securite et de recrutement que ca implique. Le refactoring est une amelioration incrementale, pas une transformation.

Cout typique : a partir de 25 000 EUR pour un module isole. Le refactoring est generalement 2 a 4 fois moins cher qu'un rebuild complet.

#Replatforming -- changer le socle technique

Le replatforming consiste a migrer l'application vers une nouvelle plateforme technique sans reecrire la logique metier. On change l'infrastructure (du on-premise vers le cloud), le runtime (de Java 8 vers Java 21), la base de donnees (d'Oracle vers Postgres). L'application reste la meme, mais elle tourne sur un socle moderne.

Quand choisir le replatforming : quand le probleme principal est l'infrastructure, pas le code. Quand les licences proprietaires coutent trop cher. Quand vous devez migrer vers le cloud pour des raisons de scalabilite ou de conformite.

Limites : si le code est du spaghetti, le mettre dans le cloud ne resout rien. Vous aurez du spaghetti dans le cloud. Le replatforming est pertinent quand le code est sain mais que l'infrastructure est obsolete.

Cout typique : a partir de 40 000 EUR pour une migration d'infrastructure avec adaptation du runtime. Variable selon la complexite des dependances.

#Rebuild -- reecrire de zero

Le rebuild consiste a reecrire l'application a partir de zero sur une stack moderne. C'est l'approche la plus radicale, la plus couteuse, et la plus risquee. Mais c'est parfois la seule option quand le code existant est tellement degrade que le refactoring ou le replatforming ne sont pas viables.

Quand choisir le rebuild : quand le code est inmaintenable (zero test, zero documentation, complexite cyclomatique explosive). Quand la stack source est tellement obsolete qu'aucune migration progressive n'est possible. Quand le cout cumule du refactoring depasserait celui du rebuild.

Limites : le rebuild est le scenario le plus risque. On perd la logique metier implicite accumulee dans le code legacy -- les cas limites, les regles d'exception, les workarounds qui compensent des bugs connus. Et on perd du temps : pendant que vous reecrivez, le legacy continue de tourner et d'accumuler des evolutions que le nouveau systeme devra rattraper.

Cout typique : a partir de 121 000 EUR pour un projet complet, selon scope et complexite.

#Comment on tranche chez Nehos

Notre diagnostic de 5 jours (a partir de 1 522 EUR) repond a cette question avec des donnees. On mesure la qualite du code (scan statique, complexite cyclomatique, couverture de tests), on cartographie les dependances, on evalue la criticite metier de chaque module. En sortie, on delivre un score de dette technique (0-100) et une recommandation argumentee : refactor, replatform, rebuild ou decommissioning. Pas de recommandation generique -- un chiffrage module par module.

#Le pattern Strangler Fig : migration sans rupture de service

Le Strangler Fig pattern, popularise par Martin Fowler, est le coeur de notre methode. Le principe : construire le nouveau systeme a cote de l'ancien, basculer progressivement le trafic, decommissionner l'ancien quand 100 % du trafic est migre.

C'est l'inverse du Big Bang. Pas de nuit de bascule ou tout peut echouer. Pas de rupture de service. Possibilite de rollback a tout moment.

#Comment ca marche concretement

Etape 1 -- Decoupe en bandes fonctionnelles. On identifie les modules metier du legacy et on les classe par priorite de migration. Criteres : criticite business, complexite technique, couplage avec d'autres modules. On commence par les modules les plus isoles et les moins critiques -- pour roder le processus avant d'attaquer le coeur du systeme.

Etape 2 -- Construction de la nouvelle bande. On developpe le module equivalent sur la stack cible. Tests automatises exhaustifs : unitaires, integration, end-to-end. Le comportement du nouveau module doit etre strictement identique a celui de l'ancien. C'est la que l'IA-assistance via Claude Code et Cursor accelere le plus : la phase de reecriture est divisee par 2 a 4 selon le langage source.

Etape 3 -- Routage progressif. On installe un routeur (API gateway ou feature flags) entre les utilisateurs et les deux systemes. On bascule 10 % du trafic vers le nouveau module. On surveille les metriques : taux d'erreur, temps de reponse, coherence des donnees. Si tout est nominal, on monte a 25 %, 50 %, puis 100 %.

Etape 4 -- Dual-run. Pendant 30 a 90 jours, les deux systemes tournent en parallele. On compare les sorties en temps reel. Le moindre ecart declenche une alerte et une investigation. C'est le filet de securite ultime.

Etape 5 -- Decommissioning. Quand 100 % du trafic est migre et que le dual-run n'a revele aucune anomalie, on decommissionne le module legacy. Archivage des donnees historiques, mise a jour de la documentation, audit de sortie.

#Pourquoi on deconseille fortement le Big Bang

Le Big Bang -- reecriture complete puis bascule en une nuit -- a un taux d'echec catastrophique. Le risque operationnel est maximal : si quelque chose casse, tout casse en meme temps. Les seuls cas ou le Big Bang est defendable : application qui peut accepter 1 a 2 jours d'indisponibilite, volume de code inferieur a 30 000 lignes et zero integration externe critique. Quasiment jamais en banque, industrie ou administration. Notre position est claire : on ne fait pas de Big Bang sur un SI critique.

#Notre methode proprietaire : Nehos Legacy Strangler IA-Assisted

On a combine le pattern Strangler Fig avec l'IA-assistance pour creer la methode Nehos Legacy Strangler IA-Assisted. Voici les 6 etapes du processus complet.

#Etape 1 -- Diagnostic dette technique (5 jours, a partir de 1 522 EUR)

Audit complet du SI legacy. Cartographie des modules, scan statique du code, analyse des dependances, entretiens avec votre equipe dev. Output : rapport chiffre avec score de dette (0-100), risques operationnels, recommandation de strategie. Tarif fixe, pas de surprise.

#Etape 2 -- Architecture cible et plan migration (2 a 4 semaines)

Definition de la stack moderne cible : Next.js + Symfony 7, Java Spring Boot 3, .NET 8 ou Go selon le contexte. Decoupage en bandes fonctionnelles Strangler Fig. Planning detaille sur 12 a 36 mois. ADRs (Architecture Decision Records) documentes. On ne commence jamais a coder avant que le plan ne soit valide par votre equipe.

#Etape 3 -- Build des nouvelles bandes (phases de 8 a 16 semaines)

Implementation des nouvelles bandes fonctionnelles a cote du legacy. Tests automatises exhaustifs. CI/CD GitHub Actions. Code review humaine systematique du code IA-assiste. Reviews architecture mensuelles avec votre Tech Lead interne. L'IA accelere la production, mais c'est le developpeur senior qui valide chaque ligne.

#Etape 4 -- Migration progressive et dual-run

Mise en production de chaque bande nouvelle. Routage progressif (10 %, 25 %, 50 %, 100 %) via feature flags (PostHog, Unleash) ou API gateway (Kong, Traefik). Dual-run pendant 30 a 90 jours pour validation comportementale. Rollback operationnel a tout moment.

#Etape 5 -- Decommissioning legacy

Decommissionnement progressif des modules legacy une fois 100 % du trafic bascule. Archivage des donnees historiques. Mise a jour de la documentation. Audit de sortie sur la nouvelle stack : securite, performances, observabilite.

#Etape 6 -- MCO post-migration

Maintien en condition operationnelle sur la nouvelle stack moderne. Monitoring (Sentry + Grafana + Prometheus), mises a jour securite, evolutions fonctionnelles. Vous restez libre : vos equipes internes peuvent reprendre la main a 100 % ou continuer en MCO avec Nehos. Pas de lock-in.

#Pourquoi Claude Code change la donne sur le refactor legacy

On utilise Claude Code en production sur tous nos projets de modernisation depuis octobre 2024. Pas comme gadget marketing -- comme outil de productivite quotidien. Voici ce qu'on a appris, en toute transparence. Pour un comparatif detaille des outils, consultez notre analyse Cursor vs Claude Code vs Copilot.

#Ce qui marche vraiment

Analyse du code legacy. Le LLM lit la base de code, identifie les modules, genere la documentation manquante. 4 fois plus rapide qu'une analyse manuelle. Sur un monolithe PHP de 200 000 lignes, Claude Code a produit une cartographie complete des dependances en 2 jours au lieu des 8 jours habituels.

Reecriture du code. Sur PHP, Java moderne, Python, C# -- gain reel de 2 a 4 fois. Le developpeur senior valide et corrige le code genere, il ne le tape pas. Le workflow : le LLM propose la traduction vers la stack cible, le dev review, corrige les cas limites et valide. C'est du pair programming avec un assistant qui ne dort pas.

Generation de tests. Le LLM produit des cas de test exhaustifs a partir du comportement legacy observe. Sur nos 5 projets 2024-2025, la couverture de tests est passee de 30-40 % a 70-80 % typiquement. Les cas limites que les developpeurs oublient sont souvent ceux que le LLM detecte en premier.

Documentation. Architecture decision records, README, runbooks -- tout est genere en qualite production en sortie de projet. Fini les projets livres sans documentation.

#Ce qui ne marche pas (et on l'assume)

COBOL. Le corpus LLM est faible sur COBOL -- trop peu de code source dans le pre-training. On garde un lead COBOL senior obligatoire en review. Le LLM aide a 30-40 %, pas plus. On documente cette limite dans nos devis et on ne la cache pas.

Delphi et VB6. Meme probleme que COBOL : corpus rare, qualite variable du code genere. L'IA assiste, mais ne remplace pas l'expertise humaine sur ces stacks.

Logique metier opaque. Si le code legacy implemente des regles metier non documentees (et c'est quasiment toujours le cas sur un SI de 15 ans), le LLM ne peut pas les inventer. C'est le developpeur senior qui comprend l'intent metier en collaborant avec vos equipes. L'IA execute, elle n'invente pas la strategie.

Architecture. Un LLM ne fera pas spontanement un decoupage Strangler Fig. C'est un architecte humain qui concoit la strategie de migration, definit les bandes fonctionnelles et arbitre les compromis techniques. L'IA est un outil, pas un architecte.

#L'approche API-first et la migration cloud

Moderniser un legacy, c'est aussi repenser l'architecture d'integration. La plupart des systemes legacy communiquent par fichiers plats, par base de donnees partagee ou par appels RPC proprietaires. C'est fragile, non scalable et impossible a monitorer correctement.

#Pourquoi API-first

On pose systematiquement une couche API REST (ou GraphQL selon le contexte) entre chaque module du nouveau systeme. Trois raisons.

Decouplage. Chaque module peut evoluer independamment. Une modification du module facturation ne casse pas le module gestion de commandes. C'est la condition pour une maintenance saine a long terme.

Interoperabilite. Vos partenaires, vos clients et vos outils internes (BI, CRM, ERP) se connectent via des API standards. Plus de connecteurs ad hoc, plus de fichiers CSV echanges par email.

Observabilite. Chaque appel API est trace, mesure et alerte. Vous savez exactement ce qui se passe dans votre SI en temps reel, pas 48 heures apres un incident.

#Migration cloud souveraine

Notre stack cible standard est hebergee en France : OVH par defaut, SecNumCloud pour les projets regules (banque, sante, defense), Scaleway en alternative. On ne pousse pas AWS, Azure ou GCP par defaut -- on documente toujours l'alternative souveraine dans nos recommandations.

La containerisation Docker + Kubernetes est systematique. Chaque service tourne dans son conteneur, se deploie independamment, se scale horizontalement. Le monitoring est integre des le jour 1 : Sentry pour les erreurs applicatives, Grafana + Prometheus pour les metriques d'infrastructure.

Pour les contextes qui l'exigent (banque sous DORA, administration sous NIS2), on recommande un hebergement SecNumCloud avec audit de securite externe. C'est plus cher, mais c'est le prix de la conformite -- et les sanctions en cas de non-conformite coutent bien plus.

#La strategie de tests : zero regression en production

Sur 5 projets de refactor IA-assiste en 2024-2025, zero regression critique livree en production. Ce n'est pas de la chance -- c'est une strategie de tests en quatre couches.

#Couche 1 -- Tests unitaires (generes par IA, valides par humain)

Le LLM genere les tests unitaires a partir du comportement observe du code legacy. Le developpeur senior les review, ajoute les cas limites metier que le LLM n'a pas detectes, et valide. Couverture cible : 70 % minimum, 80 % quand le module est critique.

#Couche 2 -- Tests d'integration

Chaque module est teste dans son interaction avec les modules adjacents. Les contrats d'API sont valides automatiquement. Les tests d'integration tournent a chaque pull request dans la CI/CD.

#Couche 3 -- Tests end-to-end

Les parcours utilisateurs critiques sont automatises (Playwright, Cypress). Chaque release candidate passe par la batterie complete de tests end-to-end avant le deploiement.

#Couche 4 -- Dual-run en production

Le filet de securite ultime. Les deux systemes (legacy et nouveau) traitent le meme trafic en parallele pendant 30 a 90 jours. On compare les sorties en temps reel. Le moindre ecart est investigue avant de basculer definitivement. C'est cette couche qui garantit que la modernisation n'introduit pas de regression invisible.

#Gestion du changement : le facteur humain

La technologie, c'est 50 % du travail. L'autre moitie, c'est le facteur humain. On a vu des projets de modernisation techniquement reussis echouer parce que les equipes internes n'avaient pas ete embarquees.

#Equipe mixte Nehos + client

Notre mode de fonctionnement prefere : une equipe mixte. Typiquement 4 a 6 ETP Nehos + 2 a 5 ETP de vos equipes internes. Vos developpeurs montent en competence sur la stack cible et sur les outils IA pendant le projet. A la fin, votre equipe peut reprendre la main en autonomie. C'est notre objectif : construire pour que vous repreniez le controle, pas pour vous fideliser artificiellement.

#Formation et montee en competence

On propose en option (mais fortement recommande) une formation Qualiopi de 3 a 10 jours. Modules : maitrise de la stack cible (Symfony 7, Java Spring Boot, .NET 8), methodes de refactor IA-assiste (Claude Code en equipe), gouvernance qualite du code IA-genere, monitoring et observabilite moderne. Public : vos developpeurs seniors qui reprendront le projet en autonomie. Financement OPCO possible.

#Communication avec les metiers

Les utilisateurs finaux doivent comprendre ce qui change et pourquoi. On produit des release notes lisibles par des non-techniques, on planifie des sessions de demonstration a chaque bande livree, on recueille les retours et on les integre dans les bandes suivantes. Le Strangler Fig a un avantage majeur ici : les changements sont progressifs, pas un choc unique.

#ROI et chiffrage : ce que ca coute, ce que ca rapporte

Parlons chiffres. Pas de fourchettes vagues -- des donnees issues de nos projets.

#Couts typiques

#Duree typique

12 a 36 mois pour une modernisation complete par bandes Strangler Fig. Chaque bande est livree en 8 a 16 semaines. La premiere bande genere de la valeur des sa mise en production -- pas besoin d'attendre la fin du projet pour en tirer des benefices.

#Retour sur investissement mesure

Sur nos 3 cas clients documentes :

Banque mutualiste -- migration COBOL vers Java Spring Boot. 3 modules migres sur 12. Duree reduite de 40 % par rapport a l'estimation initiale grace a l'IA-assistance. Le cout de maintenance de ces 3 modules a baisse de 60 % des la premiere annee. Voir le cas client complet.

ETI industrielle -- migration Oracle Forms vers Next.js + API REST. 5 applications migrees. ROI atteint a 14 mois. Equipe interne en autonomie complete a partir du mois 18. L'economie annuelle sur les licences Oracle a elle seule representait 35 % du cout du projet. Voir le cas client complet.

ETI services B2B -- refactor PHP 5 / Symfony 2 vers Symfony 7 + PHP 8.3. Refactor en 9 mois au lieu des 18 mois estimes sans IA-assistance. Velocite de l'equipe interne en hausse de 60 % post-migration. Le temps de deploiement d'une nouvelle fonctionnalite est passe de 3 semaines a 3 jours. Voir le cas client complet.

#Le calcul que vous devez faire

Prenez votre cout annuel de maintenance legacy (salaires des devs legacy + licences + incidents production + cout d'opportunite des fonctionnalites non livrees). Multipliez par 3 (horizon 3 ans). Comparez au cout de la modernisation. Sur les 18 audits qu'on a realises, la modernisation etait moins chere que le statu quo dans 14 cas sur 18. Pour les 4 cas restants, le legacy etait suffisamment sain pour justifier un refactoring leger plutot qu'une migration complete.

#Cas d'usage par stack legacy

#COBOL et mainframe (secteur bancaire)

Le sujet par excellence. Les banques mutualistes et les assureurs ont des millions de lignes COBOL qui font tourner le core banking depuis les annees 80. La migration est longue (24 a 36 mois minimum pour un perimetre significatif), couteuse et sensible -- mais ineluctable. Le vivier de developpeurs COBOL se tarit, les salaires montent, et les obligations reglementaires (DORA, NIS2) imposent une modernisation du SI. Notre equipe combine un lead COBOL senior avec l'IA-assistance pour les langages cibles (Java Spring Boot, .NET). Stack cible souveraine recommandee (hebergement francais, SecNumCloud si applicable). En savoir plus sur la migration COBOL vers Java.

#Oracle Forms (industrie, secteur public)

Les applications Oracle Forms 10g et 11g sont omnipresentes dans l'industrie et le secteur public. Des milliers d'ecrans, des dizaines d'annees de logique metier accumulee. Le pattern Strangler Fig est particulierement adapte : on migre ecran par ecran vers une application web Next.js + API REST, sans interrompre la production. L'economie sur les licences Oracle finance une partie du projet. En savoir plus sur la migration Oracle Forms.

#PHP legacy / Symfony 2-3 (PME et ETI)

C'est le cas ou l'IA-assistance est la plus efficace. Le corpus PHP dans les LLMs est massif -- Claude Code genere du code PHP/Symfony de qualite production avec un taux de correction minime. On migre de PHP 5/7 et Symfony 2-3 vers Symfony 7 + PHP 8.3 en conservant la logique metier et en modernisant l'architecture. Sur notre dernier projet, le refactor a pris 9 mois au lieu des 18 estimes. En savoir plus sur la migration PHP/Symfony.

#.NET Framework / VB6 (applications Windows)

Les applications C# legacy (.NET Framework, WinForms, VB6) sont frequentes dans les PME industrielles. Migration vers .NET 8 + EF Core + Postgres. Compatible hebergement Azure souverain ou OVH. Le challenge principal : les applications VB6 avec interface graphique riche, ou l'IA-assistance est moins performante en raison du corpus LLM limite. On garde un lead .NET senior (Sana Elmokhtar chez Nehos) pour la review et les arbitrages. En savoir plus sur la migration VB6/.NET.

#Delphi / WinForms (applications client lourd 90s-2000s)

Les applications Delphi sont le legacy des PME industrielles qui ont informatise leurs processus dans les annees 90 et 2000. Client lourd Windows, base de donnees locale, zero API. La migration vers une application web necessite une reecriture quasi complete -- c'est l'un des rares cas ou le rebuild se justifie plus que le refactoring. L'IA-assistance aide moderement (corpus Delphi rare), mais elle accelere massivement la construction de la stack cible. En savoir plus sur la migration Delphi.

#Monolithe vers microservices

Pas forcement du legacy au sens "vieux code" -- mais un monolithe Java 8 ou PHP 7 de 300 000 lignes qui ne scale plus est un probleme de modernisation. On decoupe en services avec le pattern Strangler Fig, en utilisant l'IA pour l'analyse des dependances entre modules. Stack cible : microservices Next.js + Go pour les services performance-critical + Postgres. En savoir plus sur le decoupage monolithe.

#Modernisation core banking : un cas particulier

Pour les banques sous DORA et NIS2, la modernisation de core banking est un sujet a part. Trois principes non negociables chez Nehos.

Zero Big Bang. Uniquement du Strangler Fig avec dual-run prolonge (90 jours minimum). Sur un core banking, un Big Bang rate peut couter des millions en pertes operationnelles et en sanctions reglementaires.

Audit de securite externe obligatoire. Tests de resilience operationnelle (TIBER-EU si applicable), monitoring tiers ICT, incident reporting framework conforme DORA. On travaille avec un cabinet partenaire pour les audits de securite.

Stack cible souveraine. Java Spring Boot + Postgres + hebergement francais, idealement SecNumCloud. Pas de dependance a un cloud provider americain pour un core banking europeen. Pour le detail reglementaire, consultez notre page dediee a la conformite DORA bancaire.

Pour les projets dans le secteur Banque, Assurance & Finance, on adapte notre methode aux contraintes specifiques du secteur : gouvernance renforcee, comite de pilotage mensuel avec la DSI et la direction des risques, documentation de conformite exhaustive.

#Stacks legacy couvertes et stack cible

#9 stacks legacy couvertes

Notre equipe maitrise les langages et frameworks suivants : COBOL (avec lead senior dedie), Java 7-8 / Java EE (Mohamed Tarroumi en lead), PHP 5-7 / Symfony 2-3 / Drupal 7 (Mohamed Tarroumi + Houssem Baklouti), .NET Framework / C# legacy (Sana Elmokhtar en lead), VB6, Oracle Forms 10g/11g, Delphi, ASP Classic, AngularJS / jQuery legacy.

Pour les stacks rares (RPG iSeries, PowerBuilder, FoxPro), on evalue au cas par cas. On n'accepte un projet que si on peut garantir la qualite de la livraison.

#Stack cible standard

La stack cible depend du contexte du client :

• Source PHP : Symfony 7 + PHP 8.3 + Postgres 16
• Source Java : Spring Boot 3 ou Quarkus + Postgres 16
• Source .NET : .NET 8 + EF Core + Postgres 16
• Source Oracle Forms : Next.js 16 + Symfony 7 backend + Postgres 16
• Source mainframe : Java Spring Boot ou .NET selon la culture interne du client

Hebergement : OVH par defaut, SecNumCloud pour les projets regules, Scaleway en alternative. L'agence IA Nehos integre systematiquement les outils IA pour dev (Claude Code, Cursor) dans le workflow de developpement.

#Outillage

• Claude Code pour le refactor IA-assiste (PHP, Java, Python, C# moderne)
• Cursor IDE pour la collaboration humaine + IA
• Docker + Kubernetes pour la containerisation
• API gateway (Kong, Traefik) pour le routage dual-run
• Feature flags (PostHog, Unleash) pour le routage progressif
• Monitoring : Sentry + Grafana + Prometheus
• CI/CD : GitHub Actions

#Questions frequentes sur la modernisation legacy

Combien coute la modernisation d'une application COBOL bancaire ?

Tres variable selon le scope. Migration d'un module isole de 20 a 50 000 lignes COBOL : a partir de 200 000 EUR. Migration d'un core banking complet (200 000+ lignes, plusieurs modules interconnectes) : plusieurs millions d'euros sur 24 a 36 mois. Notre diagnostic dette technique (a partir de 1 522 EUR, 5 jours) chiffre precisement votre cas.

Combien de temps prend un refactor Strangler Fig sur un monolithe Java ?

12 a 36 mois selon taille et complexite. Chaque bande fonctionnelle est migree en 8 a 16 semaines. Sur un monolithe Java 8 de taille moyenne (300 000 lignes, 15 modules), on compte typiquement 18 mois pour un refactor complet en parallele de la maintenance courante. Avec IA-assistance, on observe un gain de 30 a 40 % par rapport a l'estimation initiale.

Claude Code est-il vraiment utilisable sur du code legacy critique ?

Oui, avec discernement. Trois criteres. Le langage source doit etre dans le corpus LLM (PHP, Java, Python, C#, JavaScript -- oui ; COBOL, Delphi, VB6 -- partiellement). Le code genere est systematiquement review par un dev senior -- on ne livre jamais du code IA non review en prod. Les tests automatises sont la garantie principale : si les tests passent, le code refactorise est conforme au comportement original. Sur 5 projets refactor en 2024-2025, zero regression critique livree en production. Documentation officielle Claude Code.

Comment garantir zero impact sur la production pendant la migration ?

Quatre garde-fous. Le pattern Strangler Fig : on construit a cote, on ne touche pas a l'ancien tant que le nouveau n'est pas pret. Le dual-run obligatoire : les deux systemes tournent en parallele 30 a 90 jours, on compare les sorties en temps reel. Le routage progressif via feature flags : on bascule 10 %, 25 %, 50 %, 100 % du trafic en surveillant les metriques. Le rollback operationnel a tout moment : retour au legacy en quelques minutes via le routeur.

Quelle stack cible recommandez-vous pour une reecriture en 2026 ?

Ca depend du contexte. Si la source est PHP : Symfony 7 + PHP 8.3 + Postgres. Si Java : Spring Boot 3 ou Quarkus + Postgres. Si .NET : .NET 8 + EF Core + Postgres. Si Oracle Forms : Next.js 16 + Symfony 7 backend + Postgres. Hebergement OVH par defaut, SecNumCloud pour les projets regules. On documente toujours l'alternative souveraine.

Pouvez-vous travailler avec nos equipes internes ?

C'est notre mode prefere. Equipe mixte : 4 a 6 ETP Nehos + 2 a 5 ETP de vos equipes. Vos devs montent en competence pendant le projet. A la fin, votre equipe reprend la main en autonomie. Pas de lock-in.

Que se passe-t-il si l'IA hallucine sur un module critique ?

Trois lignes de defense. Revue humaine systematique -- aucun code IA n'est livre sans validation d'un dev senior. Couverture de tests superieure a 70 % -- si les tests passent, le comportement metier est conforme a l'original. Dual-run en production 30 a 90 jours -- on compare les sorties du legacy et du nouveau systeme sur du trafic reel. Resultat : zero regression critique sur 5 projets.

L'IA-assistance fonctionne-t-elle aussi bien sur tous les langages legacy ?

Non, et on l'assume. Bons resultats : PHP, Java moderne, Python, C#, JavaScript, TypeScript, Go. Resultats moyens : Java 7, Ruby legacy, ASP.NET MVC. Faibles : COBOL, Delphi, VB6, FoxPro, PowerBuilder. Pour les langages rares, on garde un lead senior obligatoire -- l'IA aide a 20 a 40 %, pas plus. On documente cette dependance dans nos devis.

Pouvez-vous faire un Big Bang plutot qu'un Strangler Fig ?

Techniquement oui, mais on deconseille fortement. Le Big Bang a un taux d'echec eleve. Le Strangler Fig reduit le risque operationnel et permet de capturer la valeur progressivement. Les seuls cas defendables : application tolerant 1 a 2 jours d'indisponibilite, volume de code inferieur a 30 000 lignes, zero integration critique. Quasiment jamais en banque, industrie ou administration.

#Demarrer un projet de modernisation legacy

On ne commence jamais par du code. On commence par un diagnostic. 5 jours, a partir de 1 522 EUR, tarif fixe. En sortie : un score de dette technique, une cartographie de vos modules, une recommandation de strategie argumentee et un chiffrage par bande fonctionnelle.

Reservez 30 minutes avec Mohamed Tarroumi (Lead Dev PHP Fullstack) ou Chokri Siala (CTO). On comprend votre SI legacy, on identifie les bandes prioritaires, on chiffre une approche Strangler Fig realiste. Pas de commercial, pas de pitch generique : un expert technique qui connait votre contexte.

Vous pouvez aussi lancer notre diagnostic dette technique gratuit en 10 questions pour obtenir un premier score et une premiere orientation avant de nous contacter.