En bref : Migrer WinDev vers le web consiste à séparer ce que WinDev mélange : l'interface, la logique métier et l'accès aux données. L'architecture cible type associe un front React ou Angular, une API qui porte les règles métier et une base relationnelle. La réussite tient au découpage par modules : on migre un domaine fonctionnel après l'autre, avec une coexistence temporaire entre l'ancien et le nouveau système.
Accès depuis n'importe quel poste, travail à distance, ouverture aux clients et aux partenaires, fin des installations sur chaque PC : les raisons de passer une application WinDev en version web sont nombreuses. La hausse du coût de l'écosystème PC SOFT en 2026 accélère encore la réflexion. Mais une application de gestion WinDev n'est pas un site vitrine. Elle concentre des années de règles métier, d'états et de traitements. La transformer en application web demande une architecture claire et une méthode progressive. Ce guide présente l'architecture cible que nous recommandons et la manière de découper le projet. Si vous n'avez pas encore choisi votre technologie, lisez d'abord notre article pour choisir la cible d'une sortie de WinDev.
- Pourquoi migrer WinDev vers le web
- L'architecture cible, couche par couche
- Découper l'application par modules
- Migrer les données HFSQL
- Les points d'attention spécifiques au web
- Planning et budget : à quoi s'attendre
- Questions fréquentes
Pourquoi migrer WinDev vers le web
Le passage au web n'est pas une mode. Pour une PME, il répond à des besoins très concrets :
- Accessibilité : un navigateur suffit, depuis le bureau, le domicile ou un chantier.
- Déploiement simplifié : une seule mise à jour côté serveur, plus d'installation poste par poste.
- Ouverture : un portail client, une application mobile ou un partenaire peuvent consommer la même API.
- Recrutement : React, Angular et les frameworks d'API sont enseignés partout, ce qui réduit la dépendance à des compétences rares.
- Indépendance : les briques sont open source ou largement standardisées, sans licence d'exécution à l'usage.
Le web n'est pas toujours la bonne réponse. Certaines applications très liées au poste de travail (pilotage de matériel, traitements locaux lourds) se prêtent mieux à une cible bureau comme .NET. Notre article sur la migration WinDev vers C# / .NET détaille ces cas.
L'architecture cible, couche par couche
Dans une application WinDev classique, le code des fenêtres accède souvent directement aux fichiers HFSQL et contient les règles métier. L'architecture web cible sépare ces responsabilités en trois couches :
| Couche | Rôle | Technologies courantes |
|---|---|---|
| Front-end | Écrans, formulaires, tableaux, navigation | React ou Angular, en TypeScript |
| API | Règles métier, contrôles, sécurité, traitements | .NET, Node.js, Java ou PHP selon vos compétences |
| Données | Stockage, intégrité, historique | PostgreSQL, SQL Server ou MySQL |
Schématiquement, le flux devient : navigateur → front React ou Angular → API sécurisée → base relationnelle. Autour de ce cœur viennent des services annexes : génération des états PDF, envoi de mails, traitements planifiés, authentification centralisée.
Le choix entre React et Angular dépend surtout de vos équipes. Angular impose un cadre structuré, apprécié pour les grosses applications de gestion. React est plus souple et dispose d'un écosystème très large. Les deux conviennent à une application métier.
Découper l'application par modules
La principale cause d'échec d'une migration est la tentation du « big bang » : tout réécrire puis tout basculer d'un coup. Nous recommandons au contraire un découpage par domaine fonctionnel :
- Cartographier l'application : fenêtres, états, traitements, fichiers de données, et les liens entre eux.
- Regrouper par domaine : clients, devis et commandes, facturation, stocks, planning, paramétrage.
- Identifier les dépendances : quel module lit ou écrit les données d'un autre ?
- Choisir un premier module à forte valeur et faible dépendance, par exemple la consultation client ou un portail.
- Migrer module par module, chacun livré, testé et mis en production avant de passer au suivant.
Pendant la transition, l'ancienne application WinDev et la nouvelle application web coexistent. Cette coexistence repose le plus souvent sur une API commune ou une base partagée. Notre article pour interfacer WinDev avec une API web explique comment faire dialoguer les deux mondes.
Migrer les données HFSQL
La base de données est souvent le premier chantier, car le front et l'API en dépendent. Passer de HFSQL à une base relationnelle standard permet aussi à l'application WinDev existante de lire et d'écrire dans la nouvelle base pendant la transition, via un connecteur ou un accès natif.
- Nettoyer le modèle : rubriques inutilisées, doublons, clés manquantes.
- Traduire les types : dates, mémos, binaires et numériques n'ont pas toujours d'équivalent direct.
- Contrôler chaque transfert : nombre d'enregistrements, totaux, échantillons comparés.
Notre tutoriel HFSQL vers PostgreSQL détaille les étapes et la check-list de contrôle des données.
Les points d'attention spécifiques au web
Passer au web change certaines habitudes que les utilisateurs d'une application WinDev tiennent pour acquises. Mieux vaut les anticiper :
- Ergonomie : saisie rapide au clavier, raccourcis, tables éditables. Les utilisateurs habitués doivent retrouver leur productivité.
- États et impressions : les états WinDev doivent être reconstruits avec un moteur de génération PDF côté serveur.
- Sécurité : une application web exposée exige authentification forte, gestion des droits dans l'API, chiffrement et journalisation.
- Périphériques : douchettes, imprimantes d'étiquettes, balances. Chaque intégration locale doit être étudiée.
- Mode hors ligne : si certains utilisateurs travaillent sans réseau, il faut le prévoir dès la conception.
Pour garantir que la nouvelle application calcule exactement comme l'ancienne, nous comparons systématiquement les résultats des deux systèmes sur les mêmes données, selon notre méthode Mirror.
Planning et budget : à quoi s'attendre
La durée et le coût d'une migration vers le web dépendent du nombre de fenêtres, d'états et de traitements, de la qualité du code et du volume de données. Nous préférons ne pas avancer de chiffre générique : seul l'examen de votre application permet un chiffrage sérieux.
Le découpage par modules a un avantage décisif : chaque module livré apporte de la valeur et réduit le risque, sans attendre la fin du projet. Le planning se construit module par module, avec des jalons de mise en production réguliers. Notre article sur la durée d'une migration WinDev donne des repères de planification.
Pour être accompagné de la cartographie initiale jusqu'à la mise en production du dernier module, découvrez notre offre de migration d'application WinDev.
Questions fréquentes
Peut-on convertir automatiquement une application WinDev en application web ?
Pas de façon satisfaisante pour une application de gestion. Les outils peuvent aider sur une partie du code, mais l'architecture web impose de repenser la séparation entre interface, règles métier et données.
React ou Angular : lequel choisir ?
Les deux conviennent. Angular apporte un cadre structuré apprécié sur les grosses applications de gestion, React plus de souplesse. Le choix dépend surtout des compétences de vos équipes et de votre prestataire.
Faut-il tout migrer d'un coup ?
Non. Nous recommandons une migration module par module, avec une coexistence temporaire entre WinDev et la nouvelle application web.
Et WebDev, ce n'est pas plus simple ?
WebDev permet de réutiliser une partie du savoir-faire WLangage, mais vous restez dans l'écosystème PC SOFT et sa politique de licences. Le choix doit être fait en connaissance de cause.
Que deviennent les états imprimés ?
Ils sont reconstruits avec un moteur de génération PDF côté serveur. C'est un poste à ne pas sous-estimer dans le chiffrage.
Vous envisagez de migrer WinDev vers le web ? Nous cartographions votre application, proposons l'architecture cible et pilotons la migration de votre application WinDev module par module.
