En bref : C# et .NET sont une cible naturelle pour une application WinDev de gestion sous Windows : écosystème mature, outils gratuits, nombreux développeurs. Mais une migration réussie ne se résume pas à traduire du WLangage. Elle passe par un audit, une architecture cible claire, une migration par lots et une preuve de parité. Et dans certains cas, notamment quand l'application doit devenir web ou mobile, .NET n'est pas forcément le meilleur choix.
Parmi les entreprises qui envisagent de quitter WinDev, beaucoup pensent d'abord à C# et à .NET. Le choix est logique : comme WinDev, .NET est très présent dans le monde Windows et permet de développer des applications de gestion robustes. Mais entre l'intention et une application en production, il y a une méthode à suivre et des pièges à connaître. Cet article partage notre retour terrain sur ce type de projet, et vous dit aussi quand .NET n'est pas la bonne cible. Si vous hésitez encore sur le principe, lisez d'abord migration WinDev ou rester ? Comment décider en 2026.
- Pourquoi C# / .NET est une cible fréquente
- La méthode en 6 étapes
- Combien de temps dure une migration vers .NET ?
- Les pièges que nous rencontrons le plus souvent
- Quand .NET n'est pas le bon choix
- Se faire accompagner
- Questions fréquentes
Pourquoi C# / .NET est une cible fréquente
Une application WinDev typique est une application de gestion Windows, connectée à une base de données, avec beaucoup d'écrans de saisie, des états imprimés et des traitements métier. .NET couvre bien ces besoins :
- Un écosystème mature, maintenu par Microsoft, avec des versions à support long.
- Des outils de développement disponibles gratuitement pour de nombreux usages, et des bibliothèques pour presque tout.
- Un vivier de développeurs bien plus large que celui de WinDev, ce qui réduit la dépendance à quelques personnes. Voir notre article sur la pénurie de développeurs WinDev.
- Plusieurs options d'interface : client lourd Windows, application web ou API consommée par un front moderne.
- Une base de données au choix : SQL Server, PostgreSQL ou d'autres.
Enfin, sortir de WinDev met fin à l'exposition aux abonnements et aux Sessions de PC SOFT. Pour mesurer cet enjeu, consultez notre article sur le prix d'une licence WinDev en 2026.
La méthode en 6 étapes
Sur le terrain, les migrations qui se passent bien suivent toutes à peu près le même chemin :
- Auditer l'existant. Cartographier les fenêtres, les états, les traitements, les accès aux données et les dépendances. Repérer le code mort et les fonctions réellement utilisées.
- Définir l'architecture cible. Client Windows ou web, découpage en couches, choix de la base, gestion de l'authentification, outillage de tests et de déploiement.
- Migrer les données. Souvent, c'est la première brique : la base passe de HFSQL à SQL Server ou PostgreSQL. Notre guide HFSQL vers PostgreSQL détaille cette étape.
- Réécrire par lots fonctionnels. Un module à la fois : référentiels, puis ventes, puis stocks, etc. Chaque lot est livré, testé et validé par les utilisateurs.
- Prouver la parité. Comparer les résultats de l'ancienne et de la nouvelle application sur les mêmes données. C'est le principe de notre méthode Mirror.
- Basculer et accompagner. Formation, période de double fonctionnement si nécessaire, support renforcé les premières semaines.
Combien de temps dure une migration vers .NET ?
Il n'existe pas de durée standard. Une petite application de quelques dizaines de fenêtres peut se migrer en quelques mois ; un ERP métier développé pendant vingt ans demande souvent plus d'un an. Ces ordres de grandeur sont génériques : seul un audit permet de chiffrer votre cas. Les facteurs qui font varier la durée sont toujours les mêmes :
| Facteur | Effet sur la durée |
|---|---|
| Nombre de fenêtres, d'états et de traitements | Principal facteur de volume |
| Qualité du code et de la documentation | Un code peu structuré allonge l'analyse |
| Logique métier enfouie dans les écrans | Oblige à extraire et reformuler les règles |
| Nombre et complexité des états imprimés | Souvent sous-estimés |
| Interfaces avec d'autres systèmes | Chaque flux doit être retesté |
| Disponibilité des utilisateurs clés | Conditionne la validation des lots |
Pour des repères plus détaillés, lisez notre article sur la durée d'une migration WinDev et son planning.
Les pièges que nous rencontrons le plus souvent
- Traduire ligne à ligne. Le WLangage et le C# n'ont pas la même philosophie. Une traduction littérale reproduit les défauts de l'existant dans une technologie moderne, sans en tirer les bénéfices.
- Oublier les états. Les états WinDev sont nombreux et riches. Leur réécriture avec un outil de reporting .NET représente souvent une part importante du projet.
- Sous-estimer les fonctions implicites de HFSQL : identifiants automatiques, recherches, verrous, comportements par défaut. Côté .NET, tout doit être explicite.
- Vouloir tout refaire en même temps. Un « big bang » concentre les risques. La migration par lots est plus sûre.
- Négliger le changement pour les utilisateurs. Une interface différente, même meilleure, demande de l'accompagnement.
- Ne pas récupérer les sources. Sans code source complet, l'analyse devient de la rétro-ingénierie. Notre guide pour récupérer le code source d'une application WinDev vous aide à sécuriser ce point.
Quand .NET n'est pas le bon choix
.NET est une excellente cible, mais pas une cible universelle. Dans plusieurs situations, nous recommandons de regarder ailleurs :
- L'application doit devenir web et accessible partout. .NET sait faire du web, mais si votre équipe ou votre prestataire maîtrise mieux un front JavaScript moderne avec une API, cette combinaison peut être plus adaptée.
- Le besoin est couvert par un progiciel. Si votre application WinDev réimplémente une comptabilité ou une gestion commerciale standard, un logiciel du marché peut coûter moins cher qu'une réécriture.
- Votre équipe interne maîtrise une autre technologie, par exemple Java ou Python. Mieux vaut une cible que vos équipes sauront maintenir. Voir notre comparatif WinDev vs Java et Python.
- L'application est en fin de vie et sera remplacée à court terme : une migration complète n'a alors pas de sens.
Le choix de la cible doit découler de vos besoins, de vos compétences et de votre feuille de route, pas d'une habitude. Notre article sortir de WinDev : choisir la cible propose une grille de comparaison.
Se faire accompagner
Une migration vers .NET mobilise des compétences rares : il faut comprendre finement le WLangage et HFSQL, et maîtriser l'architecture .NET moderne. C'est précisément le double profil que nous mettons en œuvre dans nos projets de refonte et migration d'applications WinDev. Nous commençons toujours par un audit, puis nous proposons un découpage en lots, un planning et un budget, avec une preuve de parité à chaque étape.
Questions fréquentes
Peut-on convertir automatiquement du WLangage en C# ?
Des outils existent, mais ils ne produisent pas une application maintenable sans un important travail de reprise. La logique, les états et les accès aux données demandent presque toujours une réécriture.
Faut-il changer de base de données en même temps ?
C'est fréquent et souvent judicieux : on migre HFSQL vers SQL Server ou PostgreSQL, en première étape, avant de réécrire les modules.
Combien de temps dure une migration WinDev vers .NET ?
De quelques mois pour une petite application à plus d'un an pour un ERP métier, à titre d'ordre de grandeur. Seul un audit permet de chiffrer votre cas.
Peut-on continuer à utiliser l'application pendant la migration ?
Oui. Avec une migration par lots, l'ancienne application reste en service pendant que les nouveaux modules sont livrés progressivement.
Faut-il choisir un client Windows ou une application web ?
Cela dépend des usages : postes fixes en atelier, mobilité, accès externes. L'architecture cible se décide pendant l'audit, en fonction de vos utilisateurs.
Vous envisagez de migrer votre application WinDev vers C# / .NET ? Découvrez notre offre de refonte et migration WinDev : audit, découpage en lots et preuve de parité, pour une migration sans rupture.
