Où vivent ces données ?

🌐 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 4 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 : Construisez le vôtre : les objets personnalisés · Suivant : Choisir le bon objet

La question à laquelle répond ce module : avant de créer un objet, où ces données doivent-elles réellement vivre : sur le cœur dans Salesforce, référencées là où elles se trouvent déjà, ou archivées ?

Laissez-moi vous poser une question. Une nouvelle exigence arrive sur votre bureau. Quelle est la première chose que vous faites ?

Si vous êtes comme la plupart d’entre nous, vous ouvrez la Configuration et vous créez un objet personnalisé. Je comprends. En dix minutes, vous avez un onglet, une présentation de page et une vue de liste. Et voici ce que je dis dans chaque cours : au moment où vous créez ce nouvel objet, vous pensez déjà comme un architecte, que vous le vouliez ou non. Parce que chaque objet que vous créez 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 quiconque le touche. Et une fois que des gens et des intégrations en dépendent, bon courage pour le retirer.

La première décision d’architecture n’est donc pas quel objet. C’est où ces données doivent-elles vivre ? Répondez juste, et le type d’objet se choisit presque tout seul.

Sur le cœur et hors du cœur

D’abord, un mot que je vais beaucoup utiliser : le cœur (core). Le cœur, c’est la plateforme Salesforce sur laquelle tourne votre organisation : la plateforme mutualisée, pilotée par les métadonnées, du module 1, où vivent les objets Sales et Service du module 2, et chaque objet personnalisé que vous construisez au module 3. Quand je dis que des données sont sur le cœur, je veux dire qu’elles sont stockées dans votre organisation, dans ses objets.

Toutes les données ne vivent pas là. Data 360 garde ses données dans son propre stockage, en dehors des objets de votre organisation (il est proche du cœur (near-core) : géré sur le cœur, ses données hébergées hors du cœur ; plus de détails au chapitre 4). Et puis il y a tout ce que votre entreprise fait tourner et qui n’est pas du tout Salesforce : l’ERP, l’entrepôt, le système de commandes, la plateforme du partenaire. Tout cela est hors du cœur. Salesforce peut l’atteindre, l’afficher et l’utiliser, mais votre organisation ne le stocke pas.

Sur le cœur, deux sortes d’objets contiennent réellement vos enregistrements : les sObjects, standard et personnalisés (__c), et les big objects (__b). Hors du cœur, vous atteignez les données via les objets externes (__x) et les autres outils d’intégration. Gardez en tête ces suffixes du module 3 ; ils vous disent où vit une donnée rien qu’à son nom.

Je vois ça comme un bureau. Certaines choses ont leur place sur votre bureau, où vous les utilisez tous les jours. D’autres, vous avez juste besoin de les consulter dans le classeur de quelqu’un d’autre. Et d’autres encore partent dans des cartons, dans l’abri au fond du jardin. Cela me donne trois réponses.

1. Sur le cœur : elles vivent sur votre bureau

Les données sont créées, modifiées et utilisées dans Salesforce tous les jours : comptes, requêtes, opportunités, ordres d’exécution. Les garder dans des sObjects, c’est comme les garder sur le devant de votre bureau. C’est à ça que servent les objets standard et personnalisés, et vous avez tout : présentations de page, partage, automatisation, rapports, recherche, et maintenant les fonctionnalités d’IA construites sur le modèle de données.

Votre bureau n’est pas gratuit pour autant. Les données sur le cœur coûtent du stockage, compté à la manière de Salesforce, enregistrement par enregistrement, pas colonne par colonne, et les documents comptent à part, dans le stockage de fichiers. Nous avons vu les deux au module 2. Les gros volumes de photos et de scans ont souvent leur place hors du cœur, Salesforce ne gardant qu’un lien.

2. Référencées : elles vivent dans le classeur de quelqu’un d’autre

Les données appartiennent à un autre système (l’ERP, un entrepôt de données, une plateforme de commandes), et ce système reste la source de vérité. Les utilisateurs ont besoin de les voir dans Salesforce, peut-être de les relier à un enregistrement, mais Salesforce n’a pas besoin de sa propre copie. On parle aussi de données virtuelles : elles apparaissent virtuellement dans Salesforce, sans jamais y être stockées.

