Migration WinDev vers le web : quand sortir de WinDev, et par quelle voie

Il faut migrer une application WinDev vers le web quand elle freine l'activité : besoin d'accès à distance ou sur mobile, clients et partenaires à connecter, dépendance à un seul développeur, postes Windows qu'on ne peut plus mettre à jour. Trois voies existent : passer à WEBDEV chez le même éditeur, réécrire en C# et .NET, ou construire une application web sur des technologies standards. Dans tous les cas, la reprise des données HFSQL et la reconstitution des règles métier pèsent plus lourd que le choix du langage.

Cet article s'adresse au dirigeant qui doit décider, pas au développeur qui code la migration. Il ne dénigre pas WinDev : l'outil a permis à des milliers de PME de se doter d'un logiciel métier à moindre coût, et beaucoup tournent très bien. La question est de savoir si le vôtre doit évoluer, et comment le faire sans arrêter l'entreprise.

Pourquoi tant d'entreprises veulent sortir de WinDev

WinDev, édité par la société française PC SOFT, est un atelier de développement d'applications Windows avec son propre langage, le WLangage, et sa propre base de données, HFSQL. Ce modèle tout intégré fait sa force au départ, et devient une contrainte quand l'entreprise grandit.

Les motifs qui reviennent le plus souvent :

• l'accès hors du bureau : commerciaux, techniciens, agences ou télétravailleurs qui ont besoin du logiciel sans poste Windows connecté au réseau de l'entreprise ;
• l'ouverture aux clients et partenaires : un portail de commande, un suivi de dossier, un échange automatique avec un fournisseur ;
• la dépendance à une personne : le développeur qui a écrit l'application, interne ou freelance, part à la retraite ou n'est plus disponible, et le vivier de développeurs WLangage est plus restreint que celui des langages généralistes ;
• la dépendance à un éditeur : licences, montées de version, choix techniques, tout passe par PC SOFT ;
• les postes qui vieillissent : Microsoft a arrêté la prise en charge de Windows 10 le 14 octobre 2025. Une application installée sur des postes anciens hérite de leurs failles de sécurité.

Quand il vaut mieux ne pas migrer

Une migration coûte cher et immobilise l'équipe. Elle ne se justifie pas si votre application :

• fonctionne et évolue peu ;
• tourne sur des postes et un serveur à jour ;
• est maintenue par un développeur compétent et disponible, avec le code source sous votre contrôle ;
• n'a besoin ni d'accès à distance, ni d'ouverture vers l'extérieur.

Dans ce cas, mieux vaut sécuriser l'existant : sauvegardes vérifiées, documentation des règles principales, montée de version de WinDev si nécessaire, et un second développeur qui connaît le projet. Vous gardez la migration pour le jour où un vrai besoin la justifie.

Les voies possibles, comparées

Passer à WEBDEV

C'est la voie la plus courte en apparence. D'après la page WEBDEV de PC SOFT (relevé du 06/11/2026), WINDEV, WEBDEV et WINDEV Mobile partagent classes, procédures, états et requêtes, et HFSQL est livré en standard. La même page précise que le déploiement d'un site nécessite le Serveur d'Application WEBDEV, soumis à une licence distincte.

Ce que cela veut dire pour vous : une partie de la logique métier se reprend, mais l'interface est à reconcevoir, car une page web ne se comporte pas comme une fenêtre Windows (navigation, sessions, temps de réponse du réseau). Et vous restez dans le même écosystème, avec les mêmes dépendances. C'est une bonne option si votre problème est l'accès à distance, pas la dépendance à l'éditeur.

Réécrire en C# et .NET

C'est la requête « migration WinDev vers C# » : quitter le WLangage pour un langage généraliste, très répandu en entreprise, avec la plateforme .NET de Microsoft. Elle permet de rester sur une application de bureau Windows, si vos utilisateurs en ont besoin, ou de passer au web avec ASP.NET Core.

Il n'existe pas de convertisseur qui transforme proprement une application WinDev complète en C#. Des outils d'aide à la traduction existent, mais le code produit doit être relu et restructuré. En pratique, il s'agit d'une réécriture guidée par l'existant. Le choix de .NET se justifie surtout si votre informatique est déjà centrée sur Microsoft (SQL Server, Active Directory, Microsoft 365) ou si vous disposez de développeurs C#.

Construire une application web sur des standards ouverts

Une application dans le navigateur, une base PostgreSQL, des interfaces de programmation (API) documentées. C'est la voie qui ouvre le plus de possibilités : accès depuis n'importe quel poste, tablette ou téléphone, portail client, échanges automatiques avec d'autres logiciels, hébergement au choix. C'est aussi celle qui demande de repenser le plus de choses : impressions, lecteurs de codes-barres, balances, fonctionnement hors connexion. Notre article sur les technologies d'une application métier aide à choisir la pile technique.

Le vrai chantier : les données HFSQL

