Coût migration WinDev : rentable en 1 an ou en 5 ans ? Le calcul pour votre application

En bref. Le coût d’une migration WinDev ne se compare pas au prix d’une licence, mais au coût total de chaque option sur plusieurs années. Pour décider, on chiffre trois scénarios sur le même horizon (souvent cinq ans) : maintenir l’application telle quelle, la moderniser progressivement, ou la réécrire. La migration se justifie quand les économies annuelles remboursent son budget bien avant la fin de cet horizon, et quand l’application a encore une longue vie devant elle. Dans le cas contraire, maintenir reste souvent le choix le plus rationnel.

Ce qui a changé en 2026 : faits, annonces et hypothèses

Deux questions écrites ont été déposées à l’Assemblée nationale en juin 2026, par Philippe Latombe puis par Jérôme End. Elles interrogent le gouvernement sur le rachat, la hausse des tarifs et la redevance facturée à des clients finaux qui n’ont pas de contrat direct avec PC SOFT. Au moment où nous écrivons, aucune réponse ministérielle n’a été publiée.

Conséquence pratique : ne bâtissez pas une décision à plusieurs dizaines de milliers d’euros sur un tarif lu dans un article de blog, y compris celui-ci. Demandez un devis écrit à PC SOFT pour votre propre parc, puis faites tourner le calcul ci-dessous avec ce chiffre.

Les trois options à comparer

1. Maintenir l’application WinDev

Vous continuez à faire évoluer l’application avec WinDev et vous payez les abonnements et redevances. C’est l’option la moins risquée à court terme : l’application fonctionne, vos équipes la connaissent, et aucun projet ne vient perturber l’activité.

Ses limites sont connues : coût récurrent qui dépend des décisions de l’éditeur, vivier de développeurs WLangage plus restreint que pour les langages courants, et dépendance à un seul fournisseur.

2. Moderniser progressivement

Vous gardez l’application en service, mais vous la sortez de WinDev par morceaux. Le schéma le plus fréquent consiste à :

• migrer d’abord les données HFSQL vers une base standard comme PostgreSQL ou SQL Server ;
• exposer ces données par une API ;
• réécrire ensuite les modules un par un, en commençant par ceux qui coûtent le plus en sessions ou qui évoluent le plus souvent.

L’intérêt est d’étaler l’investissement et le risque. L’inconvénient est une période de coexistence pendant laquelle vous payez à la fois l’ancien et le nouveau.

3. Migrer par réécriture complète

Vous réécrivez l’application dans une technologie courante : .NET, Java, une application web (par exemple React avec une API), ou un outil plus léger si le besoin le permet. Il n’existe pas d’outil qui convertisse automatiquement le WLangage en code maintenable : même assistée par l’IA, une migration reste une réécriture qu’il faut spécifier, tester et recetter.
C’est l’option qui supprime le plus vite la dépendance, mais aussi celle qui concentre le plus de risque sur une courte période.

Comment calculer le coût de chaque option

Le principe : un coût total sur le même horizon

Pour comparer, on calcule le coût total de possession (TCO) de chaque option sur le même horizon, en général cinq ans :

TCO = coût de départ + (coûts annuels × nombre d’années)

Le coût de départ est nul ou faible pour « maintenir », et élevé pour « migrer ». Les coûts annuels, eux, sont souvent plus élevés pour « maintenir ».

Les postes à inclure

Côté WinDev (option « maintenir » et période de coexistence) :

• Abonnements des postes de développement
• Redevance d’exécution : nombre de sessions × prix par session
• Licences serveur WebDev, le cas échéant
• Maintenance corrective et évolutive (temps de développeur)
• Risque de dépendance : hausse future possible, difficulté de recrutement.

Côté migration (options « moderniser » et « migrer ») :

• Audit et inventaire de l’existant (fenêtres, états, règles métier, interfaces) ;
• Reprise des données HFSQL, souvent sous-estimée quand la base est partagée entre plusieurs postes ou sites
• Développement, tests et recette
• Formation des utilisateurs et accompagnement
• Double fonctionnement pendant la bascule
• Marge pour imprévus, d’autant plus large que l’application est mal documentée

Ce qui continue de coûter après la migration :

