Sortir de HFSQL : extraire et fiabiliser vos données

Votre base de données est au format HFSQL, le moteur propriétaire de PC SOFT. Tant que l'application WinDev ou WebDev qui l'exploite reste en place, ce format ne pose pas de problème visible. Le verrou apparaît au moment où vous envisagez une migration HFSQL vers un environnement plus ouvert.

Cette page détaille ce qui bloque réellement quand on veut exporter une base HFSQL, les trois cibles courantes, et la méthode qui limite le risque de perte de données pendant la bascule.

Elle s'adresse aux responsables informatiques et aux dirigeants qui savent que leur base HFSQL contient l'essentiel de la valeur métier de leur système d'information, et qui veulent comprendre ce que représente réellement une extraction avant de la lancer ou de la sous-traiter.

Cette page complète la page dédiée à la migration WinDev pour qui veut approfondir spécifiquement le sujet de la base de données, souvent traité trop rapidement dans les premiers chiffrages, alors qu'il conditionne directement la fiabilité de tout le reste du projet.

Pourquoi HFSQL est le vrai verrou

Beaucoup de dirigeants pensent que migrer une application PC SOFT se limite à réécrire l'interface. Dans la majorité des dossiers que nous traitons, la base HFSQL est en réalité le chantier le plus long et le plus risqué de la migration.

• Format propriétaire non lisible nativement par les outils SQL standards, ce qui impose une étape d'extraction avant toute exploitation externe.
• Types de données spécifiques à HFSQL, sans équivalence directe et automatique vers PostgreSQL, SQL Server ou MySQL.
• Contraintes et liaisons parfois gérées au niveau applicatif plutôt qu'au niveau de la base, donc invisibles tant qu'on ne relit pas le code WLangage qui les applique.

Ce verrou n'est pas toujours perçu comme tel tant que l'application WinDev ou WebDev associée reste en place. Il devient concret dès qu'un projet de reporting, de connexion à un outil tiers ou de migration applicative impose d'accéder aux données autrement que par l'application d'origine.

Ce qui ne se transpose pas automatiquement

Aucun outil ne convertit une base HFSQL vers une base SQL standard sans intervention humaine sur plusieurs points.

Chacun de ces points demande une vérification manuelle, table par table. C'est ce travail de détail, plus que le volume brut de données, qui détermine la durée réelle d'un chantier d'extraction HFSQL.

Cibles : PostgreSQL, SQL Server, MySQL

Le choix se fait rarement pour des raisons techniques pures : il suit l'écosystème déjà en place chez vous, ou celui de la technologie cible retenue pour l'application qui exploite la base.

Dans les trois cas, la performance et la fiabilité obtenues dépassent largement celles d'une base HFSQL sur les mêmes volumes, grâce à des décennies d'optimisation communautaire et industrielle sur ces moteurs. Ce n'est pas une critique de HFSQL, conçu pour un autre usage, mais un constat sur l'écart d'outillage disponible autour de chaque technologie.

Cet écart se traduit concrètement par un accès plus large à des outils de supervision, de sauvegarde et de réplication, souvent déjà standardisés dans les infrastructures cloud actuelles, alors qu'une base HFSQL impose des solutions plus spécifiques et moins interopérables avec le reste du système d'information.

Méthode d'extraction et de recette

L'extraction d'une base HFSQL suit une méthode en plusieurs étapes, toujours dans le même ordre.

• Cartographie complète des tables, champs, types et liaisons, y compris celles qui ne sont pas documentées.
• Extraction des données vers un format intermédiaire, puis chargement dans la base cible.
• Recette croisée : comparaison ligne à ligne entre l'ancienne et la nouvelle base sur un échantillon représentatif, puis sur l'intégralité des tables critiques.
• Bascule planifiée avec fenêtre de synchronisation finale, pour garantir zéro perte entre le dernier export et la mise en production.

La recette croisée est l'étape la plus sous-estimée par les équipes qui découvrent ce type de chantier. Comparer deux bases ligne à ligne demande des scripts de vérification dédiés, pas une simple relecture visuelle, en particulier sur les tables volumineuses ou celles qui contiennent des champs calculés.

Bases décentralisées : le cas des réseaux d'agences

Certaines organisations exploitent une base HFSQL par agence, par site ou par magasin, sans synchronisation centrale. Ce cas ajoute une étape avant l'extraction elle-même : il faut d'abord harmoniser les schémas, parfois légèrement différents d'une agence à l'autre après des années d'évolutions locales, avant de pouvoir consolider les données dans une base cible unique.

La consolidation révèle souvent des doublons entre agences : un même client ou un même produit enregistré différemment d'un site à l'autre. Ces doublons doivent être identifiés et arbitrés avant la bascule, avec les équipes métier concernées, plutôt que résolus arbitrairement par un script automatique qui risquerait de fusionner des enregistrements distincts.

Durée type d'un chantier HFSQL

La durée d'un chantier d'extraction HFSQL dépend du nombre de tables, de la présence ou non de bases décentralisées, et de la qualité des données existantes : doublons, champs mal renseignés, incohérences accumulées au fil des années.

Sur un dossier limité à une dizaine de tables et une base unique, l'extraction et la recette se bouclent en quelques semaines. Un réseau d'agences avec plusieurs bases décentralisées et des dizaines de tables étend le chantier sur plusieurs mois.

Cette durée s'ajoute à celle de la migration de l'application elle-même, sans forcément la retarder. Sur une trajectoire de migration progressive, l'extraction HFSQL démarre en amont, pendant que la cartographie de l'interface et des règles métier se poursuit en parallèle, ce qui raccourcit la durée totale perçue du projet.

L'audit de code gratuit inclut un premier inventaire de votre base HFSQL et une estimation de durée avant tout engagement.