Parce que toute donnée répétée finit par DIVERGER (modifiée à un endroit et pas à l'autre), ce qui produit des incohérences, des totaux faux et des bugs très difficiles à corriger — le rôle des LIAISONS est précisément d'éviter cette duplication. Le problème de la répétition : (1) INCOHÉRENCE garantie à terme. Si le nom d'un client est stocké à la fois dans le fichier Client ET recopié dans chaque Commande, que se passe-t-il quand le client change de nom ? Soit on met tout à jour partout (fastidieux et faillible), soit on oublie — et l'application affiche deux noms différents pour le même client. La question n'est pas SI cela arrivera, mais QUAND. (2) Données FAUSSES silencieusement. C'est le pire type de défaut : l'application ne plante pas, elle ment. Les recherches donnent des résultats incomplets, les regroupements se dédoublent, les statistiques sont fausses. (3) ESPACE et performance : stocker mille fois la même adresse gaspille de la place et alourdit les traitements. (4) MAINTENANCE alourdie : chaque modification doit être répercutée à plusieurs endroits, dans le code comme dans les données. (5) Quelle est la « bonne » valeur ? Quand deux copies divergent, plus personne ne sait laquelle fait foi. La solution : les LIAISONS : (1) Chaque information est stockée UNE SEULE FOIS, à l'endroit qui lui correspond : le nom du client dans le fichier Client, le libellé du produit dans le fichier Produit. C'est la « source de vérité ». (2) Les autres fichiers s'y RÉFÈRENT par la clé (l'identifiant) : la Commande ne stocke pas le nom du client, elle stocke l'IDENTIFIANT du client. (3) Pour afficher le nom, on suit la liaison (jointure) — WinDev le fait naturellement dans les requêtes, les états et les champs liés. (4) Résultat : on modifie le nom à UN seul endroit, et tout l'affichage suit automatiquement, partout. C'est exactement le principe de la NORMALISATION en modélisation relationnelle. L'exception à connaître (données historiques) : (1) Il existe un cas où l'on duplique VOLONTAIREMENT : les données HISTORIQUES qui doivent être FIGÉES. Exemple classique : le PRIX d'un produit sur une ligne de commande. (2) Si la ligne de commande se contente de pointer vers le produit, alors changer le prix du produit demain modifierait rétroactivement le montant de toutes les anciennes factures — inacceptable comptablement. (3) On stocke donc le prix pratiqué AU MOMENT de la commande dans la ligne de commande. Ce n'est pas une duplication accidentelle, c'est une donnée de nature différente : « le prix facturé ce jour-là » n'est pas « le prix actuel du produit ». (4) Même logique pour l'adresse de facturation figée sur un document émis. La règle : (1) Duplication PAR DÉFAUT : NON — utilisez les liaisons. (2) Duplication VOLONTAIRE et RAISONNÉE : uniquement pour figer un historique, et en le documentant. En résumé : ne répétez pas une information parce que les copies FINISSENT TOUJOURS par diverger — on modifie une occurrence et pas les autres — ce qui produit des données incohérentes, des recherches incomplètes, des statistiques fausses et des bugs sournois (l'application ne plante pas, elle ment), tout en gaspillant de l'espace et en alourdissant la maintenance. La solution est le rôle même des LIAISONS : stocker chaque information UNE SEULE FOIS à sa place légitime (le nom dans le fichier Client) et la référencer ailleurs par sa CLÉ (la Commande stocke l'identifiant du client, pas son nom), l'affichage suivant la liaison. Une modification à un seul endroit se propage alors partout automatiquement — c'est le principe de la normalisation relationnelle. Seule exception, volontaire et documentée : figer des données HISTORIQUES (le prix pratiqué au moment de la commande, l'adresse de facturation d'un document émis), car il s'agit conceptuellement d'une donnée différente de la valeur actuelle, qui ne doit pas changer rétroactivement.

