Dessiner le paysage avant l'organisation

🌐 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)

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Chapitre 4 de Data Architect, Partie 1 : Devenir architecte de données. Précédent : L’architecture de données Salesforce.

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, et seulement ensuite, faites un premier essai de modèle de données.

L’ordre surprend les gens. Nous sommes architectes de données ; ne devrions-nous pas commencer par le modèle de données ? Voici pourquoi je ne le fais pas. Si je dessine d’abord le modèle de données, j’ai déjà décidé de ce qui a sa place dans Salesforce. Si je dessine d’abord le paysage, je vois tout ce qui doit orienter cette décision : l’ERP qui possède les clients et les produits, l’entrepôt de données qui répond aux questions sur cinq ans, le fournisseur d’identité qui décide qui entre, le partenaire qui envoie un fichier chaque après-midi, le système hérité dont tout le monde dit qu’il va être retiré.

Les chapitres 2 et 3 ont conçu l’organisation : ce que le modèle doit être, et comment il vit sur Salesforce. Ce chapitre recule la caméra et dessine ce qui entoure l’organisation, avant de la concevoir. Salesforce est un système parmi d’autres, et bien souvent ce n’est pas lui qui possède les données.

Image générée par IA.

Les idées de ce chapitre

• Le paysage d’abord. Trouvez les systèmes, puis les données qui circulent entre eux, puis qui possède chaque élément. Ensuite seulement, décidez du rôle de Salesforce.
• Une flèche dépend d’autres flèches. Les commandes envoyées vers l’ERP ont besoin que les clients, les produits et les prix y soient d’abord. Chaque fois que je vois une intégration avec un seul flux, je commence à m’inquiéter.
• Les données se présentent en types, et en charges de travail. Les données maîtres, les données de référence, transactionnelles, les métadonnées, les données analytiques et non structurées changent, grossissent et sont utilisées différemment ; les charges de travail opérationnelles (OLTP), analytiques (OLAP) et en flux veulent des emplacements différents. L’organisation fait tourner l’entreprise ; les entrepôts et les lacs l’analysent.
• Les systèmes ont des rôles, pas seulement des logos. Enregistrement, engagement, référence, analyse. « Salesforce est notre système d’enregistrement » : pour quoi ?
• L’endroit où vit l’analytique suit l’endroit où vivent les données. Tout sur le cœur : les rapports standard. Des données dans d’autres stockages : une plateforme d’analytique, et l’entrepôt de données lorsque les données Salesforce y sont fusionnées.
• Data 360 est proche du cœur (near-core) : géré sur le cœur, hébergé hors du cœur. Les utilisateurs ne s’y connectent jamais, il se place donc avec la tuyauterie.
• Les données possédées par l’ERP sont lues localement et écrites sous contrôle, avec un préfixe erp_ pour que le schéma montre qui possède chaque champ.
• 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. Deux flux, ce sont deux flèches ; une flèche à double pointe est réservée à un connecteur.
• Chaque flèche a un client et un serveur, et chacun possède sa moitié. Rien de cela ne figure sur le paysage, mais chaque flèche l’a.
• Comptez avant de dessiner les flèches. Les zéros vont dans l’inventaire, et ce sont eux qui choisissent le mécanisme : par lots, synchrone ou par événements.
• La stratégie d’organisation est une décision de paysage, prise dans les premières minutes : une organisation ou plusieurs, et où elle s’exécute.
• Un état actuel montre ce qui ne va pas. Du rouge pour un mauvais processus, des pointillés pour ce qui se fait à la main, des points rouges pour ce qui manque.

La disposition de paysage de Steve

Il existe de nombreuses façons de dessiner un paysage des systèmes. Voici la mienne, affinée pendant de nombreuses années, et elle se lit comme une phrase : les personnes à gauche atteignent Salesforce au centre, reconnues par les systèmes au-dessus, servies par les canaux en dessous, et connectées au back-office à droite.

