Chaque structure est un engagement

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

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

Chapitre 3 du cours Data Architect, Partie 1 : Devenir architecte de données. Précédent : Modéliser les données pour leur sens.

Voici une question que je pose dans chaque cours. Si quelqu’un dit « je travaille avec Salesforce », quel est le nom d’API de l’objet produit ?

C’est Product2. C’est mon premier test décisif. À un moment donné, Salesforce a construit l’objet produit, s’est rendu compte qu’il ne fonctionnait pas, et a dû le laisser derrière lui. Impossible de simplement le retirer, alors ils ont ajouté Product2. Même Salesforce vit avec ses anciennes structures.

Salesforce s’est aussi laissé de la place pour grandir. Ses objets standard n’ont ni préfixe ni suffixe, et nous, qui personnalisons les organisations, ne pouvons jamais occuper cet espace. Salesforce peut donc continuer d’ajouter des objets sans jamais entrer en collision avec ce que nous construisons.

Voici la leçon : créer un objet prend dix minutes. Vivre avec prend des années. Chaque objet et chaque champ que vous ajoutez est un engagement. Il prend du stockage. Il ramasse des limites. Il reçoit un modèle de partage, que vous en ayez conçu un ou non. Il exige une licence pour chaque personne qui le touche. Et maintenant l’IA le lit aussi, donc la façon dont vous le nommez et le décrivez décide de ce qu’un agent comprend de vos données. Ajouter est facile. Retirer est difficile.

Ce chapitre transforme les briques de Salesforce en décisions.

Image générée par IA.

Les structures en un coup d’œil

Salesforce vous donne six endroits où garder des données. Je les mets sur une seule diapositive, car le premier travail est de savoir qu’ils existent tous :

Structure	À quoi elle sert	Le piège
Objets standard	Le modèle propre à Salesforce : compte, contact, opportunité, requête, actif et les autres	Utilisez-les pour ce à quoi ils servent, sinon ils vous résistent
Objets personnalisés	Vos propres données métier	Faciles à créer, difficiles à retirer
Objets externes	Des données qui vivent dans un autre système, affichées dans Salesforce	Chaque accès est un appel externe
Big objects	D’énormes volumes à conserver mais rarement ouverts	Pas d’interface ni de rapports standard ; on interroge via l’index
Fichiers	Documents, photos et autres contenus	Le stockage de fichiers grimpe vite
Pièces jointes	L’ancienne façon de stocker des fichiers	Héritage : utilisez Fichiers

Choisir l’une d’elles n’est pourtant qu’une partie de la décision. Avant la structure vient la question de savoir où les données doivent vivre tout court : sur le cœur, référencées là où elles se trouvent déjà, ou archivées.

Le parcours de ce chapitre

Ce chapitre est gros, il est donc découpé en dix parties. Chacune se suffit à elle-même. Au chapitre 2, nous avons décidé ce que devait être le modèle ; ici, nous décidons comment il doit vivre sur Salesforce.

1. La plateforme de données Salesforce : plus qu’une base de données. Ce qui rend Salesforce différent, et pourquoi la plateforme a une forme.
2. Regardez le vaisseau mère : les modèles de données standard. Les modèles Sales et Service que Salesforce a déjà construits, les fichiers, le stockage et les comptes personnels.
3. Construisez le vôtre : les objets personnalisés. Ce que décide l’écran Nouvel objet personnalisé, les champs que vous n’avez pas créés, et comment lire n’importe quel nom d’API : standard, personnalisé ou package géré.
4. Où vivent ces données ? Sur le cœur, référencées ou archivées : à décider avant de créer le moindre objet.
5. Choisir le bon objet. Le test de l’adéquation nette, les bagages qu’apportent les objets standard, les comptes personnels, et les licences qui décident de ce que les gens peuvent utiliser.
6. Les champs aussi, c’est de l’architecture. Type de champ par type de champ, les comportements qui surprennent, et pourquoi chaque champ reçoit une description.
7. Les relations ont des conséquences. Référence ou principal-détails, trois niveaux de profondeur et deux parents de largeur, l’objet de jonction logique et l’objet de jonction Salesforce (Salesforce Junction Object), et les limites qui font mal.
8. Propriété et cycle de vie. À qui appartient un enregistrement, la table de partage où la propriété devient l’accès, et ce qui arrive à un enregistrement au cours de sa vie.
9. Garder les données cohérentes. L’échelle de la cohérence : chaque couche a un coût, et on ne « corrige » jamais l’historique pour satisfaire une nouvelle règle.
10. Concevoir le modèle physique Salesforce. Une tranche de Steve Trucking, du modèle logique à Salesforce, construite pas à pas, avec le raisonnement.

Quand vous avez terminé, testez-vous avec le guide d’étude du chapitre : une liste de contrôle pour l’examen, les habitudes qui vont au-delà, les mots à connaître et quelques questions.

Ce que l’architecte décide ici

• Ce que Salesforce modélise déjà, avant d’inventer quoi que ce soit : regardez le vaisseau mère.
• Où vit chaque type de données, sur le cœur, référencées ou archivées, avant de choisir une structure.
• Quelle structure les accueille, en sachant à quoi chacune renonce.
• Comment les objets sont liés, à qui appartiennent les enregistrements, et ce que cela signifie pour l’accès et le passage à l’échelle.
• De quelles licences dépend le modèle, vérifié avant de concevoir les objets, pas après.
• Comment les données restent cohérentes, et ce que coûte chaque couche de cohérence.

Au-delà de l’examen : la construction assistée par IA peut créer des objets et des champs en quelques minutes. Quand ajouter ne coûte presque plus rien, « chaque structure est un engagement » compte plus, pas moins. Chaque module se termine par ce que l’IA change pour cette décision.

Pour aller plus loin

• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), aide Salesforce (en anglais)
• Standard User Licenses (opens in a new tab), aide Salesforce (en anglais)

Suivant : Comprendre les données de l’entreprise