En bref : Une mise à jour de version WinDev se prépare comme un petit projet : inventaire, environnement de test, conversion du projet, corrections, puis recette complète. Le risque principal ne vient pas de la compilation mais des comportements qui changent sans erreur visible. Une check-list de tests métier est le meilleur moyen de livrer sans mauvaise surprise. En 2026, le choix de la version cible doit aussi tenir compte de la nouvelle politique tarifaire de PC SOFT.
Beaucoup d'applications WinDev en production ont été compilées avec une version ancienne : WinDev 19, 21 ou 23 ne sont pas rares. Tant que l'application tourne, la montée de version est repoussée. Puis un jour, un nouveau poste sous une version récente de Windows, un besoin de connecteur ou une faille de sécurité oblige à franchir le pas. Plus l'écart entre les versions est grand, plus l'opération demande de méthode. Ce guide décrit la procédure que nous appliquons, les risques à anticiper et, surtout, la check-list de tests à dérouler après la montée de version. Les éléments de contexte tarifaire sont à jour au 2 novembre 2026.
- Pourquoi faire une mise à jour de version WinDev
- Quelle version cible choisir en 2026 ?
- La procédure pas à pas
- Les risques à anticiper
- La check-list de tests après montée de version
- Quel budget prévoir ?
- Questions fréquentes
Pourquoi faire une mise à jour de version WinDev
Une montée de version n'est pas une fin en soi. Elle se justifie par des besoins concrets, qu'il faut identifier avant de commencer :
- Compatibilité système : les anciennes versions de WinDev n'ont pas été testées sur les dernières versions de Windows et de Windows Server.
- Sécurité : les versions récentes intègrent des protocoles et des bibliothèques plus à jour, notamment pour les échanges chiffrés.
- Fonctionnalités : nouveaux champs, nouvelles fonctions WLangage, meilleure prise en charge des API web. PC SOFT annonce par exemple 900 nouveautés pour la version 2026.
- Maintenabilité : trouver un développeur prêt à travailler sur une version très ancienne devient difficile.
Si aucun de ces besoins n'est réel, rester sur la version actuelle peut être un choix raisonnable, à condition de l'assumer et d'en connaître les risques. Notre article faut-il geler votre version WinDev ? détaille ce scénario.
Quelle version cible choisir en 2026 ?
Le choix de la version cible a changé de nature cette année. Selon la Wx Alliance (billet du 22 septembre 2026), seules les applications compilées à partir de la version 2026 consomment des « Sessions », le nouveau mode de facturation à l'usage de PC SOFT. Monter en version 2026 n'est donc plus une décision purement technique : elle peut avoir un impact direct sur vos coûts d'exploitation.
Concrètement, deux options se dessinent pour la plupart des entreprises :
- Viser la version 2025 pour bénéficier des correctifs récents sans entrer dans le système de Sessions, en acceptant de ne pas profiter des nouveautés 2026.
- Viser la version 2026 après avoir chiffré l'impact des Sessions sur votre parc.
Pour comprendre ce mécanisme, lisez notre article sur la redevance à la session WinDev. Pour le coût des licences de développement, consultez notre guide du prix d'une licence WinDev en 2026.
La procédure pas à pas
Une montée de version bien conduite suit toujours le même enchaînement. Sauter une étape fait gagner quelques jours au début et en fait perdre beaucoup plus à la fin.
- Inventaire : version actuelle, composants externes, DLL, connecteurs natifs, états, traitements planifiés, postes et serveurs concernés.
- Sauvegarde et gel : archivez le projet dans sa version d'origine, avec ses exécutables. C'est votre point de retour.
- Environnement de test : un poste et, si besoin, un serveur HFSQL dédiés, avec une copie récente des données de production.
- Conversion du projet : ouverture dans la nouvelle version, migration de l'analyse, recompilation.
- Corrections : erreurs et avertissements de compilation, fonctions obsolètes, composants à remplacer.
- Recette : déroulé de la check-list de tests, d'abord par l'équipe technique, puis par les utilisateurs référents.
- Déploiement : mise à jour des postes et du serveur, avec une procédure de retour arrière écrite.
Pour les écarts de version importants, il est souvent plus sûr de passer par une version intermédiaire plutôt que de sauter directement de plusieurs générations.
Les risques à anticiper
Le piège classique consiste à croire que le travail est terminé quand le projet compile. En réalité, les problèmes les plus coûteux sont ceux qui ne produisent aucune erreur :
- Comportements modifiés : une fonction WLangage dont le comportement par défaut a évolué, un arrondi, un format de date.
- États et impressions : marges, polices et sauts de page peuvent bouger d'une version à l'autre.
- Composants tiers : un composant ou une DLL sans équivalent récent peut bloquer toute la migration.
- Base de données : la mise à jour du moteur HFSQL et le format des fichiers doivent être planifiés avec soin.
- Postes clients : les applications de versions différentes ne cohabitent pas toujours bien sur un même poste.
Un audit d'application WinDev en amont permet d'identifier ces points de fragilité avant de lancer les travaux, et donc de les chiffrer.
La check-list de tests après montée de version
Voici la liste que nous déroulons systématiquement après une montée de version. Adaptez-la à votre application, mais ne la raccourcissez pas.
| Domaine | À vérifier |
|---|---|
| Installation | Installation et mise à jour sur un poste vierge et sur un poste existant |
| Connexion | Authentification, droits utilisateurs, groupware |
| Données | Lecture, création, modification et suppression sur chaque fichier principal |
| Calculs | Totaux, arrondis, TVA, remises, dates et échéances sur des cas réels |
| États | Factures, bons, étiquettes : mise en page, PDF, impression physique |
| Échanges | Imports, exports, envois de mails, appels d'API, fichiers Excel |
| Traitements planifiés | Exécution nocturne, journaux, reprise sur erreur |
| Performances | Temps de réponse des écrans et requêtes les plus utilisés |
La méthode la plus fiable consiste à comparer les résultats de l'ancienne et de la nouvelle version sur les mêmes données. C'est le principe de notre méthode Mirror pour prouver la parité, qui s'applique aussi aux montées de version.
Quel budget prévoir ?
Il n'existe pas de prix unique : le budget dépend de l'écart de versions, de la taille du projet, du nombre de composants externes et de la qualité du code. Les postes de dépense, eux, sont toujours les mêmes :
- Licence de développement dans la version cible.
- Analyse préalable : inventaire et identification des risques.
- Conversion et corrections : la part la plus variable, de quelques jours à plusieurs semaines selon l'état du projet.
- Recette : temps technique et temps des utilisateurs, souvent sous-estimé.
- Déploiement et accompagnement des premiers jours.
À titre d'ordre de grandeur générique, une petite application bien structurée se met à jour beaucoup plus vite qu'un gros projet sans documentation qui accumule les versions de retard. Le plus sûr est de demander un chiffrage après analyse du projet. Nos équipes de développement WinDev réalisent ce type d'estimation.
Questions fréquentes
Peut-on passer directement de WinDev 19 à WinDev 2025 ?
C'est souvent possible, mais l'écart est grand. Selon la complexité du projet, un passage par une version intermédiaire peut réduire les risques. Un inventaire préalable permet de trancher.
La base HFSQL doit-elle aussi être mise à jour ?
Le plus souvent oui, au moins le moteur et parfois le format des fichiers. Cette étape se planifie avec une sauvegarde complète et un test de restauration.
Monter en version 2026 déclenche-t-il les Sessions ?
Selon la Wx Alliance (22 septembre 2026), seules les applications compilées à partir de la version 2026 consomment des Sessions. Vérifiez ce point auprès de PC SOFT avant de choisir votre version cible.
Combien de temps dure une montée de version WinDev ?
De quelques jours pour une petite application récente à plusieurs semaines pour un projet volumineux et ancien. La recette représente une part importante de ce délai.
Faut-il prévenir les utilisateurs ?
Oui. Ils doivent participer à la recette et être informés de la date de bascule. Prévoyez aussi une procédure de retour arrière en cas de problème bloquant.
Vous préparez une mise à jour de version WinDev ? Nos experts en développement WinDev analysent votre projet, chiffrent la montée de version et prennent en charge la recette.
