Salesforce est un système parmi d'autres

🌐 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 1 sur 6 du chapitre Comprendre les données de l’entreprise, chapitre 4 du cours Data Architect. Chaque module est autonome. Suivant : Les types de données de l’entreprise

La question à laquelle répond ce module : pourquoi un architecte de données dessine-t-il ce qui entoure l’organisation avant de concevoir l’organisation ?

Quand j’enseigne à des candidats CTA, les devoirs après le premier jour sont toujours les mêmes. Lisez le scénario. Commencez le paysage des systèmes sur une page blanche. Ensuite seulement, faites un premier essai de modèle de données. Pas les objets, pas le détail des intégrations : le paysage. Je veux voir ce qui entoure Salesforce avant que nous décidions de ce qui a sa place à l’intérieur.

C’est un changement de perspective pour beaucoup de professionnels Salesforce. Si vous avez passé votre carrière comme administrateur ou développeur, Salesforce est naturellement le centre de votre monde. Vous ouvrez la Configuration, créez des objets, construisez des flows, écrivez de l’Apex, et intégrez d’autres systèmes dans Salesforce. Tout semble commencer par l’organisation. Un architecte doit reculer la caméra, car dans une entreprise Salesforce est un système parmi d’autres, et bien souvent ce n’est pas lui qui possède les données.

Dessiner d’abord le paysage

Le chapitre 2 a construit le modèle logique, et le chapitre 3 a demandé comment il vit sur Salesforce. Maintenant, je vais agrandir le problème. Avant de décider ce que Salesforce doit posséder, je veux comprendre l’entreprise qui l’entoure. Quels systèmes existent déjà ? Où sont créés les clients, définis les produits, lancées les commandes, générées les factures ? Où vit l’identité ? Où se fait l’analytique, où sont gardés les documents, où se trouve l’historique ? Quels systèmes ont besoin des données de Salesforce, et de quels systèmes Salesforce dépend-il ?

Ces questions changent l’architecture. Alors je pars d’une page blanche, je place Salesforce au centre et je dessine tout autour. Le module 4 montre exactement comment je le dispose. Pour l’instant, la leçon est simple : ne concevez pas l’organisation avant de comprendre le monde dans lequel elle doit vivre.

Salesforce n’est souvent pas le système d’enregistrement

Prenez une entreprise très courante : Salesforce plus un ERP, un progiciel de gestion intégré comme SAP ou Oracle, qui gère la finance, les produits, les stocks, les achats et l’exécution des commandes. Posez maintenant une question simple : où vit le client ?

Cela peut être Salesforce, l’ERP, ou les deux, et c’est là que ça devient intéressant. Les commerciaux peuvent travailler des prospects comme comptes dans Salesforce, tandis que l’ERP attribue le numéro client officiel quand ils deviennent clients payants. Les produits et les prix ? Probablement l’ERP. Les stocks ? Presque jamais Salesforce. Les commandes peuvent être saisies dans Salesforce et exécutées dans l’ERP ; les factures viennent de l’ERP ; le service vit dans Salesforce ; l’analytique est partagée entre les rapports Salesforce et un entrepôt de données. Soudain, notre joli modèle de données Salesforce n’est plus le modèle de données de l’entreprise. Il n’en est qu’une partie.

L’intégration que je vois encore et encore

L’intégration la plus courante que je vois ressemble à ceci : les clients, les produits et les prix arrivent dans Salesforce depuis l’ERP, et les commandes repartent. Remplacez par SAP, Oracle ou n’importe quel autre ERP ; la forme est la même. L’ERP possède le golden record du client et du produit, donc ces flux viennent de la droite, vers Salesforce. Les ventes concluent l’affaire dans Salesforce, donc la commande y naît et repart vers l’ERP pour être exécutée, facturée et comptabilisée.

Ces flux ne sont pas seulement des intégrations. Ils me disent où l’entreprise pense que se trouve la vérité.

Les flèches à sens unique me rendent nerveux

Chaque fois que je vois une intégration avec un seul flux, je commence à m’inquiéter. À haut niveau, quelqu’un dessine une seule flèche : les commandes de Salesforce vers l’ERP. Très bien. Maintenant, regardez plus loin. Comment puis-je envoyer une commande à l’ERP si je ne connais pas ses clients, ses produits ou ses prix ? La commande doit être rattachée à un client que l’ERP possède déjà, et chaque ligne doit être un SKU que l’ERP vend déjà. Je ne peux pas envoyer une ligne de commande pour un produit qui n’existe pas de l’autre côté. Donc, avant que cette flèche des commandes puisse fonctionner, des flux de retour doivent exister, dans l’autre sens.

C’est la question que je pose à chaque flèche : de quoi dépend ce flux ? La flèche de haut niveau que vous voyez a généralement besoin de flux de retour que vous n’avez pas encore dessinés.

