Parce que dans WinDev TOUT découle de l'analyse (RAD, champs liés, requêtes, états) : un modèle de données juste fait gagner un temps énorme, alors qu'un modèle bancal contamine toute l'application et devient très coûteux à corriger une fois les données en production. Pourquoi l'analyse commande tout : (1) Le RAD s'appuie dessus. WinDev peut GÉNÉRER automatiquement des fenêtres, des états et du code à partir de l'analyse. Si l'analyse est propre, la génération produit une base de travail solide ; si elle est bancale, elle génère une application bancale — plus vite, certes, mais bancale. (2) Les CHAMPS se LIENT aux rubriques. Un champ de saisie lié à une rubrique lit et enregistre quasi automatiquement. Renommer ou restructurer une rubrique après coup impacte donc les fenêtres. (3) Les REQUÊTES et les ÉTATS sont bâtis sur les fichiers et les liaisons : les modifier ensuite oblige à reprendre requêtes et impressions. (4) La JUSTESSE des données en dépend : de mauvaises liaisons produisent des doublons, des totaux faux, des incohérences — les pires bugs, car ils ne plantent pas, ils mentent. Pourquoi corriger plus tard coûte cher : (1) Effet domino : changer la structure impose de reprendre les fenêtres, les requêtes, les états et le code qui s'y réfèrent. (2) MIGRATION DES DONNÉES : dès qu'il existe des données réelles (en production), modifier la structure exige de les convertir sans rien perdre — l'opération la plus risquée qui soit. WinDev fournit des mécanismes de modification automatique des fichiers de données, mais le risque et le travail restent réels. (3) Régressions : chaque reprise peut casser ce qui marchait. (4) Le coût d'une correction croît fortement avec l'avancement du projet : quasi nul au moment de la conception, très élevé en production. Comment bien concevoir son analyse : (1) PARTEZ DU MÉTIER, pas de l'écran : quelles sont les entités réelles (client, produit, commande, ligne de commande) et leurs relations ? (2) Une entité = un fichier ; une information élémentaire = une rubrique. (3) Ne mélangez pas plusieurs concepts dans un même fichier. (4) Évitez la RÉPÉTITION d'informations (le même nom de client recopié partout) : c'est le rôle des liaisons. Répéter, c'est risquer des incohérences (on modifie à un endroit et pas à l'autre). (5) Choisissez le bon TYPE pour chaque rubrique (une date en type date, un montant en numérique — jamais en texte) : les types conditionnent les tris, calculs et contrôles. (6) Définissez les CLÉS PRIMAIRES (identifiant unique, souvent automatique). (7) Tracez les LIAISONS conformément aux règles métier (un client a plusieurs commandes ; une commande a plusieurs lignes). (8) VALIDEZ le modèle avec les utilisateurs métier avant de construire : ce sont eux qui savent si « un produit peut appartenir à plusieurs catégories ». (9) Prévoyez raisonnablement l'évolution, sans sur-concevoir. En résumé : soignez l'analyse AVANT les fenêtres parce que dans WinDev tout en découle — le RAD génère l'application à partir d'elle, les champs se lient aux rubriques, les requêtes et états s'y appuient, et la justesse des données en dépend. Une analyse propre transforme le RAD en accélérateur ; une analyse bancale industrialise les problèmes. Et corriger plus tard coûte très cher : effet domino sur fenêtres, requêtes, états et code, plus la MIGRATION DES DONNÉES existantes dès qu'on est en production — l'opération la plus risquée. La bonne méthode : partir du MÉTIER (entités et relations réelles), une entité par fichier, éviter les informations répétées (c'est le rôle des liaisons), choisir les bons TYPES, définir les CLÉS PRIMAIRES, tracer les LIAISONS selon les règles métier, et VALIDER le modèle avec les utilisateurs avant de dessiner le premier écran. C'est l'investissement le plus rentable de tout le projet.

C'est un choix de VOCABULAIRE historique propre à PC SOFT : les concepts sont ceux des bases de données relationnelles classiques (fichier = table, rubrique = colonne, liaison = relation), seuls les mots changent — mais il faut connaître cette correspondance pour ne pas se perdre. La correspondance de vocabulaire : (1) FICHIER (WinDev) = TABLE (SQL) : l'ensemble des enregistrements d'une même nature (le fichier Client contient tous les clients). (2) RUBRIQUE (WinDev) = COLONNE / champ (SQL) : une information élémentaire décrite dans le fichier (Nom, Ville). (3) ENREGISTREMENT (WinDev) = LIGNE / tuple (SQL) : une occurrence concrète (le client Dupont). (4) LIAISON (WinDev) = RELATION / clé étrangère (SQL) : le lien entre deux fichiers. (5) ANALYSE (WinDev) = SCHÉMA / modèle de données (MCD-MLD). Pourquoi ce vocabulaire : (1) Raisons HISTORIQUES : WinDev vient d'une longue tradition d'outils de gestion où l'on manipulait des « fichiers de données » ; le vocabulaire est resté, même si HFSQL est aujourd'hui une vraie base de données relationnelle supportant le SQL. (2) Cohérence interne : tout l'atelier et le WLangage utilisent ces termes (HAjoute, HLitRecherche, parcours de fichier…) — le vocabulaire est homogène dans l'outil et sa documentation. (3) Ce vocabulaire est plus proche du langage courant, ce qui rejoint la philosophie d'accessibilité de PC SOFT. Le piège à éviter : (1) Ne confondez pas le « fichier » au sens de l'analyse (= une table de données) avec un « fichier » au sens du système d'exploitation (un document sur le disque). Le contexte lève l'ambiguïté, mais c'est une source de confusion classique pour les débutants et pour les développeurs venant d'autres technologies. (2) Quand vous lisez de la documentation SQL généraliste ou discutez avec des développeurs d'autres horizons, faites la TRADUCTION mentale : fichier↔table, rubrique↔colonne. Pourquoi c'est important de connaître les DEUX vocabulaires : (1) Le SQL est universel : HFSQL supporte le SQL, et vous écrirez des requêtes avec SELECT, FROM, WHERE, JOIN — donc en pensant en tables et colonnes. Savoir passer d'un vocabulaire à l'autre est indispensable. (2) Vous travaillerez peut-être avec d'AUTRES bases (SQL Server, MySQL, Oracle, PostgreSQL) : WinDev sait s'y connecter, et là c'est le vocabulaire standard qui s'applique. (3) Communication : pour échanger avec des DBA, des développeurs ou lire de la documentation internationale, il faut les termes standards. (4) Compétences transférables : ce sont les CONCEPTS (modèle relationnel, clés, jointures, normalisation) qui valent, pas les mots. Les maîtriser vous rend meilleur en WinDev ET ailleurs. En résumé : WinDev dit « fichier », « rubrique » et « liaison » là où le monde des bases de données dit « table », « colonne » et « relation » — c'est un héritage HISTORIQUE de PC SOFT, cohérent dans tout l'atelier, la documentation et le WLangage, mais les CONCEPTS sous-jacents sont exactement ceux du modèle relationnel classique. Retenez la correspondance : fichier=table, rubrique=colonne, enregistrement=ligne, liaison=relation/clé étrangère, analyse=schéma de données. Attention au piège du mot « fichier », qui ne désigne PAS ici un document du disque. Et surtout, apprenez les DEUX vocabulaires : HFSQL supporte le SQL (vous écrirez des SELECT/JOIN en pensant tables et colonnes), vous serez peut-être amené à travailler avec d'autres bases de données, et ce sont les concepts relationnels — universels et transférables — qui font la vraie compétence, bien au-delà des mots choisis par un éditeur.