Penser comme un architecte 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)
Guide d’étude du chapitre 1 du cours Data Architect. Lisez d’abord les sept 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.
Ce chapitre contient peu de faits d’examen, et c’est voulu. Il porte sur la façon de penser d’un architecte, et aucun objectif d’examen ne lui appartient en propre. Mais l’examen est construit à partir de scénarios : une entreprise, quelques chiffres, une contrainte, et plusieurs réponses qui pourraient fonctionner. Les habitudes de ce chapitre sont la façon de lire ces scénarios. La liste ci-dessous indique donc quel objectif chaque point soutient, plutôt que de prétendre qu’il est testé directement.
Pour l’examen
Section intitulée « Pour l’examen »Cochez-les au fur et à mesure. Chacun renvoie à l’endroit où il est enseigné.
Lire un scénario comme un architecte (soutient tous les objectifs)
- Je sépare la vraie exigence de la conception sous laquelle elle est arrivée (« il nous faut des champs Approbateur 2 et Approbateur 3 » contre « il nous faut suivre chaque approbation »). (Ne vous contentez pas de prendre l’exigence)
- Je cherche les exigences implicites que personne n’a formulées : propriété, fraîcheur, échec, conservation, accès. (Cherchez les exigences implicites)
- Je mets des chiffres : volume par jour, par an, avec la croissance, et je remarque quand un zéro de plus change la réponse. (Connaissez vos chiffres)
- Parmi plusieurs réponses qui fonctionnent, je compare ce que chacune gagne et sacrifie au regard des exigences et des contraintes énoncées. (Sachez à quoi vous renoncez, Les contraintes changent la réponse)
- Je traite le coût, les licences et les limites comme faisant partie de l’adéquation d’un outil, pas comme un détail de fin. (Les neuf questions)
Le modèle de données (soutient DM-1)
- Je sais juger un modèle selon qu’il soutient le métier, peut grandir avec lui et performe. (Soutenir. Grandir. Performer.)
- Je sais repérer un modèle trop plat (Champ 1, Champ 2, Champ 3), sur-normalisé, ou construit sur le mauvais objet standard. (Trop plat, trop compliqué, ou simplement faux)
- Je sais pourquoi une liste de sélection convient à une liste courte et stable, et une relation de référence à une liste qui continue de grandir ou qui arrive par une intégration. (De nombreuses façons de résoudre le problème)
- Je sais qu’une clé porteuse de sens (une partie d’un nom, par exemple) casse quand ce sens change. (Certaines décisions coûtent peu à changer)
Changer ce qui existe déjà (soutient DM-1 et SDM-2)
- Je sais pourquoi changer le type d’un champ, ou rendre un champ existant obligatoire, peut casser des choses plus tard, et pourquoi la plateforme bloque un changement de type tant que du code ou des flows référencent le champ. (Prudence avant de changer l’ossature)
- Je connais le principe ajouter plutôt que modifier, déprécier plutôt que surprendre, et je sais que Field Usage peut marquer un champ comme candidat à l’abandon. (Prudence avant de changer l’ossature)
- Je connais les faits sur principal-détails derrière le test de réversibilité : l’accès et la propriété du détail suivent le principal, supprimer un principal supprime ses détails, les récapitulatifs de cumul exigent une relation principal-détails, et une relation de référence ne se convertit en principal-détails que si chaque enregistrement a une valeur. (Le test de réversibilité, Pour aller plus loin)
Licences et partage (soutient SDM-1)
- Je sais que les utilisateurs de communauté à volume élevé (dont Customer Community) n’ont pas de rôle et n’utilisent pas le modèle de partage, donc leur accès vient des ensembles de partage et des groupes de partage, et le partage Apex ne peut pas les atteindre. (Un exemple concret : le partage Apex)
L’échec (soutient MIG-1 et les chapitres sur l’intégration)
- Je sais que « tâche terminée » n’est pas la même chose que les données sont correctes, et comment le rapprochement retrouve les enregistrements qui ne sont pas passés. (Une réussite partielle reste un échec à comprendre)
Au-delà de l’examen
Section intitulée « 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.
- Quelqu’un doit tenir le plan. L’architecture, c’est prendre de bonnes décisions avec des informations incomplètes, et en connaître les conséquences.
- Le modèle de données est l’ossature. Tout le reste est construit dessus.
- Le test de réversibilité : à quel point est-ce difficile à défaire, et combien de choses vont en dépendre ?
- L’architecture crée de la gravité. Ce sont les dépendances qui rendent le changement coûteux, pas le changement lui-même.
- Pensez au rayon d’impact, dans Salesforce et dans toute l’entreprise. L’architecture est une circulation à double sens.
- Écrivez pourquoi : contexte, options, décision, conséquences, responsable, révision. Remplacez ; n’effacez pas.
- La meilleure pour quoi ? Une décision sous-optimale peut faire partie d’une architecture optimale, si vous savez que vous la prenez.
- Gardez en tête une image de l’optimal, pour savoir dans quelle direction vous vous en éloignez, et pourquoi.
- Penser juste. Penser vite. La vitesse vient de la réflexion faite avant le moment.
- Construire pour aujourd’hui. Prévoir demain. Prévoir l’échec. Et utilisez 30 % de croissance quand personne ne vous donne de chiffre.
- Apprenez les neuf questions, pas seulement les réponses.
- L’IA est un propulseur de fusée. Générer n’est pas juger, l’irréversible reste irréversible, et la revue humaine n’est pas une cérémonie. Faire confiance, mais vérifier.
Les mots à connaître
Section intitulée « Les mots à connaître »| Terme | En une ligne |
|---|---|
| Décision d’architecture | Une décision difficile à défaire, dont beaucoup de choses dépendent |
| Test de réversibilité | À quel point est-ce difficile à défaire, et combien de choses vont en dépendre ? |
| Gravité | Les dépendances qui s’accumulent autour d’une décision avec le temps |
| Rayon d’impact | Tout ce qui bouge d’autre quand une décision change |
| Registre de décision | Contexte, options, décision, conséquences, responsable et point de révision, en version courte |
| Compromis | Ce qu’une option gagne, et ce qu’elle sacrifie pour l’obtenir |
| Exigence implicite | Ce que le métier attend sans le demander, comme la reprise quand un chargement échoue |
| Le Nombre de Zéros de Steve | Un zéro de plus dans le volume peut changer toute l’architecture |
| Rapprochement | Comparer ce qui aurait dû se passer avec ce qui s’est passé, enregistrement par enregistrement |
| Déprécier | Signaler qu’une chose est en voie de disparition, puis la retirer délibérément, au lieu de la modifier sur place |
| Utilisateur à volume élevé | Un utilisateur de communauté (dont Customer Community parmi les licences) sans rôle, hors du modèle de partage |
| Prolifération du schéma | Des objets et des champs qui s’accumulent parce qu’ils coûtaient peu à créer, jusqu’à ce que personne n’ait conçu le modèle |
Testez-vous
Section intitulée « Testez-vous »De courts scénarios dans le style du cours. Décidez de votre réponse avant de l’ouvrir.
1. Une équipe commerciale demande des champs Approbateur 2 et Approbateur 3, chacun avec une date, sur l'opportunité. Que demandez-vous, et que pourriez-vous construire ?
Demandez pourquoi, et combien d’approbations il peut y avoir. S’il peut y en avoir plus de deux ou trois, l’exigence est de suivre chaque approbation, pas d’ajouter des champs : un objet enfant, un enregistrement par approbation. Relisez Ne vous contentez pas de prendre l’exigence.
2. Quelqu'un veut renommer l'étiquette d'un champ, et quelqu'un d'autre veut changer le format de l'identifiant client que cinq systèmes stockent déjà. Lequel mérite le plus votre attention, et pourquoi ?
L’identifiant. L’étiquette coûte peu à changer. L’identifiant échoue au test de réversibilité : difficile à défaire, et beaucoup de choses en dépendent déjà. Proportionnez votre attention au coût de l’erreur. Relisez Certaines décisions coûtent peu à changer.
3. Un champ texte est utilisé depuis des années. Le métier veut maintenant qu'il contienne un nombre. Quelle est votre approche ?
Ne le modifiez pas sur place. Trouvez ce qui en dépend (flows, Apex, rapports, intégrations, agents) et ce qui arrive aux anciennes données. En général : ajoutez un nouveau champ, migrez délibérément, et dépréciez l’ancien. Relisez Prudence avant de changer l’ossature.
4. 1 200 sites, 100 rendez-vous par site et par jour, environ 305 jours par an, deux enregistrements par rendez-vous, cinq ans conservés, 30 % de croissance. Combien d'enregistrements, en gros, et pourquoi est-ce important ?
Environ 73 millions d’enregistrements la première année (36,6 millions de rendez-vous, deux enregistrements chacun), et plus de 650 millions sur cinq ans avec la croissance. Même fonctionnalité, deux zéros de plus, une architecture très différente. Relisez Connaissez vos chiffres.
5. Un chargement de nuit indique « terminé » sur un million d'enregistrements. Comment savez-vous qu'il a fonctionné ?
Vous faites un rapprochement. Le côté qui reçoit confirme chaque enregistrement enregistré ; l’expéditeur compare ce qu’il a envoyé avec ce qui a été confirmé. Des confirmations manquantes signifient que ça n’a pas fonctionné, quoi qu’en dise le statut de la tâche, et vous indiquent quels enregistrements réessayer, confier à une personne, ou signaler par une alerte. Relisez Une réussite partielle reste un échec à comprendre.
6. Une communauté de 15 millions d'utilisateurs Customer Community a besoin d'un accès complexe aux enregistrements. Quelqu'un propose le partage Apex. Quel est le problème ?
Ce sont des utilisateurs à volume élevé : pas de rôle, hors du modèle de partage, donc il n’y a aucun enregistrement de partage qu’Apex pourrait écrire. L’accès vient des ensembles de partage et des groupes de partage. La licence a décidé quels outils de partage existent. Relisez Un exemple concret : le partage Apex.
7. Un outil d'IA génère vingt objets pour une nouvelle application en quelques minutes. Quel est maintenant le travail de l'architecte ?
Décider si nous devrions en avoir cinq. Comprendre le modèle assez bien pour le défendre : pourquoi ces objets et ces relations, où sont les clés et les données de référence, ce qui se passe à grande échelle. Vérifier les faits sur lesquels il s’est appuyé. Générer n’est pas juger. Relisez Une mise en œuvre bon marché déplace la valeur.
Pour aller plus loin
Section intitulée « 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.