Migration WinDev vers C# : reprendre l’application sans tout arrêter
Une migration WinDev vers C# consiste à reprendre les règles métier, les écrans et, souvent, la base HFSQL d’une application PC SOFT dans un projet .NET. C# est la cible la plus proche quand l’application doit rester sur un poste Windows. Si l’accès depuis un navigateur devient le besoin principal, on vise plutôt une application web, éventuellement avec une API encore écrite en .NET. Dans les deux cas, la méthode la plus sûre avance par étapes : audit du code, API sur les données existantes, puis bascule module par module. Anaska, dont l’éditeur est WebGuard Agency, décrit ici cette méthode. Le tarif se définit sur devis, après audit.
WinDev est un atelier propriétaire. On y programme en WLangage, souvent avec HFSQL. La famille comprend aussi WebDev et WinDev Mobile. PC SOFT continue de faire évoluer le produit : la version présentée sur son site officiel est WINDEV 2026. Beaucoup de logiciels de gestion de PME construits avec cet outil fonctionnent encore très bien. Le sujet n’est pas de dire que WinDev est mort, c’est de savoir si l’application peut encore évoluer au rythme de l’entreprise.
Pourquoi partir, et pourquoi C#
Les raisons qui reviennent le plus souvent sont concrètes : recrutement (un développeur WLangage n’est pas toujours disponible, la connaissance repose parfois sur une seule personne), accès à distance, licences et dépendance à un éditeur, intégrations avec un site, un CRM ou une application mobile. Si aucune de ces contraintes ne vous gêne, garder WinDev reste raisonnable.
C#/.NET arrive en tête quand les utilisateurs veulent conserver une application installée, avec des fenêtres et des formulaires. Les équipes retrouvent des réflexes proches, et le même socle peut exposer une API pour d’autres usages. Ce n’est pas une conversion automatique du WLangage : les règles sont réécrites et testées. Si le vrai besoin est le navigateur (télétravail, plusieurs sites), le web est souvent plus juste que de recréer un client lourd « par habitude ».
| Votre besoin | Cible souvent retenue | Point de vigilance |
|---|---|---|
| Rester sur poste Windows | C#/.NET | Réécriture des écrans, compétences .NET ensuite |
| Accès navigateur, multisite | Application web (React ou Vue) + API (.NET, Node ou PHP) | Droits et sécurité dès le départ |
| Usage terrain | Web responsive, ou Flutter / React Native | Hors-ligne à concevoir tôt |
| Base HFSQL | PostgreSQL, MariaDB ou SQL Server | Contrôle des totaux avant la bascule |
Les étapes d’une migration WinDev vers C# (ou vers le web)
On commence par un audit : lecture du WLangage, liste des fenêtres, des états, des traitements et des échanges avec d’autres logiciels. On repère ce qui sert vraiment. Puis on écrit les règles métier (prix, remises, stocks, plannings) avec les utilisateurs clés : elles sont souvent cachées dans le code.
Une API donne ensuite accès aux données, y compris encore dans HFSQL. Elle sert de pont. On remplace un module utile et bien délimité, on le met en production, on passe au suivant. Chaque module est recetté sur des cas réels, en comparant les résultats avec l’application WinDev. Quand tout est repris et les données contrôlées, l’ancienne application passe en lecture seule, puis s’arrête.
Les données se préparent tôt : inventaire, nettoyage, export rejouable, comparaison des effectifs et des totaux. Une réécriture d’un bloc n’a de sens que pour une application petite, ou un métier déjà très différent. Dans la majorité des cas, l’approche progressive limite le risque.
Comment choisir un prestataire, et le budget
Avant de signer, demandez un audit avec un chiffrage par lots, des références de reprises WinDev ou HFSQL, la propriété du code et des accès, la façon dont les deux applications cohabitent, et qui maintient ensuite. Le budget se fixe sur devis après audit. Il dépend du nombre d’écrans et d’états, de la complexité des règles, du volume et de la qualité des données, et des logiciels déjà connectés.
Pour poser le contexte : le formulaire de contact. Décrivez l’application (bureau ou déjà WebDev / mobile) et ce que vous visez, en particulier une cible C#. Un comparatif des alternatives à WinDev aide à confirmer la cible avant de lancer la reprise.
Si l’application à reprendre est une base Microsoft Access plutôt qu’un projet WinDev, la méthode change sur les données et les écrans : voir la migration Access vers le web.