Transformer le modèle en 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

Module 6 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 : Concevoir en troisième forme normale, puis prendre du recul · Suivant : le guide d’étude du chapitre, puis le chapitre suivant : l’architecture de données Salesforce

La question à laquelle répond ce module : comment un modèle de données logique devient-il un modèle de données physique Salesforce ?

Nous allons enfin parler de Salesforce. Si vous résistiez à l’envie de transformer chaque boîte en objet, vous pouvez maintenant y aller. Mais remarquez l’ordre dans lequel nous sommes arrivés ici : nous avons compris le métier, décrit les données, mis chaque fait à sa place, et décidé où nous l’infléchirions volontairement. C’est seulement maintenant que je demande comment Salesforce doit le mettre en œuvre. C’est la progression que je veux que vous reteniez : conceptuel → logique → physique. Le modèle conceptuel décrit le métier. Le modèle logique décrit les données. Le modèle physique décrit comment nous allons réellement le construire.

Assis, pas bouger, modèle

L’étape physique se voit le plus facilement sur quelque chose de petit, alors les animaux passent en premier.

Qui sont les entreprises et les personnes ? L’éleveur est une entreprise, il devient donc un compte avec le type d’enregistrement Éleveur. Le propriétaire est aussi un compte, ou un compte personnel, avec le type d’enregistrement Propriétaire. Deux sortes du même objet standard, côte à côte en haut du diagramme, exactement là où elles sont depuis le module 1.

Qu’est-ce qui n’a pas de place standard ? Animal, Race, Tour, Tour de l’animal et Évaluation de tour deviennent des objets personnalisés. Et vous vous souvenez de l’espèce que nous avons copiée sur l’animal au module 5 ? Ici, elle reçoit son rôle : elle devient le type d’enregistrement de l’Animal, Chien ou Chat. Un seul objet avec deux types d’enregistrement, chacun avec sa propre présentation de page et ses propres valeurs de liste de sélection, au lieu d’un objet Chien et d’un objet Chat.

Quelles relations sont principal-détails ? J’utilise principal-détails uniquement là où l’enfant ne changera jamais de parent. Un Tour de l’animal appartient à son animal pour la vie, et chaque Évaluation de tour appartient à son Tour de l’animal, donc les deux sont principal-détails. Cela paie tout de suite : c’est la relation principal-détails qui permet à l’animal de garder un champ de récapitulatif de cumul de ses Tours de l’animal, pour que le compteur Tours connus du module 5 reste synchronisé tout seul. Les animaux changent de foyer, en revanche, donc le Propriétaire est une relation de référence.

Lesquelles sont des relations de référence ? Salesforce ne recommande pas plus de 10 000 enfants sur un seul parent. Un tour populaire comme « Assis », une race courante ou un gros éleveur pourraient facilement dépasser ce seuil, donc Tour de l’animal pointe vers son Tour par une relation de référence, et l’animal pointe de la même façon vers sa Race et son Éleveur. Et évitez les relations polymorphes quand vous le pouvez, celles où un même champ peut pointer vers plusieurs types d’objets. Elles sont pratiques le premier jour et plus difficiles pour tout ce qui doit les lire ensuite : rapports, intégrations, et maintenant les agents.

Qu’est-ce qui reste hors de la plateforme ? Si l’animal porte un collier GPS qui signale où il se trouve, cette position n’a pas du tout besoin d’être copiée. Elle peut être un objet externe, lu en direct depuis le système de suivi du collier.

Click to enlarge

Chaque décision de ce diagramme remonte à quelque chose que nous avons décidé plus tôt, et c’est tout l’intérêt. Maintenant, la même étape pour Steve Trucking.

Commencez par le modèle logique

Notre modèle logique de Steve Trucking contient maintenant Partenaire distributeur, Centre de distribution, Manifeste, Livraison, Article de livraison, Destinataire, Tournée, Arrêt, Équipe, Camion et Affectation d’équipe. Ce sont des concepts métier, et je peux maintenant commencer à les transposer dans Salesforce.

Un partenaire distributeur pourrait être un compte. Une livraison pourrait correspondre à quelque chose que Salesforce propose déjà pour le travail planifié sur le terrain, ou devenir un objet personnalisé. Rien de standard ne convient à un manifeste, donc il deviendra probablement personnalisé. Et le destinataire est une question vraiment difficile : un compte personnel, un contact, ou simplement des informations sur la livraison ? Nous y répondrons correctement au chapitre suivant.

