Plus qu'une base de données

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

Image générée par IA

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

Module 1 sur 10 du chapitre L’architecture de données Salesforce, chapitre 3 du cours Data Architect. Chaque module se suffit à lui-même. Suivant : Regardez le vaisseau mère : les modèles de données standard

La question à laquelle répond ce module : qu’est-ce qui rend Salesforce différent d’une base de données traditionnelle ?

Si vous êtes administrateur Salesforce depuis un moment, vous savez déjà créer un objet. Configuration, Gestionnaire d’objets, Nouvel objet personnalisé. Donnez-lui un nom, ajoutez quelques champs, construisez une présentation de page, et dix minutes plus tard les utilisateurs peuvent travailler avec.

Mais que s’est-il réellement passé quand vous avez cliqué sur Enregistrer ?

Si vous venez du monde des bases de données, vous imaginez sans doute que Salesforce a créé une nouvelle table. Ce n’est pas le cas. Et comprendre pourquoi est l’un des moments où vous commencez à passer de la pensée d’administrateur ou de développeur à celle d’architecte.

Salesforce stocke des données, bien sûr ; il y a des bases de données en dessous. Mais Salesforce n’est pas une base de données avec un joli écran par-dessus. C’est une plateforme applicative pilotée par les métadonnées, et cette distinction façonne presque chaque décision de ce cours.

La plateforme a une forme

Au chapitre 2, nous avons construit le modèle sans nous soucier du tout de Salesforce. C’était voulu : nous avons écouté les noms, construit le modèle conceptuel, ajouté des attributs, des clés et des relations, et seulement ensuite demandé comment Salesforce devait le mettre en œuvre. Il nous faut maintenant comprendre ce sur quoi nous le mettons en œuvre.

J’utilise une formule simple pour cela : la plateforme a une forme. Salesforce nous donne des objets, des champs, des relations, la sécurité, l’automatisation, des API, des transactions, des rapports et la recherche, et tout cela est connecté. Quand je crée un objet, je ne crée pas seulement un endroit où mettre des lignes. Je crée quelque chose qui participe au modèle de sécurité, sur lequel l’automatisation peut agir, que les API exposent, que les rapports peuvent utiliser, auquel d’autres objets peuvent se rattacher, et dont les utilisateurs, les intégrations et, de plus en plus, les agents vont dépendre. C’est bien plus qu’une table.

Les métadonnées sont le plan

Pensez à un bâtiment. Il y a le bâtiment lui-même, et il y a le plan qui le décrit : où sont les murs, où vont les portes, comment les pièces communiquent. Salesforce fonctionne de la même façon. Une définition d’objet est une métadonnée. Une définition de champ est une métadonnée. Une relation est une métadonnée. La plupart de ce que nous configurons dans la Configuration est une métadonnée, et la plateforme la lit à l’exécution pour donner à notre organisation sa structure et son comportement.

Salesforce décrit le cœur de la plateforme comme à la fois mutualisé (multitenant) et piloté par les métadonnées : quand nous définissons un objet ou un champ, la définition est stockée comme métadonnée, pas comme une nouvelle table ou colonne physique pour notre organisation (Platform Multitenant Architecture (opens in a new tab), en anglais).

Quand j’enseigne cela, je soulève le capot. Salesforce ne crée pas une nouvelle base de données pour vous à chaque fois que vous ajoutez un objet. Il ajoute un enregistrement dans ses propres tables : une table des objets, une table des champs, une table des données, et des tables pivots pour les index et les relations, toutes indexées par un identifiant d’organisation qui sépare les données de votre organisation de celles de tous les autres. Ajouter un champ, c’est donc simplement ajouter une entrée. C’est pourquoi vous pouvez en créer un à la volée, à l’heure du déjeuner, en production.

Cela explique aussi quelque chose sur quoi les gens trébuchent. Quand vous écrivez SELECT Id, Name, Special__c FROM Account, on dirait une seule table. En dessous, vous lisez l’objet standard et son champ personnalisé à partir de structures différentes, donc la plateforme fait une jointure que vous n’avez jamais écrite. Les index existent, mais ils ne fonctionnent pas comme un index de base de données traditionnelle. Vous n’avez pas besoin de connaître ces mécanismes internes pour l’examen. Vous devez savoir que ce que vous voyez dans le Gestionnaire d’objets n’est pas une image fidèle, une à une, de tables physiques, et que cette abstraction est à la fois la force de la plateforme et la raison de son comportement.

