Choisir le bon objet
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 5 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 : Où vivent ces données ? · Suivant : Les champs aussi, c’est de l’architecture
La question à laquelle répond ce module : quel type d’objet Salesforce ce concept métier devrait-il devenir, et que permettent les licences ?
L’une des choses les plus faciles à faire dans Salesforce est de créer un objet personnalisé. C’est exactement pourquoi je pense que nous en créons trop.
Vous êtes en séance d’exigences et quelqu’un dit : « Il faut qu’on suive nos distributeurs. » Nouvel objet personnalisé : Distributeur. Terminé. Sauf que je veux que l’architecte pose d’abord une autre question : qu’est-ce qu’un distributeur ? C’est une entreprise. Salesforce a déjà une assez bonne façon de représenter une entreprise. Ça s’appelle un compte. Cela ne veut pas dire que la réponse est toujours Compte. Mais si je dois expliquer pourquoi une entreprise n’est pas un compte, je veux une meilleure raison que « le métier les appelle des distributeurs ».
C’est ici que le modèle logique du chapitre 2 rencontre la plateforme, et ma position de départ est simple : si le concept métier correspond nettement à la finalité prévue d’un objet standard, commencez par là.
Commencez par le sens
Section intitulée « Commencez par le sens »Même quand quelque chose mérite d’être un objet, il ne mérite pas automatiquement d’être un objet personnalisé. Demandez ce que la chose représente réellement. Une entreprise ou une organisation, quelle que soit sa forme ? Commencez par le compte. Une personne qui travaille avec cette organisation ? Le contact. Quelque chose qu’un client possède ou a acheté ? L’actif. Quelque chose que vous essayez de vendre ? L’opportunité entre alors dans la conversation.
C’est pourquoi nous avons d’abord regardé le vaisseau mère, au module 2. Ces modèles ne conviennent pas à toutes les activités, mais nous ne devrions pas les ignorer parce que construire les nôtres paraît plus propre. Avant Nouvel objet personnalisé, demandez comment Salesforce modélise ce concept, ce qui a été construit autour de ce modèle, et à quoi vous renonceriez en le remplaçant.
Le test de l’adéquation nette
Section intitulée « Le test de l’adéquation nette »Mon test tient en une question : ce concept métier correspond-il nettement à la finalité prévue de l’objet standard ? Si oui, je penche vers l’objet standard.
Un distributeur est une entreprise avec laquelle nous avons une relation, donc le compte est une adéquation nette. Peu m’importe que les utilisateurs appellent une entreprise distributeur, une autre fournisseur, une autre partenaire distributeur et une autre client. Ce sont des rôles métier, et ils n’ont pas besoin de quatre objets physiques. Des noms métier différents ne veulent pas automatiquement dire des structures de données différentes. Un type, un type d’enregistrement ou une relation peut porter la différence.
Le test marche aussi dans l’autre sens. Au chapitre 1, je vous ai laissé une question : l’entreprise d’un client a de nombreux lieux de livraison. Chaque lieu doit-il être un compte, ou un objet personnalisé ?
Un compte vous apporte beaucoup. Vous avez les champs d’adresse, et tout ce qui attend déjà une adresse de compte : rapports, cartes, intégrations. Mais vous avez aussi la charge : beaucoup de champs, le partage, la hiérarchie, la propriété, tout ce qui se rattache à un compte, et la plupart n’a rien à voir avec une adresse séparée. Vous porteriez beaucoup de choses lourdes dont vous ne vous servirez pas, juste pour une autre adresse.
Un objet personnalisé, enfant du compte, peut être léger : juste les champs d’adresse, un lieu où nous livrons, avec son propre cycle de vie que je peux gérer indépendamment.
C’est donc un équilibre : le poids que vous prenez contre la valeur que vous obtenez. Si tout ce qu’il me faut, c’est une adresse avec son propre cycle de vie, c’est là que je passe au personnalisé.
Pareil pour les sous-problèmes d’une requête. Si chaque sous-problème est vraiment une requête, traitée par un agent, avec son propre statut et son propre niveau de service, imbriquez-les avec la requête parente (Parent Case) du module 2. Mais si ce n’est qu’un élément de liste de contrôle que personne ne traite comme une requête, une requête complète porte beaucoup de choses dont elle ne se servira jamais, et un simple enfant personnalisé peut peser moins. Pas parce que le personnalisé est plus propre. Parce que le sens est différent, ou le poids n’est pas le bon.
Les objets standard viennent avec des bagages
Section intitulée « Les objets standard viennent avec des bagages »Quand vous choisissez un objet standard, vous choisissez plus que ses champs. Vous choisissez quelque chose que les produits Salesforce comprennent déjà : rapports, automatisation, relations intégrées, fonctionnalités produit, packages AppExchange, et tout ce que Salesforce construira ensuite. Cela peut avoir énormément de valeur.
Les objets standard viennent aussi avec des partis pris : un comportement existant, des relations, des considérations de sécurité, parfois des exigences de licence, et des fonctionnalités dont vous n’avez pas besoin. « Toujours utiliser les objets standard » n’est donc pas ma règle. Je n’ai pas de règle « toujours ». J’ai un penchant : utiliser l’objet standard quand le sens correspond nettement et que le comportement de la plateforme autour aide la conception plutôt que de la combattre. Si je passe cinq ans à faire se comporter l’opportunité comme quelque chose qui n’est pas une opportunité commerciale, je n’ai rien gagné à rester standard. J’ai juste fait le mauvais compromis dans l’autre sens.
L’actif est un bon exemple
Section intitulée « L’actif est un bon exemple »L’actif (Asset) est l’un des objets standard que les gens négligent. Le plus simplement possible : c’est une chose que le client possède. Peut-être nous l’a-t-il achetée, peut-être pas. Je m’intéresse quand même au produit d’un concurrent installé chez mon client, parce que je l’entretiens, ou que j’essaie de le remplacer, ou que je dois comprendre son parc installé. Si je crée Customer_Product__c sans regarder d’abord l’actif, j’ai sauté une question d’architecture. L’actif ne gagne pas automatiquement, mais il mérite d’être évalué.
Les comptes personnels : quand la personne est-elle le compte ?
Section intitulée « Les comptes personnels : quand la personne est-elle le compte ? »Au module 2, nous avons rencontré les comptes personnels : un compte et un contact dans un seul enregistrement, pour les clients qui sont des particuliers. Maintenant, la décision.
Ma position : en B2C, il est difficile de s’en passer. Les comptes et les contacts apportent tellement de choses prêtes à l’emploi que le coût et la charge en valent la peine. Et il y a un coût : environ deux fois le stockage d’un compte professionnel, une option qu’on ne peut pas désactiver, et certaines licences externes ne peuvent pas les utiliser. Partner Community ne peut pas être utilisée avec les comptes personnels (Experience Cloud User Licenses (opens in a new tab), en anglais). La question n’est donc pas « avons-nous des personnes dans notre base de données ? ». Chaque organisation a des personnes. C’est « la personne est-elle réellement le compte dans cette activité ? ». Un contact qui est une personne n’en fait pas un compte personnel. C’est la relation d’affaires qui le fait.
Maintenant, compliquons tout : les licences
Section intitulée « Maintenant, compliquons tout : les licences »Jusqu’ici : trouver le concept, chercher l’adéquation standard la plus nette, passer au personnalisé quand le sens ne correspond pas. Voici maintenant la question suivante de l’architecte : qui doit l’utiliser ? Vous pouvez concevoir un beau modèle et découvrir ensuite que la moitié des gens qui ont besoin des données n’ont pas de licence pour les objets choisis. Les licences font partie du modèle de données.
Trois licences internes
Section intitulée « Trois licences internes »Commencez par vos propres collaborateurs. Dans l’entreprise, il y a trois types de licences que je veux que chaque architecte connaisse par cœur, parce qu’elles déterminent ce que chaque utilisateur peut voir et faire, et donc ce sur quoi votre modèle de données peut compter.
Sales Cloud (désormais Agentforce Sales). Ces utilisateurs ont la licence d’utilisateur Salesforce complète : les objets CRM standard, et toute application standard ou personnalisée. Cela veut dire les pistes, les opportunités et les prévisions en plus des comptes et des contacts, et même les requêtes : un commercial peut voir les requêtes ouvertes d’un client avant un appel. Créer et lancer des campagnes demande une pièce de plus, la licence de fonctionnalité Marketing User.
Service Cloud (désormais Agentforce Service). La même licence d’utilisateur Salesforce, configurée pour le service. Les requêtes sont au centre, traitées dans la Service Console : c’est la licence de fonctionnalité Service Cloud User qui ouvre la console Salesforce pour le service. C’est là que vivent les accords de niveau de service (SLA), via la gestion des droits et les jalons (milestones), et là qu’intervient Knowledge, que la plupart des éditions achètent en option.
Platform (Salesforce Platform). Pour les personnes qui ont besoin de vos applications personnalisées, pas du CRM. Elles ont les comptes, les contacts, les rapports, les tableaux de bord, les documents et toutes les applications personnalisées de l’organisation. Ce qu’elles n’ont pas : les prévisions, les pistes, les campagnes et les opportunités. Elle coûte moins cher, et c’est exactement pour ça que tant de grandes applications personnalisées tournent dessus, et exactement pour ça qu’elle peut prendre votre modèle de données en défaut.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| Licence d’utilisateur | Salesforce | Salesforce | Salesforce Platform |
| Conçue pour | Vendre | Accompagner les clients | Les applications personnalisées |
| Comptes, contacts | Oui | Oui | Oui |
| Pistes, opportunités, prévisions | Oui | Oui | Non |
| Requêtes | Oui, pour voir les requêtes d’un client | Au centre, dans la Service Console | Non |
| Accords de niveau de service | Non | Oui, droits et jalons | Non |
| Objets et applications personnalisés | Oui | Oui | Oui |
Lisez le tableau comme le fait un architecte. Si un grand groupe d’utilisateurs est sur Platform, toute conception qui place leur travail sur une opportunité est cassée avant même de commencer. Si les dirigeants ont besoin des chiffres de SLA, c’est leur licence qui décide s’ils peuvent les voir. Ces trois types déterminent le comportement.
Quand la licence décide de l’objet
Section intitulée « Quand la licence décide de l’objet »L’opportunité est la victime que j’ai rencontrée le plus souvent. Vous l’avez vu dans le tableau : les utilisateurs Platform ne l’ont pas (Standard User Licenses (opens in a new tab), en anglais), et les utilisateurs Customer Community ne peuvent pas non plus travailler dessus. Alors le besoin ressemble à une opportunité, quelqu’un dit « utilisons l’opportunité », et je demande qui a besoin d’y accéder. Si une grande population est sur des licences Platform ou Customer Community, la licence n’est plus un détail d’achat. C’est une contrainte d’architecture, et elle pousse généralement la conception vers un objet personnalisé.
Cela marche aussi vers le haut. En cours, je demande : le PDG veut de jolis tableaux de bord ; licence Sales ou Service ? Un utilisateur Sales peut voir les objets commerciaux et même les requêtes, donc pour des tableaux de bord commerciaux et le nombre de requêtes ouvertes, Sales suffit. Mais dès que le dirigeant veut des KPI de SLA (combien de temps avant qu’une requête dépasse son niveau de service), ces données sont dans les droits et jalons (entitlements et milestones), et la gestion des droits exige Agentforce Service, anciennement Service Cloud (Supported Editions for Service Features (opens in a new tab), en anglais). Vous voilà en train de mettre à niveau les licences des dirigeants. Écoutez l’exigence métier, et sachez quelle licence se trouve sous les données dont elle a besoin.
Le stade
Section intitulée « Le stade »Je vois les licences comme des places dans un stade. Tout le monde regarde le même match. Si j’achète les places chères au centre, je vois les deux équipes de près. Si je suis tout en haut dans un coin des gradins, les sièges ne sont pas rembourrés et je regarde avec des jumelles.
Ce sont les licences externes, pour les personnes extérieures à l’entreprise : des clients et des partenaires qui se connectent à un site Experience Cloud. Il y en a trois que je veux que vous connaissiez.
Customer Community : les gradins. Conçue pour un grand nombre d’utilisateurs externes qui ont besoin des requêtes et de Knowledge : un client qui vérifie où en est sa requête d’assistance. Les places coûtent environ moitié moins et peuvent aller à des nombres énormes d’utilisateurs. Que perdez-vous là-haut ? Les rapports, les tableaux de bord, et la table de partage : le partage basé sur les rôles dont bénéficient les niveaux supérieurs. Elle fonctionne avec les comptes personnels.
Customer Community Plus : à mi-hauteur environ. Salesforce la décrit comme la licence des utilisateurs externes qui ont besoin de rapports, de tableaux de bord et du partage standard : un client qui gère l’accès d’autres personnes, ou qui a besoin de voir ses chiffres.
Partner Community : encore plus près, pour le business-to-business, avec un accès aux données commerciales. Les partenaires travaillent les pistes et les opportunités : ils enregistrent des affaires, et ils mènent des campagnes avec vous. C’est la place externe qui atteint les objets commerciaux. Un piège : elle ne peut pas être utilisée avec les comptes personnels (Experience Cloud User Licenses (opens in a new tab), en anglais).
L’erreur, c’est de concevoir comme si tout le monde avait le billet cher, puis de découvrir à la mise en œuvre que la plupart de vos utilisateurs ne peuvent pas entrer dans la tribune où vous avez mis leurs données. Vous avez alors trois choix : acheter d’autres places, déplacer l’expérience, ou reconcevoir le modèle. Les trois relèvent de l’architecture.
La façon de payer change la conception
Section intitulée « La façon de payer change la conception »Il y a une autre question que les gens oublient : comment ces utilisateurs vont-ils se connecter ? Les licences externes existent sous deux formes. Par membre : vous payez par utilisateur, ce qui convient à 500 partenaires qui se connectent tous les jours. Par connexion : vous achetez un nombre de connexions par mois, ce qui convient à cinq millions de clients qui se connectent quelques fois par an. Se connecter plusieurs fois le même jour compte toujours pour une seule connexion (Experience Cloud User Licenses (opens in a new tab), en anglais).
Alors quand quelqu’un dit « nous construisons un portail client », ma question suivante n’est pas quel modèle de site. C’est : qui sont les clients, combien sont-ils, à quelle fréquence viennent-ils, de quelles données ont-ils besoin, et qu’ont-ils le droit d’en faire ?
Quand la licence façonne le modèle
Section intitulée « Quand la licence façonne le modèle »Parfois, la licence ne choisit pas seulement l’objet ; elle tord tout le modèle. Certaines licences de plateforme limitent les utilisateurs à une application personnalisée de dix objets personnalisés au maximum (Lightning Platform – One App, par exemple ; Standard User Licenses (opens in a new tab), en anglais).
Sur un des premiers projets, pour une grande entreprise de services professionnels et de construction, nous devions construire une sorte de LinkedIn pour tout le personnel : les postes, les compétences, les certifications, les langues et les projets de chacun, pour qu’on puisse trouver le constructeur de ponts certifié dans un pays donné. Sans limite, j’aurais construit un objet poste-utilisateur, compétence-utilisateur, certification-utilisateur, langue-utilisateur et projet-utilisateur, plus des listes de référence des certifications et des projets. Avec une licence à dix objets, et la consigne de ne pas tous les griller, ce n’était pas possible. C’est devenu un jeu de « en combien de notes » : avec combien d’objets puis-je construire ça ? La réponse était deux. Un objet de référence, avec un type d’enregistrement par type de liste (poste, compétence, certification, langue, projet), et un objet attribut utilisateur, avec les types d’enregistrement correspondants, qui pointe vers lui.
Ce n’était pas le modèle optimal. Il était pénible pour les rapports, et je l’aurais préféré plus propre. Mais c’est ce que la licence permettait. J’appelle ces objets des objets couteau suisse : gardez le modèle dans votre poche arrière, et quand les limites ne laissent plus de place, brisez la vitre et passez à la séparation par type d’enregistrement. Sachez seulement ce que vous échangez. Des autorisations différentes selon le type d’enregistrement peuvent vous obliger à séparer l’objet de toute façon.
Les personnes ne sont plus les seuls utilisateurs
Section intitulée « Les personnes ne sont plus les seuls utilisateurs »Une autre question de licence est devenue importante : qu’en est-il de ce qui n’est pas une personne ? Les intégrations ont des identités. Les agents ont des identités. Salesforce propose désormais une licence Salesforce Integration pour les intégrations de système à système : API uniquement, pas pour les humains, avec cinq licences incluses dans chaque organisation Enterprise, Unlimited et Performance Edition (Standard User Licenses (opens in a new tab), en anglais). Alors ne demandez pas seulement quels utilisateurs ont besoin d’accès. Demandez quelles identités ont besoin d’accès : une personne, un client, un partenaire, une intégration, un agent. Puis ce que chacune doit voir et faire.
Au-delà de l’examen : ce que l’IA change. À mesure que les agents deviennent un autre consommateur et créateur de données, le choix des objets et les licences ne concernent plus seulement les écrans humains. Sachez sous quelle identité l’agent s’exécute, ce que cette identité peut atteindre, et si le modèle place les données dont il a besoin derrière un objet ou une autorisation qu’il ne peut pas utiliser.
Steve Trucking : un cas facile et un cas difficile
Section intitulée « Steve Trucking : un cas facile et un cas difficile »Steve Trucking travaille avec des partenaires distributeurs (Retail Partners). Qu’est-ce qu’un partenaire distributeur ? Une entreprise. Facile : un compte. Je ne crée pas Retail_Partner__c parce que quelqu’un a utilisé le mot « partenaire ».
Maintenant le destinataire (Recipient), la personne qui reçoit le réfrigérateur. Contact ? Compte personnel ? Autre chose ? Un million de nouveaux destinataires par an, qui sont les clients des partenaires distributeurs, pas les nôtres. C’est exactement le genre de question où je ne veux pas sauter sur un objet avant de comprendre la relation, l’accès et le volume. Nous en déciderons au point de contrôle de la partie 1.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- Si un concept métier correspond nettement à la finalité prévue d’un objet standard, ou si son sens ou son poids est différent.
- Si des étiquettes métier différentes sont des entités différentes ou simplement des rôles différents de la même entité.
- Si chaque personne, utilisateur externe, intégration et agent qui a besoin des données peut atteindre l’objet choisi avec les licences prévues.
- Comment la population et le mode de connexion (par membre ou par connexion) façonnent la licence et le modèle.
- Quand une limite de licence justifie un modèle moins qu’optimal, et ce que coûte ce compromis en rapports et en autorisations.
Le propos n’est pas que les objets standard sont bons et les objets personnalisés mauvais. C’est que le choix a des conséquences, et que parfois il n’est pas du tout décidé par le nom, mais par les personnes, et les machines, qui doivent l’utiliser.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Aide Salesforce, Standard User Licenses (opens in a new tab) (en anglais), consulté le 2026-10-02, revérifié le 2026-10-12 : les utilisateurs Platform n’ont pas droit aux prévisions, pistes, campagnes et opportunités ; une application personnalisée de 10 objets personnalisés au maximum ; cinq licences Salesforce Integration dans chaque organisation Enterprise Edition.
- Aide Salesforce, Experience Cloud User Licenses (opens in a new tab) (en anglais), consulté le 2026-10-02, revérifié le 2026-10-12 : Partner Community ne peut pas être utilisée avec les comptes personnels ; Customer Community Plus pour les rapports, les tableaux de bord et le partage standard ; plusieurs connexions dans la même journée comptent pour une seule.
- Aide Salesforce, Supported Editions for Service Features (opens in a new tab) (en anglais), consulté le 2026-10-02, revérifié le 2026-10-12 : accords de niveau de service (gestion des droits) avec Agentforce Service ; Knowledge en coût supplémentaire dans la plupart des éditions.
- Aide Salesforce, Available Feature Licenses (opens in a new tab) (en anglais), consulté le 2026-10-12 : Service Cloud User, « Access the Salesforce Console for Service » ; Marketing User pour créer et gérer des campagnes.