L'architecture de données Salesforce

🌐 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)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Guide d’étude du chapitre 3 du cours Data Architect. Lisez d’abord les dix modules ; cette page vous aide à vérifier ce que vous en avez retenu.

À propos de ce guide d’étude. Il est construit uniquement à partir du contenu de ce cours et de la liste des objectifs publiée dans le guide d’examen de Salesforce. Il ne s’appuie jamais sur de vraies questions d’examen et ne prétend pas savoir ce que contient l’examen. Si vous avez passé l’examen, merci de ne pas m’en envoyer les questions : l’accord de certification interdit de les partager, et apprendre des réponses par cœur n’est de toute façon pas la bonne manière de devenir architecte.

C’est le chapitre où le modèle rencontre la plateforme, et il porte une grande partie de l’examen. Il alimente les deux plus grosses sections, Data Modeling and Database Design et Salesforce Data Management, chacune un quart de l’examen. Les chiffres de la plateforme changent : la liste donne ceux que citent les modules, avec la date de vérification. Apprenez à quoi sert chaque limite, et vérifiez le chiffre actuel avant de vous y fier.

Pour l’examen

Cochez-les au fur et à mesure. Chacun renvoie à l’endroit où il est enseigné.

DM-1 : concevoir le modèle de données sur la plateforme

• Je sais que Salesforce est une plateforme mutualisée, pilotée par les métadonnées : un objet est une métadonnée, pas une nouvelle table, et chaque objet a ses API dès qu’il existe. (Les métadonnées sont le plan, Votre API est venue avec l’objet)
• Je sais que les limites du gouverneur existent pour qu’un locataire ne puisse pas monopoliser les ressources partagées. (Vous ne pouvez pas monopoliser l’ascenseur)
• Je sais lire les modèles de données standard : la conversion d’une piste en compte, contact et opportunité ; un produit d’opportunité pointe vers une entrée de catalogue de prix (Price Book Entry), qui pointe vers Product2 ; et requête, actif et droit (Entitlement) côté service. (Le modèle Sales, Le modèle Service)
• Je sais ce que décide l’écran Nouvel objet personnalisé (New Custom Object) : un nom d’enregistrement Texte ou à numérotation automatique ; la classification de l’objet (avec le partage, l’API Bulk et l’API Streaming activés, c’est un objet Enterprise Application ; désactivés, un objet Light Application) ; et Autoriser la recherche (Allow Search), désactivé par défaut. (L’écran Nouvel objet personnalisé)
• Je sais lire un nom d’API : les objets et champs standard n’ont ni préfixe ni suffixe ; les objets et champs personnalisés se terminent par __c ; un package géré ajoute son préfixe d’espace de noms (abc__) ; et un champ que vous ajoutez à l’objet d’un package reçoit __c mais jamais le préfixe de l’éditeur. (Préfixes et suffixes)
• Je sais appliquer le test de l’adéquation nette pour un objet standard, et je sais quand le sens ou le poids oriente vers un objet personnalisé. (Le test de l’adéquation nette)
• Je sais à quoi servent l’actif et les comptes personnels, qu’un compte personnel prend environ deux fois le stockage d’un compte professionnel, et qu’une fois les comptes personnels activés, ils ne peuvent pas être désactivés. (L’actif est un bon exemple, Les comptes personnels, Quand la personne est-elle le compte ?)
• Je choisis un type de champ pour le comportement dont j’ai besoin (un numéro de parc n’est pas un nombre), et je sais que la date/heure est stockée en GMT et affichée dans le fuseau horaire de chaque lecteur, donc on la compare avec des plages, pas avec une égalité. (Un nombre n’est pas toujours un nombre, Date, Date/Heure et Heure)
• Je sais que le texte existe en deux sortes : jusqu’à 255 caractères sur l’enregistrement (indexable, utilisable comme unique ou comme ID externe), et le texte long ou enrichi au-delà, sans index, sans filtrage WHERE et sans formules. (La famille Texte)
• Je sais quand utiliser un Name à numérotation automatique, et que ce n’est pas l’ID de l’enregistrement. (Un humain doit-il l’identifier ?)
• Je sais comment un ID externe permet à une intégration de faire un upsert, et de charger des enfants par l’ID externe de leur parent. (Les ID externes)
• Je sais quand une valeur doit être dérivée par une formule, et quand c’est un fait historique qui doit être stocké. (Stocké ou dérivé ?)
• Je connais la différence entre un objet de jonction logique (l’idée de modélisation : un objet qui relie deux autres dans un plusieurs-à-plusieurs, avec ses propres attributs) et un objet de jonction Salesforce (Salesforce Junction Object : un objet personnalisé avec deux relations principal-détails), et je sais que Salesforce entend le second. (Deux parents de large)
• Je connais la relation hiérarchique : une référence spéciale, uniquement sur l’objet Utilisateur, comme le champ standard Responsable (Manager), qui ne peut pas revenir au même utilisateur, directement ou indirectement, et qui n’est pas la hiérarchie des rôles. (Hiérarchique)
• Je connais la différence entre une référence et principal-détails : propriété, partage, parent obligatoire, suppression en cascade, champs de récapitulatif de cumul. (Référence, Principal-détails)
• Je sais qu’on ne peut pas créer de principal-détails sur un objet qui contient déjà des données (créer une référence, la remplir, convertir), qu’on ne peut revenir à une référence que sans cumul sur le principal, et qu’il faut Autoriser le changement de parent pour déplacer un enfant. (L’enfant peut-il changer de parent ?)
• Je connais la forme de la plateforme pour principal-détails : jusqu’à trois niveaux de détail personnalisés de profondeur (une référence peut couper la chaîne n’importe où), et deux parents principal-détails de large. Dans un objet de jonction Salesforce, la relation principal-détails créée en premier est la primaire (propriétaire, apparence, division), la seconde est secondaire, et l’accès exige les deux parents : la plus restrictive l’emporte. (Trois niveaux de profondeur, Deux parents de large)
• Je connais les trois choix d’une référence quand le parent est supprimé : vider le champ (par défaut), bloquer la suppression, ou supprimer en cascade, ce qui est désactivé tant que Salesforce ne l’active pas et contourne le partage. (Référence)
• Je sais qu’une auto-relation doit être une référence, et je connais les deux intégrées : le compte parent du compte et la requête parent de la requête. (Les auto-relations)
• Je sais que le recalcul des cumuls peut prendre du temps, qu’un cumul ne peut pas utiliser une formule avec NOW(), TODAY() ou une référence inter-objets, et qu’il ne faut pas choisir principal-détails juste pour obtenir un cumul : un champ stocké, tenu à jour par un flow ou un déclencheur, est l’alternative. (Les cumuls sont utiles, mais ils ne sont pas gratuits)
• Je connais les limites de relations citées par le module : deux principal-détails par objet ; 40 champs de relation par défaut (50 au maximum) ; 25 cumuls par défaut (40 au maximum). (Les relations ont aussi des limites)

