Passez en Client/Serveur dès que plusieurs utilisateurs travaillent simultanément de façon intensive, que les volumes grossissent, que vous avez besoin de sécurité fine ou d'accès distants — le Classic reste parfait en monoposte ou pour quelques postes en usage léger. Ce que fait le CLASSIC (et ses limites) : (1) En Classic, chaque poste ACCÈDE DIRECTEMENT aux fichiers de données, posés sur le disque local ou un partage réseau. Il n'y a pas de serveur intermédiaire. (2) Avantages : aucune installation de serveur, gratuité totale, simplicité de déploiement, parfait pour une application monoposte ou une petite équipe en usage modéré. (3) Limites : tout le TRAVAIL est fait par le poste client, qui doit lire beaucoup de données à travers le réseau. Plus il y a d'utilisateurs et de données, plus le réseau devient le goulot d'étranglement. (4) Robustesse : une coupure réseau, un poste éteint brutalement pendant une écriture, ou un partage instable peuvent endommager les fichiers de données — le risque augmente avec le nombre de postes. (5) Sécurité : les fichiers étant accessibles sur un partage, leur protection dépend surtout des droits du système de fichiers. Les signaux qui doivent faire basculer : (1) Plusieurs utilisateurs SIMULTANÉS travaillant intensément (au-delà de quelques postes en usage léger). C'est le critère principal. (2) LENTEURS qui s'aggravent : recherches longues, listes lentes à s'afficher, temps de réponse dégradés aux heures de pointe. (3) VOLUMES qui grossissent (beaucoup d'enregistrements, historiques importants). (4) Besoin de SÉCURITÉ : gestion fine des droits d'accès par utilisateur, données confidentielles à protéger (le Client/Serveur centralise et contrôle les accès, avec chiffrement possible des échanges). (5) ACCÈS DISTANTS (télétravail, agences, itinérants) : le Classic sur partage réseau distant est à proscrire — le Client/Serveur est conçu pour cela. (6) Incidents de données à répétition ou craintes de corruption. (7) Besoins avancés : sauvegardes à chaud, réplication, journalisation, supervision. Ce qu'apporte le CLIENT/SERVEUR : (1) Le SERVEUR fait le travail et ne renvoie que les RÉSULTATS : le trafic réseau chute, les performances montent nettement en multi-utilisateurs. (2) ROBUSTESSE : les accès concurrents sont gérés proprement par le moteur, le risque de corruption diminue fortement. (3) SÉCURITÉ : authentification, droits par utilisateur, chiffrement des communications. (4) ADMINISTRATION : outils de supervision, sauvegardes (y compris à chaud), maintenance centralisée. (5) Meilleure montée en charge. Comment gérer la transition : (1) Bonne nouvelle : le code WLangage reste très largement le MÊME — l'analyse ne change pas et les fonctions H fonctionnent dans les deux modes. La migration porte surtout sur la configuration de connexion et le déploiement. (2) Prévoyez l'installation et le paramétrage du serveur, la migration des données, la mise à jour des paramètres de connexion et un plan de sauvegarde. (3) TESTEZ sur une copie avant de basculer la production. (4) Formez-vous (ou faites-vous accompagner) sur l'administration du serveur. En résumé : restez en HFSQL CLASSIC tant que vous êtes en monoposte ou sur un petit réseau en usage léger — c'est simple, gratuit et sans serveur à administrer. Basculez en CLIENT/SERVEUR dès qu'apparaissent les signaux : plusieurs utilisateurs simultanés intensifs (le critère n°1), lenteurs croissantes aux heures de pointe, volumes de données importants, besoin de SÉCURITÉ fine (droits par utilisateur, confidentialité, chiffrement), ACCÈS DISTANTS (télétravail, agences — le Classic sur partage distant est à proscrire), incidents de corruption, ou besoins avancés (sauvegarde à chaud, réplication, supervision). Le Client/Serveur transforme l'architecture : le serveur traite et ne renvoie que les résultats, ce qui réduit massivement le trafic réseau, améliore les performances, sécurise et fiabilise les accès concurrents. Bonne nouvelle pour la migration : l'analyse et le code WLangage restent très largement identiques — l'essentiel du travail porte sur l'installation du serveur, la migration des données, les paramètres de connexion et le plan de sauvegarde. Testez toujours sur une copie avant de basculer.

