Modernize Studio
Langue: FR
Nous écrire

Vos applications .NET anciennes, WinForms et Web Forms, modernisées

Les applications écrites pour .NET Framework dans les années 2000 et 2010 sont en général en meilleur état que les outils VB6 ou Access, et elles méritent une réponse plus mesurée qu'une réécriture complète. Nous établissons ce qui peut être repris tel quel et ce qui doit être reconstruit, puis nous portons l'application vers ASP.NET Core avec les mêmes données et les mêmes règles.

Demander l'analyse gratuite Estimer le prix

Pourquoi maintenant

Le support de .NET Framework 4.6.2 prend fin le 12/01/2027, et les versions 4.6.1 et antérieures ne sont déjà plus prises en charge. .NET Framework 4.8 et 4.8.1 suivent le cycle de vie de la version de Windows sur laquelle ils sont installés : une application en 4.8 n'est donc pas en danger immédiat. Le framework ne reçoit toutefois plus que des correctifs, alors que les nouvelles bibliothèques, les outils et les offres d'hébergement visent le .NET actuel.

ASP.NET Web Forms ne fonctionne que sur .NET Framework et n'a pas été repris dans ASP.NET Core. Windows Forms fonctionne bien sur le .NET actuel, mais reste une technologie de bureau Windows et ne donne pas à vos équipes un accès depuis un navigateur.

  1. Windows 10Fin du support Microsoft
  2. .NET Framework 4.6.2Fin du support Microsoft

Ce que nous modernisons

Les applications de bureau et web construites sur .NET Framework, et les services qui les entourent.

  • Applications Windows Forms

    Programmes de bureau avec grilles DataGridView, DataSets typés et TableAdapters, souvent déployés par ClickOnce ou MSI. Ils deviennent des applications web, ou passent au .NET actuel en restant des programmes de bureau quand c'est le meilleur choix.

  • Sites ASP.NET Web Forms

    Pages avec ViewState, postbacks, UpdatePanel, GridView et SqlDataSource, pages maîtres et contrôles utilisateur. Nous les reconstruisons en ASP.NET Core avec Razor Pages, MVC ou Blazor, selon l'application.

  • Accès aux données

    Code ADO.NET, DataSets typés, LINQ to SQL, modèles Entity Framework 6 et procédures stockées. Quand la base est saine, nous la gardons et ne changeons que le code qui l'interroge.

  • Services et intégrations

    Services web WCF et ASMX, .NET Remoting et services Windows. Ils deviennent des API REST et des services d'arrière-plan sur le .NET actuel.

  • Authentification et configuration

    Forms Authentication, fournisseur Membership d'ASP.NET, authentification Windows, paramètres dans web.config et app.config. Utilisateurs et rôles passent dans ASP.NET Core Identity, ou dans Microsoft Entra ID ou Active Directory si vous les utilisez déjà.

  • États

    Crystal Reports pour Visual Studio, états RDLC dans ReportViewer et exports Excel. Ils deviennent des documents produits par le serveur, en PDF ou en Excel.

À quoi ressemble la version web

Exemple illustratif, données fictives

Un suivi de loyers tel qu'il pourrait se présenter dans un programme WinForms, puis le même suivi sous forme de page web.

Faites glisser la poignée, ou utilisez les flèches du clavier.

Ce que devient chaque élément

Dans .NET Framework: Écrans WinForms ou pages .aspx
Dans l'application web: Razor Pages ou composants Blazor
Dans .NET Framework: Code-behind et gestionnaires d'événements
Dans l'application web: Services et contrôleurs couverts par des tests
Dans .NET Framework: DataSets typés, LINQ to SQL
Dans l'application web: Entity Framework Core ou Dapper, sur la même base
Dans .NET Framework: Services WCF ou ASMX
Dans l'application web: API REST sur ASP.NET Core
Dans .NET Framework: Membership et Forms Authentication
Dans l'application web: ASP.NET Core Identity ou Entra ID
Dans .NET Framework: ClickOnce ou MSI sur chaque poste
Dans l'application web: Une adresse, ouverte dans le navigateur

Comment se déroule la migration

  1. Analyse sous 48 heures

    Vous nous envoyez la solution avec son code source, une sauvegarde ou un script de la base, et les fichiers de configuration sans les mots de passe de production. Sous 48 heures, nous vous répondons par un rapport écrit : ce que fait le programme aujourd'hui, où se situent les risques, comment s'organiserait la version web, un prix ferme pour un module pilote et une estimation pour le reste. L'analyse est gratuite et ne vous engage à rien.

  2. Module pilote

    Nous réalisons une partie de l'application sur une copie de vos données réelles, en général celle que vos équipes utilisent le plus. Elles s'en servent au quotidien avant que vous décidiez de la suite.

  3. Tests automatisés ancien contre nouveau

    Nous envoyons les mêmes requêtes et les mêmes données à l'ancienne et à la nouvelle application, et comparons les résultats, des champs calculés aux réponses d'API et aux documents générés. Chaque règle identifiée fait l'objet d'un test automatisé qui fournit les mêmes entrées à l'ancien programme et à la nouvelle application, puis vérifie que les résultats concordent. Vous recevez les résultats des tests.

  4. 30 jours en parallèle

    Une fois l'application complète livrée, l'ancienne application reste en service à ses côtés pendant 30 jours. Toute différence apparaît tant que l'ancien programme est encore là, et nous la corrigeons dans le cadre du prix convenu.