DM-2 : un modèle qui respecte le partage et passe à l’échelle

• Je sais qu’un enfant principal-détails n’a ni propriétaire ni table de partage propres : l’accès suit le principal. (La propriété suit le mouvement)
• Je connais le déséquilibre parent-enfant : la recommandation de Salesforce est de ne pas dépasser environ 10 000 enfants par parent. (La question des 10 000 enfants)
• Je connais le déséquilibre de propriété (un utilisateur possédant plus de 10 000 enregistrements d’un objet) et les recommandations : répartir la propriété, ou garder cet utilisateur hors de la hiérarchie des rôles ou seul au sommet, et hors des groupes publics utilisés par les règles de partage. (La propriété peut devenir un problème de volume)
• Je connais la table de partage : l’objet de partage d’un objet personnalisé est Object__Share ; un objet détail n’en a pas, son accès vient du principal ; et un changement de propriétaire supprime les partages manuels mais garde le partage Apex qui a sa propre raison. (La table de partage)
• Je sais décider à qui appartiennent les enregistrements créés par les intégrations et les agents, selon que la propriété détermine ou non le partage. (À qui appartiennent les enregistrements créés par des systèmes ?)

DM-4 : big objects contre objets standard et personnalisés

• Je connais les trois lieux de vie des données : sur le cœur (sObjects, utilisés tous les jours), référencées (un autre système est la source de vérité : les objets externes de Salesforce Connect, __x, ou des appels personnalisés), et archivées (sur le cœur dans des big objects, __b, ou hors du cœur dans un entrepôt). (Sur le cœur et hors du cœur)
• Je sais que les objets externes font un appel externe à chaque accès, donc la latence et la disponibilité du système source comptent. (Référencées)
• Je connais les big objects : des volumes énormes, interrogés via leur index par correspondance exacte ou par plage, sans interface ni rapports standard, avec seulement les autorisations d’objet et de champ, sans automatisation. (Archivées)
• Je sais que la plupart des enregistrements comptent pour environ 2 Ko de stockage de données quel que soit le nombre de champs, et que les fichiers sont comptés séparément, dans le stockage des fichiers. (Deux colonnes ou deux cents, Fichiers et pièces jointes)

