Considéré comme « vieux mais costaud », Windows Forms (WinForms) continue de fonctionner en 2025 avec .NET 9. Alors que WinUI et MAUI visent l’avenir et que WPF s'est lui aussi mis à Dotnet Core, WinForms demeure l’option la plus simple pour créer rapidement des applications Windows desktop. Mais dans quel contexte son usage est-il encore légitime ? Quels sont ses avantages actuels, ses limites, et pourquoi certaines entreprises l’utilisent toujours ?
✅ Ce que WinForms fait encore très bien
- Créer une UI ultra-rapide à mettre en œuvre
Un simple formulaire avec bouton peut être codé en quelques secondes :
var form = new Form { Text = "Ma fenêtre" };
var button = new Button { Text = "Cliquez-moi" };
button. Click += (s, e) => MessageBox.Show("Bonjour !");
form.Controls.Add(button);
Application.Run(form);
C'est du vieux code, c'est moins élégant que le XAML de WinUI, de MAUI ou WPF, mais on dispose d'un designer visuel et d'une approche ultra simple ayant une subtilité d'un niveau à peine supérieure à celle de Visual Basic ou d'autres produits comme Delphi de l'époque Borland. On ne bluffera personne à la machine à café avec WinForms, pour la drague il faut oublier, et pour rouler des mécaniques aussi devant les mâles Alpha. Mais ça marche... Et pour certains pragmatiques endurcis c'est tout ce qui compte !
- Compatibilité avec les outils d’entreprise existants
- Nombreux outils internes en WinForms
- Interopérabilité avec COM, bibliothèques Win32
- Intégration directe de contrôles tiers anciens (ActiveX, Crystal Reports, etc.)
- Accès simplifié aux API Windows
Les développeurs peuvent encore utiliser DllImport, les API GDI+ ou Shell sans friction.
🎯 Quand utiliser WinForms aujourd’hui ?
|
Situation
|
Raisonnement
|
|
Petit outil interne rapide
|
✅ Lancement instantané, simplicité
|
|
Migration progressive d’un existant
|
✅ Conservation de la base existante
|
|
Interface brute pour outil technique
|
✅ Facile à coder, pas besoin de style
|
⚠️ Ce que WinForms ne fait pas ou mal en 2025
|
Fonction
|
Limite
|
|
UI moderne (dark mode, responsive)
|
❌ Très limité, pas prévu pour ça
|
|
Accessibilité (a11y)
|
⚠️ Partiellement supportée
|
|
Animations, composition
|
❌ Absent sans bibliothèques tierces
|
|
Multiplateforme
|
❌ Strictement Windows
|
|
High-DPI moderne
|
⚠️ Support partiel, souvent manuel
|
🧰 Moderniser une app WinForms avec .NET 9
- Utiliser les dernières API .NET : HttpClient, System.Text.Json, Task, Span<T>, ValueTask, etc.
- Remplacer les accès synchrones par async/await.
- Isoler la logique dans des services C# réutilisables (injection possible avec Microsoft.Extensions.DependencyInjection).
- Ajouter WebView2 pour intégrer des contenus modernes :
var webView = new Microsoft.Web.WebView2.WinForms.WebView2();
webView.Source = new Uri("https://www.microsoft.com");
- Publier en mode autonome (PublishSingleFile) pour distribution simple :
dotnet publish -r win-x64 -c Release -p:PublishSingleFile=true
🚫 Quand éviter WinForms
- Vous ciblez autre chose que Windows
- Vous voulez une UI moderne et stylisée
- Votre app manipule des animations, des effets graphiques
- Vous souhaitez un écosystème actif et maintenu
- Vous ciblez des clients pour qui le look des application de l'an 2000 ne passe pas...
Conclusion
WinForms n’est pas mort, mais n’évolue plus vraiment. Il est pertinent dans un cadre pragmatique : outils internes, maintenance de legacy, ou prototypes rapides. Mais il n’est pas adapté à une application publique moderne ou évolutive.
En tant que vieux routier du développement, je ne conseille à personne de faire du WinForms aujourd'hui même sous .NET 9, en tout cas pas pour des applications professionnelles. C'est un cul-de-sac technologique. Maintenant pour bricoler un utilitaire, une moulinette, vite-fait bien-fait, je ne dis pas, il faut rester pragmatique. Mais être pragmatique ne signifie pas perdre toute lucidité non plus....