Les systèmes autour de 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 3 sur 6 du chapitre Comprendre les données de l’entreprise, chapitre 4 du cours Data Architect. Chaque module est autonome. Précédent : Les types de données de l’entreprise · Suivant : Dessiner le paysage des systèmes

La question à laquelle répond ce module : qu’est-ce qui entoure Salesforce, et quel rôle joue chaque système ?

Le module précédent a trié les données. Maintenant, je veux les placer quelque part, et c’est là que les architectes Salesforce ont des ennuis. Nous connaissons Salesforce, donc les données clients veulent dire compte, les données de commande veulent dire commande, les documents veulent dire fichiers, l’analytique veut dire rapports. Mais l’entreprise n’a pas acheté Salesforce pour remplacer tout ce qu’elle possède d’autre. Il peut y avoir un ERP qui gère la finance et l’exécution des commandes, un entrepôt de données avec des années d’historique, une plateforme d’intégration, un fournisseur d’identité, des systèmes de partenaires, une plateforme d’événements, une plateforme MDM, et Data 360 qui en relie plusieurs. Le travail n’est pas de mémoriser des technologies. C’est de comprendre quel est le travail de chaque système.

Ne commencez pas par le nom du produit

« Nous avons SAP » ne m’en dit pas assez. Snowflake, MuleSoft, Tableau ou Data 360 non plus. Je veux savoir ce que fait ce système dans cette architecture : quelles données il possède, ce qu’il lit, ce qu’il modifie, qui l’utilise, ce qui dépend de lui, ce qui se passe quand il est en panne. Deux entreprises peuvent posséder exactement les mêmes produits et avoir des architectures complètement différentes.

Alors j’étiquette les systèmes par rôle. Quatre rôles couvrent l’essentiel :

• Système d’enregistrement (system of record) : là où la version qui fait autorité de quelque chose est maintenue.
• Système d’engagement : là où les gens font le travail.
• Système de référence : là où un système va chercher une information dont il a besoin mais qu’il ne possède pas.
• Système d’analyse (system of insight) : là où les données se rejoignent pour mesurer, analyser et prédire.

Une plateforme peut jouer plusieurs rôles, et les rôles varient selon les données. Salesforce peut être le système d’enregistrement des requêtes, le système d’engagement des agents de service, et un consommateur des données produit que possède l’ERP. Alors quand quelqu’un dit « Salesforce est notre système d’enregistrement », terminez la phrase : système d’enregistrement de quoi ?

L’ERP : le back-office a de la gravité

L’ERP est le système que vous trouverez le plus souvent à côté de Salesforce, pour la finance, les stocks, les achats, l’exécution des commandes et la facturation. Le schéma du module 1 (clients et produits en entrée, commandes en sortie) signifie que l’ERP possède les produits, mais que les commerciaux en ont quand même besoin dans Salesforce. Très bien : faites-les entrer. Mais copier des données ne transfère pas la propriété. Une copie n’est pas une autorité.

Ma position : les données possédées par l’ERP sont lues localement et écrites sous contrôle. Les utilisateurs Salesforce ont les données là où ils travaillent, mais Salesforce n’a pas le droit de modifier ce que possède l’ERP. Et je le rends visible dans le schéma : les champs de l’ERP portent un préfixe erp_, comme erp_Product_Number__c, pour que quiconque lit l’objet sache qui possède chaque champ et fasse attention avant de le modifier. Le préfixe n’impose rien ; ce sont les autorisations, la validation et le modèle d’intégration qui le font. Il communique une intention, et c’est la carte des autorités rendue visible.

L’entrepôt, le lac et le lakehouse

Les systèmes opérationnels font tourner l’entreprise ; les systèmes analytiques aident à la comprendre. « Montre-moi mes opportunités ouvertes » est un rapport Salesforce. « Montre-moi cinq ans de ventes, d’exécution, de retours, de requêtes, de stocks et de finance sur tous les canaux » est un autre problème.

Vous rencontrerez trois types de stockage analytique. Un entrepôt de données (data warehouse) contient des données structurées préparées pour l’analyse. Un lac de données (data lake) contient bien plus de données sous plus de formes, souvent brutes. Un lakehouse combine les deux : un stockage à la manière d’un lac avec une analyse à la manière d’un entrepôt. Connaissez-les, car ils apparaissent sur les paysages. Mais mon expérience, c’est que les lakehouses et le data mesh restent marginaux dans les projets Salesforce. Le paysage typique, c’est un CRM, un ERP, un entrepôt de données et une couche d’intégration, avec d’autres plateformes là où le métier en a vraiment besoin. Apprenez l’architecture ; ne courez pas après le vocabulaire.

