Modernisation d'applications legacy : réduire la dette technique sans tout réécrire

#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 entièrement. Votre application Oracle Forms fait tourner la production, mais le dernier développeur 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 avec des méthodes classiques -- rewrite manuel, migration progressive -- et on intègre Claude Code et Cursor dans le workflow de refactor. Le gain sur la phase de réécriture dépend du langage source ; on le mesure projet par projet, sans dégrader la qualité du code livre.

On ne promet pas de miracles. On promet une méthode structurée, des résultats 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, stratégie 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. Trois constats reviennent dans tous les SI legacy.

Une part croissante du temps de l'equipe dev est consacree à la maintenance de la dette. Autrement dit, une part importante de votre budget dev part dans du colmatage, pas dans de la création de valeur.

Les bugs production sont plus frequents que sur une stack moderne équivalente. Chaque incident coute du temps de diagnostic, de correction et de déploiement -- sans compter l'impact business sur vos utilisateurs.

Le coût d'ajout d'une fonctionnalité métier explose par rapport à la stack cible équivalente. Quand il faut des mois pour ajouter un champ dans un formulaire parce que le code est tellement imbriqué que personne n'ose toucher a la logique métier, le calcul devient déraisonnable.

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

#Six signes que votre SI legacy est en zone critique

1. Vos développeurs préfèrent ajouter une couche au lieu de modifier l'existant. C'est le symptôme classique du code spaghetti accumule sur 15 ou 20 ans. Chaque nouvelle couche ajoute de la complexité sans résoudre le problème de fond.

2. Plus aucun développeur de l'equipe ne maitrise l'intégralité du code. Le développeur historique est parti, la documentation est inexistante ou obsolete. Le risque opérationnel sur le turnover est critique : si votre dernier expert COBOL part, vous êtes bloque.

3. Les mises à jour de sécurité sont décalées de 6 mois ou plus. Chaque faille CVE non corrigée est une porte ouverte. Et sur un système legacy, appliquer un patch de sécurité peut casser des dépendances 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 étendue. COBOL n'a jamais eu de communauté open source significative. Le recrutement devient difficile et les salaires montent -- quand vous trouvez quelqu'un.

5. Le délai d'ajout d'une fonctionnalité métier depasse 6 mois. Votre métier evolue, la réglementation change, vos clients demandent de nouvelles fonctionnalités. Si votre SI ne peut pas suivre, c'est votre compétitivité business qui est compromise.

6. Le coût de licence de votre stack propriétaire augmente chaque année. Oracle, IBM, Microsoft : les éditeurs de solutions propriétaires augmentent régulièrement leurs tarifs. Une migration vers une stack open source (Postgres, Linux, Java Spring Boot) peut diviser le coût 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 stratégie. Trois approches existent, chacune avec ses avantages et ses limites. Le choix depend de l'état du code existant, du budget disponible et de la criticite métier du système.

#Refactoring -- moderniser sans réécrire

Le refactoring consiste a améliorer le code existant sans changer son comportement externe. On restructure, on nettoie, on extrait des modules, on ajoute des tests. Le système reste fonctionnellement identique, mais le code devient maintenable et évolutif.

Quand choisir le refactoring : quand le code existant est de qualité acceptable et que la logique métier est solide. Quand le coût d'une réécriture 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 êtes sur PHP 5 et que vous refactorisez du PHP 5, vous restez sur PHP 5 -- avec tous les problèmes de sécurité et de recrutement que ca implique. Le refactoring est une amelioration incrementale, pas une transformation.

Coût : sur devis, selon le périmètre. Le refactoring est généralement beaucoup moins cher qu'un rebuild complet.

#Replatforming -- changer le socle technique

