Concevoir en troisième forme normale, puis prendre du recul
Aussi en 28 langues
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)
Module 5 sur 6 du chapitre Modéliser les données pour leur sens, chapitre 2 du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Mettre les données à leur place · Suivant : Transformer le modèle en Salesforce
La question à laquelle répond ce module : quand dois-je m’éloigner volontairement d’un modèle propre et normalisé ?
Dans le module précédent, je vous ai dit de concevoir en troisième forme normale.
Maintenant, je vais vous dire de la casser.
Parfois.
C’est une distinction importante. Il y a une grande différence entre construire par accident un modèle de données désordonné et dénormaliser délibérément un modèle propre. Si vous ne comprenez pas d’abord où les données ont leur place, les copier ailleurs n’est pas de l’architecture. C’est juste de la duplication.
Mais une fois que je comprends le modèle logique propre, je peux décider consciemment de donner aux données une autre forme pour les personnes et les systèmes qui les consomment.
Concevoir en troisième forme normale quand c’est faisable. Puis prendre du recul quand c’est nécessaire.
Remarquez ce que cette phrase ne dit pas. Elle ne dit pas que la troisième forme normale est plus facile à comprendre. Parfois, elle l’est moins : un modèle entièrement normalisé peut éparpiller une même idée métier sur cinq objets, et ceux qui l’utilisent doivent la reconstituer dans leur tête. La normalisation me dit où chaque fait a sa place. Elle ne promet pas que c’est la forme la plus facile à lire, à utiliser ou à exploiter en rapport. C’est exactement pourquoi prendre du recul est une compétence de conception et non un échec.
Commencez par modéliser la vérité. Puis décidez comment cette vérité doit être livrée.
Assis, pas bouger, modèle
Section intitulée « Assis, pas bouger, modèle »Retour aux chiens, et cette fois nous faisons quelques choix délibérés.
La Race : une liste de sélection, ou sa propre table ? Passez-la au crible des questions que je vous donnerai plus loin dans ce module. Y a-t-il plus d’une colonne d’information ? Oui : la taille, au moins. Combien de valeurs ? Les clubs canins reconnaissent quelques centaines de races (l’American Kennel Club en recense à lui seul 205), bien au-delà de ma règle empirique d’une vingtaine. La Race mérite donc sa propre table, et chaque chien pointe vers sa race. Cela tranche la question que nous portons depuis le module 1 : la Race est une boîte à part entière.
Le Niveau de maîtrise : une liste de sélection. En apprentissage, Bon, Expert. Trois libellés, rien d’autre à en dire, et ils ne changeront pas. C’est exactement à cela que sert une liste de sélection.
Combien de tours chaque chien connaît-il ? La réponse est déjà dans le modèle : comptez les enregistrements Tour du chien du chien. Mais le dresseur veut ce nombre sur chaque rapport, pour trier et filtrer dessus, sans construire un rapport sur deux tables. Alors je prends du recul, et je garde un compteur Tours connus directement sur le chien. C’est une copie. La vérité vit toujours dans Tour du chien ; le compteur en est une représentation, et il doit rester synchronisé. Salesforce nous donne une façon propre de faire exactement cela, et nous la verrons au module 6.
Maintenant, le rebondissement : l’école pour chiens commence à accepter les chats. Que faisons-nous ? Première option : ajouter une table Chat à côté de la table Chien, et un Tour du chat à côté du Tour du chien. Tout double : deux de chaque écran, deux de chaque rapport, et le jour où l’école accepte les lapins, trois. L’autre option : prendre du recul et remarquer qu’un chat a un propriétaire, peut-être un éleveur, une race, une date de naissance et, avec de la patience, un tour ou deux. Les mêmes faits et les mêmes relations qu’un chien. Alors nous généralisons : un Animal, avec une Espèce, chien ou chat. Chaque race appartient aussi à une espèce, et c’est là que l’espèce vit vraiment : un labrador est un chien. L’animal en porte une copie, volontairement, pour que chaque écran et chaque rapport puisse commencer par « chien ou chat ? » sans aller chercher la race. Encore une copie délibérée, et au module 6 elle reçoit un rôle à part entière.
C’est concevoir pour le changement, et c’est un compromis. Généralisez trop tôt et tout devient une vague « Chose » avec un champ de type que personne ne comprend. Je généralise quand le métier m’apporte réellement le deuxième type, et que les deux partagent presque tout, comme les chiens et les chats ici. Si les chats avaient besoin de faits très différents, j’y réfléchirais à deux fois.
Voyons maintenant le même genre de choix chez Steve Trucking, où les enjeux sont plus élevés.
Le modèle le plus propre n’est pas toujours le meilleur système
Section intitulée « Le modèle le plus propre n’est pas toujours le meilleur système »Imaginez une équipe à un arrêt. La livraison a ses articles. L’installation a une liste de contrôle. Chaque étape demande des photos. Le destinataire signe.
Le modèle normalisé est magnifique : Livraison → Article de livraison → Liste de contrôle d’installation → Photo, chacun à sa place.
Puis je m’assois avec les gens qui l’utilisent réellement. Une équipe clôt une dizaine d’arrêts par jour, dans des allées de garage, souvent sans réseau. Si mon beau modèle les fait passer par un labyrinthe d’écrans et de listes associées pour terminer un arrêt, j’ai un problème d’architecture.
Le modèle de données n’est pas la seule chose que nous concevons.
Nous concevons un système.
Parfois, l’expérience utilisateur l’emporte
Section intitulée « Parfois, l’expérience utilisateur l’emporte »C’est l’une des raisons pour lesquelles je m’éloigne parfois d’un modèle parfaitement normalisé : l’expérience utilisateur.
Un concept pourrait techniquement être sa propre entité, mais le séparer ajoute une complexité qui apporte très peu. Un parent avec plusieurs niveaux d’enfants est propre sur le plan académique mais pénible à saisir et à maintenir. Le concept est petit, stable, et sert surtout de sélection.
C’est là que je cesse de demander seulement « Où ce fait a-t-il théoriquement sa place ? » et que je commence à demander « Comment ce système va-t-il réellement être utilisé ? »
Cela ne veut pas dire que chaque plainte sur un clic de trop aplatit le modèle. Cela veut dire que la facilité d’utilisation est un critère d’architecture légitime.
Parfois, les rapports l’emportent
Section intitulée « Parfois, les rapports l’emportent »Les rapports sont une autre raison courante.
Chaque partenaire distributeur veut un tableau de bord : les livraisons à l’heure par région, par mois. Dans le modèle propre, une livraison connaît son centre de distribution, et le centre connaît sa région. Techniquement, nous pouvons naviguer jusque-là.
Mais l’outil de rapports le peut-il ? Les gens qui construisent leurs propres rapports le peuvent-ils ? Peuvent-ils répondre à la question sans une architecture de rapports plus compliquée que la question elle-même ?
C’est là que je pourrais copier ou dériver la région sur la livraison, plus près de l’endroit où elle est consommée.
J’ai introduit de la duplication. Il me faut donc une autre question : à qui appartient la vérité ?
Si la valeur source change, qu’arrive-t-il à ma copie ? Doit-elle changer ? Ou doit-elle garder ce qui était vrai au moment de la livraison ? Ce sont des exigences différentes.
La dénormalisation ne supprime pas la complexité.
Elle la déplace.
Référence ou liste de sélection ?
Section intitulée « Référence ou liste de sélection ? »Voici un exemple plus modeste que les administrateurs Salesforce rencontrent tout le temps. L’utilisateur doit choisir dans un ensemble de valeurs. Est-ce que je crée une autre entité et je m’y relie, ou est-ce que j’utilise une liste de sélection ?
Prenez le statut d’une livraison : planifiée, chargée, en cours de livraison, arrivée, livrée, installée, exception, retournée. Une liste d’étiquettes courte et stable. Une liste de sélection est exactement ce que je veux.
Prenez maintenant le type d’arrêt : livraison seule, livraison avec installation, livraison avec enlèvement. Celui-là porte ses propres informations : la durée de l’arrêt, les compétences nécessaires à l’équipe, la liste de contrôle d’installation qui s’applique. Il change indépendamment, et c’est le métier qui le gère. C’est une entité, pas une étiquette.
Si je crée un objet pour chaque concept qui pourrait théoriquement être normalisé, je peux construire un système techniquement magnifique que personne n’aime utiliser. Si je transforme chaque concept en liste de sélection parce que c’est facile, je peux m’enfermer dans un coin très vite.
Alors je demande : a-t-il ses propres informations ? Des relations ? Change-t-il indépendamment ? Doit-il être géré comme des données ? Le métier pourrait-il finir par en attendre plus qu’une étiquette ?
Voici les questions que je pose réellement en séance de conception.
Y a-t-il plus d’une colonne d’information ? Si la valeur a besoin d’une description, d’une durée, d’une liste de compétences, d’un propriétaire, ce n’est plus une étiquette.
Combien de valeurs ? Ma règle empirique est d’environ 20. Au-delà de 20 valeurs, une liste de sélection commence à craquer, et il est temps de penser à un objet. Les États américains, à cinquante, sont l’exception avec laquelle on vit, et les pays sont pires ; franchement, est-ce que quelqu’un aime les listes de sélection de pays ? Je les trouve agaçantes.
Les valeurs sont-elles créées au fil du temps, et par qui ? Ajouter une valeur de liste de sélection est un changement de configuration, donc il faut un administrateur. Si le métier ajoute des valeurs chaque semaine, et que ceux qui les ajoutent ne sont pas administrateurs, une liste de sélection impose un billet à chaque nouvelle valeur.
Les gens doivent-ils filtrer et faire des rapports dessus ? Les listes de sélection sont excellentes pour ça. Les relations de référence sont moins propres. Chaque référence ajoute un saut : un type de rapport ne suit qu’une courte chaîne d’objets liés (un type de rapport personnalisé autorise au plus quatre relations d’objet), l’écran devient des listes associées dans des listes associées, et le code se complique.
Une liste de valeurs commence souvent sa vie comme liste de sélection et, avec le temps, gagne le droit de devenir un objet à part entière. Laissez-la le gagner.
Parfois, le volume change la réponse
Section intitulée « Parfois, le volume change la réponse »Une conception qui fonctionne parfaitement avec quelques milliers d’enregistrements peut se comporter très différemment avec des millions.
Alors ne regardez pas seulement le schéma. Connaissez les chiffres.
Steve Trucking fait environ un million de livraisons par an, avec 30 % de croissance annuelle. Chaque livraison accumule environ huit mises à jour de statut. Cela fait huit millions d’enregistrements de statut cette année, et environ 13,5 millions par an à la troisième année. Ajoutez quatre ou cinq millions de photos par an.
Même modèle. Architecture très différente.
Nous irons beaucoup plus loin dans Concevoir pour le volume. Pour l’instant, retenez : le volume peut changer une décision de modélisation. Une relation logiquement correcte n’est pas automatiquement la meilleure conception physique à toutes les échelles.
Des consommateurs différents veulent des formes différentes
Section intitulée « Des consommateurs différents veulent des formes différentes »Jusqu’ici, nous avons pensé au système opérationnel. Les coordinateurs planifient les livraisons. Les équipes clôturent les arrêts. Le système change au rythme de l’activité.
Mais le métier veut aussi analyser des années d’historique. Quels partenaires et quelles régions sont en retard ? Comment le temps de livraison a-t-il évolué ? À quelle fréquence les installations exigent-elles une deuxième visite ?
Un système analytique peut vouloir les mêmes informations organisées autrement. Vous entendrez des termes comme entrepôt de données, fait, dimension et schéma en étoile. Nous ne les détaillons pas ici ; chez Steve Trucking, c’est l’entrepôt Snowflake, et nous y reviendrons plus tard dans le cours.
Pour l’instant : des consommateurs différents peuvent avoir besoin de formes différentes de la même vérité.
L’IA ajoute un autre consommateur
Section intitulée « L’IA ajoute un autre consommateur »Et il y a maintenant un autre consommateur : l’IA.
Un destinataire envoie un SMS : « Où est ma livraison ? » Un assistant d’IA pourrait trouver ceci :
Livraison 10427, tournée 3312, arrêt 7, camion 117, créneau 13 h 00 – 15 h 00.
Une application traditionnelle suit très bien ces relations. Mais pour répondre au destinataire, l’assistant a besoin d’un contexte assemblé à partir de plusieurs endroits :
Votre lave-vaisselle Redrock est le septième arrêt de la tournée d’aujourd’hui au départ du centre de distribution de Phoenix. Le camion est à trois arrêts de chez vous, et vous êtes toujours dans votre créneau de 13 h à 15 h.
Nous avons pris des informations de plusieurs entités liées et assemblé une représentation plus plate et riche en contexte pour un consommateur particulier.
Cela ne veut pas dire que je détruis mon modèle normalisé. Et cela ne veut certainement pas dire « l’IA aime les données plates, alors mettez tout dans un objet géant ». Ne faites pas ça.
La source de vérité reste propre. L’IA reçoit une représentation construite pour le travail qu’elle fait. C’est la même idée que nous venons de voir avec l’analyse :
Une seule source de vérité peut alimenter plusieurs formes de consommation.
Nous irons beaucoup plus loin dans l’ancrage (grounding) et la récupération plus tard dans le cours.
Ne créez pas plusieurs vérités
Section intitulée « Ne créez pas plusieurs vérités »Il y a un danger ici.
Si je copie la région sur la livraison pour les rapports, envoie une version aplatie à Snowflake, et construis une version riche en contexte pour l’assistant d’IA, laquelle est correcte ?
Cette question a besoin d’une réponse. Je veux savoir où se trouve la valeur qui fait foi. Tout le reste est une représentation de cette vérité dans un but précis.
Cet endroit est le système d’enregistrement (system of record). Les copies dénormalisées peuvent être bonnes : l’écran d’arrêt, le tableau de bord, Snowflake et le contexte de l’IA font chacun mieux leur travail avec une forme construite pour eux, et s’y référer ne pose pas de problème. Mais quand quelque chose change, le changement part du système d’enregistrement, généralement le modèle relationnel, et se propage vers chaque copie. Personne ne corrige la région dans Snowflake, ni ne modifie le contexte de l’IA à la main. Corrigez à la source, et laissez le changement se propager.
Et c’est quand les données changent que cela compte le plus. Si un centre de distribution passe aujourd’hui dans une autre région, les livraisons du mois dernier doivent-elles afficher la nouvelle région ? Peut-être. Peut-être pas. Pour l’historique, j’ai peut-être besoin de la région qui était vraie au moment de la livraison. Ce n’est plus un problème de synchronisation. C’est une décision métier.
C’est pourquoi la dénormalisation ne devrait jamais arriver par accident. Chaque fait dupliqué soulève des questions de propriété, de synchronisation, d’historique et de confiance. C’est le raisonnement par compromis du chapitre 1 : sachez ce que vous achetez (un écran plus simple, un rapport plus simple, un meilleur contexte pour l’IA) et ce que vous payez (des données dupliquées, de la synchronisation, une propriété de la vérité plus compliquée). Et comme nous sommes partis d’un modèle logique propre, nous pouvons montrer chaque copie et dire : « Je sais que ceci a sa place là-bas. J’en mets une représentation ici à cause de cette exigence. » C’est une décision que nous pouvons revoir, remettre en cause et écrire, pour que l’architecte suivant sache pourquoi.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »Quand j’envisage une dénormalisation, je décide :
- Où se trouve la source qui fait foi pour chaque fait métier.
- Si le modèle propre crée de vrais problèmes pour les utilisateurs, les rapports, le volume ou la performance.
- Si une représentation plus simple vaut la duplication, et comment la copie reste digne de confiance.
- Si les valeurs historiques doivent changer quand la source actuelle change.
- Si l’analyse ou l’IA a besoin d’une autre forme des données que le système opérationnel.
Le point de départ ne change jamais : savoir où la vérité a sa place. Puis, quand les exigences le justifient, lui donner une forme pour la livraison.
Ensuite, Salesforce revient dans le tableau. Nous allons transformer ce que nous avons conçu en modèle de données physique.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 juin 2019 (en anglais, consulté le 2026-10-12) : un type de rapport personnalisé « peut couvrir jusqu’à 4 relations d’objets ».
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 janvier 2026 (en anglais, consulté le 2026-10-12) : « L’AKC reconnaît 205 races, dont ces trois nouvelles venues. »
- Pour le plaisir : la nomenclature des races de la FCI (opens in a new tab), Fédération Cynologique Internationale (consulté le 2026-10-12) : la liste des races de la fédération internationale, en dix groupes. Parcourez-la et vous verrez pourquoi la Race a mérité sa propre table.