SDM-1 : les licences et les objets que les gens peuvent utiliser

• Je connais les trois licences internes, Sales Cloud, Service Cloud et Platform, et ce que chacune peut utiliser. (Trois licences internes)
• Je sais que les licences font partie du modèle de données : les utilisateurs Salesforce Platform n’ont pas les pistes, les campagnes, les opportunités ni les prévisions, et les utilisateurs Customer Community ne peuvent pas utiliser l’opportunité. (Maintenant, compliquons tout : les licences)
• Je connais les niveaux de licences externes : Customer Community, Customer Community Plus (rapports, tableaux de bord, partage standard), Partner Community (objets commerciaux) ; et que Partner Community ne peut pas être utilisée avec des comptes personnels. (Le stade)
• Je connais les licences par membre et par connexion, et à quelle population chacune convient. (La façon de payer change la conception)
• Je sais que certaines licences de plateforme limitent les utilisateurs à une application de dix objets personnalisés au maximum, et je connais le modèle par type d’enregistrement pour travailler dans cette limite. (Quand la licence façonne le modèle)
• Je sais que la licence Salesforce Integration est destinée aux utilisateurs de système à système, API uniquement. (Les personnes ne sont plus les seuls utilisateurs)
• Je sais que les rapports de SLA ont besoin des droits et jalons, qui exigent des licences Service. (Maintenant, compliquons tout : les licences)

SDM-2 : garder les données cohérentes

• Je sais placer une règle sur le bon barreau de l’échelle de cohérence : type de champ et vocabulaire, obligatoire et unique, règles de validation, règles de doublons, automatisation. (Garder les données cohérentes)
• Je sais qu’une liste de sélection restreinte rejette les valeurs absentes de la liste, même via l’API, et qu’un ensemble de valeurs global partage une liste entre plusieurs champs (jusqu’à 1 000 valeurs). (Premier barreau)
• Je sais qu’une exigence dans une présentation de page ne protège que cet écran, pas les données, et que les règles de validation s’exécutent à chaque enregistrement. (La validation dans l’interface n’est pas une validation des données, Troisième barreau)
• Je sais limiter une règle de validation avec ISNEW() et ISCHANGED(), une autorisation personnalisée ou une date d’entrée en vigueur, en sachant quels enregistrements chaque choix vérifie encore (y compris ceux que je ne contrôle pas, comme un changement de propriétaire par lots ou un cumul). (Le problème des anciens enregistrements)
• Je connais les règles de correspondance et les règles de doublons, les limites citées par le module (cinq règles de doublons actives par objet, trois règles de correspondance chacune), et je sais qu’elles ne résolvent pas l’identité entre systèmes. (Quatrième barreau : les règles de doublons)
• Je sais que les règles de doublons ne comparent pas entre eux les enregistrements sauvegardés au même moment, que les enregistrements via l’API et l’importation sont bloqués sans alerte, et qu’un enregistrement et tout ce qu’il déclenche sont annulés comme une seule transaction. (Quatrième barreau, Tout ou rien)
• Je sais que les règles de workflow et Process Builder ne sont plus pris en charge ; l’automatisation, c’est Flow ou Apex. (Cinquième barreau : l’automatisation)

Au-delà de l’examen

L’examen est le plancher, pas le plafond. Voici les habitudes de ce chapitre dont un architecte a besoin, qu’une question les aborde ou non.

• La plateforme a une forme. Concevez pour la plateforme sur laquelle vous êtes, pas pour une base de données générique.
• Regardez le vaisseau mère. Voyez comment Salesforce modélise un concept avant d’en inventer un.
• Chaque objet est un engagement : stockage, limites, modèle de partage, licences et dépendances.
• Demandez où vivent les données avant de choisir un objet : sur le cœur, référencées ou archivées.
• Lisez n’importe quel nom d’API et vous savez qui l’a créé, et ce que vous pouvez modifier.
• Si vous n’archivez pas aujourd’hui, allez-vous un jour archiver ?
• Faites un prototype de big object avant de le proposer.
• Des noms métier différents ne veulent pas automatiquement dire des objets différents.
• Demandez quelles identités ont besoin des données : personnes, clients, partenaires, intégrations et agents.
• Chaque champ reçoit une description, et une classification là où elle compte.
• Décrivez d’abord le comportement de la relation ; la configuration le met en œuvre. Ne déformez pas le modèle pour obtenir une fonctionnalité.
• La question de la suppression : que doit-il arriver aux enfants si quelqu’un supprime le parent ?
• Choisissez quel lien coupe la chaîne : mettez la référence là où l’enfant a vraiment sa propre vie.
• La propriété vient du primaire, l’accès des deux : le plus restrictif l’emporte.
• Séparez inactif de disparu, et faites de la conservation une règle métier.
• Placez la règle aussi bas qu’elle a correctement sa place, et donnez une dérogation à l’historique légitime au lieu de le réécrire.
• Le schéma n’est pas l’architecture. Soyez capable de faire remonter chaque structure à une raison métier.

