Migrer de WinDev vers .NET / C#

Pour une application de gestion desktop qui doit rester desktop, C# est la cible qui demande le moins de renoncements. Même paradigme fenêtré, même écosystème Windows, un outillage mature et un vivier de développeurs sans commune mesure avec celui du WLangage. Cette page détaille ce qui se transpose bien, ce qui coûte, et le plan type d'une bascule.

Pourquoi C# est la cible la plus proche

WinDev et .NET partagent la même philosophie d'application : des fenêtres, des champs liés à des données, des traitements événementiels. Un développeur WinDev retrouve ses repères en C# plus vite qu'en JavaScript. Les concepts se correspondent presque terme à terme : les procédures deviennent des méthodes, les collections de procédures des classes de service, les requêtes HFSQL des requêtes SQL via un ORM comme Entity Framework.

Autre atout : l'intégration à un parc Microsoft existant. Active Directory, SQL Server, Office, déploiement par GPO ou Intune : tout est natif. Pour une DSI déjà outillée Microsoft, la migration réduit le nombre de technologies à opérer au lieu de l'augmenter.

Le champ Table WinDev et son équivalent .NET

Le champ Table de WinDev est l'objet le plus utilisé des applications de gestion : tri, filtre, saisie en cellule, export, impression, le tout intégré. En .NET, le DataGridView de base ne couvre pas ce périmètre. Il faut le dire clairement : reproduire l'expérience du champ Table passe par une suite de composants tiers.

C'est un poste de budget à part entière, et il est récurrent : ces suites se licencient par développeur et par an. En contrepartie, elles offrent des grilles plus riches que le champ Table d'origine : virtualisation de gros volumes, regroupements, tableaux croisés, thèmes modernes.

Le budget composants (DevExpress, Telerik, Syncfusion)

Notre conseil : choisir la suite pendant l'audit, sur la base de deux ou trois écrans représentatifs reconstruits en maquette. Le choix engage pour des années ; le tester sur votre cas réel coûte quelques jours et évite un regret durable.

Desktop, WPF ou Blazor ?

Trois formes d'interface coexistent dans l'écosystème .NET. Windows Forms : le plus proche du modèle WinDev, rapide à prendre en main, parfait pour une reprise iso-fonctionnelle. WPF : plus moderne et plus souple graphiquement, avec une courbe d'apprentissage plus raide. Blazor : du web en C#, pertinent quand une partie de l'application doit devenir accessible en navigateur sans basculer toute l'équipe vers JavaScript.

Le choix n'est pas définitif à l'échelle du parc : un cœur de services C# bien découplé peut alimenter un client Windows Forms aujourd'hui et un front Blazor demain. C'est l'architecture de services qui protège l'investissement, pas le choix du framework d'interface.

Erreurs fréquentes sur une migration vers .NET

• Choisir la suite de composants après avoir démarré la reconstruction des écrans : le changement de suite en cours de route double le travail sur les écrans déjà faits.
• Sous-estimer les états et impressions parce qu'ils paraissent secondaires à l'audit : c'est systématiquement l'un des postes qui déborde le plus le calendrier initial.
• Traduire les traitements HFSQL requête par requête sans revoir leur logique : un parcours ligne à ligne recopié tel quel en Entity Framework produit une application lente.
• Négliger la formation des utilisateurs au nouvel outil sous prétexte que WPF ou Windows Forms ressemble à WinDev : l'ergonomie proche n'élimine pas le besoin d'accompagnement au changement.

Ces erreurs partagent un point commun : elles viennent presque toujours d'un raccourci pris pour tenir un calendrier optimiste, plutôt que d'un manque de compétence technique. C'est pour cela que l'audit préalable, qui prend le temps de cartographier avant d'engager la reconstruction, réduit le risque plus efficacement qu'un contrôle qualité en fin de projet.

Plan de migration type

• Audit et cartographie : volumétrie du code, écrans, états, dépendances, base HFSQL.
• Migration de la base vers SQL Server ou PostgreSQL, avec recette d'intégrité : le socle de tout le reste.
• Reconstruction des services métier en C#, documentés et testés, à partir des règles extraites du WLangage.
• Reconstruction des interfaces par lots fonctionnels, avec la suite de composants retenue.
• Cohabitation : les modules migrés et l'application d'origine tournent ensemble le temps de la bascule.
• Reprise des états et impressions, poste à chiffrer tôt car systématiquement sous-estimé.

La durée dépend de la volumétrie et du nombre de modules, et se compte en mois. L'audit de cinq jours produit un chiffrage par scénario et un ordre de passage des modules : c'est le document qui permet d'arbitrer sereinement.