Les pièges habituels, et comment nous les traitons

  1. ViewState et logique de postback

    Les pages Web Forms conservent leur état dans le ViewState et dans Session, et leur logique est répartie entre Page_Load, les événements des contrôles et les tests IsPostBack. ASP.NET Core n'a pas d'équivalent. Nous transposons le cycle de vie des pages en requêtes explicites, pour que chaque action ait un point d'entrée clair.

  2. Des API qui n'existent plus

    Les domaines d'application, .NET Remoting et la sécurité d'accès du code (CAS) ne sont pas disponibles sur le .NET actuel, et certaines API compilent mais lèvent PlatformNotSupportedException à l'exécution. Nous les recherchons dans le code pendant l'analyse, avant de fixer un prix.

  3. Mots de passe Membership

    Les comptes créés par l'ancien fournisseur Membership d'ASP.NET stockent les mots de passe dans un format de hachage qu'ASP.NET Core Identity n'utilise pas. Nous migrons les comptes pour que chacun se connecte avec son mot de passe actuel et que le hachage soit mis à niveau à la première connexion, ou nous prévoyons une réinitialisation si les anciens paramètres ne le permettent pas.

  4. Contrôles tiers et moteurs d'états

    Les suites de contrôles pour Web Forms et WinForms, comme celles de Telerik, DevExpress ou Infragistics, et le runtime Crystal Reports sont liés à des versions précises du framework. Nous vérifions versions et licences, et décidons contrôle par contrôle de ce qui les remplace.

  5. Règles dans les procédures stockées et les déclencheurs

    Dans beaucoup d'applications de cette époque, les vraies règles métier se trouvent dans la base. Si la base reste, ces procédures restent aussi et sont couvertes par les tests de comparaison. Si elle change, nous les déplaçons une à une, en connaissance de cause.

  6. État conservé en mémoire

    Les applications qui gardent des données dans Session, dans des variables statiques ou dans le cache en mémoire supposent un serveur unique qui ne redémarre jamais. Nous rendons cet état explicite, pour que la nouvelle application puisse tourner sur plusieurs instances et survivre à un redémarrage.

Prix et paiement

Analyse

Gratuite

écrite, sous 48 heures

Module pilote

1 000–1 500 €

en général, réglé 50 % au démarrage et 50 % à la validation

L'analyse est gratuite. Si vous décidez de ne pas donner suite, vous gardez le rapport et ne devez rien.

Les prix sont fermes et convenus par écrit avant le démarrage. Si le périmètre change, nous vous envoyons un nouveau devis écrit et attendons votre accord avant de réaliser le travail supplémentaire.

Pour une migration complète, nous visons un prix inférieur de 40 à 60 % au devis habituel d'une agence. C'est possible parce que nous sommes un petit studio, sans locaux à payer ni équipe commerciale.

Prix hors TVA.

Essayer l'estimateur de prix

Une vraie migration, vérifiée par des tests

Northwind est la base d'exemple que Microsoft fournissait avec Access, pas l'un de nos clients. Nous en avons migré une copie publique vers SQLite et PostgreSQL, comparé chaque table et chaque requête à l'original par des tests automatisés, et construit une application web qui fonctionne sur le résultat. L'étude de cas donne les chiffres, le rapport d'équivalence détaille chaque contrôle.

Northwind est une base Access, mais nous suivons la même méthode pour .NET WinForms et WebForms : migrer, tester face à l'original, faire tourner les deux en parallèle.

Lire l'étude de casOuvrir l'application web (en anglais)

Rapport d'équivalence (en anglais) · Aperçu cliquable et analyse d'exemple (démo)

Questions fréquentes

Faut-il tout réécrire ?

Non. Les bibliothèques de classes qui portent la logique métier passent souvent au .NET actuel avec peu de modifications, et la base peut en général rester. Ce qui change le plus, c'est l'interface : les pages Web Forms et les écrans WinForms. L'analyse sépare ce qui peut être repris de ce qui doit être reconstruit.

Notre application WinForms peut-elle rester un programme de bureau ?

Oui. Windows Forms est pris en charge sur le .NET actuel, et y passer prolonge la vie du programme pour moins cher qu'une réécriture web. Si vos utilisateurs ont besoin d'un accès depuis un navigateur ou hors du bureau, l'application web est la réponse. Quand les deux ont du sens, l'analyse chiffre les deux.

Notre application tourne sur .NET Framework 4.8. Est-ce urgent ?

Pas pour une question de support, puisque 4.8 et 4.8.1 suivent le cycle de vie de la version de Windows qui les héberge. Les raisons de migrer sont en général autres : accès depuis un navigateur, hébergement sous Linux, bibliothèques qui ne ciblent plus .NET Framework, ou difficulté à trouver des développeurs Web Forms.

La migration peut-elle se faire par étapes ?

Oui. ASP.NET Core et l'ancienne application peuvent fonctionner côte à côte derrière la même adresse, une partie étant migrée après l'autre. La documentation de Microsoft décrit elle-même cette approche progressive pour les applications ASP.NET.

Utilisez-vous des outils de migration automatique ?

Là où ils sont utiles, par exemple pour mettre à jour les fichiers de projet et les références de paquets. Ils ne décident pas de la façon dont une page Web Forms doit fonctionner dans ASP.NET Core, et chaque partie convertie passe par les mêmes tests de comparaison que le reste.

Quelle base de données utiliserons-nous ?

En général celle que vous avez déjà, le plus souvent SQL Server. Changer de base est une décision à part, que nous ne recommandons qu'avec une raison claire.

Nos autres services

Contact

Par e‑mail :

riccardo@modernizestudio.com
Écrire un e‑mail

Envoyez-nous le code source et une copie de la base avec des données fictives, ou une courte description de l'application. Nous vous répondons sous un jour ouvré.

Nous travaillons depuis l'Italie.

Nous écrire