En 2026, j’ai dû choisir entre poursuivre avec une version de WinDev sous abonnement ou revenir à une version perpétuelle que je possédais déjà, protégée par un dongle.
Le choix de WinDev 28 répondait à un objectif simple : conserver un environnement de développement stable et maîtrisé, sans abandonner des années de code, d’analyses HFSQL et de règles métier.
Le véritable enjeu n’était pas l’installation de la V28. Il fallait rendre plusieurs projets 2026 réellement compatibles, compilables et fonctionnels dans une version antérieure, sans altérer les données ni perdre les évolutions métier récentes.
Un downgrade WinDev n’est pas un simple « Enregistrer sous »
Les formats de projets WinDev ne sont pas conçus pour être ouverts directement dans une version antérieure. Entre WinDev 2026 et WinDev 28, un projet peut avoir évolué à plusieurs niveaux :
- structure de l’analyse HFSQL, rubriques, index et liaisons ;
- classes, procédures, requêtes et composants ;
- fenêtres, plans, champs, ancrages et événements ;
- états et impressions ;
- syntaxe WLangage ou fonctions apparues après la V28 ;
- groupware utilisateur et métadonnées de gestion de sources.
Une compilation sans erreur ne prouve donc pas que la migration est terminée. Une fenêtre peut compiler tout en ayant perdu un champ, une liaison, une géométrie ou un comportement. Un état peut s’ouvrir mais produire un document différent. La méthode devait contrôler le code, la structure et le résultat métier.
1. Figer et sauvegarder chaque source
J’ai commencé par identifier précisément la bonne version 2026 de chaque projet et sa cible V28. Chaque dossier cible a été sauvegardé avant intervention, avec un manifeste d’empreintes SHA-256 pour pouvoir vérifier son intégrité et revenir à l’état initial.
Les projets ont été traités séparément. Cette discipline évite de mélanger les sources, les anciennes copies, les projets hors périmètre et les éléments déjà migrés.
2. Produire une référence comparable
Pour chaque projet, j’ai généré une documentation complète depuis WinDev 2026 et depuis WinDev 28. J’ai également exporté les structures SQL des analyses lorsqu’elles existaient.
Ces références ont permis de construire un inventaire des objets et de qualifier les écarts :
- objets absents ou supplémentaires ;
- rubriques et contraintes différentes ;
- lignes de code modifiées ;
- champs d’interface à ajouter, déplacer ou contrôler ;
- éléments identiques ne nécessitant aucune action.
Le but n’était pas de copier tout le projet 2026, mais de reporter uniquement les différences utiles et vérifiées.
3. Reconstituer l’analyse HFSQL dans le bon ordre
J’ai d’abord aligné les analyses : tables, rubriques, types, index, cardinalités et règles de suppression ou de modification. Après chaque lot, l’analyse V28 était régénérée puis exportée en SQL afin de vérifier qu’aucune modification parasite n’avait été introduite.
Aucune synchronisation des données de production n’était lancée tant que la cible n’était pas structurellement validée. Cette séparation entre description et données a fortement réduit le risque.
4. Reporter le code et les interfaces
Les classes, procédures, requêtes, fenêtres et états ont ensuite été repris par lots courts. Les éléments natifs étaient comparés dans les deux environnements, puis contrôlés après report dans la V28.
Pour les interfaces, j’ai vérifié les plans, les conteneurs, les champs enfants, les attributs, les ancrages et les coordonnées. Pour les états, le contrôle incluait l’aperçu avant impression. Les différences liées uniquement à la génération documentaire étaient distinguées des véritables écarts fonctionnels.
5. Compiler, tester et réintégrer proprement
Chaque lot suivait le même cycle : modification ciblée, génération, comparaison indépendante, recompilation complète puis contrôle fonctionnel. Les avertissements étaient conservés dans le suivi au lieu d’être assimilés à une validation.
Les éléments validés étaient ensuite réintégrés dans le gestionnaire de sources, avec un contrôle final pour vérifier qu’aucun objet ne restait extrait. Cette démarche a permis d’aligner plusieurs projets de tailles et de rôles différents, y compris des applications principales, des services REST et des utilitaires.
Trois solutions pour sortir d’une dépendance WinDev
Le downgrade vers WinDev 28 n’est pas la seule réponse. Le choix dépend de l’état de l’application, de sa durée de vie, de ses utilisateurs et de la stratégie informatique de l’entreprise.
Solution 1 — Downgrade vers une version avec dongle
Cette solution conserve l’application WinDev, ses habitudes d’utilisation et son architecture générale. Le projet est rendu compatible avec une version perpétuelle légalement licenciée, comme WinDev 28 avec dongle.
Elle convient lorsque l’application reste adaptée au métier et que l’objectif principal est de stabiliser l’outil sans abonnement récurrent. Elle exige toutefois un audit précis : certaines fonctions récentes doivent être adaptées ou remplacées.
Solution 2 — Migration vers une application Web open source
L’application est reconstruite sur une architecture Web ouverte, par exemple avec Django et PostgreSQL. Elle devient accessible depuis un navigateur sur Windows, Linux, macOS, Android ou iOS, sans installer un client WinDev sur chaque poste.
Les données HFSQL sont reprises dans une base standard, les règles métier sont revalidées et la bascule est préparée sur une copie. L’ancienne application peut rester disponible en lecture seule pendant la transition.
Solution 3 — Migration vers une application client-serveur multiplateforme
Lorsque le métier nécessite une application installée, un fonctionnement local renforcé ou des interactions matérielles spécifiques, une nouvelle solution client-serveur peut être développée avec des technologies ouvertes.
Cette approche permet de viser plusieurs systèmes d’exploitation, de conserver une ergonomie proche d’un logiciel de bureau et de choisir librement la base de données, l’hébergement et le cycle de maintenance.
Préserver les données et l’activité avant tout
Dans les trois scénarios, la méthode reste la même : audit, inventaire des règles métier, migration à blanc, contrôles de conformité, recette utilisateur et bascule planifiée. La base d’origine reste intacte pendant la préparation.
Pour une reconstruction Web ou client-serveur, l’ancienne et la nouvelle solution peuvent fonctionner en parallèle pendant la recette. Nous préparons alors la reprise finale pour obtenir une migration transparente, sans interruption de service lorsque la configuration le permet.
Une migration réussie ne consiste pas seulement à déplacer des fichiers. Elle doit préserver les données, les calculs, les documents, les droits et les habitudes indispensables au fonctionnement quotidien.
Vous souhaitez quitter un abonnement WinDev, revenir vers une version avec dongle ou migrer vers une technologie ouverte ? Retrouvez notre méthode et les trois solutions proposées sur migrerdepuiswindev.provencecloud.com.
Si la migration échoue selon les critères convenus du fait de Provence Cloud, la prestation de migration n’est pas facturée. L’audit préalable, prestation autonome, reste dû. Voir les conditions détaillées.
WinDev, WEBDEV, HFSQL et HyperFileSQL sont des marques de PC SOFT. Provence Cloud est un prestataire indépendant et n’est pas affilié à cet éditeur.