Les INDEX accélèrent massivement les recherches et les tris (au lieu de parcourir toute la base, le moteur va droit au but), mais ils ont un COÛT à l'écriture et en espace : il faut donc en mettre sur ce qui est réellement recherché ou trié, pas partout. Ce qu'est un index et pourquoi il accélère : (1) Un INDEX est une structure ordonnée que le moteur maintient sur une rubrique — l'équivalent de l'index alphabétique d'un livre. (2) Sans index, chercher un client par son nom oblige le moteur à examiner TOUS les enregistrements un par un (parcours complet). Sur cent mille clients, c'est cent mille lectures. (3) Avec index, le moteur va directement au bon endroit, en un nombre d'opérations très réduit. Le gain n'est pas de quelques pourcents : il peut être de plusieurs ORDRES DE GRANDEUR. (4) C'est pourquoi l'indexation est souvent l'optimisation la plus RENTABLE : quelques secondes de configuration peuvent transformer une recherche de 10 secondes en une recherche instantanée. Ce qu'il faut indexer : (1) Les CLÉS PRIMAIRES — automatiquement indexées, c'est indispensable. (2) Les rubriques de RECHERCHE fréquente : le nom d'un client, une référence produit, un numéro de commande, un code. Si un utilisateur tape une valeur pour retrouver un enregistrement, cette rubrique mérite un index. (3) Les rubriques de LIAISON (clés étrangères) : essentielles, car elles sont utilisées dans toutes les jointures. Une jointure sur une rubrique non indexée est un classique des applications lentes. (4) Les rubriques de TRI fréquent (afficher les commandes par date). (5) Les rubriques servant de FILTRE habituel. Pourquoi ne PAS tout indexer : (1) COÛT à l'ÉCRITURE : chaque index doit être MIS À JOUR à chaque ajout, modification ou suppression. Multiplier les index ralentit donc les écritures — ce qui est très sensible sur les imports et traitements par lot. (2) ESPACE DISQUE : les index occupent de la place, parfois significative. (3) Inutilité : indexer une rubrique jamais recherchée (un champ mémo de commentaire, une rubrique purement descriptive) ne sert à rien et coûte quand même. (4) Faible sélectivité : indexer une rubrique qui ne prend que deux ou trois valeurs différentes (un booléen, un statut binaire) apporte peu, car l'index ne réduit guère le champ de recherche. La bonne méthode : (1) Partez des USAGES réels : quelles recherches vos utilisateurs font-ils vraiment ? Quels tris ? Quelles jointures ? (2) Indexez systématiquement clés primaires et clés étrangères (liaisons). (3) Ajoutez les rubriques de recherche et de tri fréquentes. (4) MESUREZ : si une recherche est lente, regardez si la rubrique concernée est indexée — c'est la première chose à vérifier. (5) Réévaluez quand les usages évoluent ou que les volumes grossissent : un index inutile sur une petite base peut devenir vital sur une grosse. (6) Attention aussi aux requêtes qui empêchent l'usage d'un index (recherches commençant par un caractère générique, calculs appliqués à la rubrique). En résumé : les INDEX sont décisifs parce qu'ils évitent au moteur de parcourir toute la base pour trouver un enregistrement — le gain peut atteindre plusieurs ordres de grandeur, ce qui en fait l'optimisation la plus rentable en base de données. Mais NON, il ne faut pas en mettre partout : chaque index doit être mis à jour à chaque écriture (ce qui ralentit ajouts, modifications, suppressions et surtout les imports en masse) et consomme de l'espace disque. Indexez donc ce qui est réellement utilisé : les CLÉS PRIMAIRES (d'office), les rubriques de LIAISON/clés étrangères (essentielles pour les jointures — une jointure non indexée est une cause classique de lenteur), les rubriques de RECHERCHE fréquente (nom, référence, code) et de TRI habituel. Évitez d'indexer les rubriques jamais recherchées ou celles à très faible sélectivité (deux ou trois valeurs possibles). La démarche : partir des usages réels, indexer clés et liaisons systématiquement, puis MESURER — devant une recherche lente, le premier réflexe est de vérifier l'index — et réévaluer quand volumes et usages évoluent.