Click to enlarge

Regardez le vaisseau mère

L’une des choses que je dis en cours, c’est de regarder le vaisseau mère. Avant d’inventer une façon compliquée de faire quelque chose sur Salesforce, regardez comment Salesforce lui-même le fait.

Prenez le compte. Ce n’est pas vous qui l’avez créé ; c’est Salesforce. Mais vous pouvez y ajouter des champs, automatiser autour, changer ses présentations, l’exposer via les API et y rattacher d’autres objets. Les objets personnalisés fonctionnent sur la même mécanique, c’est pourquoi objets standard et personnalisés se ressemblent tant quand on construit dessus. En Apex, ils partagent même une classe de base, le sObject.

C’est l’habitude sur laquelle s’appuie ce chapitre, et dans le module suivant, nous regardons pour de bon : les modèles de données standard que Salesforce a déjà construits pour vous.

Nous ne construisons pas à côté de Salesforce. Nous l’étendons.

Votre API est venue avec l’objet

Créez une table dans une base de données traditionnelle, et vous avez une table. Si une autre application doit l’utiliser, quelqu’un a encore du travail à faire. Créez un objet sur Salesforce, et la plateforme le comprend déjà à travers ses couches applicative et d’intégration : elle utilise les mêmes métadonnées pour fournir ses API REST et SOAP, si bien que les enregistrements de l’objet peuvent être créés, lus, mis à jour et supprimés à travers elles dès que l’objet existe (Platform Multitenant Architecture (opens in a new tab), en anglais).

Je n’ai pas conçu d’API parce que j’ai créé un objet. La plateforme connaît l’objet, ses champs, leurs types, ses relations et sa sécurité. C’est l’une des raisons pour lesquelles le développement Salesforce avance si vite. C’est aussi pourquoi créer un objet est une décision plus importante qu’il n’y paraît : vous branchez une structure sur toute une plateforme applicative. Et cela marche dans l’autre sens aussi. Des gens venant de SQL Server ou d’Oracle me demandent parfois comment charger des données directement dans la base. Vous ne pouvez pas. Tout passe par les API.

L’immeuble

Voici maintenant le mot que vous entendez tout le temps : mutualisation (multitenancy). Je le vois comme un immeuble d’appartements.

Vous avez votre appartement. Vos meubles sont à vous, et votre clé ne devrait pas ouvrir ma porte. Mais nous partageons l’immeuble : l’électricité, l’eau, les ascenseurs, le hall. Votre organisation ressemble à votre propre environnement, avec vos données, vos objets, votre automatisation. En dessous, Salesforce décrit chaque organisation comme un locataire, isolant les données, les métadonnées et la logique de chaque locataire tandis que l’infrastructure et les services sont partagés (Platform Multitenant Architecture (opens in a new tab), en anglais). C’est ainsi qu’il peut offrir à chaque client une plateforme aussi personnalisable sans faire tourner une pile séparée pour chacun.

Mais partager l’immeuble a des conséquences. Si un locataire achète un énorme climatiseur et fait tourner en même temps le sèche-cheveux et le four, il fait sauter le disjoncteur, et tout l’étage se retrouve dans le noir.

Vous ne pouvez pas monopoliser l’ascenseur

Restez une minute de plus dans l’immeuble. Imaginez qu’un résident annonce : « J’ai besoin de l’ascenseur de huit heures à midi. Personne d’autre ne peut l’utiliser. » Ça ne marche pas dans un immeuble partagé, et ça ne marche pas non plus sur Salesforce. On ne peut pas laisser un locataire consommer sans limite des ressources partagées et dégrader la plateforme pour tous les autres.

C’est de là que viennent les limites du gouverneur (governor limits). Si vous avez développé sur Salesforce, vous les avez sans doute rencontrées comme une liste de chiffres à apprendre par cœur. Je ne veux pas que vous les voyiez ainsi. Salesforce applique des limites au niveau de la transaction et de l’organisation pour que la charge d’un locataire ne monopolise pas la puissance de calcul partagée (Architecture Basics (opens in a new tab), en anglais). C’est cela, l’architecture ; chaque limite n’en est que la mise en œuvre. Plus loin dans le cours, nous nous intéresserons à certaines limites parce qu’elles changent une conception. Pour l’instant, souvenez-vous de l’immeuble : vous avez une énorme liberté pour rénover votre appartement. Vous ne pouvez pas monopoliser l’ascenseur.