Le mot important reste pourrait. Ne supposez pas la mise en œuvre juste parce qu’un concept métier ressemble à un objet Salesforce. C’est pourquoi nous avons d’abord construit le modèle logique : il nous donne de quoi éprouver la conception Salesforce.

Une entité métier ne veut pas automatiquement dire un objet personnalisé

Voici un piège que je veux que les administrateurs évitent : « Nous avons identifié onze entités, donc il nous faut onze objets personnalisés. » Non. Une entité logique nous dit que le concept métier compte. Elle ne dicte pas comment Salesforce doit le stocker. Un concept peut devenir un objet standard, un objet personnalisé, une relation entre objets, un champ ou quelques champs, une valeur gérée en configuration, ou des données qui vivent entièrement hors de Salesforce (les photos de livraison de Steve Trucking sont un bon candidat). C’est dans le modèle physique que ces choix se font, et c’est exactement pourquoi nous ne les avons pas faits lors du premier appel.

Les attributs deviennent des champs physiques

La même transition se produit avec les attributs. Notre camion logique a un numéro de parc, un VIN, une marque, un modèle, une année, une plaque d’immatriculation et un statut. Nous décidons maintenant comment ils existent physiquement : quel objet les détient, quels types de champ ils utilisent, lesquels sont obligatoires, lesquels doivent être uniques, lesquels sont des identifiants externes, lesquels ont besoin d’une validation, lesquels sont dérivés plutôt que stockés, et lesquels sont sensibles. Au niveau logique, nous avons demandé ce que signifie Camion. Au niveau physique, nous demandons comment Salesforce va représenter Camion. Des questions différentes.

Click to enlarge

Les relations deviennent des décisions de plateforme

Tout le temps passé sur les relations est récompensé ici. Nous savons déjà si chacune est un-à-un, un-à-plusieurs ou plusieurs-à-plusieurs, obligatoire ou facultative, et si son historique compte. Nous décidons maintenant comment Salesforce la met en œuvre : une relation de référence, une relation principal-détails ou un objet de jonction Salesforce (Salesforce Junction Object), et peut-être une jonction avec ses propres attributs, parce que, comme nous l’avons vu, la relation elle-même peut avoir un sens métier.

Repensez à l’affectation d’équipe. Nous aurions pu commencer ce chapitre en disant : « Créons un objet de jonction Salesforce entre équipe et camion. » Regardez ce que nous aurions sauté : pourquoi la relation existe, si elle a besoin d’une date et d’une tournée, si elle a un statut, et si une réclamation pour dommage des semaines plus tard a besoin de son historique. Ces questions métier nous disent ce qu’est une affectation d’équipe. Ce n’est qu’ensuite que nous devrions décider comment Salesforce la construit, et si Salesforce a déjà quelque chose qui fait ce travail.

Dessinez maintenant le modèle physique

Le schéma change encore. Le modèle conceptuel montrait des concepts métier et des traits simples. Le modèle logique a ajouté des attributs, des clés, la cardinalité et les entités cachées dans les relations. Maintenant, le modèle physique commence à ressembler à Salesforce : objets standard, objets personnalisés, champs, types de relation, et ce qui vit hors de la plateforme.

Click to enlarge

Je veux que vous puissiez mettre ces trois schémas côte à côte et voir la progression : pas trois schémas sans rapport, mais le même métier à trois niveaux.

Un mot sur la façon dont je les dessine, car la mise en page fait partie du message. Je place l’objet principal au milieu, un peu en bas. S’il a des objets parents, je les place un peu au-dessus, pour qu’on lise le modèle de haut en bas, de gauche à droite, comme le métier y pense. Les données de référence vont sur le côté. La couleur a aussi un sens : je mets toujours Salesforce en bleu, et je choisis une couleur pour les systèmes propres à l’entreprise, généralement le vert, parce que le vert est une couleur agréable et amicale. Je n’utilise pas le rouge, et les jaunes sont un peu agressifs. Quand un modèle est disposé ainsi, il me parle. Beaucoup des schémas que vous trouverez sont en réalité de la gestion d’espace : comment garer toutes mes voitures dans mon garage encombré ? Je préfère peindre une image logique que l’esprit peut saisir.

Le modèle physique doit respecter la plateforme