Les mots à connaître

Terme	En une ligne
Piloté par les métadonnées	Les objets et les champs sont des définitions que la plateforme lit à l’exécution, pas de nouvelles tables physiques
Mutualisation	De nombreuses organisations partagent l’infrastructure, chacune isolée, comme des appartements dans un même immeuble
Limites du gouverneur	Des limites qui empêchent un locataire de monopoliser les ressources partagées
Objet externe	Des données affichées dans Salesforce via Salesforce Connect, récupérées à la source à chaque accès
Big object	Un stockage pour des données très volumineuses et rarement utilisées, interrogées via leur index
Compte personnel	Un individu représenté comme un compte, pour les modèles B2C
Adéquation nette	Un concept métier qui correspond à la finalité prévue d’un objet standard
ID externe	Un champ qui contient l’identifiant d’un autre système, utilisé pour les upserts et les correspondances
Upsert	Mettre à jour l’enregistrement s’il existe, le créer sinon
Référence (lookup)	Une relation où l’enfant garde son propre propriétaire et sa propre vie
Principal-détails	Une relation où l’enfant appartient au parent : propriétaire et partage hérités, suppression en cascade, cumuls
Objet de jonction logique	L’idée de modélisation : un objet qui relie deux autres dans un plusieurs-à-plusieurs et porte ses propres attributs, quelle que soit sa construction
Objet de jonction Salesforce (Salesforce Junction Object)	Ce que Salesforce entend par « objet de jonction » : un objet personnalisé avec deux relations principal-détails
Principal primaire et secondaire	La relation principal-détails créée en premier dans un objet de jonction Salesforce (propriétaire, apparence, division) et la seconde (périmètre des rapports ; devient primaire si la première est supprimée)
Relation hiérarchique	Une référence spéciale, uniquement sur l’objet Utilisateur, comme Responsable (Manager), qui ne peut pas revenir au même utilisateur
Préfixe d’espace de noms	Le préfixe de l’éditeur sur les objets et champs d’un package géré, comme abc__Inspection__c
Table de partage	L’objet de partage (AccountShare, Truck__Share) qui contient l’essentiel du partage d’un enregistrement, une ligne par utilisateur ou groupe, avec sa raison
Récapitulatif de cumul	Un champ sur le principal qui compte, additionne, ou trouve le minimum ou le maximum de ses détails
Déséquilibre de données (skew)	Trop d’enregistrements sous un même parent ou un même propriétaire, causant des verrous et de longs recalculs de partage
Par membre / par connexion	Payer par utilisateur externe, ou par connexion chaque mois
Échelle de cohérence	Les couches qui appliquent les règles de données, du type de champ à l’automatisation
Liste de sélection restreinte	Une liste de sélection qui rejette toute valeur absente de sa liste, quelle qu’en soit la source
Classification des données	Des métadonnées de champ sur le propriétaire, l’utilisation, la sensibilité et la catégorie de conformité

Testez-vous

De courts scénarios dans le style du cours. Décidez de votre réponse avant de l’ouvrir.

1. Les utilisateurs doivent voir le détail des commandes que l'ERP possède et met à jour toute la journée. Ils ne les modifient pas dans Salesforce. Les copier, ou non ?

Les référencer : les objets externes via Salesforce Connect gardent l’ERP comme source de vérité, sans copie à synchroniser. Acceptez que chaque affichage fasse un appel externe, donc la latence et la disponibilité de l’ERP comptent, et que cela convient mieux à la lecture qu’à beaucoup de modifications ou de rapports. Relisez Référencées.

2. Le métier veut suivre des distributeurs, des fournisseurs et des partenaires distributeurs. Trois objets personnalisés ?

Non. Ce sont toutes des entreprises, donc le compte est une adéquation nette ; les noms différents sont des rôles, portés par un type, un type d’enregistrement ou une relation. Relisez Le test de l’adéquation nette.