Privilégiez presque toujours une CLÉ AUTOMATIQUE (identifiant technique généré par le moteur) : elle est stable, simple et sans surprise ; les clés « métier » (code client, numéro de sécurité sociale, e-mail) semblent séduisantes mais posent des problèmes dès qu'elles changent ou se dupliquent. Ce que doit être une clé primaire : (1) UNIQUE : deux enregistrements ne peuvent jamais avoir la même valeur. (2) STABLE : elle ne doit jamais changer au cours de la vie de l'enregistrement (car d'autres fichiers y font référence). (3) TOUJOURS RENSEIGNÉE : jamais vide. (4) De préférence COMPACTE et simple (performances des liaisons et des index). Pourquoi la clé AUTOMATIQUE est recommandée : (1) Elle garantit l'unicité sans effort : le moteur s'en charge, aucun risque de collision. (2) Elle est parfaitement STABLE : n'ayant aucune signification métier, elle n'a aucune raison de changer. C'est l'argument décisif. (3) Elle est simple et performante (un numérique, idéal pour les index et les jointures). (4) Elle ne fuite aucune information et ne dépend d'aucune règle externe. (5) WinDev la gère nativement (identifiant automatique) — c'est la pratique standard. Pourquoi les clés « MÉTIER » posent problème : (1) Elles CHANGENT. Un code client est renuméroté lors d'une réorganisation, un e-mail change, une référence produit est revue. Or modifier une clé primaire oblige à répercuter le changement dans TOUS les fichiers liés — opération lourde et risquée. (2) Leur unicité n'est pas garantie : deux personnes peuvent partager une adresse e-mail familiale ; une référence peut être réattribuée. (3) Elles peuvent être ABSENTES à la création (on ne connaît pas encore le code). (4) Données PERSONNELLES : utiliser un identifiant national ou un e-mail comme clé pose des questions de confidentialité et de conformité (⚠️ la réglementation sur les données personnelles VARIE selon les pays — vérifiez le droit applicable chez vous). (5) Elles sont souvent plus longues (texte), donc moins efficaces en index et en jointures. La bonne pratique (le meilleur des deux) : (1) Clé PRIMAIRE = identifiant automatique (technique, interne, jamais montré à l'utilisateur si possible). (2) Code métier = rubrique NORMALE avec une contrainte d'UNICITÉ (un index unique). Ainsi le code client reste unique et exploitable pour les recherches et l'affichage, mais s'il change un jour, cela n'impacte AUCUNE liaison — seule la rubrique est modifiée. (3) C'est la combinaison gagnante : robustesse technique + besoin métier satisfait. (4) Documentez ce choix pour l'équipe. Cas particuliers : (1) Les fichiers de LIAISON (associations n,n) peuvent avoir une clé composée des deux identifiants — c'est acceptable car ces valeurs sont elles-mêmes stables. (2) Pour des données de référence figées et normalisées de façon externe, une clé métier peut se défendre — mais vérifiez sa stabilité réelle. En résumé : choisissez presque toujours la CLÉ AUTOMATIQUE. Une clé primaire doit être UNIQUE, TOUJOURS renseignée et surtout STABLE ; l'identifiant automatique coche toutes ces cases sans effort, il est compact et performant, et n'a aucune raison de changer puisqu'il ne porte aucune signification métier. Les clés « métier » (code client, e-mail, identifiant national) échouent justement sur la STABILITÉ — elles changent lors des réorganisations — obligeant alors à propager la modification dans tous les fichiers liés ; leur unicité est souvent illusoire, elles peuvent manquer à la création, et les données personnelles soulèvent des questions de conformité (⚠️ variable selon les pays). La bonne pratique combine les deux : clé PRIMAIRE automatique pour la technique et les liaisons, PLUS le code métier en rubrique normale avec une contrainte d'UNICITÉ pour les besoins d'affichage et de recherche. Si le code métier change, aucune liaison n'est affectée.