Migrer une application WinDev
vers C# et .NET.

Pourquoi C# et .NET pour remplacer WinDev ?

Une application WinDev concentre souvent des années de règles de gestion : calculs de prix, contrôles de saisie, enchaînements de traitements, éditions. Le problème n'est pas ce qu'elle fait, mais ce sur quoi elle repose : un atelier de développement propriétaire, un langage que peu de développeurs pratiquent, des licences à renouveler et des choix techniques qui appartiennent à l'éditeur.

.NET répond à ces trois points. C'est une plateforme open source, utilisée par un très grand nombre d'entreprises, pour laquelle il est facile de recruter ou de trouver un prestataire. Le C# est un langage typé, outillé et documenté, avec des environnements de développement gratuits ou largement diffusés. Et surtout, .NET couvre tous les usages d'une application WinDev :

• Application de bureau avec WPF ou WinForms, pour des postes Windows très interactifs ;
• Application web avec ASP.NET Core, seul ou associé à un front React ou Angular, accessible depuis un navigateur ;
• API REST pour partager les mêmes règles métier entre le poste de travail, le web et le mobile ;
• Accès aux données avec Entity Framework Core ou Dapper, sur PostgreSQL, MySQL / MariaDB ou SQL Server.

Le C# n'est pas la seule cible possible : Node.js ou une stack entièrement web peuvent mieux convenir à certains projets. Nous vous recommandons une technologie selon votre contexte, jamais par habitude. Mais pour une équipe qui pense « application de gestion », c'est souvent la transition la plus douce.

Équivalence des concepts WinDev → .NET

La première étape d'une migration consiste à faire correspondre chaque brique du projet WinDev à son équivalent dans le monde .NET. Ce tableau résume les correspondances que nous utilisons le plus souvent.

Ces équivalences ne sont pas des traductions mécaniques. Une fenêtre WinDev mélange souvent l'affichage, les contrôles de saisie et les accès à la base dans le même code. En .NET, on sépare ces responsabilités : l'écran affiche, un service applique la règle métier, une couche d'accès aux données lit et écrit. C'est ce découpage qui rendra votre logiciel testable et facile à faire évoluer.

Exemple : une procédure WLangage réécrite en C#

Prenons une procédure typique : elle parcourt les commandes d'un client, totalise les montants et applique une remise au-delà d'un seuil. En WinDev, la lecture se fait enregistrement par enregistrement avec les fonctions HFSQL.

// Procédure globale CalculTotalClient
PROCÉDURE CalculTotalClient(nIDClient est un entier) : monétaire
moTotal est un monétaire = 0

HLitRecherchePremier(Commande, IDClient, nIDClient)
TANTQUE HTrouve(Commande)
    moTotal += Commande.MontantHT
    HLitSuivant(Commande, IDClient)
FIN

// Remise fidélité au-delà de 1 000 €
SI moTotal > 1000 ALORS
    moTotal = moTotal * 0.95
FIN
RENVOYER moTotal

En C#, la même règle devient une méthode d'un service. Le total est calculé par la base de données en une seule requête, au lieu d'une boucle côté application, et les valeurs du seuil et du taux sont nommées au lieu d'être enfouies dans le code.

public class CommandeService(AppDbContext db)
{
    private const decimal SeuilRemise = 1000m;
    private const decimal TauxRemise = 0.05m;

    // Règle métier reprise de CalculTotalClient (WinDev)
    public async Task<decimal> CalculerTotalClientAsync(int idClient)
    {
        decimal total = await db.Commandes
            .Where(c => c.IdClient == idClient)
            .SumAsync(c => c.MontantHT);

        return total > SeuilRemise ? total * (1 - TauxRemise) : total;
    }
}

La règle est désormais isolée, donc testable. Les comportements observés dans l'ancienne application deviennent des tests automatiques, qui garantissent que le nouveau code calcule exactement la même chose :

[Fact]
public async Task Remise_appliquee_au_dela_du_seuil()
{
    var service = CreerServiceAvecCommandes(42, 600m, 500m);

    decimal total = await service.CalculerTotalClientAsync(42);

    Assert.Equal(1045m, total); // 1 100 € - 5 %
}

Multipliez cet exemple par quelques centaines de procédures et vous obtenez l'essentiel d'une migration : comprendre ce que fait le code, l'exprimer proprement dans le nouveau langage et prouver que rien n'a changé pour l'utilisateur.

Les pièges d'une migration WinDev vers C#

Le type monétaire et les arrondis

Le type monétaire de WinDev est un décimal à virgule fixe. Le reprendre en double introduit des écarts d'arrondi sur les montants. En C#, il faut utiliser decimal partout où l'on manipule de l'argent, et vérifier que les règles d'arrondi (au centime, à la ligne ou au total) sont identiques.

Les indices qui commencent à 1

En WLangage, les tableaux et les positions dans une chaîne commencent à 1 : Milieu(sCode, 1, 3) renvoie les trois premiers caractères. En C#, tout commence à 0 : code.Substring(0, 3). C'est une source classique d'erreurs décalées d'un caractère, d'où l'intérêt des tests de non-régression.

Les dates vides et les valeurs nulles

Dans beaucoup de bases HFSQL, une date « vide » est une chaîne vide ou une valeur par défaut, pas une vraie valeur nulle. En C#, une date absente doit devenir un DateTime? (ou DateOnly?) nul. Il faut décider, champ par champ, comment ces valeurs sont converties. Le sujet est détaillé dans notre page HFSQL vers PostgreSQL.

La lecture enregistrement par enregistrement

Les boucles HLitRecherchePremier / HLitSuivant fonctionnent bien sur une base locale. Recopiées telles quelles sur un serveur SQL, elles multiplient les allers-retours et ralentissent l'application. On les remplace par des requêtes ensemblistes : filtrer, totaliser et trier dans la base, pas dans une boucle.

Le code dispersé dans les champs

Une même règle peut se retrouver dans le clic d'un bouton, la sortie d'un champ et une procédure globale, avec de légères variantes. L'audit sert justement à repérer ces doublons, à choisir la version de référence et à la centraliser dans un service unique.

Les comportements implicites du framework

WinDev fait beaucoup de choses sans qu'on l'écrive : contexte HFSQL partagé, filtres actifs, blocages d'enregistrements, affichage automatique des tables. En .NET, ces comportements doivent être explicites : transactions, gestion de la concurrence, chargement des listes. Les oublier, c'est découvrir des écarts en production.

Notre méthode, de WinDev à .NET

1. Audit de l'existant. Inventaire des fenêtres, procédures, requêtes, états, composants et de l'analyse HFSQL. Voir notre page audit d'application WinDev.
2. Choix de l'architecture. Bureau (WPF, WinForms), web (ASP.NET Core avec React ou Angular) ou les deux autour d'une même API ; base de données cible.
3. Extraction des règles métier. Le code WLangage est cartographié, même sans documentation, et les règles sont décrites puis couvertes par des tests.
4. Migration par modules. Nous privilégions une migration progressive : un module à la fois, pendant que l'ancienne application continue de tourner. Une refonte complète reste possible quand elle est plus pertinente.
5. Reprise des données. Les données HFSQL sont transférées avec des scripts vérifiés et des contrôles à chaque étape.
6. Mise en production et évolutions. Accompagnement des utilisateurs, maintenance et nouvelles fonctions sur la nouvelle plateforme.

À l'issue du projet, 100 % du code source vous est livré. Vous ne payez plus de redevance éditeur et vous restez libre de faire évoluer votre logiciel avec le prestataire de votre choix. Pour une vue d'ensemble de nos prestations, consultez notre page migration et refonte d'applications WinDev.