ASP.NET WebForms en 2026 : maintenir, migrer ou réécrire ?

Une application ASP.NET WebForms encore utilisée n’est pas automatiquement à remplacer. La bonne décision dépend de sa stabilité, de sa maintenabilité, de ses contraintes de sécurité et des évolutions métier attendues.

WebForms repose sur .NET Framework et sur un modèle serveur différent d’ASP.NET Core. Une migration demande donc généralement de repenser l’interface, les dépendances et une partie de l’architecture, pas simplement de changer la version du framework.

Dans quels cas continuer avec WebForms ?

• L’application est stable et peu évolutive.

• Les compétences et les procédures d’exploitation sont disponibles.

• Les dépendances restent supportables et correctement sécurisées.

• Une migration apporterait peu de valeur métier à court terme.

Dans ce cas, documenter, tester et sécuriser l’existant peut être plus rationnel qu’une refonte précipitée.

Quels signaux justifient de préparer une migration ?

• Les évolutions deviennent lentes ou risquées.

• Les tests automatisés et les déploiements sont difficiles.

• L’application dépend de composants non maintenus.

• Les nouvelles intégrations nécessitent des API ou des mécanismes difficiles à ajouter.

• L’interface doit devenir web moderne, mobile ou mieux accessible.

• Le recrutement et la transmission de connaissance deviennent fragiles.

Maintenir, migrer progressivement ou réécrire

Maintenir et stabiliser

Approche adaptée à une application stable dont les besoins évoluent peu. Elle nécessite malgré tout une gestion des dépendances, des sauvegardes, de la sécurité et de la connaissance.

Migrer progressivement

Les nouvelles capacités sont exposées par API ou développées dans des modules ASP.NET Core. L’ancien et le nouveau coexistent jusqu’à ce que chaque périmètre soit validé.

Réécrire

Une réécriture peut être cohérente si l’application doit être profondément redessinée et si les règles métier sont suffisamment connues. Elle augmente toutefois le risque de tunnel et de perte fonctionnelle.

Exemple de cible WebForms vers .NET moderne

WebForms existant → API ASP.NET Core → services métier C# → SQL Server ou PostgreSQL → interface React/Next.js. L’authentification peut être centralisée avec Keycloak ou une autre solution OAuth 2.0/OIDC si le contexte le justifie.

Les frontières doivent suivre les capacités métier, pas seulement les pages WebForms. Un découpage par commandes, dossiers, facturation ou référentiels est souvent plus durable qu’une conversion écran par écran.

Comment réduire le risque de migration

1. Cartographier les parcours et règles critiques.

2. Créer des tests de caractérisation autour de l’existant.

3. Identifier les dépendances et composants spécifiques.

4. Choisir un premier module isolable.

5. Définir la responsabilité de chaque donnée pendant la coexistence.

6. Mesurer les erreurs, performances et usages avant chaque bascule.

Commencez par un audit du code legacy et comparez les trajectoires avec notre guide de migration de code legacy. La page migration WebForms vers .NET Core décrit l’accompagnement proposé par Kodeva.

FAQ WebForms

Peut-on convertir automatiquement WebForms en ASP.NET Core ?

Non, pas de manière complète et fiable. Le modèle de pages et de contrôles WebForms ne possède pas d’équivalent direct dans ASP.NET Core.

Faut-il choisir React pour la nouvelle interface ?

Pas nécessairement. React ou Next.js convient à certaines interfaces riches, mais Razor Pages, MVC ou une autre approche peut être plus simple.

Peut-on faire coexister WebForms et ASP.NET Core ?

Oui, avec une authentification, des API, des routes et une responsabilité des données clairement définies.

Voir les réalisations de modernisation d’applications.