Les ID Salesforce font partie de l’abstraction

Chaque enregistrement Salesforce a une identité que la plateforme comprend, l’ID d’enregistrement, et elle fonctionne dans toutes les fonctionnalités : l’interface, les API, les rapports, l’automatisation.

Au chapitre 2, nous avons dit qu’une bonne clé est unique, immuable, sans signification et jamais une donnée personnelle. L’ID Salesforce correspond à cela pour Salesforce. Mais ce n’est pas la même chose qu’une clé métier. Votre entreprise peut encore avoir un numéro client ERP, un matricule ou le numéro de commande d’un partenaire qui a un sens entre plusieurs systèmes. Ne confondez pas « Salesforce sait de quel enregistrement il s’agit » avec « l’entreprise sait de quelle chose métier il s’agit ». Ce sont des problèmes d’identité différents, et le second revient avec l’intégration et les données de référence.

Les objets sont plus que du stockage

Voici le changement que je veux que vous fassiez avant le reste de ce chapitre. Un objet n’est pas seulement un endroit où stocker des données. Un champ n’est pas seulement une colonne, et une relation n’est pas seulement une clé étrangère. J’utilise les comparaisons avec les bases de données en cours, parce qu’elles se rattachent à ce que les gens savent déjà. Mais si nous nous arrêtons là, nous passons à côté de l’architecture.

L’objet que nous choisissons décide des capacités qui viennent avec. Le type de champ influence la validation, l’intégration, la recherche, les rapports et la façon dont d’autres systèmes lisent les données. La relation décide du cycle de vie, de la propriété, du partage et de la suppression. L’endroit où nous mettons les données influence le stockage, la performance et le passage à l’échelle. Et comme tout cela tourne sur une plateforme partagée, un choix sans conséquence avec cent enregistrements peut se comporter très différemment avec cent millions. Nous prendrons ces décisions une par une.

Au-delà de l’examen : ce que l’IA change. Pendant des années, de bons noms et de bonnes descriptions ont aidé l’administrateur ou le développeur suivant à comprendre ce que nous avions construit. Maintenant, les machines lisent aussi ce contexte. Un système d’IA qui travaille avec un champ appelé Flag2__c a le même problème qu’un nouveau développeur : qu’est-ce que ce truc signifie ? Les métadonnées ne sont plus de la décoration ; elles font partie de la façon dont les machines comprennent l’application.

Ce que l’architecte décide ici

• Est-ce que je conçois pour la plateforme sur laquelle je suis réellement, ou est-ce que je traite Salesforce comme une base de données générique ?
• Quelles parties de ma conception sont des concepts métier, et lesquelles sont des choix de mise en œuvre Salesforce ?
• Quel comportement de la plateforme vient avec la structure que je m’apprête à créer ?
• Quelles limites expriment l’architecture partagée, et lesquelles vont façonner cette conception ?
• Si cette structure sera difficile à changer plus tard, est-ce que je la traite comme une décision d’architecture ?

Au chapitre 2, nous avons dit : ne concevez pas depuis la Configuration. Vous connaissez maintenant une autre raison. Cliquer sur Nouvel objet personnalisé ne vous donne pas seulement une table ; cela branche une pièce de plus de votre architecture sur une plateforme mutualisée pilotée par les métadonnées. Mais avant de décider quel objet créer, il y a une question plus fondamentale : ces données devraient-elles seulement vivre ici ? C’est la suite.

Pour aller plus loin

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (en anglais), consulté le 2026-10-02, revérifié le 2026-10-12 : les définitions d’objets et de champs sont stockées comme métadonnées, pas comme de nouvelles tables ; des tables partagées (MT_Objects, MT_Fields, MT_Data, MT_Indexes) indexées par OrgID ; les mêmes métadonnées fournissent les API REST et SOAP.
• Salesforce Architects, Architecture Basics (opens in a new tab) (en anglais), consulté le 2026-10-02, revérifié le 2026-10-12 : des limites du gouverneur et d’exécution pour que le code et les transactions « ne monopolisent pas les ressources de calcul partagées ».