Le replatforming consiste a migrer l'application vers une nouvelle plateforme technique sans réécrire la logique métier. On change l'infrastructure (du on-premise vers le cloud), le runtime (de Java 8 vers Java 21), la base de données (d'Oracle vers Postgres). L'application reste la même, mais elle tourne sur un socle moderne.

Quand choisir le replatforming : quand le problème principal est l'infrastructure, pas le code. Quand les licences propriétaires coûtent trop cher. Quand vous devez migrer vers le cloud pour des raisons de scalabilite ou de conformité.

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

Coût : sur devis, variable selon la complexité des dépendances.

#Rebuild -- réécrire de zero

Le rebuild consiste a réécrire l'application à partir de zero sur une stack moderne. C'est l'approche la plus radicale, la plus coûteuse, et la plus risquée. 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, complexité cyclomatique explosive). Quand la stack source est tellement obsolete qu'aucune migration progressive n'est possible. Quand le coût cumule du refactoring dépasserait celui du rebuild.

Limites : le rebuild est le scenario le plus risque. On perd la logique métier implicite accumulée dans le code legacy -- les cas limites, les règles d'exception, les workarounds qui compensent des bugs connus. Et on perd du temps : pendant que vous réécrivez, le legacy continue de tourner et d'accumuler des évolutions que le nouveau système devra rattraper.

Coût : sur devis, selon scope et complexité.

#Comment on tranche chez Nehos

Notre diagnostic de 5 jours répond a cette question avec des données. On mesure la qualité du code (scan statique, complexité cyclomatique, couverture de tests), on cartographie les dépendances, on evalue la criticite métier de chaque module. En sortie, on delivre un score de dette technique (0-100) et une recommandation argumentée : refactor, replatform, rebuild ou decommissioning. Pas de recommandation générique -- 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 méthode. Le principe : construire le nouveau système à côté 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 échouer. Pas de rupture de service. Possibilité de rollback a tout moment.

#Comment ca marche concrètement

Étape 1 -- Decoupe en bandes fonctionnelles. On identifie les modules métier du legacy et on les classe par priorité de migration. Critères : criticite business, complexité 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 système.

Étape 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 être 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 réécriture est accélérée, dans une mesure qui dépend du langage source.

Étape 3 -- Routage progressif. On installe un routeur (API gateway ou feature flags) entre les utilisateurs et les deux systèmes. On bascule 10 % du trafic vers le nouveau module. On surveille les métriques : taux d'erreur, temps de réponse, coherence des données. Si tout est nominal, on monte a 25 %, 50 %, puis 100 %.

Étape 4 -- Dual-run. Pendant 30 a 90 jours, les deux systèmes tournent en parallèle. On compare les sorties en temps réel. Le moindre écart declenche une alerte et une investigation. C'est le filet de sécurité ultime.

Étape 5 -- Decommissioning. Quand 100 % du trafic est migre et que le dual-run n'a révélé aucune anomalie, on decommissionne le module legacy. Archivage des données historiques, mise à jour de la documentation, audit de sortie.

#Pourquoi on deconseille fortement le Big Bang

Le Big Bang -- réécriture complete puis bascule en une nuit -- a un taux d'échec catastrophique. Le risque opérationnel 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'indisponibilité, volume de code inférieur 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 méthode propriétaire : Nehos Legacy Strangler IA-Assisted

On a combine le pattern Strangler Fig avec l'IA-assistance pour créer la méthode Nehos Legacy Strangler IA-Assisted. Voici les 6 étapes du processus complet.

#Étape 1 -- Diagnostic dette technique (5 jours)

Audit complet du SI legacy. Cartographie des modules, scan statique du code, analyse des dépendances, entretiens avec votre equipe dev. Output : rapport chiffre avec score de dette (0-100), risques opérationnels, recommandation de stratégie. Périmètre et livrables fixés avant de démarrer.

#Étape 2 -- Architecture cible et plan migration (quelques 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.

#Étape 3 -- Build des nouvelles bandes (phases de 8 à 16 semaines)

Implementation des nouvelles bandes fonctionnelles à côté du legacy. Tests automatises exhaustifs. CI/CD GitHub Actions. Code review humaine systématique du code IA-assiste. Reviews architecture mensuelles avec votre Tech Lead interne. L'IA accelere la production, mais c'est le développeur senior qui valide chaque ligne.

#Étape 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 opérationnel a tout moment.

#Étape 5 -- Decommissioning legacy

Decommissionnement progressif des modules legacy une fois 100 % du trafic bascule. Archivage des données historiques. Mise à jour de la documentation. Audit de sortie sur la nouvelle stack : sécurité, performances, observabilite.

#Étape 6 -- MCO post-migration

Maintien en condition opérationnelle sur la nouvelle stack moderne. Monitoring (Sentry + Grafana + Prometheus), mises à jour sécurité, 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 au quotidien sur nos projets de modernisation. Pas comme gadget marketing -- comme outil de productivité 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. Nettement plus rapide qu'une analyse manuelle.

Réécriture du code. Sur PHP, Java moderne, Python, C# -- gain reel. Le développeur 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. La couverture de tests augmente nettement. Les cas limites que les développeurs oublient sont souvent ceux que le LLM detecte en premier.

Documentation. Architecture decision records, README, runbooks -- tout est genere en qualité 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. L'aide du LLM reste limitée. On documente cette limite dans nos devis et on ne la cache pas.

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

Logique métier opaque. Si le code legacy implemente des règles métier non documentées (et c'est quasiment toujours le cas sur un SI de 15 ans), le LLM ne peut pas les inventer. C'est le développeur senior qui comprend l'intent métier en collaborant avec vos equipes. L'IA execute, elle n'invente pas la stratégie.

Architecture. Un LLM ne fera pas spontanément un decoupage Strangler Fig. C'est un architecte humain qui conçoit la stratégie de migration, définit 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'intégration. La plupart des systèmes legacy communiquent par fichiers plats, par base de données partagée ou par appels RPC propriétaires. C'est fragile, non scalable et impossible a monitorer correctement.

#Pourquoi API-first

On pose systématiquement une couche API REST (ou GraphQL selon le contexte) entre chaque module du nouveau système. Trois raisons.

Decouplage. Chaque module peut évoluer indépendamment. Une modification du module facturation ne casse pas le module gestion de commandes. C'est la condition pour une maintenance saine à long terme.

Interopérabilité. 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 réel, pas 48 heures après un incident.

#Migration cloud souveraine

Notre stack cible standard est hébergée en France : OVH par défaut, SecNumCloud pour les projets régulés (banque, santé, defense), Scaleway en alternative. On ne pousse pas AWS, Azure ou GCP par défaut -- on documente toujours l'alternative souveraine dans nos recommandations.

La containerisation Docker + Kubernetes est systématique. Chaque service tourne dans son conteneur, se déploie indépendamment, se scale horizontalement. Le monitoring est intégré des le jour 1 : Sentry pour les erreurs applicatives, Grafana + Prometheus pour les métriques d'infrastructure.

Pour les contextes qui l'exigent (banque sous DORA, administration sous NIS2), on recommande un hébergement SecNumCloud avec audit de sécurité externe. C'est plus cher, mais c'est le prix de la conformité -- et les sanctions en cas de non-conformité coûtent bien plus.

#La stratégie de tests : zero regression en production

Notre objectif est zéro régression critique en production. Ce n'est pas de la chance -- c'est une stratégie de tests en quatre couches.

#Couche 1 -- Tests unitaires (générés par IA, valides par humain)

Le LLM genere les tests unitaires a partir du comportement observe du code legacy. Le développeur senior les review, ajoute les cas limites métier que le LLM n'a pas détectés, et valide. Couverture cible : 70 % minimum, 80 % quand le module est critique.

#Couche 2 -- Tests d'intégration

Chaque module est teste dans son interaction avec les modules adjacents. Les contrats d'API sont valides automatiquement. Les tests d'intégration tournent à 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 déploiement.

#Couche 4 -- Dual-run en production

Le filet de sécurité ultime. Les deux systèmes (legacy et nouveau) traitent le même trafic en parallèle pendant 30 a 90 jours. On compare les sorties en temps réel. Le moindre écart est investigue avant de basculer définitivement. 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 moitié, c'est le facteur humain. On a vu des projets de modernisation techniquement réussis échouer parce que les equipes internes n'avaient pas été embarquées.

#Equipe mixte Nehos + client

Notre mode de fonctionnement prefere : une equipe mixte. Nehos et vos equipes internes travaillent ensemble. Vos développeurs 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 fidéliser artificiellement.

#Formation et montée en competence

On propose en option (mais fortement recommande) une formation de plusieurs jours. Modules : maitrise de la stack cible (Symfony 7, Java Spring Boot, .NET 8), méthodes de refactor IA-assiste (Claude Code en equipe), gouvernance qualité du code IA-genere, monitoring et observabilite moderne. Public : vos développeurs seniors qui reprendront le projet en autonomie.

#Communication avec les métiers

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 à chaque bande livrée, 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

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

Nous ne publions pas de grille de prix pour la modernisation legacy : l'écart entre un module isolé et un core banking est trop grand. Nous chiffrons sur devis en 48 h après un premier échange, après un diagnostic de 5 jours si le périmètre est flou.

#Coûts : ce qui entre dans le chiffrage

• Diagnostic dette technique (5 jours)
• Architecture cible et plan de migration
• Projet de modernisation, par bande fonctionnelle
• MCO post-migration, en option

Pour de la maintenance logicielle, notre repère est de 750 € par mois. Pour du développement en régie, 275 € HT par jour.

#Durée

Plusieurs mois à plusieurs années pour une modernisation complète par bandes Strangler Fig. Chaque bande est livrée par phases de quelques semaines. La première bande génère de la valeur dès sa mise en production -- pas besoin d'attendre la fin du projet pour en tirer des bénéfices.

#Ce qu'on mesure

Avant et après chaque bande : temps de déploiement d'une nouvelle fonctionnalité, coût de maintenance, nombre d'incidents en production, économie de licences propriétaires. Nous ne promettons pas de retour chiffré à l'avance.

#Le calcul que vous devez faire

Prenez votre coût annuel de maintenance legacy (salaires des devs legacy + licences + incidents production + coût d'opportunité des fonctionnalités non livrées). Multipliez par 3 (horizon 3 ans). Comparez au coût de la modernisation. Dans certains cas, le legacy est suffisamment sain pour justifier un refactoring léger plutôt qu'une migration complète : c'est précisément ce que le diagnostic établit.

#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 années 80. La migration est longue (plusieurs années pour un périmètre significatif), coûteuse et sensible -- mais ineluctable. Le vivier de développeurs COBOL se tarit, les salaires montent, et les obligations réglementaires (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 recommandée (hébergement français, 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 omniprésentes dans l'industrie et le secteur public. Des milliers d'écrans, des dizaines d'années de logique métier accumulée. Le pattern Strangler Fig est particulièrement adapte : on migre écran par écran vers une application web Next.js + API REST, sans interrompre la production.

L'économie 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 qualité 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 métier et en modernisant l'architecture. 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 hébergement 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 années 90 et 2000. Client lourd Windows, base de données locale, zero API. La migration vers une application web necessite une réécriture quasi complete -- c'est l'un des rares cas ou le rebuild se justifie plus que le refactoring.

L'IA-assistance aide modérément (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 problème de modernisation. On decoupe en services avec le pattern Strangler Fig, en utilisant l'IA pour l'analyse des dépendances 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 négociables 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 coûter des millions en pertes opérationnelles et en sanctions réglementaires.

Audit de sécurité externe obligatoire. Tests de resilience opérationnelle (TIBER-EU si applicable), monitoring tiers ICT, incident reporting framework conforme DORA. On s'appuie sur un cabinet spécialisé pour les audits de sécurité.

Stack cible souveraine. Java Spring Boot + Postgres + hébergement français, idéalement SecNumCloud. Pas de dépendance a un cloud provider américain pour un core banking européen. Pour le detail réglementaire, consultez notre page dédiée à la conformité DORA bancaire.

Pour les projets dans le secteur Banque, Assurance & Finance, on adapte notre méthode aux contraintes spécifiques du secteur : gouvernance renforcée, comité de pilotage mensuel avec la DSI et la direction des risques, documentation de conformité 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 qualité 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

Hébergement : OVH par défaut, SecNumCloud pour les projets régulés, Scaleway en alternative. L'agence IA Nehos integre systématiquement les outils IA pour dev (Claude Code, Cursor) dans le workflow de développement.

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

Très variable selon le scope : un module isolé n'a rien à voir avec un core banking complet. Notre diagnostic dette technique (5 jours) chiffre précisément votre cas. Devis en 48 h après un premier échange.

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

Plusieurs mois à plusieurs années selon taille et complexité. Chaque bande fonctionnelle est migrée par phases de quelques semaines. Le refactor se fait en parallèle de la maintenance courante. L'IA-assistance réduit le temps de réécriture ; nous mesurons le gain sur votre projet.

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

Oui, avec discernement. Trois critères. Le langage source doit être dans le corpus LLM (PHP, Java, Python, C#, JavaScript -- oui ; COBOL, Delphi, VB6 -- partiellement). Le code genere est systématiquement 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. Documentation officielle Claude Code.

Comment garantir zero impact sur la production pendant la migration ?

Quatre garde-fous. Le pattern Strangler Fig : on construit à côté, on ne touche pas a l'ancien tant que le nouveau n'est pas prêt. Le dual-run obligatoire : les deux systèmes tournent en parallèle 30 a 90 jours, on compare les sorties en temps réel. Le routage progressif via feature flags : on bascule 10 %, 25 %, 50 %, 100 % du trafic en surveillant les métriques. Le rollback opérationnel a tout moment : retour au legacy en quelques minutes via le routeur.

Quelle stack cible recommandez-vous pour une réécriture 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. Hébergement OVH par défaut, SecNumCloud pour les projets régulés. On documente toujours l'alternative souveraine.

Pouvez-vous travailler avec nos equipes internes ?

C'est notre mode prefere. Equipe mixte Nehos et 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 systématique -- aucun code IA n'est livre sans validation d'un dev senior. Couverture de tests supérieure a 70 % -- si les tests passent, le comportement métier est conforme a l'original. Dual-run en production 30 a 90 jours -- on compare les sorties du legacy et du nouveau système sur du trafic reel. Objectif : zero regression critique.

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

Non, et on l'assume. Bons résultats : PHP, Java moderne, Python, C#, JavaScript, TypeScript, Go. Résultats 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 de façon limitée. On documente cette dépendance dans nos devis.

Pouvez-vous faire un Big Bang plutôt qu'un Strangler Fig ?

Techniquement oui, mais on deconseille fortement. Le Big Bang a un taux d'échec eleve. Le Strangler Fig réduit le risque opérationnel et permet de capturer la valeur progressivement. Les seuls cas défendables : application tolerant 1 a 2 jours d'indisponibilité, volume de code inférieur a 30 000 lignes, zero integration critique. Quasiment jamais en banque, industrie ou administration.

#Démarrer un projet de modernisation legacy

On ne commence jamais par du code. On commence par un diagnostic. 5 jours. En sortie : un score de dette technique, une cartographie de vos modules, une recommandation de stratégie argumentée et un chiffrage par bande fonctionnelle.

Réservez 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 réaliste. Pas de commercial, pas de pitch générique : un expert technique qui connaît votre contexte.

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