HFSQL vers PostgreSQL : migrer les données d'une application WinDev sans perte

Une base HFSQL migrée vers PostgreSQL peut afficher le bon nombre de lignes dans chaque table et contenir de mauvaises données : factures sans client, doublons que l'ancien moteur tolérait, dates vides. Voici notre méthode, de l'analyse du schéma à la bascule, en passant par une étape que beaucoup sautent : faire tourner WinDev sur PostgreSQL pendant la réécriture. Ce chantier s'inscrit dans notre guide complet de la migration WinDev.

Pourquoi PostgreSQL

PostgreSQL est libre, sans redevance, accessible depuis tous les langages, les ETL et les outils de BI. Son modèle de concurrence (MVCC) évite que les lectures bloquent les écritures. Et tous les clouds l'opèrent en service managé : sur Google Cloud, Cloud SQL pour PostgreSQL couvre la plupart des applications de gestion, AlloyDB prend le relais quand le workload analytique ou transactionnel le justifie.

Étape 1 : extraire et transposer le schéma

L'éditeur d'analyses de WinDev génère le script SQL de création des tables. C'est un point de départ : la transposition demande des décisions explicites, type par type. Voici la correspondance que nous recommandons.

Type HFSQL	Cible PostgreSQL	Point de vigilance
Chaîne, chaîne Unicode	varchar(n) ou text	Encodage ANSI ou Unicode selon les fichiers
Numérique, monétaire	numeric(p,s)	Jamais de flottant pour des montants
Date, heure, date-heure	date, time, timestamp	Dates vides ou 00000000 à interpréter
Booléen	boolean	Valeurs historiques parfois stockées en entier
Mémo texte	text	Taille, encodage
Mémo binaire	bytea ou stockage objet	Volume, externalisation possible
Identifiant automatique	bigint generated always as identity	Recaler les séquences après import

Étape 2 : rendre explicite ce qui était implicite

La plupart des migrations simplifiées échouent sur ce point. Dans beaucoup d'applications WinDev, les clés étrangères ne figurent pas dans la base : le code garantit, plus ou moins, la cohérence. Sealog le résume : les clés primaires et étrangères de HFSQL sont « parfois implicites ou gérées de façon non stricte par l'application »¹. Nous les déclarons dans PostgreSQL.

Conséquence directe : la première migration à blanc fait remonter des orphelins (lignes de facture sans facture, règlements sans client), des doublons sur des index que HFSQL tolérait, des valeurs hors domaine. Chaque anomalie appelle une décision : corriger, archiver ou tolérer avec une contrainte différée. Le métier prend ces décisions ; le script les applique.

Étape 3 : nettoyer avant de migrer, pas après

Nous traitons le nettoyage comme un livrable : une liste d'anomalies par table, avec la règle appliquée et sa validation. Un agent classe les anomalies et propose des règles de correction ; le responsable métier choisit celles qui s'appliquent.

Étape 4 : migrations à blanc et rapports de conformité

Chaque migration à blanc se fait sur une copie, la base d'origine restant en lecture seule. Elle produit un rapport de conformité à quatre niveaux :

• volumétrie : nombre de lignes par table, source et cible ;
• intégrité : clés, relations, unicité ;
• contenu : sommes de contrôle par colonne, échantillons comparés ;
• sens métier : totaux de factures, soldes clients, quantités en stock, recalculés des deux côtés.

Nous validons la migration quand les chiffres tombent juste, au centime. Nous répétons les migrations à blanc jusqu'à obtenir deux rapports de conformité consécutifs sans écart ; la durée de la dernière fixe la fenêtre de bascule.

Étape 5 : la phase transitoire, WinDev sur PostgreSQL

Les accès natifs permettent à une application WinDev de travailler sur PostgreSQL avec des instructions proches de celles utilisées pour HFSQL. Sealog recommande cette étape intermédiaire¹ ; nous la pratiquons : l'application existante tourne sur la nouvelle base pendant que la nouvelle application se construit.

Vous sortez d'HFSQL sans attendre la réécriture ; les deux applications partagent la même base pendant la cohabitation ; le golden master compare des écritures dans le même moteur. Point de vigilance : le SQL écrit à la main dans l'application, dont la syntaxe propre à HFSQL reste partiellement incompatible.

Étape 6 : la bascule

Pour une base en production active : migration initiale, puis synchronisation des deltas jusqu'à la bascule applicative. Nous écrivons et testons la procédure de retour arrière avant le jour J.

Outils et ordres de grandeur du marché

Le marché propose des outils et des prestations dédiés. BTBSofting vend UniDataTransfer, une licence perpétuelle pour un poste, 199,99 € HT (239,99 € TTC) au prix affiché sur son site en octobre 2026². Provence Cloud propose un audit de la base HFSQL dont le montant est déduit du prix de la migration si celle-ci est commandée dans les six mois suivant la remise du rapport ; la migration n'est pas facturée en cas d'échec selon les critères convenus, l'audit préalable restant dû (aucun tarif n'est affiché publiquement)³. Dev-Booster a développé un outil maison de migration HFSQL vers PostgreSQL, MySQL, MariaDB, Firebird et SQL Server⁴. Sealog écrit son outil de migration en WinDev, l'environnement qui connaît nativement HFSQL : « La solution la plus fiable reste de développer un outil de migration en WinDev lui-même »¹. Ces offres couvrent la donnée. L'application et la décision sur les anomalies restent à votre charge.

Questions fréquentes

Peut-on migrer HFSQL Classic comme HFSQL Client/Serveur ?

Oui, la méthode est la même. Le Classic demande souvent plus de nettoyage, car il a rarement été contraint.

Combien de migrations à blanc prévoir ?

Autant qu'il en faut pour obtenir deux rapports de conformité consécutifs sans écart. En pratique, plusieurs.

Faut-il conserver la structure à l'identique ?

Pour la phase transitoire, oui, afin que WinDev continue de fonctionner. La refonte du modèle vient ensuite, module par module.

MySQL ou SQL Server sont-ils possibles ?

Oui. Nous recommandons PostgreSQL par défaut pour son ouverture et son support cloud.

Passer à l'action

La donnée est souvent le premier lot que nous traitons, car elle réduit la dépendance dès la bascule. Voir aussi le choix de la stack cible et la méthode globale pour réécrire une application WinDev avec l'IA. Point d'entrée : le Diagnostic 10x.

Sources

1. Sealog, De WinDev à l'open source : comment l'IA a changé la donne — blogsealog.blogspot.com, 5 juillet 2026.
2. BTBSofting, UniDataTransfer — unidatatransfer.btbsofting.fr.
3. Provence Cloud, Migration HFSQL vers PostgreSQL, MariaDB, SQL Server — migrerdepuiswindev.provencecloud.com.
4. Dev-Booster, Feuilleton de l'été, épisode 3 — dev-booster.com, 14 août 2026.