Pourquoi envisager une migration WinDev ?
La migration Windev est devenue un sujet central pour de nombreuses entreprises françaises. Depuis le rachat de PC SOFT par le groupe canadien Volaris, l’écosystème a basculé vers un modèle d’abonnement obligatoire, avec une hausse tarifaire estimée à environ 43 % sur les licences. Cette évolution a fait exploser les recherches liées à la migration Windev, passant de 10 à 50 requêtes mensuelles en juin 2026.
Mais la question tarifaire n’est pas la seule à pousser les directions informatiques à s’interroger. Quatre causes principales se combinent régulièrement :
- La cause économique : le coût de possession de l’environnement WinDev a fortement augmenté, poussant les organisations à recalculer le retour sur investissement du maintien en l’état.
- La cause humaine : le développeur historique qui maîtrise l’application n’est pas remplaçable au même niveau de connaissance. Son départ ou sa retraite bloque toute évolution.
- La cause technique : compatibilité limitée avec les environnements récents, interfaces vieillissantes et absence d’API pour connecter l’application à d’autres outils métier.
- La cause stratégique : impossibilité d’ouvrir un canal web ou mobile sans réécriture complète.
Migration Windev : une réécriture, pas un simple transfert
Il faut être clair dès le départ : la migration Windev vers un autre langage ne se fait pas automatiquement. Le WLangage est un langage propriétaire, et il n’existe aucun outil capable de convertir automatiquement le code vers C#, Java ou JavaScript.
Comme le souligne Laurent Glesner d’EloNeva dans un entretien pour Programmez!, « on ne peut pas parler de migrer au sens strict du terme mais plutôt de réécriture du code et de l’interface ». La partie données constitue un autre chantier majeur : la base HFSQL, bien que basée sur SQL, utilise des schémas et des formats qu’il n’est pas possible de transposer directement.
Ce qui peut être repris et ce qui doit être reconstruit
Une migration Windev réussie commence par un tri précis entre les actifs réellement réutilisables et les éléments à reconstruire :
| Élément | Reprise possible | Commentaire |
|---|---|---|
| Règles métier | Oui | C’est le vrai actif de l’application |
| Interface (fenêtres) | Non | À reconstruire dans la nouvelle technologie |
| Champ Table WinDev | Non | Prévoir un composant tiers équivalent |
| États et impressions | Partiel | Le poste le plus sous-estimé dans les chiffrages |
| Code WLangage | Transcodage assisté | Jamais automatique, relecture humaine nécessaire |
| Base HFSQL | Extraction | Un chantier à part entière |
Vers quelle technologie migrer ?
Le choix de la cible technologique conditionne les recrutements, la maintenabilité et la pérennité de l’application sur 10 à 15 ans. Trois trajectoires principales se dégagent pour une migration Windev.
Migration WindDev vers .NET / C#
.NET est souvent présenté comme la voie la plus naturelle pour sortir de WinDev. Cet écosystème open source depuis 2016 bénéficie d’une feuille de route publique avec des versions LTS clairement définies. Il couvre l’intégralité du périmètre fonctionnel d’une application métier : desktop (WPF, WinForms, MAUI), web (ASP.NET Core, Blazor), API et services en arrière-plan.
Un playbook open source publié sur GitHub propose même une méthode complète pour migrer vers .NET en s’appuyant sur l’intelligence artificielle, avec deux assistants Claude : l’un pour l’architecture et la relecture, l’autre pour l’exécution du code et les tests.
Migration Windev vers Java / Spring Boot
Java n’est jamais le choix le plus rapide ni le moins cher, mais il s’impose comme le choix de la robustesse à grande échelle. Cette cible se justifie lorsque l’application WinDev est un maillon d’un système d’information plus large où Java domine déjà (ETI, groupe, secteur bancaire ou industriel), ou lorsque les volumes de transactions dépassent ce qu’une application de gestion classique rencontre.
Spring Boot apporte des standards de tests unitaires, des pipelines de déploiement automatisés et une portabilité complète (Linux, conteneurs, cloud). L’application, autrefois confinée à sa base HFSQL, devient un citoyen normal du SI, supervisé et intégré comme les autres.
Migration Windev vers le web (WebDev ou SaaS)
Transformer une application WinDev en application web ne consiste pas simplement à « webiser » des fenêtres : c’est un changement de modèle. WEBDEV propose un assistant de webisation qui permet de convertir des fenêtres WinDev en pages web, à condition d’utiliser la version 24 ou ultérieure.
Cependant, cette approche a ses limites. Les fonctionnalités non disponibles sur le web (scanner, communication Bluetooth, traitement de texte) ne peuvent pas être migrées et nécessitent des développements spécifiques. La méthode recommandée est une transition progressive, module par module, sans jamais arrêter l’exploitation.
La méthode de migration Windev étape par étape
Une migration Windev réussie repose sur une méthodologie rigoureuse. Voici les étapes clés.
1. L’audit initial
Avant toute décision, un audit complet est indispensable. Il doit couvrir l’inventaire des modules et de leur usage réel, la volumétrie et la qualité des données HFSQL, les interfaces avec l’extérieur (imports, exports, EDI, matériel connecté), et l’identification des utilisateurs pilotes. Ce travail prend quelques semaines mais garde sa valeur même si le projet est différé d’un an.
2. Le big-bang est une faute de gestion
Tout réécrire en parallèle puis basculer d’un coup est la stratégie au pire historique de l’industrie logicielle. Joel Spolsky l’écrivait dès 2000 dans « Things You Should Never Do ». La migration doit se faire progressivement, en maintenant l’ancienne et la nouvelle application en coexistence pendant la transition.
3. La reconstruction module par module
Chaque module est réécrit, testé et déployé indépendamment. Les données sont migrées en premier, car elles conditionnent le calendrier. Les interfaces avec le matériel et les systèmes tiers sont traitées en priorité, car ce sont elles qui contraignent les délais, pas les écrans.
4. La formation et l’accompagnement
La migration Windev ne se limite pas à la technique. Les équipes doivent être formées aux nouveaux outils, et les utilisateurs accompagnés dans le changement. Négliger cet aspect est l’une des erreurs les plus fréquentes, au même titre que le sous-dimensionnement de l’équipe de maintenance après la mise en production.
Combien coûte une migration Windev ?
Le coût d’une migration Windev dépend de trois facteurs principaux avant même de parler de taille de parc : la trajectoire choisie, la volumétrie réelle du code et l’état de la base HFSQL. Sortir de HFSQL seule coûte nettement moins cher qu’une refonte complète.
À titre indicatif, pour un parc de moins de 15 postes, une migration peut prendre 2 à 4 mois selon la trajectoire. Pour des périmètres plus importants, la durée et le coût augmentent proportionnellement à la complexité des interfaces et des traitements par lots.
Un devis sérieux ne peut être établi sans cartographie préalable. C’est le rôle de l’audit initial. Méfiez-vous des estimations fondées sur le seul nombre de postes ou de fenêtres.
Les erreurs à éviter
Plusieurs pièges guettent les projets de migration Windev :
- Choisir une technologie par prestige sans que le volume ou la criticité réels du parc WinDev le justifient. C’est le moyen le plus sûr de faire exploser le budget sans bénéfice proportionnel.
- Sous-estimer les états et impressions, souvent le poste le plus sous-dimensionné dans les chiffrages.
- Négliger la reprise des traitements par lots existants, qui constituent souvent le cœur caché de l’application.
- Vouloir tout intégrer d’emblée : mieux vaut un périmètre restreint qui fonctionne qu’une architecture complète qui ne stabilise jamais.
Anticiper pour ne pas subir
La migration Windev n’est plus une option théorique pour de nombreuses organisations. Entre la hausse des coûts de licence, la pénurie de compétences WLangage et les besoins croissants en web et mobile, la question n’est plus « faut-il migrer ? » mais « comment migrer sans tout casser ? ».
La réponse tient en trois mots : audit, progressivité, formation. Un audit rigoureux permet de chiffrer le projet sur des bases solides. Une migration progressive, module par module, évite le big-bang destructeur. Et une formation adaptée garantit l’adoption par les équipes.
Plus vous attendez, plus la migration coûte cher — et plus le levier tarifaire de l’éditeur est puissant. Anticiper, c’est reprendre le contrôle de votre système d’information.