Ce sont les objets externes, via Salesforce Connect. J’aime dire que ça ressemble à un canard et que ça marche comme un canard, mais que ce n’est pas un canard. Ça apparaît comme un sObject : vous pouvez le mettre dans les présentations de page et les listes associées, et le relier à vos propres enregistrements avec des références externes et indirectes. Mais les données ne sont pas stockées sur le cœur. Chaque fois que vous y touchez, il fait un appel externe. Ouvrez un enregistrement, chargez une liste associée, lancez un rapport, et Salesforce va interroger l’autre système. Cela veut dire de la latence, et votre page n’est disponible que si le système derrière l’est.

Les gens tiquent sur le coût de la licence, alors faites le calcul comme je le fais en cours. Connect est facturé par point de terminaison, et un point de terminaison peut apporter de nombreux objets. Demandez maintenant ce que coûte de construire et de maintenir l’alternative : un composant personnalisé, le code d’appel externe derrière, et un développeur d’astreinte quand ça casse. Souvent, la licence revient moins cher, et vos administrateurs peuvent la configurer sans écrire une ligne de code. Là où elle montre ses limites : des données que vos utilisateurs modifient toute la journée, ou sur lesquelles ils font beaucoup de rapports.

Les documents aussi peuvent être référencés. Si un contrat vit déjà dans SharePoint Online, OneDrive, Google Drive ou Box, Files Connect permet aux utilisateurs de l’atteindre depuis Salesforce sans le copier.

Salesforce Connect n’est pas la seule façon de référencer des données. Parfois, c’est de la logique personnalisée : du code qui appelle l’autre système en temps réel et affiche ses données dans la page, sans en garder de copie. Cela vous donne un contrôle total, et une responsabilité totale pour l’appel externe, les erreurs et la maintenance. Et Data 360 peut aussi fédérer sans copier. Ce choix a son propre chapitre (Virtualisation, fédération et zéro copie). Ici, ce qui compte, c’est la décision elle-même : référencer, ne pas copier.

3. Archivées : elles vont dans l’abri au fond du jardin

Historique, pistes d’audit, anciennes transactions. Vous devez les garder, parfois des années, mais presque personne ne les ouvre. Et c’est celle que les équipes repoussent. Quand une classe me dit avoir un objet de 50 millions d’enregistrements et me demande pourquoi archiver, je leur retourne la question : si vous n’archivez pas aujourd’hui, allez-vous un jour archiver ? À 50 millions aujourd’hui, vous allez vers 100, 150, 200 millions.

Il y a deux abris. Le premier est sur le cœur : les big objects. Voyez-les comme un stockage au garage. Vous pouvez stocker un nombre énorme d’enregistrements, mais vous ne pouvez pas les mettre dans une présentation de page, il n’y a ni interface ni rapports standard, et vous interrogez via l’index du big object, par correspondance exacte ou par plage (Big Objects Best Practices (opens in a new tab), en anglais). La sécurité se limite aux autorisations d’objet et de champ, sans partage d’enregistrement, et l’automatisation ne s’exécute pas dessus. J’ai utilisé Salesforce Connect des dizaines de fois et les big objects seulement une ou deux fois. Ils fonctionnent, mais ils sont peu commodes, et j’ai écrit ma part de contournements pour atteindre les données. Mon conseil : faites un prototype avant de les proposer, et prévoyez comment les gens trouveront les données avant de les choisir.

L’autre abri est hors du cœur : un entrepôt ou une base de données ailleurs (Concevoir pour le volume). C’est souvent le meilleur abri, et il n’a pas à être hors de vue. Des données archivées hors du cœur peuvent encore apparaître dans des rapports grâce à des outils comme Tableau, et rester accessibles depuis Salesforce, via Salesforce Connect ou une autre façon de les virtualiser, quand quelqu’un a besoin de regarder en arrière.