3. Une conception utilise l'opportunité, mais la plupart des gens qui ont besoin des données ont des licences Salesforce Platform ou Customer Community. Et maintenant ?

Ces licences ne peuvent pas utiliser l’opportunité, donc la licence est une contrainte d’architecture : acheter d’autres licences, déplacer l’expérience, ou reconcevoir, généralement vers un objet personnalisé. Relisez Maintenant, compliquons tout : les licences.

4. L'ERP envoie chaque nuit des mises à jour de comptes. Comment l'intégration doit-elle trouver le bon enregistrement sans chercher les ID Salesforce ?

Stockez le numéro client de l’ERP dans un champ ID externe et faites un upsert dessus : mise à jour si trouvé, création sinon. Les enregistrements enfants peuvent aussi désigner leur parent par son ID externe. Relisez Les ID externes.

5. Un article de livraison ne peut pas exister sans sa livraison, ne bouge jamais et n'a pas besoin de propriétaire propre. Une livraison existe avant d'être planifiée et peut passer dans une autre tournée. Quelle relation pour chacun ?

Article de livraison vers livraison : principal-détails (il appartient au parent pour la vie, hérite de l’accès, suppression en cascade). Livraison vers tournée : une référence (sa propre vie, facultative au départ, déplaçable, et supprimer une tournée ne doit jamais supprimer de livraisons). Relisez Commencez par la relation métier.

6. Une intégration crée 3 300 livraisons par jour, toutes possédées par l'utilisateur d'intégration, qui a un rôle au milieu de la hiérarchie. Quel est le risque, et la correction ?

Le déséquilibre de propriété : au-delà de 10 000 enregistrements, déplacer cet utilisateur ou changer ses groupes déclenche de longs recalculs de partage. Répartissez la propriété si elle compte pour l’accès ; sinon, gardez l’utilisateur d’intégration hors de la hiérarchie des rôles, ou seul dans un rôle au sommet, et hors des groupes utilisés par les règles de partage. Relisez La propriété peut devenir un problème de volume.

7. Vous ajoutez une règle de validation, et 20 000 anciens enregistrements l'enfreignent. Un utilisateur modifie un numéro de téléphone sur l'un d'eux et l'enregistrement échoue. Qu'aurait dû faire la règle ?

Dire quand s’appliquer, pas seulement ce qui doit être vrai : la limiter avec ISNEW() ou ISCHANGED() sur les champs concernés, et donner aux enregistrements antérieurs à la règle une dérogation délibérée plutôt que réécrire leur historique. Relisez Le problème des anciens enregistrements.

8. Le métier veut chaque photo de livraison « dans Salesforce » : quatre à cinq millions par an, en hausse de 30 %. Que proposez-vous ?

Séparer l’accès du stockage. Gardez les fichiers dans un stockage conçu pour ce volume, hors de l’organisation principale, et gardez une référence, un nombre ou un enregistrement d’index dans Salesforce pour que les utilisateurs puissent les trouver et les voir. Relisez Photos.

9. Une affectation d'équipe (Crew Assignment) a des relations principal-détails vers l'équipe (créée en premier) et vers le camion. Un répartiteur peut voir l'équipe mais pas le camion. Peut-il voir l'affectation d'équipe ?

Non. L’équipe est le principal primaire, donc elle donne à l’affectation son propriétaire et son apparence, mais l’accès exige les deux parents : le répartiteur a besoin d’accéder à l’équipe et au camion, au niveau que demande le paramètre de partage (Sharing Setting) de chaque champ principal-détails. Le plus restrictif l’emporte. Relisez Deux parents de large.

10. Un partenaire renvoie un fichier de manifeste, et le même client y apparaît deux fois. Vous avez une règle de doublons sur le compte configurée pour bloquer. Êtes-vous protégé ?

Pas par la seule règle de doublons. Les enregistrements sauvegardés au même moment ne sont pas comparés entre eux, seulement avec les enregistrements déjà présents dans Salesforce, donc les deux lignes peuvent passer. Descendez l’unicité jusqu’au champ : un ID externe unique, que la plateforme vérifie à chaque enregistrement, pour qu’un seul l’emporte. Relisez Quatrième barreau : les règles de doublons et Tout ou rien.

Pour aller plus loin

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-09-25) : la liste officielle des objectifs et de leurs pondérations. Vérifiez toujours la version actuelle avant de réserver l’examen.
• La section Pour aller plus loin de chaque module liste la documentation Salesforce derrière ses faits sur la plateforme, avec la date de vérification.