Devis migration legacy .NET / Java vers stack moderne : budget et stratégies en 2026

Nous recevons régulièrement des demandes de devis pour migrer des applications .NET Framework ou Java EE vers des stacks modernes. La question est toujours la même : combien ça coûte ? La réponse dépend de trois variables : la taille du codebase, la complexité des intégrations et la stratégie de migration choisie. Cet article donne les repères pour les estimer.

La migration legacy est un sujet technique avant d'être commercial. Les DSI et les responsables techniques ont besoin de repères factuels pour arbitrer entre maintenir, moderniser ou réécrire. Pas de promesses vagues : les facteurs qui font vraiment varier un devis.

#Phase 1 : l'audit technique préalable

Toute migration sérieuse commence par un diagnostic. Notre audit technique dure quelques jours et couvre quatre axes. Il est chiffré sur devis, en 48 h après un premier échange.

Cartographie du codebase. Analyse statique du code source (.NET Framework 4.x, ASP.NET WebForms, Java EE 7/8, Spring Boot 1.x/2.x), mesure de la dette technique avec SonarQube, identification des dépendances obsolètes et des bibliothèques non maintenues. Nous mesurons le nombre de lignes de code, la couverture de tests, la complexité cyclomatique et le couplage entre modules.

Inventaire des intégrations. Chaque connexion à un système tiers (ERP, CRM, base de données, API partenaires, services SOAP, files de messages) est documentée avec son protocole, sa fréquence d'appel et sa criticité métier. C'est ce poste qui fait exploser les budgets quand il est sous-estimé.

Analyse de l'infrastructure. Serveurs IIS ou Tomcat, bases de données SQL Server ou Oracle, dépendances Windows spécifiques, certificats, tâches planifiées, jobs batch. Tout ce qui n'est pas dans le code source mais qui fait tourner l'application en production.

Recommandation stratégique. À l'issue de l'audit, nous livrons un rapport qui recommande la stratégie de migration la plus adaptée (strangler fig, big bang ou progressive) avec une estimation budgétaire et un planning macro.

La durée de l'audit dépend de la taille du codebase : quelques jours pour une petite application, davantage et avec deux architectes pour une grosse base de code.

#Les 3 stratégies de migration et leur impact budgétaire

Le choix de la stratégie est la décision la plus structurante du projet. Elle détermine le budget, le planning et le profil de risque.

#Strangler fig : migration module par module

Principe : on entoure l'application legacy d'une façade moderne et on migre les modules un par un. L'ancien et le nouveau coexistent en production pendant toute la durée du projet. Chaque module migré est immédiatement utilisable.

Avantages. Risque maîtrisé : si un module migré pose problème, on redirige le trafic vers l'ancien. Pas d'interruption de service. L'équipe métier valide chaque module avant de passer au suivant. Le retour sur investissement est progressif.

Inconvénients. Coût d'infrastructure de coexistence (reverse proxy, gestion de sessions partagées, synchronisation de données entre ancien et nouveau système). Surcoût par rapport au big bang.

Budget type. Le coût de base de la migration, plus le surcoût de coexistence. Il se chiffre sur devis après l'audit.

#Big bang : réécriture et bascule

Principe : on réécrit l'intégralité de l'application dans la stack cible, puis on bascule d'un coup. L'ancien système est éteint le jour de la mise en production du nouveau.

Avantages. Pas de coûts de coexistence. Architecture cible propre sans compromis liés à l'ancien système. Le code legacy peut être complètement abandonné.

Inconvénients. Risque d'échec élevé sur les gros projets. Pas de valeur livrée tant que la bascule n'est pas faite : si le projet dure un an, c'est un an sans retour sur investissement.

Budget type. Le budget de base, sans surcoût de coexistence. Mais le risque de dépassement est plus élevé : les avenants et les retards s'ajoutent fréquemment au budget initial.

#Migration progressive : modernisation par couches

Principe : on modernise l'application existante couche par couche sans la réécrire. Migration du framework (.NET Framework vers .NET 8, Java EE vers Spring Boot 3), mise à jour des dépendances, refactoring progressif du code, conteneurisation. L'application reste la même, mais sa stack technique est modernisée.

Avantages. Coût inférieur à une réécriture complète. La logique métier accumulée sur 10 ou 15 ans est préservée. Pas de régression fonctionnelle liée à une réinterprétation des spécifications.

Inconvénients. Ne convient pas si l'architecture est fondamentalement inadaptée (monolithe trop couplé, absence de séparation des responsabilités). La dette technique structurelle reste si elle n'est pas traitée explicitement.

Budget type. Moins élevé qu'une réécriture pour un périmètre équivalent. À chiffrer après l'audit.

#Repères par taille d'application

Les budgets se chiffrent sur devis. Voici les profils qui servent de base au chiffrage : un premier logiciel ou module sur mesure démarre à 15 000 € HT, un projet plus large à 30 000 € HT.

#Application simple

Profil : 5 000 à 25 000 lignes de code, 1 à 3 intégrations tierces, base de données de moins de 30 tables, 2-3 utilisateurs internes ou API métier isolée.

Exemples concrets : API de calcul tarifaire en ASP.NET WebForms, portail de suivi logistique en Java Struts, outil de reporting interne en WinForms.

