Vous avez une application métier critique développée avec WinDev ou WebDev. Elle tourne, elle est connue de vos équipes, et personne n’a envie d’y toucher. Puis arrive un moment où la migration devient inévitable : rachat de l’éditeur, hausse de licence, départ du seul développeur qui connaît le WLangage, ou besoin d’évolution que l’outil ne peut plus suivre. .NET revient souvent dans cette conversation. Voici pourquoi c’est souvent le bon choix, et ce que ça implique concrètement.
Vous n’avez pas suivi le rachat de PC SOFT ? Lisez d’abord cet article.
Pourquoi .NET et pas autre chose ?
Quand une organisation sort d’un outil propriétaire comme WinDev, elle a plusieurs directions possibles : Java, Python, Node.js, PHP, .NET, ou toute autre technologie. Le choix n’est pas anodin, car il conditionne les recrutements, la maintenabilité et la pérennité sur 10 à 15 ans.
.NET a plusieurs arguments solides dans ce contexte. C’est un écosystème open source depuis 2016. Microsoft le maintient avec une feuille de route publique et des LTS (Long Term Support) clairement définis. Contrairement à WinDev, le code source est accessible et auditable. Il ne dépend donc pas des décisions commerciales d’un éditeur racheté en silence. Par ailleurs, la communauté est l’une des plus actives au monde — ce qui se traduit directement par la disponibilité des profils sur le marché.
C’est aussi l’un des rares environnements qui couvre l’intégralité du périmètre fonctionnel d’une application métier. Desktop (WPF, WinForms, MAUI), web (ASP.NET Core, Blazor), API, services en arrière-plan, connecteurs base de données, reporting : tout est couvert. Ainsi, une migration WinDev vers .NET ne force pas à fragmenter l’architecture entre plusieurs technologies.
Enfin, les performances : .NET 8 et 9 figurent systématiquement parmi les environnements les plus rapides dans les benchmarks TechEmpower. Ce n’est pas un critère décisif pour toutes les applications métier. En revanche, pour les applications à fort volume de données ou à forte charge concurrente, c’est une différence mesurable.
Ce que WinDev ne dit pas sur la dépendance technique
Le WLangage est propriétaire. Il n’existe aucun outil de migration automatique vers un autre langage. De plus, les compétences sont non transférables : un développeur WinDev expérimenté n’est pas, par définition, un développeur .NET. C’est exactement ce que Constellation Software, le nouveau propriétaire de PC SOFT, exploite. Plus vous attendez, plus la migration coûte cher — et plus le levier tarifaire de l’éditeur est puissant.
À cela s’ajoute la question des bases de données. WinDev/WebDev encourage l’utilisation de HFSQL (anciennement HyperFileSQL), une base propriétaire. Si votre application s’appuie dessus, il faudra aussi sortir les données vers un SGBD standard — PostgreSQL, SQL Server, MySQL. C’est faisable, mais à anticiper dans le scope du projet.
.NET : un écosystème ouvert, pas un autre silo
Le risque d’une migration mal conçue, c’est de sortir d’un silo propriétaire pour en entrer dans un autre. .NET échappe à ce risque pour des raisons structurelles.
Le code que vous écrivez en C# est standard. N’importe quel développeur .NET peut le lire, n’importe quel outil Git peut le versionner, et il se déploie sur Windows, Linux ou en conteneurs. Pas de format propriétaire, pas de connecteur maison. Aucune dépendance à un éditeur unique pour faire tourner l’application. Si vous changez de prestataire dans 5 ans, le code reste donc lisible et maintenable.
L’outillage est également un atout. Visual Studio et Visual Studio Code sont gratuits. Les outils de test, de CI/CD et de conteneurisation s’intègrent nativement. Les bibliothèques disponibles via NuGet couvrent la quasi-totalité des besoins courants : reporting, PDF, connecteurs ERP, authentification, cartographie. Aucune ne dépend d’un éditeur qui peut changer ses conditions du jour au lendemain.
Migration WinDev vers .NET : comment ça se passe concrètement
Une migration réussie ne se fait pas d’un bloc. La réécriture totale, c’est le scénario classique qui dérape : il coûte plus cher que prévu, il prend plus de temps, et il expose l’organisation à une période de transition à haut risque.
L’approche que nous appliquons chez Mahé Technologies est différente. On commence par cartographier ce qui existe : modules, dépendances, briques critiques, volumes de données, nombre d’utilisateurs par fonctionnalité. Cette cartographie conditionne tout le reste. Elle permet en effet de prioriser par criticité et risque — et non par ordre d’apparition dans l’organigramme.
Ensuite, on découpe la migration en lots livrables. Chaque lot est testé avant la bascule, pas après. On compare les résultats de l’ancienne et de la nouvelle application sur les mêmes données — pour s’assurer qu’on n’a rien cassé. Dev et QA travaillent ensemble dès le départ. Pendant ce temps, l’ancien système continue de tourner. Zéro interruption.
Ce que ça change pour vous
Sortir de WinDev ou WebDev vers .NET, c’est reprendre le contrôle. Le code vous appartient, les compétences se recrutent sur le marché standard, et les coûts de maintien sont prévisibles. Vous ne dépendez plus d’un éditeur dont les conditions commerciales changent sans préavis.
Ce n’est pas une décision à prendre à chaud, sous pression d’une hausse de licence ou d’un départ de compétences. Elle se prépare : cartographie du parc, évaluation de la dette technique, priorisation des modules. Ensuite vient l’estimation du coût de migration — à comparer avec le coût de rester.
Vous avez une application WinDev ou WebDev en production ? Vous voulez savoir ce qu’implique une migration vers .NET ? On peut regarder ça ensemble.