Regardez encore plus loin et vous trouvez le trajet retour. Salesforce envoie une commande. Et ensuite ? A-t-elle été acceptée ou rejetée ? A-t-elle été expédiée, partiellement expédiée, annulée ? A-t-elle été facturée ? Quelqu’un dans Salesforce a-t-il besoin de le savoir ? Peut-être que non. Mais quelqu’un aurait dû poser la question. Si rien ne revient, très bien. Dites-moi pourquoi.

L’entreprise n’est pas arrivée d’un seul coup

Les paysages se compliquent en partie parce que personne ne les a construits d’un seul coup. Les données sont arrivées par vagues. D’abord les fichiers : des enregistrements à format fixe, puis des fichiers délimités comme le CSV. Puis les bases de données relationnelles pour les données opérationnelles. Puis les entrepôts de données pour tout rassembler à des fins d’analyse. Puis les bases de données NoSQL pour les documents, les paires clé-valeur et les graphes qui ne tiennent pas proprement dans des tables. Puis les lacs de données pour d’énormes quantités de données brutes et semi-structurées, et les lakehouses qui combinent les deux. Les flux d’événements, comme Kafka ou le bus d’événements Salesforce, déplacent les données au moment où elles se produisent plutôt que par lots nocturnes. Et maintenant la fédération, où les données n’ont pas besoin d’être copiées à un seul endroit pour qu’une autre plateforme puisse les utiliser.

La technologie n’est pas encore le sujet. Le sujet, c’est ceci : la nouvelle vague fait rarement disparaître l’ancienne. Entrez dans une grande entreprise et vous les trouverez toutes à la fois : des bases relationnelles, l’ERP, Salesforce, un entrepôt de données, un lac, des dépôts SFTP, des API, des flux d’événements, le tableur que quelqu’un envoie encore par courriel chaque vendredi, et le système auquel tout le monde a peur de toucher parce que la personne qui l’a construit est partie à la retraite il y a six ans. C’est l’entreprise que vous architecturez, pas celle de la brochure produit.

Des systèmes différents existent pour des raisons différentes

C’est aussi pourquoi je ne commence jamais par « comment faire entrer toutes les données dans Salesforce ? » Pourquoi voudrais-je qu’elles y soient toutes ? Salesforce est peut-être le meilleur endroit pour que les équipes commerciales et de service travaillent avec les clients. Cela n’en fait pas le système financier, l’entrepôt de données de l’entreprise, le stockage de télémétrie, l’archive documentaire, ni la maison de chaque clic, chaque relevé GPS et chaque transaction historique que l’entreprise a jamais produits.

Le chapitre 3 demandait où ces données doivent-elles vivre ? pour une organisation. À l’échelle de l’entreprise, la même question grandit : parfois Salesforce possède les données, parfois il en garde une copie, parfois juste une référence, et parfois il ne devrait pas les avoir du tout.

Le cœur, l’extérieur du cœur et Hyperforce

Il y a une autre frontière à comprendre : même « Salesforce » n’est pas un seul environnement d’exécution et une seule base de données. Au chapitre 3, sur le cœur (on core) désignait l’endroit où se trouvent les données : sur votre bureau, dans les objets propres à l’organisation. Ici, les mêmes mots décrivent l’endroit où s’exécute un produit. Vous entendrez les architectes employer les deux.

Historiquement, l’environnement Core hébergeait la plus grande partie de la plateforme. Aujourd’hui, Salesforce décrit une plateforme de centaines de services indépendants pilotés par les métadonnées, Core restant l’unique système d’enregistrement des métadonnées des applications (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), en anglais). C’est pourquoi vous entendrez des architectes dire qu’une fonctionnalité s’exécute sur le cœur (on core) ou hors du cœur (off core).

Cela comptait bien avant que la plateforme ne se divise en services. Quand je demande à une classe pourquoi Salesforce a racheté SteelBrick pour les devis plutôt qu’Apttus, la réponse que j’attends est simple : SteelBrick était construit à 100 % sur le cœur. Les flows et les triggers vivent dans le cœur, donc un produit construit là récupère avec lui les métadonnées, les personnalisations et l’automatisation de la plateforme. Ce produit de devis a depuis cédé la place à Revenue Cloud, mais la leçon demeure. Ensuite, il y a le proche du cœur (near-core), et Data 360 est l’exemple que j’utilise. Data 360 n’est pas le cœur. Son tenant est hors du cœur : les données et les mécanismes qui les traitent s’exécutent dans leur propre lakehouse, à côté de la base de données relationnelle de l’organisation plutôt qu’à l’intérieur (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), en anglais). Mais les écrans que vous utilisez pour le configurer et le piloter s’affichent sur le cœur, dans l’organisation. Donc la façon la plus précise que je connaisse de le dire : géré sur le cœur, hébergé hors du cœur. Aucune des données ni aucun des traitements ne s’exécute réellement dans Core ; l’interface sur Core pilote le tenant hors du cœur. Et puis, bien sûr, il y a tout ce qui est hors du cœur parce que ce n’est pas du tout Salesforce.