L’analytique vit là où vivent les données

C’est l’une de mes positions les plus fermes : l’analytique vit là où vivent les données. Si le rapport n’a besoin que des comptes, des opportunités et des commerciaux, tout est sur le cœur : rapports et tableaux de bord standard. Puis le métier demande d’ajouter les factures de l’ERP. Puis le coût des produits. Puis cinq ans de commandes depuis l’entrepôt de données. Puis l’activité du site web. À un moment donné, traîner tout cela dans le CRM opérationnel juste pour faire des rapports n’a plus de sens. Dès que d’autres stockages de données entrent en jeu, une plateforme d’analytique devient nécessaire : Tableau (y compris Tableau Next, construit sur Data 360), ou CRM Analytics là où il est déjà utilisé. Elle est indispensable quand les données Salesforce sont fusionnées avec un entrepôt de données. L’exigence ne s’est pas seulement compliquée ; le paysage a changé l’endroit où la question doit trouver sa réponse. Alors je ne commence jamais par « quel outil d’analytique ? » Je commence par où sont les données ?

Je pose la même question aux candidats CTA : « Lequel de mes diagrammes résout cela magnifiquement ? Le paysage. » Si vous êtes entièrement sur le cœur, utilisez les rapports. Si vous avez des données dans d’autres référentiels, je veux voir une plateforme d’analytique. Le paysage répond à la question des rapports avant que quiconque n’ouvre un générateur de rapports. (Les noms de produits changent ; le chapitre Data 360 couvre l’état actuel de l’analytique chez Salesforce.)

Le MDM : qui est vraiment ce client ?

Supposez maintenant que les informations client vivent dans Salesforce, l’ERP, le commerce électronique, une plateforme de fidélité et un système partenaire, et que chacun pense savoir qui est le client. C’est là qu’intervient la gestion des données maîtres (MDM) : établir et gouverner l’identité qui fait autorité pour les données clés à travers les systèmes. Mais le MDM n’est pas « une base clients maîtresse ». Les questions difficiles sont : quel système peut créer le client, quels attributs chaque système possède, comment on trouve les doublons, quel identifiant survit, et ce qui se passe quand les systèmes ne sont pas d’accord. Le chapitre 6 porte entièrement là-dessus. Ici, reconnaissez le rôle : s’il existe une plateforme MDM, elle peut être une autorité essentielle entre Salesforce et le reste de l’entreprise.

La couche d’intégration et les événements

Connectez chaque système directement à tous les autres, et le paysage tourne vite au plat de spaghettis. C’est pourquoi les entreprises ont une couche d’intégration : un ESB (bus de services d’entreprise) ou un iPaaS (plateforme d’intégration en tant que service). MuleSoft est celui que vous rencontrerez le plus dans les paysages Salesforce. Il sert d’intermédiaire, pour que chaque application n’ait pas à comprendre toutes les autres.

Mais une boîte MuleSoft au milieu ne rend pas l’intégration bonne. Je veux toujours savoir ce qui passe par elle et ce qui n’y passe pas, qui transforme les données, qui possède le contrat, ce qui se passe quand la destination est en panne, si c’est synchrone ou asynchrone, et comment on sait qu’un message a réussi. Le cours Integration Architect va en profondeur ; ici, reconnaissez-la comme un rôle à part entière.

Et toutes les intégrations ne sont pas un système A qui appelle un système B. Parfois, quelque chose se produit (une commande est créée, une livraison change de statut, un camion entre dans une région), un événement est publié, et ceux que cela intéresse réagissent. Les événements en mouvement ont aussi leur infrastructure : les capacités d’événements propres à Salesforce, un bus d’événements d’entreprise, d’autres messageries. Dessinez les mécanismes qui transportent les données, pas seulement les bases de données.

Le système que les développeurs oublient : l’identité

