Comprendre les données de l'entreprise

🌐 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

Guide d’étude du chapitre 4 du cours Data Architect. Lisez d’abord les six modules ; cette page vous aide à vérifier ce que vous en avez retenu.

À propos de ce guide d’étude. Il est construit uniquement à partir du contenu de ce cours et de la liste des objectifs publiée dans le guide d’examen de Salesforce. Il ne s’appuie jamais sur de vraies questions d’examen et ne prétend pas savoir ce que contient l’examen. Si vous avez passé l’examen, merci de ne pas m’en envoyer les questions : l’accord de certification interdit de les partager, et apprendre des réponses par cœur n’est de toute façon pas la bonne manière de devenir architecte.

Le guide de l’examen indique qu’il ne teste pas les concepts de bases de données hors Salesforce, et l’essentiel de ce chapitre porte sur l’entreprise autour de Salesforce. Alors, comme au chapitre 1, cette liste indique quels objectifs chaque point soutient. Mais ne la sautez pas : beaucoup de scénarios d’examen commencent par un ERP, un entrepôt de données ou une seconde organisation, et la réponse dépend de qui possède les données.

Pour l’examen

Cochez-les au fur et à mesure. Chacun renvoie à l’endroit où il est enseigné.

Qui possède les données (soutient SDM-2, SDM-3 et le chapitre Données maîtres)

• Je sais dire quel système est le système d’enregistrement pour chaque type de données, et je termine la phrase : système d’enregistrement de quoi ? (Salesforce n’est souvent pas le système d’enregistrement, Ne commencez pas par le nom du produit)
• Je connais le schéma courant : les clients, les produits et les prix arrivent de l’ERP, les commandes repartent, et je sais que la flèche des commandes dépend des autres ; ensuite, je pose la question du trajet de retour. (L’intégration que je vois encore et encore, Les flèches à sens unique me rendent nerveux)
• Je pose trois questions aux données maîtres : où sont-elles créées, où sont-elles modifiées, et où sont-elles référencées ? (Les quatre questions derrière les catégories)
• Je sais qu’une copie n’est pas une autorité : les données possédées par l’ERP sont lues localement et écrites sous contrôle, avec leur identifiant ERP gardé comme ID externe. (L’ERP : le back-office a de la gravité, Le paysage change le modèle de données)

Les types de données et leurs charges de travail (soutient DM-1, LDV-1 et MDM-4)

• Je sais distinguer les données maîtres, de référence, transactionnelles, métadonnées, analytiques et non structurées, et ce que chacune implique pour l’endroit où elle vit. (Commencez par le type, pas par l’objet)
• Je sais que les données de référence sont petites mais que c’est là que se cachent les hypothèses d’intégration (Delivered, Complete, D). (Les données de référence)
• Je sais distinguer les charges de travail opérationnelles (OLTP), analytiques (OLAP) et en flux : l’organisation fait tourner l’entreprise, les entrepôts et les lacs l’analysent. (Le type n’est que la moitié de la question : la charge de travail)
• Je distingue le synchrone (attendre à la porte), l’asynchrone (continuer, s’en occuper au retour) et le traitement par lots (toutes les heures, toutes les quelques heures, chaque jour), je sais quand le traitement par lots suffit, et je sais que le temps réel a un coût. (À quelle vitesse doivent-elles circuler ?)
• Je pose les quatre questions à chaque jeu de données : qui le possède, à quelle vitesse il change, quelle taille il atteint, et son cycle de vie. (Les quatre questions derrière les catégories)

Les systèmes autour de Salesforce (soutient SDM-3, LDV-3 et les chapitres sur l’intégration)

