Les modèles de données standard
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 2 sur 10 du chapitre L’architecture de données Salesforce, chapitre 3 du cours Data Architect. Chaque module se suffit à lui-même. Précédent : La plateforme de données Salesforce : plus qu’une base de données · Suivant : Construisez le vôtre : les objets personnalisés
La question à laquelle répond ce module : qu’est-ce que Salesforce a déjà modélisé pour vous, et comment est-ce assemblé ?
Au module 1, je vous ai dit de regarder le vaisseau mère : avant d’inventer quelque chose, regardez comment Salesforce lui-même le fait. C’est dans ce module que nous regardons vraiment. Salesforce a déjà modélisé une bonne partie de votre activité, dans ses objets standard, et deux de ces modèles font l’essentiel du travail dans la plupart des organisations où j’arrive : le modèle Sales et le modèle Service. Avant de pouvoir décider si quelque chose mérite un objet personnalisé, il faut savoir ce qui existe déjà. C’est l’objet des deux prochains modules.
Ce qui fait un objet standard
Section intitulée « Ce qui fait un objet standard »Un objet standard est fourni d’emblée. C’est Salesforce qui l’a construit, il a une finalité définie, et il vient avec ses propres champs et relations. Vous pouvez lui ajouter des champs, construire de l’automatisation autour et changer ses présentations, mais vous ne pouvez pas le reconcevoir : les champs et relations standard appartiennent à Salesforce.
Regardez les noms. Account, Contact, Case. Ni préfixe, ni suffixe. C’est Salesforce qui se réserve cet espace. Tout ce que nous construisons se termine par __c, si bien que Salesforce peut ajouter de nouveaux objets standard à tout moment sans jamais entrer en collision avec quoi que ce soit dans votre organisation. Et il le fait, à chaque version.
À un moment donné, quelqu’un a construit un objet produit qui n’a pas marché et a dû être laissé de côté. C’est pourquoi le nom d’API est Product2. C’est mon premier test décisif quand quelqu’un me dit qu’il connaît Salesforce.
Le modèle Sales
Section intitulée « Le modèle Sales »Commencez à gauche, avec la piste (Lead) : quelqu’un qui pourrait devenir client. Une piste ne fait pas encore vraiment partie du modèle. C’est une zone d’attente. Quand vous la convertissez, Salesforce crée les vrais enregistrements : un compte, un contact et, s’il y a une affaire, une opportunité. C’est pourquoi je dessine la piste à l’écart.
Le compte est l’entreprise. Ses contacts sont les personnes qui y travaillent. Une opportunité est une affaire avec ce compte. Jusqu’ici, rien d’inattendu.
C’est ensuite que ça devient intéressant. Qu’y a-t-il dans l’affaire ? Chaque ligne est un produit d’opportunité (Opportunity Product), et un produit d’opportunité ne pointe pas directement vers un produit. Il pointe vers une entrée de catalogue de prix (Price Book Entry) : ce produit, à ce prix, dans ce catalogue de prix. L’entrée de catalogue de prix se place entre le produit et le catalogue de prix (Price Book), si bien que le même produit peut avoir un prix dans le catalogue de prix standard et un autre dans votre catalogue de prix partenaires.
Ce sont deux relations devenues des choses, l’une après l’autre. Vous vous souvenez de l’article de livraison au chapitre 2, entre la livraison et le produit, et du tour du chien entre le chien et le tour ? Salesforce a fait exactement la même chose ici, deux fois : le produit d’opportunité entre l’opportunité et l’entrée de catalogue de prix, et l’entrée de catalogue de prix entre le produit et le catalogue de prix. Quand vous savez lire cela, vous savez lire l’essentiel du modèle de données standard.
Voici cette chaîne de près, avec les champs qui la tiennent ensemble :
Une règle sur laquelle les gens trébuchent : il existe un catalogue de prix standard, et une entrée de catalogue de prix dans n’importe quel autre catalogue de prix peut simplement utiliser le prix standard du produit. Sachez quel catalogue de prix une opportunité utilise avant de charger ses produits.
Le modèle Service
Section intitulée « Le modèle Service »Passons maintenant à l’autre côté de la maison. Même compte, mêmes contacts. Quand quelque chose ne va pas, le client ouvre une requête (Case).
La requête porte généralement sur quelque chose que le client possède, et Salesforce a un objet pour cela : l’actif (Asset). Au module 5, je l’appellerai l’objet standard que les gens négligent. C’est une chose que le client possède, qu’il vous l’ait achetée ou non.
Et à quoi le client a-t-il droit ? C’est le droit (Entitlement) : l’assistance qu’un compte est en droit de recevoir, souvent liée à un actif, un produit ou un contrat de service. Mettez un droit sur une requête, et la requête sait désormais quel niveau d’assistance elle est censée recevoir.
Regardez le trait qui part de la requête et revient sur elle-même. Chaque requête a un champ Requête parente (Parent Case), qui pointe vers une autre requête. C’est une auto-référence (self-lookup) : une relation d’un objet vers lui-même. Elle déroute beaucoup de gens la première fois qu’ils la voient, alors voici les deux raisons pour lesquelles je l’utilise.
Un : un gros problème qui se décompose en plus petits. Le client signale que toute l’installation est en panne. Nous ouvrons des sous-requêtes pour le réseau, le matériel et la configuration, chacune traitée de son côté, et elles se résolvent toutes vers le haut : la requête parente n’est pas terminée tant qu’elles ne le sont pas.
Deux : l’historique. Une requête a été clôturée le mois dernier, et voilà que le même problème revient. La nouvelle requête pointe vers l’originale, si bien que quiconque l’ouvre voit que c’est déjà arrivé, et ce qui a été fait.
Nous reviendrons aux auto-références quand nous aborderons les relations au module 7.
Remarquez que le compte et le contact sont au même endroit dans les deux diagrammes. Ce sont les mêmes enregistrements. Un commercial et un agent du service client regardent le même client, depuis deux côtés de la maison. C’est l’un des arguments les plus forts pour rester standard : les modèles ont été construits pour se rejoindre.
Fichiers et pièces jointes
Section intitulée « Fichiers et pièces jointes »Tout ce qui se trouve sur un enregistrement n’est pas un champ. Les contrats, les photos, les PDF et les feuilles de calcul sont des fichiers, et ils ont leur place dans Salesforce Files, pas dans l’ancien modèle des pièces jointes (Attachments), qui est hérité. Si le document vit déjà dans SharePoint Online, OneDrive, Google Drive ou Box, Files Connect permet aux utilisateurs d’y accéder depuis Salesforce sans le copier.
Les fichiers ne sont pas comptés comme les enregistrements. Salesforce divise le stockage en deux : le stockage de fichiers contient les pièces jointes, Files, Salesforce CRM Content, les fichiers Chatter et autres, et le stockage de données contient vos enregistrements. Le stockage de fichiers grimpe vite quand chaque enregistrement reçoit des photos ou des scans, donc les gros volumes d’images, comme les photos d’une application terrain, ont souvent leur place entièrement hors de Salesforce, Salesforce ne gardant qu’un lien. Le module 4 y revient.
Deux colonnes ou deux cents
Section intitulée « Deux colonnes ou deux cents »Le stockage de données n’est pas non plus compté comme dans une base de données. Dans une base de données classique, une table de deux colonnes et d’un million de lignes est petite, et une table de cent colonnes et d’un million de lignes est un éléphant. Salesforce les pèse de la même façon : la plupart des enregistrements comptent pour environ 2 Ko, quel que soit leur nombre de champs. Il y a des exceptions. Une campagne compte davantage, un courriel compte pour sa taille réelle, et un compte personnel compte pour environ 4 Ko, parce que c’est un compte et un contact.
Voici une astuce. Chaque fois que j’arrive dans une nouvelle organisation, l’un des premiers endroits où je vais est Configuration → Utilisation du stockage (Storage Usage). Je demande même une capture d’écran au client dès le premier appel. Cet écran ne ment pas. Il vous dit quels objets grossissent, et lesquels sont déjà les éléphants.
Les comptes personnels : quand le client est une personne
Section intitulée « Les comptes personnels : quand le client est une personne »Le modèle compte et contact fonctionne à merveille pour une entreprise et les personnes qui y travaillent. Mais si votre client n’est pas une entreprise ? S’il s’agit d’une personne ?
C’est le compte personnel (person account) : un compte et un contact réunis en un seul enregistrement, pour les particuliers. Leurs champs de contact suivent, et les champs personnalisés apparaissent avec leur propre suffixe, __pc. Chacun compte à la fois dans le stockage des comptes et dans celui des contacts, parce qu’en dessous, c’est les deux.
Un avertissement avant de les activer : une fois les comptes personnels activés, ils ne peuvent pas être désactivés. C’est le test de réversibilité du chapitre 1 dans sa forme la plus pure. Le module 5 vous donne ma position sur les cas où ils en valent la peine.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- Quelles parties de l’activité Salesforce a déjà modélisées, avant de concevoir quoi que ce soit de nouveau.
- Si un concept relève du modèle Sales, du modèle Service ou des deux, en sachant qu’ils partagent le compte et le contact.
- Où vivent les documents et les images : Salesforce Files, un système de fichiers connecté, ou hors de la plateforme avec un lien.
- Ce que les données coûteront en stockage, compté comme Salesforce le compte : en enregistrements, pas en colonnes.
- Si le client est une entreprise ou une personne, avant d’activer quelque chose qu’on ne peut pas désactiver.
Et quand Salesforce n’a pas ce qu’il vous faut ? Vous le construisez. C’est la suite.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- OpportunityLineItem (opens in a new tab) (en anglais), Object Reference for the Salesforce Platform (consulté le 2026-10-12) : « un membre de la liste des produits Product2 associés à une opportunité » ; l’entrée de catalogue de prix est obligatoire.
- PricebookEntry (opens in a new tab) (en anglais), Object Reference (consulté le 2026-10-12) : « une association entre un Pricebook2 et un Product2 » ; une entrée peut utiliser le prix standard.
- Case (opens in a new tab) (en anglais), Object Reference (consulté le 2026-10-12) : ParentId, « l’ID de la requête parente dans la hiérarchie », libellé Parent Case ; une référence vers Case.
- Entitlement (opens in a new tab) (en anglais), Object Reference (consulté le 2026-10-12) : « l’assistance client qu’un compte ou un contact est en droit de recevoir », éventuellement fondée sur un actif, un produit ou un contrat de service.
- Data and Storage Resources (opens in a new tab) (en anglais), Salesforce Help (consulté le 2026-10-12) : ce que comprennent le stockage de fichiers et le stockage de données.
- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab) (en anglais), Salesforce Help (consulté le 2026-10-12) : « la plupart des enregistrements Salesforce consomment environ 2 Ko de stockage de données » ; les comptes personnels environ 4 Ko.
- Enable Person Accounts (opens in a new tab) (en anglais), Salesforce Help (consulté le 2026-10-12) : « une fois les comptes personnels activés, ils ne peuvent pas être désactivés ».
- Files Connect FAQ (opens in a new tab) (en anglais), Salesforce Help (consulté le 2026-09-25).