---
schema_version: "1"
id: afbb53532b918ea1785f6ee31152fdb21656367b2b555294493a5d08310535cc
title: Composants standard
collection: architect
version: current
locale: fr-fr
portal_url: https://docs.salesforce.com/architect/current/fr-fr/reference-diagrams/guides/kit-of-parts.md
canonical_url: https://architect.salesforce.com/docs/architect/fr-fr/reference-diagrams/guide/kit-of-parts.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 0dc21c3fe1a77ad100d882c1fa6444a4804e047602825c2d22696814321a67bc
products:
- Diagrammes de référence
- Architect Site Content Repo
updated_at: 2024-09-01T00:00:00Z
---
## 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 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
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.
**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 :
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.
## **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.
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é.
**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.
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).