Le modèle de données est l'ossature
Aussi en 28 langues
English · Español · 日本語 · Português (Brasil) · 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) · Français (Canada) · Deutsch (Schweiz)
Module 2 sur 7 du chapitre Penser comme un architecte de données, le premier chapitre du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Penser comme un architecte · Suivant : Le test de réversibilité
La question à laquelle répond ce module : pourquoi le modèle de données compte-t-il plus que tout ce qui est construit dessus, et comment le juger ?
Quand j’enseigne l’architecture de données, il y a une phrase à laquelle je reviens sans cesse : le modèle de données est l’ossature.
Le modèle de données est l’ossature du système. Tout le reste est construit autour, et c’est lui qui tient l’ensemble du corps. On ne voit pas les os quand on regarde quelqu’un, mais ils décident de sa taille, de sa façon de bouger et de ce qu’il peut porter.
Pensez à tout ce que nous construisons dans une mise en œuvre Salesforce. Nous construisons de l’automatisation autour du modèle de données. Nous écrivons de l’Apex dessus, et des flows qui le lisent et le mettent à jour. Nous construisons des intégrations qui y envoient des données et en extraient. Nous créons des rapports et des analyses dessus, et nous concevons la sécurité autour. Et de plus en plus, nous construisons des agents d’IA qui doivent comprendre ces données et agir dessus. Tout cela dépend de la structure en dessous.
C’est pourquoi il est si important d’avoir le bon modèle de données tôt. On peut changer l’ossature plus tard. Mais ça va probablement faire mal.
Commencez par le métier
Section intitulée « Commencez par le métier »Un bon modèle de données commence par une question simple : que doit réellement représenter le métier ? Pas « quels objets Salesforce avons-nous ? ». Et surtout pas « qu’est-ce que je peux construire vite ? ».
Nous essayons d’abord de comprendre le métier. Quelles sont les choses importantes dans cette activité ? Comment sont-elles liées ? À qui appartiennent-elles ? Comment évoluent-elles dans le temps ? Que faut-il mémoriser, et qu’est-ce qui est partagé entre les processus métier ? Ce n’est qu’après avoir compris cela que nous devrions commencer à les traduire en objets, champs et relations.
Cela paraît évident. En pratique, il est très facile de faire l’inverse. Quelqu’un reconnaît quelque chose qui ressemble à une opportunité, une requête ou un actif, et commence aussitôt à concevoir autour. Parfois, c’est exactement juste. Parfois, on essaie de faire entrer une cheville carrée dans un trou rond, et une fois qu’assez de choses ont été construites autour de cette décision, retirer la cheville devient très coûteux.
Voici une question que j’entends tout le temps. L’activité d’un client peut avoir de nombreux lieux de livraison. Chaque lieu doit-il être un compte, ou un objet personnalisé ? Avant de répondre, remarquez ce que vous auriez besoin de savoir d’abord : ce qu’un lieu signifie pour cette activité, et ce qui lui arrive. C’est modéliser le métier avant les objets. (Je vous donnerai ma réponse au chapitre 3.)
Soutenir. Grandir. Performer.
Section intitulée « Soutenir. Grandir. Performer. »Quand je regarde un modèle de données, je veux qu’il passe trois tests : soutenir le métier, grandir avec le métier, et performer.
Soutenir. Le modèle doit soutenir ce que le métier essaie réellement d’accomplir. Il y a une grande différence entre un modèle capable techniquement de stocker les données et un modèle qui représente bien le métier. Si j’ajoute constamment des champs étranges, des indicateurs spéciaux, de l’automatisation compliquée et des exceptions parce que le modèle ne colle pas tout à fait, je commence à me demander si le problème est vraiment l’automatisation. Le modèle est peut-être faux. Un bon modèle devrait rendre le métier plus facile à comprendre, pas plus difficile.
Grandir. Quand je dis grandir, je ne parle pas seulement de plus d’enregistrements. Le volume compte : dix mille enregistrements et cent millions posent des problèmes très différents. Mais les entreprises grandissent aussi en complexité. Elles ajoutent des produits, entrent sur de nouveaux marchés, rachètent des sociétés, changent leurs processus, ajoutent des canaux et connectent de nouveaux systèmes. Elles découvrent que ce qu’elles croyaient être une seule chose en est en réalité cinq. Un modèle qui fonctionne parfaitement aujourd’hui peut devenir un piège s’il n’y a pas de place pour demain. C’est pourquoi je préfère les conceptions qui grandissent par ajout plutôt que celles qui modifient sans cesse l’existant. Ajouter quelque chose de nouveau est généralement plus facile que redéfinir quelque chose dont des dizaines d’autres choses dépendent.
Performer. Les données ne restent pas là sans rien faire. Nous les écrivons, les cherchons, les interrogeons, les partageons, en faisons des rapports, les intégrons, et de plus en plus, des systèmes d’IA les récupèrent comme contexte avant d’agir. Un modèle peut être magnifique sur un schéma et pourtant pénible à exploiter. Nous concevons donc à la fois pour la façon dont les données sont stockées et la façon dont elles seront utilisées.
Et il doit continuer à performer. Il doit performer à grande échelle : quand le nombre d’utilisateurs augmente, quand le volume de données augmente, dans les conditions réelles et aux pics, le jour le plus chargé de l’année plutôt qu’un jour moyen. Et il doit continuer à performer quand quelque chose d’inattendu se produit.
Soutenir. Grandir. Performer. Nous reviendrons sans cesse à ces trois tests tout au long de ce cours.
Trop plat, trop compliqué, ou simplement faux
Section intitulée « Trop plat, trop compliqué, ou simplement faux »J’ai vu des modèles de données mal tourner de trois façons.
La première consiste à choisir la mauvaise chose dès le départ. On utilise un objet standard parce qu’il a l’air assez proche, puis on passe des années à ajouter des exceptions parce qu’il n’a jamais vraiment convenu. C’est la cheville carrée.
La deuxième consiste à faire un modèle trop plat. Tout va dans un seul objet, et au début cela paraît merveilleusement simple. Puis le métier grandit, et on découvre que certaines de ces choses ont leur propre cycle de vie, peuvent exister en plusieurs exemplaires, ont besoin de leur propre sécurité ou ont leurs propres relations. Soudain, on représente une relation un-à-plusieurs avec Champ 1, Champ 2 et Champ 3, ou avec des indicateurs et une automatisation de plus en plus compliqués. Le modèle ne nous a laissé aucune place pour grandir.
La troisième est l’erreur inverse : on sur-normalise. On crée un schéma élégant avec objet après objet, chaque concept parfaitement séparé. Techniquement magnifique, pratiquement misérable. Les utilisateurs ont du mal à le comprendre, et les présentations de page et pages Lightning, avec liste associée après liste associée, peuvent sembler d’une profondeur infinie. Les requêtes se compliquent, l’automatisation traverse plus de relations, les rapports deviennent plus difficiles, et la plateforme travaille davantage pour répondre à des questions métier ordinaires.
Alors, lequel est correct, plat ou normalisé ? Il n’y a pas de formule. Vous gardez en tête l’image du modèle optimal et vous comprenez les compromis à mesure que vous vous en éloignez. C’est l’art de l’architecture, et nous y reviendrons au module 4 et au chapitre suivant, où nous apprenons à modéliser. Pour l’instant, retenez que la structure elle-même est une décision d’architecture.
Prudence avant de changer l’ossature
Section intitulée « Prudence avant de changer l’ossature »Une fois qu’un système est en service, je deviens très prudent avant tout changement fondamental du modèle de données.
Supposons qu’un champ texte existe depuis des années, et que quelqu’un dise : « On ne l’utilise plus vraiment comme ça. Passons-le en nombre. » Cela ressemble à une modification de champ. Mais qu’est-ce qui dépend de ce champ ? Des flows, de l’Apex, des rapports, des intégrations, des pipelines de données, des applications externes, des agents d’IA. Et qu’arrive-t-il aux données historiques ? La plateforme elle-même ne vous laisse pas changer le type d’un champ tant que du code ou des flows y font encore référence, ce qui vous montre jusqu’où va le changement.
Parfois, la bonne réponse n’est pas de modifier l’existant. Selon la gravité du changement, je préfère créer quelque chose de nouveau, migrer délibérément, et rendre obsolète l’ancienne structure :
Ajoutez plutôt que modifier. Dépréciez plutôt que surprendre.
Salesforce vous donne même un moyen de le dire dans les métadonnées : l’utilisation du champ (Field Usage) d’un champ peut être définie sur DeprecateCandidate, « dont l’abandon est prévu et qui n’est plus utilisé ». Cela signale le champ à tous ceux qui lisent l’objet ; cela ne le masque pas, donc le retirer reste une décision que vous devez mener à bien.
Car une fois que d’autres parties de l’architecture dépendent de quelque chose, changer son sens peut être bien plus dangereux que changer son nom. La pire version, c’est le champ dont le nom reste le même alors que son contenu change : tout ce qui est en aval fait encore confiance au nom.
Même quelque chose d’aussi simple que cocher la case Obligatoire d’un champ peut devenir une bombe à retardement. Si vous avez déjà collecté des données, certains enregistrements n’auront pas ce champ renseigné. Puis, des jours, des semaines ou des mois plus tard, quelqu’un met à jour l’un de ces enregistrements, et l’enregistrement échoue à cause du champ obligatoire, et personne ne connaît la valeur. Un changement aussi simple que rendre un champ obligatoire peut avoir des conséquences imprévues et différées. Nous reviendrons sur l’obligatoire, et sur le moment où une valeur est réellement connue, au chapitre 3.
Au-delà de l’examen : l’IA construit aussi sur l’ossature. Demandez à un outil d’IA de construire une application et il générera les objets, les champs, les flows, l’Apex, les composants et les tests en quelques minutes. Si le modèle de données d’origine était faux, nous n’avons pas évité les conséquences d’une mauvaise décision ; nous les avons accélérées, car chaque couche générée est une chose de plus qui dépend de cette structure. C’est pourquoi je veux qu’un architecte humain revoie un modèle de données généré par l’IA, le comprenne et en soit responsable. Le module 7 va plus loin.
L’ossature d’abord
Section intitulée « L’ossature d’abord »Tout au long de ce cours, nous parlerons de beaucoup de technologie : objets et relations, gros volumes de données, requêtes, intégration, migration, transactions, sécurité, Data 360 et IA. En dessous de tout cela, il y a le modèle de données.
Si le modèle soutient le métier, peut grandir avec lui et performe pour les usages que nous ferons des données, nous avons construit de solides fondations. Si nous nous trompons sur les fondations, tout ce qui suit devient plus difficile.
Le modèle de données est l’ossature. Les architectes doivent être très prudents lorsqu’ils conçoivent l’ossature. Modifier des structures existantes peut avoir des conséquences en cascade.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- Si le modèle soutient le métier, peut grandir avec lui et performe pour les usages qui seront faits des données.
- Si un concept convient à un objet standard ou s’il s’agit d’une cheville carrée.
- À quel point rendre le modèle plat ou normalisé, et pourquoi.
- Si un changement de l’ossature doit être un ajout, une migration ou une dépréciation, plutôt qu’une modification sur place.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-02 ; revérifié le 2026-10-12) : quels changements de type peuvent faire perdre des données, et pourquoi on ne peut pas changer le type d’un champ référencé par de l’Apex, des flows ou des processus.
- Data Classification Metadata Fields (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-02 ; revérifié le 2026-10-12) : les valeurs de Field Usage (Active, DeprecateCandidate, Hidden) et les autres champs de classification.