Il y a une boîte que je veux toujours sur le paysage et à laquelle les développeurs pensent rarement : le fournisseur d’identité. Les développeurs se connectent directement à leurs sandboxes avec un nom d’utilisateur et un mot de passe, donc l’identité est invisible pendant la construction. Puis arrivent l’UAT ou la production, et soudain il y a l’authentification unique de l’entreprise pour les employés, peut-être un second fournisseur pour les partenaires, la connexion par réseaux sociaux pour les clients. L’identité a toujours fait partie de l’architecture. Le développeur ne la voyait simplement pas encore.

Un fournisseur d’identité (IdP) est le système qui authentifie un utilisateur et établit l’identité à laquelle Salesforce fait confiance. Il a sa place sur le paysage dès le premier jour, même s’il est configuré plus tard dans le pipeline de livraison, car qui peut entrer décide de qui peut accéder aux données.

Il y a aussi une subtilité pratique : la configuration de l’identité est déployable, mais pas entièrement. La configuration de l’authentification unique SAML et les fournisseurs d’authentification sont des types de la Metadata API, ils passent donc par le pipeline (SamlSsoConfig (opens in a new tab), en anglais). Mais les secrets client des fournisseurs d’authentification ne sont plus renvoyés dans les réponses de la Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), en anglais), et les certificats diffèrent généralement d’un environnement à l’autre. Prévoyez les parties qui voyagent et celles qui ne voyagent pas.

Click to enlarge

Lisez le paysage comme des rôles, pas comme des logos : ce que chaque système possède, lit ou décide.

Où se place Data 360 ?

Data 360 pose une jolie question de dessin. Je le place à droite, sous l’ESB ou MuleSoft. La raison, ce sont ses connexions : les utilisateurs ne s’y connectent jamais directement, alors que lui se connecte directement à de nombreux systèmes back-end. Il a donc sa place avec la tuyauterie des données, là où ces lignes restent courtes, pas dehors avec les utilisateurs. Dessinez-le comme un écran de plus où les gens se connectent, et vous racontez la mauvaise histoire.

Les administrateurs et les équipes de données ouvrent bien les écrans de Data 360, mais ces écrans sont dans l’organisation, sur le cœur. Le tenant qui fait le travail, ses données et ses traitements, s’exécute hors du cœur. C’est pourquoi je l’appelle proche du cœur (near-core) : géré sur le cœur, hébergé hors du cœur (le module 1 explique ces termes). Le dessin suit le tenant : il se place avec la tuyauterie, avec une ligne qui le relie à l’organisation qui le gère.

Ce qu’il fait, selon les mots de Salesforce, inclut le zéro copie (zero copy) : une technologie de fédération de données qui permet à une entreprise d’accéder aux données et de les interroger sans les copier (Zero Copy (opens in a new tab), en anglais). Les capacités et les connecteurs évoluent vite, alors le chapitre Data 360 les traite correctement au lieu de transformer ce module en visite guidée des produits.

Lisez le paysage comme des responsabilités

Quand vous regardez un paysage, ne lisez pas les logos ; lisez les responsabilités. L’ERP : que possède-t-il ? L’entrepôt de données : à quelles questions répond-il ? La plateforme d’intégration : que déplace-t-elle ? L’IdP : qui authentifie-t-il ? Le MDM : quelle identité gouverne-t-il ? Data 360 : que relie-t-il, et pour quoi faire ? Salesforce : de quoi est-il réellement responsable ? Une fois que vous savez répondre, les boîtes veulent dire quelque chose, et les flèches entre elles deviennent bien plus intéressantes. Ensuite, nous les dessinons délibérément.

Ce qu’un architecte décide ici

• Quel rôle joue chaque système, au-delà du nom de son produit.
• Quel système fait autorité pour chaque jeu de données important, et où Salesforce n’en garde qu’une copie locale.
• Si les données possédées par l’ERP sont disponibles dans Salesforce avec des écritures contrôlées, et comment cette propriété se voit dans le schéma.
• Où l’analytique a sa place, selon l’endroit où vivent les données.
• Où se placent l’identité, l’intégration, les événements et l’autorité sur les données maîtres dans le paysage.

Un paysage de dix rectangles n’est pas une architecture ; c’est un inventaire. L’architecture commence quand vous pouvez montrer chaque rectangle et dire pourquoi il est là, ce qu’il possède, qui l’utilise, ce dont Salesforce a besoin de lui, et ce qui casse si vous comprenez mal son rôle.

Pour aller plus loin

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, notes de version Winter ‘23, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (page produit, en anglais), consulté le 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab) (en anglais), martinfowler.com, 2019.