En bref : une application en WinDev 5.5 ou 7.5 peut encore être reprise, mais pas d'un seul saut. Il faut d'abord retrouver les sources et l'analyse, convertir les données Hyper File 5.5 au format actuel, puis remonter le projet dans une version récente et tout retester. Selon l'état du code, une réécriture dans une technologie actuelle peut être plus sûre qu'une remontée de version. Un audit initial permet de trancher.
Il existe encore, dans beaucoup de PME, des applications développées en WinDev 5.5 ou 7.5, au tournant des années 2000. Elles tournent, parfois depuis plus de vingt ans, et font le travail. Jusqu'au jour où un poste est remplacé, où Windows évolue, ou où le seul développeur qui les connaissait n'est plus là. La question devient alors urgente : peut-on encore migrer une version aussi ancienne ? Cet article répond aux questions techniques que l'on nous pose le plus souvent, au 2 novembre 2026. Si vous ne disposez plus des sources, lisez d'abord notre guide pour récupérer le code source d'une application WinDev.
- Pourquoi une application WinDev 5.5 devient risquée
- Est-il encore possible de migrer depuis WinDev 5.5 ou 7.5 ?
- Le cas particulier des données Hyper File 5.5
- Le chemin de migration par étapes
- Vers quelle version remonter ?
- Quand faut-il réécrire plutôt que migrer ?
- Questions fréquentes
Pourquoi une application WinDev 5.5 devient risquée
Une application ancienne qui fonctionne n'est pas un problème en soi. Elle le devient quand son environnement change. Les signaux d'alerte les plus fréquents sont les suivants :
- Les nouveaux postes : l'application s'installe mal ou présente des anomalies d'affichage et d'impression sur les versions récentes de Windows.
- Plus personne ne sait la modifier : l'environnement de développement d'origine n'est plus installé, la licence est perdue ou le développeur est parti.
- Les données sont fragiles : les fichiers Hyper File anciens supportent mal les accès réseau intensifs et les volumes qui ont grossi avec les années.
- La sécurité : aucune mise à jour n'existe pour ces versions, et l'application ne peut pas suivre les exigences actuelles.
Si vous reconnaissez l'un de ces signaux, il est temps d'agir avant la panne. Notre article sur la reprise d'une application WinDev abandonnée détaille le plan d'urgence des dix premiers jours.
Est-il encore possible de migrer depuis WinDev 5.5 ou 7.5 ?
Oui, dans la grande majorité des cas. Mais il faut distinguer trois éléments, qui ne posent pas les mêmes difficultés :
| Élément | Difficulté | Ce qu'il faut vérifier |
|---|---|---|
| Le projet (fenêtres, code WLangage) | Moyenne à élevée | Présence des sources complètes et de l'analyse |
| Les données Hyper File | Moyenne | Format des fichiers et disponibilité de la description (analyse) |
| Les dépendances externes | Variable | DLL, composants ActiveX, pilotes d'imprimante, échanges de fichiers |
Le point de blocage le plus courant n'est pas technique : c'est l'absence de sources. Sans le projet et l'analyse, on ne peut que reconstruire l'application à partir de son comportement, ce qui revient à une réécriture.
Le cas particulier des données Hyper File 5.5
Les données d'une application WinDev 5.5 sont généralement stockées au format Hyper File 5.5, antérieur au format utilisé à partir de WinDev 7. Une différence importante, souvent rappelée sur les forums d'entraide des développeurs WinDev : les fichiers créés à partir de la version 7 contiennent leur propre description, alors que les fichiers 5.5 en sont dépourvus. Pour les lire depuis une version plus récente, il faut donc disposer de l'analyse d'origine, le fichier qui décrit la structure des tables.
En pratique, nous recommandons :
- De sécuriser l'analyse d'origine avant toute opération : sans elle, l'interprétation des fichiers devient beaucoup plus délicate.
- De travailler sur une copie des données, jamais sur les fichiers de production.
- De convertir les données au format actuel, puis de contrôler les volumes, les index, les dates et les caractères accentués.
- D'envisager directement une base SQL si l'application doit être modernisée. Notre guide HFSQL vers PostgreSQL décrit la démarche et la check-list de contrôle.
Si vous restez sur HFSQL, le choix entre le mode Classic et le mode Client/Serveur se pose aussi. Nous le détaillons dans notre comparatif HFSQL Classic ou Client/Serveur.
Le chemin de migration par étapes
On ne passe pas de WinDev 5.5 à une version récente d'un seul coup. Voici le chemin que nous suivons :
- Inventaire : sources, analyse, composants externes, liste des exécutables en production, nombre d'utilisateurs.
- Gel et sauvegarde : copie complète du projet et des données, mise sous gestion de sources.
- Documentation des règles métier : avant de toucher au code, on décrit ce que fait l'application. Notre méthode est détaillée dans l'article extraire les règles métier d'une application WinDev.
- Conversion des données au format actuel, avec contrôles de volumes et de cohérence.
- Remontée du projet dans une version récente, éventuellement en passant par une version intermédiaire si la conversion directe pose problème.
- Correction des fonctions obsolètes, des fenêtres et des états qui ne se comportent plus comme avant.
- Recette avec les utilisateurs, en comparant les résultats de l'ancienne et de la nouvelle version.
Pour les étapes 5 à 7, notre guide sur la montée de version WinDev propose une check-list de tests détaillée.
Vers quelle version remonter ?
La question de la version cible a changé de nature depuis l'annonce des Sessions. Selon la Wx Alliance (22 septembre 2026), seules les applications compilées à partir de la version 2026 entrent dans le périmètre de cette facturation par utilisateur. Remonter une application de WinDev 5.5 directement en 2026 revient donc à accepter cette redevance.
Deux options sont envisageables :
- Remonter en version 2025, si vous disposez d'une licence, pour rester hors du périmètre des Sessions. Notre article geler la version WinDev 2025 en présente les avantages et les risques.
- Sortir de WinDev à l'occasion de la migration, puisque l'application doit de toute façon être reprise en profondeur.
Quand faut-il réécrire plutôt que migrer ?
Remonter une application de vingt ans n'est pas toujours la meilleure idée. Une réécriture est souvent préférable quand :
- les sources sont incomplètes ou introuvables ;
- le code s'est accumulé sans structure et plus personne ne le comprend ;
- l'application doit devenir accessible en ligne ou sur mobile ;
- le coût d'une remontée, ajouté aux Sessions, dépasse celui d'une migration vers une technologie ouverte.
Dans ce cas, l'ancienne application reste précieuse : elle sert de référence pour vérifier que la nouvelle donne les mêmes résultats. Notre article sortir de WinDev : choisir la cible vous aide à choisir la technologie. Dans tous les cas, un audit d'application WinDev permet de trancher sur des faits plutôt que sur des impressions.
Questions fréquentes
Peut-on ouvrir un projet WinDev 5.5 dans une version récente ?
C'est souvent possible, mais rarement sans corrections. Selon l'état du projet, il peut être nécessaire de passer par une version intermédiaire et de reprendre les fonctions devenues obsolètes.
Les fichiers Hyper File 5.5 sont-ils encore lisibles ?
Oui, à condition de disposer de l'analyse d'origine, car ces fichiers ne contiennent pas leur propre description, contrairement aux fichiers créés à partir de WinDev 7.
Que faire si nous n'avons plus les sources ?
Il faut d'abord tenter de les récupérer auprès de l'ancien prestataire ou dans vos archives. À défaut, la seule voie est une réécriture à partir du comportement de l'application et de ses données.
Faut-il remonter l'application en WinDev 2026 ?
Pas forcément. Selon la Wx Alliance, compiler en 2026 fait entrer l'application dans le périmètre des Sessions. Une remontée en 2025 ou une sortie de WinDev sont à comparer.
Combien de temps prend une telle migration ?
Cela dépend de la taille de l'application, de l'état des sources et du volume de données. Seul un audit permet de donner une estimation sérieuse.
Votre application tourne encore en WinDev 5.5 ou 7.5 ? Commencez par un audit de votre application WinDev : nous vérifions les sources, les données et les dépendances, puis nous chiffrons la remontée de version et la réécriture.
