En bref : HFSQL Classic stocke les données dans des fichiers que chaque poste lit et écrit directement, souvent sur un partage réseau. HFSQL Client/Serveur confie l'accès aux données à un moteur serveur qui centralise les requêtes. Le mode Classic convient à un poste isolé ou à un très petit réseau ; au-delà, le mode Client/Serveur est plus fiable, plus sûr et plus performant. Dans les deux cas, connaître votre mode actuel est indispensable pour préparer une migration.
Beaucoup d'applications WinDev reposent sur HFSQL, la base de données fournie par PC SOFT. Mais HFSQL existe en deux modes très différents : Classic et Client/Serveur. Les dirigeants l'ignorent souvent, alors que ce choix conditionne la fiabilité de l'application, la sécurité des données et le coût d'une future migration. Cet article explique les différences, propose un tableau de décision et détaille l'impact sur un projet de migration. Si vous constatez déjà des lenteurs ou des corruptions de fichiers, lisez aussi nos signaux qui doivent déclencher un audit de base de données.
- HFSQL Classic : des fichiers partagés
- HFSQL Client/Serveur : un moteur central
- Tableau décisionnel : Classic ou Client/Serveur ?
- Passer de Classic à Client/Serveur : ce qu'il faut prévoir
- Quel impact sur une migration vers une autre base ?
- Questions fréquentes
HFSQL Classic : des fichiers partagés
En mode Classic, chaque table est un ensemble de fichiers sur disque : un fichier de données, un fichier d'index et, le cas échéant, un fichier pour les mémos (textes longs, images). L'application WinDev ouvre directement ces fichiers.
Sur un poste seul, c'est simple et rapide. Dans une entreprise, les fichiers sont généralement placés dans un dossier partagé sur un serveur de fichiers ou un NAS, et chaque poste y accède à travers le réseau. C'est là que les difficultés commencent :
- Chaque poste lit les fichiers à travers le réseau, ce qui génère beaucoup de trafic dès que le volume augmente.
- Les blocages sont gérés par chaque poste, sans arbitre central. Une coupure réseau ou un poste qui plante pendant une écriture peut laisser un fichier ou un index dans un état incohérent.
- La sécurité repose sur les droits du partage Windows. Un utilisateur qui a accès au dossier peut copier ou supprimer les fichiers.
- Les sauvegardes à chaud sont délicates, puisque les fichiers peuvent être ouverts en écriture à tout moment.
Le mode Classic reste adapté à une application monoposte, à un outil embarqué ou à un très petit réseau avec peu d'écritures simultanées.
HFSQL Client/Serveur : un moteur central
En mode Client/Serveur (souvent abrégé C/S), un moteur HFSQL est installé sur un serveur, sous Windows ou Linux. Les postes n'accèdent plus aux fichiers : ils envoient leurs requêtes au moteur, qui les exécute et renvoie uniquement les résultats.
Ce fonctionnement apporte plusieurs bénéfices concrets :
- Moins de trafic réseau, puisque seuls les résultats circulent.
- Une gestion centralisée des accès concurrents et des transactions, ce qui réduit fortement le risque de corruption.
- Des comptes utilisateurs et des droits propres à la base, indépendants du partage de fichiers.
- Des outils d'administration : sauvegardes planifiées, suivi de l'activité, statistiques, procédures stockées et déclencheurs côté serveur.
- Des options de haute disponibilité, comme la réplication, pour les applications les plus critiques.
En contrepartie, il faut installer, sécuriser et surveiller un serveur. C'est une tâche d'administration à prévoir, en interne ou chez un prestataire.
Tableau décisionnel : Classic ou Client/Serveur ?
Le tableau suivant vous aide à situer votre application. Il s'agit de repères qualitatifs : la frontière exacte dépend du volume de données et de la fréquence des écritures.
| Situation | Mode conseillé | Pourquoi |
|---|---|---|
| Application monoposte ou embarquée | Classic | Simplicité, aucun serveur à gérer |
| Quelques postes, peu d'écritures simultanées | Classic acceptable, C/S recommandé | Le risque de corruption augmente avec chaque poste ajouté |
| Plusieurs utilisateurs qui saisissent en même temps | Client/Serveur | Gestion centralisée des blocages et des transactions |
| Accès à distance, télétravail, plusieurs sites | Client/Serveur | Le partage de fichiers à distance est lent et fragile |
| Données sensibles ou réglementées | Client/Serveur | Comptes et droits propres à la base, traçabilité |
| Migration prévue à moyen terme | Client/Serveur ou migration directe | Un modèle de données assaini facilite la reprise |
En cas de doute, un audit de base de données permet de mesurer l'état de vos fichiers, les volumes et les points de contention avant de décider.
Passer de Classic à Client/Serveur : ce qu'il faut prévoir
Le passage de Classic à Client/Serveur est généralement moins lourd qu'une migration vers une autre base. L'analyse WinDev (le modèle de données) reste la même ; ce qui change, c'est la façon dont l'application se connecte aux données. PC SOFT fournit des outils pour transférer les fichiers vers un serveur HFSQL.
Quelques points demandent toutefois de l'attention :
- Le code qui manipule directement les fichiers (chemins en dur, copies de fichiers, réindexations lancées par l'application) doit être revu.
- Les traitements lourds peuvent être optimisés en les déplaçant côté serveur.
- Les sauvegardes et la supervision doivent être mises en place dès le premier jour.
- Les tests de montée en charge sont indispensables avant la bascule.
Attention aussi au contexte économique. Comme nous l'expliquons dans notre article Sessions WinDev facturées en 2026, PC SOFT a annoncé la facturation des sessions HFSQL. Avant d'investir dans un passage en Client/Serveur, mesurez votre exposition avec notre article calculer le coût des sessions WinDev.
Quel impact sur une migration vers une autre base ?
Si vous envisagez de quitter WinDev ou HFSQL, le mode actuel change la préparation du projet :
- Depuis Classic, il faut d'abord vérifier l'intégrité des fichiers. Des années d'utilisation en partage réseau laissent souvent des index corrompus, des enregistrements orphelins ou des doublons. Le nettoyage des données représente une part importante de l'effort.
- Depuis Client/Serveur, les données sont en général plus saines, mais il faut recenser les procédures stockées et les déclencheurs côté serveur : ce sont des règles métier à reprendre dans la nouvelle base ou dans l'application.
Dans les deux cas, le passage vers une base standard comme PostgreSQL suit les mêmes étapes : transposition du modèle, gestion des types de données propres à HFSQL, reprise à blanc et contrôles de cohérence. Notre guide HFSQL vers PostgreSQL les détaille pas à pas.
Enfin, si vous hésitez à faire évoluer votre version de WinDev pour éviter les nouvelles conditions tarifaires, notre article faut-il geler votre version WinDev ? présente les avantages et les risques de cette option.
Questions fréquentes
Quelle est la différence entre HFSQL Classic et Client/Serveur ?
En Classic, chaque poste lit et écrit directement les fichiers de données, souvent sur un partage réseau. En Client/Serveur, un moteur central reçoit les requêtes des postes et gère seul l'accès aux données.
HFSQL Classic convient-il à un usage en réseau ?
Pour quelques postes avec peu d'écritures simultanées, il fonctionne. Au-delà, le risque de lenteurs et de corruption de fichiers augmente, et le mode Client/Serveur est préférable.
Le passage en Client/Serveur demande-t-il de réécrire l'application ?
Non, l'analyse reste la même. Il faut surtout revoir le code qui manipule directement les fichiers, mettre en place le serveur et tester la montée en charge.
Comment savoir si mon application utilise Classic ou Client/Serveur ?
Si les fichiers de données se trouvent dans un dossier partagé ouvert par chaque poste, vous êtes en Classic. Si un service HFSQL tourne sur un serveur et que les postes s'y connectent, vous êtes en Client/Serveur.
Faut-il passer en Client/Serveur avant de migrer vers PostgreSQL ?
Pas nécessairement. Si la migration est décidée, il est souvent plus efficace de nettoyer les données Classic et de migrer directement vers la base cible.
Classic, Client/Serveur ou migration ? Faites le point avec un audit de votre base de données HFSQL : intégrité, volumes, performances et scénarios chiffrés.