• Je connais les quatre rôles des systèmes : enregistrement, engagement, référence et analyse. (Ne commencez pas par le nom du produit)
• Je sais que l’endroit où vit l’analytique suit l’endroit où vivent les données : les rapports du cœur quand tout est dans Salesforce ; une plateforme d’analytique (Tableau, y compris Tableau Next, ou CRM Analytics là où il est utilisé) ou l’entrepôt de données quand d’autres stockages entrent en jeu. (L’analytique vit là où vivent les données)
• Je sais ce que sont un entrepôt de données, un lac et un lakehouse, et le rôle du MDM, d’un ESB ou iPaaS, et des événements. (L’entrepôt, le lac et le lakehouse, La couche d’intégration et les événements)
• Je place le fournisseur d’identité sur le paysage dès le premier jour, et je sais que la configuration SSO se déploie mais que les secrets et les certificats ne voyagent pas ; sur le paysage, c’est un certificat partagé (la confiance), pas un appel, car l’authentification passe par le navigateur. (Le système que les développeurs oublient : l’identité)
• Je sais que Data 360 est proche du cœur (near-core) (géré sur le cœur, hébergé hors du cœur), et que son zéro copie permet d’interroger des données sans les copier. (Où se place Data 360 ?, Le cœur, l’extérieur du cœur et Hyperforce)

Organisations et hébergement (soutient SDM-4)

• Je commence avec une seule organisation et je cherche une vraie frontière (résidence, réglementation, séparation juridique, modèle opérationnel différent, acquisition) avant d’en ajouter une autre. (Commencez avec une seule organisation, Cherchez les vraies frontières)
• Je sais ce que coûtent plusieurs organisations : rapports mondiaux, données maîtres, intégration, identité et déploiements, chacun multiplié. (Parcourez de nouveau les flèches)
• Je sais qu’Hyperforce permet de choisir la région où résident les données d’une organisation (pas le fournisseur de cloud), mais ne promet pas que chaque service y reste ; et que le RGPD n’exige pas à lui seul une organisation séparée : il fixe des règles pour les données personnelles qui quittent l’UE, et une entreprise peut choisir une organisation européenne pour les respecter. (L’hébergement fait partie du dessin, Quand l’Europe a sa propre organisation)

Dessiner et lire un paysage (soutient chaque scénario)

• Je sais dessiner un paysage : les personnes à gauche, Salesforce au centre avec ses communautés qui le touchent par en dessous, l’identité au-dessus, l’intégration et le back-office à droite, Data 360 sous la couche d’intégration, les canaux en dessous, les données entrantes et sortantes en bas à droite. (La disposition de paysage de Steve)
• Sur un paysage, une flèche part du système qui ouvre la connexion et son étiquette dit ce qui circule et dans quel sens ; sur un diagramme de flux de données, les flèches suivent les données. Deux flux, ce sont deux flèches. (Maintenant, dessinez les flèches)
• Pour chaque flèche, je sais ce que gère le client et ce que définit le serveur : où, authentification, protocole et contrat, charge utile, rythme, traçabilité, erreurs. Une information d’identification nommée (Named Credential) et son information d’identification externe (External Credential) quand Salesforce appelle vers l’extérieur ; une application client externe (External Client App) et un utilisateur d’intégration API uniquement quand quelque chose appelle Salesforce. (Chaque flèche a besoin d’un mécanisme)
• Je compte avant de dessiner les flèches : le volume va dans l’inventaire et détermine le mécanisme, et il peut même changer le sens de la flèche. (Mettez les zéros dans l’inventaire)
• Je ne dessine un couloir (swim lane) que lorsqu’un processus comporte plus d’un ou deux allers-retours. (Des flèches sur le paysage, les conversations dans un couloir)

Au-delà de l’examen

L’examen est le plancher, pas le plafond. Voici les habitudes de ce chapitre dont un architecte a besoin, qu’une question les aborde ou non.