• Hébergement et infrastructure
• Maintenance de la nouvelle application, qui ne disparaît pas
• Éventuelles licences de la nouvelle pile (base de données, outils, services cloud)
• Montée en compétences de l’équipe interne.

Oublier ces coûts persistants est l’erreur la plus fréquente : elle fait paraître toute migration rentable en quelques mois.

Le délai de retour sur investissement

Une fois les postes chiffrés, le calcul de base tient en une ligne :

Délai de retour (en années) = budget de migration ÷ économies annuelles nettes

Les économies annuelles nettes sont la différence entre les coûts annuels de l’option « maintenir » et ceux de l’option retenue, coûts persistants compris.

Un exemple chiffré, entièrement hypothétique

Prenons une entreprise fictive avec une application de bureau WinDev utilisée par 40 personnes, chacune sur un poste. Nous retenons l’hypothèse d’un prix catalogue de 290 € HT par session et par an, et nous supposons que la maintenance coûte la même chose avant et après migration.

• Redevance d’exécution annuelle : 40 × 290 € = 11 600 € HT par an.
• Économies annuelles nettes si l’application quitte WinDev : environ 11 600 €, hors abonnements de développement.

Pourquoi on trouve si peu de prix publics ?

Si vous cherchez « prix migration WinDev », vous trouverez surtout des fourchettes très larges, de quelques centaines d’euros pour une petite reprise à plusieurs dizaines de milliers pour un logiciel métier complet. Elles ne sont pas fausses, mais elles ne disent rien de votre cas. Le budget dépend de quelques variables que seul un inventaire permet de mesurer :

• Le nombre de fenêtres, d’états et de traitements
• La complexité des règles métier et leur documentation
• Le volume et la qualité des données HFSQL
• Les interfaces avec d’autres logiciels (comptabilité, ERP, matériel)
• Le niveau d’exigence en tests et en continuité de service

Quand ne pas migrer

Migrer n’est pas toujours la bonne réponse. Il vaut souvent mieux maintenir l’application, au moins pour l’instant, dans les cas suivants :

• L’application a une fin de vie prévue dans les deux ou trois ans (remplacement par un progiciel, fusion, arrêt d’activité).
• Le nombre d’utilisateurs est faible et la redevance reste modeste face au coût d’une réécriture.
• Les règles métier ne sont documentées nulle part et les personnes qui les connaissent ne sont pas disponibles pour un projet.
• Votre équipe ne peut pas absorber un projet en parallèle de son activité, et vous n’avez pas de budget pour vous faire accompagner.
• Le devis réel de PC SOFT est très inférieur à l’hypothèse que vous aviez en tête.

Dans ces situations, la bonne décision peut être de maintenir tout en réduisant la dépendance : documenter l’application, sortir les données de HFSQL, et préparer un plan de modernisation à déclencher plus tard.

Deux situations qui changent le calcul

Rester sur sa version actuelle

Certaines entreprises envisagent de ne plus renouveler leur abonnement et de rester sur la dernière version acquise. Avant d’en faire une stratégie, faites confirmer par écrit deux points : ce que prévoit votre contrat pour les applications déjà déployées, et si la redevance d’exécution s’applique à elles. Gardez aussi en tête qu’une application figée cesse de recevoir les correctifs de l’outil, ce qui devient un risque de sécurité et de compatibilité avec les futures versions de Windows.

Une base HFSQL partagée entre plusieurs postes

Quand plusieurs postes ou plusieurs sites partagent la même base HFSQL, la migration des données devient le cœur du projet. C’est aussi souvent la meilleure première étape : une fois les données dans une base standard, chaque module peut être réécrit à son rythme, et vous gagnez en sauvegarde, en sécurité et en possibilités de reporting, même si vous ne migrez rien d’autre.

La méthode en cinq étapes

1. Inventorier l’application : modules, fenêtres, états, bases, interfaces, nombre réel d’utilisateurs.
2. Obtenir un devis écrit de PC SOFT pour votre parc, plutôt que de raisonner sur un prix public.
3. Chiffrer les trois scénarios sur le même horizon, coûts persistants compris.
4. Calculer le délai de retour et le confronter à la durée de vie prévue de l’application.
5. Décider et séquencer : maintenir, moderniser par étapes ou réécrire, avec un premier lot à faible risque.