« On souhaite quitter WinDev, mais combien ça va nous coûter ? Et comment être sûr de ne pas perdre tout ce qu'on a développé ? »
Ce sont des questions que nous entendons régulièrement chez Dev-Booster. Avec l'évolution des conditions commerciales de PC SOFT, des entreprises et des éditeurs réfléchissent à moderniser leurs applications. Et après 10 ou 20 ans de développement, on ne prend pas cette décision à la légère.
Nous travaillons avec WinDev depuis plus de 20 ans. Voici les cinq sujets à éclaircir avant de lancer une migration vers .NET, le Web ou une autre technologie.
1. Combien va coûter la migration de mon logiciel WinDev ?
C'est généralement la première question, et il n'existe pas de prix universel. Un logiciel de 50 fenêtres peut être plus complexe à reprendre qu'une application qui en possède 150. Tout dépend des traitements, des règles métier, de l'architecture, des éditions et des échanges avec des logiciels tiers.
Faut-il tout redévelopper ?
Pas nécessairement. Nous analysons ce qui peut être conservé, ce qui doit être réécrit et ce qui n'est plus utilisé. Après quinze années d'évolutions, certaines fenêtres n'ont plus d'utilité : les reproduire à l'identique coûterait de l'argent pour rien. Les outils de développement actuels, y compris l'IA pour certaines tâches, peuvent accélérer la reprise, mais ne remplacent pas l'analyse de l'existant.
Comparer le coût de la migration… et celui du maintien de l'existant
Pour illustrer la question, prenons une hypothèse de 290 € HT par session et par an, tarif de référence évoqué en 2026 pour certaines offres PC SOFT. Voici le coût théorique si chaque utilisateur nécessite une session :
- 5 utilisateurs : 1 450 € HT/an, soit 4 350 € sur 3 ans.
- 10 utilisateurs : 2 900 € HT/an, soit 8 700 € sur 3 ans.
- 25 utilisateurs : 7 250 € HT/an, soit 21 750 € sur 3 ans.
- 50 utilisateurs : 14 500 € HT/an, soit 43 500 € sur 3 ans.
- 100 utilisateurs : 29 000 € HT/an, soit 87 000 € sur 3 ans.
- 200 utilisateurs : 58 000 € HT/an, soit 174 000 € sur 3 ans.
- 500 utilisateurs : 145 000 € HT/an, soit 435 000 € sur 3 ans.
Il s'agit d'une simulation, pas d'un devis PC SOFT ni d'un tarif garanti actuellement : le tarif de référence a évolué, les contrats peuvent différer, toutes les installations ne comptent pas nécessairement une session par utilisateur et les coûts complémentaires ne sont pas inclus. Les projections sur trois ans supposent un prix constant.
Pour un éditeur comptant 200 sessions, cette hypothèse représente 58 000 € HT par an. Ce n'est pas une raison suffisante pour migrer immédiatement, mais c'est une raison sérieuse de comparer le coût total des deux scénarios sur trois à cinq ans : licences, développement, hébergement, maintenance, formation et évolutions futures.
2. Comment être certain que mon nouveau logiciel fonctionnera aussi bien que l'ancien ?
Une application WinDev qui fonctionne depuis quinze ans renferme souvent des règles métier que personne n'a formalisées. Un contrôle à la sortie d'un champ, un plafond de remise, une exception de facturation ou une règle de stock peuvent être disséminés dans les événements des fenêtres et les procédures.
Reproduire l'apparence des écrans ne suffit pas. Il faut retrouver ces règles et valider le comportement métier du nouveau logiciel. Nous privilégions, lorsque le projet le permet, une migration en blocs fonctionnels cohérents avec des comparaisons entre les deux applications.
Sur une facture, par exemple, les calculs de TVA, de remises, les arrondis et les droits de modification doivent être vérifiés. Même chose pour les mouvements de stock ou les règlements. Une migration à blanc et une phase de tests utilisateurs peuvent limiter les mauvaises surprises.
Le risque zéro n'existe pas, mais la préparation et la validation réduisent fortement les incertitudes.
3. Comment éviter de redevenir dépendant d'un éditeur ?
On peut être propriétaire de son code source et rester dépendant d'un environnement pour le compiler et le faire évoluer. C'est l'une des préoccupations des entreprises qui souhaitent quitter WinDev.
Des technologies largement adoptées comme C#, .NET, React, Symfony ou PostgreSQL donnent souvent davantage de choix : outils de développement, prestataires, hébergeurs et profils à recruter. Elles ne garantissent pas à elles seules une indépendance totale. L'architecture, les composants, la documentation et les clauses contractuelles comptent tout autant.
Nous considérons qu'un client doit pouvoir conserver la maîtrise de son application, notamment grâce à l'accès aux sources, à la documentation, aux procédures de déploiement et aux éléments nécessaires à sa maintenance, dans le cadre prévu au contrat.
Quitter un écosystème fermé pour devenir dépendant d'un nouveau prestataire n'aurait aucun intérêt.
4. Que deviennent mes données HFSQL pendant la migration ?
Un changement d'application pose souvent la question de la base de données. Faut-il conserver HFSQL ou passer vers PostgreSQL, SQL Server, MySQL ou une autre solution ? La réponse dépend de l'architecture, des volumes et des besoins futurs.
Dans de nombreux cas, les données peuvent être extraites et transférées. Mais une migration sérieuse demande davantage qu'un export de tables : vérifier les types, les dates, les décimales, les identifiants, les relations, l'intégrité et les historiques.
Chez Dev-Booster, nous avons développé un outil de migration HFSQL vers plusieurs moteurs, dont PostgreSQL, MySQL, MariaDB, Firebird et SQL Server. Il accélère certaines opérations techniques, sans dispenser de contrôler les données reprises.
Nous pouvons aussi organiser une migration à blanc afin de comparer les volumes, les montants et les données sensibles avant la bascule définitive. Les données sont souvent l'actif le plus précieux du logiciel : leur reprise mérite autant d'attention que le code.
5. Combien de temps dure une migration, et peut-on continuer à utiliser l'ancien logiciel ?
Il n'existe pas davantage de durée universelle que de prix universel. Tout dépend du périmètre, de l'état du code, des dépendances, de la qualité de la documentation et du temps de validation nécessaire. Une fonctionnalité développée n'est pas encore une fonctionnalité validée.
Quand l'architecture le permet, il est possible de migrer progressivement, voire de faire cohabiter des modules anciens et nouveaux. Dans d'autres projets, mieux vaut préparer une nouvelle application complète avant de basculer.
Selon les enjeux, on peut prévoir une migration à blanc, un groupe pilote, une courte période de fonctionnement parallèle, une bascule planifiée et une procédure de retour arrière. Ces solutions doivent être étudiées dès le cadrage.
Une migration réussie, ce n'est pas seulement un nouveau logiciel : c'est aussi une transition maîtrisée pour ses utilisateurs.
Alors, faut-il vraiment quitter WinDev ?
Après plus de vingt ans dans cet environnement, nous n'allons pas prétendre que WinDev ne permet pas de faire de bons logiciels. Nous en avons développé beaucoup, et certains continuent de très bien fonctionner.
Mais entre les évolutions commerciales de PC SOFT, les outils disponibles aujourd'hui et la volonté de garder davantage de liberté, la question mérite d'être posée : combien coûte le maintien de l'existant, combien coûterait la migration, et que gagnerait-on dans cinq ans ?
Chez Dev-Booster, nous connaissons à la fois WinDev, le WLangage et HFSQL, et des technologies comme .NET, React, Next.js, Symfony, PostgreSQL et SQL Server. Cette double expérience nous permet d'étudier une migration progressive, une réécriture ou le maintien temporaire de certains composants, selon les contraintes réelles.
Vous envisagez de quitter WinDev ?
Que votre logiciel compte 20, 100 ou plusieurs centaines de fenêtres, la première étape consiste à comprendre son fonctionnement, son coût actuel et ses risques. Nous pouvons en discuter et examiner avec vous les différentes trajectoires possibles.
Jérémy Depoortere — Dirigeant de Dev-Booster