Salesforce n’est pas une base de données relationnelle générique. Il a ses propres principes sur les relations, la propriété, la sécurité et les rapports. Il a des limites, un comportement de requête et de l’automatisation, et une architecture qui influence le comportement d’un modèle à grande échelle. Un modèle logique qui paraît parfait sur un tableau blanc peut donc devoir changer en devenant physique. Ce n’est pas Salesforce qui vous gêne. Cela veut dire que la plateforme a une forme, et que les bons architectes comprennent cette forme. C’est exactement le sujet du chapitre suivant.

Parfois aussi, le modèle physique différera volontairement du modèle logique propre à cause des décisions de dénormalisation prises au module 5. Ce n’est pas un problème, tant que nous pouvons expliquer pourquoi.

Ne concevez pas depuis la Configuration

Il y a une habitude que je veux vous voir perdre si vous l’avez : commencer votre architecture de données par Configuration → Gestionnaire d’objets → Nouvel objet personnalisé et trouver le modèle au fil de l’eau. Salesforce rend incroyablement facile de créer des choses ; c’est l’une de ses forces, et l’une des raisons pour lesquelles les modèles de données faibles apparaissent si vite. Quelques clics et vous avez un objet, quelques autres et vous avez des champs et une relation. Puis les données arrivent, des flows sont construits, des rapports sont créés, des intégrations en dépendent, et l’objet créé en cinq minutes devient très coûteux à changer. C’est le test de réversibilité du chapitre 1. Alors, avant de cliquer sur Nouvel objet personnalisé, dessinez le modèle.

Physique ne veut pas dire permanent

Il y a une autre raison pour laquelle je garde les trois modèles séparés : la technologie change. Aujourd’hui, une partie des données de Steve Trucking vit sur le cœur de Salesforce. Demain, une partie pourra vivre dans Data 360, un entrepôt, ou un système que nous n’avons pas encore choisi, et l’assistant d’IA a besoin de sa propre représentation. L’architecture physique peut changer, alors que les concepts métier restent remarquablement stables : les partenaires distributeurs, les livraisons et les destinataires existent toujours. C’est ce qui donne sa valeur au modèle logique. C’est une description durable du métier, qui n’est pas liée à la mise en œuvre d’aujourd’hui.

Ce que l’architecte décide ici

Quand je transforme un modèle logique en modèle physique Salesforce, je décide :

• Quelles entités métier correspondent à des capacités standard de Salesforce, et lesquelles ont besoin d’objets personnalisés ou d’une autre représentation.
• Comment les attributs logiques deviennent des champs physiques, et comment les relations sont mises en œuvre sur la plateforme.
• Où la dénormalisation délibérée a sa place dans la conception physique.
• Quelles données ont leur place sur Salesforce, et lesquelles ailleurs.
• Quelles caractéristiques de la plateforme obligent le modèle physique à différer du modèle logique.

Surtout, je veux pouvoir faire remonter chaque décision. Si vous montrez quelque chose dans mon modèle physique en demandant « Pourquoi c’est là ? », je dois pouvoir vous ramener à travers le modèle logique et le modèle conceptuel jusqu’à quelque chose dont le métier a réellement besoin : métier → conceptuel → logique → physique.

Au-delà de l’examen : ce que l’IA change. L’IA peut maintenant passer d’un cahier des charges à des objets et des champs Salesforce en un seul saut. Cela rend la séquence plus importante, pas moins : si elle saute des exigences à la configuration, demandez-lui de montrer ce qui s’est passé entre les deux : ce qu’elle a considéré comme une entité, quelles clés elle a choisies, quelles relations elle a supposées, et où elle a dénormalisé. Ce sont des décisions d’architecture, et l’architecte a toujours besoin de les voir.

Nous avons commencé ce chapitre lors d’un premier appel, en écoutant les noms, et nous le terminons avec un modèle physique que nous pouvons faire remonter jusqu’au métier. Maintenant que nous avons choisi de construire sur Salesforce, la question suivante va plus loin : sur quel type de plateforme de données construisons-nous réellement ?

Pour aller plus loin

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (en anglais, consulté le 2026-10-02) : « configurez les relations parent-enfant avec au plus 10 000 enfants par enregistrement parent ». Une recommandation liée au déséquilibre de données (data skew), pas une limite stricte ; le chapitre 7 va plus loin.
• Roll-Up Summary Field (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-12) : un champ de récapitulatif de cumul compte ou additionne les enregistrements de détail via une relation principal-détails.