# architect Diagrammes de référence (reference-diagrams) - Full Documentation # Activation par lot Salesforce Data 360 et architecture d'actions pilotées par l'événement Activation par lot Salesforce Data 360 et architecture d'actions pilotées par l'événement ## Description Voici un diagramme représentant Salesforce Data 360 dans une solution complète pour des activations marketing. Il montre comment élaborer une solution complète avec des produits tels que les organisations domestiques, les organisations compagnes, Data Cloud One, Agentforce 360, Agentforce Sales, Marketing Cloud et Tableau Next. ## Liens téléchargeables - [Lucid](https://lucid.app/lucidchart/editNew/620837ec-bb08-4f1e-af26-1164fc5f789c) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-actions-activations.webp) # Architecture d'implémentation de Data 360 Customer Zero Architecture d'implémentation de Data 360 Customer Zero ## Description Un diagramme de bout en bout montrant Salesforce Data 360 tel qu'implémenté dans Salesforce en tant que notre programme Customer Zero. Salesforce Data 360 sert de couche centrale d'intelligence et de gouvernance, unifiant les données d'entreprise via la fédération Zero Copy avec des systèmes externes Snowflake et AWS tout en préservant Trust et sémantique. Cette fondation de données prête pour l'IA unifiée propulse l'activation Agentforce 360\. Elle permet aux agents riches en raisonnement, l'enrichissement CRM et l'automatisation inter-clouds avec des flux de données sécurisés et sensibles aux politiques à travers toutes les fonctions métiers, transformant ainsi l'organisation en entreprise agentique. ## Liens téléchargeables - [Lucid](https://lucid.app/lucidchart/editNew/af215946-127b-4b47-95b9-a7c158be351b) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/sfdc_customer_zero_implementation.png) # Architecture d'intégration de données sans copie avec Data 360 Architecture d'intégration de données sans copie entre Salesforce Data 360 et AWS ## Description Diagramme montrant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à divers services de données AWS, ainsi que la puissante interopérabilité Zero Copy avec AWS Redshift et S3\. Cette architecture permet aux organisations d'intégrer et d'unifier de façon transparente les données à travers les plates-formes fédérées, fournissant une couche d'unification et d'activation centrale qui est essentielle pour la transformation en véritable entreprise Agentic. Il comprend des produits Salesforce tels que Agentforce 360, Tableau Next, Marketing Cloud, Data 360 et Agentforce Sales. ## Liens téléchargeables : **Backend : Amazon Web Services** - [Lucid](https://lucid.app/lucidchart/editNew/04991364-85c0-45e6-b5de-553367fbb473) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-aws.webp) **Backend : Google Cloud Platform** - [Lucide](https://lucid.app/lucidchart/editNew/4661f0e4-e86a-409b-9a98-8301cbbca74f) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-gcp.webp) **Backend : Databricks** - [Lucide](https://lucid.app/lucidchart/editNew/e74f6e22-ce6d-4b6d-a258-76ddb8f73f4e) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-databricks.webp) **Backend : Snowflake** - [Lucide](https://lucid.app/lucidchart/editNew/b02236c2-f3f4-4de8-b13b-35f67fd5390d) - [Image](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-snf.webp) # Architecture d'organisation unique Single org architecture (architecture d'organisation unique) : diagramme détaillant une stratégie d'organisation unique prenant en charge les unités commerciales internationales. ## Description Diagramme détaillant une stratégie d'organisation unique prenant en charge plusieurs unités commerciales. La case inférieure peut inclure la liste des produits utilisés (comme indiqué ci-dessus) ou les capacités requises pour les unités commerciales telles que Panier d'achat, Gestion des pistes ou Gestion des requêtes. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/92edbe8d-18b8-4998-a851-7d1e815ea7d5) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/single-org-architecture.webp) # Architecture de la solution de gestion de la fidélité Architecture de solution de gestion de la fidélité : un diagramme d'architecture qui présente les produits et les capacités directement impliqués dans une solution de gestion de la fidélité. ## Description Diagramme d'architecture qui présente les produits et les capacités directement impliqués dans une solution de gestion de la fidélité. Cela inclut Agentforce Commerce, Agentforce Sales, Agentforce Service, Marketing Cloud Engagement, MuleSoft, Data 360 et Tableau pour les analytiques. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/217c76c7-b8c4-44ed-aade-a7ae3fb8df0a) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/loyalty-management-solution-architecture.webp) # Architecture de solution Les diagrammes d'architecture de solution illustrent les détails de conception technique et d'implémentation de solutions spécifiques, montrant comment les composants, les services et les intégrations fonctionnent ensemble pour répondre aux exigences métiers. Ces diagrammes présentent aux architectes et aux développeurs une vue détaillée des interactions système, des flux de données et des modèles architecturaux. Ils servent de modèles pour l'implémentation, aidant les équipes à comprendre les relations des composants, les points d'intégration et les dépendances techniques au sein d'une solution. Cette section contient 4 diagrammes de référence associés à l'architecture de solution : | Nom du diagramme | Description | | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | [Architecture d'intégration de données sans copie avec Data 360](/docs/architect/fr-fr/reference-diagrams/guide/aws-data-360) | Diagrammes représentant Salesforce Data 360 utilisant des connecteurs prêts à l'emploi pour l'intégration à divers services de données back-end. | | [Architecture d'implémentation Data 360 Customer Zero](/docs/architect/fr-fr/reference-diagrams/guide/sfdc-customer-zero-implementation) | Un diagramme de bout en bout montrant Salesforce Data 360 tel qu'implémenté dans Salesforce en tant que notre programme Customer Zero. | | [Architecture d'activation par lots et d'action pilotée par l'événement pour Data 360](/docs/architect/fr-fr/reference-diagrams/guide/data360-actions-activations) | Diagramme représentant Salesforce Data 360 dans une solution complète pour les activations marketing. | | [Architecture de solution de gestion de la fidélité](/docs/architect/fr-fr/reference-diagrams/guide/loyalty-management-solution-architecture) | Diagramme d'architecture qui présente les produits et les capacités directement impliqués dans une solution de gestion de la fidélité. | # Carte des capacités Les cartes des capacités offrent une représentation visuelle des capacités commerciales et techniques, illustrant comment différents produits et services contribuent aux objectifs de l'organisation. Ces diagrammes aident les architectes et les parties prenantes à comprendre la relation entre les moteurs métiers, les capacités et la pile technologique sous-jacente. Ils servent d'outils de planification stratégique qui permettent une meilleure adéquation entre les objectifs métiers et la mise en œuvre technique. Cette section contient 4 diagrammes de référence associés aux cartes de capacité : | Nom du diagramme | Description | | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | [Carte des capacités commerciales](/docs/architect/fr-fr/reference-diagrams/guide/business-capability-map) | Un modèle de carte des capacités destiné à représenter les moteurs métiers et les capacités avec un positionnement produit de haut niveau. | | [Carte des capacités techniques Data 360](/docs/architect/fr-fr/reference-diagrams/guide/data-360-technical-capability-map) | Une carte des capacités montrant les capacités techniques de Data 360 et le mix produit impliqué dans leur prise en charge. | | [Carte des capacités de gestion de la fidélité](/docs/architect/fr-fr/reference-diagrams/guide/loyalty-management-capability-map) | Une carte des capacités montrant les services de gestion de la fidélité avec un positionnement produit de haut niveau. | | [Centre d'excellence](/docs/architect/fr-fr/reference-diagrams/guide/center-of-excellence) | Un diagramme détaillant comment un Centre d'excellence (CoE) relie les parties prenantes exécutives et l'informatique. | # Carte des capacités de gestion de la fidélité Carte des capacités de gestion de la fidélité : une carte des capacités qui montre les services de gestion de la fidélité avec un positionnement produit de haut niveau. Elle inclut des capacités telles que Administration de la fidélité, Traitement et Analytics. ## Description Ce diagramme de carte des capacités montre les services de gestion de la fidélité avec un positionnement produit de haut niveau. Il inclut des capacités telles que Administration de la fidélité, Traitement et Analytics. Cette solution utilise des produits Salesforce tels que Marketing Cloud Engagement, Agentforce Service et MuleSoft. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/d41ccba2-71ea-449a-8497-ea95396102b4) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/loyalty-management-capability-map.webp) # Carte des capacités métiers Carte des capacités métiers : un modèle de carte des capacités qui présente les moteurs et les capacités métiers avec un positionnement produit de haut niveau. ## Description Un modèle de carte des capacités pour représenter les moteurs et les capacités métiers avec un positionnement produit de haut niveau. Les moteurs métiers sont les objectifs stratégiques de haut niveau ou les pressions externes qui poussent une organisation à changer son fonctionnement. Exemples de moteurs métiers : - Croissance du revenu - Réduction des coûts opérationnels - Rétention des clients ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/fe6ccc24-6a13-4e0f-8076-1e5af8b08466) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/business-capability-map.webp) # Carte des capacités techniques de Data 360 Carte des capacités techniques de Data 360 : une carte des capacités qui montre les capacités techniques de Data 360 et la combinaison de produits impliqués dans leur prise en charge. Elle inclut des capacités telles que Data Lakehouse, Traitement des Big Data, Connecteurs de données, Transformations, Modèles et Source unique de vérité. ## Description Une carte des capacités montrant les capacités techniques de Data 360 et le mix produit impliqué dans leur prise en charge. Elle inclut des capacités telles que Data Lakehouse, Traitement des Big Data, Connecteurs de données, Transformations, Modèles et Source unique de vérité. Ce diagramme montre également comment Tableau et MuleSoft s'intègrent dans une solution complète. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/9b36e287-525d-472c-92ec-729bca136540) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/data-360-technical-capability-map.webp) # Centre d'excellence Centre d'excellence - Diagramme montrant comment un Centre d'excellence (CoE) relie les parties prenantes exécutives et l'informatique. Il met en évidence le rôle central des capacités fonctionnelles et techniques de leadership dans un CoE. ## Description Diagramme montrant comment un Centre d'excellence (CoE) relie les parties prenantes exécutives et l'informatique. Il souligne comment les capacités fonctionnelles et techniques de leadership sont essentielles dans un Centre d'excellence (CoE). Les Centres d'excellence offrent l'expertise et des conseils à l'échelle de l'entreprise. Ils fournissent de la valeur avec des activités telles que : - Mise en place des meilleures pratiques pour la mise en œuvre des solutions - Faire respecter les normes de l'entreprise et les pratiques standard de l'industrie - En tant qu'experts produit, éduquer et former les équipes de projet aux produits. - Résoudre les problèmes difficiles qui se posent pendant l'implémentation ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/59956c3b-3c73-469b-87a4-44c6dad948e5) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/center-of-excellence.webp) ## Introduction Les diagrammes sont un outil essentiel et un élément clé du travail architectural. Ils nous permettent de communiquer de nombreuses idées différentes à de nombreux types de parties prenantes. Les diagrammes aident les équipes de livraison à rester alignées, en servant de source unique de vérité sur les réalités des implémentations et des produits. Les diagrammes sont également essentiels pour permettre aux parties prenantes de prendre les bonnes décisions en matière d'achat et de technologie. **Les diagrammes doivent toujours :** - Lire de gauche à droite et de haut en bas, le plus près possible - Transmettre un message concis, avec une portée d'informations appropriée pour en faciliter la lisibilité. - Utiliser les [composants standard Salesforce Diagrams](/docs/architect/fr-fr/reference-diagrams/guide/kit-of-parts), y compris des cartes et un en-tête avec une description claire décrivant le contenu, la portée et l'objet du diagramme ## Portée du diagramme La portée d'un diagramme doit se limiter aux informations critiques à transmettre pour un sujet spécifique. Tout élément qui n'est pas nécessaire pour capturer le message que vous souhaitez communiquer doit être exclu. Plusieurs diagrammes peuvent (et doivent) être créés pour capturer divers concepts, afin de communiquer plus clairement et d'affiner le contenu du diagramme. - Définir les informations/messages critiques que vous devez transmettre à votre audience - Classer les étendues logiques afin de concentrer les informations pour capturer le message - Identifier le ou les types de diagramme les plus appropriés à utiliser en tant que modèles ## Types de diagramme Salesforce Diagrams a défini nos types de diagramme les plus utiles/populaires afin de vous aider à utiliser des modèles et à comprendre les conventions de diagramme. Nos ressources actuelles sont classées comme suit : ### Cartes des capacités - Capturer la combinaison de propriétés et les capacités clés pertinentes incluses dans une solution - Mettre l'accent sur les fonctionnalités, les moteurs métiers et les valeurs ✨ Retrouvez des cartes de capacité dans la [Galerie d’architecture de référence](/docs/architect/fr-fr/reference-diagrams/guide/section-capability-map) ### Paysages système - Capturer les produits et/ou les systèmes techniques impliqués dans une implémentation donnée - Mettre en évidence les propriétés, les aspects spécifiques des propriétés et les connexions entre les propriétés ✨ Recherchez des exemples et des modèles de paysage système dans la [galerie Architecture de référence](/docs/architect/fr-fr/reference-diagrams/guide/section-system-landscape) ### Architectures de solutions - Inclure des produits ou des technologies avec une intégration, un comportement et/ou des fonctionnalités - Mettre l'accent sur les connexions détaillées et/ou les aspects de communication entre les propriétés ✨ Retrouvez des exemples et des modèles d’architecture de solution dans la [galerie Architecture de référence](/docs/architect/fr-fr/reference-diagrams/guide/section-solution-architecture) ### Feuilles de route - Aider les organisations à planifier et à visualiser l'implémentation stratégique des capacités, des composants, des fonctionnalités et des systèmes au fil du temps - Fournir une vue claire de l'ordre d'implémentation, des dépendances et des priorités ✨ Retrouvez des exemples et des modèles de feuille de route dans la [galerie Architecture de référence](/docs/architect/fr-fr/reference-diagrams/guide/section-roadmap) ### Interaction / Processus / Flux - Capturer les étapes temporelles, les flux de données ou les interactions requis pour prendre en charge un processus - Mettre en évidence et clarifier (avec la numérotation séquencée) l'ordre des aspects/propriétés ✨ Retrouvez des exemples et des modèles de diagrammes d'interaction, de processus et de flux dans la [galerie Architecture de référence](/docs/architect/fr-fr/reference-diagrams/guide/section-interaction-process-flow) ### Modèles de données / MER - Capturer des entités (objets), des relations et des concepts pour des implémentations de métadonnées ✨ Recherchez des exemples et des modèles de modèle de données dans la [Galerie de modèles](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) de données Consultez des exemples de types de diagrammes dans la [Galerie d’architecture de référence](/diagrams) ou dans notre [Galerie de modèles de données dédiée](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html). Utilisez un modèle pour créer rapidement et aisément un diagramme adapté à votre cas d'utilisation. ## Étapes de création d'un diagramme : - Définissez la **portée** du message que vous devez transmettre : - _Pensez à votre audience, aux propriétés/aspects que vous devez représenter, aux informations nécessaires pour capturer le message et à ce qui peut être exclu_ - Assurez-vous qu'il y a un **en-tête** avec un **titre** clair et une **description** concise et réfléchie qui capture l'objet, la portée et le message de votre diagramme Assurez-vous que l'en-tête contient un titre clair et une description concise et réfléchie qui reflète l'objet, la portée et le message de votre diagramme - Utilisez des **cartes** pour capturer les propriétés (systèmes, concepts, entités, etc.) - Capturer les détails des propriétés ou les principaux aspects / capacités si nécessaire dans **les attributs Carte** Attributs de carte - Utilisez les **Connectors** pour représenter les relations nécessaires entre les propriétés de votre carte. Connectors - Incorporer des **icônes de carte** lorsque cela est utile, disponible et/ou approprié Icônes de carte - Utilisez les **pieds de page** et les **icônes de pied de page** pour capturer d'autres aspects clés des propriétés Icônes de pied de page **Avertissement :** En raison d'une limitation actuelle avec Lucidchart, les icônes de pied de page dans les diagrammes créés à partir d'un modèle sont désancrées de la carte. Vous devrez réancrer les icônes en les faisant glisser vers le centre du pied de page. Consultez la [page des composants standard](/docs/architect/fr-fr/reference-diagrams/guide/kit-of-parts) pour plus de détails et de bonnes pratiques. **Vous avez des remarques ou des questions sur Salesforce Diagrams ?** Merci de nous faire part de vos commentaires [ici](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link). ## Composants standard Les composants standard facilitent l'élaboration, la personnalisation et la réutilisation de diagrammes cohérents et de haute qualité. Salesforce recommande Lucid pour les diagrammes d'architecture. Le style professionnel est utilisé par toutes les formes et tous les modèles de diagramme Salesforce. Bibliothèque et modèles Salesforce Shape dans Lucidchart Bibliothèque de formes et modèles Salesforce dans Lucidchart
Recherchez des exemples d'utilisation de composants dans la [galerie Architecture de référence](https://architect.salesforce.com/diagrams#reference-architecture-gallery) ## Meilleures pratiques Les sections suivantes présentent les meilleures pratiques détaillées pour l'[en-tête](#en-tête), [les cartes](#cartes), [les icônes](#icônes) et [les connecteurs](#connecteurs) inclus dans les composants standard. ## En-tête En-tête du diagramme L'en-tête doit être présent sur tous les diagrammes et inclure : - Un titre qui peut être rapidement compris par votre audience - Une description claire de ce que le diagramme couvre, son but et son intention - (facultatif) votre logo ou nom de société pour transmettre l'auteur - (facultatif) une Clé pour clarifier les icônes, dessins ou symboles utilisés en tant que classifications La taille doit occuper au moins 10 % de la hauteur du diagramme et 100 % de la largeur. La taille de police de la description doit être au moins égale à la moitié de la taille du titre. Une Clé doit être incluse lors de l'utilisation d'icônes, de connecteurs, de couleurs, etc., qui ne sont pas spécifiées avec des titres sur le diagramme lui-même. La clé doit être regroupée en lignes paires si possible. ## Cartes Toutes les propriétés de votre diagramme doivent être représentées par une carte. Les cartes peuvent être redimensionnées et avoir des remplissages transparents ou colorés. Plusieurs sections de la carte présentent des variantes que vous pouvez utiliser pour représenter différents concepts dans votre diagramme. ### **Anatomie des cartes** Un exemple de carte est ci-dessous, avec les différentes sections décrites. Le seul contenu de la carte requis est le titre. Les autres sections peuvent être utilisées selon les besoins pour des cas d'utilisation spécifiques. Anatomie des cartes **Icône de carte** Les icônes de carte sont des actifs visuels représentant la propriété de la carte **Titre de la carte** Le titre de la carte est un nom de carte qui peut être rapidement compris, capturant la propriété, la zone ou le concept que la carte représente **Attributs de carte** Les attributs de carte sont des détails textuels sur la propriété, représentés sous forme de liste et utilisés lorsque vous devez capturer et transmettre plusieurs points de données **Pied de page de carte** Le pied de page de la carte fournit des caractéristiques supplémentaires de la propriété. Exemples : Noms de package, d'objet ou d'API, Propriété, Capacités, etc. **Icônes de pied de page de carte** La section Icônes de pied de page permet aux actifs visuels d'afficher des informations supplémentaires sur la propriété. Exemples : canaux, services partagés, capacités, etc. Les icônes de pied de page doivent être incluses / expliquées dans votre clé de diagramme. Avertissement : En raison d'une limitation actuelle avec Lucidchart, les icônes de pied de page dans les diagrammes créés à partir d'un modèle sont désancrées de la carte. Vous devrez réancrer les icônes en les faisant glisser vers le centre du pied de page. ### **Variations de carte** L'utilisation de différentes sections fournit différentes variantes de carte pour différentes utilisations. Vous pouvez mélanger et mapper l'anatomie des cartes si nécessaire pour créer ces variations dans vos diagrammes. Voir exemples ci-dessous : Carte réduite Carte détaillée Carte détaillée avec pied de page Pour des idées sur l'utilisation de ces variantes, consultez la [Galerie d'architecture](https://architect.salesforce.com/diagrams#reference-architecture-gallery) de référence. Utilisez la possibilité d'ajuster la taille et la couleur de vos cartes si nécessaire pour différencier les types et créer des diagrammes clairs et compréhensibles. ## **Conteneurs** Les cartes peuvent également agir en tant que conteneurs, c'est-à-dire des regroupements pour plusieurs propriétés. Vous pouvez imbriquer des cartes dans une autre carte pour représenter les relations hiérarchiques ou classer les propriétés associées si nécessaire. Conteneurs ## **Icônes** Les diagrammes Salesforce fournissent une série de logos de produit Salesforce de base ainsi que des icônes supplémentaires pour représenter les propriétés et d'autres zones de votre diagramme. Icônes Vous trouverez des exemples d'utilisation d'icônes dans la [galerie Architecture de référence](https://architect.salesforce.com/diagrams#reference-architecture-gallery) _Pour d'autres icônes, consultez les [icônes du Lightning Design System](https://www.lightningdesignsystem.com/icons/)_ ## Connecteurs Les connecteurs doivent toujours utiliser des lignes de connexion coudées et être droits dans la mesure du possible pour plus de lisibilité. Connecteurs et pastilles **Les connecteurs** représentent une étape de relation, d'intégration ou de processus entre deux cartes. Les styles de ligne indiquent un type de connexion différent et doivent être représentés dans votre clé de diagramme. Les points de terminaison indiquent la direction d'un connecteur d'intégration ou de processus. Les points de terminaison indiquent également la cardinalité et l'ordinalité dans un connecteur de relation. **Pastilles** sont utilisées pour fournir des détails sur les connexions. Consultez les diagrammes [Architecture de solution](/docs/architect/fr-fr/reference-diagrams/guide/section-solution-architecture) et [Flux de processus d'interaction](/docs/architect/fr-fr/reference-diagrams/guide/section-interaction-process-flow) pour voir des exemples d'utilisation des pilules. ## Accessibilité Dans le monde, environ [1,3 milliard de](https://www.salesforce.com/company/legal/508_accessibility/#:~:text=Product%20Accessibility%20Status&text=Around%20the%20world%2C%20approximately%201.3,global%20economy%20that%20includes%20everyone.) personnes vivent avec une forme de handicap, soit 15 % de la population mondiale. L'accessibilité consiste à rendre votre diagramme compréhensible pour tous vos visualiseurs. Deux zones d'intérêt particulières peuvent faciliter l'accès à vos diagrammes : Optimiser pour les lecteurs d'écran et utiliser correctement le contraste des couleurs. Vous trouverez plus de ressources sur la conception pour l'accessibilité dans le [blog Salesforce Design](https://medium.com/salesforce-ux/tagged/accessibility). **Lecteurs d'écran** Un lecteur d'écran est une application logicielle qui lit à haute voix les termes d'un fichier, d'une application ou d'un site Web. Un lecteur d'écran peut lire les diagrammes pour les personnes qui ne peuvent pas les voir clairement. Le meilleur format pour la compatibilité du lecteur d'écran est PDF (Portable Document Format). Contrairement aux images et aux applications non accessibles, les fichiers PDF sont accessibles par les lecteurs d'écran pour lire les mots, les formes et les couleurs. L'exportation de vos diagrammes au format PDF lors du partage avec d'autres utilisateurs peut améliorer l'accessibilité. **Contraste des couleurs** Augmenter le contraste de couleur est une autre façon d'aider votre diagramme à être plus accessible. Les personnes seront plus en mesure de reconnaître et de lire vos diagrammes lorsqu'ils respectent les [Web Content Accessibility Guidelines (WCAG) minimum de contraste](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html) de couleur d'avoir un ratio de 4,5:1 entre la couleur d'arrière-plan derrière le texte et la couleur du texte lui-même. Exemple de palette de couleurs pour afficher le contraste suggéré Chaque couleur du [système Salesforce](https://medium.com/salesforce-ux/the-salesforce-color-system-c7c6b5b9c577) est associée à un chiffre, compris entre 0 et 100. Lorsque vous choisissez des couleurs pour vos diagrammes, assurez-vous que la couleur d'arrière-plan derrière le texte est supérieure ou inférieure d'au moins 50 points à la couleur du texte. Par exemple, si votre couleur d'arrière-plan est 80, la couleur de votre texte ne doit pas dépasser 30\. Vous pouvez également utiliser la règle des 50 points pour les bordures et les contours. **Vous avez des retours ou des questions sur les diagrammes Salesforce ?** Merci de nous faire part de vos avis [ici](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link). # Contrôle de réclamation Contrôle de réclamation : indique qu'un événement est publié lors de la modification d'un enregistrement. Le corps du message de l'événement est stocké dans un magasin de données séparé, tandis que l'en-tête, qui contient un contrôle de réclamation, est transmis à un abonné. L'abonné utilise ensuite le contrôle de réclamation pour récupérer le corps du message lorsqu'il est prêt à traiter l'information si nécessaire. ## Description Ce diagramme montre le modèle du jeton de réclamation. Ce modèle publie et événement dans un bus d'événement lorsqu'un enregistrement est modifié. Le corps du message de l'événement est stocké dans un magasin de données séparé, tandis que l'en-tête, qui contient un contrôle de réclamation, est transmis à un abonné. L'abonné utilise ensuite le contrôle de réclamation pour récupérer le corps du message lorsqu'il est prêt à traiter les informations. ## Liens téléchargeables - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0699a470-11ca-4291-88d6-a6399142a1ca) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/claim-check.webp) # Feuille de route Agentforce Feuille de route Agentforce – un exemple de feuille de route illustrant les composants de déploiement de l'IA dans le cadre d'une implémentation Salesforce Customer 360 ## Description Diagramme de feuille de route montrant les étapes de déploiement des fonctionnalités Agentforce dans une implémentation Salesforce Customer 360. Cela comprend des étapes telles que _Créer des normes, Modéliser la gouvernance, Préparer les données, Établir l'équipe_ et _Vérifier et surveiller_. Les swimlanes comprennent le Centre d'excellence, les ventes, le service et les développeurs. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/1d9723f0-0835-4dc2-9cbb-01b2e97c91e8) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/generative-ai-roadmap.webp) # Feuille de route des capacités Feuille de route des capacités : une feuille de route visuelle qui rationalise la planification et la budgétisation des ressources en regroupant les capacités et en identifiant l'ordre d'implémentation, les dépendances et la valeur. ## Description Une feuille de route visuelle qui rationalise la planification et la budgétisation des ressources en regroupant les capacités et en identifiant l'ordre d'implémentation, les dépendances et la valeur. Pour chaque capacité de ce diagramme, il est courant d'avoir une [Component Roadmap](/docs/architect/fr-fr/reference-diagrams/guide/component-roadmap) dédiée pour explorer les détails de la livraison. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/12103374-8b95-49bb-b7ad-b0f8154ccec6) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/capability-roadmap.webp) # Feuille de route des composants feuille de route des composants : une feuille de route visuelle qui optimise la planification des ressources et la budgétisation en identifiant les fonctionnalités du système, les fonctionnalités pertinentes, l'ordre d'implémentation, les délais et les dépendances des parties prenantes. ## Description Ce diagramme contient une feuille de route visuelle qui optimise la planification des ressources et la budgétisation en identifiant les fonctionnalités système, les fonctionnalités pertinentes, l'ordre d'implémentation, les délais et les dépendances des parties prenantes. Ce diagramme est habituellement utilisé comme vue de détail d'une case d'une [feuille de route des capacités](/docs/architect/fr-fr/reference-diagrams/guide/capability-roadmap). Pour chaque composant de ce diagramme, il est courant d'avoir une [feuille de route](/docs/architect/fr-fr/reference-diagrams/guide/feature-roadmap) dédiée pour explorer les détails de la livraison de fonctionnalités. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/2ca75fbd-af2e-45fd-a636-01255f1fb0cf) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/component-roadmap.webp) # Feuille de route des fonctionnalités Fiche de route des fonctionnalités : une feuille de route visuelle qui améliore la collaboration entre les équipes commerciales et techniques en identifiant l'ordre d'implémentation des fonctionnalités, les dépendances et les fonctionnalités supplémentaires à des fins de planification. ## Description Un diagramme de feuille de route visuel qui améliore la collaboration entre les équipes commerciales et techniques en identifiant l'ordre d'implémentation des fonctionnalités, les dépendances et les fonctionnalités supplémentaires à des fins de planification. Ce diagramme est généralement utilisé comme vue de détail d'une boîte dans une [feuille de route des composants](/docs/architect/fr-fr/reference-diagrams/guide/component-roadmap). ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/8e43258e-b21b-4525-87bf-8e5ba96f4032) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/feature-roadmap.webp) # Feuille de route système Feuille de route système : diagramme de feuille de route qui simplifie la planification des ressources et la budgétisation. ## Description Un diagramme de feuille de route qui simplifie la planification des ressources et la budgétisation en identifiant l'ordre d'implémentation du système, les dépendances, les zones fonctionnelles et les fonctionnalités pertinentes pour les parties prenantes. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/ead3af9a-ddc2-492a-a8c9-7ab3943fabd7) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/system-roadmap.webp) # Flux de personnalisation client Flux de personnalisation client : affiche les interactions temporelles impliquées dans le flux d'informations de bout en bout, depuis les interactions des clients sur le site Experience Cloud jusqu'à l'automatisation back-end dans Marketing Cloud et Slack. MuleSoft orchestre les intégrations à des systèmes back-end, Slack connecte tous les membres de l'équipe et Marketing Cloud boucle la boucle avec le parcours client. ## Description Ce diagramme montre les interactions temporelles impliquées dans le flux d'informations de bout en bout, depuis les interactions des clients sur le site Experience Cloud jusqu'à l'automatisation back-end dans Marketing Cloud et Slack. MuleSoft orchestre les intégrations à des systèmes back-end, Slack connecte tous les membres de l'équipe et Marketing Cloud boucle la boucle avec le parcours client. Cette architecture utilise également les produits Headless 360 et Data 360. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/b13e3166-d3a1-4621-b275-242638f3f9af) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/customer-personalization-flow.webp) # Flux de processus d'interaction Les diagrammes de flux de processus d'interaction illustrent la séquence des interactions, des flux de données et des étapes de processus entre les composants système, les services et les utilisateurs. Ces diagrammes aident les architectes et les développeurs à comprendre comment les différentes parties d'un système communiquent, comment les événements se propagent à travers l'architecture et comment les processus asynchrones et synchrones sont orchestrés. Ils fournissent une documentation essentielle pour comprendre le comportement du système, identifier les blocages et optimiser les flux de processus. Cette section contient 6 diagrammes de référence associés au flux de processus d'interaction : | Nom du diagramme | Description | | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Traitement asynchrone via des événements de plate-forme](/docs/architect/fr-fr/reference-diagrams/guide/asynchronous-processing-via-platform-events) | Montre le fonctionnement du traitement asynchrone avec les événements de plate-forme. Les événements publiés dans le bus sont consommés par les abonnés pour traitement. | | [Claim Check](/docs/architect/fr-fr/reference-diagrams/guide/claim-check) | Affiche un événement publié lors de la modification d'un enregistrement. Le corps du message de l'événement est stocké dans une base de données et seule une référence est transmise via le bus de message. | | [Flux de personnalisation client](/docs/architect/fr-fr/reference-diagrams/guide/customer-personalization-flow) | Affiche les interactions temporelles impliquées dans le flux d'informations de bout en bout depuis les interactions des clients jusqu'aux systèmes de livraison en passant par les moteurs de personnalisation. | | [Intégrations externes via HTTP](/docs/architect/fr-fr/reference-diagrams/guide/external-integrations-via-http) | Exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre les intégrations externes utilisant des protocoles HTTP. | | [Processus de gestion de la fidélité hôtelière](/docs/architect/fr-fr/reference-diagrams/guide/hospitality-loyalty-management-process) | Affiche les interactions temporelles des systèmes dans un processus de gestion de la fidélité hôtelière. | | [Mise en file d'attente](/docs/architect/fr-fr/reference-diagrams/guide/queuing) | Affiche un exemple de modèle File d'attente qui représente un événement publié et écrit dans une file d'attente, les abonnés traitant les événements dans l'ordre. | # Hiérarchie des rôles Salesforce Hiérarchie des rôles Salesforce : un exemple de hiérarchie d'organisations, qui capture un sous-ensemble de rôles afin de clarifier la structure métier, les personnes et les autorisations pour un cas d'utilisation spécifique ## Description Diagramme représentant un exemple de hiérarchie d'organisations, capturant un sous-ensemble de rôles afin de clarifier la structure métier, les personnes et les autorisations pour un cas d'utilisation spécifique. Ce n'est pas un diagramme typique de paysage, mais il est similaire en ce sens qu'il montre un plan conceptuel pour la façon dont les rôles sont associés et modélisent le domaine métier. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/4fe3cd5e-0ccf-4ffd-9f7c-a418ce615c67) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/salesforce-role-hierarchy.webp) # Intégrations externes via Http Intégrations externes via http : cet exemple de diagramme d'architecture de solution du guide de décision Building Forms montre une connexion à une source de données externe via un appel externe HTTP dans Flux et une action HTTP dans OmniStudio. ## Description Voici un exemple de diagramme d'architecture de solution du guide de décision Building Forms qui montre une connexion à une source de données externe via un appel externe HTTP dans Flux et une action HTTP dans OmniStudio. Il montre le schéma familier de requête et de réponse HTTP. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/161cc130-341d-4c6d-84dc-00ca6aa00462) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/external-integrations-via-http.webp) # Mise en file d'attente queuing : montre un exemple de modèle Queuing qui représente un événement publié et écrit dans une file d'attente lorsqu'un enregistrement est modifié. Les abonnés reçoivent des copies de l'événement de leurs files d'attente associées et effectuent les mises à jour appropriées dans leurs propres enregistrements. ## Description Affiche un exemple de modèle File d'attente qui représente un événement publié et écrit dans une file d'attente lorsqu'un enregistrement est modifié. Les abonnés reçoivent des copies de l'événement depuis leur file d'attente associée et effectuent les mises à jour appropriées dans leurs propres enregistrements. ## Liens téléchargeables - [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0cef151e-5b48-4237-bbe4-a774eee152ab) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/queuing.webp) ## Introduction Ce document présente une vue d'ensemble de la notation et des conventions relatives aux diagrammes des relations des entités (ERD) Salesforce pour vous aider à interpréter clairement les modèles de données produits disponibles dans la [galerie de modèles](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) de données. Un ERD, également appelé modèle de données, est une représentation graphique d'un système d'information. Il montre les relations entre les personnes, les objets, les lieux, les concepts et les événements de ce système. C'est un modèle logique qui transmet la structure fonctionnelle des données. Dans les ERD Salesforce, les entités sont généralement mappées avec un objet de la base de données Salesforce. ## Entités Une entité est une chose ou un objet important, réel ou conceptuel, sur lequel l'information doit être connue ou détenue. sample data model entity Les entités sont représentées dans les diagrammes sous forme de cases avec des coins arrondis. Chaque case d'entité fournit généralement deux étiquettes (le cas échéant) : - Le nom logique de l'entité (par exemple « Entité Salesforce » dans l'exemple présenté ici). Cela peut correspondre à l'étiquette au singulier de l'objet Salesforce représenté, mais pas toujours. - Le Nom d'API « physique » ou Nom du développeur de l'objet dans votre organisation Salesforce (par exemple « _Nom d'API_ » dans l'exemple). Généralement, pour des objets de package géré, le nom d'API répertorié dans le diagramme n'inclut pas l'espace de noms du package géré (« vlocity_ins\*\* », par exemple), sauf si Salesforce ou Industry Cloud utilise plusieurs packages gérés. La fin du nom d'API des objets package géré indique le type d'objet personnalisé utilisé : « \*\*c » pour les objets personnalisés habituels et les paramètres personnalisés, « \*\*mdt » pour les métadonnées personnalisées, « \*\*x » pour les objets externes. Les cases d'entité peuvent également répertorier un ou plusieurs attributs représentatifs des attributs de cette entité. Un attribut est précédé d'un caractère « # » ou « - ». - Un « # » indique un attribut qui fait partie de la clé unique logique de l'entité. Dans l'exemple de diagramme, « Attribut de clé utilisateur » est considéré comme la clé primaire utilisateur de l'entité. - Un « • » indique un attribut non clé. ### Mise en forme de l'entité Chaque diagramme de relation d'entité illustre le modèle de données Salesforce du point de vue d'un cloud spécifique tel que Sales Cloud, Service Cloud ou Marketing Cloud. La palette de couleurs du diagramme reflète le nuage en évidence. Tous les clouds sectoriels tels que Financial Service Cloud, Health Cloud et Media Cloud utilisent le même schéma de couleurs sectoriel. La couleur d'une entité donnée sur le diagramme a également une signification spécifique. La couleur du nuage de focus est indiquée en utilisant sa couleur de marque Salesforce, avec quelques exemples ci-dessous. sample data model clouds La section suivante examinera les différentes mises en forme d'entité en référence à l'exemple de légende Sales Cloud ci-dessous : sample data model entities legend ### Entité Cloud Une entité avec les couleurs du focus cloud représente un objet fourni avec la licence de ce cloud. ### Entité associée Une entité avec un remplissage blanc et une bordure noire représente un objet fourni avec une licence différente de celle de focus Cloud et qui n'est pas étendue par la licence focus Cloud. Les entités Compte et Contact affichées dans un ERD Sales ou Service Cloud, par exemple, sont affichées en blanc avec une bordure noire, car ces objets sont disponibles avec une licence de plate-forme. ### Entité associée étendue Une entité avec un remplissage gris clair et une bordure noire représente un objet fourni avec une licence différente de celle du focus Cloud, mais le focus Cloud étend cet objet. Par exemple, Commerce Cloud étend l'objet de base Product2 avec des champs supplémentaires. Les extensions comprennent des champs, des relations et des types d'enregistrement supplémentaires. ### Entité externe Les entités sans bordure sont virtuelles. Utilisées dans un diagramme, ces cases reconnaissent l'existence d'une entité dans le modèle logique du domaine, mais l'entité n'est pas implémentée en tant qu'objet physique dans Salesforce. Les données de cette entité devraient être accédées via des appels d'API externes ou Salesforce Connect dans la solution déployée. ### Entité Type d'enregistrement Les entités avec une bordure en tirets sont modélisées en tant que types d'enregistrement dans Salesforce. Dans l'exemple présenté ici, les sous-types Compte professionnel, Compte de facturation, Compte consommateur et Compte de service ont une bordure en tirets, car ils sont mappés avec les types d'enregistrement livrés avec le package géré Communications Cloud. sample data model record type notation ### Entité conceptuelle Les entités avec une bordure en pointillés sont virtuelles. Ni les types d'enregistrement ni un objet séparé ne sont utilisés pour différencier ces sous-types dans la solution Salesforce. Ces sous-types représentent logiquement un concept du domaine qui aide à illustrer la fonctionnalité du modèle de données. ### Entités Supertype et Sous-type Un sous-type d'entité est la définition d'un sous-ensemble de ses occurrences. Lorsqu'un ensemble de sous-types est ajouté dans une entité supertype, l'entité supertype représente les attributs et les relations communs, tandis que les entités sous-types affichent les attributs et les relations spécifiques au sous-type. Dans la notation du diagramme, les sous-types sont mutuellement exclusifs, ce qui signifie que tout enregistrement unique doit appartenir à un seul sous-type. sample subtype relationships Les sous-types peuvent avoir des sous-types imbriqués qui différencient davantage les occurrences. Les sous-types des diagrammes sont logiques, mais ils peuvent être mappés avec une représentation physique de l'une des trois façons suivantes. La solidité de la bordure de l'entité du sous-type définit comment le sous-type est implémenté dans le modèle de données Salesforce. sample supertype Les entités de sous-type avec une bordure continue ont un objet réel qui suit les occurrences de ce sous-type. Dans l'exemple présenté ici, le sous-type Utilisateur externe de Contact a une bordure solide, car les Contacts enregistrés en tant qu'Utilisateurs externes sont suivis avec un enregistrement dans l'objet Utilisateur. sample subtype contact object ## Relations Une relation est une association nommée et significative entre deux entités. sample relationships Les marques et le texte sur ou autour des lignes décrivent la cardinalité, le caractère facultatif et le sens de la relation. ### Cardinalité des relations sample relationships legend La cardinalité indique le nombre relatif d'occurrences de chaque côté de la relation. Dans la notation, les extrémités d'une ligne de relation indiquent la cardinalité de la relation à cette extrémité. Une patte d'oie à une extrémité indique que de nombreuses occurrences d'entité à cette extrémité peuvent être associées à chaque occurrence à l'extrémité opposée. L'absence de patte d'oie à une extrémité indique qu'au plus une occurrence d'entité à cette extrémité peut être associée à une occurrence donnée à l'autre extrémité. ### Relations parent-enfant Salesforce prend en charge deux types de [champs de relation](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/field_types.htm#i1435823): champs de recherche et champs parent-enfant (également appelés maître-détail). Les champs Parent-Enfant sont semblables à des références obligatoires, mais ils appliquent un couplage supplémentaire entre les entités associées. Les enregistrements du côté multiple de la relation sont supprimés en cascade lorsque l'enregistrement parent est supprimé. De plus, la visibilité des enregistrements de détail est contrôlée par la visibilité de l'enregistrement parent. Pour illustrer la différence entre une relation parent-enfant et une relation de recherche, les ERD Salesforce empruntent la notation diamant à UML. Un diamant du côté singulier d'une relation signifie que l'entité de ce côté joue le rôle principal dans la relation. L'entité du côté multiple d'une telle relation est le détail ou l'entité enfant et peut être considérée comme contenue dans l'entité parente. ### Optionnalité des relations L'option indique si la relation est requise ou non pour une occurrence à chaque extrémité. En tant que concept, l'optionnalité est étroitement liée à la cardinalité et la notation reflète cette proximité. L'option est indiquée à chaque extrémité d'une relation par un cercle ou une barre en travers de la ligne à l'autre extrémité de la relation. Pourquoi à l'autre bout de la relation ? Pour inclure la marge d'optionnalité du même côté de la ligne que la cardinalité. Du côté multiple (c’est-à-dire patte d’oie) de la relation, il y a presque toujours un cercle sur la ligne. Cela signifie qu'il peut y avoir de zéro à plusieurs occurrences du côté multiple de la relation pour chaque occurrence du côté singulier de la relation. Du côté singulier de la relation, un cercle et une barre indiquent une relation facultative pour l'entité située du côté patte d'oie de la relation. Le cercle et la barre signifient qu'il peut y avoir zéro ou une occurrence du côté singulier de la relation pour chaque occurrence du côté multiple. Alternativement, du côté singulier de la relation, les barres doubles indiquent une relation requise pour l'entité du côté multiple de la relation. Les barres doubles signifient qu'il doit y avoir une et une seule occurrence du côté singulier de la relation pour chaque occurrence du côté multiple. Le caractère facultatif d'une relation peut être indiqué comme obligatoire, même si la relation physique sous-jacente dans Salesforce est facultative. Par exemple, le champ AccountId dans Contact est physiquement une relation facultative, mais si vous ignorez Contacts privés, la relation directe d'un Contact à un Compte est logiquement requise. L'indicateur d'optionnalité est utilisé avec précaution. Dans la plupart des cas, l'optionalité indiquée dans l'ERD reflète l'optionalité sous-jacente de la relation. ### Sens des relations sample relationships meaning Au-delà de la cardinalité et de l'optionnalité, chaque relation entre deux entités exprime une signification particulière qui distingue cette relation des autres relations entre les deux mêmes entités. Les noms de fin de relation, tels que « partie de » et « composée de » dans le diagramme ci-dessus, définissent la nature de la relation. sample relationships meaning Lorsque vous combinez la cardinalité, l'optionnalité et les noms de fin d'une relation, ils peuvent être utilisés pour former une phrase qui décrit la relation. De gauche à droite : Chaque (peut/doit) être (un et un seul / un ou plusieurs) . De droite à gauche : Chaque (peut/doit) être (un et un seul / un ou plusieurs) . Par exemple, sample relationships meaning De gauche à droite : « Chaque contact doit être principalement un contact pour un seul et unique compte. » De droite à gauche : « Chaque Compte peut être représenté principalement par un ou plusieurs Contacts. » ### Code couleur des relations Les lignes de relation ont un code couleur. Les relations ajoutées par le cloud en focus pour le diagramme sont dessinées dans une couleur. Les lignes noires représentent une relation associée à une licence différente de celle du cloud en focus. sample relationships color ### Relations récursives Les relations peuvent exister entre deux occurrences de la même entité. C'est ce qu'on appelle une relation récursive. Une ligne de relation courbe est utilisée pour indiquer des relations récursives. sample recursive relationships ### Relations mutuellement exclusives sample mutual exclusive relationships Généralement, les DRE Salesforce excluent la plupart des règles métiers pour se concentrer sur la structure du modèle de données, mais une relation mutuellement exclusive est une règle métier qui est informative pour la structure. Une relation mutuellement exclusive indique qu'une seule des relations incluses dans l'arc sera utilisée pour une occurrence donnée. Notez que deux, trois relations ou plus peuvent participer à la même relation mutuellement exclusive. Une phrase décrivant la relation mutuellement exclusive présentée ici pourrait être la suivante : « Chaque entité peut être une instance d'une et d'une seule Première autre entité ou d'une et d'une seule Deuxième autre entité. » sample mutual exclusive relationships Notez que dans les ERD Salesforce, une ligne de relation rompue qui passe par l'arc ne fait pas partie de la relation mutuellement exclusive. ## Conventions de présentation Les ERD officiels de Salesforce respectent les conventions de présentation pour améliorer la lisibilité. Ces conventions de présentation comprennent les suivantes : - Les lignes de relation doivent toujours être droites. - Les lignes de relation doivent être tracées verticalement ou horizontalement. Dans de rares cas où cela n'est pas possible, utilisez une ligne droite sur une diagonale. - Afin de garder les lignes de relation droites, les cases d'entité peuvent être redimensionnées (plus hautes ou plus larges) pour fournir un point de destination aux relations entre les deux entités. Les entités les plus importantes (qui ont plus de relations atterrissant sur elles) sont affichées en plus grand sur le diagramme, renforçant leur importance. - Tout au long d’une même ERD, les pattes d’oie sur les relations doivent être toujours à gauche et/ou en haut de la ligne de relation (présentation à l’envers) – ou toujours à droite et/ou en bas de la ligne de relation (présentation à l'endroit). Cette convention apporte de la clarté, car elle aboutit à des entités similaires réunies dans la même zone du diagramme, ce qui est utile pour comprendre les entités. L'utilisation de la présentation à l'envers entraîne l'affichage de diagrammes à l'envers avec des entités enfants au-dessus ou à gauche des entités parentes. Cependant, cela garantit que les entités les plus spécifiques du diagramme se situent en haut à gauche du diagramme, ce qui rend les diagrammes plus distincts et reconnaissables. L'utilisation de la convention de présentation côté droit entraîne la présence des mêmes entités communes en haut à gauche de chaque diagramme, mais les entités enfants sont sous ou à droite des entités parentes. En respectant étroitement ces conventions de présentation, vous obtenez un diagramme clair et facile à lire. Assurez-vous de consulter la [galerie de modèles de données Salesforce](https://developer.salesforce.com/docs/platform/data-models/guide) pour découvrir les derniers modèles de données Salesforce qui suivent cette norme. # Paysage du système de marketing Customer 360 Data 360 Marketing - un exemple de paysage système - une architecture Customer 360 montrant comment différents composants d'une solution Salesforce intégrée communiquent entre eux en utilisant des connecteurs natifs ## Description Ceci est un diagramme de paysage système pour une implémentation Customer 360, comprenant Agentforce Sales, Agentforce Service, Agentforce Commerce, Tableau et Data 360\. Il montre comment différents composants au sein d'une solution Salesforce intégrée communiquent entre eux en utilisant des connecteurs natifs et des connecteurs personnalisés. Il inclut des capacités telles que l'entrée de données, la résolution de l'identité, la segmentation et l'activation. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/e83190b9-5d7d-4468-aff9-882c9086e73f) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/data-360-marketing.webp) # Paysage du système de vente au détail Paysage du système de vente au détail - Un paysage système montrant une solution B2C Commerce et Marketing, indiquant l'ensemble des produits Salesforce et d'autres technologies impliquées dans l'implémentation. Il inclut des capacités telles que l'automatisation du marketing, la gestion des interactions, le catalogue de produits et la segmentation. ## Description Un paysage système montrant une solution B2C Commerce et Marketing, indiquant le mélange de produits Salesforce et d'autres technologies impliquées dans l'implémentation telles que MuleSoft, Data 360, Agentforce Sales, Agentforce Marketing, Agentforce Commerce et Agentforce Service. Il inclut des capacités telles que l'automatisation du marketing, la gestion des interactions, le catalogue de produits et la segmentation. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/4d6b109a-ea3e-46c2-bab6-84a07efd9ac5) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/retail-system-landscape.webp) # Paysage système Les diagrammes de paysage système offrent une vue complète de l'écosystème technologique d'une organisation, illustrant les relations entre les produits Salesforce, les systèmes externes et les points d'intégration. Ces représentations visuelles aident les architectes à comprendre la topologie complète du système, à identifier les dépendances et à planifier des implémentations stratégiques. Ils servent de documentation essentielle aux parties prenantes pour visualiser comment les différents composants interagissent au sein d'une architecture Customer 360 et soutenir les objectifs métiers. Cette section contient 5 diagrammes de référence associés au paysage système : | Nom du diagramme | Description | | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Customer 360 Marketing System Landscape](/docs/architect/fr-fr/reference-diagrams/guide/data-360-marketing) | Un paysage système pour une implE9mentation de l'architecture Customer 360. | | [Agentforce System Landscape](/docs/architect/fr-fr/reference-diagrams/guide/einstein-system-landscape) | Un paysage système capturant la combinaison de produits Salesforce et d'autres systèmes technologiques disponibles avec Agentforce. | | [Retail System Landscape](/docs/architect/fr-fr/reference-diagrams/guide/retail-system-landscape) | Un paysage système montrant une solution B2C Commerce et Marketing, indiquant la combinaison de produits Salesforce et d'autres technologies impliquées dans l'implémentation. | | [Salesforce Role Hierarchy](/docs/architect/fr-fr/reference-diagrams/guide/salesforce-role-hierarchy) | Exemple de hiérarchie d'organisations, capture d'un sous-ensemble de rôles afin de clarifier la structure métier, les relations du personnel et les modèles d'accès. | | [Single Org Architecture](/docs/architect/fr-fr/reference-diagrams/guide/single-org-architecture) | Un diagramme détaillant une stratégie d'organisation unique soutenant plusieurs unités commerciales. | # Paysage système Agentforce Paysage système Agentforce : un paysage système capturant la combinaison de produits Salesforce et d'autres systèmes technologiques disponibles avec Agentforce. ## Description Un paysage système capturant la combinaison de produits Salesforce et d'autres systèmes technologiques disponibles avec Agentforce. Il montre comment la couche Trust Einstein et la pile IA générative (modèles d'invite, passerelle LLM, modèles externes, BYOM) se combinent à Data 360 pour fournir une fondation puissante sur laquelle élaborer de puissantes applications agentiques. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/28e332b9-b4d5-4780-8220-12e097f0dc58) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/einstein-system-landscape.webp) # Plan de lancement Agentforce Plan de lancement Agentforce - Diagramme détaillant les livrables pour une version initiale de projet d'IA générative. ## Description Un diagramme de feuille de route détaillant les livrables d'une version initiale du projet Agentforce. Il comprend des étapes telles que la définition du projet, la configuration et les tests, la version pilote et la version bêta. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/241905d5-9a36-451d-952a-e43390349502) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/generative-ai-release-plan.webp) # Processus de gestion de la fidélité hôtelière Processus de gestion de la fidélité hôtelière - Interactions temporelles des systèmes dans un processus de gestion de la fidélité hôtelière. ## Description Les interactions temporelles des systèmes dans un processus de gestion de la fidélité hôtelière. Ce flux suit le processus à travers Agentforce Commerce, Agentforce Sales, Agentforce Platform, Data 360, Marketing Cloud Engagement, MuleSoft et des sources de données externes. ## Liens téléchargeables - [Lucide](https://lucid.app/lucidchart/editNewOrRegister/899f5366-4dea-4da7-81af-dc3939aece42) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/hospitality-loyalty-management-process.webp) # Roadmap Les diagrammes de feuille de route aident les organisations à planifier et à visualiser l'implémentation stratégique des capacités, des composants, des fonctionnalités et des systèmes au fil du temps. Ces diagrammes permettent aux architectes et aux chefs de projet de rationaliser la planification des ressources, d'optimiser la budgétisation et d'améliorer la collaboration entre les équipes commerciales et techniques. Ils présentent une vue claire de l'ordre d'implémentation, des dépendances et des priorités, et aident les parties prenantes à comprendre l'approche progressive de livraison de solutions Salesforce complexes. Cette section contient 6 diagrammes de référence liés aux feuilles de route: | Nom du diagramme | Description | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Feuille de route des capacités](/docs/architect/fr-fr/reference-diagrams/guide/capability-roadmap) | Une feuille de route visuelle qui rationalise la planification et la budgétisation des ressources en regroupant les capacités et en identifiant l'ordre d'implémentation, les dépendances et la valeur. | | [Feuille de route des composants](/docs/architect/fr-fr/reference-diagrams/guide/component-roadmap) | Une feuille de route visuelle qui optimise la planification des ressources et la budgétisation en identifiant les fonctionnalités système, les fonctionnalités pertinentes, l'ordre d'implémentation, les délais et les dépendances des parties prenantes. | | [Feuille de route des fonctionnalités](/docs/architect/fr-fr/reference-diagrams/guide/feature-roadmap) | Une feuille de route visuelle qui améliore la collaboration entre les équipes commerciales et techniques en identifiant l'ordre d'implémentation des fonctionnalités, les dépendances et les fonctionnalités supplémentaires à des fins de planification. | | [Plan de lancement Agentforce](/docs/architect/fr-fr/reference-diagrams/guide/generative-ai-release-plan) | Diagramme détaillant les livrables d’une version initiale de projet d’IA générative. | | [Feuille de route Agentforce](/docs/architect/fr-fr/reference-diagrams/guide/generative-ai-roadmap) | Exemple de feuille de route montrant les composants pour le déploiement de l'IA dans le cadre d’une implémentation Salesforce Customer 360. | | [Feuille de route système](/docs/architect/fr-fr/reference-diagrams/guide/system-roadmap) | Simplifiez la planification des ressources et la budgétisation en identifiant l'ordre d'implémentation du système, les dépendances et les priorités des fonctionnalités. | # Traitement asynchrone via des événements de plate-forme Traitement asynchrone via des événements de plate-forme : montre le fonctionnement du traitement asynchrone avec des événements de plate-forme. Les événements publiés dans le bus sont livrés dans l'ordre via publish after commit, puis traités en masse par un flux dans un contexte synchrone séparé. ## Description Le diagramme illustre un flux de processus d'interaction pour le traitement asynchrone en utilisant des événements de plate-forme, montrant comment les événements sont publiés dans le bus d'événements dans le cadre d'un schéma d'architecture plus large. Ce schéma est conçu pour les scénarios dans lesquels un processus doit déclencher un travail en aval sans bloquer la transaction principale, laissant Salesforce gérer le gros du travail de façon asynchrone. ## Liens téléchargeables : - [Lucid](https://lucid.app/lucidchart/editNew/73e12d46-2c45-4d7c-bcf4-a2ca7596ed4c) - [Image](https://architect.salesforce.com/ns-assets/reference-architectures/asynchronous-processing-via-platform-events.webp)