Je tiens moins à mémoriser quel produit tourne où cette année, car cela change, qu’à l’habitude : une frontière peut affecter le déplacement des données, la latence, l’identité, l’intégration et la résidence. Alors ne supposez pas que parce qu’un produit porte le nom Salesforce, ses données sont juste à côté de vos enregistrements de compte. Regardez l’architecture réelle.

Ensuite, il y a Hyperforce : l’infrastructure de Salesforce conçue pour le cloud public et définie sous forme de code, plutôt que ses centres de données traditionnels, qui donne aux clients plus de choix sur l’endroit où résident leurs données (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), en anglais). Cela compte, et le module 5 y revient. Mais l’architecture d’infrastructure n’est pas l’architecture de données de l’entreprise. Déplacer une organisation vers le cloud public ne vous dit pas qui possède le client, où vivent les stocks, où s’exécute l’analytique, ni quelles données peuvent franchir une frontière. Hyperforce peut orienter certaines de ces décisions, surtout la résidence. Il ne remplace pas la connaissance du paysage.

Le paysage passe avant la boîte

Voici donc l’habitude. Quelqu’un vous remet un scénario. Ne commencez pas à construire la solution Salesforce. Trouvez d’abord les systèmes : l’ERP, le fournisseur d’identité, l’entrepôt de données, la plateforme d’intégration, les systèmes des partenaires, les canaux clients, les stockages de documents. Puis trouvez les données qui circulent entre eux : clients, produits, commandes, factures, documents, événements, identités. Puis demandez qui possède chacune. Ensuite seulement, décidez de ce qui a sa place dans Salesforce. Sinon, vous concevez une boîte sans savoir à quoi elle se connecte.

Click to enlarge

Étape 1 sur 3 : l’organisation que nous concevons, seule. Vue d’ici, elle ressemble au monde entier.

Click to enlarge

Étape 2 sur 3 : prenez du recul. Salesforce est un système parmi d’autres (le module 4 enseigne cette disposition).

Click to enlarge

Étape 3 sur 3 : les premières flèches. Clients, produits et prix entrants depuis l’ERP, commandes sortantes : elles disent où l’entreprise pense que se trouve la vérité.

Le paysage change le modèle de données

Voici pourquoi cela compte pour un architecte de données. Le chapitre 2 dit que le client est une entité importante. Très bien. Puis le paysage dit que l’ERP fait autorité pour le client. Cela change le modèle physique. Salesforce peut quand même garder un compte local, parce que les gens l’utilisent tous les jours, mais il nous faut maintenant l’identifiant de l’ERP comme ID externe ; savoir quels champs Salesforce peut modifier (je marque les champs de l’ERP avec un préfixe erp_, comme nous le verrons au module 3) ; à quelle vitesse arrivent les changements de l’ERP ; si Salesforce peut créer un client avant que l’ERP le connaisse ; et ce qui se passe quand les deux ne sont pas d’accord. Ce ne sont pas des questions d’intégration pour plus tard. Ce sont des questions d’architecture de données, et le paysage les a mises au jour.

Voici comment l’une d’elles vous mord. Un commercial convertit une piste pour une grande entreprise de boissons, crée le compte, remporte l’affaire, et le client part vers l’ERP. Mais l’entreprise travaille avec ce fabricant de boissons depuis des années, et l’ERP l’a déjà. Maintenant, il y en a deux. Le commercial aurait-il dû pouvoir créer ce compte ? Les chapitres 5 et 6 y reviennent ; c’est sur le paysage que vous le voyez venir.

Ce qu’un architecte décide ici

• Quels systèmes entourent Salesforce, et quel rôle joue chacun.
• Quel système possède chaque type important de données, avant de décider quelle part Salesforce en garde.
• Ce qui entre dans Salesforce, ce qui en sort, et ce qui revient.
• Quelles données Salesforce doit posséder, copier, référencer, fédérer, archiver ou laisser de côté.
• Quelles frontières de plateforme et d’infrastructure comptent, au lieu de supposer que tout ce qui porte la marque Salesforce vit au même endroit.

Passer de développeur à architecte, ce n’est souvent pas apprendre une fonctionnalité de plus. C’est apprendre quand arrêter de regarder Salesforce : reculer la caméra, suivre les données, trouver qui possède la vérité, puis revenir et décider quel doit être le rôle de Salesforce.

Pour aller plus loin

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (en anglais), consulté le 2026-10-14.