Où	Ce qu’on y met
Gauche	Les personnes, de haut en bas : les utilisateurs internes, les partenaires, les clients
Centre	Salesforce, une simple boîte, avec ses communautés qui la touchent par en dessous
Haut	Les fournisseurs d’identité au-dessus de Salesforce ; AppExchange décalé vers la droite ; les sites web publics en haut à gauche
Droite	La couche d’intégration, puis les systèmes internes : ERP, finance, entrepôt
Sous la couche d’intégration	Data 360, proche du cœur, avec la tuyauterie
Bas	Les canaux clients : courriel, formulaires web, téléphone, messagerie
En bas à droite	Les données entrantes et sortantes : archives, chargements de données, sources externes, partenaires

Les systèmes sont des cartes dans des zones pâles et étiquetées, chacune avec une icône, et une légende dit ce que tout signifie. Derrière l’image se trouve un inventaire : pour chaque jeu de données ou flux, son propriétaire, son volume, son mécanisme et son rythme, son authentification, et s’il faut le copier, le référencer ou le fédérer.

Click to enlarge

Le paysage du module 4, avec ses flèches.

Le parcours de ce chapitre

Six modules, chacun autonome.

1. Salesforce est un système parmi d’autres. Pourquoi le paysage passe avant la boîte, l’intégration que je vois encore et encore et les flux de retour dont elle dépend, les données par vagues, et le cœur, le proche du cœur et Hyperforce.
2. Les types de données de l’entreprise. Six types ; créées, modifiées, référencées ; OLTP et OLAP ; temps réel, quasi temps réel et traitement par lots ; les quatre questions derrière les catégories.
3. Les systèmes autour de Salesforce. Les rôles des systèmes ; l’ERP, l’entrepôt de données et le lakehouse ; l’analytique suit les données ; le MDM ; l’intégration et les événements ; le fournisseur d’identité que les développeurs oublient ; la place de Data 360.
4. Dessiner le paysage des systèmes. Ma disposition, construite à partir d’une toile vierge ; les zéros avant les flèches ; des flèches qui partent de l’initiateur ; le client et le serveur derrière chaque flèche, dans les deux sens ; des couloirs pour les conversations ; l’inventaire derrière l’image.
5. La stratégie d’organisation est une décision de paysage. Commencer avec une seule organisation ; ce qui en justifie une autre ; la région, pas le fournisseur ; une séparation en AMER et EMEA imposée par le RGPD ; ce qu’ajoute la deuxième organisation.
6. Le paysage de Steve Trucking. Aujourd’hui, avant une vraie mise en œuvre, annoté : des manifestes qui arrivent dans RouteDesk, des tournées ressaisies à la main dans Salesforce et en retour, un îlot de données GPS, un tableur qui alimente la finance, et 108 000 appels « où est ma livraison ? » par an.

Quand vous avez terminé, testez-vous avec le guide d’étude du chapitre : une liste de contrôle pour l’examen, les habitudes qui vont au-delà, les mots à connaître et quelques questions.

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.
• Comment fonctionne chaque connexion : ce qui circule, dans quel sens, comment elle s’authentifie, à quelle vitesse, et ce qui revient.
• Combien d’organisations, et où elles s’exécutent, décidé en premier, car tout le reste du paysage en dépend.
• Si l’état actuel est assez bien compris pour concevoir un état cible.

Au-delà de l’examen : le paysage devient une carte des agents. Avant qu’un agent puisse répondre « où est ma livraison ? », quelqu’un doit savoir quel système fait autorité pour chaque fait, à quel point il est à jour, et comment l’agent peut l’atteindre. Chaque module se termine par ce que l’IA change pour sa partie de l’image.

Pour aller plus loin

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Pour aller plus loin, pour les candidats CTA : Salesforce Architects publie ses propres recommandations sur les diagrammes, How to Build Salesforce Diagrams (opens in a new tab) (en anglais).

Suivant : Qualité et gouvernance des données