Laissez-moi vous parler d’un projet où nous avons fait ça bien dès le départ. Un client du commerce de détail avait plus de 1 200 sites. Il m’a dit : « Nous ne faisons qu’une centaine de rendez-vous par jour et par magasin. Rien de grave. » Puis j’ai fait le calcul : cent par jour, six jours par semaine (environ 305 jours par an), sur 1 200 sites, cela fait plus de 36 millions de rendez-vous par an. Puis il a précisé que chaque visite créait deux rendez-vous, un au comptoir et un pour l’arrière-boutique : plus de 73 millions d’enregistrements par an. Puis il voulait cinq ans d’historique : plus de 360 millions d’enregistrements, avant toute croissance. Nous n’étions pas encore en production, et je voyais déjà le train foncer tout droit vers la gare des gros volumes de données. L’archive a donc été construite avant que nous ayons collecté un seul rendez-vous : les rendez-vous anciens partaient dans des big objects, et l’écran de recherche affichait les rendez-vous actuels avec les archivés juste en dessous. Des années plus tard, ça fonctionne toujours bien.

Click to enlarge

Mise en pratique : Steve Trucking

Steve Trucking est notre scénario fil rouge : une entreprise familiale de livraison du dernier kilomètre qui récupère des appareils électroménagers et électroniques dans les centres de distribution de grandes enseignes, puis les livre et les installe au domicile des clients. Quatre types de données, trois réponses :

Données	Où elles vivent	Pourquoi
Livraisons, équipes et rendez-vous du jour	Sur le cœur	Les répartiteurs et les équipes y travaillent toute la journée
Le détail des commandes de l’enseigne	Référencées (ou une copie légère sur le cœur)	Le système de l’enseigne est la source de vérité
L’historique des livraisons d’il y a trois ans	Archivées	Gardées pour les réclamations et les tendances ; presque personne ne l’ouvre
Les photos de livraison	Hors du cœur, avec un lien	Des milliers par jour ; stockées hors de Salesforce avec un lien sur la livraison

Voici la même chose sous forme de modèle de données. La livraison (Delivery) est sur le cœur, où les gens y travaillent toute la journée. Au bout de trois ans, elle passe dans l’historique des livraisons (Delivery History), un big object : toujours sur le cœur, mais dans l’abri. La commande du partenaire apparaît comme un objet externe, __x : Salesforce y relie la livraison, mais les données restent dans le système de l’enseigne. Et les photos vivent entièrement hors du cœur, avec un lien depuis la livraison. Un modèle, trois foyers.

Click to enlarge

Chaque vraie organisation a les trois. Celles qui ont des ennuis ont tout mis sur le cœur, parce que créer un objet était le bouton par défaut.

Ce que l’architecte décide ici

• La place de chaque type de données, avant de concevoir le moindre objet : sur le cœur, référencées ou archivées.
• La source de vérité. Si un autre système possède les données, Salesforce ne devrait pas devenir discrètement un second maître.
• Le chemin d’accès pour tout ce qui est hors du cœur. Les données référencées ont besoin d’une source disponible et d’une latence acceptable ; les données archivées ont besoin d’un moyen pour que les gens les trouvent.
• La croissance du stockage. Faites le calcul maintenant (enregistrements par jour, fois la croissance, fois la durée de conservation), pas quand l’alerte de stockage arrive.

Au-delà de l’examen : l’IA fait monter les enjeux du « sur le cœur ». Les fonctionnalités d’IA et les agents fonctionnent mieux sur des données que la plateforme comprend : des données dans des objets standard et personnalisés, bien nommées et bien décrites. Cela pousse à mettre davantage sur le cœur. Résistez-y pour les mauvaises données. Un agent ancré sur une copie périmée des données ERP donne des réponses assurées et fausses. Souvent, il vaut mieux référencer la source en direct, ou garder sur le cœur une petite tranche bien décrite. L’endroit où l’IA lit les données fait maintenant partie de la décision sur l’endroit où elles vivent.

Pour aller plus loin

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (en anglais, consulté le 2026-09-25)
• Files Connect FAQ (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-09-25)
• Dans ce cours : Virtualisation, fédération et zéro copie et Concevoir pour le volume