Composition du budget. Audit et spécifications, architecture et setup, développement et migration, tests et recette, déploiement et formation.

Durée. 6 à 12 semaines. Équipe : 2 développeurs seniors + 1 architecte à temps partiel.

Stack cible type. .NET 8 / ASP.NET Core ou Spring Boot 3 + PostgreSQL, déployé en conteneurs Docker chez un hébergeur français ou sur AWS.

#Application moyenne

Profil : 25 000 à 80 000 lignes de code, 3 à 8 intégrations tierces (ERP, CRM, services SOAP, API REST), base de données de 30 à 100 tables, 20 à 200 utilisateurs quotidiens.

Exemples concrets : ERP de gestion commerciale en .NET Framework 4.6, plateforme métier en Java EE 7 avec JSF, application de gestion de sinistres en WCF/SOAP.

Composition du budget. Audit et architecture, développement backend, développement frontend, migration de données, refonte des intégrations, tests (fonctionnels, charge, sécurité).

Durée. 3 à 6 mois. Équipe : 3 à 5 développeurs seniors + 1 architecte + 1 chef de projet.

#Application complexe

Profil : 80 000+ lignes de code, 8+ intégrations tierces, architecture distribuée (services Windows, jobs batch, files de messages), base de données 100+ tables avec données critiques, contraintes réglementaires (RGPD, NIS2, DORA).

Exemples concrets : système de trading en C#/.NET, plateforme bancaire en Java EE, ERP industriel en ASP.NET MVC avec couche SOAP épaisse, système de gestion de production en WPF.

Composition du budget. Audit et architecture détaillée, développement backend et frontend, migration de données et ETL, refonte des intégrations, tests de régression, charge et sécurité, conduite du changement.

Durée. 6 à 18 mois. Équipe : 5 à 10 développeurs + 2 architectes + 1 delivery manager + 1 QA lead.

#Modernisation vs réécriture : la comparaison

Le tableau ci-dessous compare les deux approches sur un cas type : une application .NET Framework de taille moyenne avec quelques intégrations ERP/CRM.

Notre recommandation : la modernisation progressive est la bonne stratégie dans la plupart des cas. La réécriture se justifie quand l'architecture est fondamentalement inadaptée (couplage trop fort, absence de séparation des couches) ou quand les besoins métier ont radicalement changé depuis la conception initiale.

#Les 6 facteurs de risque qui font varier le devis

1. La couverture de tests existante. Une application bien couverte par des tests est plus rapide à migrer. Sans tests, il faut les écrire avant de toucher au code, ce qui ajoute du budget.

2. La qualité de la documentation. Pas de documentation fonctionnelle ? Prévoyez des ateliers de recueil de besoins avec les équipes métier.

3. Les dépendances propriétaires. Les composants Telerik, DevExpress, Crystal Reports ou les contrôles ActiveX nécessitent un remplacement sur mesure. Chaque composant propriétaire est un chantier à chiffrer.

4. Les services SOAP et WCF. La migration de services WCF vers des API REST modernes est un chantier en soi, variable selon la complexité de chaque service.

5. Les procédures stockées massives. Les applications legacy qui concentrent la logique métier dans des procédures stockées SQL Server ou Oracle nécessitent un travail d'extraction et de refactoring coûteux. Plus elles sont nombreuses, plus le surcoût est important.

6. L'authentification legacy. Windows Authentication, NTLM, Active Directory intégrée au code applicatif. La migration vers un système d'authentification moderne (OAuth2, OpenID Connect) dépend du nombre de flux à migrer.

#La méthodologie Nehos en 5 phases

Notre processus de modernisation legacy est structuré en 5 phases avec des jalons de validation à chaque étape.

Phase 1 : audit et diagnostic. Cartographie du codebase, inventaire des intégrations, analyse de l'infrastructure. Livrable : rapport d'audit avec recommandation stratégique et estimation budgétaire.

Phase 2 : architecture cible et planning. Définition de l'architecture cible, choix de la stack moderne, planning détaillé par sprint. Validation avec le client avant le démarrage du développement.

Phase 3 : migration itérative. Développement en sprints de 2 semaines avec démo client à chaque fin de sprint. En stratégie strangler fig, chaque module migré est déployé en production immédiatement.

Phase 4 : tests et validation. Tests de régression automatisés, tests de charge, tests de sécurité, validation fonctionnelle par les équipes métier. Nous visons un niveau de couverture de tests convenu avant la mise en production.

Phase 5 : bascule et stabilisation. Migration des données de production, bascule DNS, monitoring renforcé et support prioritaire après la mise en production.

Chaque devis est structuré poste par poste, avec un prix défini sur le périmètre validé. En régie, le développement est facturé 275 € HT/jour.

#Fiscalité et aides

Certains projets de modernisation peuvent relever de dispositifs fiscaux liés à l'innovation, comme le Crédit d'Impôt Innovation, quand ils intègrent des composants innovants. L'éligibilité dépend de votre entreprise, de la nature du projet et du prestataire : faites-la valider par votre expert-comptable avant de la budgéter.

Pour obtenir un devis personnalisé basé sur votre situation réelle, réservez un appel de découverte de 15 minutes. Vous repartez avec une première estimation et une recommandation de stratégie.

Photos : SHVETS production, Anna Shvets sur Pexels.