• Dessinez le paysage avant de concevoir l’organisation. Partez d’une page blanche.
• Reculez la caméra. Salesforce est un système parmi d’autres.
• La nouvelle vague fait rarement disparaître l’ancienne. Architecturez l’entreprise qui existe, pas la brochure.
• Lisez le paysage comme des responsabilités, pas comme des logos.
• Les flèches à sens unique me rendent nerveux. De quoi dépend ce flux, et qu’est-ce qui revient ?
• Chaque flèche a besoin d’un mécanisme. « Fire and forget » n’est pas une réponse.
• Les flèches sur le paysage, les conversations dans un couloir.
• Comptez avant de dessiner les flèches. Les zéros vont dans l’inventaire, et ce sont eux qui choisissent le mécanisme.
• Dessinez l’état actuel avant de le corriger : le tableur, le dépôt SFTP, le système « que nous retirons ».
• Marquez honnêtement un état actuel : du rouge pour un mauvais processus, des pointillés pour ce qui se fait à la main, des points rouges pour ce qui manque. Chaque ligne rouge est une exigence qui attend d’être écrite.
• Deux flux, deux flèches. Une flèche à double pointe est réservée à un connecteur.
• Ne jouez pas à l’avocat. Demandez quelle exigence précise vous satisfaites, et traduisez-la avec ceux qui la possèdent.
• Séparé ne veut pas dire simple.

Les mots à connaître

Terme	En une ligne
Paysage des systèmes	Les systèmes autour de Salesforce, les personnes qui les utilisent, et les flux importants entre eux
Système d’enregistrement	Là où est gardée la version qui fait autorité d’un type de données
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	Là où les données se rejoignent pour mesurer, analyser et prédire
ERP	Le système de back-office pour la finance, les produits, les stocks, les achats et l’exécution des commandes
Données maîtres	Les éléments durables autour desquels une entreprise fonctionne : clients, produits, sites
Données de référence	Le vocabulaire partagé qui classe d’autres données : codes, statuts, catégories
Données transactionnelles	Les traces de ce qui s’est passé : commandes, livraisons, paiements, requêtes
Données analytiques	Des données dérivées d’autres données pour mesurer et comparer
Données non structurées	Documents, images, audio, vidéo, transcriptions
Entrepôt de données / lac / lakehouse	Stockage analytique structuré / stockage brut à grande échelle / un mélange des deux
ESB / iPaaS	Une couche d’intégration qui sert d’intermédiaire entre les systèmes
OLTP / OLAP	Le travail opérationnel sur quelques enregistrements à la fois / l’analyse sur un grand nombre
Proche du cœur (near-core)	Géré sur le cœur, hébergé hors du cœur : Data 360
Information d’identification nommée / externe (Named Credential / External Credential)	L’endroit où Salesforce conserve un point de terminaison sortant / son authentification
Application client externe (External Client App)	La façon dont un système extérieur est autorisé à appeler Salesforce
État actuel	Le paysage tel qu’il est aujourd’hui, avant la conception ; annoté avec ce qui ne va pas
Fournisseur d’identité (IdP)	Le système qui authentifie les utilisateurs et établit l’identité à laquelle Salesforce fait confiance
Synchrone / asynchrone / par lots	Attendre la réponse / continuer et la traiter quand elle arrive / déplacer les données en groupe selon un calendrier
Hyperforce	Salesforce sur une infrastructure de cloud public, avec le choix de la région
Zéro copie	Interroger les données là où elles vivent, sans les copier

Testez-vous

De courts scénarios dans le style du cours. Décidez de votre réponse avant de l’ouvrir.

1. Les commerciaux travaillent les comptes dans Salesforce, mais l'ERP attribue le numéro client officiel dès qu'ils achètent. Salesforce envoie les commandes à l'ERP. Que devez-vous concevoir ?

Qui possède le client à chaque étape ; le numéro de l’ERP comme ID externe sur le compte ; quels champs Salesforce peut modifier ; à quelle vitesse arrivent les changements de l’ERP ; et ce qui revient après l’envoi d’une commande (acceptée, rejetée, expédiée, facturée). Relisez Le paysage change le modèle de données.