Quelle que soit la voie, les données doivent passer dans la nouvelle base. HFSQL existe en deux modes : Classic, où chaque table est un ensemble de fichiers sur un disque partagé (données, index, mémos), et Client/Serveur, où un serveur gère la base. Le second se prête mieux à une migration progressive, parce que plusieurs logiciels peuvent s'y connecter.

Trois voies d'extraction, à choisir selon votre version et votre volume :

• l'export depuis l'application elle-même ou depuis les outils d'administration HFSQL fournis par PC SOFT, en fichiers texte ou XML ;
• le pilote ODBC que distribue PC SOFT, qui permet à un autre logiciel de lire les tables (à vérifier pour votre version de HFSQL) ;
• un petit programme WinDev d'extraction, écrit par un développeur qui connaît l'outil, quand les deux premières voies ne suffisent pas.

Les pièges classiques d'une reprise HFSQL :

• l'intégrité non déclarée : les liens entre tables sont souvent gérés dans le code, pas dans la base, et des enregistrements orphelins se sont accumulés ;
• les mémos et fichiers joints, stockés à part, parfois volumineux ;
• les dates et les nombres saisis dans des champs texte, avec des formats qui ont varié au fil des années ;
• l'encodage des caractères, quand l'application est passée d'une version ancienne à une version récente ;
• les données calculées dont on ne sait plus si elles font foi ou si elles se recalculent.

La méthode complète, migrations de test et validation par le métier comprises, est décrite dans la reprise de données lors d'une migration de logiciel.

Les autres risques à anticiper

• Les règles métier enfouies dans le code WLangage : calculs de prix, remises, échéances, contrôles de saisie. Elles se retrouvent en lisant le code, quand vous en disposez, et en observant les utilisateurs.
• Les états imprimés : bons de livraison, factures, étiquettes. Ils sont souvent nombreux et doivent être refaits un par un, au format PDF ou pour l'imprimante concernée.
• Les périphériques : douchettes, balances, imprimantes d'étiquettes, lecteurs de cartes. Chacun demande une solution dans le navigateur ou un petit relais local.
• Le fonctionnement hors connexion : un atelier ou un dépôt mal couvert par le réseau a besoin d'un mode dégradé.
• Le code source : vérifiez que vous en disposez, à jour, et que vous avez le droit de l'exploiter. Notre article sur la propriété du code source rappelle les règles, avec des droits définis au cas par cas dans le contrat.

Migrer par étapes plutôt que d'un bloc

Une application WinDev centrale se prête mal à une bascule unique : tout se joue le même jour, et le moindre oubli bloque toute l'entreprise. La méthode la plus sûre consiste à construire la nouvelle application à côté de l'ancienne, module par module :

1. Inventaire : les fenêtres et états réellement utilisés, par qui, à quelle fréquence. Dans une application ancienne, une partie ne sert plus.
2. Premier module choisi pour sa valeur : souvent ce qui manque le plus à l'application actuelle, comme un accès mobile pour les techniciens ou un portail client.
3. Prototype validé par les utilisateurs avant tout développement.
4. Cohabitation : le nouveau module lit la base HFSQL, idéalement en Client/Serveur, ou reçoit ses données par un échange régulier.
5. Bascule module par module, avec retour arrière prévu, jusqu'à l'extinction de l'application WinDev.

Cette méthode est détaillée dans notre article sur la refonte d'une application métier par étapes. La même logique s'applique aux bases Access, voir migrer Access vers une application web.

Combien coûte une migration WinDev

Le coût dépend des mêmes facteurs que toute refonte : nombre de fenêtres réellement utilisées, règles métier, états imprimés, intégrations, volume et état des données. Le langage d'origine compte peu. Ce qui alourdit vraiment une migration WinDev, ce sont les états nombreux, les périphériques et l'absence de documentation. Nos repères et les postes de coût sont détaillés dans le prix de la refonte d'un logiciel métier.

La check-list du dirigeant

• Disposez-vous du code source à jour, et de la dernière version de l'environnement qui l'ouvre ?
• La base est-elle en HFSQL Classic ou Client/Serveur ?
• Quelles fenêtres et quels états sont utilisés chaque semaine ?
• Quels périphériques et quelles impressions sont indispensables ?
• Qui, dans l'équipe, connaît les règles métier et peut les valider ?
• Quel est le besoin qui justifie la migration : mobilité, ouverture, dépendance, sécurité ?
• Où sera hébergée la nouvelle application ? Voir l'hébergement d'une application métier en France.

Par où commencer

Rassemblez quelques captures des écrans les plus utilisés, la liste des états imprimés et, si possible, un export de la base. Avec cela, un premier échange suffit à dire quelle voie vous convient.

Chez LPR Studio, cet échange débouche sur un prototype visuel gratuit du premier module web, présenté en visio sous 5 jours ouvrés : vos équipes voient leur futur écran avant toute décision. La démarche est expliquée dans voir son logiciel avant de le payer.