2. La direction veut cinq ans de ponctualité par région, joints à la finance. Faut-il le construire en rapports Salesforce ?

Probablement pas. C’est une charge analytique sur plusieurs stockages, elle a donc sa place là où les données se rejoignent : l’entrepôt de données, avec CRM Analytics ou Tableau par-dessus. L’analytique vit là où vivent les données. Relisez L’analytique vit là où vivent les données.

3. Une entreprise présente dans 30 pays demande une organisation par pays. Que demandez-vous ?

Quelle exigence vient avec chaque pays : stockage, traitement, transfert transfrontalier, contrats, un autre hébergeur. Sans vraie frontière, commencez avec une seule organisation, car chaque organisation supplémentaire multiplie les rapports, les données maîtres, l’intégration, l’identité et les déploiements. Relisez La géographie n’est pas automatiquement une stratégie d’organisation.

4. Les camions envoient 200 000 relevés GPS par jour. Salesforce doit-il tous les stocker ?

Probablement pas. Ce sont des données en flux : le répartiteur a besoin de la position actuelle, tandis que l’historique et les tendances ont leur place sur une plateforme conçue pour ce volume. Comptez les zéros (plus de 70 millions par an) et séparez « où est-il maintenant ? » de « que s’est-il passé le trimestre dernier ? ». Relisez Le type n’est que la moitié de la question.

5. Les équipes travaillent leurs arrêts dans Salesforce, mais les tournées sont construites dans un ancien outil de répartition, et rien ne relie les deux. Comment dessinez-vous l'existant ?

Tel quel, annoté comme un état actuel : les tournées ressaisies dans Salesforce et les arrêts terminés ressaisis en retour, en pointillés parce que ce sont des personnes qui le font, et en rouge parce que c’est mauvais. Ne dessinez pas l’intégration que vous aimeriez avoir ; chaque ligne rouge devient une exigence pour la conception. Relisez Marquez ce qui ne va pas et RouteDesk est toujours là.

6. Quelqu'un dit que le droit européen de la protection des données exige une organisation séparée. Comment répondez-vous ?

Ni accepter aveuglément ni passer outre. Le RGPD n’exige pas à lui seul une organisation séparée ; il fixe des règles pour les données personnelles, y compris leurs transferts hors de l’UE. Demandez quelle exigence précise cela satisfait (stockage, traitement, transfert, accès du support, un contrat, une politique), puis travaillez avec les équipes protection des données, juridique et sécurité pour la traduire en architecture. Relisez Ne jouez pas à l’avocat et Quand l’Europe a sa propre organisation.

7. Salesforce envoie les commandes à l'API de l'ERP. Quel côté gère les nouvelles tentatives, et où Salesforce conserve-t-il le secret ?

Salesforce est le client : il ouvre la connexion, voit l’aller-retour complet et c’est le seul côté qui peut réessayer. Une information d’identification nommée (Named Credential) contient le point de terminaison, et son information d’identification externe (External Credential) l’authentification. L’ERP, le serveur, définit le contrat et valide ce qui arrive. Relisez Chaque flèche a besoin d’un mécanisme.

8. Une intégration envoie aujourd'hui quelques enregistrements par minute, et l'entreprise en attend des dizaines de milliers par heure l'an prochain. La flèche change-t-elle ?

Peut-être son mécanisme, et même son sens. Quelques enregistrements par minute peuvent passer par un appel sortant depuis Salesforce ; beaucoup plus peut signifier publier des événements auxquels l’autre système s’abonne, et la flèche part alors de l’autre bout ; des millions pendant la nuit, c’est un traitement par lots. Connaissez les volumes avant de choisir. Relisez Mettez les zéros dans l’inventaire.

Pour aller plus loin

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-09-25) : la liste officielle des objectifs et de leurs pondérations. Vérifiez toujours la version actuelle avant de réserver l’examen.