# architect Bien architecté (well-architected) - Full Documentation > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Une solution Salesforce **adaptable** évolue avec l'entreprise. Une solution bien conçue pour être **adaptable** est résiliente et composable. Les solutions **résilientes** gèrent bien le changement.
Les solutions **composables** s'ajustent rapidement et avec plus de stabilité. Le besoin de changement commercial peut provenir de nombreuses sources : demandes des clients, perturbation du marché ou du secteur d’activité, ou opportunités de transformation numérique. Parfois, les modifications sont petites. Parfois, les changements sont profonds. Au niveau le plus profond, un changement peut obliger les entreprises à repenser et à déplacer leurs raisons principales d'exploitation, et à réévaluer le quoi, comment et où de leurs offres clients. Les architectures **adaptables** n’aident pas seulement les entreprises à survivre et à se relever des interruptions, elles offrent aux entreprises un potentiel d’innovation et de prospérité en période de changement profond. Créer des systèmes **adaptables** nécessite une réflexion architecturale profondément créative et précise. Vous devez commencer par une compréhension précise de la trajectoire à court et à long terme de l'entreprise. En évaluant les détails d'implémentation individuels, vous devez prendre en compte les impacts sur plusieurs dimensions et niveaux de détail. Vous devez penser en termes de personnes, de processus et de technologie. Vous devez prédire simultanément les impacts aux niveaux macro et micro — pour l'état actuel et tous les états futurs. Les sections suivantes fournissent des conseils plus approfondis pour chaque comportement de base d'une architecture de solution **adaptable**. ## Vue d'ensemble adaptable
Résilient
Les solutions résilientes gèrent bien le changement. Les architectures résilientes peuvent rétablir rapidement et de façon prévisible le comportement et les opérations attendus.
Gestion du cycle de vie des applications Réaction incidente Planification de continuité
Gestion des versions
Stratégie environnementale
Stratégie de test
Temps de récupération
Capacité de tri
Surveillance et alerte
Continuité des affaires
Continuité technologique
Composable
Les solutions composables s'ajustent rapidement et avec plus de stabilité. Les architectures composables sont construites dans des unités qui fonctionnent gracieusement les unes avec les autres, et peuvent être échangées et hors service.
Séparation des préoccupations Interopérabilité Packageability
Unités fonctionnelles
Gestion des états
Messagerie et événementiel
Gestion des API
Couplage lâche
Gestion des dépendances
> Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Une solution Salesforce de **confiance** protège les entreprises et les parties prenantes. Une solution bien conçue pour être **confiée** est sécurisée, conforme et fiable. Les solutions **sécurisées** contrôlent l'accès et protègent les données.
Les solutions **conformes** respectent les consignes légales et éthiques.
Des solutions **fiables** fonctionnent de façon efficace et fiable.
La création d'une solution **de confiance** nécessite une planification minutieuse. Vous devez comprendre le contexte de l'entreprise et/ou du secteur d'activité que votre solution sert. Quelle est la tolérance globale au risque de l'entreprise ? Quels types de données vont entrer et sortir du système ? Salesforce servira-t-il de système d'enregistrement ou de point de stockage pour des données avec des considérations de sécurité, de conformité ou d'éthique spécialisées ? Quelles sont les réglementations et normes de conformité pertinentes ? Existe-t-il des normes supplémentaires spécifiques à l'entreprise ? Salesforce est-il un système critique pour l'entreprise ? Y a-t-il des pics saisonniers ou circonstanciels d'utilisation du trafic ou du système que vous devez prendre en compte ? Pour parvenir à une solution **de confiance**, vous devez établir un partenariat avec des parties prenantes dans l'ensemble de l'entreprise. Vous devez avoir une vue claire des types d'utilisateurs et de systèmes qui doivent accéder à votre solution, ainsi que des données et des autorisations requises pour effectuer le travail. Vous devez comprendre les exigences juridiques et sectorielles, ainsi que les politiques et normes internes. Vous devez travailler avec les équipes de développement et de maintenance pour vous assurer que les fonctionnalités sont accessibles et servent les utilisateurs équitablement. Vous devez planifier la disponibilité et les performances des solutions, même en période d'interruption ou de croissance rapide. Rien n'est plus essentiel pour une solution bien conçue que d'avoir **confiance** en soi. Les sections suivantes fournissent des conseils plus approfondis sur les considérations fondamentales relatives à une architecture de solution **de confiance**. ## Présentation approuvée
Sécurisé
Un système sécurisé protège l'entreprise, les parties prenantes et les données. Les architectures sécurisées garantissent que seuls les utilisateurs approuvés peuvent obtenir l'accès, limitent l'accès des utilisateurs aux éléments essentiels pour réaliser le travail et protègent les données du système contre toute atteinte.
Sécurité organisationnelle Sécurité de session Sécurité des données
Authentification
Autorisation
Gestion des sessions
Accès à l'appareil
Détection et réponse aux menaces
Partage et visibilité
Utilisation du cryptage
Conforme
Les solutions conformes respectent les consignes légales et éthiques. Les architectures conformes respectent les réglementations légales et les normes de l'industrie, respectent les politiques éthiques et servent équitablement tous les utilisateurs.
Adhésion légale Normes éthiques Accessibilité
Confidentialité des données
Localisation
Politiques de l'entreprise
Intelligence artificielle
Saisie de données
Navigation
Fiable
Des solutions fiables fonctionnent efficacement et de façon fiable, dans diverses conditions. Des architectures fiables sont disponibles quand et où les utilisateurs attendent, sont performants et évoluent avec l'entreprise.
Disponibilité Performance Évolutivité
Gestion des risques
Atténuation des échecs
Débit
Latence
Modélisation des données
Volume de données
> Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Les systèmes démontrent un comportement automatisé en permettant à l'entreprise d'atteindre les buts et objectifs clés plus rapidement et à grande échelle. Une automatisation saine permet aux utilisateurs de se concentrer sur les tâches à valeur élevée et réduit le temps consacré aux tâches répétitives et manuelles ou à la saisie de données complexes. Le plus souvent, l'automatisation consiste à traduire les processus métiers d'un formulaire à un autre : du formulaire papier au formulaire numérique, d'un ancien système au nouveau. Chaque traduction de processus métier offre une opportunité de transformation. La transformation ne consiste pas à utiliser les nouvelles technologies pour introduire des changements perturbateurs et déroutants pour les utilisateurs. La transformation consiste à créer des méthodes de travail plus simples, à permettre à l'entreprise de se développer sans friction et à permettre aux utilisateurs professionnels de se concentrer davantage sur ce qui compte vraiment pour leurs parties prenantes. D'un point de vue architectural, il s'agit d'identifier les tâches qui peuvent être totalement éliminées, ou traitées automatiquement. Elle nécessite un lien clair entre l'utilisation de la technologie et son impact mesurable sur l'entreprise. Notez un point important à propos de l'automatisation avec Salesforce : elle peut être réalisée avec divers outils, en utilisant des ensembles de compétences par programmation et déclaratives. Concevoir des automatisations bien conçues ne consiste pas à choisir d'élaborer avec un seul outil d'automatisation. Il s'agit d'utiliser des approches cohérentes et prévisibles, et de permettre aux équipes de développer, de tester, de déployer et de maintenir les automatisations que vous concevez. Vos automatisations doivent prendre la forme la plus [maintenable et lisible](/docs/architect/fr-fr/well-architected/guide/intentional) possible. Cette section présente comment concevoir et refactoriser des automatisations pour permettre aux entreprises d'atteindre rapidement et à grande échelle les objectifs clés. Vous pouvez améliorer l'architecture de vos automatisations dans Salesforce en vous concentrant sur l'efficacité et l'intégrité des données. ## Efficacité Pour plus d'efficacité dans vos automatisations, il ne s'agit pas de recréer consciencieusement le statu quo avec les technologies Salesforce. Il s'agit de comprendre en profondeur les métriques clés et les résultats métiers que les équipes devront respecter ou suivre, et de prendre du recul pour observer les [unités fonctionnelles](/docs/architect/fr-fr/well-architected/guide/composable#unités-fonctionnelles) dans et à travers le travail que vous automatisez. Il s'agit d'identifier comment créer des modèles avec vos automatisations qui permettent à l'entreprise de fonctionner plus efficacement et rapidement, à grande échelle. Une logique d'automatisation efficace permettra à vos systèmes : - Plus évolutif et plus utile pour l'entreprise - Plus utile pour les utilisateurs - Plus [adaptable](/docs/architect/fr-fr/well-architected/guide/adaptable-overview) et capable de répondre à l'évolution des besoins métiers Vous pouvez améliorer l'efficacité de vos automatisations grâce à la conception de processus et à la logique opérationnelle. ### Conception de processus La conception de processus consiste à définir les méthodes de travail. L'élaboration de processus efficaces et efficaces signifie que vos conceptions ne se contentent pas de reproduire les méthodes de travail actuelles. Il est essentiel d'identifier et de supprimer les étapes inefficaces ou imprécises. Les processus optimisés doivent créer une valeur métier mesurable (voir [indicateurs de performance](/docs/architect/fr-fr/well-architected/guide/automated#kpis) clés) sans étapes inutiles. Des étapes imprécises ou inutiles créeront probablement une dette technique et entraîneront des automatisations impossibles à maintenir. Souvent, la responsabilité de la découverte et de la documentation des processus métiers incombe à un analyste commercial ou même à un administrateur système. Les architectes sont responsables de collaborer avec ces membres de votre équipe pour s'assurer que vos conceptions de processus sont techniquement solides et bien structurées. L'application de votre Knowledge de la plate-forme Salesforce le plus tôt possible aidera votre équipe à identifier les processus à rationaliser grâce à l'automatisation ou les processus qui doivent changer pour éviter les personnalisations coûteuses. Pour élaborer des processus optimisés pour Salesforce, tenez compte des points suivants : - **Définissez les processus** Les processus dont les objectifs ne sont pas clairs ou dont les définitions sont ambiguës sont plus susceptibles d'être mal interprétés au moment de la conception. Cela entraînera des conceptions erronées basées sur des hypothèses, ce qui entraînera des automatisations incorrectes ou inefficaces. Assurez-vous que les processus métiers que vous souhaitez automatiser respectent les normes suivantes : - Portée d'une fonction unique et spécifique (voir [Unités fonctionnelles](/docs/architect/fr-fr/well-architected/guide/composable#unités-fonctionnelles)) - A des extrants clairement définis et mesurables (voir [Valeur métier](/docs/architect/fr-fr/well-architected/guide/automated#valeur-métier)) - A des entrées et des sorties clairement définies - Bien qu'il soit parfois tentant d'ajouter des étapes supplémentaires qui « pourraient être utiles à l'avenir », cette approche n'est jamais **claire**. Chaque étape d'une automatisation est pertinente pour le résultat du processus global. Assurez-vous que chaque étape du processus présente les caractéristiques suivantes : - Exécute une tâche spécifique et précise (voir [composable](/docs/architect/fr-fr/well-architected/guide/composable)) - Requis pour que le processus génère sa sortie définie (supprimer toutes les étapes non essentielles) - Peut être réalisé en utilisant un nombre minimal de ressources - Utilise les données système existantes au lieu de demander l'entrée des utilisateurs dans la mesure du possible (voir [Engagement](/docs/architect/fr-fr/well-architected/guide/engaging)) - Fournit des options d'entrée que les utilisateurs peuvent comprendre sans avoir à connaître le fonctionnement des systèmes sous-jacents (voir [utile](/docs/architect/fr-fr/well-architected/guide/engaging#utile)) La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/automated#modèles-defficacité-et-anti-modèles) ci-dessous montre à quoi ressemble une optimisation correcte (et médiocre) dans une organisation Salesforce. Vous pouvez les utiliser pour valider vos conceptions d'automatisation avant de les élaborer, ou identifier les automatisations qui doivent être optimisées. Pour plus d'informations sur les outils d'automatisation des processus disponibles dans Salesforce, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/automated#outils-pertinents-pour-automatisé) Automatisé. ### Logique opérationnelle La logique opérationnelle traite de l'efficacité avec laquelle un processus est traduit depuis sa conception jusqu'à sa mise en œuvre réelle. Les automatisations avec une logique opérationnelle forte continuent d'être performantes, quels que soient les pics de volume de transactions ou le nombre d'instances simultanées en cours d'exécution. Logiquement, des automatisations saines aident les entreprises à s'adapter à des niveaux de demande plus élevés. L'intégration d'une logique opérationnelle solide dans vos automatisations est directement liée à la [fiabilité](/docs/architect/fr-fr/well-architected/guide/reliable) globale de votre système. Les automatisations qui ne fonctionnent pas efficacement offrent une expérience utilisateur et client médiocre, entraînant à la fois des pertes de chiffre d'affaires potentielles et une perte de Trust client. Ils ont également des coûts de maintenance plus élevés et peuvent devenir des goulets d'étranglement qui retardent les processus associés, contribuant à des problèmes de performance générale du système. Pour créer une logique opérationnelle efficace dans les automatisations, tenez compte des points suivants : - **Assurez-vous que tous les utilisateurs qui créent des automatisations savent comment procéder**. De mauvais choix de conception peuvent être faits avec tout type d'outil d'automatisation. Le code n'est pas moins sujet aux erreurs ou aux mauvais choix d'implémentation que les outils basés sur le clic. L'utilisation d'ID de référence codés en dur, par exemple, est un anti-modèle affiché dans Flux et dans le code. Les outils basés sur le clic ne doivent pas être considérés comme une licence permettant à tout le monde de publier une automatisation en production. Chaque membre de l'équipe qui crée une automatisation doit savoir comment la construire correctement. Pour plus d'informations sur la définition et l'application de normes efficaces dans vos systèmes, consultez [Normes de lisibilité](/docs/architect/fr-fr/well-architected/guide/intentional#lisibilité) et [de conception](/docs/architect/fr-fr/well-architected/guide/intentional#normes-de-conception). - **Documentez clairement tous les chemins d'exécution**. L'utilisation accrue des automatisations augmente non seulement les volumes de données potentiels, mais également les contextes d'invocation imprévus. Vous devez comprendre comment les différentes automatisations peuvent être invoquées et vous assurer que des contrôles de transaction appropriés (voir Gestion des données) sont affichés dans toutes les automatisations qui ont plusieurs points d'entrée. Par exemple, les flux d"écran ne seront pas exécutés avec des chargements de données en masse, mais les déclencheurs Apex et les flux déclenchés (et lancés automatiquement) le seront probablement. Documenter clairement les parcours d'exécution planifiés et potentiels pour les automatisations est un aspect clé pour comprendre les conditions logiques que vous devrez accepter pendant l'implémentation. - **“Bulkify” toutes les opérations de données (y compris SOQL)**. Chaque opération de données (insertion, mise à jour, etc.) doit être effectuée sur des collections. Toujours. Sans exception. C’est ce que l’on entend par opérations de « mise en masse ». Bien que la plate-forme puisse prendre en charge les opérations de données singleton, vous ne devez jamais autoriser l'implémentation de modèles singleton. - **Utilisez SOSL pour les opérations** de recherche. Il existe une idée fausse selon laquelle les opérations sur les données ne peuvent pas être effectuées sur des enregistrements renvoyés via SOSL. Il est vrai que DML ne peut pas être invoqué directement contre les résultats SOSL, mais un code peut analyser les résultats SOSL et créer une collection qui peut être référencée dans des méthodes de classe DML ou Database. Les principales différences entre SOSL et SOQL résident dans les types de renvoi de chacun et dans leur réponse aux recherches généralisées ou génériques. SOSL peut fonctionner avec plusieurs types de sObject (c'est pourquoi le type de retour est différent) et gérer les recherches de caractères génériques et de chaînes généralisées avec de meilleures performances que SOQL. - **Traitez SOQL comme une opération de données**. N'utilisez pas SOQL pour rechercher des enregistrements, utilisez-le pour affiner vos opérations sur les données. Les opérations SOQL et de données peuvent avoir un impact très similaire sur les performances de la [base de données relationnelle](/docs/architect/fr-fr/fundamentals/guide/platform-multitenant-architecture#la-couche-de-données-de-la-plate-forme) sous-jacente. SOQL peut même transmettre [un indicateur DML explicite](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update) qui verrouille les lignes de la base de données en prévision des opérations sur les données. Pour créer des automatisations évolutives, assurez-vous de traiter SOQL avec la même diligence raisonnable : ne l'utilisez pas sans critères de sélection très spécifiques et bien formés, n'autorisez pas les références de champs inutiles et exigez une correspondance minutieuse des types de données entre les champs et les entrées de filtrage dans la logique d'instruction `WHERE`. Votre code doit également avoir des contrôles appropriés pour garantir qu'une requête ne sera jamais exécutée dans des contextes non traités en masse ou avec des critères de filtrage nuls ou vides. - **Gardez les opérations synchrones strictement concentrées sur le travail qui aide un utilisateur en temps réel**. Pendant votre [optimisation des processus](/docs/architect/fr-fr/well-architected/guide/automated#conception-de-processus), identifiez la logique pertinente pour les actions que les utilisateurs doivent exécuter en temps réel ou en temps quasi réel, et celles qui peuvent être reportées dans une transaction asynchrone (asynchrone). Pour plus d'informations sur la conception d'opérations de synchronisation/asynchronie, consultez [Traitement des données](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-données). La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/automated#modèles-defficacité-et-anti-modèles) ci-dessous montre à quoi ressemble une logique opérationnelle correcte (et mauvaise) dans l'automatisation de Salesforce. Vous pouvez les utiliser pour valider vos conceptions d'automatisation avant de les élaborer, ou identifier les automatisations qui doivent être optimisées. Pour plus d'informations sur les outils disponibles dans Salesforce qui peuvent vous aider à planifier l'échelle, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/automated#outils-pertinents-pour-automatisé) Automatisé. ### KPIs Les indicateurs de performance clés de l'automatisation mesurent l'impact d'une automatisation au fil du temps. Sans eux, vous n'aurez aucun moyen de déterminer si une automatisation ajoute réellement de la valeur métier ou crée une complexité inattendue pour vos utilisateurs. Chaque automatisation que vous élaborez doit être associée à un ensemble clair et mesurable d'indicateurs de performance clés. Les bons indicateurs de performance clés sont définis par une valeur mesurable avec une période associée. Exemples : - \[Nombre X] heures de travail gagnées par mois - Traitement des échecs de saisie manuelle de données réduit de \[Y%] par semaine Lorsque vous avez des indicateurs de performance clés clairs et mesurables, vous devez également comprendre si et comment une automatisation dans Salesforce génère des données pertinentes pour la génération de rapports sur ces indicateurs. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/automated#modèles-defficacité-et-anti-modèles) ci-dessous montre à quoi ressemblent les indicateurs de performance clés appropriés (et médiocres) en ce qui concerne les automatisations Salesforce. Vous pouvez les utiliser pour valider vos indicateurs de performance clés existants ou identifier les points à mieux identifier avant de les élaborer. Pour plus d'informations sur les outils disponibles dans Salesforce pour l'aide sur les indicateurs de performance clés, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/automated#outils-pertinents-pour-automatisé) Automatisé. ### Modèles d'efficacité et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'efficacité dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/easy-efficiency) et anti-modèle.
Modèles Anti-Patterns
Conception de processus Dans votre organisation :
- Chaque flux sert un seul objectif spécifique
- Chaque étape effectue une tâche spécifique, granulaire
- Les flux sont organisés dans une structure hiérarchique composée d'un flux principal et de flux secondaires de support
- Toutes les entrées utilisateur ont un but clair dans le flux
- Les utilisateurs sont invités à fournir des données uniquement lorsque les données système existantes ne peuvent pas être utilisées
Dans votre organisation :
- Les flux servent plusieurs objectifs et nécessitent des entrées supplémentaires pour fournir le contexte
- Les flux nécessitent des entrées dont les données ne sont pas utilisées
- Les groupes d'étapes associés contiennent des fonctionnalités qui chevauchent les groupes d'étapes d'autres flux
- Les flux demandent des entrées utilisateur lorsque des données stockées peuvent être utilisées à la place
Dans Apex :
- Chaque classe sert un but unique et spécifique
- Chaque méthode effectue une tâche spécifique, granulaire
- Toutes les variables d'entrée ont un but clair dans la classe
- L'exécution de code nécessite un nombre minimal de ressources
Dans Apex :
- Les classes servent plusieurs objectifs
- Les méthodes exécutent plusieurs tâches ou les méthodes exécutent des tâches qui ne correspondent pas à l'objectif déclaré de la classe dont elles font partie
- Les variables d'entrée ne sont pas réellement utilisées dans les méthodes
- Les méthodes récupèrent inutilement les données de la base de données ou de systèmes externes
Logique opérationnelle Dans Flux :
- Aucune variable ne référence des valeurs codées en dur (pour des types d'enregistrement, des utilisateurs, etc.)
- Tous les flux et processus lancés automatiquement utilisent des éléments de décision et/ou d'interruption pour évaluer les critères d'entrée et empêcher les boucles infinies ou les exécutions sur des volumes de données importants
- Les flux (y compris les processus) transmettent la logique à Apex dans des contextes de volume de données important
- Les flux secondaires sont utilisés pour les sections d'un processus qui doivent être réutilisées dans l'ensemble de l'entreprise
Dans Flux :
- Les variables ont des valeurs codées en dur
- Les flux (y compris les processus) doivent être désactivés manuellement avant le chargement de données en masse
- Les flux (y compris les processus) déclenchent des avis d'"exception non gérée"
- Même de simples flux entraînent régulièrement des erreurs liées aux limites du gouverneur
- Les parties d'un flux sont répétées à travers les flux plutôt que d'utiliser des flux secondaires
Dans Apex :
- Aucune variable ne référence des valeurs codées en dur (pour des types d'enregistrement, des utilisateurs, etc.)
- Tous les critères génériques sont affichés en SOSL
- SOQL est encapsulé dans try-catch
- Aucun SOQL n'est affiché dans une boucle
- Les instructions SOQL sont sélectives, notamment :
-- aucune utilisation de comparaisons J'AIME ou de comparaisons de texte partiel
-- les opérateurs de comparaison utilisent une logique positive (c.-à-d. INCLUSE, IN) comme logique principale ou uniquement
-- l'utilisation de = NULL, != NULL est rare et/ou suit toujours un opérateur de comparaison positif
-- aucune instruction LIMIT 1 n'est affichée
-- aucune utilisation du mot-clé ALL ROWS
Dans Apex :
- Les variables ont des valeurs codées en dur
- SOSL est rarement ou pas systématiquement utilisé pour les critères de sélection de caractères génériques
- SOQL n'est pas encapsulé dans try-catch
- SOQL affiché dans les boucles
- Les instructions SOQL ne sont pas sélectives, notamment :
-- Les critères de filtrage J'AIME et générique sont affichés
-- les comparaisons utilisant des critères NOT, NOT IN sont utilisées comme opérateur de comparaison principal ou unique
-- = NULL, != NULL critères sont utilisés comme opérateur principal ou seulement de comparaison
-- Affichage des instructions LIMIT 1
-- Le mot-clé ALL ROWS est utilisé
Dans vos normes de conception et votre documentation :
- Les parcours d'exécution planifiés et potentiels pour les automatisations sont clairement indiqués
- Les cas d'utilisation des opérations synchrones et asynchrones dans les automatisations sont clairement décrits dans le cadre des normes de conception
Dans vos normes de conception et votre documentation :
- L'invocation de l'automatisation n'est pas documentée
- Les cas d'utilisation d'opérations synchrones et asynchrones ne sont pas traités
Indicateurs de performance clés Dans votre documentation :
- Les sorties de chaque automatisation sont mesurables et limitées dans le temps
- Les parties prenantes responsables sont répertoriées pour chaque indicateur de performance clé
Dans votre documentation :
- Les indicateurs de performance clés n'existent pas pour les automatisations ou ont des délais de mesure imprécis
- Les indicateurs de performance clés existent sans parties prenantes responsables
Dans des rapports et des tableaux de bord :
- Toutes les métriques associées aux indicateurs de performance clés sont incluses dans au moins un rapport ou tableau de bord
Dans des rapports et des tableaux de bord :
- Les rapports sur les indicateurs de performance clés n'existent pas ou des métriques manquantes sont associées à certains indicateurs de performance clés
## Intégrité des données L'intégrité des données consiste à déterminer si un système conserve des données précises et complètes. Salesforce Platform maintient une [logique de traitement](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#manipulation-de-la-base-de-données) robuste et intégrée conçue pour protéger l'intégrité des données stockées dans la base de données relationnelle d'une organisation individuelle. L'un des principes fondamentaux de l'élaboration d'automatisations saines est de comprendre les comportements d'intégrité des données intégrés à Salesforce, et de vous assurer que toutes vos conceptions d'automatisation respectent (et reconnaissent) ces comportements. Les principaux anti-modèles de conception de l'automatisation proviennent de l'incapacité de reconnaître les puissants services d'intégrité des [données déjà fournis par Salesforce](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#manipulation-de-la-base-de-données) et de l'incapacité d'utiliser une [fonctionnalité standard](/docs/architect/fr-fr/well-architected/guide/intentional#fonctionnalité-standard-par-rapport-à-la-fonctionnalité-personnalisée) qui tire parti de ces services. Pour concevoir des automatisations qui protègent et maintiennent l'intégrité des données, vous devez connaître l'ordre fondamental des comportements de fonctionnement de Salesforce. En étendant correctement l'intégrité des données dans vos automatisations personnalisées, votre système peut : - fonctionner contre des volumes de données en masse et importants sans intervention manuelle, - appliquer les stratégies de sécurité des utilisateurs en cas de besoin et basculer vers le contexte système en cas de besoin, - rencontrent des erreurs à l'exécution et suivent des parcours de reprise ou d'échec prévisibles. Vous pouvez améliorer l'intégrité des données dans vos automatisations Salesforce en traitant correctement les données et les erreurs. ### Traitement des données La première étape de la conception d'un traitement approprié des données dans Salesforce consiste à comprendre comment la plate-forme multilocataire gère [les transactions](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#transactions). Cela comprend la compréhension des comportements [d'exécution](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) intégrés que Salesforce Platform utilise pour garantir l'intégrité des données pendant les opérations de données au niveau de l'enregistrement. Pour plus d'informations sur les impacts de ce comportement, consultez [Manipulation de base](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#manipulation-de-la-base-de-données) de données dans Bases de l'architecture Salesforce. Une mauvaise gestion des données dans vos automatisations peut être l'un des anti-modèles les plus difficiles à identifier et à corriger. La nature récursive et superposée de l'ordre d'exécution de la plate-forme peut rendre difficile l'identification de l'origine des problèmes. La section spécifique d'un code ou d'un flux qui entraîne une erreur fatale ou dépasse les limites du gouverneur peut ne pas être à l'origine d'un problème de traitement des données sous-jacent. La _sensibilisation aux transactions_ est essentielle pour élaborer des automatisations fiables et adaptées à Salesforce. Cela signifie que chaque étape d'une automatisation est conçue en Knowledge de sa position par rapport à l'[ordre d'exécution](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) contrôlé par la plate-forme, peut remplir correctement sa fonction et transmet correctement les informations à l'étape suivante. Quel que soit l'outil d'automatisation que vous utilisez, la sensibilisation appropriée aux transactions suit des modèles similaires et nécessite des considérations communes : - Supposons que chaque automatisation doit être exécutée à tout moment et sans préavis sur des volumes de données importants. Les automatisations doivent avoir des chemins permettant l'exécution par lot ou en masse (voir [Évolutivité](/docs/architect/fr-fr/well-architected/guide/reliable#évolutivité)). - Ne mélangez pas les opérations de données de contexte système et utilisateur dans la même transaction. - Réservez les opérations de synchronisation des données pour les actions [_avant_ contexte](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm) et utilisez des opérations asynchrones pour toutes les actions _après_ contexte. - Utilisez la [messagerie et les notifications](/docs/architect/fr-fr/well-architected/guide/engaging#notifications-et-messages) pour éviter de créer des expériences dans l'application qui obligeraient un utilisateur à attendre les données basées sur les résultats d'une opération asynchrone. Au-delà de la sensibilisation aux transactions, il existe une deuxième dimension au traitement des données : savoir quand réaliser une logique dans différents [contextes d'exécution](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#contexte-dexécution). Les raisons courantes pour séparer les automatisations en différents contextes d'exécution sont les suivantes : - **Opérations de volume important et/ou de données complexes** - [Les opérations de transfert](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-données) en masse ne garantissent pas qu'une automatisation gère correctement les volumes de données importants. Si le volume d'opérations de données dans une automatisation dépasse les limites par transaction, vous devrez effectuer des opérations de données en utilisant une fonctionnalité spécifique aux volumes de données importants (par exemple via Apex batch ou l'[API Bulk 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)). Elles ont des limites en transactions distinctes, adaptées aux volumes de données importants. - Les opérations de données qui doivent traverser des hiérarchies de relations complexes ou effectuer des recalculs complexes (sans inclure les champs de formule) entre les enregistrements peuvent facilement dépasser les limites par transaction lorsqu'elles sont effectuées en masse. Tenez compte du « bruit » d'une mise à jour d'un enregistrement, en termes d'opérations de données associées ou de SOQL nécessaires pour exécuter les actions suivantes dans le système. - Les types de sObjects impliqués dans la chaîne complète d'une automatisation peuvent vous obliger à séparer les opérations de données en transactions séparées afin d'éviter les erreurs « [DML mixtes](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm) ». - **Logique à exécuter dans le contexte utilisateur ou système** - Salesforce Platform impose le [partage et la visibilité](/docs/architect/fr-fr/well-architected/guide/secure#partage-et-visibilité) dans le contexte de l'utilisateur. Si vous devez exécuter des opérations qui dépassent les niveaux d'autorisation des utilisateurs de votre automatisation, assurez-vous que ces opérations sont exécutées dans le contexte système. - Différents outils seront exécutés ou non dans différents contextes : - Apex sera exécuté par défaut en contexte système. Vous pouvez contrôler si et comment les comportements Apex appliquent les règles de partage au niveau de l'utilisateur en utilisant des [mots-clés de partage](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user) dans une définition de classe Apex. - Le flux n'a pas de comportement par défaut unique. Un flux est exécuté dans le contexte de l'utilisateur ou du système [selon son lancement](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5). Vous pouvez appliquer automatiquement le partage dans le contexte système. - Les processus (c'est-à-dire les automatisations élaborées avec le Générateur de processus) sont exécutés dans le contexte système sans considérations de partage. (Note : Nous recommandons d'élaborer des automatisations à faible code avec Flow. - **Logique qui doit être exécutée de façon asynchrone** - Opérations système externes : les appels externes synchrones ou les actions qui accèdent à des données externes ne sont inclus dans aucun comportement de restauration de la plate-forme. Pour tirer parti de ces comportements, vous devez placer les actions impliquant des systèmes externes dans des transactions séparées (en utilisant des méthodes [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm) asynchrones, des [chemins asynchrones](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234) ou des [actions invocables](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm)). - Concours complet et messagerie - Pour contrôler le flux d'événements ou de messages liés aux opérations sur les données (et tirer parti des comportements d'annulation de la plate-forme), placez toutes les actions liées à la messagerie ou aux événements dans des contextes [_postérieurs_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm), en utilisant des méthodes Apex asynchrones. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/automated#modèles-dintégrité-des-données-et-anti-modèles) ci-dessous montre à quoi ressemble le traitement correct (et médiocre) des données dans les automatisations Salesforce. Vous pouvez les utiliser pour valider vos conceptions d'automatisation avant de les élaborer, ou identifier les automatisations qui doivent être refactorisées pour améliorer le traitement des données. Pour plus d'informations sur les outils disponibles dans Salesforce pour le traitement des données dans l'automatisation, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/automated#outils-pertinents-pour-automatisé) Automatisé. ### Traitement des erreurs Le traitement des erreurs est essentiel pour l'intégrité des données. Un traitement efficace des erreurs aide également votre système à évoluer et à vieillir avec plus de [résilience](/docs/architect/fr-fr/well-architected/guide/resilient). Une mauvaise gestion des erreurs dans les automatisations peut entraîner : - Incohérences dans les enregistrements et autres problèmes d'intégrité des données - Envoi de notifications imprécises aux utilisateurs et à d'autres systèmes - Perte de temps et de ressources en traitement manuel ou répété - Manque général de [Trust](/docs/architect/fr-fr/well-architected/guide/trusted-overview) dans un système Le traitement des erreurs dans les automatisations nécessite de donner à n'importe quel processus en cours la capacité d'analyser une erreur pour rechercher des informations, d'accéder à une logique sur les étapes suivantes basées sur les informations d'erreur, puis de suivre le chemin correct. Ces capacités n'ont pas besoin d'être renforcées à chaque automatisation (c'est un [anti-schéma d'optimisation](/docs/architect/fr-fr/well-architected/guide/automated#conception-de-processus)). À la place, chaque automatisation du système devrait avoir la possibilité de se connecter aux [composants](/docs/architect/fr-fr/well-architected/guide/composable#couplage-lâche) de traitement des erreurs appropriés. Pour intégrer des contrôles de gestion des erreurs appropriés à vos automatisations, posez les questions suivantes : - Qu'est-ce qu'une erreur « fatale » ? - Qu'est-ce qu'une erreur « récupérable » ? - Pour les automatisations déclenchées par des actions utilisateur, comment l'automatisation peut-elle détecter et notifier l'utilisateur des erreurs avant de tenter d'engager des modifications ? Une fois que vous avez décidé comment gérer ces erreurs, vous pouvez commencer à intégrer un traitement efficace des erreurs dans vos automatisations. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/automated#modèles-dintégrité-des-données-et-anti-modèles) ci-dessous montre à quoi ressemble le traitement correct (et médiocre) des erreurs dans une automatisation Salesforce. Vous pouvez les utiliser pour valider vos conceptions d'automatisation avant de les élaborer, ou identifier les automatisations qui doivent être refactorisées pour améliorer le traitement des erreurs. Pour plus d'informations sur les outils disponibles dans Salesforce pour le traitement des erreurs, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/automated#outils-pertinents-pour-automatisé) Automatisé. ### Modèles d'intégrité des données et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'intégrité des données dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/easy-data-integrity) et anti-modèle.
Modèles Anti-Patterns
Traitement des données Dans votre dictionnaire de données :
- Données au niveau du champ et logique de priorisation pour toutes les sources de données et objets lac de données
- Le mappage de champs entre un objet lac de données et un objet modèle de données existe
Dans votre dictionnaire de données :
- Les données au niveau du champ et la logique de priorisation des sources de données et des objets lac de données ne sont pas incluses
- Mappage de champs entre des objets lac de données et des objets modèle de données n'est pas inclus
Dans votre Apex :
- Toutes les instructions DML synchrones ou méthodes de classe Database sont exécutées dans des contextes d'exécution avant déclenchement
- Les invocations Apex asynchrones utilisent des files d'attente pour 'enchaîner' des DML complexes entre les transactions
- Apex par lot est utilisé exclusivement pour des volumes de données importants
- @future Apex n'est pas utilisé ou utilisé avec précaution, pour les appels externes ou l'objet système DML
Dans votre Apex :
- Les instructions DML sont régulièrement affichées dans le code qui sera invoqué dans les contextes après le déclenchement
- Apex asynchrone est rarement utilisé
- Les fonctionnalités Apex asynchrones sont utilisées arbitrairement, notamment:
-- Les méthodes futures et Apex Queueable sont utilisées de façon incohérente ou interchangeable
-- Les opérations de base de données n'ont pas de logique claire et cohérente pour transmettre l'exécution à Apex par lot en cas de besoin
Dans Flux :
- Tous les flux lancés dans le contexte de l'utilisateur excluent toutes les transactions du contexte système dans des flux secondaires, qui sont régulièrement placés après un élément Interrompre, pour créer une
- Des séquences complexes d'opérations de données associées sont créées avec Orchestrateur (au lieu d'invoquer plusieurs flux secondaires dans un flux monolithique)
- Tous les flux déclenchés par un enregistrement ont des valeurs d'ordre
- Les flux impliquant des appels système externes ou des processus longs utilisent des chemins asynchrones
Dans Flux :
- De grands flux monolithiques tentent de coordonner des séquences complexes d'opérations de données associées (avec ou sans flux secondaire)
- Les flux déclenchés par un enregistrement n'utilisent pas du tout les attributs d'ordre de déclenchement ou n'utilisent pas de façon cohérente les valeurs d'ordre de déclenchement
- Les parcours asynchrones ne sont pas utilisés de façon cohérente ou du tout
Dans votre organisation :
- Les règles de réconciliation de résolution de l'identité suivent la logique de priorisation de votre dictionnaire de données
Dans votre organisation :
- Les règles de réconciliation de résolution de l'identité ne suivent pas la logique de priorité dans le dictionnaire de données
Traitement des erreurs Dans Apex :
- Le code enveloppe toutes les étapes DML, SOQL, appels externes et autres étapes critiques du processus dans des blocs d'essai
- Des exceptions personnalisées sont utilisées pour créer un message d'erreur avancé et une logique
- Dans des contextes asynchrones et en masse, les méthodes de classe Base de données sont utilisées au lieu de DML
- Les méthodes de classe de base de données peuvent être utilisées exclusivement pour toutes les opérations de données (au lieu de DML)
Dans Apex :
- DML, SOQL, appels externes ou autres étapes critiques du processus ne sont pas toujours encapsulés dans des blocs d'essai
-Les instructions System.debug sont affichées dans le code de production (et ne sont pas commentées)
- Aucune méthode de classe Database n'est utilisée
- Les opérations sur les données sont effectuées exclusivement avec DML
Dans Lightning Web Components (LWC) :
- JavaScript enveloppe toutes les opérations de données et les étapes critiques du processus dans les blocs if ()/else if ()
- Toutes les fonctions @wire utilisent des propriétés de données et d'erreur fournies par l'API
- Tous les énoncés si (erreur)/si (erreur) contiennent une logique de traitement des erreurs et fournissent des messages informatifs
Dans LWC :
- JavaScript n'utilise pas toujours if ()/else if () bloque avec des opérations de données ou des étapes de processus critiques
- les fonctions @wire n'utilisent pas les données et les propriétés d'erreur fournies par l'API (ou ne les utilisent pas de façon cohérente)
- Si elles sont utilisées, les instructions if (error)/else if (error) ne contiennent pas réellement de logique pour traiter les erreurs et fournir des messages d'erreur utiles
Dans Aura :
JavaScript regroupe toutes les opérations de données et les étapes critiques du processus dans des blocs d'essai
- Dans les blocs try-catch, l'erreur JavaScript native est utilisée dans les instructions throw (pas d'utilisation de $A.error())
- Toute la logique d'erreur récupérable est affichée dans les instructions de capture et fournit des messages utilisateur clairs
Dans Aura :
JavaScript n'enveloppe pas de façon cohérente les opérations de données et les étapes critiques du processus dans des blocs d'essai
- Les composants utilisent $A.error()
- La logique d'erreur récupérable n'est pas toujours affichée dans les relevés de capture et les messages d'erreur aux utilisateurs ne sont pas clairs
Dans Flux :
- Les flux d'écran utilisent régulièrement des connecteurs de défaut pour afficher les erreurs aux utilisateurs
- Les messages d'erreur personnalisés sont configurés pour les erreurs affichées à l'écran
- Les flux avec des opérations de données, des appels externes et d'autres logiques de traitement critiques ont des chemins de défaut pour toutes les actions clés
Dans Flux :
- Les flux n'utilisent pas les chemins de défaut de façon cohérente ou du tout
- Les messages d'erreur personnalisés ne sont pas utilisés. Par conséquent, les utilisateurs affichent le message par défaut « Une erreur non gérée s'est produite dans ce flux ».
## Valeur métier Le concept de valeur métier, dans le contexte de l'automatisation, consiste à déterminer dans quelle mesure les processus créent un impact mesurable et positif pour les parties prenantes de l'entreprise. Idéalement, l'automatisation des processus permet aux utilisateurs de consacrer moins de temps à des tâches répétitives et de faible valeur. Il contribue également à renforcer l'intégrité des données en éliminant les activités de traitement manuelles qui peuvent entraîner des erreurs. De la même façon que la [conception de processus](/docs/architect/fr-fr/well-architected/guide/automated#conception-de-processus), l'identification et la livraison d'automatisations qui généreront une réelle valeur métier nécessitent un travail qui va au-delà de la découverte de base et de l'analyse métier. Parfois, il peut sembler que la meilleure façon d'offrir de la valeur à l'entreprise est simplement d'automatiser chaque processus demandé par un utilisateur professionnel, soit dans l'ordre dans lequel il est affiché dans votre backlog (ou file d'attente de billetterie), soit en fonction de facteurs politiques dans votre organisation. Cela peut entraîner deux problèmes liés : construire des automatisations dans un ordre non optimal et construire des automatisations incorrectes. Le premier problème, une mauvaise priorisation, empêche la mise en œuvre des processus à valeur élevée quand ils le devraient, ce qui peut ralentir la croissance. Le deuxième problème, l'élaboration d'automatisations incorrectes, non seulement retarde la livraison d'automatisations à valeur élevée, mais entraîne également un temps perdu, des coûts inutiles et une frustration accrue parmi les équipes de livraison. Vous pouvez accroître la valeur métier en vous concentrant sur les indicateurs de performance clés et la priorisation. ## Outils pertinents pour Automatisé
OutilDescriptionEfficacitéIntégrité des donnéesValeur métier
Lot ApexEnregistrements par lot et traitement des segments maniablesXX
Apex Future MethodsExécuter de façon asynchrone des méthodes Apex en arrière-planXX
Apex Queueing Ajouter des tâches Apex à une file d'attente et les surveillerXX
Apex SchedulerExécuter de façon asynchrone des classes Apex à des heures spécifiéesXX
ApprobationsSpécifier les étapes requises pour approuver les enregistrementsXX
Asynchronous ApexExécuter un code Apex de façon asynchroneXX
Actions automatiséesExécuter des mises à jour de champ, des envois d'e-mails et d'autres actions en arrière-planXX
Einstein Next Best ActionAfficher les recommandations appropriées aux bonnes personnes au moment opportunXX
Alerte par e-mailCréer et envoyer des e-mails automatisésXX
Actions d'escaladeSpécifier les actions automatisées à exécuter pour les escalades de requêtesXX
Mise à jour de champMettre à jour les valeurs de champ en fonction de l'automatisationXX
Flow BuilderÉlaborer des automatisations avec une interface par pointer-cliquerXX
Extensions de fluxAccéder aux variables stockées en tant qu'entrées de composant dans des fluxX
Bibliothèque de modèles de fluxUtiliser des modèles pour concevoir des flux spécifiques au secteur d'activitéXX
Déclencheur de fluxAutomatiser les processus métiers complexesX
Actions invocablesAjouter une fonctionnalité Apex à des fluxXX
OrchestrateurCréer et gérer des automatisations à plusieurs étapesXX
Message sortantEnvoyer des informations à partir d'un processus automatisé avec des reçus et des tentatives X
Publication d'événements de plate-forme avec un fluxPublier des événements via des interactions utilisateur et des automatisationsX
Optimiseur de requêteUtiliser la sélectivité et les index pour améliorer les performances des requêtes, des rapports et des vues de listeXX
Flux SalesforceCréer des automatisations de processus déclaratives avec Flow BuilderXX
Envoi de notifications avec des fluxEnvoyer des messages par SMS, WhatsApp ou Facebook MessengerXX
Envoi de notifications avec des processusEnvoyer des messages par SMS, WhatsApp ou Facebook MessengerXX
Modificateur SOQL FOR UPDATEVerrouiller les enregistrements pour éviter les conditions de course et les problèmes de sécurité des threadsX
Stratégie BuilderIdentifier les recommandations à exposer dans les pages d'enregistrementXX
SubflowsRéduire la complexité des flux en les réutilisantX
S'abonner à des événements de plate-forme avec un fluxRecevoir les messages publiés via des automatisationsX
Actions de tâcheDéterminer les détails d'attribution donnés à un utilisateur par une automatisationX
## Ressources relatives à Automatisé
RessourceDescriptionEfficacitéIntégrité des donnéesValeur métier
Exécution Apex Gouverneurs et limitesDécouvrez comment le moteur d'exécution Apex applique les limitesXX
Ressources de gestion par lotCréer, gérer, planifier et surveiller des tâches par lotXX
Meilleures pratiques pour SOQL et SOSL Améliorer les performances de requête des applications avec des volumes de données importantsX
Modèle Design StandardsCréer des normes de conception pour votre organisationXXX
En masse de flux dans les transactionsConcevoir des flux pour fonctionner avec des collectionsXX
Considérations relatives aux données de fluxDécouvrez les flux déclenchés par une planification pour des données par lotXX
Débogage de fluxTester et dépanner les fluxX
Comment les demandes sont traitéesDécouvrez comment Salesforce traite les tâches rapidement et réduit les échecsXX
Modèle de feuille de calcul KPIDéterminer la valeur métier d'une métrique particulièreXX
Passer des appels externes à des systèmes externes à partir d'actions invocablesAppeler des systèmes externes à partir d'un flux en utilisant ApexX
Opérations DML mixtesConnaître les sObjects qui peuvent être utilisés ensemble pour DML dans la même transactionXX
Ordre d'exécutionComprendre l'ordre des événements pour les insertions, les mises à jour et les mises à jour/insertionsXX
FAQ sur les plans de requêteOptimiser les requêtes impliquant des volumes de données importantsXX
Considérations relatives aux flux déclenchés par une planificationComprendre les comportements spéciaux des flux déclenchés par une planificationX
Contrôle des transactionsGénérer un point d'enregistrement qui spécifie l'état actuel de la base de donnéesXX
Que se passe-t-il lorsqu'un flux échoue ?Comprendre le traitement des erreurs dans les fluxXX
Guide des meilleures pratiques d'automatisation des workflowsPremiers pas avec l'automatisation de SalesforceXXX
Utilisation de requêtes SOQL très volumineusesÉcrire des requêtes SOQL plus efficacesX
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Les solutions composables s'ajustent rapidement et avec plus de stabilité. Un système conçu pour être composable est construit dans des unités significatives, ou blocs de construction, qui peuvent fonctionner gracieusement les uns avec les autres et peuvent être facilement échangés dans et hors service. L'intégration de la composition dans un système permet d'introduire de nouvelles fonctionnalités ou de supprimer une dette technique en refactorisant ou en réassemblant des unités individuelles d'un système. La composabilité permet des cycles de livraison et des versions plus rapides et plus prévisibles, car les équipes peuvent se concentrer sur l'élaboration et la livraison de fonctionnalités significatives avec de petites quantités de modifications. Les systèmes composables permettent aux entreprises de s'adapter plus rapidement et avec plus de stabilité, que le stimulus soit interne à l'entreprise ou causé par des facteurs externes. La composabilité aide les systèmes à être plus [résilients](/docs/architect/fr-fr/well-architected/guide/resilient) et peut aider à rendre les solutions et les modèles architecturaux plus [intentionnels](/docs/architect/fr-fr/well-architected/guide/intentional). Vous pouvez rendre vos solutions Salesforce plus composables en élaborant trois habitudes clés : séparation des préoccupations, interopérabilité et empaquetage. Ci-dessous, vous pouvez voir la relation de ces habitudes de deux façons : pour une unité unique de dans un système composable, et à travers plusieurs unités dans un système composable. Unité unique et composable : Ceci est un diagramme montrant comment les rubriques de composable sont liées à travers trois cartes imbriquées. La carte la plus interne est une unité fonctionnelle, la couche suivante est l'interopérabilité et la couche externe est l'empaquetage. Un système composable: Ceci est un diagramme montrant comment les rubriques de composable sont liées à travers trois cartes imbriquées. La carte la plus interne est une unité fonctionnelle, la couche suivante est l'interopérabilité et la couche externe est l'empaquetage. ## Séparation des préoccupations Concept fondamental du génie logiciel et de l'architecture système, la _séparation des préoccupations_ consiste à identifier diverses préoccupations au sein d'un système plus large qui peut être séparé en unités modulaires. Pour parvenir à une forte séparation des préoccupations au sein d'un système, il faut créer des unités pertinentes pour la logique d'application et les fonctions dans l'ensemble du système. Les unités plus petites aident les équipes de livraison et de maintenance d'applications à comprendre comment et où apporter des modifications, en limitant au maximum les interruptions dans le système plus grand. Les unités plus petites indiquent également clairement comment et où orienter le travail en traitant [la dette technique](/docs/architect/fr-fr/well-architected/guide/intentional#dette-technique) et contribuent à la [lisibilité](/docs/architect/fr-fr/well-architected/guide/intentional#lisibilité) générale de votre système. Vous pouvez mieux séparer les préoccupations dans votre organisation Salesforce en vous orientant vers les capacités métiers et l'état de gestion. ### Unités fonctionnelles Pour les systèmes Salesforce, la meilleure approche pour séparer les préoccupations applique une perspective orientée métier afin d'identifier et d'organiser les unités (ou capacités) modulaires au sein du système. Ceci est différent d'une vue orientée vers l'ingénierie, qui identifie les unités en fonction de leur fonction technique. Une perspective orientée métier dans la séparation des préoccupations nécessite d'organiser le code et les personnalisations dans votre système en fonction du service qu'ils fournissent aux utilisateurs professionnels et professionnels. Adopter cette approche ne signifie pas ignorer le potentiel de fonctions techniques redondantes ou dupliquées dans un système. Cela signifie plutôt que les services techniques sont clairement mappés avec un principe d'organisation qui est finalement transparent pour l'entreprise. S'orienter vers les capacités métiers permet de s'assurer que les transferts entre les équipes d'analyse métier et de découverte vers les équipes de livraison sont aussi simples que possible. Si les générateurs d'applications n'ont aucune idée de l'emplacement où leurs unités de travail sont mappées avec votre architecture composable, vous n'avez pas de paysage d'application composable. Les mappages imprécis entre l'état final requis par l'entreprise et les unités modulaires d'une organisation augmentent également les chances que des équipes de développement ou des fournisseurs construisent des fonctions redondantes dans le système. Tenez compte des points suivants pour orienter les unités fonctionnelles vers les capacités commerciales : - **Commencez par les tâches à faire**. Concentrez-vous sur les tâches à réaliser (JTBD) des utilisateurs et de l'entreprise elle-même. Lancée par Tony Ulwick, l'approche JTBD est centrée sur la compréhension du « travail », ou véritable objectif, que les gens tentent d'accomplir en utilisant un produit ou un service. C'est un niveau d'abstraction supérieur à celui des tâches associées au rôle des utilisateurs ou des étapes individuelles d'un processus métier. Par exemple, des tâches telles que les contrôles dupliqués et les validations d'adresses peuvent appartenir à une fonction d'ordre supérieur « établir une vue unique du client ». Lorsque vous avez une idée claire de ces capacités métier de niveau supérieur, vous pouvez commencer à mapper des parties de votre système avec elles. - **Orienter vers les capacités, pas vers les structures hiérarchiques**. La hiérarchie interne de vos unités commerciales n'est pas un proxy pour des capacités significatives ou des tâches à réaliser. La hiérarchie interne de votre entreprise a un impact important sur les processus et les structures de l'équipe (sans parler des budgets). Ce sont des considérations logistiques importantes. Mais les besoins fonctionnels de l'entreprise fonctionnent à un niveau d'abstraction plus élevé que la logistique. Si vous créez un module pour servir une structure hiérarchique au lieu d'une fonction d'ordre supérieur, notez qu'il peut être nécessaire de prendre des mesures supplémentaires pour identifier la relation entre ce module et les capacités métiers. - **Soyez itératif**. Commencez par établir un partenariat avec l'entreprise afin d'identifier les capacités qui pourraient fonctionner pour un produit minimum viable (MVP). Lorsque vous identifiez une capacité, commencez à élaborer ce MVP. Pendant l'élaboration, identifiez les processus, les métadonnées et les [événements ou messages](/docs/architect/fr-fr/well-architected/guide/composable#messagerie-et-événementiel) qui sont essentiels à l'unité fonctionnelle que vous créez. Identifiez tous les processus, métadonnées et événements ou messages qui sont des dépendances externes. À mesure que des unités plus fonctionnelles sont conçues, implémentez la [gestion des API](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-api) et la [gestion des dépendances](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-dépendances) pour élaborer des unités qui fonctionnent bien les unes avec les autres (au lieu de construire des unités cloisonnées). La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/composable#séparation-des-préoccupations-schémas-et-anti-schémas) ci-dessous montre à quoi ressemble une orientation correcte (et mauvaise) de la fonction métier dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils disponibles dans Salesforce pour vous aider à mieux vous orienter vers les capacités métiers, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/composable#outils-pertinents-pour-composable) Composable. ### Gestion des états La gestion de l'État est centrée sur la circulation de l'information à travers un système à divers moments dans le temps. Une gestion efficace des états permet aux applications de gérer des flux de données ou des interactions complexes avec un minimum de résultats imprévus ou indéterminés. La gestion de l'état dans une organisation Salesforce modulaire nécessite d'élaborer des chemins clairs pour les flux logiques dans et entre les unités, ainsi que des chemins gracieux pour les comportements d'exécution imprévus. La gestion d'état permet de former des flux logiques cohérents à partir d'unités d'application Salesforce modulaires. Dans la plupart des cas, cela nécessite [une interopérabilité](/docs/architect/fr-fr/well-architected/guide/composable#interopérabilité) pour structurer le flux d'informations entre les unités. Les difficultés de gestion des états entre des unités faiblement couplées entraînent souvent un développement d'application monolithique dans Salesforce. Vous pouvez le voir dans les grands « monoflux », qui sont construits pour tenter d'orchestrer un processus complexe dans un flux singulier. Un autre exemple est celui des classes Apex massives, qui orchestrent des processus complexes à travers _un code spaghetti_, ou une longue série de méthodes à usage unique. Ces types d'architecture d'application rendent la refactorisation et le débogage difficiles et augmentent les temps d'intégration pour les nouveaux membres d'équipe ou fournisseurs. Ils réduisent également la valeur des applications livrées à l'entreprise, car les fonctionnalités ne sont pas réutilisables. Tenez compte des points suivants pour gérer l'état dans une organisation Salesforce modulaire : - **Déterminez quand utiliser des schémas stateful par rapport à stateless**. Les modèles Stateful conservent les informations dans tout un parcours d'exécution, pas les modèles sans état. Dans un système faiblement couplé, les modèles sans état permettent de refactoriser les composants plus rapidement et avec moins d'effets secondaires. Cependant, les modèles sans état d'âme ne sont pas adaptés à tous les cas d'utilisation. Si vous élaborez des composants pour des opérations sur les données, les modèles d'état peuvent faciliter l'intégrité et la cohérence des données dans vos systèmes. Utilisez un schéma avec état si votre composant remplit l'un des critères suivants : - La sensibilisation au placement dans un parcours d'exécution plus important est essentielle au comportement du composant - Le comportement du composant doit changer en fonction des résultats d'une action en aval (par exemple, il doit changer l'exécution en fonction des messages d'annulation/d'erreur/de réussite des composants en aval) - Le composant doit attendre les réponses d'un système externe ou en aval pour terminer son travail - **Créez des catégories pertinentes pour les informations importantes**. _État_ est un terme ambigu qui peut s'appliquer à un éventail d'informations si vaste et si vaste au sein d'une organisation Salesforce (et au-delà) qu'en soi, ce terme n'a presque aucun sens. Une première étape nécessaire à l'élaboration de modèles d'états est donc de créer des catégories _significatives_ pour les parcours d'exécution d'états les plus importants (ou types de comportement d'états) dans votre système. Quelques catégories à prendre en compte : - Navigation et formulaires - Opérations de base de données - Opérations par lot et en masse - Erreurs - **Définissez les états associés aux données en termes de [transactions de base](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#manipulation-de-la-base-de-données)** de données. Les comportements intégrés de la plate-forme vont limiter la majorité des considérations d'état pour les données dans Salesforce. N'essayez pas de gérer ce comportement. Concevez pour et avec. Concevez des solutions qui réduisent ou éliminent la logique des transactions distribuées. (pour plus de détails, consultez [traitement des données](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-données)). - **Identifier les états qui se produisent dans (et entre) les unités fonctionnelles**. En assemblant des unités fonctionnelles dans de plus grands systèmes, tenez compte du fait que vous mélangez le comportement des composants sans état et sans état, et évitez les combinaisons qui pourraient créer des boucles interminables ou des écarts dans le traitement. - **Définissez les transferts**. Déterminez quels composants de schémas de [messagerie ou d'événements](/docs/architect/fr-fr/well-architected/guide/composable#messagerie-et-événementiel) vont utiliser pour transmettre des données relatives à l'état à une autre partie du système. Assurez-vous que vous sensibilisez vos composants aux transactions et [à leur gestion](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-données). N'incluez aucune logique de transaction distribuée dans vos transferts. - **Créez des mappages entre vos diagrammes et états de processus**. Les diagrammes de processus détaillent les étapes qui déplacent les informations à travers votre système à divers moments dans le temps. Un diagramme d'état montre les changements réels dans les informations (l'état). Utilisez la partie du pied de page des métadonnées des formes des [diagrammes Salesforce](/docs/architect/fr-fr/reference-diagrams/guide/kit-of-parts) pour capturer l'évolution de l'état des informations à chaque étape de votre processus. Si vous séparez les diagrammes de processus et les diagrammes d'état, assurez-vous de les lier. Il ne faut pas confondre ce concept avec la capture de l'état actuel et futur des processus ou des paysages du système pendant la conception et la mise en oeuvre, car il ne s'agit pas de l'information qui circule dans le système. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/composable#séparation-des-préoccupations-schémas-et-anti-schémas) ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion de l'état dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les emplacements de votre système qui doivent être refactorisés. Pour plus d'informations sur les outils Salesforce de gestion des états, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/composable#outils-pertinents-pour-composable) Composable. ### Séparation des préoccupations Schémas et anti-schémas Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles de séparation des préoccupations dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/adaptable-separation-of-concerns) et anti-modèle.
Modèles Anti-Patterns
Unités fonctionnelles Dans vos normes de conception :
- Les conventions de nommage indiquent comment désigner une unité fonctionnelle
- Une liste de toutes les unités fonctionnelles actuellement définies (et conventions de nommage associées) existe
- Il existe des normes pour proposer des ajouts ou des modifications d'unité fonctionnelle
Dans vos normes de conception :
- Les normes de conception n'existent pas ou ne traitent pas des unités fonctionnelles et des cas d'utilisation
Dans votre documentation :
- Les diagrammes de paysage système montrent clairement les unités fonctionnelles dans une organisation
- Tous les diagrammes de documentation et de mise en œuvre indiquent clairement l'unité fonctionnelle des composants
- La documentation relative aux composants individuels inclut le mappage des unités fonctionnelles du composant
- Tous les composants d'une unité fonctionnelle peuvent être recherchés et faciles à trouver
Dans votre documentation :
- La documentation sur les composants n'existe pas
- La documentation sur les composants décrit l'unité fonctionnelle à laquelle un composant appartient, mais c'est le seul endroit où la définition de cette unité fonctionnelle apparaît
- Vous ne pouvez pas rechercher une unité fonctionnelle particulière et/ou les recherches n'aident pas à identifier tous les composants dans une unité fonctionnelle
Dans votre organisation :
- Il est possible d'identifier rapidement l'alignement de l'unité fonctionnelle pour un élément de métadonnées donné (par exemple, un flux, une classe Apex, ou une page Lightning)
- Les unités fonctionnelles sont étiquetées en termes commerciaux
Dans votre organisation :
- Il n'est pas possible d'identifier l'alignement des unités fonctionnelles pour des métadonnées
- Les informations sur les unités fonctionnelles sont incohérentes ou inexactes
- Les informations sur les unités fonctionnelles sont étiquetées en termes axés sur l'ingénierie qui n'ont aucun sens pour les utilisateurs commerciaux
Gestion d'État Dans vos normes de conception :
- Les cas d'utilisation de conceptions avec ou sans état sont clairs
- Des schémas approuvés pour la communication sans état d'âme existent
- Il existe des schémas approuvés pour la communication statique
- Des catégories claires pour l'état existent
Dans vos normes de conception :
- Les normes de conception n'existent pas ou ne traitent pas des schémas et des cas d'utilisation d'états/apatrides
Dans votre documentation :
- Chaque composant qui gère la communication par état et/ou sans état indique quel modèle a été implémenté
- Il est possible de rechercher et de retrouver tous les composants qui ont implémenté un schéma stateful/stateless particulier
- Les diagrammes de processus et d'interaction fournissent des détails sur les catégories d'état et les transferts
Dans votre documentation :
- La documentation sur les composants n'existe pas
- La documentation sur les composants décrit le modèle stateful/stateless implémenté, mais c'est le seul endroit où la définition est affichée
- Il n'est pas possible de rechercher un modèle particulier et/ou les recherches n'aident pas à identifier tous les composants utilisant ce modèle
Dans Apex :
- Les points d'enregistrement et les comportements de restauration sont utilisés dans toutes les opérations de données
Dans Apex :
- Les points d'enregistrement et les comportements de restauration ne sont pas utilisés
Dans Flux :
- Chemins de défaut et l'élément Restaurer les enregistrements est utilisé
Dans Flux :
- L'élément Restaurer les enregistrements n'est pas utilisé
## Interopérabilité Dans un système conçu pour l'interopérabilité, les composants peuvent échanger des informations et fonctionner ensemble efficacement. L'interopérabilité est essentielle pour rendre un système modulaire composable plutôt que cloisonné. L'interopérabilité peut s'avérer difficile à atteindre dans un système [peu couplé](/docs/architect/fr-fr/well-architected/guide/composable#couplage-lâche). Vous devez établir des normes pour des méthodes d’intégration cohérentes qui ne compromettent pas l’indépendance entre les unités et la [séparation des préoccupations](/docs/architect/fr-fr/well-architected/guide/composable#séparation-des-préoccupations) globales à travers le système. L'interopérabilité impacte également la qualité de vos expériences utilisateur. Vos utilisateurs s'attendent à ce que les données créées dans une zone (par exemple les informations sur les commandes) puissent être utilisées dans une autre (par exemple les campagnes marketing), et vos générateurs s'attendent à ce que s'ils apprennent à faire quelque chose (par exemple élaborer un flux ou s'authentifier à une API), ils trouvent que les techniques familières fonctionnent lorsqu'ils passent au problème suivant. Ne pas concevoir pour l'interopérabilité entraînera des architectures redondantes, des données répliquées, des processus inefficaces et des coûts de développement et de support accrus. Vous pouvez créer l'interopérabilité dans des systèmes modulaires avec la messagerie et les événements, ainsi qu'avec la gestion des API. ### Messagerie et événementiel Les messages et les événements sont deux façons d'activer les composants à travers un système pour envoyer et recevoir des informations. En termes de contenu qu'ils peuvent véhiculer, les événements et les messages sont similaires. Une différence importante est le comportement de l'expéditeur. Généralement, un composant qui envoie un _message_ envoie des données à une destination spécifique et attend une réponse du destinataire. Par contre, un composant émet un _événement_ lorsqu'un événement s'est produit. Il n'y a pas de destination spécifique, ni d'attente de réponse. Ces différences de comportement supportent différents modèles de communication. Les messages prennent en charge les modèles de communication sans état et les événements prennent en charge les modèles de communication sans état. (Voir [Gestion de l'État](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-états) pour plus d'informations sur cette distinction.) Il est important d'aligner les équipes sur les protocoles et les cas d'utilisation pour la messagerie et les événements. Des normes imprécises peuvent entraîner une combinaison de modèles dans votre système, entraînant : - Problèmes de performance et d'évolutivité lorsque des modèles incorrects sont appliqués à un cas d'utilisation spécifique - Traitement incohérent qui rend le système instable pour les utilisateurs - Des temps de dépannage plus longs et des processus de maintenance plus complexes Tenez compte des points suivants lors de la conception de messages et d'événements pour créer des structures plus vaguement couplées dans votre organisation Salesforce : - **Identifiez les cas** d'utilisation de synchronisation et d'asynchronie. Le concours complet permet des communications vaguement couplées, sans état et asynchrones à travers un système. La messagerie permet des modèles de communication plus étroitement contrôlés, précis et synchrones. Lorsque vous choisissez d'utiliser des messages ou des événements, vous devez déterminer si votre communication doit être synchrone (et potentiellement bloquante) par rapport à asynchrone et non bloquante. - **Définissez soigneusement les structures** de données. La structure de l'information que les composants transmettent entre eux est un élément important pour maintenir un système faiblement couplé gérable et cohérent. (pour plus d'informations, consultez [Gestion des API](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-api)). Une considération clé lors de la conception d'un message ou d'un événement est la fréquence à laquelle la structure de l'information doit changer. Une fois la structure d'un message ou d'un événement définie et implémentée dans votre système, il peut être difficile de gérer les mises à jour, en particulier si l'événement ou le message est déjà utilisé pour envoyer des informations à un système externe. - **Messages de taille** correcte. En général, il est recommandé de limiter la taille des messages. Cependant, il existe également un équilibre entre _la taille_ et _le volume_ des messages. Les systèmes peuvent traiter plus rapidement de petites quantités de données. L'acte de traitement entraîne des frais généraux supplémentaires, car les destinataires doivent déballer, interpréter et déterminer ce qu'ils doivent faire avec les informations qu'ils ont reçues. Ces étapes peuvent prendre un temps négligeable, mais elles peuvent s'accumuler et créer un fardeau pour les systèmes à grande échelle. Évitez les conceptions qui nécessitent que les composants du système traitent successivement de nombreux petits messages pour réaliser un travail. Pour adapter la taille de vos messages, pensez à concevoir des composants en aval avec le minimum de données nécessaires pour traiter et agir avec succès sur la base des informations qu'ils ont envoyées, sans supposer également que chaque composant en aval sera capable de demander ou de traiter de nombreux messages de suivi. - **Conception évolutive**. Des composants faiblement couplés peuvent faciliter l'adaptation de votre architecture. L'élimination des dépendances inter-composants permet aux équipes d'améliorer les performances ou l'évolutivité de n'importe quel composant individuel avec un minimum d'effets sur les autres. Cependant, les composants faiblement couplés introduisent également une complexité importante dans votre architecture à l'échelle (notamment en ce qui concerne l'[état de gestion](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-états)). Identifiez les processus qui doivent avoir une logique ou des dépendances plus étroitement couplées pour des raisons d'expérience utilisateur ou d'intégrité des données valides, et n'essayez pas d'introduire des modèles basés sur l'asynchronisme/l'événement dans ces processus. Utilisez à la place des modèles basés sur la synchronisation/les messages et un traitement approprié des erreurs. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/composable#modèles-dinteropérabilité-et-anti-modèles) ci-dessous montre à quoi ressemblent les messages et événements appropriés (et médiocres) dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les emplacements de votre système qui doivent être refactorisés. Pour plus d'informations sur les outils de messagerie et d'événementiel Salesforce, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/composable#outils-pertinents-pour-composable) Composable. Pour plus d'informations sur le choix d'un modèle ou d'un outil de concours complet pour un cas d'utilisation donné, consultez le [Architect’s Guide to Event-Driven Architecture with Salesforce](/docs/architect/fr-fr/decision-guides/guide/event-driven#key-takeaways). ### Gestion des API L'élaboration d'une interface de programmation d'application (API) de gestion appropriée dans une solution Salesforce permet aux composants individuels de votre système de suivre des modèles de communication prévisibles. Salesforce fournit des API intégrées et sécurisées à utiliser pour communiquer avec des systèmes extérieurs à Salesforce. (pour plus d'informations sur les API Salesforce Platform, consultez [Bases de l'architecture](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#api-de-plate-forme)). Une gestion efficace des API dans les solutions Salesforce est essentielle pour élaborer des architectures véritablement composables. Il permet aux composants d'une organisation Salesforce d'envoyer et de recevoir efficacement des informations. Il permet également aux générateurs de solutions de suivre des protocoles clairs pour la communication des composants qu'ils élaborent avec les autres composants du système, et les aide à identifier rapidement les implémentations incorrectes. De plus, il permet aux concepteurs de solutions de se concentrer plus étroitement sur le composant particulier qu'ils élaborent ou refactorisent, ce qui augmente la productivité et la qualité. La gestion des API au niveau de l'entreprise est une rubrique distincte, qui est plus efficace avec un outil complet de gestion des API. (pour plus d'informations sur la perspective MuleSoft à ce sujet, consultez [Qu'est-ce que la Gestion des API ?](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.)). Tenez compte des points suivants pour élaborer des capacités de gestion d'API dans vos solutions Salesforce : - **Considérez les API comme des modèles _prévisibles_ ou des contrats de communication**. Le type de données des variables d'entrée ou de sortie, les noms des variables, les informations qui doivent (ou non) apparaître dans un schéma donné, voilà les clés d'une gestion efficace des API. Ces définitions doivent figurer dans vos normes de conception, et les équipes doivent pouvoir déterminer comment ces définitions ont été implémentées dans des parties particulières de votre système via votre documentation. Une façon d'examiner les difficultés de fusion des modifications d'un nouveau développement dans un environnement d'intégration est de les considérer comme une preuve de l'emplacement où vous avez mal implémenté les communications d'API (ou peut-être aucune définition d'API du tout). - **Ne limitez pas votre réflexion sur les API à coder exclusivement**. Ce qui définit une API dans ce contexte est la cohérence des structures et des variables de message dans ce message. Tant que cette cohérence est maintenue, une API peut être implémentée dans un code ainsi que dans des personnalisations déclaratives, telles que des flux modulaires lancés automatiquement (ou déclenchés par un événement de plate-forme), ou même des modèles de flux. Basez vos décisions sur les éléments à définir dans le code par rapport aux flux non pas sur l'implémentation de l'API, mais plutôt sur [la capacité](/docs/architect/fr-fr/well-architected/guide/composable#emballage) et [la testabilité](/docs/architect/fr-fr/well-architected/guide/resilient#gestion-du-cycle-de-vie-des-applications) du package. - **Simplifiez votre cycle de vie et la gestion des versions**. Comme toutes les parties du développement d'applications, les API ont un cycle de vie : définir, élaborer, tester, déployer et maintenir (y compris retirer). Les API Salesforce Platform publient plusieurs versions par année civile, en raison du cycle de publication rapide de la plate-forme. (pour plus d'informations sur ce comportement, consultez [Bases de l'architecture](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#api-de-plate-forme) Salesforce). Cela signifie que les API de plate-forme ont un cycle de vie assez complexe, car plusieurs versions d'une API particulière doivent être conservées et disponibles pour les clients de Salesforce. Ce niveau de complexité est approprié pour les cas d'utilisation PaaS, mais il est probablement inutile pour vos architectures de solutions sur plate-forme (voir : [Readablility anti-patterns](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-lisibilité-et-anti-modèles)). Mettez l'accent sur la définition d'un objectif clair pour une API (par exemple, le traitement des erreurs) et des définitions de base claires. Essayez d'avoir une seule version de chaque API. - **Rendez vos API accessibles, accessibles et gérables**. [Documentez vos API](/docs/architect/fr-fr/well-architected/guide/intentional#normes-de-conception) afin de permettre aux consommateurs potentiels de trouver aisément les API disponibles pour s'y connecter. Les API doivent fonctionner correctement dans un paysage de [capacités](/docs/architect/fr-fr/well-architected/guide/composable#unités-fonctionnelles). - **Soyez itératif**. Concentrez-vous sur la définition et l'implémentation d'une seule API interne à la fois. Vous pouvez ainsi vous concentrer sur l'itération rapide de la définition d'API, trouver le formulaire approprié pour votre _unique_ version prise en charge et établir les meilleures pratiques à partir de l'expérience d'implémentation. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/composable#modèles-dinteropérabilité-et-anti-modèles) ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion d'API dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils disponibles dans Salesforce pour renforcer l'interopérabilité, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/composable#outils-pertinents-pour-composable) Composable. ### Modèles d'interopérabilité et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'interopérabilité dans l'[explorateur Pattern & Anti-Pattern](/docs/architect/fr-fr/well-architected-tools/guide/adaptable-interoperability).
Modèles Anti-Patterns
Messagerie et événementiel Dans vos normes de conception :
- Il existe des normes claires pour quand utiliser des modèles synchrones (messagerie) et des modèles asynchrones (soirée)
- Des normes claires existent pour les structures d'événements et de messages
Dans vos normes de conception :
- Il n'existe pas de normes de conception, ou il n'existe pas de normes claires pour les modèles de synchronisation par rapport aux modèles asynchrones, ni de normes claires pour les structures de messages ou d'événements
Dans votre organisation :
- Les événements de plate-forme utilisés pour la messagerie système interne sont clairement étiquetés
- Les outils de flux Salesforce référencent des services de messagerie ou d'événementiel à l'échelle du système
- Des modèles de messagerie et d'événementiel cohérents sont affichés dans les flux et le code
Dans votre organisation :
- Les événements de plate-forme utilisés pour la messagerie système interne ne sont pas clairement étiquetés ou n'existent pas
- Différentes stratégies pour les modèles de messagerie et d'événementiel sont affichées dans le flux et le code
Dans Apex ou LWC :
- La portée des définitions d'événements personnalisés est limitée (aucun événement ou message à l'échelle du système n'est défini dans le code)
- Les services de messagerie ou d'événementiel à l'échelle du système dans Apex sont annotés de manière à les rendre disponibles dans les outils de flux Salesforce
Dans Apex ou LWC :
- Les structures de messages et/ou d'événements à l'échelle du système sont définies en Apex ou JavaScript
- Les structures d'événements ou de messages à l'échelle du système définies dans Apex ne sont pas disponibles dans des outils comme le flux
Gestion des API Dans vos normes de conception :
- Il existe des protocoles clairs pour la communication entre les composants (c.-à-d. des API)
- Les protocoles/API sont indiqués dans des groupes logiques que les générateurs peuvent rechercher et retrouver
- Les protocoles/API définissent les types de données de variables, les noms de variables, ce qui est obligatoire ou facultatif et fournissent une description claire de quand utiliser
Dans vos normes de conception :
- Les normes de conception n'existent pas ou ne définissent pas d'API et de cas d'utilisation
Dans votre documentation :
- La documentation de chaque composant indique clairement quel protocole d'API/communication a été implémenté
- Il est possible de rechercher une API ou un protocole particulier et d'identifier les composants où il est implémenté
Dans votre documentation :
- La documentation sur les composants n'existe pas
- La documentation sur les composants décrit l'API implémentée dans un composant, mais c'est le seul endroit où la définition de l'API est affichée
- Il n'est pas possible de rechercher une API ou un protocole particulier et/ou les recherches n'aident pas à identifier les composants dans lesquels une API ou un protocole a été implémenté
Dans votre organisation :
- Les formats et les variables de message d'API pour la communication interne sont définis avec des types de métadonnées personnalisées
- Les formats et les variables des messages d'API pour la communication interne sont définis avec des événements de plate-forme
- Les personnalisations de code et déclaratives référencent le type de métadonnées personnalisées (ou événement de plate-forme) approprié afin d'envoyer ou de recevoir des informations
Dans votre organisation :
- La communication entre les composants du système (code et personnalisations déclaratives) est ponctuelle
- Les API sont définies exclusivement pour la communication entre Salesforce et des systèmes externes
## Emballage La création d'un package dans une organisation Salesforce signifie que les fonctionnalités de l'organisation proviennent d'unités qui peuvent être développées et déployées indépendamment et de façon fiable, sous forme de packages. Idéalement, ces unités sont définies comme un type de package [de deuxième génération](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm) (un package déverrouillé ou un package géré pour les éditeurs de logiciels). Remarque : Les solutions bien conçues utilisent exclusivement ces types de package. Par conséquent, les packages gérés de première génération ne sont pas traités ici. Définir la [séparation des préoccupations](/docs/architect/fr-fr/well-architected/guide/composable#séparation-des-préoccupations) et créer des unités fonctionnelles dans une organisation Salesforce est une chose. Il est également important de démêler et de gérer les dépendances de façon suffisamment claire pour réussir la version de ces unités en tant qu'artefacts de package. Pour atteindre ce niveau de stabilité et d'isolation des métadonnées, il faut un niveau de maturité DevOps (et architecturale) important. Il accélère également le temps de développement, améliore l'expérience du générateur d'applications, et apporte prévisibilité et contrôle dans les versions et la gestion des versions. Les organisations ne seront pas toutes capables de prendre en charge l'infrastructure requise pour définir, gérer et développer des packages efficaces. Cependant, l'objectif ultime de presque toutes les organisations Salesforce devrait être d'obtenir la possibilité d'empaqueter. Vous pouvez élaborer des packages dans vos solutions Salesforce en vous concentrant sur le couplage lâche et la gestion des dépendances. ### Couplage lâche Dans un système avec couplage lâche, les pièces individuelles ne sont pas fortement liées les unes aux autres. De nombreux avantages d'un système composable proviennent d'un couplage lâche. Dans les systèmes empaquetables, la réalisation d'un couplage lâche entre les packages (et l'installation d'organisations) vous permettra d'avoir des packages bien définis et des cycles de développement plus productifs pour les équipes qui travaillent avec des packages. Sur Salesforce Platform, vous pouvez élaborer des packages [étroitement couplés à une organisation](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm) particulière. Cette capacité est utile pour définir des unités fonctionnelles et expérimenter une bonne [séparation des préoccupations](/docs/architect/fr-fr/well-architected/guide/composable#séparation-des-préoccupations) dans votre organisation, à mesure que vous progressez dans la maturité de l'empaquetage. Cependant, si vous choisissez cette approche, vous ne bénéficierez que de quelques avantages des métadonnées véritablement empaquetables, notamment le développement piloté par la source, la possibilité d'utiliser la gestion des versions et la stabilité des artefacts. À la place, vous allez probablement continuer à éprouver les inconvénients d'un système étroitement couplé, y compris: - Points de défaillance uniques entraînant des pannes et des problèmes de performance - Déploiements lents et imprévisibles - Cycles de débogage et de dépannage difficiles et complexes - Problèmes d'[échelle](/docs/architect/fr-fr/well-architected/guide/reliable#évolutivité) et de [performance](/docs/architect/fr-fr/well-architected/guide/reliable#performances) L'objectif final de tout système Salesforce empaquetable est de coupler des packages vagues. Tenez compte des points suivants pour séparer vos métadonnées Salesforce en packages efficaces : - **Quelles personnalisations sont les données par rapport aux métadonnées** ? En ce qui concerne l'empaquetage, Salesforce Platform traite les données et les métadonnées très différemment. Il est important de comprendre quelles fonctionnalités de votre organisation sont des [métadonnées ou données](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#métadonnées-par-rapport-aux-données). Vous ne pouvez inclure des données dans aucune unité empaquetée. Lorsque vous choisissez où commencer à extraire la fonctionnalité dans une unité empaquetée, vos équipes doivent déterminer si les personnalisations stockées en tant que données doivent être exclues du package ou refactorisées dans une implémentation basée sur des métadonnées. - **L'impact de** l'empaquetage sur les équipes. Une réalité logistique de l'empaquetage Salesforce est qu'une grande partie du travail de production et de publication d'une version de package nécessite une compétence avec les technologies Salesforce CLI et/ou CI/CD. Cela signifie que les personnalisations à faible code et par programmation nécessitent du temps et de l'attention de la part d'une personne capable de travailler avec la technologie DevOps associée au package. Selon la façon dont votre équipe gère la livraison de fonctionnalités, l'adoption de packages peut entraîner des ralentissements ou des blocages importants pour différentes équipes d'une organisation. Vous devrez déterminer si les équipes seront en mesure de gérer la livraison de fonctionnalités via l'empaquetage, et établir un plan pour combler les lacunes en compétences ou en personnel. Les solutions peuvent inclure l'adoption d'une programmation couplée ou l'implémentation de tâches CI/CD pour des environnements de développement. - **Comment l'emballage va changer les stratégies environnementales** Dans un cycle de vie de développement piloté par le package, le travail précoce doit être effectué dans les [organisations tests](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org). Ces environnements de développement temporaires, pilotés par la source, permettent des cycles plus rapides et plus itératifs. Ils prennent également en charge des contrôles d'accès à l'environnement plus précis pour vos équipes de développement et une plus grande isolation de la production. Plus vos packages sont dépendants de métadonnées non empaquetées ou de données qui existent uniquement dans un environnement sandbox ou de production, moins les équipes sont susceptibles d'utiliser des organisations tests. Vous pouvez [activer le suivi de la source dans des organisations sandbox](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm) afin de permettre des modèles de développement pilotés par la source dans des environnements d'organisation non tests, mais vos équipes de développement ne bénéficieront pas de la vitesse et de la vélocité itératives des organisations tests. - **Comment les versions de package sont associées aux versions**. Planifiez la fréquence et le stade de développement de la gestion des versions du package. Les demandes de version de package sont limitées (par organisation) sur une base glissante de 24 heures. La meilleure pratique générale consiste à mettre en version un package uniquement lorsque vous êtes sûr qu'aucun contenu du package ne doit changer. L'idéal est de provisionner des versions de package une fois les processus d'assurance qualité terminés. Ne permettez pas aux équipes de développement d'utiliser la réussite ou l'échec des requêtes de création de packages comme « test » de la qualité de la définition des limites des packages. Il existe plusieurs façons de procéder sans essayer de mettre en version un artefact de package. - **Ce que l'état final idéal devrait soutenir**. La stratégie d'empaquetage idéale permet des versions Salesforce contrôlées et stables qui peuvent être développées et livrées rapidement. La définition d'un nombre excessif de packages dans votre organisation peut générer de nouveaux types de complexité et de blocage pour les équipes de développement. Une organisation trop modularisée peut également entraîner des versions lentes et difficiles. Commencez par élaborer et publier quelques versions d'un package unique et pertinent. Dérivez des packages de suivi de façon incrémentielle. Arrêtez d'introduire des packages lorsque vous avez une cadence de publication qui sert bien votre activité. Refactorisez les packages au fil du temps, si les besoins métiers changent ou si la qualité de la version diminue. L'état final idéal du package est subjectif. Quelle que soit la façon dont vous choisissez de définir vos packages, vous ne réussirez à mettre en version un package faiblement couplé qu'avec une [gestion des dépendances](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-dépendances) efficace. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/composable#modèles-et-anti-modèles-dempaquetage) ci-dessous montre à quoi ressemble le couplage lâche correct (et médiocre) pour l'empaquetage Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce qui facilitent l'élaboration de packages, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/composable#outils-pertinents-pour-composable) Composable. ### Gestion des dépendances Dans le contexte d'une solution Salesforce, la gestion des dépendances consiste à identifier et à structurer les relations entre les métadonnées de vos packages et les métadonnées des organisations dans lesquelles ces packages seront installés. La gestion des dépendances est un élément clé du développement d'artefacts de package stables. Les dépendances peuvent être en contradiction avec les efforts déployés pour créer des unités fonctionnelles parfaitement séparées et [peu couplées](/docs/architect/fr-fr/well-architected/guide/composable#couplage-lâche). Dans un état d'ingénierie idéal, un système faiblement couplé n'a aucune dépendance entre les unités. Dans le monde réel, cependant, l'élimination de toutes les dépendances n'est pas pratique. Souvent, l'équilibre entre la [lisibilité](/docs/architect/fr-fr/well-architected/guide/intentional#lisibilité) des systèmes et l'utilisation d'[unités fonctionnelles](/docs/architect/fr-fr/well-architected/guide/composable#unités-fonctionnelles) conviviales nécessite un compromis en termes d'isolation parfaite entre les unités d'un système. Plus pragmatiquement, les services de base fournis par la [fonctionnalité standard](/docs/architect/fr-fr/well-architected/guide/intentional#fonctionnalité-standard-par-rapport-à-la-fonctionnalité-personnalisée) de Salesforce Platform créent des dépendances clés et nettes pour n'importe quelle solution Salesforce. De nombreux avantages intégrés en matière d'évolutivité, de performance et de sécurité découlent de leur intégration profonde à la plate-forme. Lors de la conception de solutions Salesforce empaquetables, il est important de se rappeler que les dépendances de package ne sont pas intrinsèquement mauvaises. Une mauvaise gestion de la dépendance _est_ mauvaise. Une gestion efficace des dépendances avec le package Salesforce permet aux équipes de développement et de maintenance de : - Accélération de l'intégration à de nouveaux projets et accès limité à l'environnement - Développer et tester rapidement des modifications - Comprendre comment les fonctionnalités complexes doivent être fournies dans des engagements plus petits et spécifiques - Contrôler les cadences de publication et réduire les fenêtres de maintenance/d'arrêt de version du système - Annuler de façon prévisible les modifications défavorables dans n'importe quel environnement Les techniques de gestion des dépendances avec Salesforce sont assez simples : - Utilisez la [messagerie et les événements](/docs/architect/fr-fr/well-architected/guide/composable#messagerie-et-événementiel) pour gérer les transferts gracieux d'informations avec ou sans statut entre les composants. - Utilisez des types de métadonnées personnalisées pour fournir des informations d'exécution dynamiques et prendre en charge les modèles d'injection de dépendance. - Demandez aux développeurs Apex d'utiliser des [classes abstraites ou virtuelles](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm). Au final, vous devrez choisir les modèles de conception autorisés dans votre organisation à travers le développement déclaratif et programmatique. Les considérations les plus importantes (sur le plan architectural) sont de définir où vous souhaitez ajouter plus de complexité d'ingénierie afin d'avoir moins de dépendances, et où vous devez tolérer plus de dépendances pour simplifier les workflows du générateur d'applications. En élaborant des stratégies de gestion des dépendances dans vos packages, tenez compte des deux principaux principes d'organisation des unités de package : horizontal et vertical. - **Frontières horizontales**. Dans les paradigmes horizontaux, les fonctionnalités qui peuvent être nécessaires à plusieurs packages sont abstraites dans une couche horizontale. Les couches horizontales deviennent alors la source de fonctionnalités communes, et sont accédées via une dépendance déclarée. La réduction des fonctionnalités redondantes entre les packages est préférée à la réduction des dépendances. - **Frontières verticales**. Les paradigmes verticaux maximisent l'isolement et le couplage lâche entre les parties du système. Les fonctionnalités partagées sont limitées et un travail similaire peut être affiché entre les unités. Les dépendances sont strictement limitées, afin de maximiser l'isolation entre les unités de package. Notez qu'il ne s'agit pas d'une décision ou d'une décision. Vous pouvez combiner des paradigmes verticaux et horizontaux si nécessaire. Souvent, la méthode la plus rapide pour commencer avec un package est de créer des couches de service horizontales. À mesure que l'échelle et la complexité de l'adoption de votre package augmentent, l'abstraction d'unités verticales supplémentaires simplifie les processus de configuration d'environnement complexes ou l'intégration des développeurs. Un système avec deux unités fonctionnelles (A et B), par exemple, peut être structuré avec des dépendances de package organisées en paradigmes hybrides verticaux, horizontaux et verticaux-horizontaux. Ceci est un diagramme montrant deux packages, A et B, construits pour n'avoir aucune dépendance partagée (tranche verticale), construits pour avoir de nombreux services communs (horizontale) et un mélange de chaque (hybride). Quel que soit le paradigme d'organisation du package que vous choisissez, il y a quelques absolus à garder à l'esprit : - **Ne dupliquez pas les métadonnées entre les packages**. Les métadonnées requises par plusieurs packages doivent être extraites dans un ou plusieurs packages déclarés en tant que dépendances. - **Utilisez les dépendances intégrées des métadonnées Salesforce Platform**. Pour les générateurs d'applications, les services intégrés offerts par Salesforce Platform offrent de nombreuses fonctionnalités qui peuvent être configurées rapidement. Beaucoup de ces services ont des dépendances intégrées qui les rendent difficiles à extraire dans des unités fonctionnelles de bas niveau. Pour un type de métadonnées donné, vous devez comprendre sa position dans le [spectre des dépendances](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail) intégrées et utiliser cette compréhension pour [définir vos chaînes](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2) de dépendance de package. Ne commencez pas à adopter un package en essayant de forcer le couplage libre dans une fonctionnalité de plate-forme standard avec de nombreuses dépendances intégrées. Elle ajoutera de la complexité (pas de la valeur) lorsque vous atteindrez des capacités d'ordre supérieur. C'est aussi une autre façon de tomber dans les [anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-maintenabilité-et-anti-modèles) [standards par rapport](/docs/architect/fr-fr/well-architected/guide/intentional#fonctionnalité-standard-par-rapport-à-la-fonctionnalité-personnalisée) aux modèles personnalisés. Empaquetez les métadonnées depuis le bas (dépendances les plus faibles) vers le haut, puis itérez au fil du temps. - **Attention à vos chaînes de dépendance**. Évitez de créer des chaînes de dépendance de package qui obligeront les développeurs à diviser leurs modifications en plusieurs packages à la fois. - **Réfléchissez à ce qui est logique pour le contrôle de la source**. Il existe deux méthodes de base pour gérer vos packages dans le contrôle du code source. Le premier est un _monorepo_ unique avec des packages isolés dans des dossiers. Le deuxième est le repos multiple avec des packages isolés dans leur propre repos. La gestion à long terme de chaque type de stratégie source est complexe. En termes d'intégration des développeurs, les frontières verticales sont plus efficaces dans plusieurs paradigmes de référentiel. Les frontières horizontales sont plus compréhensibles dans un monorepo. Là encore, vous pouvez combiner et mapper des stratégies à mesure que votre architecture mûrit. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/composable#modèles-et-anti-modèles-dempaquetage) ci-dessous montre à quoi ressemble une gestion correcte (et médiocre) des dépendances avec les packages Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce de gestion des dépendances, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/composable#outils-pertinents-pour-composable) Composable. ### Modèles et anti-modèles d'empaquetage Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'empaquetage dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/adaptable-packageability) et anti-modèle.
Modèles Anti-Patterns
Couplage lâche Dans vos normes de conception :
- Les conventions de nommage indiquent comment désigner les unités de package
- Il est possible de rechercher et de retrouver une liste de toutes les unités de package actuellement définies (et conventions de nommage associées)
- Il existe des normes pour proposer des ajouts ou des modifications d'unité de package
- (Facultatif) Tous les cas d'utilisation approuvés pour des paramètres personnalisés sont clairement répertoriés (si vous en avez)
Dans vos normes de conception :
- Les normes de conception n'existent pas ou ne traitent pas des unités de package et des cas d'utilisation
Dans votre organisation :
- Les types de métadonnées personnalisées fournissent des informations dynamiques à l'exécution pour les personnalisations de code et déclaratives
- Aucun paramètre personnalisé n'existe ou peu de paramètres personnalisés existent, et aucun n'est associé à une fonctionnalité empaquetée
- Aucun objet personnalisé n'existe afin de fournir des informations dynamiques à l'exécution pour les personnalisations de code ou déclaratives
Dans votre organisation :
- Des paramètres personnalisés sont utilisés
- Des objets personnalisés existent afin de fournir des informations dynamiques à l'exécution pour des personnalisations de code ou déclaratives
- Les types de métadonnées personnalisées ne sont pas utilisés (ou ne sont pas utilisés de façon cohérente) pour fournir des informations dynamiques à l'exécution pour les personnalisations de code et déclaratives
Dans Apex :
- Les services courants et le code boilerplate sont définis en utilisant des classes Apex abstraites ou virtuelles
- Les méthodes dépendantes d'informations dynamiques à l'exécution référencent des types de métadonnées personnalisées appropriés
Dans Apex :
- Les services communs et le code de chaudière ne se distinguent pas facilement des autres classes
- Les références internes entre les classes et les méthodes sont difficiles à suivre et sont incohérentes dans la base de code
- Les méthodes n'utilisent pas une approche cohérente pour accéder à des informations dynamiques à l'exécution, ou les méthodes interrogent des objets personnalisés pour des informations sur le comportement à l'exécution, ou référencent des paramètres personnalisés
Dans des environnements de contrôle de source et de développement :
- les fichiers package.xml sont affichés uniquement dans les manifestes de projet à un stade précoce ou de validation de concept
Dans des environnements de contrôle de source et de développement :
- Les fichiers package.xml sont utilisés pour contrôler les déploiements de métadonnées
Dans des packages :
- Les packages déverrouillés dépendants de l'organisation sont utilisés uniquement pour des expériences en phase initiale ou de validation de concept
- Aucun package non géré n'est défini en production ou sandbox
Dans des packages :
- Tous les packages sont des packages déverrouillés dépendants de l'organisation
- Les packages non gérés sont définis en production ou en sandbox
Gestion des dépendances Dans vos normes de conception :
- Des normes de déclaration des dépendances existent
- Des normes d'introduction ou de modification de dépendances existent
Dans vos normes de conception :
- Les normes de conception n'existent pas ou ne traitent pas de la déclaration des dépendances
Dans le contrôle source :
- Les versions de package des packages déverrouillés utilisent l'aliasing (LATEST) pour déclarer les dépendances dans les manifestes sfdx-project.json
- Les développeurs peuvent créer des organisations tests et déployer des métadonnées de package avec succès depuis le contrôle source
Dans le contrôle source :
- Les versions de package pour les packages déverrouillés sont déclarées explicitement (pas dernier alias) dans les manifestes sfdx-project.json
- Les développeurs ne peuvent pas travailler avec succès avec des organisations tests en utilisant le contrôle source
Dans vos packages :
- Aucune métadonnées n'est dupliquée entre les packages
- Pour le développement de package, tous les travaux de développement en phase initiale sont effectués dans des organisations tests
Dans vos packages :
- Les dépendances sont contournées en dupliquant les métadonnées dans différents packages
- Le développement anticipé de packages se produit dans les organisations sandbox Developer ou le développement anticipé de packages ne peut pas se produire dans les organisations tests
Voir également : Couplage lâche
## Outils pertinents pour Composable
OutilDescriptionSéparation des préoccupationsInteropérabilitéEmballage
Apex REST Web ServicesExposer vos classes et méthodes Apex à des applications externes via RESTX
Apex SOAP Web ServicesExposer vos classes et méthodes Apex à des applications externes via SOAPX
Capture des donnéesPublier les modifications apportées aux enregistrements SalesforceX
Types de métadonnées personnaliséesDéfinir une fonctionnalité réutilisable, personnalisable et empaquetableX
DécorateursExposer publiquement des fonctions ou des propriétés en tant qu'APIXX
Dev HubGérez les organisations tests, les packages de deuxième génération et les fonctionnalités Einstein.XXX
Événements génériques (hérités)*Envoyer des événements personnalisés qui ne sont pas liés aux modifications des données SalesforceX
Lightning Data ServiceMettre en cache et partager des données entre les composantsXX
API de métadonnéesDéployer des personnalisations entre les environnements SalesforceX
Rapport sur la couverture des métadonnéesDéterminer la couverture des métadonnées prises en charge sur plusieurs canaux X
MuleSoft ComposerÉlaborer une automatisation des processus pour les données en utilisant des clics au lieu de codeX
Messages sortantsEnvoyer des messages à des points de terminaison externes lorsque les valeurs de champ sont mises à jourX
Événements de plate-formeEnvoyer des messages sécurisés et évolutifs contenant des données d'événements en temps quasi réelX
API Pub/SubAbonnement à des événements de plate-forme, Capture des données de modification ou Surveillance des événements en temps réelX
Événements pushTopic (hérités)*Envoyer et recevoir des notifications de modification correspondant à une requête SOQL définie par l'utilisateurX
Salesforce CLIDévelopper et élaborer une automatisation en travaillant avec votre organisation SalesforceX
Diagrammes SalesforceCréer des diagrammes pour montrer les capacités métiers et les détails techniquesX
Extensions Salesforce pour Visual Studio Code (Agrandi)Extensions VS Code officielles pour le développement SalesforceX
Organisations testsDéployer le code et les métadonnées Salesforce dans une organisation jetableX
Forfaits gérés de deuxième générationDévelopper et distribuer des applications pour AppExchangeX
API ToolingÉlaborer des outils ou des applications de développement personnalisés pour les applications Lightning PlatformX
Forfaits déverrouillésOrganiser les métadonnées, empaqueter une application ou étendre une application AppExchangeX
* Salesforce continuera de prendre en charge PushTopic et les événements génériques dans les limites des capacités fonctionnelles actuelles, mais n'envisage pas d'autres investissements dans cette technologie.
## Ressources relatives à Composable
RessourceDescriptionSéparation des préoccupationsInteropérabilitéEmballage
Un regard primitif sur l'intégration numériqueDévelopper un langage commun pour les concepts de connectivitéX
Application de la conception pilotée par le domaine avec SalesforceOrienter vos solutions autour des capacités métiersX
Meilleures pratiques pour les packages de deuxième générationCompréhension des modèles et des pratiques d’emballage 2GPX
Composants disponibles dans des packages gérésCompréhension des composants de métadonnées de package géréX
Modèle Design StandardsCréer des normes de conception pour votre organisationXXX
Guide de décision de l'architecture pilotée par les événementsComparer les modèles et les outils d'architecture pilotée par l'événementX
Anti-modèles d'événementsIdentifier les anti-modèles à éviter lors de l'utilisation d'événementsX
Comment concevoir des API pilotées par les messages et les événementsDécouvrez les différences dans un guide de développement MuleSoftXX
En savoir plus sur le cadre des tâches à accomplirExplorez JTBD sur TrailheadX
Gérer l'état global dans B2C CommerceTransmettre aisément des données entre des composants pour conserver l'étatX
Consignes de messagerieCommuniquer des informations pertinentes et créer des moments de plaisirX
Types de messagerieComprendre les différents types de messagerie par la nature de l'interaction des utilisateursX
Types de métadonnéesComprendre les différents types de métadonnées dans votre organisation SalesforceXX
Types de notification d'application mobileComprendre les types de notification pour les applications mobiles SalesforceX
Optimisation de l'état de vueMaintenir l'état dans une page VisualforceX
Salesforce Developer Experience (DX)Gérer et développer des applications sur Lightning PlatformXXX
Types de métadonnées non pris en chargeIdentifier les composants qui ne sont pas disponibles dans l'API de métadonnéesX
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. Limitation de responsabilité : Ce document est distribué à titre d'information seulement; il ne constitue pas un avis juridique et ne doit pas être utilisé en tant que tel. ## Introduction Un système conforme est conçu pour adhérer aux directives juridiques et éthiques applicables, son adhésion étant à la fois mesurable et vérifiable. Cela est démontré par la restriction de l'accès aux données aux personnes autorisées aux fins prévues, le respect des réglementations légales pertinentes et l'accès équitable pour tous les utilisateurs autorisés. Des mesures proactives sont essentielles pour prévenir et détecter les infractions à la conformité. Une approche réactive à l'égard des réglementations et des normes peut éroder la Trust client, en particulier si des changements n'interviennent qu'en réponse aux demandes ou plaintes des clients. De telles plaintes peuvent nuire à la marque et à la réputation de votre organisation et entraîner des pertes de chiffre d'affaires. Vous pouvez développer la conformité dans vos solutions Salesforce en vous concentrant sur trois habitudes clés : l'adhésion légale, les normes éthiques et l'accessibilité. ## Adhésion juridique Le respect des mandats légaux implique le respect des lois régionales et des réglementations de l'industrie. En tant qu'architecte, lorsque l'équipe juridique de votre organisation ou un auditeur tiers a déterminé les exigences de conformité spécifiques, votre responsabilité consiste à comprendre ces exigences et à identifier et à signaler proactivement les problèmes de conformité potentiels dès le début du processus de conception afin de réduire le risque d'amendes et de poursuites. Vous pouvez améliorer l'adhésion légale à vos solutions Salesforce en protégeant la confidentialité et la localisation des données. ### Confidentialité des données La confidentialité des données concerne la collecte, le stockage et le traitement des informations d'identification personnelle (PII) par votre solution, ainsi que les réglementations pertinentes et la capacité d'un individu à contrôler l'accès à ses données personnelles. Le respect de ces réglementations peut nécessiter des mises à jour de votre [modèle de partage et](/docs/architect/fr-fr/well-architected/guide/secure#partage-et-visibilité) de visibilité, des modifications des configurations de métadonnées pour restreindre l'accès, l'implémentation du cryptage au niveau du champ, la surveillance des journaux et des événements, la création d'automatisations pour exporter ou supprimer les données d'un client sur demande, et le développement de politiques régissant l'utilisation des données dans les automatisations et l'IA. Le non-respect de la réglementation sur la confidentialité des données peut entraîner des amendes et des poursuites importantes. De plus, exposer les données des parties prenantes en raison de contrôles insuffisants ou d'une faille de sécurité peut entraîner une perte de chiffre d'affaires et éroder la Trust client. Tenez compte des points suivants en travaillant pour garantir le respect des exigences de confidentialité des données : - **Consultez des experts** en réglementation. Avec votre équipe juridique ou un auditeur tiers, évaluez les réglementations de conformité spécifiques au secteur d'activité applicables à votre entreprise. Par exemple, les entreprises de santé doivent adhérer à la Health Insurance Portability and Accountability Act (HIPAA). - **Classifiez vos données**. La classification des données aide les équipes de projet à comprendre quand les divers éléments de données de votre organisation peuvent être utilisés ou non. Elle permet également à votre entreprise de [créer](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5) des rapports sur la conformité des stratégies de gestion des données. Classez les données de votre organisation en spécifiant les réglementations applicables [au niveau du champ](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5) afin de capturer le propriétaire, le niveau de confidentialité et si le champ est actuellement utilisé ou non. Pendant le processus de classification, il est important de penser à l'utilisation de tous les champs de votre modèle de données, pas seulement ceux qui semblent sensibles à première vue. Dans certains cas, les champs qui semblent sans conséquence peuvent devenir confidentiels s'ils sont utilisés dans un contexte incorrect. Par exemple, aux États-Unis, les codes postaux peuvent être un indicateur de la race et, par conséquent, s'ils sont utilisés en mode prédictif, ils peuvent involontairement ajouter des biais ou causer du tort. Les noms peuvent être utilisés pour prédire le sexe, le pays d'origine, la race, la religion et même l'âge, car les noms populaires ont tendance à changer de génération en génération. Incluez des classifications de tous les champs et une description claire de l'utilisation que les fonctionnalités IA associées peuvent en faire dans votre documentation. Utilisez des outils tels que la [Détection des données](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5) pour identifier les données confidentielles dans votre organisation. Si les champs sont classés comme sensibles ou si vous connaissez les champs sensibles, des outils tels que Einstein Content Selection identifieront également les champs qui sont [très corrélés](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm) et qui, par conséquent, peuvent être des proxy pour ces champs sensibles. - **Établir les meilleures pratiques de gouvernance des données** Assurez-vous que toute la documentation pertinente est complète, à jour et stockée de façon centralisée afin qu'elle soit facilement disponible pour toutes les parties prenantes. Cela ajoutera une couche de protection pour votre organisation contre la responsabilité légale tout en maintenant Trust avec vos clients et partenaires. Par exemple, un dictionnaire de données documente les définitions et les classifications d'objets et de champs pour tous les éléments de données qui seront stockés dans votre système, des documents de conception contiennent des détails sur toutes les automatisations que vous avez créées pour respecter la réglementation, et une matrice de sécurité indique les données auxquelles les utilisateurs ont accès. Il est essentiel que cette documentation complète devienne la source faisant autorité pour la génération augmentée par récupération (RAG), ancrant directement les systèmes agentsiques comme Agentforce dans un contexte opérationnel vérifié et conforme, empêchant ainsi les sorties incohérentes ou hallucinées. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/compliant#modèles-dadhésion-légale-et-anti-modèles) ci-dessous montre à quoi ressemble une gestion correcte (et médiocre) de la confidentialité des données dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce pour la confidentialité des données, consultez [Outils pertinents pour être conforme](/docs/architect/fr-fr/well-architected/guide/compliant#outils-pertinents-pour-être-conforme). ### Localisation La localisation consiste à adapter un produit à une langue, une culture et une esthétique locale spécifiques. Il s'agit également de s'adapter aux réglementations spécifiques à chaque région, telles que les lois sur la résidence des données, qui peuvent différer considérablement d'un pays à l'autre et même d'une municipalité à l'autre. Par conséquent, vos systèmes peuvent devoir satisfaire à plusieurs cadres réglementaires, selon l'emplacement de vos clients et la façon dont votre entreprise introduit ses produits et services sur le marché. En plus des variations dans les lois sur la confidentialité des données, de nombreux pays promulguent également des lois sur la résidence des données. Les lois sur la résidence des données exigent au minimum que toutes les données relatives aux citoyens d'un pays soient physiquement stockées à l'intérieur des frontières de ce pays. Certaines lois vont plus loin, exigeant le stockage local de toutes les données (y compris les données sur les produits et services) potentiellement accessibles par les citoyens. Dans certains cas, la réglementation exige que les données des citoyens soient conservées uniquement par d'autres citoyens de ce pays ou de cette région. La non-conformité pourrait entraîner des amendes et des poursuites importantes. Par exemple, les autorités de protection des données de l'UE peuvent imposer des amendes allant jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires mondial, selon le montant le plus élevé. Aux États-Unis, le bureau du procureur général de Californie peut demander des sanctions importantes pour des infractions intentionnelles et involontaires. Tenez compte des points suivants pour mieux gérer les exigences de localisation et de résidence des données : - **Consultez des experts** en réglementation. Avec votre équipe juridique ou un auditeur tiers, évaluez les lois en vigueur dans les régions où votre entreprise exerce ses activités afin de déterminer lesquelles sont applicables. Par exemple, le Règlement général sur la protection des données (RGPD) et la loi européenne sur l’IA de l’UE, ainsi que le California Consumer Privacy Act (CCPA) de l’UE. - **Stocker les données** Assurez-vous que les données spécifiques à une région restent dans sa propre organisation séparée. Utilisez [Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1), le substrat cloud public de Salesforce pour héberger votre organisation dans une région spécifique. - **Évitez la réplication**. Le stockage local de données signifie que les données sont stockées _au repos_ dans le pays; bien entendu, des problèmes de conformité peuvent survenir lorsque les données sont transférées hors du pays via des interfaces standard. Par exemple, la création et la gestion d'enregistrements localement, mais leur réplication dans un entrepôt de données dans un autre pays pour la génération de rapports, enfreindront les lois sur la résidence des données. Si vous travaillez pour une entreprise internationale avec des exigences de génération de rapports interrégionaux, commencez par agréger vos données dans le pays où elles sont stockées, retirez toutes les informations qui pourraient identifier les citoyens associés, puis répliquez uniquement les informations agrégées. Cette approche vous obligera peut-être à communiquer à vos parties prenantes les limitations en matière de rapports afin qu'elles sachent que des données plus précises seront disponibles au niveau national ou régional, mais que seules des données résumées seront disponibles à l'échelle mondiale. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/compliant#modèles-dadhésion-légale-et-anti-modèles) ci-dessous montre à quoi ressemblent les processus de localisation et de résidence des données appropriés (et médiocres) dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou identifier les zones qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce de localisation, consultez [Outils pertinents pour être conforme](/docs/architect/fr-fr/well-architected/guide/compliant#outils-pertinents-pour-être-conforme). ### Modèles d'adhésion légale et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'adhésion légale dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/trusted-legal-adherence) et anti-modèle.
Modèles Anti-Patterns
Confidentialité des données Dans votre documentation :
- Vous avez un dictionnaire de données à jour contenant les noms, les descriptions et les classifications au niveau du champ
- Vous avez une matrice de sécurité à jour qui identifie les utilisateurs qui ont accès à quelles données
- Vous disposez d'une documentation de conception à jour, comprenant des normes et des diagrammes pour toutes les automatisations créées pour répondre aux exigences réglementaires
Dans votre documentation :
- Un dictionnaire de données n'existe pas ou n'a pas été tenu à jour
- La documentation sur le partage et la visibilité n'existe pas ou n'a pas été mise à jour
- Les normes de conception, les diagrammes et la documentation pour les automatisations qui répondent aux exigences réglementaires n'existent pas ou n'ont pas été tenus à jour
Dans votre organisation :
- Tous les objets et champs qui contiennent des informations confidentielles ou sont soumis aux réglementations sur la confidentialité des données ont configuré Catégorie de conformité, Propriétaire des données, Niveau de confidentialité des données et Utilisation des champs
Dans votre organisation :
- La configuration des objets et des champs qui contiennent des informations confidentielles ou sont soumis à la réglementation sur la confidentialité des données est manquante pour Catégorie de conformité, Propriétaire des données, Niveau de confidentialité des données ou Utilisation des champs
Localisation Dans votre documentation :
- Vous avez une stratégie d'organisation qui indique où les données seront stockées et conservées pour satisfaire à toutes les exigences de résidence des données applicables
- Vous avez une stratégie d'intégration qui décrit des scénarios et des processus acceptables pour répliquer des données à travers les frontières
- Vous avez une stratégie d'analyse qui souligne le niveau de granularité que les rapports et les tableaux de bord peuvent contenir aux niveaux régional, national et mondial
Dans votre documentation :
- Vous n'avez pas de stratégie organisationnelle ou votre stratégie organisationnelle ne répond pas aux exigences de localisation des données et de résidence
- Vous n'avez pas de stratégie d'intégration ou votre stratégie d'intégration ne répond pas aux exigences de localisation des données et de résidence
- Vous n'avez pas de stratégie Analytics ou votre stratégie Analytics ne répond pas aux exigences de localisation des données et de résidence
## Normes éthiques Dans les contextes commerciaux, les normes éthiques sont les lignes directrices qui déterminent comment les entreprises et les individus se comportent d'un point de vue moral ou fondé sur des valeurs. Chez Salesforce, [nos valeurs fondamentales](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values) guident tout ce que nous faisons en tant qu'entreprise et en tant qu'employés. Nous avons également une équipe de [politique d'utilisation éthique](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/) qui aide à s'assurer que les clients utilisent nos logiciels de façon éthique. Notre [politique d'utilisation acceptable](https://sfdc.co/AUP) et notre [politique d'utilisation](http://sfdc.co/AI-Policy) acceptable de l'IA sont une extension de nos valeurs fondamentales et nous aident à prendre des décisions si des questions sur l'utilisation se posent. Votre organisation peut avoir un ensemble supplémentaire de politiques qui vont au-delà de la simple conformité aux réglementations locales. Ces politiques peuvent prendre diverses formes, allant de l’adhésion à la réglementation d’autres régions, au refus de faire affaire avec certaines organisations ou certains marchés, ou à la surveillance des interactions entre les employés et les clients afin d’éviter la discrimination ou les comportements biaisés. Pour respecter ces politiques, il peut être nécessaire de mettre à jour vos normes de conception ou la configuration de votre système comme vous le feriez pour l'[adhésion légale](/docs/architect/fr-fr/well-architected/guide/compliant#adhésion-juridique). Pour favoriser une plus grande adhésion aux normes éthiques dans vos solutions Salesforce, alignez-vous sur les politiques de l'entreprise et évaluez votre utilisation de l'intelligence artificielle. ### Politiques de l'entreprise Les politiques de l'entreprise sont des lignes directrices qui définissent comment les divers aspects de l'entreprise (y compris les personnes, les processus et la technologie) doivent fonctionner. Les clients préfèrent faire affaire avec des organisations de leur Trust. La plupart des politiques de l'entreprise sont conçues pour refléter ce principe. Customer Trust s'érodera rapidement si vos systèmes créent des expériences utilisateur qui ne correspondent pas à vos stratégies énoncées. Des politiques efficaces découlent naturellement d'[une culture éthique](https://www.salesforce.com/blog/new-research-ethical-leadership-business/). Chaque employé, de l’ingénierie et de la conception à la science des données, en passant par le marketing et les ventes, doit être sensibilisé à sa responsabilité en matière d’utilisation éthique. Dans une telle culture, les employés voient des structures d’incitation claires pour récompenser un comportement éthique et des conséquences claires et cohérentes pour un comportement contraire à l’éthique. Tenez compte des points suivants pour vous assurer que les politiques de votre organisation sont reflétées dans vos conceptions : - **Attention aux conséquences** involontaires. En tant qu’architecte, il est de votre responsabilité d’anticiper les impacts potentiels de vos solutions et comment elles seront utilisées. Ne tombez pas dans le piège de considérer ou de tester uniquement des chemins heureux. À la place, mettez à profit votre expertise dans le test des requêtes Edge et l'évaluation des compromis pour examiner en profondeur les implications éthiques de vos solutions. Pensez à tous ceux qui seront affectés par le produit, en particulier ceux qui sont sous-représentés, marginalisés ou vulnérables. Évaluez la multitude de façons dont une personne, ou quelque chose, peut interagir avec votre solution et créer des conséquences inattendues. Utilisez la boîte à [outils Élaborer avec intention](http://sfdc.co/BuildwithIntention) pour concevoir en tenant compte de l'inclusion. - **Incorporez l'éthique à la politique d'utilisation acceptable** de votre entreprise. Demandez à votre équipe juridique ou à un tiers d'inclure l'éthique dans votre politique d'utilisation acceptable afin de vous assurer que l'utilisation de vos solutions respecte les valeurs de votre entreprise. Votre documentation doit inclure des informations sur les valeurs et les politiques de votre organisation qui sont prises en charge par vos solutions, qu'elles soient développées avec des outils à faible code ou pro-code. Publiez votre politique d'utilisation acceptable pour montrer votre engagement à établir la Trust avec vos employés et vos clients. - **Utilisez un langage inclusif**. Comprenez les différentes façons dont les personnes expérimentent votre solution et [affinez le langage](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/) dans votre interface utilisateur, votre code et votre documentation pour refléter plus précisément l'inclusivité. Commencez par identifier et supprimer le langage exclusif, puis engagez-vous à comprendre les types d'habitudes ou de pratiques qui peuvent conduire à l'exclusion. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/compliant#modèles-de-normes-éthiques-et-anti-modèles) ci-dessous montre à quoi ressemble une adhésion correcte (et faible) aux politiques de l'entreprise dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce d'alignement des conceptions avec les politiques de l'entreprise, consultez [Outils pertinents pour être conforme](/docs/architect/fr-fr/well-architected/guide/compliant#outils-pertinents-pour-être-conforme). ### Intelligence artificielle L'intelligence artificielle utilise des systèmes de calcul pour exécuter des tâches qui nécessitent normalement l'intelligence humaine, telles que le raisonnement, la perception et la prise de décision. Les capacités IA de Salesforce Platform couvrent les technologies prédictives, génératives et agents, offrant une suite complète d'outils pour améliorer l'expérience client et les opérations commerciales : - L’**IA prédictive** analyse les données historiques et prédit les résultats futurs, par exemple les tendances commerciales ou l’attrition des clients. Einstein AI fournit ces connaissances en analysant les modèles dans vos données afin de fournir des recommandations et de prédire les résultats métiers. - L’**IA générative** se concentre sur la création de nouveaux contenus en exploitant les grands modèles de langage. Einstein GPT est un composant de base qui fonctionne avec vos données CRM pour générer des contenus personnalisés tels que des e-mails, des réponses de chat et des communications avec les clients. - L’**IA des agents** va plus loin en permettant aux agents de raisonner et d’agir de façon autonome pour atteindre un objectif spécifique. Agentforce est la plate-forme qui permet d'élaborer ces agents intelligents, capables d'automatiser des processus métiers complexes comme la résolution de requêtes clients ou l'optimisation de campagnes marketing. Ces agents peuvent interagir en temps réel avec des données via Data 360 et exploiter les workflows et les API existants. Toutes ces capacités IA sont sécurisées par la Einstein Trust Layer. ce qui garantit une utilisation éthique. La plupart des algorithmes principaux d'Einstein AI ne sont pas configurables, mais pour certaines fonctionnalités, les clients peuvent ajuster les modèles en utilisant leurs propres données comme indiqué dans la documentation. De plus, vous pouvez ancrer des modèles d’IA dans vos propres CRM, articles de base Knowledge et autres documents via l’ancrage RAG (Retrieval Augmented Grounding) afin d’accroître la précision des résultats pour votre organisation, vos clients et vos cas d’utilisation. Cependant, si vos données sous-jacentes sont biaisées ou biaisées, vos sorties peuvent également être biaisées et imprécises. Un exemple de biais est le fait de ne pas inclure les membres d'une race, d'un sexe ou d'une ethnie spécifique dans votre liste de contacts, même si votre clientèle est diverse et inclut des membres de ce groupe. Pour plus d’informations, reportez-vous au [module Création responsable](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence) d’IA Trailhead Salesforce, [Comprendre l’IA Agentique approuvée Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai), [Modèle de maturité](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf) éthique de l’IA, [Principes Intelligence artificielle approuvés](https://www.salesforceairesearch.com/trusted-ai) de Salesforce, [Directives IA générative](https://www.salesforce.com/news/stories/generative-ai-guidelines/) responsables et [Directives IA Agentique](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/) responsable. Ne pas tenir compte des réglementations légales applicables et des normes éthiques de votre entreprise peut entraîner des biais au sein de votre IA, entraînant des poursuites judiciaires, une perte de chiffre d'affaires, des problèmes de Customer Trust et un dommage à l'image publique de votre entreprise. Voici ce qu’il faut considérer pour une utilisation responsable et éthique de l’IA : - **Examinez vos jeux de données et documents**. Assurez-vous que vos jeux de données sont représentatifs de tous les impacts de vos fonctionnalités IA. Cela peut nécessiter une recherche des utilisateurs pour comprendre qui ils sont et confirmer que vos données les représentent tous correctement afin d'atténuer les biais potentiels. Il est également essentiel de consulter les données CRM, les articles Knowledge et toute autre documentation dans laquelle vous basez vos modèles pour vous assurer qu'ils sont à jour, précis et complets. L'ancrage de vos modèles dans de nombreuses données n'est pas utile et peut entraîner des hallucinations si ces données sont anciennes, contradictoires ou incomplètes. - **[Gardez un humain à la barre](https://www.salesforce.com/news/stories/human-at-the-helm/)**. Vous ne souhaitez pas que les humains interviennent dans chaque interaction IA individuelle, mais plutôt permettre à vos employés de se concentrer sur les éléments de jugement qui nécessitent le plus leur attention. Testez vos systèmes d’IA pour vous assurer qu’ils peuvent assumer plus de responsabilités et surveiller les résultats pour vous assurer qu’ils continuent de fonctionner avec précision et efficacité. Assurez-vous que vos systèmes ou agents d’IA reçoivent l’instruction d’escalader vers un humain pour des cas d’utilisation à haut risque et lorsque le niveau de confiance de l’IA est faible. - **Priorité à la sécurité des sorties et des résultats** de votre modèle. Effectuez [des évaluations](https://www.salesforce.com/news/stories/developing-ethical-ai/) de biais, d'explicabilité et de robustesse, et [une équipe rouge](https://www.salesforce.com/blog/red-teaming-ai/) éthique. Accordez la priorité à la protection de la vie privée par des réponses et des actions des agents pour toutes les informations d'identification personnelle (PII) présentes dans les données utilisées pour la formation, et créez des garde-fous afin d'éviter tout préjudice supplémentaire. Si vous détectez des résultats nocifs lors d'un test, ajoutez des instructions à vos invites système et refaites un test. Il peut également être nécessaire d'améliorer la qualité ou la représentativité des données que vous utilisez pour la génération augmentée de récupération (RAG). - **Préparez-vous aux règlements**. Outre les préoccupations éthiques relatives à l’IA, de nombreux gouvernements ont adopté ou adoptent actuellement des lois pour réglementer l’utilisation de l’IA par les organisations qui opèrent sur leur territoire. Cette législation peut inclure l'obligation de publier des cartes de modèle qui décrivent comment une solution IA a été créée et fonctionne. Avant d'implémenter une solution basée sur l'intelligence artificielle, déterminez le type de fonctionnalité liée à l'IA acceptable ou non dans les régions où vos systèmes seront utilisés, et apportez les ajustements nécessaires à votre stratégie. Il peut être nécessaire de désactiver certaines fonctionnalités dans certaines régions pour respecter les réglementations locales. Dans ce cas, assurez-vous que vos systèmes peuvent continuer à fonctionner sans ces fonctionnalités. De nombreuses juridictions exigent également la transparence lorsque des clients ou des utilisateurs interagissent avec des systèmes IA. - **Surveillez les modèles IA** de votre organisation. Les utilisateurs impactés doivent savoir quand une IA a été utilisée et avoir la possibilité de signaler aisément les dommages et de demander réparation. Il est important de noter que la génération de rapports seule peut ne pas être suffisante pour déterminer si vos fonctionnalités IA causent des dommages aux utilisateurs. Surveillez en permanence la dérive des données, l'évolution des scores d'équité/de biais, la précision et la robustesse de vos modèles. Assurez-vous que vous avez mis en place des plans pour [traiter les alertes](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5) et répondre rapidement lorsque des impacts négatifs sont identifiés. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/compliant#modèles-de-normes-éthiques-et-anti-modèles) ci-dessous montre à quoi ressemble une conception IA correcte (et médiocre) dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce d'implémentation de politiques d'IA plus éthiques, consultez [Outils pertinents pour être conforme](/docs/architect/fr-fr/well-architected/guide/compliant#outils-pertinents-pour-être-conforme). ### Modèles de normes éthiques et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles de normes éthiques dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/trusted-ethical-standards) et anti-modèle.
Modèles Anti-Patterns
Société Politiques Dans vos normes de conception :
- Les normes comprennent des directives claires pour les domaines impactés par les politiques de l'entreprise
Dans vos normes de conception :
- Les normes de conception n'existent pas ou ne fournissent pas de directives claires sur les domaines soumis aux politiques de l'entreprise
Dans votre documentation :
- La documentation sur la configuration et les personnalisations inclut des références aux valeurs de l'entreprise prises en charge
Dans votre documentation :
- La documentation sur la configuration et les personnalisations ne référence pas les valeurs ou les politiques de l'entreprise
Dans votre organisation :
- Tous les objets et champs soumis à la conformité liée à la politique de l'entreprise ont une Catégorie de conformité, un Propriétaire des données, un Niveau de sensibilité des données et une Utilisation des champs configurés
Dans votre organisation :
- Les objets et qui sont soumis à la conformité liée à la politique de l'entreprise sont manquants dans la configuration Catégorie de conformité, Propriétaire des données, Niveau de confidentialité des données ou Utilisation du champ
Intelligence artificielle Dans vos normes de conception :
- Les stratégies et les cas d'utilisation approuvés pour les applications IA sont clairs et faciles à trouver
- Assurez-vous que les données et les documents utilisés pour RAG sont représentatifs, complets, exacts et à jour. Recherchez les biais, les toxiques et les autres contenus nuisibles qui pourraient résider dans vos jeux de données ou votre documentation.
- Les réponses génératives identifient toujours les sources de données utilisées par les modèles IA
- Les jeux de données qui peuvent/ne peuvent pas être utilisés pour l'ingénierie rapide ont été documentés
- Les robots et les réponses IA génératives sont clairement identifiés pour les utilisateurs
- Définition claire des normes pour quand et comment utiliser les clauses d'exclusion de responsabilité pour l'IA générative
- Existence d'exigences claires pour la documentation des points d'implication humaine dans la conception de solutions IA
- Des normes de documentation des parcours de rétroaction directe et indirecte dans les conceptions de solutions IA existent
- Les points auxquels l'IA doit être identifiée pour un utilisateur sont clairement définis
- Garder un humain à la barre, en particulier dans les cas d'utilisation réglementés ou à haut risque
Dans vos normes de conception :
- Les normes de conception n'existent pas ou n'incluent pas de politiques claires et de cas d'utilisation approuvés pour les applications IA
- Les réponses génératives n'identifient pas les sources de données utilisées par les modèles IA
- Les jeux de données utilisés pour l'ingénierie rapide ne sont pas documentés
- Les robots et les réponses IA génératives ne sont pas identifiés pour les utilisateurs
- Avertissements concernant les réponses génératives manquants
- Aucune exigence de documentation des points d'implication humaine dans les conceptions de solutions IA n'existe
- Aucune norme de documentation des parcours de rétroaction directe et indirecte pour les conceptions de solutions IA n'existe
- Les normes de conception n'indiquent pas les points auxquels l'IA doit être identifiée pour les utilisateurs
Dans votre documentation :
- La documentation relative à la configuration et aux personnalisations impliquant des fonctionnalités IA contient une description complète de toute la logique de processus et est stockée à un emplacement central accessible par les équipes juridiques ou les auditeurs
- Les modèles que vous élaborez ou apportez à Salesforce sont clairement documentés, y compris tous les segments de données applicables
- La logique de conversation et les conversations des agents sont documentées en profondeur
- Des processus sont en place pour surveiller les modèles d'IA de votre organisation pour la dérive des données, l'évolution des scores d'équité et de biais, la précision et la robustesse
- Des descriptions sont conservées pour la formation, l'évaluation et les données de test utilisées pour tous les processus IA
- Les descriptions sont conservées pour tout nettoyage des données liées à l'IA avec les tests de biais, les résultats associés et les scores de performance/précision (par exemple, scores F1)
Dans votre documentation :
- La documentation relative à la configuration et aux personnalisations impliquant des fonctionnalités IA est manquante, incomplète ou stockée à un emplacement inaccessible
- Les modèles ou systèmes IA sont implémentés dans votre organisation sans documentation sur leurs modèles
- Les agents sont implémentés dans votre organisation sans documentation sur les messages et le flux de conversation
- Les processus de surveillance IA n'existent pas ou ne sont pas documentés
- Les informations sur les données d'entraînement, d'évaluation et de test utilisées pour tous les processus IA ne sont pas claires ou ne sont pas disponibles
- Les informations sur le nettoyage des données liées à l’IA, les tests de biais et les résultats ne sont pas claires ou ne sont pas disponibles
## Accessibilité _L'accessibilité_ en technologie désigne la facilité d'utilisation de systèmes ou de solutions pour des personnes ayant des capacités différentes. Concevoir des systèmes qui fonctionnent pour tous les utilisateurs, quelles que soient leurs capacités, est un mandat légal dans certains endroits et secteurs d'activité. Au-delà des exigences légales, la construction de systèmes accessibles aide votre organisation à favoriser et à renforcer Trust avec vos parties prenantes. Pour les applications accessibles aux clients, cela peut même augmenter le chiffre d'affaires, car les clients peuvent choisir d'utiliser vos systèmes plutôt que des alternatives moins accessibles. Salesforce publie des [rapports de conformité](https://www.salesforce.com/company/legal/508_accessibility/) à l'accessibilité, qui sont des documents standard de l'industrie détaillant la conformité de nos logiciels aux normes d'accessibilité. La plupart de nos contrôles basés sur l'interface utilisateur, y compris les composants Web Lightning et les modèles Experience Cloud, sont conçus pour adhérer à ces normes. Bien que nos fonctionnalités d'accessibilité de base puissent être suffisantes pour de nombreuses entreprises, il est important de consulter nos ACR et notes de publication avant de lancer un projet. Cela vous aidera à identifier et à documenter toutes les exigences d'accessibilité supplémentaires qui dépassent nos normes, selon l'approche de commercialisation de votre produit ou service. Vous pouvez améliorer l'accessibilité de vos systèmes en vous concentrant sur deux domaines clés : la saisie de données et la navigation. ### Saisie de données Les activités de saisie de données se produisent chaque fois qu'un utilisateur doit saisir des informations dans un champ, un formulaire ou une autre partie d'une interface utilisateur. Bien que les claviers et les souris soient les méthodes de saisie les plus courantes, certains utilisateurs peuvent s'appuyer sur la synthèse vocale ou des appareils similaires. De plus, vos utilisateurs peuvent communiquer dans différentes langues. Les solutions qui ne sont pas conçues pour l'accessibilité peuvent empêcher les personnes ayant certains handicaps d'interagir avec elles. Tenez compte des points suivants lors de la conception pour l'accessibilité : - **La langue préférée** de vos utilisateurs. Selon l'endroit où votre entreprise opère, vous pouvez définir une langue unique et standard pour vos systèmes ou offrir des capacités multilingues. Si vous affichez un texte en plusieurs langues, vos normes de conception doivent inclure une liste d'étiquettes de champ et d'autres éléments de l'interface utilisateur (notamment les notifications et les messages d'erreur) qui nécessitent une traduction. Engagez un locuteur natif pour vérifier la précision et le sens des traductions. Utilisez les [fonctionnalités de traduction](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5) de Salesforce pour les traductions de métadonnées et de données en temps réel, et testez en profondeur toutes les fonctionnalités multilingues. - **Les types de périphériques d'entrée qui seront utilisés**. Répertoriez tous les outils qui peuvent être utilisés pour la saisie de données au-delà d'un clavier et d'une souris standard dans vos normes de conception. Insérez des tests d'accessibilité dans vos plans de test et assurez-vous que toutes les entrées sont testées avec plusieurs types de périphérique d'entrée. - **La convivialité de vos formulaires** Assurez-vous que vos formulaires contiennent des étiquettes visibles, fournissent des messages d'erreur utiles, guident l'utilisateur vers la saisie, l'informent de sa progression, et le laissent réviser, confirmer et modifier ses entrées. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/compliant#modèles-daccessibilité-et-anti-modèles) ci-dessous montre à quoi ressemble la saisie de données correctement (et mal) conçue pour l'accessibilité dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce qui permettent d'élaborer une saisie de données plus accessible, consultez [Outils pertinents pour être conforme](/docs/architect/fr-fr/well-architected/guide/compliant#outils-pertinents-pour-être-conforme). ### Navigation La navigation implique que les utilisateurs déplacent le focus entre les écrans et entre les champs d'un écran. Les utilisateurs peuvent avoir besoin de parcourir les divers éléments de l'interface utilisateur de votre système de diverses façons, y compris par clics et touches clavier, tout en s'appuyant sur leur vue, leur audition et leur toucher. Assurez-vous que vos normes de conception contiennent une liste des appareils de navigation que vous envisagez de prendre en charge. Les équipes d'implémentation doivent consulter cette liste lors des tests pour s'assurer que toutes les possibilités de navigation sont prises en compte. Tenez compte des questions suivantes et de leurs réponses en concevant une navigation accessible : - **Comment les utilisateurs vont-ils parcourir votre solution ?** Répertoriez tous les appareils qui peuvent être utilisés pour la navigation au-delà d'un clavier et d'une souris standard dans vos normes de conception. - **Votre navigation est-elle cohérente ?** Établissez des normes de conception pour les contrôles de navigation afin d'assurer la cohérence dans l'ensemble de votre système. Les chemins de navigation doivent être similaires dans l'ensemble de votre système. Une navigation incohérente, par exemple un bouton « Suivant » bleu en bas à droite d'un écran et un bouton « Suivant » vert au centre du suivant, peut être un léger désagrément pour certains utilisateurs, mais peut rendre l'application inutilisable pour les personnes handicapées. - **Vos tests prennent-ils en compte l'accessibilité ?** Insérez des tests d'accessibilité dans vos plans de test et assurez-vous que tous les flux de navigation sont testés avec plusieurs types d'appareil d'entrée. - **Le focus clavier est-il toujours visible ?** Affichez toujours visuellement l'état actuel du focus clavier pour aider les utilisateurs qui s'appuient sur un clavier à naviguer. - **Votre navigation repose-t-elle sur la couleur ?** Évitez d'utiliser la couleur seule pour présenter des informations ou demander une action. Respectez les [Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast) pour utiliser correctement la couleur afin de transmettre un sens et appliquer le niveau de contraste approprié. - **Vos conceptions ont-elles été révisées ?** Effectuez des examens réguliers pour vous assurer que votre interface utilisateur est cohérente et facile à comprendre. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/compliant#modèles-daccessibilité-et-anti-modèles) ci-dessous montre à quoi ressemble la navigation lorsqu'elle est correctement (et mal) conçue pour l'accessibilité dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce qui facilitent l'accès à la navigation, consultez [Outils pertinents pour être conforme](/docs/architect/fr-fr/well-architected/guide/compliant#outils-pertinents-pour-être-conforme). ### Modèles d'accessibilité et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'accessibilité dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/trusted-accessibility) et anti-modèle.
Modèles Anti-Patterns
Saisie de données Dans vos normes de conception :
- Tous les appareils qui peuvent être utilisés pour la saisie de données au-delà d'un clavier et d'une souris standard sont répertoriés
- Les valeurs de texte et leurs traductions dans toutes les langues prises en charge sont répertoriées
Dans vos normes de conception :
- Seuls certains, ou aucun, des appareils qui peuvent être utilisés pour la saisie de données au-delà d'un clavier et d'une souris standard sont répertoriés
- Les langues prises en charge sont répertoriées avec les éléments de l'interface utilisateur à traduire
Dans vos plans de test :
- Les étapes de test comprennent l'utilisation de plusieurs types de périphérique d'entrée pour saisir des données
- Les étapes de test comprennent la saisie de données dans plusieurs langues
Dans vos plans de test :
- Les tests d'accessibilité ne sont pas inclus ou les tests de saisie de données accessibles sont effectués de façon ponctuelle
Dans votre organisation :
- Les traductions des langues prises en charge sont stockées dans le Système de traduction
Dans votre organisation :
- Les traductions sont stockées dans des étiquettes personnalisées
Navigation Dans vos normes de conception :
- Tous les appareils qui peuvent être utilisés pour la navigation (pas seulement le clavier et la souris standard) sont clairement répertoriés
- Les normes UI/UX spécifient le type et le style de toutes les commandes de navigation
- Les types d'indice visuel approuvés pour transmettre un sens ou un état sont clairement répertoriés, et la couleur n'est pas un indice principal
Dans vos normes de conception :
- Aucune norme de conception n'existe ou ne tient pas compte des exigences d'accessibilité pour les commandes de navigation
- Les normes UI/UX de navigation sont incohérentes
- Les indices visuels de signification ou d'état dépendent de la couleur ou il n'y a pas de listes claires d'indices visuels pour les constructeurs
Dans vos plans de test :
- Les étapes de test comprennent l'utilisation de plusieurs types de périphériques d'entrée pour naviguer
- Les plans de test comprennent l'utilisation de tests UI/UX pour garantir des parcours de navigation cohérents
Dans vos plans de test :
- Le test d'accessibilité n'est pas inclus ou le test de la navigation accessible est effectué au cas par cas
## Outils pertinents pour être conforme
OutilDescriptionAdhésion juridiqueNormes éthiquesAccessibilité
Agentforce AnalyticsRecueillir des connaissances sur les performances de vos agentsX
Centre de test AgentforceExécutez jusqu'à 10 tâches de test avec jusqu'à 1000 requêtes de test par test, afin de créer et d'évaluer rapidement plusieurs scénarios.X
CitationsLes citations aident à identifier les imprécisions ou les hallucinations potentielles dans les réponses générées, ce qui augmente votre confiance dans l'utilisation des outils d'IA.X
API de consentementSuivre les préférences de consentement des clientsX
Flux d'événements de consentementEnvoyer des notifications de modification du consentement ou des coordonnéesX
Objets de gestion du consentementGérer les préférences de confidentialité et de consentement des clientsX
Accès aux données et portabilitéExportation des données associées aux clients sur demandeX
Classification des donnéesEnregistrer les informations de conformité et d'audit des clés pour les champs d'objetX
Rapports Data 360Surveiller le respect des instructions des agentsX
Suppression des donnéesSupprimer les données pour respecter les réglementations légalesX
Préférences de confidentialité des donnéesStocker les préférences de confidentialité des données des clientsXX
Traduction des donnéesTraduire les données présentées aux utilisateursXX
Détection des donnéesAlignement des catégories et des niveaux de sensibilité sur les données réellesX
Explorateur Data 360Gérer les autorisations de projet et d'objet pour les scientifiques des donnéesXX
Einstein Data PrismUne solution d’ancrage pour les applications d’IA générative dans Salesforce, qui améliore la précision des solutions d’IA utilisant ses capacités d’ancrageX
Einstein Trust LayerEnsemble de fonctionnalités, de processus et de politiques conçus pour protéger la confidentialité des données, améliorer la précision de l'IA et promouvoir une utilisation responsable de l'IA dans l'écosystème SalesforceX
Journaux d'événements avancésLes journaux d'événements capturent les événements et les messages utilisateur dans une session d'agent pour vérifier l'adhésion aux instructions, tester et dépanner votre agent.X
Files ConnectParcourir, rechercher et partager des fichiers externes depuis SalesforceX
HyperforceRespecter les exigences locales en matière de stockage de donnéesX
Traduction des métadonnéesTraduire les langues pour localiser les applicationsXX
API PortabilityCompiler les données clients identifiées dans votre politique de portabilitéXX
Centre de préférenceRécupérer les préférences de communication des clientsXX
Privacy CenterSatisfaire les demandes des clients et les lois sur la confidentialité des donnéesXX
Limitation du traitement des donnéesLimiter les méthodes de traitement des données personnellesXX
Droit à l'oubliSupprimer des données clients individuelles sur demandeX
Salesforce FilesPartager et stocker des fichiers en privéX
Centre de sécuritéAfficher les paramètres de sécurité et de confidentialité dans plusieurs organisationsX
B Shield Platform EncryptionCryptage des données au repos et en transitX
Système de traductionMaintenir les valeurs traduites pour les métadonnées et les étiquettes de donnéesXX
## Ressources pertinentes pour être conforme
RessourceDescriptionAdhésion juridiqueNormes éthiquesAccessibilité
5 principes pour une conception IA responsableConcevoir la fonctionnalité Intelligence artificielle (IA) de façon éthiqueX
Accessibility Basics (Trailhead)Découvrez pourquoi l'accessibilité est importanteX
Rapports de conformité à l'accessibilité (ACR)Comprendre comment Salesforce respecte les normes d'accessibilitéX
Vue d'ensemble de l'accessibilitéComprendre l'accessibilité dans Salesforce LightningX
Modèle de maturité de l'éthique IAÉlaborer une feuille de route pour rendre opérationnels les principes éthiquesX
AI Red Teaming : Testing for TrustDécouvrez comment les « hackers éthiques » de Salesforce développent l'IA responsable via l'équipe rouge.X
Automatisation de l'adversaire : Conception d’une infrastructure évolutive pour l’IA Red TeamingDécouvrez comment Salesforce automatise la génération d'invites contradictoires et la validation des réponses. fuzzai permet de sécuriser les interactions IA tout en réduisant l'exposition humaine aux contenus nocifs.X
Meilleures pratiques de conception de conversationsRespecter les meilleures pratiques lors de la conception de chatbotsXX
Meilleures pratiques de conception durable (Trailhead)Intégrer le développement durable dans vos conceptionsX
Gestion du consentementSuivre et respecter les demandes de consentement et de désabonnementX
Stratégies de données pour EinsteinContrôler l'utilisation des données dans toutes les fonctionnalités EinsteinXX
Modèle Design StandardsCréer des normes de conception pour votre organisationXXX
Les pratiques éthiques de piratage réussissent à élaborer des produits Intelligence artificielle approuvésDécouvrez comment Salesforce utilise des pratiques d'équipe rouge pour améliorer la sécurité de nos produits IA en testant les utilisations malveillantes, les attaques d'intégrité intentionnelles, les abus bénins et en identifiant les problèmes d'IA responsables.X
Leadership éthique et affairesConnaissances sur la technologie, l'égalité et l'éthiqueX
Politique d'utilisation éthiqueExplorer la politique de Salesforce sur l'utilisation éthique de nos produits et servicesX
Ethics by Design (Trailhead)Intégrer le design éthique dans le développement technologiqueX
Exploration de la culture et des valeurs de Salesforce (Trailhead)Exploration des valeurs principales de SalesforceXX
Suivez les consignes de conception mobile accessibleSuivez les meilleures pratiques pour rendre vos conceptions accessiblesXX
Premiers pas avec l'accessibilité Web (Trailhead)Apprenez les bases pour rendre les sites Web et les applications accessiblesX
Comment Salesforce élabore une infrastructure Red Teaming reproductibleQuatre composants que nous recommandons lors de la conception, de l'implémentation et de l'exécution d'un test contradictoireX
Comment animer un atelier d'analyse des conséquencesPrendre en compte tous les résultats possibles tout en innovantX
Mise en œuvre de la protection des données et de la vie privéeÉvaluer les exigences de protection des données et de la vie privéeX
Conception inclusive (Trailhead)Favoriser l’innovation avec des principes de conception inclusiveXX
Modèle de feuille de calcul KPIDéfinition d'indicateurs de performance clés (KPI) pour votre organisationX
Informations légalesExploration du centre d'informations juridiques de SalesforceX
Module de consentement aux cookies LWCContrôler l'accès des cookies utilisateur dans les sites Experience CloudXX
Vue d'ensemble de la confidentialitéDécouverte de la confidentialité des données par région et secteur d'activitéX
Promouvoir des agents responsables et éthiquesApprenez à mettre en œuvre des stratégies d'équipe rouge et de test éthiques, et à élaborer des principes directeurs et des normes pour votre organisation.X
Consignes relatives à l’IA agentique responsableX
Création responsable du module Trailhead IAApprenez à supprimer les biais de vos données et algorithmes pour créer des systèmes d’IA éthiques dans votre entreprise.X
Consignes relatives à l’IA générative responsableNous nous sommes appuyés sur nos principes Intelligence artificielle approuvée avec une nouvelle série de lignes directrices axées sur le développement et la mise en œuvre responsables de l’IA générative.X
Certifications de conformité SalesforceExaminer les certifications et attestations de conformité de SaleforceX
Conception durable (Trailhead)Renforcer la relation entre l’entreprise et la sociétéX
Test de l'accessibilité Web (Trailhead) Utiliser des tests automatisés et manuels pour garantir l'accessibilitéX
IA agentique de confianceDécouvrez comment Agentforce utilise des garanties et des principes d'IA responsable pour créer une IA éthique.x
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. ## Introduction Salesforce Well-Architected représente les conseils et les meilleures pratiques d'un expert dans Salesforce et dans notre écosystème. Merci à tous ceux qui ont contribué des ressources et Knowledge à bien architecturé. Nous mettons à jour des documents bien archivés deux fois par an. Nous annoncerons comment contribuer à Well-Architected lors de notre prochaine période de maintenance. Vous pouvez formuler à tout moment des commentaires sur Well-Architected [ici](https://sfdc.co/bxNtvh). ## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Les systèmes montrent des comportements attrayants en facilitant l'accès et l'utilisation des applications, en donnant aux utilisateurs l'impression d'obtenir un travail de plus grande qualité et en donnant envie aux utilisateurs d'utiliser des applications dans le système. Offrir un comportement engageant est important pour l'entreprise, car il est directement corrélé à l'adoption des utilisateurs ainsi qu'à la satisfaction générale des agents et des clients. Les comportements d'engagement aident également à réduire les demandes de support et à améliorer la qualité des demandes de fonctionnalité des utilisateurs. L'un des défis de la création d'un comportement engageant est qu'il est difficile de le mesurer uniquement par des métriques objectives. Au lieu de cela, il est évalué par les expériences subjectives des utilisateurs; les utilisateurs estiment que les applications attrayantes fournissent une véritable valeur. Les applications engageantes sont [accessibles](/docs/architect/fr-fr/well-architected/guide/compliant#accessibilité), non intrusives et faciles à comprendre. Ils nécessitent un minimum d'intégration et de formation. Ils utilisent des méthodes claires pour éviter proactivement les erreurs des utilisateurs. Un autre défi est que les objectifs d'engagement varient souvent en fonction des différents types d'interaction des utilisateurs dans votre système. Par exemple, vous pouvez avoir un ensemble d'objectifs pour les utilisateurs internes qui gèrent les requêtes et un autre pour les utilisateurs externes qui soumettent des informations via un formulaire sur votre site Web. Pour concevoir des systèmes attrayants, vous devez examiner attentivement le type d'engagement que vous essayez de créer et les raisons pour lesquelles les utilisateurs souhaitent s'engager avant de commencer à assembler des fonctionnalités et des pages. Un partenariat avec des concepteurs d'expérience utilisateur (UX) vous aidera à prendre des décisions beaucoup plus efficaces pour livrer des applications attrayantes. D'un point de vue architectural, l'adoption et la rétention des utilisateurs sont des composantes essentielles d'un système sain. L'engagement des architectures réduit la probabilité de Problèmes de qualité des données causés par les utilisateurs qui se précipitent à travers les processus ou ignorent les étapes pour éviter de passer du temps dans un système qu'ils n'apprécient pas. Pour des systèmes accessibles en externe, une architecture attrayante peut augmenter le chiffre d'affaires et fidéliser les clients, car les clients qui trouvent vos systèmes plus faciles à utiliser choisissent de faire plus d'affaires avec votre organisation. Vous pouvez créer des applications plus attrayantes en offrant des expériences rationalisées et utiles. ## Rationalisation Les applications rationalisées sont faciles à parcourir, présentent clairement les informations et les tâches de saisie de données, et s'adaptent à divers facteurs de forme. Les applications rationalisées présentent également des modèles d'expérience auxquels les utilisateurs sont habitués dans d'autres applications fréquemment utilisées. Par exemple, la plupart des navigateurs Web présentent « ouvrir dans un nouvel onglet » comme l'option principale lorsque les utilisateurs cliquent avec le bouton droit sur un lien. Une application rationalisée qui contient des onglets suivra le même modèle. Les impacts d'expériences d'application inefficaces peuvent aller bien au-delà d'une application individuelle. Les mauvaises expériences d'application érodent la Trust des utilisateurs. À mesure que de plus en plus d'applications critiques pour l'entreprise et accessibles aux clients se déplacent vers les canaux numériques, cela peut coûter aux entreprises la fidélité des principales parties prenantes. Vous pouvez rationaliser vos applications en adoptant une approche délibérée de la complexité des applications, de la conception de formulaires et des facteurs de forme. ### Complexité de l'application La réduction de la complexité des applications signifie que les utilisateurs affichent uniquement les éléments de menu, les onglets et les contrôles de navigation appropriés. Vous devez créer des mappages entre des groupes d'utilisateurs, des autorisations utilisateur et l'expérience d'application appropriée. Utilisez ces mappages pour comprendre l'expérience d'application à présenter à un utilisateur donné, puis assurez-vous que votre application dispose des contrôles logiques nécessaires pour offrir cette expérience. Les applications qui présentent aux utilisateurs une complexité excessive peuvent entraîner diverses expériences médiocres : - Les utilisateurs affichent souvent des onglets inutiles ou non pertinents, accèdent à des écrans vides et rencontrent des liens désactivés ou bloqués. - Des instructions inutiles ou inutiles telles que « ignorez cet onglet si votre rôle est X... » sont affichées dans les documents de formation et d'activation. - Les menus de navigation encombrés obligent les utilisateurs à consacrer plus de temps à localiser les éléments dont ils ont besoin pour travailler. Ces expériences médiocres entraînent de faibles taux d'adoption et de satisfaction. Tenez compte des points suivants pour déterminer le niveau de complexité approprié de l'application : - Organisez les menus, les onglets et les autres contrôles de navigation en fonction de la priorité du travail que les utilisateurs doivent effectuer. - Évitez d'introduire de nouveaux comportements qu'un utilisateur doit apprendre uniquement pour pouvoir utiliser votre application. - Ne retirez pas l'accès aux fonctionnalités qui permettent aux utilisateurs de personnaliser certains aspects de leur interface utilisateur. - Utilisez des ensembles d'autorisations pour offrir des options de navigation étendues ou réduites. - Simplifiez les [attributions d'activation](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm) de page Lightning. Limitez le nombre de pages Lightning actives par application. Utilisez des formulaires dynamiques, des ensembles d'autorisations et un rendu conditionnel pour ajouter des éléments à des pages Lightning dans votre application. Faites cela au lieu de maintenir plusieurs pages Lightning, activées et attribuées par profil. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/engaging#rationalisation-des-modèles-dapplication-et-anti-modèles) ci-dessous montre à quoi ressemble la gestion de la complexité de l'application dans une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer vos conceptions d'application. Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à gérer la complexité des applications, consultez [Outils pertinents à](/docs/architect/fr-fr/well-architected/guide/engaging#outils-pertinents-pour-lengagement) l'engagement. ### Formulaires Les formulaires rationalisés organisent les informations en séquences logiques, prennent en charge la saisie rapide de données et réduisent les étapes requises. Ils permettent également d'envoyer des messages [utiles](/docs/architect/fr-fr/well-architected/guide/engaging#utile) de validation des données côté client et d'éliminer les cycles répétés de soumission de formulaires. Tenez compte des points suivants lors de la conception de formulaires : - **Regroupez les champs associés**. Regroupez les champs associés à la même étape dans un processus ou une tâche de saisie de données. Éliminez les champs qui ne se rapportent pas directement à la tâche en cours. - **Précédez la saisie et la validation** des données. Les champs qui nécessitent que les utilisateurs saisissent des données doivent être affichés tôt dans vos formulaires. Il est recommandé de mettre en évidence les problèmes de mise en forme des données ou les données manquantes au niveau du champ et le plus rapidement possible (c'est-à-dire avant qu'un utilisateur tente de passer à l'étape suivante ou de soumettre le formulaire). Évitez également d'afficher des erreurs au niveau du champ avant que les utilisateurs aient pu saisir des données dans les champs. - **Réduisez les tâches** d'entrée de données. Préremplissez ou complétez automatiquement autant de champs que possible afin de limiter les erreurs de saisie de données et d'améliorer l'efficacité. Demandez aux utilisateurs de saisir uniquement les données essentielles ou critiques. Éliminez toutes les entrées de données qui ne se rapportent pas au processus métier en cours. Utilisez des listes de sélection au lieu de champs de texte de forme libre, si possible, pour forcer la sélection d'options valides et réduire les variations d'une même réponse. - **Réduisez les soumissions au serveur**. Ne pas avoir de formulaires à plusieurs étapes qui soumettent des données plusieurs fois au serveur. Assurez-vous que tous les composants [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) ou [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) personnalisés utilisent la mise en cache côté client pour gérer les actions de navigation ou de pagination. (Salesforce Lightning Experience et l'application mobile Salesforce utilisent par défaut la mise en cache côté client). Concevez des formulaires pour permettre aux utilisateurs de soumettre des données au serveur une seule fois. Validez les entrées des utilisateurs côté client avant la soumission des formulaires. Cela réduira les soumissions d'utilisateurs indésirables, empêchera les transactions dupliquées ou sales de consommer de la bande passante sur le back-end, et vous aidera à concevoir pour un meilleur [traitement des données](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-données). - **Gérer l'état** du formulaire. La mise en cache côté client facilite non seulement les comportements tels que la navigation et la pagination, mais aide également à minimiser les pertes de données dues à des problèmes de connectivité intermittents. Une gestion efficace de l'état permet également aux applications d'orchestrer correctement la soumission de données au serveur et d'éviter les transactions dupliquées, tout en présentant aux utilisateurs des messages pertinents et opportuns basés sur le statut des actions côté serveur. Les formulaires rationalisés soumettent les opérations de données une seule fois et n'obligent pas les utilisateurs à attendre la fin des opérations de longue durée sur le serveur. - **Suivez les normes** d'accessibilité. Pour optimiser l'audience de vos applications et garantir l'inclusion de tous vos clients, appliquez des normes d'[accessibilité](/docs/architect/fr-fr/well-architected/guide/compliant#accessibilité) dans vos conceptions de formulaire. Des formulaires rationalisés aident à renforcer l'[intégrité des données](/docs/architect/fr-fr/well-architected/guide/automated#intégrité-des-données) dans vos applications et à améliorer l'[utilité](/docs/architect/fr-fr/well-architected/guide/engaging#utile) de vos applications pour les utilisateurs. Ils peuvent également réduire les tickets et les demandes de support, car les utilisateurs sont plus en mesure de corriger les erreurs et de comprendre clairement l'état de leurs soumissions de formulaire. De plus, les formulaires rationalisés permettent une saisie de données rapide et efficace, et évitent aux utilisateurs d'attendre la fin de processus plus longs pour effectuer d'autres tâches. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/engaging#rationalisation-des-modèles-dapplication-et-anti-modèles) ci-dessous montre à quoi ressemble la conception correcte (et médiocre) d'un formulaire dans une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer vos conceptions de formulaire. Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à élaborer des formulaires rationalisés, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/engaging#outils-pertinents-pour-lengagement) l'engagement. Pour des conseils plus précis sur le choix de l'outil de formulaire adapté à votre cas d'utilisation, consultez le guide [Architect’s Decision Guide to Building Forms with Salesforce](/docs/architect/fr-fr/decision-guides/guide/build-forms#principaux-points-à-retenir). ### Facteur de forme Les applications engageantes s'adaptent gracieusement à différents appareils et types d'interaction, ou facteurs de forme. Selon le type d'appareil, les différents types d'interaction utilisateur seront plus faciles (ou plus difficiles) et la lisibilité des formulaires et des champs changera. Notez qu'en plus des dimensions de l'écran, le facteur de forme désigne également l'interaction de vos utilisateurs avec l'écran. Un nombre croissant d'appareils sont désormais dotés d'écrans tactiles et certains utilisateurs peuvent également utiliser des appareils spéciaux pour l'[accessibilité](/docs/architect/fr-fr/well-architected/guide/compliant#accessibilité). Assurez-vous de prendre en compte ces facteurs lors de la conception de formulaires. Ne pas tenir compte des variations de facteur de forme peut entraîner divers problèmes, notamment : - Mauvaise qualité des données - Interfaces d'application inutilisables - Dépannage supplémentaire ou sessions « commander au nom de » pour les agents de support - Faible adoption des utilisateurs, faible nombre d'utilisateurs actifs et taux élevés d'« abandon » d'applications Pour concevoir l'interopérabilité entre les facteurs de forme dans vos applications Salesforce, tenez compte des points suivants : - **Identifiez les facteurs de forme pris en charge pour chaque application**. - **Identifiez les méthodes d'entrée et les besoins en accessibilité de vos utilisateurs**. Consultez [Accessibilité](/docs/architect/fr-fr/well-architected/guide/compliant#accessibilité) pour plus d'informations. - **Utilisez la [fonctionnalité standard](/docs/architect/fr-fr/well-architected/guide/intentional#fonctionnalité-standard-par-rapport-à-la-fonctionnalité-personnalisée) pour offrir des expériences adaptatives entre les appareils dans la mesure du possible**. - Les [modèles Lightning Page](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5) fournis par Salesforce prennent en charge par défaut différents facteurs de forme. Si vous choisissez de développer des modèles de page Lightning personnalisés avec Aura, les développeurs devront incorporer des informations sur les facteurs de forme dans le fichier de conception du composant. - Les [composants de page](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5) standard fournis par Salesforce gèrent pour vous la restitution entre les facteurs de forme pris en charge. Si vous créez des composants personnalisés avec LWC ou Aura, les développeurs doivent gérer la sensibilisation à la largeur (il existe des différences d'implémentation entre [Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) et [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware)) et déclarer la prise en charge du facteur de forme dans le fichier de conception de leurs composants. - **Suivez le guide de simplification [des formulaires sur tous](/docs/architect/fr-fr/well-architected/guide/engaging#formulaires)** les appareils. - **Créez des plans de test (et de bons tests) pour les principaux facteurs de forme**. L'idéal serait de tester tous les appareils et les facteurs de forme de toutes vos applications. Cependant, la configuration des appareils (ou simulateurs d'appareil) appropriés pour les tests de facteur de forme peut représenter un investissement important. Si vous savez qu'une application ou un ensemble d'applications aura un nombre important d'utilisateurs sur mobile ou tablette, priorisez des tests précis pour ces applications sur les facteurs de forme mobile et tablette. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/engaging#rationalisation-des-modèles-dapplication-et-anti-modèles) ci-dessous montre à quoi ressemble la sensibilisation correcte (et faible) aux facteurs de forme dans une organisation Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les pages qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce pour une conception efficace des facteurs de forme, consultez [Outils pertinents à](/docs/architect/fr-fr/well-architected/guide/engaging#outils-pertinents-pour-lengagement) l'engagement. ### Rationalisation des modèles d'application et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'applications rationalisées dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/easy-streamlined) et anti-modèle.
Modèles Anti-Patterns
Complexité de l'application Dans votre organisation :
- Les applications ont moins de 10 onglets dans la configuration par défaut fournie par l'administrateur
- Aucune application n'a défini « Désactiver la personnalisation des éléments de navigation dans cette application par l'utilisateur » sur true
Dans votre organisation :
- Les applications ont généralement plus de 10 onglets dans la configuration par défaut fournie par l'administrateur
- De nombreuses applications ont défini « Désactiver la personnalisation des éléments de navigation par l'utilisateur dans cette application » sur true ou l'autorisation de personnalisation des éléments de navigation est désactivée dans l'organisation
Formulaires Dans vos applications :
- Les champs suivent des regroupements logiques
- Les champs de saisie de données sont affichés ensemble, par groupe de cinq ou moins
- Les erreurs de saisie de données sont claires et affichées au niveau du champ, avant que les utilisateurs ne quittent ou soumettent des données
- Les contrôles de pagination activent le déplacement entre les étapes
- Soumission de données une fois
- Les étiquettes des actions et de la navigation sont claires
- Des commentaires visuels et opportuns sont fournis pour confirmer les actions de l'utilisateur telles que les clics sur les boutons
- Les boutons de navigation (par exemple, « aller », « suivant » et « retour ») sont placés de façon cohérente dans l'interface utilisateur
Dans vos applications :
- Les champs de saisie de données ne sont pas regroupés de façon logique, ce qui nécessite un nombre important de basculements de contexte par les utilisateurs qui remplissent des formulaires
- Les erreurs de saisie de données contiennent des informations cryptiques qui ne peuvent être interprétées que par quelqu'un qui comprend le fonctionnement interne du système
- Les erreurs de saisie de données sont affichées uniquement lorsque le bouton Soumettre d'un formulaire est cliqué
- Les étapes et les regroupements ne sont pas clairement définis, ce qui rend la navigation difficile
- La soumission de données se produit plusieurs fois pendant le processus de saisie de données
- Les étiquettes des actions et de la navigation prêtent à confusion pour les utilisateurs qui ne connaissent pas les fonctionnalités système sous-jacentes
- La confirmation visuelle des actions de l'utilisateur n'est pas fournie
- Les boutons de navigation sont affichés à des emplacements arbitraires dans l'interface utilisateur
Dans votre logique de formulaire :
- Les champs sont préremplis ou automatiquement remplis autant que possible
- Les utilisateurs ne sont pas contraints d'attendre la fin des longues actions côté serveur
- Les composants personnalisés utilisent cacheable=true pour les actions basées sur le serveur qui n'impliquent pas d'opérations de données
- Les opérations sur les données sont effectuées une fois
- Dans les adaptateurs LWC @wire, toutes les actions n'impliquant pas d'opérations sur les données sont gérées
Dans votre logique de formulaire :
- Les champs qui peuvent être préremplis ou automatiquement remplis nécessitent une saisie manuelle
- Les utilisateurs doivent arrêter de travailler pendant le processus de soumission pour attendre la fin des actions côté serveur
- Ensemble de composants personnalisés cacheable=false
Facteur de forme Dans votre organisation :
- Les modèles de page Lightning fournis par Salesforce sont utilisés pour toutes les pages ou la plupart des pages
- Les modèles de page Lightning personnalisés utilisent design:supportedFormFactors et design:supportedFormFactor dans les fichiers de conception de composants Aura
- Les composants LWC ou Aura personnalisés disponibles dans le Générateur d'applications déclarent les facteurs de forme pris en charge dans leurs fichiers de conception respectifs et implémentent des modèles de style sensibles à la largeur
Dans votre organisation :
- Classic est toujours actif
- Les modèles de page Lightning personnalisés n'utilisent pas uniformément design:supportedFormFactors et design:supportedFormFactor dans les fichiers de conception de composants Aura
- Les composants LWC ou Aura personnalisés disponibles dans le Générateur d'applications ne déclarent pas systématiquement les facteurs de forme pris en charge dans leurs fichiers de conception respectifs
- Dans les composants LWC ou Aura personnalisés, le style sensible à la largeur n'est pas implémenté par les interfaces fournies par Salesforce
- Dans les composants LWC ou Aura personnalisés, le style des différents facteurs de forme est piloté uniquement par des valeurs px ou % codées en dur dans CSS
Sur ordinateur de bureau :
- Les champs de saisie de données et les contrôles de navigation s'adaptent à l'écran et peuvent être interagis comme prévu
- Les pages d'enregistrement et d'application sont correctement affichées, selon les règles d'attribution d'activation de page
Sur ordinateur de bureau :
- Les champs de saisie de données et les contrôles de navigation ne sont pas affichés à l'emplacement voulu à l'écran
- Les interactions avec les champs de saisie de données et les contrôles de navigation ne correspondent pas aux comportements requis
- L'absence de règles d'attribution d'activation de page signifie que tous les utilisateurs affichent les mêmes pages d'enregistrement et d'application
Sur mobile et tablette :
- Les entrées de données et les contrôles de navigation sont correctement affichés
- Les utilisateurs peuvent saisir aisément des données
- Les menus de navigation mobiles, optimisés pour les plus petits facteurs de forme, apparaissent
- Présentations compactes affichées au niveau de l'enregistrement
Sur mobile et tablette :
- Les entrées de données et les contrôles de navigation ne sont pas restitués de façon cohérente ou correcte
- Les utilisateurs ne peuvent pas saisir facilement des données
- Les menus de navigation mobiles ne se distinguent pas de la navigation sur ordinateur de bureau
- Les présentations compactes ne sont pas configurées au niveau de l'enregistrement
## Utile Les applications utiles permettent aux utilisateurs de se sentir plus autonomes et plus efficaces, sans distraction ni interruption. Les applications utiles aident à préserver l'[intégrité des données](/docs/architect/fr-fr/well-architected/guide/automated#intégrité-des-données) en atténuant les erreurs manuelles et en fournissant des commentaires aux utilisateurs quand et où ils en ont besoin. Ils aident les utilisateurs à comprendre les actions sur lesquelles ils doivent se concentrer maintenant et ensuite, et fournissent des informations pertinentes pour les aider à résoudre leurs propres problèmes plus rapidement. Ils établissent un lien clair entre les actions d'un utilisateur et l'impact significatif ou les réalisations. Vous pouvez élaborer des applications plus utiles avec trois habitudes clés : notification et messages, guide dans l'application, et reconnaissance et récompenses. ### Notifications et messages Les notifications et les messages aident les utilisateurs à rester informés. Un système de notification et de messagerie bien conçu peut accroître l'engagement et la productivité en fournissant aux utilisateurs les informations dont ils ont besoin pour prendre des décisions critiques en temps opportun. Un système de notification et de messagerie mal conçu - qui présente des messages qui ne sont ni pertinents ni opportuns - aura l'effet inverse. Les utilisateurs internes désactivent ou ignorent rapidement les notifications, ce qui les fait passer à côté des messages légitimes qui peuvent affecter les processus métiers essentiels. Les clients ou autres utilisateurs externes qui se lassent des notifications inutiles peuvent décider d'arrêter complètement d'utiliser vos systèmes. Pour déterminer comment les applications vont gérer l'envoi de notifications et de messages aux utilisateurs, tenez compte des points suivants : - **Pour les erreurs, utilisez les notifications et les messages en dernier recours**. Concevez le [traitement des erreurs](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-erreurs) dans votre système avec un traitement back-end capable de corriger certains types d'erreur sans intervention humaine. Envoyez aux utilisateurs uniquement des messages sur les erreurs critiques qui les empêcheront d'accomplir les tâches. De la même façon, envoyez aux utilisateurs professionnels uniquement des messages d'erreur lorsqu'ils peuvent (et doivent) prendre eux-mêmes des mesures correctives. Des messages d'erreur ou des détails supplémentaires peuvent être disponibles via des rapports et/ou envoyés au personnel de support technique en utilisant des méthodes asynchrones pour un suivi ultérieur. - **Choisissez des types de message basés sur la pertinence, l'urgence et l'actualité**. Différents types de message ont différents niveaux de comportement bloquant ou interruptif. Les avis sont un type de message « bloquant », car ils obligent les utilisateurs à les confirmer avant de pouvoir poursuivre leur travail. Comme pour les messages d'erreur, les avis doivent être utilisés avec précaution. Les notifications flottantes ne sont [pas bloquantes](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast), peuvent avoir différents comportements de persistance et prendre en charge différents types de cas d'utilisation de messages. Les messages les moins gênants sont les [notifications dans l'](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5)application ou les e-mails. Ils sont plus efficaces pour fournir des informations que les utilisateurs peuvent traiter quand et quand ils le souhaitent. - **Pense à ce qui doit se passer ensuite**. Bien que certaines notifications soient informatives (par exemple des messages de réussite), d'autres peuvent demander aux utilisateurs de prendre une mesure. Lors de la conception de notifications, assurez-vous de prendre en compte non seulement la notification elle-même, mais également toutes les informations supplémentaires qu'un utilisateur peut avoir besoin d'agir. Incluez des instructions claires ou des liens vers les utilisateurs qui peuvent trouver des informations supplémentaires ou suivre les étapes de toutes les notifications actionnables. - **Concentrez-vous sur la lisibilité**. Assurez-vous de communiquer clairement l'objet de chaque notification et les étapes suivantes qu'un utilisateur doit suivre en réponse. Les messages doivent être compréhensibles pour les utilisateurs professionnels qui ne connaissent pas le fonctionnement interne des systèmes sous-jacents. Lors de la création de messages, respectez les [normes d'accessibilité](/docs/architect/fr-fr/well-architected/guide/compliant#accessibilité) et assurez-vous qu'ils sont traduits pour aider les utilisateurs dans les régions où ils peuvent apparaître. Insérez dans vos [normes de conception](/docs/architect/fr-fr/well-architected/guide/intentional#normes-de-conception) des modèles indiquant quand utiliser les notifications ou différents types d'erreur afin de vous assurer que les générateurs d'applications respectent des pratiques cohérentes. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/engaging#modèles-dapplication-utiles-et-anti-modèles) ci-dessous montre à quoi ressemblent les notifications et les messages corrects (et médiocres) dans une organisation Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les utilisations qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce pour les notifications et la messagerie, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/engaging#outils-pertinents-pour-lengagement) l'engagement. ### Guide dans l'application Le guide dans l'application peut être un puissant moyen de démystifier les workflows complexes (vous devez toutefois vous assurer de les avoir [optimisés](/docs/architect/fr-fr/well-architected/guide/automated#conception-de-processus) au préalable) ou de faciliter l'intégration de nouveaux employés. Il peut être très efficace pour introduire des modifications de processus, mettre en évidence de nouvelles fonctionnalités ou distribuer des formations de façon automatisée et évolutive. Cependant, s'il n'est pas mis en œuvre avec précaution, le guide dans l'application peut être surutilisé. Des fenêtres contextuelles ou des alertes fréquentes peuvent créer un énorme bruit et une interruption pour les utilisateurs, entraînant une perte de productivité. Le guide dans l'application peut également être sous-utilisé, ce qui entraîne des processus de gestion des versions et des modifications plus lourds (en particulier pour les fonctionnalités simples). En fin de compte, la surutilisation et la sous-utilisation du guide dans l'application entraînent un certain nombre de problèmes qui présentent des risques pour l'entreprise, notamment : - Intégrité des données réduite - Augmentation des erreurs utilisateur - Augmentation des niveaux de frustration des utilisateurs et baisse de la satisfaction des utilisateurs - Diminution de la productivité des utilisateurs Notez que vous pouvez utiliser le guide dans l'application différemment dans différents scénarios, car l'état d'esprit d'un utilisateur détermine la quantité de guide « trop » par rapport à « pas assez ». Les utilisateurs qui découvrent un nouveau système pour la première fois auront probablement besoin de messages plus fréquents que les utilisateurs qui découvrent simplement une nouvelle fonctionnalité dans un système qu'ils connaissent déjà. Voici quelques clés pour créer un guide dans l'application efficace : - **Développer des normes** de conception. Il est important de se rappeler que la surexposition au guide dans l'application peut amener les utilisateurs à ignorer ou à ignorer régulièrement les messages. À ce stade, le guide dans l'application devient gênant plutôt qu'une ressource. Définissez des [normes de conception](/docs/architect/fr-fr/well-architected/guide/intentional#normes-de-conception) pour indiquer clairement quand utiliser des invites, des procédures pas à pas, un texte d'aide au niveau du champ, des messages de validation, des parcours, des flux d'écran, etc. - **Créer un système de hiérarchisation des priorités pour la mise en œuvre des directives**. Les cas d'utilisation du guide dans l'application ne doivent pas tous être implémentés. À la place, tenez compte des questions suivantes à prioriser. Où pouvez-vous simplement utiliser de meilleurs noms de champ, des étiquettes plus explicites sur les boutons, une meilleure [conception des formulaires](/docs/architect/fr-fr/well-architected/guide/engaging#formulaires) et [une optimisation des processus](/docs/architect/fr-fr/well-architected/guide/automated#conception-de-processus) pour créer des workflows plus intuitifs ? Où pouvez-vous ajouter un texte ou des liens plus utiles à un parcours ? Quel [impact sur les coûts](/docs/architect/fr-fr/resources/guide/kpi-spreadsheet-template) métiers aura le guide dans l'application ? À quelle fréquence souhaitez-vous transmettre des messages à vos utilisateurs ? Assurez-vous également que toutes les implémentations sont incluses dans votre [feuille de route](/docs/architect/fr-fr/well-architected/guide/intentional#mappage-routier) afin d'offrir une visibilité à toutes les parties prenantes. - **Mappez les utilisateurs avec un guide dans l'application** actif (et proposé). Le mappage d'utilisateurs avec un guide dans l'application vous aidera à identifier et à prévenir la « surcharge de travail » due à un nombre excessif de guides dans l'application affichés pour un utilisateur. Souvent, c'est le résultat d'un développement cloisonné, les équipes réfléchissant trop étroitement à leur cas d'utilisation particulier. Le maintien d'une vue globale des éléments auxquels les utilisateurs seront exposés est particulièrement important pour les grandes organisations. L'insertion d'implémentations de guide dans votre feuille de route peut également vous aider. - **Recueillir et utiliser les commentaires pour améliorer**. Examinez les données d'utilisation du guide dans l'application et utilisez-les pour évaluer l'efficacité des déploiements de guides dans l'application. Assurez-vous de fournir aux utilisateurs des commentaires ouverts pour aider les générateurs de guide. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/engaging#modèles-dapplication-utiles-et-anti-modèles) ci-dessous montre à quoi ressemble un guide dans l'application correct (et médiocre) dans une organisation Salesforce. Vous pouvez les utiliser pour valider les conceptions avant de les élaborer et identifier les implémentations qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce pour le guide dans l'application, consultez [Outils pertinents à](/docs/architect/fr-fr/well-architected/guide/engaging#outils-pertinents-pour-lengagement) l'engagement. ### Reconnaissance et récompenses Élaborer une reconnaissance et des récompenses dans une application aide les utilisateurs à se sentir plus connectés à l'impact de leur travail et à mieux comprendre la valeur de leurs contributions, de leur productivité et de leurs performances. C'est également un puissant moyen de libérer la fidélité et l'engagement. Ne pas concevoir pour la reconnaissance ou des expériences d'application enrichissantes peut contribuer à divers problèmes, notamment : - Les utilisateurs qui peinent à comprendre leur progression ou leur vélocité - Confusion sur la progression vers les objectifs ou le travail inachevé - Des utilisateurs plus improductifs, qui ne voient pas de lien entre leurs tâches et une « vue d'ensemble » - Perte de temps par la direction en rapports manuels sur les objectifs de faible niveau Récompenser les expériences d'application peut s'avérer difficile à concevoir et à livrer, car elles dépendent de la culture, des politiques et des normes de l'entreprise, ainsi que du contexte et des préférences des utilisateurs individuels. Les fonctionnalités qui peuvent aider les utilisateurs de bureau à ressentir des moments de joie ou d'appréciation peuvent devenir une irritation pour un utilisateur sur un appareil mobile ou un utilisateur qui tente de travailler depuis un bureau à domicile bruyant et occupé. Les personnes qui utilisent une application pour travailler avec des informations privées ou hautement confidentielles peuvent ne pas apprécier la communication sur les jalons sous forme de célébrations de confettis ou de badges. Par contre, une équipe commerciale distribuée peut considérer une telle ludification comme une expérience d'application enrichissante. En fin de compte, il peut être préférable de déterminer les modèles d'implémentation que vous choisissez en travaillant en équipe avec des concepteurs d'expérience utilisateur (UX). En matière d'architecture, il est important d'identifier comment et où les applications peuvent implémenter des fonctionnalités qui aident les utilisateurs à se sentir reconnus et récompensés. Il est également important de comprendre comment et où ces fonctionnalités peuvent rendre les applications moins [réutilisables](/docs/architect/fr-fr/well-architected/guide/composable) ou enlever une [valeur métier réelle](/docs/architect/fr-fr/well-architected/guide/automated#valeur-métier). Voici quelques questions à prendre en compte pour évaluer la reconnaissance et les récompenses dans les applications Salesforce : - **Comment et où les utilisateurs peuvent-ils consulter leur propre progression, ainsi que les statistiques générales de l'équipe ?** Les rapports sont importants, mais ils contiennent souvent des données récapitulatives qui peuvent manquer le contexte du travail quotidien. Vous pouvez utiliser un outil tel que le Générateur d'applications Lightning pour incorporer des graphiques ou des tableaux de bord à des écrans d'enregistrement dans le contexte d'une application, afin d'aider les utilisateurs à comprendre leur impact ou leur progression dans leurs tâches quotidiennes. - **Comment reconnaître les utilisateurs ?** Cela peut varier selon les préférences de l'équipe ou de l'individu. Dans certains cas, les superviseurs peuvent afficher des messages sur la progression des utilisateurs afin qu'ils puissent être partagés avec un plus grand groupe. La reconnaissance peut également être un avantage supplémentaire pour aider à améliorer le moral des employés. Dans d'autres cas, les utilisateurs peuvent simplement préférer être les seuls notifiés de leur progression sur une tâche ou un projet donné. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/engaging#modèles-dapplication-utiles-et-anti-modèles) ci-dessous montre à quoi ressemblent la reconnaissance correcte (et médiocre) et les récompenses dans une organisation Salesforce. Vous pouvez les utiliser pour valider les conceptions avant de les élaborer et identifier les implémentations qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce de reconnaissance et de récompense, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/engaging#outils-pertinents-pour-lengagement) l'engagement. ### Modèles d'application utiles et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles d'applications utiles dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/easy-helpful) et anti-modèle.
Modèles Anti-Patterns
Notifications et messages Vos normes de conception comprennent :
- Cas d'utilisation approuvés pour les notifications, les toasts et les avis
- Modèles de conception pour les variantes flottantes et les notifications
- Concevoir des modèles pour la messagerie d'erreur
Si des normes de conception sont définies, elles ne corrigent pas les erreurs et les notifications
Dans votre organisation :
- Les notifications sont le format de messagerie prédominant
- Les messages flottants utilisent des variantes
- Les messages flottants avec le mode défini sur sticky n'existent pas
- Les avis sont rarement, voire pas du tout utilisés
- Les réponses génératives identifient toujours les sources de données utilisées
- Les robots s'identifient clairement avant la première interaction avec les utilisateurs
- Avis de non-responsabilité pour les risques associés à l’IA générative affiché pour les utilisateurs avant la première interaction
- Les exclusions de responsabilité IA sont dans un langage clair et compréhensible pour les utilisateurs
Dans votre organisation :
- Les e-mails sont le format de messagerie prédominant
- Il n'y a pas d'approche cohérente des types de message
- Les messages flottants n'utilisent pas systématiquement des variantes
- Les messages flottants avec le mode défini sur sticky existent
- Les avis sont utilisés ad hoc
- Les réponses génératives n'identifient pas les sources de données utilisées
- Les robots ne s'identifient pas clairement avant la première interaction avec les utilisateurs
- Aucune clause de non responsabilité pour les risques d’IA générative n’est affichée pour les utilisateurs
- Les exclusions de responsabilité IA ne sont pas rédigées dans un langage clair et compréhensible pour les utilisateurs
Dans vos applications :
- Aucune réponse générative n'est envoyée directement aux utilisateurs sans point d'implication humaine
Dans vos applications :
- Les réponses génératives sont envoyées directement aux utilisateurs sans point d'implication humaine
Voir également : Traitement des erreurs
Guide dans l'application Vos normes de conception et votre documentation comprennent :
- Cas d'utilisation approuvés pour le guide dans l'application
- Concevoir des modèles pour des invites et des procédures pas à pas
- Une matrice claire d'utilisateurs, d'applications et un guide dans l'application actif
Si des normes de conception et de la documentation existent, elles :
- Ne pas traiter le guide dans l'application
- Ne pas inclure une matrice claire montrant les utilisateurs, les applications, le guide dans l'application actif
Dans votre organisation :
- Le paramètre « Délai entre le guide dans l'application » utilise la valeur par défaut ou une valeur personnalisée supérieure à la période par défaut (24 heures) fournie par Salesforce
- Aucune application n'a plusieurs procédures pas à pas actives
- Aucune procédure pas à pas n'a un paramètre « Temps d'affichage » supérieur à 10
- Aucune invite n'est activée pour "Toute page, toute application" ou "Cette page, toute application"
Dans votre organisation :
- Le paramètre « Délai entre le guide dans l'application » est défini sur une période inférieure à la période par défaut (24 heures) fournie par Salesforce
- Les applications ont plusieurs procédures pas à pas actives
- De nombreuses procédures pas à pas ont un paramètre « Temps d'affichage » supérieur à 10 (et certaines ont une valeur maximale de 30)
- Les invites sont activées de façon ad hoc, beaucoup avec le paramètre "N'importe quelle page, n'importe quelle application" ou "Cette page, n'importe quelle application"
Reconnaissance et récompenses Dans votre organisation :
- Les applications utilisent des analytiques incorporées pour montrer aux utilisateurs des statistiques pertinentes de progression des objectifs et de productivité
- Les célébrations de parcours sont activées uniquement avec le consentement de l'utilisateur
- Les notifications et la messagerie incluent la reconnaissance de l'utilisateur, et reflètent les préférences de l'utilisateur dans la conception des destinataires et des déclencheurs des notifications
Dans votre organisation :
- Les analytiques associées à la progression des objectifs et aux statistiques de productivité sont disponibles uniquement dans les rapports ou les tableaux de bord de responsable
- Les célébrations de parcours sont activées sans vérification du consentement de l'utilisateur
- Les notifications et les messages ne comprennent aucun type de reconnaissance de l'utilisateur ou ne reflètent pas les préférences des utilisateurs et se sentent bruyants ou incompréhensibles
## Outils pertinents pour l'engagement
OutilDescriptionRationalisationUtile
Activation de votre page d'application LightningGérer la disponibilité, le nommage, la visibilité et le positionnement des pagesX
Tableaux de bord AdoptionExaminer l'historique des connexions, l'adoption des fonctionnalités et la productivitéXX
AlerteMaintenir les alertes pendant les sessions et les afficher sans initiation de l'utilisateurX
Mise en cache côté client des résultats de la méthode ApexÉvaluer les performances avec des données côté client mises en cacheX
Formulaires dynamiquesAfficher uniquement les champs obligatoires et les sections de page pour les utilisateursX
Connaissances d'engagementSurveiller l'activité récente des utilisateurs et prendre les mesures nécessairesXX
Guide dans l'applicationUtiliser des invites et des procédures pas à pas pour la formation et l'intégrationX
Parcours d'apprentissagePersonnaliser les expériences d'apprentissage des utilisateursX
Générateur d'applications LightningCréer des pages mobiles et Lightning personnalisées sans codeX
Lightning Data ServiceMettre en cache et partager des données entre les composantsX
Validateur du système de conception Lightning pour VS CodeValider le balisage par rapport aux consignes SLDSXX
Modèles de page LightningÉlaborer des pages Lightning pour différents facteurs de formeX
Filtres de référenceValeurs de filtrage pour les relations de référence, principal-détails et hiérarchiquesX
Gérer les devises multiplesUtiliser plusieurs devises dans des transactionsX
Messaging Envoyer des SMS, Facebook Messenger ou WhatsAppX
Mobile PublisherCréer des versions mobiles d'applications Lightning et de sites Experience CloudX
Composants Mobile-ReadyÉlaborer des composants performants dans toutes les expériences mobilesX
Sites multilinguesCréer différentes versions linguistiques de votre siteXX
Générateur de notificationCréer des notifications personnalisées pour présenter des informationsX
CheminGuider les utilisateurs à travers les processus métiers et célébrer la réussiteXX
Cache de la plate-formeAmélioration des performances et de la fiabilité lors de la mise en cache des donnéesX
Prévisualisation des pages d'application mobile dans le Générateur d'applications LightningPrévisualisation des pages d'enregistrement et d'application sur un appareil mobileX
InviteAlerter les utilisateurs des problèmes et des mises à jour liés au systèmeX
Badges de reconnaissanceReconnaître et célébrer les réalisations des utilisateursX
Reconnaissance avec WDCApprouver les compétences et remercierX
Types d'enregistrementPersonnaliser les processus métiers, les valeurs de liste de sélection et les présentations de pageXX
Présentation de la réputationReconnaître la participation et le partage KnowledgeX
Règles de restrictionEmpêcher les utilisateurs d'accéder aux enregistrements qui peuvent contenir des données inutilesX
Composants de page standardComprendre les composants Salesforce Lightning standardX
TraductionsGérer les traductions pour les utilisateurs internationauxXX
Règles de validationVérifiez que les données respectent les normes spécifiées avant d'enregistrerX
## Ressources pertinentes pour l'engagement
RessourceDescriptionRationalisationUtile
Guide de l'architecte pour la construction de formulaires Évaluer les considérations relatives à la conception de formulaires et sélectionner le meilleur outilX
Configuration de votre composant pour différents facteurs de formeConfigurer les composants à restituer sur les ordinateurs de bureau et les téléphonesX
Personnalisation du contenu d'aideAdaptez les contenus d'aide à votre implémentation unique X
Valeurs de champ par défautDéfinir des valeurs de champ par défaut, dynamiques ou statiquesX
Consign GuidelinesCréer des interfaces utilisateur cohérentes avec les meilleures pratiquesXX
Modèle Design StandardsCréer des normes de conception pour votre organisationXX
Compétences en matière d'essais de conception (Trailhead)Méthodes de planification pour valider et tester une conceptionXX
Consignes relatives aux commentaires dans l'applicationConsultez les consignes pour recueillir les commentaires de votre système.XX
Bibliothèque statique Android Lightning Design SystemÉlaborez des applications Android natives avec la présentation des pages LightningX
Bibliothèque statique iOS Lightning Design SystemÉlaborer des applications iOS natives avec la présentation des pages LightningX
Consignes de messagerieCommuniquer des informations pertinentes et créer des moments de plaisirX
Types de messagerieComprendre les différents types de messagerie basés sur l'interaction des utilisateursX
Navigation GuidelinesAider les utilisateurs à se déplacer entre les pages et à se situer dans une applicationX
Test de l'accessibilité Web (Trailhead) Utiliser des tests automatisés et manuels pour garantir l'accessibilitéXX
Consignes d'engagement des utilisateursConsultez les consignes d'intégration, d'adoption, d'assistance et d'apprentissage.XX
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. # Introduction Une solution Salesforce **facile** offre rapidement de la valeur. Une solution bien conçue pour être **facile** est intentionnelle, automatisée et engageante. Les solutions **intentionnelles** offrent une valeur métier immédiate et au fil du temps.
Les solutions **automatisées** permettent à l'entreprise d'accélerer et d'adapter son travail.
Les solutions **intéressantes** ravissent les utilisateurs et favorisent l'adoption.
Créer des architectures **faciles** peut poser des défis complexes à un architecte. Compte tenu de la flexibilité de Salesforce Platform et de la variété des [outils d'automatisation](/docs/architect/fr-fr/well-architected/guide/automated#outils-pertinents-pour-automatisé) disponibles, les détails d'implémentation peuvent varier considérablement entre les organisations Salesforce. Des architectures **faciles** peuvent nécessiter des analyses et des conversations plus intelligentes (et difficiles) avec vos parties prenantes. Une conception de solution peut être résiliente et fiable pour un programmeur, mais pas simple à gérer pour un administrateur d'organisation. Une telle solution ne serait pas **facile** à concevoir. Pour arriver à une solution **facile**, vous devez comprendre les priorités métiers en profondeur et avec précision. Vous devez comprendre vos utilisateurs, notamment leurs préférences, leurs besoins et les réalités quotidiennes de leur travail. Vous devez également comprendre les compétences (et les déficits en compétences) de vos équipes de livraison et de maintenance. Vous devrez itérer à travers différentes options d'outillage et modèles de conception pour arriver à une solution intentionnelle qui apporte de la valeur à l'entreprise tout en étant gérable pour les équipes de livraison et de maintenance, automatise le travail plus rapidement et à grande échelle, et engage réellement les utilisateurs. Les sections suivantes fournissent des conseils plus approfondis sur les considérations fondamentales relatives à une architecture de solution **facile**. ## Vue d'ensemble facile
Intentional
Les solutions intentionnelles offrent une valeur métier immédiate et au fil du temps. Les architectures intentionnelles sont planifiées et livrées de façon stratégique, peuvent être maintenues efficacement et sont faciles à lire et à comprendre pour les humains.
Stratégie Maintenabilité Lisibilité
Priorisation
Mappage routier
Gouvernance
Standard par rapport à Personnalisé
Dette technique
Normes de conception
Documentation
Automatisé
Les solutions automatisées permettent à l'entreprise d'accélerer et d'adapter son travail. Une automatisation saine réduit le temps consacré aux tâches répétitives et manuelles ou à la saisie de données complexes.
Efficacité Intégrité des données
Conception de processus
Logique opérationnelle
KPIs
Traitement des données
Traitement des erreurs
Engagement
Les solutions engageantes ravissent les utilisateurs et favorisent l'adoption. L'architecture pour l'engagement signifie créer des expériences utilisateur intuitives et utiles.
Rationalisation Utile
Complexité de l'application
Formulaires
Facteur de forme
Notifications et messagerie
Guide dans l'application
Reconnaissance et récompenses
> Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Des solutions fiables fonctionnent efficacement et de façon fiable. Ils sont disponibles, performants et adaptables pour soutenir les entreprises en croissance. Un système fiable n'est pas source d'erreurs, se comporte comme prévu et produit des résultats en temps opportun. Inversement, un système peu fiable est lent, ne se comporte pas comme prévu ou échoue à des moments critiques. Les systèmes peu fiables fournissent des informations imprécises, les parties prenantes ne peuvent donc pas leur Trust pour les décisions métiers. La fiabilité du système n'est pas constante. Un système fiable aujourd'hui peut devenir peu fiable s'il n'est pas conçu pour la croissance. Un système non fiable peut nécessiter une maintenance, une refactorisation ou une remise en œuvre coûteuses, ce qui détourne des fonds de projets stratégiques. Augmentez la fiabilité de vos solutions Salesforce en vous concentrant sur trois principes : [la disponibilité](/docs/architect/fr-fr/well-architected/guide/reliable#disponibilité), [les performances](/docs/architect/fr-fr/well-architected/guide/reliable#performances) et [l'évolutivité](/docs/architect/fr-fr/well-architected/guide/reliable#évolutivité). [La suite de produits](https://www.salesforce.com/platform/application-scaling-performance-testing/) évolutive de Salesforce offre des capacités natives qui aident les architectes à mettre en œuvre des implémentations fiables. ## Disponibilité La disponibilité est une mesure du pourcentage de temps pendant lequel votre système est opérationnel. Salesforce Platform gère la plupart des problèmes de disponibilité [au niveau infrastructurel](https://trust.salesforce.com/). Cependant, la disponibilité des solutions que vous élaborez sur la plate-forme, et qui sont expérimentées par vos clients, est une responsabilité partagée. Il est important de comprendre que même avec la [haute disponibilité](https://trust.salesforce.com/en/#systemStatus) de Salesforce, le risque d'interruption du service n'est jamais nul. Les architectes doivent se préparer aux interruptions du service Salesforce, par exemple une maintenance planifiée ou des circonstances imprévues. En plus des interruptions de service, déterminez comment maintenir des performances élevées et développer votre activité. Des choix architecturaux étroits peuvent entraîner des problèmes de disponibilité à long terme. Pensez à la disponibilité pendant la phase de conception, _avant_ l'élaboration de votre solution. Plus vous reportez l'architecture pour la disponibilité, plus le coût réel des problèmes de disponibilité sera élevé à long terme. Pour limiter les risques potentiels, utilisez Test de l'évolutivité Salesforce dans votre environnement de test. Dans cet environnement, vous pouvez tester à l'échelle de la production avant de déployer un code en production. Les architectes utilisent le langage de l'entreprise, en encadrant les préoccupations techniques des parties prenantes de l'entreprise pour obtenir l'adhésion et prioriser le travail de disponibilité.Pour limiter les risques potentiels, utilisez Test de l'évolutivité Salesforce dans votre environnement de test. Dans cet environnement, vous pouvez tester à l'échelle de la production avant de déployer un code en production. Vous pouvez concevoir une disponibilité accrue de vos solutions Salesforce grâce à la [gestion des risques](/docs/architect/fr-fr/well-architected/guide/reliable#gestion-des-risques) et [à la réduction](/docs/architect/fr-fr/well-architected/guide/reliable#atténuation-des-échecs) des pannes. ### Gestion des risques La gestion des risques dans le contexte de l'architecture Salesforce implique d'identifier les dangers potentiels pour le fonctionnement de votre système, ses utilisateurs, y compris les employés, les partenaires et les clients, et vos processus métiers. Souvent, le processus officiel d'analyse des risques relève des responsabilités des gestionnaires de projet. En tant qu'architecte, assurez-vous que l'analyse des risques représente adéquatement les préoccupations des parties prenantes techniques et commerciales. Il est également de votre responsabilité d'identifier les cas d'utilisation critiques pour l'entreprise que vous devez tester à l'échelle en fonction de vos points chauds de production. Certains des plus grands écueils de la gestion des risques viennent du fait que l'on n'y consacre pas suffisamment de temps et de réflexion. Les équipes ignorent souvent l'évaluation des risques ou confondent la résolution pour la [sauvegarde et la restauration](/docs/architect/fr-fr/well-architected/guide/resilient#renforcement-des-capacités-de-sauvegarde-et-de-restauration), une partie importante de l'atténuation des risques pour l'intégrité des données, avec une évaluation et une atténuation complètes des risques. Pour évaluer les risques pour vos solutions Salesforce, utilisez les méthodes suivantes : - **Utiliser un cadre** d'évaluation des risques. Certaines grandes entreprises ont peut-être déjà mis en place des matrices de risque pertinentes. Le cas échéant, utilisez-les pour déterminer comment classer les dangers, les types d'information à recueillir, les mesures à prendre pour y remédier, et davantage. Si vous n'avez pas encore de cadre d'évaluation des risques, recherchez-en un auprès d'une source fiable et utilisez-le. - **Évaluez la gravité de l'impact et les catégories de risque du point de vue de vos clients**. Proactive Monitoring et Scale Center fournissent des alertes et des tableaux de bord configurables. Ils évaluent en permanence les risques de performance et d'évolutivité, et réduisent votre dépendance aux listes de contrôle manuelles. Customer Trust et la perception sont essentiels à chaque entreprise. En termes d'impact commercial, les risques pour les problèmes qui touchent les clients l'emportent généralement sur les risques pour les problèmes qui ne touchent pas. Les clients peuvent ne pas penser ou percevoir les risques de la même façon que les équipes internes. Si un client ne peut pas se connecter à son compte, il ne se soucie probablement pas de l'origine du problème. Ils se soucient surtout de leur propre expérience immédiate. - **Priorité à vos risques**. Idéalement, chaque risque est lié à un solide plan d'atténuation et d'intervention. En réalité, vous aurez des écarts que vous devrez combler au fil du temps. Il est important d'adopter une approche « offrir la valeur tôt et itérer ». Vous et vos équipes de livraison et de maintenance ne pouvez prendre en charge qu'un volume de travail important à la fois. Chez Salesforce, une expression courante est « Si tout est important, rien n'est important ». Nous utilisons les V2MOM pour prioriser et aligner le travail dans toute l'entreprise, entre les équipes et jusqu'à chaque individu. (Vous pouvez en [savoir plus sur](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom) les V2MOM sur Trailhead.) Utilisez vos évaluations des risques, qui permettent de travailler avec vos parties prenantes sur la définition des priorités et l'engagement à l'égard des tâches de gestion des risques les plus importantes. Utilisez Test de l'évolutivité - Création de plan de test pour identifier les risques à prioriser et les atténuer en utilisant des tests à l'échelle. Utilisez Proactive Monitoring pour détecter les risques de disponibilité anticipée. Il expose des anomalies telles que des pics de limitation des requêtes d'API, des erreurs de verrouillage de ligne ou des échecs Apex simultanés, fournissant des connaissances actionnables avant que les problèmes ne dégénèrent en interruptions de service. Les [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/reliable#modèles-de-disponibilité-et-anti-modèles) de disponibilité montrent une gestion des risques correcte et médiocre dans une solution Salesforce. Utilisez les modèles pour valider vos conceptions avant de les élaborer ou pour identifier des zones de refactorisation dans votre système. Pour plus d'informations sur les outils Salesforce liés à la gestion des risques, consultez [Outils Salesforce pour fiabilité](/docs/architect/fr-fr/well-architected/guide/reliable#outils-salesforce-pour-la-fiabilité). ### Atténuation des échecs Un point de défaillance est une vulnérabilité qui rend un système peu fiable. Une bonne atténuation des échecs ne consiste pas à identifier chaque point de défaillance potentiel. À la place, il s'agit de classer et de prioriser rapidement les points de défaillance afin de permettre aux équipes de maintenance et de support d'intervenir efficacement. Consultez [Réaction à l'incident](/docs/architect/fr-fr/well-architected/guide/resilient#réponse-à-lincident). Pour développer de meilleures stratégies d'atténuation des échecs : - **Classez les déclencheurs de points de défaillance en termes de personnes, de processus et de technologie**. De la même façon que vous catégorisez les risques en termes de personnes, de processus et de technologie, appliquez la même réflexion au déclenchement des points de défaillance prioritaires. Cette approche vous aide à identifier les déclencheurs d'échec potentiels et à développer et organiser des réponses à ces derniers. Parfois, vous pouvez atténuer les déclencheurs de défaillance apparemment divergents avec des approches d'atténuation similaires, basées sur la classification des déclencheurs.
Classement/Type de déclencheur Mitigation
Personnes Police
Processus Playbooks, plans de continuité
Technologie Redondance
- **Identifiez à quoi ressemble l'atténuation de base, intermédiaire et mature**. Il faudra du temps pour élaborer des stratégies d'atténuation. Définissez les niveaux d'atténuation pour vous aider, vous et votre équipe, à déterminer où vous pouvez mettre immédiatement en place des contrôles et comment concentrer vos efforts sur le temps. Recherchez toujours des opportunités d'utilisation de l'automatisation dans vos approches d'atténuation, dès que possible. Pour illustrer cette approche dans la pratique, cet exemple montre un déclencheur axé sur les personnes et à quoi ressemble l'atténuation basée sur les politiques aux niveaux de base, intermédiaire et mature.
Déclencheur Mitigation Base Intermédiaire Mature
Modification de l’accès utilisateur pour un nouvel employé ou un employé qui quitte Accord de niveau de service (SLA) et exigences relatives au provisionnement ou au déprovisionnement des utilisateurs Provisionnez et déprovisionnez manuellement les utilisateurs, conformément aux accords de niveau de service pour les modifications manuelles. Traitez les modifications des utilisateurs à travers les tâches planifiées, conformément aux accords de niveau de service pour les modifications planifiées. Automatisez le provisionnement et le déprovisionnement des utilisateurs via une solution SSO/IDM.
Outre l'utilisation de livres-jeux architecturaux et la planification de la continuité, utilisez Proactive Monitoring. Avec Proactive Monitoring, vous pouvez configurer des alertes en temps réel sur des déclencheurs d'échec, tels que des échecs de connexion, des exceptions d'expiration du processeur ou des erreurs de requête d'API concurrentes. Cette approche d'alerte augmente l'atténuation des défaillances en s'assurant que les parties prenantes techniques et commerciales sont informées à temps pour réduire l'impact des défaillances. Les [modèles et anti-modèles de disponibilité](/docs/architect/fr-fr/well-architected/guide/reliable#modèles-de-disponibilité-et-anti-modèles) montrent à quoi ressemble une atténuation correcte et médiocre des défaillances dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système à refactoriser. Pour plus d'informations sur les outils Salesforce d'atténuation des défaillances, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/reliable#outils-salesforce-pour-la-fiabilité) Fiable. ### Modèles de disponibilité et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher ou à élaborer dans votre organisation, ainsi que des anti-modèles à éviter ou à cibler. ✨ Découvrez d'autres modèles de disponibilité dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/trusted-availability) et anti-modèle.
Modèles Anti-Patterns
Gestion des risques Dans votre entreprise :
- Un cadre d'évaluation des risques établi est utilisé.
- Les risques sont classés dans les domaines des personnes, des processus et de la technologie.
Dans votre entreprise :
- Le cadre d'évaluation des risques de Salesforce est ad hoc.
- Les risques ne sont pas clairement identifiés.
Dans votre documentation :
- La sévérité du risque est catégorisée et évaluée en fonction de l'impact client.
- Les plans d'atténuation des risques et d'intervention sont prioritaires.
Dans votre documentation :
- Le point de vue du client n'est pas pris en compte lors de l'évaluation de la sévérité ou de la catégorie de risque.
- Les plans d'atténuation des risques et d'intervention tentent de capturer tous les risques imaginables.
Atténuation des échecs Dans votre organisation :
- Les déclencheurs de point de défaillance et leurs plans d'atténuation correspondants sont classés par personnes, processus et technologie.
- Les contrôles d'atténuation sont mis en place immédiatement, matures au fil du temps et intègrent l'automatisation le plus tôt possible.
- Pour garantir une évolutivité optimale, des tests complets et une optimisation sont effectués avant la publication des modifications en production.
- Avant les événements critiques pour l'entreprise, des tests d'échelle et l'optimisation sont effectués, conformément aux accords de niveau de service.
Dans votre organisation :
- Les déclencheurs de point d'échec ne sont pas classés. Les approches d'atténuation n'existent pas ou ne sont utilisées que de façon ponctuelle.
- Les contrôles d'atténuation ne sont pas revisités ni améliorés.
- L'automatisation n'est pas utilisée dans l'atténuation.
Surveillance et observation Dans votre organisation :
- Pour les contrôles et la détection des anomalies, Proactive Monitoring est activé.
- Pour une visibilité permanente, les alertes Proactive Monitoring sont intégrées à Scale Center.
Dans votre organisation :
- Seuls des contrôles d'état de santé manuels sont effectués, et aucune surveillance continue n'est en place.
## Performances Les performances de l'architecture système sont une mesure du volume traité par un système (débit) et de la vitesse à laquelle il répond (latence). Généralement, vous comprenez les performances de votre système à travers des tests et une surveillance en production. Un système performant termine les processus en temps opportun à chaque niveau de demande prévu. Les performances médiocres vont de pair avec une latence plus élevée et un débit plus faible, ce qui entraîne une baisse de productivité et une augmentation de la frustration des utilisateurs. Corriger les problèmes de performance est urgent, car ils peuvent entraîner une perte de Trust client et des pertes financières. Vous pouvez améliorer les performances de vos solutions en optimisant le débit et la latence. > Remarque : L'optimisation du débit et de la latence sont des aspects essentiels de l'amélioration du traitement et de la réactivité du système. Il est toutefois important de se rappeler que les performances globales du système dépendent également de la qualité de votre conception à [l'échelle](/docs/architect/fr-fr/well-architected/guide/reliable#évolutivité). Vous devez tenir compte des deux dimensions dans vos conceptions. ### Débit Dans le contexte de l'architecture Salesforce, le débit correspond au nombre de requêtes simultanées qu'un système peut effectuer pendant une période donnée. Les solutions Salesforce des clients, conçues et optimisées pour le débit, fonctionnent mieux dans les [limites du gouverneur](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) intégré de Salesforce Platform. L'optimisation du débit dans Salesforce commence par calculer avec précision les charges de travail dans votre système et planifier leur croissance. Sans projections précises des exigences qui seront imposées au système, vous ne pouvez pas identifier les problèmes potentiels avec les capacités de débit de votre système. Lors de la réflexion sur les charges de travail, tenez compte des trois dimensions ci-dessous. - **Le nombre de transactions** que votre système doit traiter pendant une période donnée - **Le nombre d'utilisateurs** qui doivent accéder simultanément à votre système - **La complexité générale de la logique transactionnelle** dans le système Lorsqu'on pense aux performances, les équipes se concentrent parfois trop étroitement sur le calcul et les contraintes de temps processeur maximal, qui font partie des limites du gouverneur de la plate-forme. Les équipes qui se concentrent sur le temps processeur négligent les autres méthodes d'optimisation du débit. En élargissant votre attention et en appliquant ces méthodes, vous augmentez le débit global et l'efficacité de votre architecture Salesforce. Ces améliorations contribueront à réduire la latence et à améliorer les performances globales du système. ApexGuru détecte proactivement les anti-modèles qui limitent le débit, tels que SOQL dans les boucles, DML dans les boucles, les appels GGD inefficaces et les méthodes coûteuses. Ces connaissances aident les équipes à éliminer les risques de limitation du gouverneur qui limitent le débit. Pour optimiser le débit dans votre système : - **Favorisez le traitement asynchrone**. Salesforce Platform utilise des contextes de transaction pour contrôler l'intégrité des données et limiter l'emballement du code. Consultez [Transactions dans Bases](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#transactions) de l'architecture dans Bases de l'architecture. Pour cette raison, l'utilisation du traitement asynchrone (asynchrone) dans la mesure du possible peut aider à réduire les goulets d'étranglement potentiels dans les contextes d'exécution synchrone. Consultez [traitement des données](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-données). L'utilisation du calcul asynchrone n'est pas un remède à tous les problèmes de performance, et vous devez prendre en compte la latence lors de l'incorporation de processus asynchrones. Certaines capacités de la plate-forme, comme Apex pouvant être mis en file d'attente, peuvent augmenter la latence lors des pics de trafic, car elles entraînent une attente plus longue des messages dans une file d'attente. Selon votre cas d'utilisation, vous pouvez tolérer une diminution potentielle de la réactivité pour maintenir ou améliorer le débit. Dans d'autres cas, vous pouvez décider que l'augmentation de la latence n'est pas acceptable. Avec le Test de l'évolutivité, vous pouvez valider ces compromis en simulant des pics de trafic dans une organisation Sandbox Full Vous pouvez mesurer l'impact des tâches sur le débit et la latence. - **Toujours utiliser le vrac**. À un niveau élevé, le traitement en masse consiste à effectuer des opérations de collecte. Souvent, les équipes qui discutent de la rationalisation en masse de leurs solutions Salesforce se concentrent sur la rationalisation des opérations de collecte de données. Consultez [Logique opérationnelle](/docs/architect/fr-fr/well-architected/guide/automated#logique-opérationnelle). Cependant, le traitement en masse au niveau du système implique plus que de simples opérations de données. Considérez également certaines tâches, telles que les appels externes ou les calculs complexes, comme des candidats pour la tâche de traitement en masse. Un bon traitement en masse réduit les frais généraux. Il exécute plusieurs opérations avec une seule requête au lieu d'une requête par opération. ApexGuru expose des modèles anti-bulkification tels que [DML ou SOQL à l'intérieur](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5) de boucles, que vous pouvez corriger avant l'échelle en production. Consultez [Opérations en masse](/docs/architect/fr-fr/fundamentals/guide/platform-multitenant-architecture#opérations-en-masse). - **Utilisez SOSL pour les recherches et traitez SOQL comme une opération de données**. Il peut sembler évident que l'utilisation d'instructions SOQL trop complexes augmentera le temps nécessaire au système pour récupérer les enregistrements. SOQL ajoute des frais généraux à la [base de données relationnelle](/docs/architect/fr-fr/fundamentals/guide/platform-multitenant-architecture#la-couche-de-données-de-la-plate-forme) sous-jacente, ce qui ralentit le traitement. Lors de l'utilisation de critères de texte ou génériques, SOSL est plus performant. SOSL utilise le moteur de recherche de la plate-forme, qui est optimisé pour l'indexation en texte intégral et les recherches universelles. Pour optimiser les modèles de récupération d'enregistrements, assurez-vous que vos normes de conception spécifient quand utiliser SOSL pour rechercher des données dans votre système. Assurez-vous également de spécifier comment utiliser SOQL pour des opérations de données efficaces. Consultez [Logique opérationnelle](/docs/architect/fr-fr/well-architected/guide/automated#logique-opérationnelle)). - **Utilisez Cache de la plate-forme et ApexGuru**. La couche [Lightning Platform Cache](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm) accélère les performances et augmente la fiabilité lors de la mise en cache des données de session et d'organisation Salesforce. Le cache de la plate-forme améliore les performances en distribuant l'espace cache afin d'éviter que certaines applications ou opérations ne volent la capacité d'autres. ApexGuru détecte les opportunités manquées pour mettre en cache les requêtes répétées (par exemple, [Cache de plate-forme](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5) pour les résultats SOQL), ce qui améliore le débit dans les environnements à grande échelle. Les [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/reliable#modèles-de-performance-et-anti-modèles) de performance montrent à quoi ressemblent un débit correct et faible dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier des opportunités d'optimisation. Pour plus d'informations sur les outils Salesforce d'optimisation du débit, consultez [Salesforce Tools For Reliability](/docs/architect/fr-fr/well-architected/guide/reliable#outils-salesforce-pour-la-fiabilité) (Outils Salesforce pour la fiabilité). ### Latence La latence est une mesure de la vitesse à laquelle un système termine un parcours d'exécution. L'optimisation du débit de votre système contribuera à améliorer la latence. Une autre dimension de la latence est la performance perçue, ou la réactivité du système pour les utilisateurs. Les gens ne veulent pas attendre le chargement des pages ou la fin des processus. Les utilisateurs de votre système seront frustrés s'ils rencontrent souvent de longs temps de chargement en essayant de parcourir des vues de liste, des pages d'enregistrement, des rapports, etc. Dans ce cas, les clients ou partenaires peuvent décider de transférer leur activité ailleurs plutôt que de traiter avec des systèmes peu performants. À l’interne, les employés peuvent créer des contournements afin d’éviter d’utiliser le système tel que conçu, ce qui peut entraîner des problèmes en aval pour la sécurité et l’intégrité des données. Les performances perçues peuvent être difficiles à diagnostiquer. Lorsqu'un utilisateur signale des performances lentes, les équipes de support risquent de ne pas pouvoir reproduire le problème. L'augmentation de la latence est souvent le résultat d'une combinaison de petits problèmes qui s'accumulent mutuellement, ce qui peut rendre difficile le diagnostic de la cause exacte des problèmes de performance perçus. Pour réduire la latence et améliorer la réactivité dans votre système Salesforce : - **Optimisez les rapports**. Assurez-vous que chaque rapport sert un seul objectif spécifique. Identifiez clairement l'audience et l'objet de chaque rapport dans votre système. Dans les rapports, incluez uniquement le volume minimal de données dont les membres de l'audience ont besoin pour prendre des décisions. Le retrait des colonnes qui ne correspondent pas à l'objet d'un rapport améliore les performances du rapport en réduisant la quantité de données à récupérer et à afficher. - **Optimisez les filtres**. Des filtres efficaces accélèrent les performances des rapports et des vues de liste en limitant avec précision le nombre de lignes récupérées dans la base de données. En règle générale, plus votre logique de filtrage est spécifique, plus la requête de données sous-jacente est efficace. Les méthodes d'optimisation des filtres comprennent : - Utiliser « égal à » et « différent de » au lieu de « contient » et « ne contient pas » - Éviter le filtrage par champs de formule - **Simplifiez votre modèle** de partage. Un modèle de partage trop complexe peut ralentir divers processus, car le système doit vérifier le modèle de partage et de visibilité afin de déterminer si un utilisateur a accès aux données à afficher ou à traiter. Les calculs de partage complexes peuvent augmenter la latence dans les rapports, les vues de liste et l'automatisation exécutée dans le contexte de l'utilisateur. Consultez [Partage et visibilité](/docs/architect/fr-fr/well-architected/guide/secure#partage-et-visibilité). - **Optimisez les composants personnalisés** de l'interface utilisateur. Les composants Interface utilisateur (UI) personnalisés peuvent augmenter la latence. Pour optimiser les performances des composants d'interface utilisateur personnalisés, procédez comme suit. - **Utiliser des composants Web Lightning (LWC)**. L'infrastructure LWC est étroitement alignée sur les normes Web modernes. Les composants personnalisés écrits en LWC sont restitués plus efficacement dans les navigateurs Web et permettent aux développeurs d'utiliser des méthodes JavaScript plus performantes. Visez toujours à utiliser LWC au lieu des anciennes technologies d'interface utilisateur, telles que Aura ou Visualforce. - **Utilisez Lightning Data Service**. Lightning Data Service gère la création et la maintenance d'une mise en cache sécurisée, performante et partagée entre les composants. Utilisez-le pour éviter les allers-retours inutiles vers le serveur pour les données, et pour augmenter la réactivité générale des applications. - **Utilisez le tri et le filtrage côté client pour les données de liste**. Pour les composants LWC (préféré) et Aura (autrement), les développeurs peuvent utiliser la fonctionnalité de tableau JavaScript standard pour trier, filtrer et sélectionner des valeurs côté client, ce qui réduit le nombre de déplacements requis vers le serveur. Les [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/reliable#modèles-de-performance-et-anti-modèles) montrent la latence correcte et médiocre dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier des opportunités d'optimisation. Pour plus d'informations sur les outils Salesforce pour l'optimisation de la latence, consultez [Salesforce Tools For Reliability](/docs/architect/fr-fr/well-architected/guide/reliable#outils-salesforce-pour-la-fiabilité). ### Modèles de performance et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher ou à élaborer dans votre organisation, ainsi que des anti-modèles à éviter ou à cibler. ✨ Découvrez d'autres modèles de performance dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/trusted-performance) et anti-modèle.
Modèles Anti-Patterns
Débit Dans vos normes de conception :
- Le guide d'utilisation du cache de la plate-forme respecte les meilleures pratiques
Dans vos normes de conception :
- S'il existe un guide pour l'utilisation du cache de la plate-forme, il n'est pas clair ou n'est pas conforme aux meilleures pratiques.
Dans votre organisation :
- Le traitement en masse est utilisé pour les opérations sur les données et le système.
- Les méthodes DML ou de base de données fonctionnent toujours contre les collections dans Apex .
- Les champs utilisés pendant le DML pour un elapsedTime plus court dans la base de données sont limités.
- Tous les critères génériques sont utilisés en SOSL.
- Les instructions SOQL sont sélectives. :
-- Ils n'utilisent pas de comparaisons LIKE ou de comparaisons de texte partiel.
-- Les opérateurs de comparaison utilisent une logique positive (en d'autres termes, INCLUDES ou IN) comme logique principale ou uniquement logique.
-- = NULL et != NULL ne sont utilisés que rarement suit toujours un opérateur de comparaison positif.
– Pour minimiser le chargement des données et optimiser les performances, seuls les champs nécessaires dans les requêtes SOQL sont récupérés.
-- Aucune instruction LIMIT 1 n'est utilisée.
-- Le mot-clé ALL ROWS n'est pas utilisé.
- Le traitement asynchrone est privilégié dans la mesure du possible.
- Les partitions Cache de la plate-forme sont configurées.
Dans votre organisation :
- Les instructions DML ne sont pas traitées en masse.
- Les méthodes DML ou de base de données fonctionnent dans Apex contre des enregistrements uniques.
- SOSL est rarement ou pas systématiquement utilisé pour les critères de sélection de caractères génériques.
- Les instructions SOQL ne sont pas sélectives :
-- Ils incluent des critères de filtrage LIKE et générique.
-- Les comparaisons utilisant des critères !=, NOT ou NOT IN sont utilisées en tant qu'opérateur de comparaison principal ou unique.
-- Utilise = NULL et != critères NULL comme opérateurs principaux ou seulement de comparaison.
-- Les instructions LIMIT 1 sont utilisées.
-- Le mot-clé ALL ROWS est utilisé.
- SOQL est affiché dans les boucles.
- Les processus synchrones sont favorisés.
Latence Dans votre organisation :
- Les rapports servent un seul objectif spécifique et contiennent le nombre minimal de lignes et de colonnes nécessaires pour prendre des décisions.
- Les filtres utilisent « égal à » et « différent de ».
- Les filtres ne contiennent pas de champs de formule.
- Les modèles de partage sont simplifiés au maximum.
- Les composants d'interface utilisateur personnalisés utilisent des Composants Web Lightning (LWC).
- LWC utilise Lightning Data Service pour les opérations sur les données.
- Le tri et le filtrage des données de liste sont gérés côté client en JavaScript.
- Salesforce Edge est activé.
Dans votre organisation :
- Les rapports servent à plusieurs fins ou contiennent des lignes et des colonnes supplémentaires qui ne sont pas nécessaires pour prendre des décisions.
- Les filtres utilisent « contient » et « ne contient pas ».
- Les filtres contiennent des champs de formule.
- Les modèles de partage sont complexes.
- Les composants d'interface utilisateur personnalisés utilisent des frameworks qui peuvent entraîner un rendu moins efficace que LWC (par exemple Aura ou Visualforce).
- LWC utilise Apex pour les opérations de données.
- Les données des listes de tri et de filtrage sont gérées côté serveur en utilisant Apex.
- Salesforce Edge n'est pas activé.
## Évolutivité L'évolutivité est la capacité d'un système à fonctionner de façon cohérente à mesure qu'il évolue et se développe. Un système évolutif gère les augmentations importantes des volumes de transactions ou l'accès simultané sans modification fondamentale. Les services de plate-forme de Salesforce sont conçus pour prendre en charge l'évolutivité des applications. Consultez [Traitement interne de](/docs/architect/fr-fr/fundamentals/guide/platform-multitenant-architecture#traitement-de-la-plate-forme-interne) la plate-forme. Cela dit, à mesure que votre organisation se développe et que la demande pour vos produits et services augmente, vous êtes responsable de la création d'un système efficace et conforme aux attentes. L'architecture évolutive dès le départ accélère la livraison de nouvelles fonctionnalités et réduit les interruptions de service à mesure que le trafic utilisateur augmente. Au début de la phase de conception, avant de déployer de nouvelles fonctionnalités en production, utilisez **Test de l'évolutivité** pour simuler les charges de travail projetées et vérifier que l'architecture peut les adapter. Les systèmes non conçus pour l'évolutivité nécessitent un dépannage, une refonte et une refactorisation constants et coûteux. Les problèmes d'évolutivité s'aggravent au fil du temps et dégradent les performances dans l'ensemble du système. Dans certains cas, les entreprises dépensent la majorité des ressources de développement et de maintenance pour résoudre les problèmes d'évolutivité plutôt que pour de nouvelles fonctionnalités qui créent de la valeur. Parfois, une entreprise atteint un point de bascule critique. La conception originale de son système ne peut pas soutenir la croissance de l'entreprise, et des événements inattendus rendent le système instable. Utilisez les connaissances du **Scale Center** pour identifier rapidement les points de basculement de l'évolutivité. Le Centre d'échelle expose les points chauds d'exception, les transactions de longue durée et les goulets d'étranglement dans les files d'attente qui s'aggravent au fil du temps. Vous pouvez améliorer l'architecture d'échelle en vous concentrant sur l'optimisation du modèle de données et la gestion du volume de données. _Note : Bien que cela ne soit pas abordé ici, le test de l'évolutivité est une partie essentielle de la validation de vos architectures d'application. Pour plus d'informations, consultez [Stratégie de test](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-de-test)._ ### Modélisation des données La modélisation des données consiste à structurer les objets de votre organisation et à les associer les uns aux autres afin de permettre à vos utilisateurs et à vos processus automatisés de récupérer les données dont ils ont besoin le plus rapidement possible. Prendre des mesures pour [améliorer le débit](/docs/architect/fr-fr/well-architected/guide/reliable#débit) résout de nombreux problèmes de performance, mais vos efforts ne seront pas aussi efficaces sans un modèle de données optimisé. Les impacts négatifs d'un modèle de données mal conçu ne sont pas immédiatement visibles. Ses faiblesses sont exposées à mesure que le système se développe en termes de volume de données, de processus, d'utilisateurs et d'intégrations. Un modèle de données bien conçu facilite la refactorisation continue de votre application à mesure que les exigences sont ajoutées et étendues. **ApexGuru** expose des anti-modèles d'accès aux données tels que SOQL non sélectif, champs inutilisés et inefficacités de schéma qui impactent directement l'évolutivité du modèle de données. Pour optimiser votre modèle de données : - **Utilisez les modèles de données prédéfinis de Salesforce**. Salesforce fournit des modèles de données prédéfinis pour Sales, Service et divers secteurs d'activité. L'utilisation des modèles de données fournis par Salesforce garantit que les capacités de votre système sont définies une seule fois, éliminant ainsi la redondance et les silos, et établissant une source de vérité unique dans l'ensemble du système. Comme vous avez utilisé des modèles de données prédéfinis Salesforce pour cette source unique, il est plus facile de comprendre les données d'application avec des analytiques et d'utiliser les services d'intelligence artificielle prédéfinis de Salesforce. De plus, la réduction des personnalisations que vous devez prendre en charge réduit les coûts de maintenance et réduit la dette technique. - **Choisissez les types de données** appropriés. Comprenez les différents types de champ pris en charge par Salesforce et leurs limitations. Tenez compte des exigences de génération de rapports et de cryptage afin d'éviter d'avoir à convertir des données entre les types à l'avenir. - **Choisissez les bonnes relations**. Salesforce prend en charge deux types de relation entre les objets : principal-détails et référence. Les relations principal-détails offrent deux avantages principaux. L'un d'eux est les capacités récapitulatives de cumul intégrées, qui comptent et agrègent les détails des enregistrements enfants. L'autre est une capacité de suppression en cascade intégrée, par laquelle la suppression d'un enregistrement parent supprime également ses enregistrements enfants. Assurez-vous toutefois de bien comprendre les [conséquences de partage](/docs/architect/fr-fr/well-architected/guide/reliable#volume-de-données) et d'asymétrie des données des relations principal-détails avant de décider de les utiliser. - **Dénormalisez pour l'échelle.** La normalisation est le processus de structuration de votre modèle de données pour réduire la redondance des données et améliorer l'intégrité des données. Malheureusement, la normalisation entraîne parfois des problèmes d'échelle. Les tableaux dénormalisés peuvent être plus performants à l'échelle, mais pensez à prendre en compte l'intégrité et la redondance des données. Les [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/reliable#modèles-dévolutivité-et-anti-modèles) montrent à quoi ressemble l'optimisation correcte et médiocre du modèle de données dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier des opportunités d'optimisation. Pour plus d'informations sur les outils Salesforce d'optimisation du modèle de données, consultez [Salesforce Tools For Reliability](/docs/architect/fr-fr/well-architected/guide/reliable#outils-salesforce-pour-la-fiabilité) (Outils Salesforce pour la fiabilité). ### Volume de données Le volume de données est une mesure de la quantité de données stockées dans votre système, basée sur le nombre et la taille des enregistrements. Si votre organisation compte des dizaines de milliers d'utilisateurs, des dizaines de millions d'enregistrements ou des centaines de gigaoctets de stockage total d'enregistrements, vous avez un volume de données important. Le volume de données et les relations entre les objets de votre organisation affectent l'évolutivité et auront probablement un impact plus important sur l'évolutivité que le nombre d'enregistrements seul. Pour améliorer l'évolutivité des organisations qui ont des volumes de données importants : - **Distribuez des enregistrements enfants**. Évitez l'asymétrie des données parent-enfant en vous assurant qu'aucun parent n'a un grand nombre d'enregistrements enfants. La recommandation générale est qu'aucun parent ne devrait avoir plus de 10 000 enregistrements enfants. Par exemple, dans un déploiement qui contient de nombreux contacts, mais qui n'utilise pas de compte, vous pouvez configurer plusieurs enregistrements de compte et distribuer entre eux les enregistrements de contact associés. - **Distribuez la propriété des enregistrements**. Évitez l'asymétrie de propriété en vous assurant qu'aucun utilisateur ou file d'attente ne possède, ni que tous les membres d'un rôle ou d'un groupe public unique possèdent, plus de 10 000 enregistrements du même objet. Les données de « stationnement » avec un « utilisateur fictif » sont une pratique qui entraîne souvent un biais de propriété. Si vous rencontrez ce problème, tenez compte de son impact sur les [calculs de partage](/docs/architect/fr-fr/well-architected/guide/reliable#latence). Si vous ne pouvez pas redistribuer les enregistrements pour éviter l'asymétrie de propriété, évitez d'attribuer l'utilisateur propriétaire des données à un rôle. Si le modèle de partage de votre organisation nécessite une attribution de rôle, placez l'utilisateur propriétaire des données dans un rôle distinct en haut de la hiérarchie de partage. N'autorisez pas les changements fréquents ou imprévus dans le rôle de cet utilisateur, car toute modification aura des impacts importants sur les performances en raison des recalculs de partage. Éloignez cet utilisateur des groupes publics qui pourraient être référencés dans des règles de partage. - **Réduisez la quantité de données d'enregistrement dans Salesforce**. Salesforce est conçu pour offrir aux entreprises une vue unique de leurs clients. Il peut sembler contre-intuitif que la limitation des données dans Salesforce soit une meilleure pratique. Cependant, la puissance de la vue unique réside dans la mesure où elle permet aux utilisateurs professionnels de comprendre et d'agir sur les données des clients. À mesure que le volume de données augmente, les données qui ne sont pas à jour ou pertinentes pour les processus quotidiens ou les analytiques entraînent plusieurs problèmes. Ces problèmes comprennent une dégradation des performances de l'application, un risque accru pour la sécurité des données et des impacts négatifs sur la recherche, les rapports et les analytiques. Pour éviter de tels problèmes, définissez un cycle de vie des données pour chaque objet de votre modèle de données, avec des chronologies et des classifications pour les données vieillissantes et perdant immédiatement de leur valeur métier. Conformément au cycle de vie des données, implémentez ces procédures pour gérer les données au fil du temps. - **Archivage et purge** des données : pour limiter au maximum les volumes de données, retirez les enregistrements dont l'entreprise n'a pas besoin pour limiter au maximum les volumes de données. Utilisez la fonction de suppression définitive de l'API de transfert en masse 2.0 pour supprimer des volumes de données importants. - **Agrégation de données :** créez des objets personnalisés d'agrégation qui résument les tendances historiques clés ou les données récapitulatives sous un format compatible avec les rapports. Remplissez les objets personnalisés en utilisant [Apex par lot](/docs/architect/fr-fr/well-architected/guide/reliable#débit). Les utilisateurs peuvent ensuite exécuter des rapports basés sur les enregistrements d'objet agrégés. - **Nivelage des données**. Conservez les jeux de données volumineux dans une autre application s'ils ne sont pas nécessaires pour les rapports Salesforce ou le travail quotidien. Rendez les données disponibles dans Salesforce si nécessaire via des mashups, des renvois ou des objets externes. En pratique, vous ne pouvez pas toujours résoudre immédiatement la cause profonde d'un problème d'évolutivité en cas de problème. Pour cette raison, Salesforce fournit des options qui aident à soulager les points douloureux immédiats. Il est important de savoir que l'activation de ces fonctionnalités dans votre organisation n'est pas une stratégie architecturale viable à long terme pour gérer des volumes de données importants. Ces solutions de contournement à court terme peuvent aider à réduire la latence dans les systèmes souffrant d'une architecture de données médiocre, mais elles peuvent également ajouter une dette technique à votre organisation. Les contournements à court terme des problèmes d'échelle comprennent : - Les index **personnalisés** sont stockés dans un tableau interne spécial que l'optimiseur de requête de la plate-forme utilise pour accélérer les opérations d'accès aux données. Consultez [Index multiples](/docs/architect/fr-fr/fundamentals/guide/platform-multitenant-architecture#indexes)). La plate-forme indexe automatiquement certains types de champ par défaut. Pour accélérer les requêtes peu performantes, vous pouvez demander des index personnalisés supplémentaires en contactant le Support client de Salesforce. Utilisez l'outil Plan de requête pour déterminer si les index personnalisés améliorent les performances de vos requêtes. - **Tables maigres**. Si vous devez optimiser davantage les requêtes pour des ensembles de champs communs dans des objets contenant plus d'un million d'enregistrements, des tableaux fins peuvent vous aider. Les tableaux fins éliminent la [jointure en arrière-plan](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm) qui se produit lors de l'utilisation de champs personnalisés et standard du même objet dans un rapport ou une automatisation. Pour pouvoir utiliser des tableaux fins, le Support client de Salesforce doit les activer pour votre organisation. Les [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/reliable#modèles-dévolutivité-et-anti-modèles) d'évolutivité montrent à quoi ressemble une gestion correcte et médiocre du volume de données dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier des opportunités d'optimisation. Pour plus d'informations sur les outils Salesforce de gestion des volumes de données, consultez [Outils Salesforce pour fiabilité](/docs/architect/fr-fr/well-architected/guide/reliable#outils-salesforce-pour-la-fiabilité). ### Modèles d'évolutivité et anti-modèles Il montre une sélection de modèles à rechercher ou à élaborer dans votre organisation, et des anti-modèles à éviter ou à cibler pour la correction. ✨ Découvrez d'autres modèles d'évolutivité dans l'[explorateur Pattern & Anti-Pattern](/docs/architect/fr-fr/well-architected-tools/guide/trusted-scalability).
Modèles Anti-Patterns
Modélisation des données Dans vos normes de conception :
- Il existe des normes et des directives pour lesquelles des justifications métiers justifient un objet personnalisé.
Dans vos normes de conception :
- Aucune norme de création d'objets personnalisés n'existe.
Dans votre modèle de données :
- Les objets standard sont utilisés dans la mesure du possible.
- Les contrôles ApexGuru des anti-modèles confirment que les requêtes SOQL sont sélectives et évitent l'utilisation inefficace du schéma.
- Les tableaux sont dénormalisés pour l'échelle.
Dans votre modèle de données :
- Vous avez répliqué des objets standard.
- Les tableaux sont normalisés pour éviter la redondance.
Au sein de votre entreprise :
- Les générateurs de code faible comprennent les différents types de champ pris en charge par Salesforce, et évaluent les exigences de génération de rapports et de cryptage avant de sélectionner des types de données de champ.
- Avant de décider d'établir une relation principal-détails entre des objets, vous évaluez les implications de partage et d'asymétrie des données de cette relation.
Au sein de votre entreprise :
- Les générateurs à faible code sélectionnent des types de données sans évaluer les exigences de génération de rapports et de cryptage en aval.
- Avant de décider d'établir des relations principal-détails entre des objets, vous n'évaluez pas les implications de partage et d'asymétrie des données de cette relation.
Volume de données Dans vos données :
- Aucun enregistrement parent ne contient plus de 10 000 enregistrements enfants.
- Aucun utilisateur n'est attribué à plus de 10 000 enregistrements de même type d'objet.
- Aucune instance ne contient plus de 10 000 enregistrements qui ont des champs de référence pointant vers le même enregistrement.
- Les chargements de données en masse sont triés par lots en fonction des valeurs de champ ParentId.
- Pour s'assurer que les stratégies par lot ne se brisent pas en cas de concurrence, le Test de l'évolutivité est utilisé pour valider les modèles de chargement en masse à l'échelle de production.
- Les chargements de données en masse en production ne sont pas effectués pendant les heures de pointe.
- Les chargements de données en masse incluent uniquement les données minimales nécessaires pour les décisions métiers.
Dans vos données :
- Des enregistrements contenant plus de 10 000 enregistrements enfants existent.
- Les utilisateurs sont attribués à plus de 10 000 enregistrements de même type.
- Il existe des instances dans lesquelles plus de 10 000 enregistrements ont des champs de référence qui pointent vers le même enregistrement.
-Les chargements de données en masse ne sont pas triés par lots en fonction des valeurs de champ ParentId.
- Les chargements de données en masse en production ont lieu pendant les heures ouvrables de pointe.
- Les chargements de données en masse ne sont pas limités aux données minimales requises pour les décisions métiers.
Dans Flow et Apex :
- Une logique existe pour distribuer le nombre d'enregistrements enfants entre plusieurs enregistrements parents dans les scénarios où l'asymétrie des données est préoccupante.
- Lors de l'importation ou de la réplication d'enregistrements via l'intégration, la logique les attribue aux utilisateurs humains appropriés.
- Pour les collections Apex, telles que les listes et les ensembles, une logique existe pour traiter plusieurs enregistrements afin de minimiser les requêtes et d'optimiser le traitement des données.
- Un code Apex efficace qui suit les normes et les meilleures pratiques pour un code évolutif est écrit et déployé.
Dans Flow et Apex :
- Les enregistrements enfants sont attribués arbitrairement à des enregistrements parents, quel que soit le nombre d'enregistrements enfants déjà attribués.
- Les enregistrements créés via des chargements de données ou des intégrations sont attribués à un « utilisateur de l'intégration » générique.
- Plusieurs requêtes SOQL récursives à partir du même objet sont dans des transactions synchrones, ce qui entraîne une utilisation élevée de la pile.
- Lorsque les développeurs écrivent un code Apex, ils introduisent des inefficacités et des anti-modèles de performance.
Au sein de votre entreprise :
- Vous avez documenté et mis en place une stratégie d'archivage et de purge des données
Au sein de votre entreprise :
- Vous n'avez pas de stratégie d'archivage et de purge des données ou votre stratégie a été documentée, mais pas implémentée
## Outils Salesforce pour la fiabilité
OutilDescriptionDisponibilitéPerformancesÉvolutivité
Gros objets Stockez et gérez des volumes de données importants sur la plate-forme. X
Scanner de code Scannez le code Apex pour détecter les problèmes de performance. X
Index personnalisés Améliorez les performances des requêtes avec des index personnalisés. X
Suppression de données Supprimez les données inutiles pour améliorer les performances. X X
Divisions Partitionnez les données pour limiter le nombre d'enregistrements dans les requêtes et les rapports. X
Test à l'échelle Testez les performances du système et interprétez les résultats. Avant le déploiement en production, pour valider l'évolutivité et les performances, imitez les charges de travail d'interface utilisateur et d'API à grande échelle en utilisant des scripts Playwright ou JMeter. X X
Centre d'échelle Recueillez des connaissances en libre-service et en temps réel sur les performances du système. Recherchez les transactions à long terme, les points chauds d'exception et les blocages de débit. Diagnostiquez les problèmes d'échelle plus tôt dans votre cycle de développement. X X
ApexGuru Utilisez cette fonctionnalité basée sur GenAI dans le Centre d'échelle pour détecter Apex, SOQL et les anti-modèles de classe de test à l'exécution. Avec l'intégration d'ApexGuru à Salesforce Code Analyzer, recevez des recommandations pilotées par l'IA et des correctifs en ligne dans le workflow de développement. Utilisez ces recommandations et correctifs pour résoudre les points chauds et améliorer la sélectivité des requêtes, le traitement en masse, l'utilisation de la mémoire cache et la qualité des tests. X X
Salesforce Code Analyzer Scannez le code avec IDE, CLI ou CI/CD pour vous assurer qu'il respecte les meilleures pratiques. Avec l'intégration de Salesforce Code Analyzer à ApexGuru, recueillez des connaissances sur les anti-modèles de performance directement dans le workflow du développeur. X
Salesforce Edge Network Améliorez les temps de téléchargement et l'expérience utilisateur en acheminant votre Mon domaine via le Réseau Edge Salesforce. X
Tableaux fins Évitez les jointures dans les tableaux qui contiennent des champs fréquemment utilisés. X
Proactive Monitoring Surveillez en permanence les anomalies de croissance record, d'asymétrie de propriété et de régression des performances. Alertez sur les problèmes d'échelle avant qu'ils ne deviennent critiques. X X
## Ressources Salesforce pour la fiabilité
RessourceDescriptionDisponibilitéPerformancesÉvolutivité
Les défis d'échelle coûtent des millions — Voici comment pérenniser votre activité Découvrez comment la mise en œuvre de l'évolutivité conduit à une croissance durable et à la réussite à long terme. X X
Élaboration et déploiement d'applications évolutives en utilisant le Centre d'échelle Comprenez comment évaluer et résoudre proactivement les problèmes de performance dans vos implémentations Salesforce.
Analyse des performances et des points chauds d'échelle dans les applications Salesforce complexes Corrigez les problèmes de performance et d'évolutivité dans votre organisation. X X
Votre application ne devrait pas paniquer dans le trafic aux heures de pointe - Voici comment vous préparer Découvrez quatre étapes clés pour réussir les tests d'échelle.
Le moteur IA ApexGuru expliqué Découvrez comment ApexGuru utilise des modèles entraînés sur mesure, la télémétrie d'organisation réelle et le filtrage intelligent pour fournir des connaissances précises, contextuelles et actionnables. X X
Optimisation de votre Apex pour les applications et Agentforce avec ApexGuru Apprenez comment ApexGuru aide les développeurs à détecter et corriger les anti-modèles de performance, notamment SOQL, DML, le débogage, et tester les inefficacités., Utilisez ApexGuru en tant que coach piloté par l'IA pour le développement évolutif de vos applications et votre implémentation d'Agentforce. X X
ApexGuru Antipatterns Découvrez la bibliothèque officielle des anti-modèles détectés par ApexGuru, qui est mise à jour pour chaque version majeure de Salesforce. X X
Meilleures pratiques pour les déploiements avec des volumes de données importants Comprenez les impacts des processus des volumes de données importants. X
Considérations relatives au Réseau Edge Salesforce Découvrez comment préparer votre organisation à utiliser le Réseau Edge Salesforce. X
Modèle Design Standards Créez des normes de conception pour votre organisation. X X X
Considérations relatives à la conception de modèles de données Optimisez les modèles de données pour l'échelle et la maintenance. X X
Conception de l'accès aux enregistrements pour Enterprise Scale Optimisez les performances du contrôle d'accès par la configuration. X
Infrastructure pour les systèmes avec des volumes de données importants Découvrez les capacités qui prennent en charge les performances système pour les déploiements avec des volumes de données importants. X
Ressources d'apprentissage pour la gestion par lot Découvrez la Gestion par lot. X X
Optimisation des performances Lightning Experience Améliorez Lightning Experience dans votre organisation pour aider vos utilisateurs à travailler plus vite. X
Gestion de l'asymétrie des références dans Salesforce pour éviter les exceptions de verrouillage d'enregistrement Comprenez comment minimiser les effets des biais de référence. X X
Meilleures pratiques SOQL et SOSL Suivez les meilleures pratiques SOQL et SOSL pour les déploiements avec des volumes de données importants. X X
Outils pour les réalignements à grande échelle Planifiez et exécutez efficacement les réalignements. X
Utilisation de Mashups Gérez des jeux de données volumineux dans une autre application. X X
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Les solutions intentionnelles offrent une valeur métier immédiate et au fil du temps. Les architectures intentionnelles sont planifiées et livrées de façon stratégique, peuvent être maintenues efficacement et sont faciles à lire et à comprendre pour les humains. Les fonctionnalités et les correctifs sont priorisés et livrés de façon transparente pour les parties prenantes commerciales et technologiques. Les choix d'ingénierie créent des implémentations faciles à utiliser pour les équipes de livraison et de maintenance, sans fonctionnalités ou complications supplémentaires. Les architectures intentionnelles sont plus faciles à approprier, à gérer et à faire évoluer avec l'entreprise, car elles suivent des modèles d'implémentation clairs et cohérents. Les générateurs peuvent interpréter et implémenter des conceptions pour de nouvelles fonctionnalités, et les équipes de maintenance peuvent comprendre la documentation sur les éléments implémentés. Vous pouvez créer des systèmes plus intentionnels en vous concentrant sur trois domaines clés : stratégie, maintenabilité et lisibilité. ## Stratégie La stratégie en architecture signifie que les systèmes sont soigneusement planifiés et livrés. Cela signifie que les équipes de livraison et de maintenance ont une vue claire du travail à réaliser aujourd'hui et à l'avenir, et que tout le monde est aligné sur le « pourquoi » du travail à réaliser. Cela signifie que les demandes urgentes peuvent être triées de façon efficace et efficiente, et que les parties prenantes peuvent comprendre clairement les impacts et les compromis des demandes. Vous pouvez élaborer une stratégie plus claire dans votre architecture en vous concentrant sur la priorisation, la feuille de route et la gouvernance. ### Priorisation La priorisation signifie planifier l'ordre et la portée du travail que vous allez réaliser. La priorisation consiste à comprendre l'impact réel des livrables sur l'entreprise, à évaluer ces impacts par rapport à d'autres demandes de travail et à la feuille de route globale de votre produit ou programme. Une façon d'évaluer l'impact d'un élément de travail donné est d'examiner le coût ou l'avantage réel pour l'entreprise. Une fois les [indicateurs de performance](/docs/architect/fr-fr/well-architected/guide/automated#kpis) clés identifiés pour l'automatisation, vous pouvez utiliser une [feuille de calcul](/docs/architect/fr-fr/resources/guide/kpi-spreadsheet-template) d'impact métier pour évaluer le coût ou les avantages globaux de l'implémentation. Ces calculs peuvent vous aider à obtenir l'adhésion de vos parties prenantes sur les automatisations à élaborer et dans quel ordre. Ils peuvent également vous aider à identifier les automatisations à reporter ou à éviter. Pour les automatisations, consultez [Conception de processus](/docs/architect/fr-fr/well-architected/guide/automated#conception-de-processus) pour plus d'informations sur l'identification d'un travail efficace. L'établissement d'un cadre de priorisation de la livraison vous aidera également, vous et vos équipes de maintenance, à gérer les attentes des utilisateurs et à respecter votre feuille de route. Voici quelques considérations que vous pouvez prendre en compte pour prioriser : - Impact commercial (coût/avantage) du produit livrable - Montant des nouveaux travaux requis pour le livrable - Volume de travail requis pour maintenir le produit livrable La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-stratégie-et-anti-modèles) ci-dessous montre à quoi ressemble la priorité appropriée (et mauvaise) en ce qui concerne le travail Salesforce. Vous pouvez les utiliser pour valider vos plans de mise en œuvre, ou identifier les zones où vous devez mieux identifier les priorités avant de les élaborer. Pour plus d'informations sur les outils disponibles dans Salesforce pour faciliter la définition des priorités, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/intentional#outils-pertinents-pour-intentionnel) Intentionnel. ### Mappage routier Une feuille de route est une vue prioritaire, validée et bien définie des actions à réaliser. Des feuilles de route efficaces donnent une image claire de l'impact commercial et technologique des travaux à venir. L'engagement de vos parties prenantes commerciales et techniques est un élément clé de la feuille de route. Les feuilles de route permettent de recueillir des commentaires et d'obtenir l'adhésion sur l'approche et les résultats avant le début des travaux. En fin de compte, les feuilles de route alignent chaque partie prenante sur le « pourquoi » du travail à venir. Si votre équipe utilise un backlog, il est important de comprendre que votre feuille de route n'est pas un résumé ou une liste des éléments du backlog. La relation est inverse : Les éléments doivent entrer dans le backlog uniquement s'ils peuvent être liés de façon claire et crédible à un livrable de votre feuille de route. Des feuilles de route de grande qualité, créées avec l'engagement des parties prenantes, fournissent aux équipes de livraison et de maintenance une vue claire des éléments sur lesquels elles doivent se concentrer et de la façon dont elles doivent prioriser les demandes, ce qui facilite le tri des demandes conflictuelles et la gestion des attentes des parties prenantes. Une mauvaise cartographie ou l'inexistence d'une carte routière entraîne : - Manque de clarté quant à la date de disponibilité des nouvelles fonctionnalités - Priorités conflictuelles entre les parties prenantes - Un décalage entre les solutions livrées et la vision globale de l'organisation - Difficulté à comprendre les travaux en cours - Charges de travail inégales entre les équipes - Manque de visibilité des relations et des dépendances entre les éléments de travail - Implémentations bloquées, en raison de dépendances mal gérées Les parties prenantes ont souvent besoin d'informations correspondant à leurs rôles pour prendre des décisions. La création de feuilles de route efficaces nécessite une compréhension claire de votre audience et du type d'information dont elle a besoin. Les feuilles de route sont classées en deux styles pour soutenir les audiences métiers et techniques. Chaque style contient deux niveaux de granularité pour prendre en charge différents types d'information. Les feuilles de route métiers aident les parties prenantes à planifier les changements organisationnels, à tirer parti des opportunités de croissance et à respecter les objectifs de l'entreprise. Les feuilles de route métiers permettent également de s'assurer que les dépenses informatiques correspondent à la vision métier globale. - Créez une feuille de route des capacités métiers pour montrer aux dirigeants les capacités qui seront activées. Ce type de feuille de route contient des détails généraux sur les capacités elles-mêmes et leur adéquation avec les objectifs métiers, par exemple l'augmentation de l'efficacité opérationnelle ou le lancement d'une nouvelle gamme de produits. - Créez une feuille de route de fonctionnalité métier pour explorer une capacité spécifique, et montrez ses fonctionnalités de support et ses fonctionnalités lorsque vous devez aider les parties prenantes de l'entreprise avec la planification des ressources, l'élaboration du budget et la gestion du changement. Les feuilles de route technologiques aident les parties prenantes techniques à planifier l'allocation de budgets et de ressources. Ils aident également les équipes de mise en œuvre à comprendre la place de leurs projets dans une perspective globale et à identifier les dépendances inter-équipes. - Créez une feuille de route du système technologique pour montrer les systèmes spécifiques qui seront implémentés, ainsi que toutes les dépendances au niveau du système. Ce type de feuille de route montre des informations générales sur le système et l'alignement entre les systèmes et les capacités métiers. - Créez une feuille de route pour les composants technologiques afin d'explorer les composants spécifiques d'un système qui sera déployé pour répondre aux exigences de planification et d'activation des ressources. Ce type de feuille de route affiche les informations au niveau du composant et les exigences de mise en œuvre (par exemple, développement déclaratif, pro-code, etc.). Assurez-vous que vos feuilles de route contiennent des calendriers réalistes. Une erreur fréquente consiste à inclure uniquement le temps nécessaire pour implémenter un système sans tenir compte également du temps nécessaire pour réaliser les activités connexes. Cela peut entraîner une surallocation des membres de l'équipe d'implémentation et des délais plus longs que prévu. Lors de la création d'une feuille de route, tenez compte du temps nécessaire pour réaliser les éléments suivants : - Documentation de toutes les fonctionnalités nouvelles et mises à jour - Maintenance des fonctionnalités existantes nécessaires pour prendre en charge les nouvelles fonctionnalités - Mises à jour des systèmes associés requises pour prendre en charge les intégrations - Augmentation du soutien des équipes de projet immédiatement après la mise en ligne - Tests, formation et gestion du changement Des feuilles de route métiers et technologiques bien alignées présentent une vue globale de la mise en service des capacités et de la technologie qui les sous-tend. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-stratégie-et-anti-modèles) ci-dessous montre à quoi ressemblent les feuilles de route correctes (et médiocres) pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer votre stratégie de cartographie routière. Pour plus d'informations sur les outils Salesforce qui peuvent vous aider avec le mappage routier, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/intentional#outils-pertinents-pour-intentionnel) Intentionnel. ### Gouvernance La gouvernance est la structure que vous utilisez pour gérer la priorisation, la prise de décision et la gestion du changement avec vos parties prenantes. La gouvernance indique clairement comment les décisions sont prises et communiquées. Il fournit des moyens cohérents pour les commentaires et les demandes d'entrée dans le processus décisionnel, et pour toutes les parties prenantes de comprendre l'état des travaux de maintenance et de développement. La gouvernance aide à définir des processus de gestion clairs et cohérents, et aide tous les membres de l'équipe à comprendre leurs rôles et responsabilités. Sans gouvernance adéquate, les équipes seront confrontées à divers problèmes, notamment : - Les demandes de superposition de fonctionnalités et de fonctionnalités arrivent au cas par cas - Les équipes de mise en œuvre priorisent les efforts « plus faciles » ou les demandes des parties prenantes plus influentes, sans prendre en compte correctement la valeur métier, les compromis ou les objectifs généraux de l'organisation. - Manque de cohérence des processus d'approbation et d'examen - Cadences de publication et qualité incohérentes - Taux de défauts élevés, écrasements, conflits et travail redondant dans les efforts de développement Le signe le plus clair qu'un système n'a pas une gouvernance efficace est peut-être la lenteur et la lourdeur des publications. Il est important de reconnaître que la taille d'un système de gouvernance ne mesure pas son efficacité. En fait, des systèmes élaborés de gouvernance (comme ceux que l'on trouve dans de nombreuses grandes entreprises) peuvent limiter la vitesse et la fréquence des publications. Une bonne gouvernance consiste à empêcher les mauvaises personnalisations de passer les premières étapes du développement, et à intégrer les bonnes personnalisations en production de façon prévisible et cohérente. Trop souvent, les efforts de gouvernance sont réactionnaires. Ils sont initiés ou redoublés lorsqu'un problème, par exemple une dette technique excessive, commence à devenir un problème métier. Dans de nombreux cas, la réponse malheureuse est que l'entreprise « verrouille » les efforts de développement et les versions, au lieu de créer des [normes de conception](/docs/architect/fr-fr/resources/guide/design-standards-template) efficaces et d'élaborer une automatisation pour appliquer ces normes dans les chaînes d'outils pour développeur et les systèmes de contrôle de code source. Lors de l'élaboration de l'infrastructure de votre système de gouvernance Salesforce, incluez les éléments suivants et tenez compte des questions clés suivantes auxquelles vous devez répondre : - **Demandes de travail.** Comment les utilisateurs peuvent-ils demander des fonctionnalités ? Comment les bogues sont-ils signalés ? - **Priorité et planification des travaux.** Qui décide quelles demandes de travail sont importantes ? Comment le travail est-il défini, priorisé, accepté ou approuvé ? - **Environnements et planification de versions.** Quel est le pipeline d'environnement pour le développement, les tests et la publication ? Qui fait quoi pour provisionner, actualiser et accorder l'accès ? Qui gère les déploiements et la validation ? Comment et quand les modifications sont-elles publiées ? Comment gérer les déploiements ou les environnements pendant un cycle de publication de Salesforce ? (pour plus d'informations, consultez [Gestion du cycle](/docs/architect/fr-fr/well-architected/guide/resilient#gestion-du-cycle-de-vie-des-applications) de vie des applications). - **Appui à la propriété du service et à la production.** Qui prend en charge quoi ? Qui gère les problèmes de production « corrigés » ? Comment ces éléments sont-ils testés et publiés ? Qui est responsable des normes de sécurité globales de l'organisation ? La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-stratégie-et-anti-modèles) ci-dessous montre à quoi ressemble une bonne (et mauvaise) gouvernance pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer votre stratégie de gouvernance. Pour plus d'informations sur les outils Salesforce disponibles pour la gouvernance, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/intentional#outils-pertinents-pour-intentionnel) Intentionnel. ### Modèles de stratégie et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles de stratégie dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/easy-strategy) et anti-modèle.
Modèles Anti-Patterns
Priorité Dans votre documentation :
- Tous les nouveaux éléments de travail ont des métriques de valeur métier claires (par exemple, augmentation du chiffre d'affaires, économies de coûts liées à l'optimisation des processus, etc.)
- Feuilles de route montrant le travail prioritaire en fonction de la valeur métier
Dans votre documentation :
- La valeur commerciale associée au travail n'est pas claire ou n'existe pas
- Les feuilles de route n'existent pas
Au sein de votre entreprise :
- Les coûts de mise en œuvre et de maintenance ont été identifiés pour tous les éléments de travail
- Les demandes de fonctionnalités sont priorisées en fonction de l'impact sur l'entreprise, de la quantité de nouveaux travaux à livrer et de la quantité de travail à maintenir
Au sein de votre entreprise :
- Les coûts associés à l'implémentation et à la maintenance des fonctionnalités ne sont pas clairs
- Les demandes sont livrées de façon ponctuelle ou selon le principe du premier entré/premier sorti
Cartographie routière Feuilles de route :
- Communiquer des informations adaptées à votre audience (métier ou technique)
- Communiquer les informations au niveau de détail correct
- Afficher les dates de début et de fin
- Afficher les prérequis et les dépendances
Feuilles de route (si elles existent) :
- Sont utilisés comme matériel de lancement de projet et non comme artefacts pour la livraison
- Ne pas aider à aligner les parties prenantes et les équipes de livraison
-Mélanger les niveaux de détail (par exemple, en incluant des systèmes et des composants dans la même feuille de route)
- Contenir des informations qui ne sont pas adaptées à leur audience (par exemple, les capacités métiers et les systèmes dans la même feuille de route)
Au sein de votre entreprise :
- Les parties prenantes comprennent le « pourquoi » des éléments de travail
- Les équipes de livraison savent évaluer les éléments du backlog par rapport aux priorités à plus long terme
- Les équipes savent qui fait quoi et comment gérer les dépendances
- Le travail est intentionnel, même lorsque les priorités doivent changer rapidement
Au sein de votre entreprise :
- Le travail est extrait de tout ce qui est dans le backlog et il n'y a pas de « pourquoi » clair
- Les équipes ont du mal à coordonner le travail interdépendant et souvent à répliquer le travail sans s'en rendre compte
- Le travail est souvent réactif
- Les intervenants se sentent souvent frustrés et confus au sujet de ce qui est fait et sont fatigués lorsque de nouvelles capacités seront livrées
Gouvernance Au sein de votre entreprise :
- Les utilisateurs peuvent aisément signaler des bogues et demander des fonctionnalités
- Le processus de priorisation des éléments de travail est documenté et transparent pour toutes les parties prenantes
- La stratégie environnementale est clairement documentée et les environnements de développement correspondent à la documentation
- La planification de la version est prévisible et transparente pour tous les membres de l'équipe de livraison
- Les membres de l'équipe savent qui est responsable de quoi tout au long du cycle de vie de l'application
- Les versions sont claires pour les utilisateurs et les équipes de livraison/maintenance
- Les processus de support en production sont clairs et les correctifs ont un chemin clair vers la production
- Les équipes et les projets utilisent uniquement des modèles IA approuvés pour des usages métiers
Au sein de votre entreprise :
- Les rapports de bogues et les demandes de fonctionnalité sont ponctuels
- Les éléments de travail n'ont pas de priorité claire
- Les environnements sont provisionnés ad hoc et peuvent ne pas être actualisés de façon prévisible; les développeurs n'ont souvent pas les environnements et l'accès dont ils ont besoin
- Les versions sont imprévisibles pour les équipes de diffusion et les utilisateurs
- Les équipes ne savent pas qui est responsable de quoi
- Les correctifs sont traités ad hoc
- Votre backlog est devenu une « banque d’idées » périmée et stagnante
- Les organes de gouvernance agissent comme un service d'assistance qui dépanne les demandes de support
- La documentation n'est pas facilement accessible
- Les équipes sélectionnent des modèles IA ad hoc
## Maintenabilité La maintenabilité signifie qu'un système peut être maintenu dans un état sain, avec de nouvelles fonctionnalités entrant dans le système et une dette technique sortant du système sur une base régulière et prévisible. Les systèmes maintenables permettent à vos équipes d'offrir de la valeur à l'entreprise avec une rapidité et une qualité prévisibles. La maintenabilité d'un système dépend de plusieurs facteurs, notamment de sa lisibilité, de son faible couplage et de la rigueur de sa stratégie de test. Plus important encore, la maintenabilité d'un système dépend de la simplicité de sa conception. Cette section présente comment créer des conceptions de solutions plus simples et améliorer la maintenance. Vous pouvez élaborer des solutions plus faciles à gérer en vous concentrant sur deux éléments clés : l'utilisation de fonctionnalités standard plutôt que personnalisées et le traitement de la dette technique. ### Fonctionnalité standard par rapport à la fonctionnalité personnalisée Salesforce offre une gamme de solutions prédéfinies - Sales Cloud, Service Cloud et de nombreuses solutions de l'industrie Salesforce - ainsi que la flexibilité nécessaire pour créer vos propres solutions personnalisées. Les services de base qui propulsent les propres solutions cloud de Salesforce sont également disponibles pour toutes les solutions personnalisées élaborées sur Salesforce Customer 360 Platform. Utilisez les services et solutions prédéfinis de Salesforce comme fondation de confiance pour autant de solutions que possible. L'utilisation de services de plate-forme prédéfinis présente deux avantages distincts. Tout d'abord, vos applications bénéficient naturellement des toutes dernières innovations Salesforce à chaque version. Ensuite, vos équipes de développement peuvent se concentrer sur l'expansion et l'approfondissement des capacités métiers fournies par vos solutions Salesforce plutôt que de gérer les tâches architecturales de base. Bien choisir quand utiliser la fonctionnalité standard et quand élaborer une fonctionnalité personnalisée n'est pas difficile d'un point de vue architectural. Les clés sont : - **Personnaliser la plate-forme signifie modifier et étendre, pas copier**. En concevant ou en évaluant votre architecture, vous devez demander : Existe-t-il déjà quelque part sur Salesforce Platform ? Si la réponse est « _Oui, mais... \[insérer les modifications souhaitées ici par une partie prenante...] »_, utilisez la fonctionnalité prédéfinie dans la plate-forme. Le travail architectural à réaliser consiste à identifier les méthodes les plus utiles pour configurer la fonctionnalité Salesforce prédéfinie afin de répondre aux attentes de l'entreprise. - **Aucune personnalisation n'est anodine**. Au fil du temps, chaque changement a des conséquences. Si vous devez implémenter une solution personnalisée, vous pouvez limiter l'inévitable [dette technique](/docs/architect/fr-fr/well-architected/guide/intentional#dette-technique) que votre système accumulera en choisissant d'utiliser une technologie à faible code dans la mesure du possible et en créant des [unités composables](/docs/architect/fr-fr/well-architected/guide/composable) dans vos implémentations. - **Considérez le spectre construction-achat**. [Salesforce AppExchange](https://appexchange.salesforce.com/) est une place de marché d'applications et de solutions pour étendre Salesforce. Les applications AppExchange peuvent offrir des fonctionnalités sans les frais généraux liés à l'élaboration et à la maintenance d'une solution personnalisée. Tenez compte des points suivants lors de l'évaluation des solutions AppExchange : - Identifiez les fonctionnalités et les lacunes de la solution. Idéalement, vous trouverez une application qui répond à toutes vos exigences métiers. En réalité, il se peut que vous ne trouviez pas un ajustement parfait. En évaluant les solutions, mappez les fonctionnalités de la solution potentielle avec une liste prioritaire d'exigences métiers. Cela vous aidera à trouver la solution qui répond le mieux à vos exigences les plus critiques. - Utilisez des sandbox et des évaluations gratuites. Utilisez des périodes d'évaluation gratuites pour évaluer les applications dans des environnements sandbox et identifier les plus adaptées. Déterminez si les applications nécessitent des modifications de configuration en conflit avec votre configuration existante. - Tenez compte des coûts à court et à long terme. Évaluez les économies à long terme réalisées en matière de maintenance des applications par rapport aux coûts récurrents des applications par abonnement. Évitez les scénarios dans lesquels vous devez payer des coûts récurrents pour de nombreuses fonctionnalités que vos parties prenantes n'utiliseront jamais. - **Utilisez les modèles de données prédéfinis de Salesforce.** Salesforce fournit des modèles de données prédéfinis pour Sales, Service et divers secteurs d'activité. L'utilisation des modèles de données fournis par Salesforce garantit que les capacités de votre système sont définies une seule fois (en éliminant la redondance et les silos), établit une source de preuve unique dans l'ensemble du système, facilite la compréhension des données d'application avec les analytiques, facilite l'utilisation des services d'intelligence artificielle prédéfinis de Salesforce, réduit les coûts de maintenance (en réduisant les personnalisations que vous devez prendre en charge) et réduit la dette technique. C'est aussi simple. Comme vous pouvez le voir dans les [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-maintenabilité-et-anti-modèles) ci-dessous, les anti-modèles se résument à répliquer des fonctionnalités standard dans une solution personnalisée ou à utiliser une technologie plus complexe pour offrir des personnalisations. Dans la pratique, vous pouvez rencontrer un scénario dans lequel une fonctionnalité personnalisée anti-modèle est considérée par les parties prenantes de l'entreprise comme la meilleure ou la seule voie viable à suivre. Dans ce cas, il est essentiel d'expliquer aux parties prenantes les compromis nécessaires pour choisir cette voie, puis de documenter en détail la décision, sa justification et sa mise en œuvre. Il s'agit également d'un domaine où la livraison anticipée de la valeur de base et l'adaptation au fil du temps peuvent aider vos parties prenantes à mieux comprendre la meilleure façon d'avancer. Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à améliorer la maintenance, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/intentional#outils-pertinents-pour-intentionnel) Intentionnel. ### Dette technique La dette technique est une partie naturelle de tout système. Les conceptions sonores d'hier peuvent devenir anti-modèles lorsque la technologie ou les besoins métiers évoluent. Peut-être qu'un élément conçu pour combler une lacune dans les fonctionnalités de Salesforce Platform devient soudain redondant avec une nouvelle version Salesforce ou un lancement de produit. Peut-être qu'une technologie plus performante ou plus flexible remplace une technologie que vous avez déjà implémentée. La dette technique peut être créée de nombreuses façons. L ' un des principaux avantages de l ' élaboration d ' applications avec Salesforce Customer 360 Platform est la [rétrocompatibilité intégrée à](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#api-de-plate-forme) la plate-forme. Cela signifie que les nouvelles innovations de plate-forme peuvent changer le modèle que vous devriez utiliser pour les solutions futures, mais la fonction quotidienne des solutions que vous avez élaborées à partir des technologies Salesforce précédentes continuera de fonctionner. Au fil du temps, toute solution basée sur une technologie plus ancienne commencera à présenter des risques ou des goulets d'étranglement pour l'ajout de nouvelles fonctionnalités à vos applications, et diminuera l'intégrité générale de la solution. La planification et la réalisation de travaux réguliers pour traiter les dettes techniques sont essentielles pour maintenir des conceptions saines et simples dans une solution Salesforce. Ne pas planifier, auditer et réparer une dette technique est un moyen sûr de créer un système mal conçu. Une façon de minimiser la dette technique est d'éviter de l'introduire autant que possible, en évitant les raccourcis et en préférant une [fonctionnalité standard à](/docs/architect/fr-fr/well-architected/guide/intentional#fonctionnalité-standard-par-rapport-à-la-fonctionnalité-personnalisée) une fonctionnalité personnalisée. Les raccourcis, comme les valeurs codées en dur, peuvent être tentants pour gagner du temps, mais à long terme, ils créent des dettes qui doivent être remboursées. Les clés pour traiter la dette technique d'un point de vue architectural comprennent: - Identification des [coûts ou avantages](/docs/architect/fr-fr/resources/guide/kpi-spreadsheet-template) réels de l'action par rapport à l'inaction - [Carte routière](/docs/architect/fr-fr/well-architected/guide/intentional#mappage-routier) appropriée - Élaboration de [solutions composables](/docs/architect/fr-fr/well-architected/guide/composable) La difficulté peut être d'amener les parties prenantes à agir. Certaines parties prenantes peuvent percevoir la maintenance continue comme une correction des « erreurs d'hier » ou comme une suppression des fonctionnalités qu'elles souhaitent que leur budget prenne en charge. Montrer les impacts métiers réels de l'action et de l'inaction, ainsi que des livrables et des échéanciers clairement définis, peut aider vos parties prenantes à comprendre la valeur et la priorité relative du traitement de la dette technique. Faire constamment le travail pour associer la dette technique aux impacts métiers n'aidera pas seulement vos parties prenantes à mieux comprendre le travail à réaliser. Il vous aidera également à identifier et à traiter les dettes techniques de manière à bénéficier réellement aux utilisateurs. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-maintenabilité-et-anti-modèles) ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion technique de la dette pour une organisation Salesforce. Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à gérer les dettes techniques, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/intentional#outils-pertinents-pour-intentionnel) Intentionnel. ### Modèles de maintenabilité et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles de maintenabilité dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/easy-maintainability) et anti-modèle.
Modèles Anti-Patterns
Standard vs. Personnalisé Dans vos normes de conception :
- Il existe un principe directeur clair pour empêcher les solutions de personnalisation inutile
- Le principe directeur des solutions utilise la priorité suivante: 1. Utiliser des services de plate-forme intégrés, 2. Tenez compte des applications AppExchange avant d'élaborer une solution personnalisée, 3. Utiliser des personnalisations à faible code avant d'écrire un code
Dans vos normes de conception :
- Les normes de conception n'existent pas ou n'ont pas de justification claire pour éviter les personnalisations et le code inutiles
Dans votre documentation :
- Les enregistrements de décision affichent le calcul des coûts à court et à long terme lors du choix d'élaborer ou d'acheter des solutions
Dans votre documentation :
- Les enregistrements de décision ne prennent pas en compte les coûts à court et à long terme lors du choix d'élaborer ou d'acheter des solutions
Dans des modèles de données :
- Aucun objet n'a de nom ou de fonctionnalité qui duplique des objets standard
- Les objets standard ne sont pas utilisés à des fins qui sortent de leur portée prévue
Dans des modèles de données :
- Les objets dupliquent les noms et/ou les fonctionnalités des objets standard
- Les objets standard sont utilisés à des fins qui dépassent largement leur portée prévue
Dans LWC, Aura ou Visualforce :
- Aucun code n'existe pour remplacer les mécanismes de vue de page standard
Dans LWC, Aura ou Visualforce :
- Un code existe pour remplacer les mécanismes de vue de page standard, souvent sous la forme d'une application à page unique
Dans LWC, Aura ou Apex :
- Aucun code ne tente de remplacer ou de contourner l'ordre d'exécution de la plate-forme
Dans LWC, Aura ou Apex :
- Le code tente de remplacer ou de contourner l'ordre d'exécution de la plate-forme
Dette technique Dans votre feuille de route :
- Des travaux de résolution de la dette technologique sont prévus
- Les livrables et les dates de début/fin sont clairs
Dans votre feuille de route :
- Aucun travail de résolution de la dette technologique n'est prévu
- Les livrables sont vagues; les dates de début/fin ne sont pas claires
Dans vos enregistrements de décision :
- Les indicateurs de performance clés pour l'assainissement de la dette avant ou après la technologie sont clairement documentés
- Les discussions de compromis pour l'action et l'inaction se concentrent sur les coûts ou les avantages de l'entreprise
Dans vos enregistrements de décision :
- L'assainissement de la dette technologique n'a aucun indicateur de performance clé mesurable
- La dette technologique est considérée en termes techniques ou informatiques, sans pertinence pour l'entreprise
Dans votre organisation :
- Aucune technologie non prise en charge ou héritée n'est active, notamment :
-- Tous les utilisateurs travaillent dans Lightning Experience
-- pas ou très peu d'utilisations de @future dans Apex (Queueable est utilisé)
-- Tous les Apex tiers appartiennent à des packages AppExchange
-- aucune règle de workflow active (flux utilisé)
-- aucun processus Générateur de processus actif (flux utilisé)
-- Événements PushTopic (capture des données modifiées utilisée)
-- Événements génériques (les événements de plate-forme sont utilisés)
-- versions d'API antérieures à 30.0
-- Les connexions d'organisation Salesforce utilisent l'adaptateur inter-organisations pour Salesforce Connect
Dans votre organisation :
- Une technologie non prise en charge ou héritée est active, notamment :
-- Utilisateurs travaillant dans Salesforce Classic
-- @future use in Apex
-- Apex tiers provenant de sources non AppExchange
-- Règles de workflow
-- Processus du Générateur de processus
-- Événements PushTopic
-- Événements génériques
-- versions d'API antérieures à 30.0
-- Connexions Salesforce à Salesforce
## Lisibilité À la base, le concept de _lisibilité_ consiste à créer une cohérence qui aide les gens à comprendre le fonctionnement. L'élaboration de systèmes lisibles aligne les équipes de livraison et de maintenance, et aide les personnes qui ne connaissent pas le système à comprendre rapidement comment les pièces s'agencent. Cela signifie que votre équipe peut être moins dépendante de personnes individuelles ayant des Knowledge institutionnelles ou historiques pour intégrer efficacement des fournisseurs ou de nouveaux membres d'équipe. Cela signifie que les personnes compétentes d'une équipe peuvent se concentrer sur la qualité et les compromis des choix faits, car la configuration et le code du système sont faciles à lire et à comprendre pour les humains. La lisibilité peut accélérer les processus de gouvernance et d'assurance qualité, et aider les équipes à mieux identifier quand elles créent des personnalisations redondantes. Il peut également augmenter les chances d'avoir un système qui se comporte de manière réutilisable et testable. Vous pouvez améliorer la lisibilité grâce à des normes de conception et une documentation efficaces. ### Normes de conception Les [normes de conception](/docs/architect/fr-fr/resources/guide/design-standards-template) fournissent des conseils pour maintenir toutes les personnalisations cohérentes, même aux premières étapes de développement. Les normes de conception agissent comme des garde-fous. Elles permettent à toutes les équipes de livraison et de maintenance qui travaillent sur votre système d'aborder et d'implémenter les personnalisations. La définition de normes de conception permet d'accroître la productivité de vos équipes de livraison et de maintenance, de faciliter la réalisation de révisions de code et d'architecture, et de fournir une base pour une meilleure [documentation](/docs/architect/fr-fr/well-architected/guide/intentional#documentation). Sans normes de conception, les équipes sont plus susceptibles de travailler en vase clos. Sans la cohérence qu'offrent les normes de conception, les entreprises se trouveront aux prises avec : - Les fournisseurs et les équipes de développement utilisent des modèles et des approches ad hoc dans les solutions, ce qui peut introduire des anti-modèles et réduire la réutilisation (voir [Séparation des préoccupations](/docs/architect/fr-fr/well-architected/guide/composable#séparation-des-préoccupations)). - Augmentation du temps nécessaire pour résoudre les problèmes de production, et soutenir les équipes requises pour intégrer les nouveaux membres de l'équipe et les aider à comprendre un ensemble différent de modèles et d'approches. - Mauvaise collaboration entre les équipes, redondances dans le travail entre les équipes, temps perdu dans la résolution des conflits et bogues découverts pendant les tests d'intégration. - Frustration accrue et taux de rotation plus élevés. Un avantage clé des normes de conception découle des conversations et des décisions que les parties prenantes doivent prendre pour les créer. Plus précisément, le processus donne à vos pistes commerciales et technologiques la possibilité de s'aligner sur la conception optimale pour votre entreprise. Insérez les éléments suivants dans vos [normes de conception](/docs/architect/fr-fr/resources/guide/design-standards-template) - **Conventions de nommage pour les métadonnées Salesforce**. Définissez une série de conventions pour nommer chaque personnalisation d'un système. Les bonnes conventions de nommage ne se contentent pas d'appliquer une cohérence entre les noms d'objets, de champs, de code, de flux et d'autres éléments de votre système. De bonnes conventions de nommage aident également les équipes de développement à utiliser des noms qui transmettent des informations sur l'objet et les fonctionnalités de ce qu'elles élaborent. Ainsi, les autres parties prenantes peuvent mieux comprendre une personnalisation particulière, simplement en voyant son nom. - Les **modèles de conception approuvés et leurs cas d'utilisation** Établissez une bibliothèque d'[Explorateur de schémas](/docs/architect/fr-fr/well-architected-tools/guide/patterns) et d'anti-modèles, avec des informations importantes sur l'utilisation (et non) de chaque schéma. La bibliothèque peut inclure des modèles de déclencheur Apex requis ou des modèles d'orchestration de flux basés sur la [composabilité](/docs/architect/fr-fr/well-architected/guide/composable) souhaitée dans votre système. - **Environnement de développement** et guide de l'outil. Tenez une liste claire des outils que les équipes de développement doivent utiliser pour leur travail. Cela peut inclure des chaînes d'outils et des langages approuvés pour toute personne écrivant un code, ou des fonctionnalités déclaratives approuvées (ou non) pour le développement à faible code. Vos normes peuvent inclure une liste de systèmes de contrôle de la source pour la personnalisation et la documentation, et les étapes requises d'entrée/sortie. Ils pourraient également inclure une liste d'environnements à utiliser pour différents types de travail de développement. En plus de définir ces normes, vous devez déterminer comment et où les gérer et les stocker. Si les équipes de votre entreprise ne trouvent pas vos normes de conception (ou ne savent même pas qu'elles existent), elles ne seront pas efficaces. Idéalement, vos normes de conception résident dans le même système que votre documentation (pour plus d'informations, consultez la section suivante). La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-lisibilité-et-anti-modèles) ci-dessous montre les normes de conception correctes (et médiocres) pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer vos normes de conception. Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à définir des normes de conception, consultez [Outils pertinents à](/docs/architect/fr-fr/well-architected/guide/intentional#outils-pertinents-pour-intentionnel) l'intentionnel. ### Documentation La documentation explique le quoi, comment et pourquoi de votre système. Sans documentation pertinente et cohérente, les équipes perdent beaucoup de temps à essayer de comprendre le système tel qu'il est (et les fonctionnalités et les personnalisations qui peuvent mal comprendre). La création d'une bonne documentation prend du temps. Bien que la plupart des équipes conviennent que la documentation est importante pour les grands projets, il peut être tentant d'ignorer une étape lors de modifications rapides telles que des mises à jour de configuration ou des ajustements mineurs d'une automatisation. Ne pas documenter les modifications que vous apportez à votre système est toujours anti-modèle. Ignorer la documentation peut faire gagner un peu de temps à l'avance, mais le temps nécessaire pour dépanner une organisation qui n'est pas correctement documentée va plus qu'annuler ce gain de temps. Insérez toujours suffisamment de temps pour créer de la documentation dans toutes vos estimations, quel que soit le niveau d'effort requis pour les mises à jour que vous envisagez d'effectuer. Le manque de documentation claire peut entraîner divers problèmes, notamment : - Cycles de développement consacrés au remaniement des implémentations existantes - Discussions répétitives revisitant ou laissant perplexe des décisions antérieures - Intégration plus longue pour les nouveaux membres d'équipe ou fournisseurs - Dépendance excessive à l'égard d'individus ayant des Knowledge institutionnelles ou historiques - Architectures redondantes pour prendre en charge des capacités identiques ou similaires dans l'ensemble de l'entreprise - Difficulté à communiquer l'objet et la valeur de votre solution aux principales parties prenantes Pour les solutions Salesforce, gérez la documentation relative aux éléments suivants : - **Vues d'ensemble** de la solution. Les [diagrammes](/docs/architect/fr-fr/reference-diagrams/guide/introduction) permettent à vous et à vos parties prenantes de visualiser les solutions à divers niveaux de détail. L'infrastructure de diagramme Salesforce facilite la création de diagrammes qui montrent les capacités métiers des solutions, ainsi que les détails d'implémentation technique. - **Enregistrements de décision**. Notez les options envisagées, les compromis, la décision finale et le raisonnement à un emplacement central auquel tous les membres de l'équipe peuvent accéder pour référence ultérieure. - **Code**. Le format du code lui-même est un élément clé de la documentation, qui peut (et doit) être conforme à vos [normes de conception](/docs/architect/fr-fr/well-architected/guide/intentional#normes-de-conception). Vous voudrez également avoir un journal des informations clés et le mettre à jour à chaque modification d'un élément de code. Pour toutes les classes, tous les déclencheurs et tous les composants, documentez les éléments suivants : - Qui est l'auteur du code - Quand le code a été écrit - Ce que le code est censé faire - Dépendances clés - Toutes les modifications - **Personnalisation déclarative**. Pour chaque type de personnalisation qui peut être apporté aux métadonnées de votre organisation, Salesforce fournit des [attributs intégrés](/docs/architect/fr-fr/fundamentals/guide/platform-multitenant-architecture#développement-dapplications-basées-sur-le-navigateur-sans-code-et-à-faible-code) permettant aux équipes de fournir des informations utiles sur l'objet et l'intention des métadonnées. Dans le cadre de vos normes de conception, indiquez comment les équipes doivent utiliser ces fonctionnalités intégrées et comment nommer les personnalisations déclaratives. Tenez également un journal des informations clés identiques à celui que vous utilisez pour le code. Élaborer un ensemble de normes de documentation pour s'assurer que tous les membres actuels et futurs de l'équipe seront en mesure d'interpréter les documents de la même façon (les [normes de conception](/docs/architect/fr-fr/resources/guide/design-standards-template) peuvent y contribuer). Il est également important de déterminer comment les utilisateurs peuvent rechercher dans la documentation des sections ou des termes pertinents. À mesure que votre système vieillit et gagne en complexité, votre documentation s'enrichira. L'utilité des informations contenues dans votre documentation dépendra directement de la fréquence, de la rapidité et de la facilité avec lesquelles les utilisateurs peuvent rechercher et trouver des éléments pertinents. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/intentional#modèles-de-lisibilité-et-anti-modèles) ci-dessous montre à quoi ressemble la documentation appropriée (et médiocre) pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer votre stratégie de documentation. Pour plus d'informations sur les outils de documentation Salesforce, consultez [Outils pertinents à](/docs/architect/fr-fr/well-architected/guide/intentional#outils-pertinents-pour-intentionnel) Intentionnel. ### Modèles de lisibilité et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier. ✨ Découvrez d'autres modèles de lisibilité dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/easy-readability) et anti-modèle.
Modèles Anti-Patterns
Normes de conception Dans votre organisation :
- Les personnalisations de code et déclaratives ont des noms cohérents et lisibles par l'utilisateur
- Les modèles de données ont des noms cohérents et uniformes pour les objets et les champs
- Les audits montrent que les champs sont systématiquement remplis et référencés dans les rapports, etc.
Dans votre organisation :
- Les personnalisations de code et déclaratives n'ont pas de noms cohérents
- Les modèles de données ont des noms incohérents et de nombreux objets et champs semblent redondants
- Les audits montrent de nombreux champs inutilisés ou divers niveaux d'utilisation, et il n'y a pas de lien cohérent avec les rapports, etc.
Au sein de votre entreprise :
- Les équipes savent quels outils utiliser (et ne pas utiliser) pour réaliser le travail
- Les modèles de conception approuvés sont faciles à trouver et à identifier par cas d'utilisation
- Les modèles IA approuvés sont clairement identifiés et incluent une finalité
Au sein de votre entreprise :
- Les équipes utilisent de nombreux outils différents pour réaliser un travail similaire
- Il n'y a pas de modèles de conception approuvés
- Il faut beaucoup de temps aux fournisseurs ou aux nouveaux employés pour intégrer
- Les modèles IA approuvés ne sont pas clairement identifiés et leur objet n'est pas clair
Documentation Dans votre organisation :
- Les personnalisations de code et déclaratives ont des descriptions claires
Dans votre organisation :
- Les personnalisations de code et déclaratives n'ont pas de description, ont des descriptions difficiles à comprendre ou ont des descriptions qui ne semblent pas correspondre à ce que la personnalisation fait réellement
Au sein de votre entreprise :
- Des diagrammes des capacités métiers et des détails d'implémentation technique existent pour toutes les solutions
- Clé qui/quand/quels journaux d'information existent pour les personnalisations de code et déclaratives
- Les gens peuvent rechercher et trouver la documentation pertinente
Au sein de votre entreprise :
- Le quoi/comment/pourquoi des solutions est difficile à trouver et peut ne pas être disponible pour la plupart des équipes
- Les gens peinent à comprendre les solutions et le système avec lequel ils travaillent
- Il faut beaucoup de temps aux fournisseurs ou aux nouveaux employés pour intégrer
## Outils pertinents pour Intentionnel
OutilDescriptionStratégieMaintenabilitéLisibilité
ApexDocDocument Apex avec des pages HTML statiquesXX
Supprimer en masse les valeurs de liste de sélection inactivesSupprimer les valeurs inactives inutilisées des listes de sélectionX
Validateur Lightning Design SystemValider le balisage et voir comment améliorer votre codeXX
Migrer vers fluxConversion des règles de workflow et des processus du Générateur de processus en fluxX
Outil de gestion de projet par Salesforce LabsGérer les projets dans votre organisation SalesforceXX
Extensions Salesforce pour Visual Studio Code (Agrandi)Analyse efficace du code Salesforce avec les extensions de code Visual StudioXX
Vérification de l'organisationAnalyse rapide de votre organisation et de sa dette techniqueX
Salesforce Code AnalyzerScannez le code via IDE, CLI ou CI/CD pour vous assurer qu'il respecte les meilleures pratiquesXX
Explorateur de feuille de route SalesforceExploration des innovations produits SalesforceX
Piste d'audit de configurationSuivre les modifications de configuration et l'historique d'auditXX
## Ressources pertinentes pour Intentionnel
RessourceDescriptionStratégieMaintenabilitéLisibilité
5 stratégies de documentation pour améliorer votre organisation SalesforceAmélioration de la documentation d'implémentation de SalesforceX
Choisir des conventions de nommage (Trailhead)Apprenez à appliquer des conventions de nommageX
Définition, identification et mesure de la dette techniqueDéfinir, identifier et mesurer la dette techniqueXX
Modèle Design StandardsCréer des normes de conception pour votre organisationXXX
Premiers pas avec les diagrammes SalesforceApprenez à créer le diagramme adapté à votre cas d'utilisationX
Premiers pas avec les conventions de codage (Trailhead)Définir et suivre des conventions de codageX
Comment lutter contre la dette technique (Trailhead)Gérer la dette technique dans votre organisation SalesforceXX
Améliorez votre code Apex (Trailhead)Appliquer les principes de base du développement piloté par les essaisX
Organizational Alignement (Trailhead)Découvrez le processus V2MOM pour l'alignementX
Priorité et planification d'une sortie de la dette techniqueFormer un plan de réduction et de suppression de la dette techniqueXX
Modèle Conventions de nommage SalesforcePremiers pas avec les conventions de nommageXX
Dette technique : Qu'est-ce que c'est et pourquoi devriez-vous vous soucier? Comprendre l'impact de la dette technique dans votre organisationX
Utilisation de la zone de dessin Business Model dans l'architecture d'entrepriseCréer, livrer et afficher de la valeur dans un modèle commercialX
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Les solutions résilientes maintiennent une qualité de service élevée même en cas de défaillance. Si les performances se dégradent ou si le service est interrompu, la solution se rétablit rapidement et efficacement. La résilience d’une solution repose sur deux qualités clés : - **Dureté**: Lorsque des problèmes surviennent, la solution les supporte et les endure. - **Élasticité**: Une fois les problèmes résolus, la solution retrouve son état ou sa forme idéal. Pour concevoir votre solution de résilience, vous devez concevoir à la fois pour la ténacité et l'élasticité, en assurant à la fois la durabilité et la récupération rapide face aux changements planifiés et imprévus. Dans un contexte technologique, considérez un système ou une solution comme un ensemble de composants interdépendants qui se coordonnent pour atteindre des objectifs communs. Chaque composant peut échouer. Les problèmes au sein de ces composants, depuis les défauts de code et de configuration jusqu'aux problèmes réseau et matériel, peuvent entraîner un comportement inattendu et indésirable. Un système montre un comportement résilient lorsqu'un ou plusieurs composants tombent en panne, mais le système global continue de fonctionner ou revient rapidement à un état stable. Pour améliorer la résilience de vos solutions Salesforce, nous recommandons de vous concentrer sur trois habitudes clés. - [**Gestion du cycle**](/docs/architect/fr-fr/well-architected/guide/resilient#gestion-du-cycle-de-vie-des-applications) de vie des applications : comment les équipes gèrent les logiciels tout au long de leur cycle de vie, depuis l'idée jusqu'au retrait - [**Réaction aux incidents**](/docs/architect/fr-fr/well-architected/guide/resilient#réponse-à-lincident) : comment les équipes identifient, résolvent et préviennent les problèmes qui affectent la disponibilité ou la sécurité d'un système - [**Planification de continuité**](/docs/architect/fr-fr/well-architected/guide/resilient#planification-de-la-continuité) : comment les équipes planifient le fonctionnement de leurs équipes et de leurs systèmes lorsque des événements imprévus entraînent des problèmes ## Gestion du cycle de vie des applications La gestion du cycle de vie des applications (ALM) est une pratique qui permet de gérer de façon globale un logiciel tout au long de son cycle de vie, depuis sa création jusqu'à son retrait. L'ALM est une pierre angulaire de la résilience du système et englobe les personnes, les processus, les outils et les disciplines associés au cycle de vie des applications. Ces disciplines comprennent les DevOps et les méthodologies de livraison, l'observabilité, les stratégies de test, la gouvernance et l'IC/CD. Lorsqu'une entreprise pratique une ALM efficace, ses équipes réagissent rapidement aux changements, et ses applications suivent l'évolution des exigences métiers sans compromettre la stabilité ou la qualité. D'autre part, sans ALM saine, les équipes rencontrent des difficultés à chaque étape du cycle de vie de l'application. Les symptômes d'une mauvaise ALM comprennent : - Cycles de développement lents et sujets aux erreurs - Déploiements intensifs et difficiles - Problèmes ou bogues de grande gravité découverts dans des environnements de production et de post-AQ - Agents IA qui hallucinent ou dont le comportement est incohérent - Annulations fréquentes ou déploiements correctifs requis pour stabiliser les versions L'ALM touche presque tous les aspects d'une solution. Par conséquent, l'établissement de pratiques d'ALM claires et efficaces pour votre solution est un élément clé de votre travail architectural. Élaborez de meilleures pratiques de GTA en vous concentrant sur trois domaines clés. - [**Gestion des versions**](/docs/architect/fr-fr/well-architected/guide/resilient#gestion-des-versions) : la planification, le séquencement, le contrôle et la migration des modifications vers différents environnements - [**Stratégie environnementale**](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-environnementale) : une stratégie d'utilisation et de gestion d'applications dans des environnements cibles pendant le développement et les tests - [**Stratégie de signalisation**](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-de-signalisation) : définition des signaux critiques et instrumentation d'application utilisés pour détecter et corriger les défaillances dans le système avant la dégradation - [**Stratégie de test**](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-de-test) : les principes et les normes qui guident la planification et l'exécution de tests pour évaluer la réussite de vos applications pendant les processus ALM ### Gestion des versions La gestion des versions consiste à planifier, séquencer, contrôler et migrer les modifications vers un ou plusieurs environnements. Une version unique est un groupe de modifications planifiées qu'une équipe déplace en même temps vers un environnement cible. La publication d'une modification dans un système entraîne un risque. Si le système est dans un état stable avant la modification, il passe à un nouvel état, où il est également plus vulnérable aux risques liés aux modifications futures. Si de futures modifications déclenchent un état incontrôlé et instable dans le système, elles peuvent entraîner un incident critique. Dans une architecture de solution, concevoir des versions résilientes ne se limite pas à [tester efficacement les modifications](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-de-test) apportées. Cela implique également de planifier comment introduire des modifications dans vos systèmes et leurs utilisateurs en toute sécurité. Le travail de vos équipes dépend d'informations de publication prévisibles et précises. Dans vos processus de gestion des modifications et d'activation, déterminez clairement quelles modifications peuvent être intégrées à votre système. Dans vos processus de gestion des versions et d'activation, spécifiez comment et à quelle fréquence les modifications sont publiées dans votre système. Vos parties prenantes s'intéressent également aux informations sur les versions, en particulier si elles sont liées aux fonctionnalités ou aux correctifs de bogues qu'elles demandent. Pour gagner Trust en votre solution et démontrer de la valeur à vos parties prenantes, établissez des calendriers de publication cohérents et clairs et expédiez des artefacts de publication stables. Pour établir une gestion efficace des versions pour Salesforce : - **En étroite adéquation avec la gouvernance** architecturale et de développement. Assurez-vous que les versions sont planifiées longtemps à l'avance pour s'aligner sur tous les forums et contrôles de gouvernance pertinents. Avant de vous lancer dans le développement, faites examiner et approuver par le Conseil de l'IA tous les cas d'utilisation Agentforce prioritaires. Obtenez des cas d'utilisation Agentforce à haut risque examinés par les équipes Legal and Ethical Use.Utilisez des listes de contrôle de déploiement et de la documentation pour suivre les artefacts de déploiement, tels que les noms d'API d'agent Agentforce, par rapport aux activités de gouvernance. - **N'utilisez pas de [processus de développement](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)** basé sur l'organisation ou de publication. Ce paradigme reflète des technologies plus anciennes et plus limitées pour le développement et la publication. Avec la Salesforce CLI, les équipes peuvent désormais adopter des capacités de développement et de publication pilotées par la source. - **Choisissez le mécanisme de libération le plus stable possible**. Cette approche accomplit deux choses. Premièrement, il réduit la durée des fenêtres de publication et des interruptions de service. Deuxièmement, il permet des comportements de libération hautement contrôlés et prévisibles. Plus votre mécanisme de publication est stable, moins les versions risquent d'introduire des modifications qui nécessitent des correctifs ou des annulations. En cas de problème imprévu, des mécanismes de publication stables simplifient également la tâche du personnel de support ou des administrateurs système. Les meilleurs mécanismes de publication pour votre équipe sont les options les plus stables pour lesquelles votre équipe possède les compétences requises. Ce sont les mécanismes de libération recommandés, répertoriés par ordre de stabilité. Tous sont compatibles les uns avec les autres. Par conséquent, utilisez-en plusieurs en même temps si cela convient à votre entreprise. - [**Packages déverrouillés**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm) : les packages déverrouillés sont l'artefact de version le plus stable. Le déploiement de modifications en installant un package est le moyen le plus rapide et le plus prévisible d'introduire des modifications. Les packages utilisent la gestion des versions, qui permet une gestion robuste des modifications et des restaurations précises et conviviales pour l'administrateur système. Les packages nécessitent une solide gestion des métadonnées, qui peut vous aider à identifier rapidement les dépendances mal gérées. Ils créent également des pipelines et des artefacts de développement auditables. Consultez [Empaquetage](/docs/architect/fr-fr/well-architected/guide/composable#emballage). - [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5) – DevOps Center permet aux équipes d’exécution qui ont des ensembles de compétences à faible code ou pro-code d’utiliser le contrôle de la source, de travailler en collaboration sur les modifications et de définir des parcours de publication communs. DevOps Center s'intègre au contrôle des sources et permet de contrôler par pointer-cliquer les modifications et les déploiements. - **Développement piloté par la source et déploiement de métadonnées en utilisant la [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli)** : si vous ne pouvez pas utiliser de packages, utilisez la Salesforce CLI pour votre développement piloté par la source et déploiement de métadonnées. Ne déployez pas de métadonnées en utilisant l'ancien format package.xml, qui suit une structure différente de celle du [format source](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm) recommandé. Le format source a évolué pour prendre en charge le développement de packages, les workflows d'organisation test et un suivi des modifications plus précis dans les organisations sandbox. Le format est plus lisible, permet de découpler davantage les types de métadonnées complexes et les dépendances, et vous donne beaucoup plus de contrôle sur les manifestes de déploiement. - **Nommez vos versions**. Donnez à vos versions des identifiants clairs pour aider vos équipes et vos parties prenantes à rester alignées. Dans Salesforce, le nom de chaque version majeure commence par « Spring », « Summer » ou « Winter », suivi de l'année de la version (par exemple, « Summer ’25 »). Si vous n'avez pas encore de convention de nommage pour définir et organiser les versions dans votre entreprise, établissez-en une et utilisez-la. L'utilisation de noms de version clairs facilite l'organisation à chaque étape de la planification, du développement et de la livraison, dans tous les systèmes de vos équipes. Utilisez vos noms de version dans votre [feuille de route](/docs/architect/fr-fr/well-architected/guide/intentional#mappage-routier) pour communiquer clairement à vos parties prenantes les changements à venir et quand. Utilisez vos noms de version dans votre documentation, vos journaux de modification, vos descriptions de travail, vos commentaires de code et vos branches de contrôle de code source afin de faciliter le suivi et l'audit de vos artefacts de développement. - **Dans un Manifeste de version, gérez correctement les dépendances**. Les métadonnées Salesforce ont des dépendances intégrées. L'échec des déploiements Salesforce est souvent dû au fait que les dépendances ne sont pas correctement gérées. Le choix d'un mécanisme de publication stable, tel que décrit précédemment, peut vous aider à révéler les dépendances mal gérées plus tôt dans votre cycle de développement. L'une des principales raisons pour lesquelles les packages déverrouillés sont le vecteur de publication le plus stable est leur solide gestion des métadonnées, qui est requise pour le développement et la création de packages. Si vous ou vos équipes de gestion des versions ne comprenez pas les dépendances intégrées entre les types de métadonnées Salesforce, vous ne pourrez pas détecter proactivement les combinaisons problématiques dans vos manifestes de déploiement et de publication. Consultez [Gestion des dépendances](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-dépendances). Les [modèles et anti-modèles pour ALM](/docs/architect/fr-fr/well-architected/guide/resilient#modèles-alm-et-anti-modèles) montrent à quoi ressemble une gestion des versions correcte et médiocre pour une organisation Salesforce. Utilisez les modèles pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés. Pour plus d'informations sur les outils Salesforce pour la gestion des versions, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Stratégie environnementale Salesforce fournit divers [environnements](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5) que vous pouvez utiliser pendant les cycles de développement et de test d'applications. Une stratégie d'environnement efficace pour Salesforce nécessite de comprendre comment utiliser les environnements et à quoi ressemble une bonne gestion. En ALM, l'utilité d'un environnement de développement ou de test dépend de sa fidélité et de son isolement par rapport à la production. Une bonne stratégie environnementale offre plusieurs avantages. - Une plus grande fidélité à la production - Accélération de la configuration et de la destruction des environnements - Plus agile dans le développement et les tests - Sécurité accrue dans tout votre pipeline - Réduction du bruit et des conflits à travers les étapes de livraison - Équipes de développement plus heureuses Les équipes peinent souvent à tirer parti de ces avantages. Les défis pour tirer le meilleur parti de vos environnements de développement et de votre stratégie peuvent provenir de plusieurs sources. Une source probable est le type de modèle de développement que vos équipes suivent. Dans l'ancienne approche de développement basée sur l'organisation, chaque environnement devait remplir plusieurs fonctions. En plus d'être l'endroit où votre équipe effectue ses différents types de travail, elle devait être la source de vos artefacts de version (c'est-à-dire les métadonnées que vous souhaitiez déployer dans une version). Les environnements n'étaient pas faciles à configurer ou à démanteler. Par conséquent, ils étaient souvent surpeuplés et remplis de conflits de métadonnées entre les équipes, et ils ne contribuaient pas à une vitesse ou à une flexibilité significatives de l'ALM dans son ensemble. L'utilisation d'un modèle de développement basé sur la source modifie fondamentalement la relation des environnements avec vos versions et artefacts de version. Dans ce modèle, le contrôle de la source est la source des métadonnées que vous souhaitez publier. Les environnements ne sont que des lieux où vos équipes travaillent. Cependant, suivre le modèle de développement basé sur la source ne garantit pas à lui seul une bonne stratégie environnementale. Même avec le contrôle du code source, les équipes peuvent avoir du mal à configurer des conditions pour tester des intégrations à des systèmes externes, des configurations qui dépendent de métadonnées qui ne sont pas dans le contrôle du code source, par exemple des packages gérés ou des personnalisations qui dépendent de [données](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#métadonnées-par-rapport-aux-données)), etc. Dans certaines circonstances, les défis d'un modèle basé sur la source sont similaires aux défis typiques d'un modèle basé sur l'organisation. Pour élaborer une stratégie environnementale efficace : - **Adoptez un modèle de développement et de version** piloté par la source. Arrêtez d'utiliser des modèles de [développement basés sur](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models) l'organisation. Consultez [Gestion des versions](/docs/architect/fr-fr/well-architected/guide/resilient#gestion-des-versions).) Vous devez dissocier vos environnements de ce que vous déployez pour créer une stratégie environnementale saine et des versions plus saines. - **Comprenez les types de travail que chaque environnement prend** en charge. Les types d'environnement pris en charge par Salesforce ont des capacités et des limites différentes. En concevant votre stratégie environnementale, tenez compte des actions que les environnements peuvent et ne peuvent pas exécuter. Assurez-vous que vos équipes travaillent dans un environnement doté des capacités dont elles ont besoin. Pour plus d'informations, consultez cette présentation des environnements de développement Salesforce et de leurs fonctionnalités.
Organisation test Developer Sandbox Sandbox Developer Pro Sandbox Partial Copy Sandbox Full
Prend en charge la forme organisationnelle Oui Non Non Non Non
Prend en charge le suivi source Oui Oui Oui Non Non
Durée de vie 1 à 30 jours Contrôlé manuellement Contrôlé manuellement Contrôlé manuellement Contrôlé manuellement
Intervalle d'actualisation Non disponible 1 jour 1 jour 5 jours 29 jours
Prise en charge de l'aperçu de la version Développeur contrôlé Basé sur une instance sandbox Basé sur une instance sandbox Basé sur une instance sandbox Basé sur une instance sandbox
Temps de provisionnement > 5 minutes Heures ou jours Heures ou jours Heures ou jours Heures ou jours
Métadonnées déterminées par Contrôle de la source Production Production Production Production
Données déterminées par Chargement manuel des données Chargement manuel des données Chargement manuel des données Modèle sandbox Production
Limite en données 200 MO 200 MO 1 GB 5 GO Identique à la production
Consultez ce tableau pour découvrir les fonctionnalités et les environnements à utiliser pour plusieurs tâches de développement courantes.
Tâche Forme de l'organisation Suivi de la source Actualisations fréquentes Prise en charge de l'aperçu de la version Toutes les métadonnées de production Métadonnées partielles de production Jeux de données volumineux de production Jeux de données partiels de production Environnements compatibles
Prototypage X X X X X X X Organisations tests, organisations sandbox Developer et Developer Pro
Enquêtes sur les nouvelles fonctionnalités ou développement de preuves de concept X X X X X X X Organisations tests, organisations sandbox Developer et Developer Pro
Test d'acceptation utilisateur X X X X X X sandbox Developer, Developer Pro et Partial Copy
Essais de performance et d'échelle X X X Sandbox Full
Formation utilisateur X X X X X* X Developer Pro, Partial Copy et * sandbox Full
*Si nécessaire pour réaliser un type de travail spécifique, sinon utilisez un environnement moins gourmand en ressources
Par ailleurs, notez que pour les agents Agentforce qui utilisent des fonctionnalités telles que la Bibliothèque de données Einstein, des articles Knowledge et des données non structurées, les tests complets sont limités, sauf si vous avez une sandbox Data 360. Une organisation sandbox Data 360 est également requise pour garantir des conditions de test précises. - **Découplez les environnements des artefacts de publication.** N'utilisez pas le [développement basé sur](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models) l'organisation. Traitez les environnements comme des lieux où le travail dure une période déterminée. Considérez l'état des métadonnées dans un environnement comme séparé de vos artefacts de publication. Si un élément de code ou de configuration est « compris » dans un environnement, il doit être engagé dans le contrôle de la source, ce qui en fait un artefact de version. - Les environnements sont éphémères. Élaborez des processus pour pouvoir les créer et les détruire le plus rapidement possible. - Les artefacts perdurent. Ils appartiennent au contrôle source. - **Découplez les environnements des parcours de publication**. Il est courant d'afficher des parcours de publication obligatoires qui nécessitent le déploiement de modifications dans des environnements spécifiques. Souvent, cette approche est implémentée afin d'établir un proxy pour valider la maturité de l'application ou la stabilité de la version. Les équipes peuvent également l'utiliser pour tenter de limiter le nombre d'environnements dans lesquels elles doivent configurer une infrastructure de test complexe. Dans les paradigmes basés sur la source, vous disposez d'une plus grande flexibilité dans la façon et l'emplacement de validation et de test des modifications. - Les étapes de publication s'appliquent aux artefacts de publication, pas aux environnements. Ne créez pas un environnement uniquement dans le but de « recueillir » toutes les modifications à une étape de publication particulière. Le contrôle de la source, en particulier la branchement, sert à cela. Utilisez des stratégies de branchement dans le contrôle du code source pour organiser les modifications à déployer dans quels environnements. Selon le travail que vous devez effectuer, il peut être nécessaire de déployer toutes les métadonnées d'une version dans un environnement. La branchement permet de le faire. À quelques exceptions près, chaque environnement de développement doit être actualisé ou détruit dès que les travaux pertinents sont terminés. Assurez-vous de synchroniser toutes les modifications apportées aux métadonnées effectuées dans un environnement spécifique (et que vous souhaitez conserver) vers le contrôle source. - Les environnements ne sont aussi utiles que leur fidélité à la production. Optimisez les workflows de configuration ou l'automatisation de votre environnement afin de démanteler ou d'actualiser les environnements le plus rapidement possible. Considérez toute configuration qui vous empêche d'effectuer des actualisations d'environnement plus rapides et plus fréquentes comme un risque critique pour la résilience globale de vos processus ALM. Si vous avez des travaux d'assainissement connexes, ajoutez-les à vos plans et priorisez-les. Explorez comment adopter des [unités modulaires](/docs/architect/fr-fr/well-architected/guide/composable) à couplage plus souple dans votre système. Ils permettent aux équipes d'effectuer plus de types de développement dans des organisations tests et libèrent des allocations sandbox pour d'autres tâches. N'oubliez pas les capacités que les organisations tests offrent pour tester des fonctionnalités que vous n'avez pas en production, soit parce que vous n'avez pas acheté de licences pour elles, soit parce que vous ne les avez pas activées. - Dans les environnements auxquels les utilisateurs professionnels ou les utilisateurs peuvent accéder, laissez ces utilisateurs se concentrer sur ce qui les intéresse. Ne pas avoir d'environnements génériques et indifférenciés dans lesquels de nombreux groupes d'utilisateurs finaux ou parties prenantes tentent d'effectuer un travail lié à la gestion des relations commerciales commerciales. Invitez et activez des parties prenantes spécifiques dans des environnements spécifiques pour effectuer un travail spécifique. Évaluez attentivement tout processus qui place les utilisateurs ou les parties prenantes dans un environnement contenant plus de données qu'une sandbox Partial Copy ne peut prendre en charge. Assurez-vous que le volume de données est nécessaire au travail à réaliser. Planifiez vos cycles de test d'acceptation des utilisateurs et de développement en phase initiale de manière à ce qu'ils se déroulent le plus étroitement possible. Optimisez toutes les étapes de test afin d'activer des cycles de commentaires et d'itération plus rapides et plus précoces pour vos équipes de développement et vos utilisateurs. Consultez [Stratégie de test](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-de-test). - **Élaborez différents parcours de publication pour différents types de modification**. Les modifications n'exigent pas toutes que les mêmes types de travail ALM soient effectués dans le même ordre. Demander aux utilisateurs d'effectuer des tests d'acceptation des modifications mineures apportées aux composants back-end d'un système n'est probablement pas une bonne utilisation de leur temps. Cependant, l'acceptation des utilisateurs et les tests à l'échelle peuvent s'avérer extrêmement utiles pendant les premières étapes du développement d'une application mobile. Identifiez les parcours de publication pour différentes catégories de changement, par exemple risque élevé, risque moyen et risque faible. - **Risque élevé :** Les modifications impactent les clients, les partenaires ou tous les utilisateurs internes. Les modifications impactent la sécurité ou l'intégration. Les modifications ajoutent de nouvelles fonctionnalités complexes. - **Risque moyen :** Les modifications impactent plus d'un seuil défini d'utilisateurs internes. Les modifications impactent les modèles de données, l'automatisation qui effectue des opérations sur les données ou l'intégration. - **Risque faible :** impacte directement un nombre d'utilisateurs internes inférieur à un seuil défini. N'inclut pas les modifications apportées à la sécurité, aux modèles de données ou aux automatisations impliquant des opérations sur les données ou l'intégration. - **N'autorisez pas l'existence** d'environnements surpeuplés. Un manque de discipline dans la définition des priorités, la portée et l'ordonnancement des travaux entraîne inévitablement une surcharge de travail dans les environnements de développement, avec des volumes de travail trop importants, trop nombreux et trop différents. Les environnements surpeuplés créent des niveaux élevés de stress, d'ambiguïté et de conflits entre les équipes de développement. Ils créent également du bruit dans les pipelines de développement et entravent les efforts de contrôle de la qualité. Outre ces effets négatifs, les environnements de développement surpeuplés constituent de graves menaces pour le maintien et la sécurité de l'environnement. Considérez la surpopulation comme un symptôme de problèmes potentiels dans vos processus ALM. Déterminez les causes profondes des problèmes et corrigez-les. Si vous rencontrez encore une surpopulation, vous pouvez [acheter des sandbox](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5) supplémentaires. La liste des [modèles et anti-modèles pour ALM](/docs/architect/fr-fr/well-architected/guide/resilient#modèles-alm-et-anti-modèles) montre à quoi ressemble une bonne et une mauvaise gestion de l'environnement dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce pour la gestion de l'environnement, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Stratégie de signalisation Une stratégie de signalisation définit les signaux critiques et l'instrumentation d'application nécessaires pour détecter, diagnostiquer et corriger les pannes avant qu'elles ne se dégradent en cascade à l'échelle du système. Une instrumentation efficace transforme les applications de victimes passives d'échecs en participants actifs à leur propre résilience, capables de détecter les problèmes, d'adapter leur comportement et de coordonner une dégradation gracieuse lorsque nécessaire. Lorsque les applications mettent en œuvre une instrumentation complète, elles acquièrent la capacité de s'autoréguler en cas de stress, de communiquer leur état de santé aux opérateurs et de participer aux efforts coordonnés de rétablissement. Ces capacités permettent aux systèmes de maintenir la qualité du service même lorsque des composants individuels sont en détresse. D'autre part, sans instrumentation appropriée, les applications deviennent des boîtes noires qui échouent silencieusement jusqu'à l'apparition de symptômes catastrophiques. Les équipes réagissent aux problèmes uniquement lorsque les utilisateurs les signalent, et le dépannage devient un exercice d'archéologie plutôt que d'observation. - **Détecter les échecs dans l'application** Les applications doivent s'instrumenter pour détecter et répondre aux modèles de défaillance courants qui émergent sous une forte charge. Tenez compte de la saturation de la file d'attente. Lorsque les files d'attente de messages se remplissent plus rapidement qu'elles ne peuvent être traitées, les applications non instrumentées continuent d'accepter du travail jusqu'à ce que l'épuisement de la mémoire ou des cascades d'expiration se produisent. Des applications correctement instrumentées surveillent la profondeur de la file d'attente, les taux de rejet et la latence de traitement, déclenchant des réponses défensives lorsque les seuils sont dépassés. - **Gérer efficacement les signaux extérieurs à l'application**: Le traitement des signaux du système d'exploitation représente un autre point d'instrumentation critique. Les applications doivent enregistrer les gestionnaires de signaux de terminaison (SIGTERM, SIGINT) pour permettre un arrêt gracieux. Pendant l'arrêt, les applications correctement instrumentées arrêtent d'accepter de nouveaux travaux, autorisent les requêtes en vol à se terminer, vident les tampons, ferment les connexions proprement et désinscrivent de la découverte du service. Cet arrêt orchestré évite la perte de données et permet aux répartiteurs de charge de rediriger le trafic sans interruption. - **Instrument pour scénarios de défaillance complexes :** Au-delà de ces schémas de base, les applications doivent s'instrumenter pour des modes d'échec plus subtils. L'identification des défaillances grises, dans lesquelles les composants semblent sains pour certains observateurs alors qu'ils échouent pour d'autres, nécessite de corréler les signaux internes et externes. Une application peut utiliser son pool de connexions à la base de données pour signaler les contrôles d'intégrité réussis tout en suivant simultanément les taux de réalisation des transactions qui révèlent une dégradation rampante. Des stratégies d'instrumentation efficaces superposent plusieurs points d'observation. - Les **métriques métiers** suivent des indicateurs de réussite spécifiques à l'application, tels que les taux de réalisation de commandes ou la qualité des résultats de recherche. - Les **métriques système** surveillent l'utilisation des ressources, les distributions de latence et les taux d'erreur. - **Les sondes synthétiques** suivent en permanence des parcours critiques pour détecter la dégradation avant que les utilisateurs ne la rencontrent. - **Le traçage distribué** permet de visualiser les demandes à travers les frontières du service. Ces signaux sont exposés via des interfaces standardisées qui permettent aux systèmes automatisés et aux opérateurs humains d'évaluer l'intégrité de l'application. L'instrumentation elle-même fait partie de la stratégie de résilience de l'application, permettant aux disjoncteurs de déclencher en fonction des taux d'erreur, aux autotartres de répondre aux profondeurs de file d'attente et aux [opérateurs de prendre des décisions informées en cas d'incident](/docs/architect/fr-fr/well-architected/guide/resilient#réponse-à-lincident). Les [modèles et anti-modèles ALM](/docs/architect/fr-fr/well-architected/guide/resilient#modèles-alm-et-anti-modèles) montrent à quoi ressemble une stratégie de signalisation correcte et médiocre dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce pour une stratégie de signalisation, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Stratégie de test Une stratégie de test est un ensemble de principes directeurs et de normes pour planifier et exécuter des tests qui évaluent la réussite et l'échec des applications pendant les processus ALM. Une stratégie de test tient chaque partie prenante impliquée dans les tests informée de la priorité, du but et de la portée d'un test donné. Il aide également les équipes de projet à créer des plans de test efficaces et réfléchis. Généralement, les développeurs ou les experts en assurance qualité et en tests sont impliqués dans la création et l'exécution de tests spécifiques. Une stratégie de test permet de s'assurer que ces personnes savent quels types de test doivent être effectués pour un projet donné et dans quelle séquence les effectuer. Une stratégie de test permet également de s'assurer que les équipes disposent des éléments nécessaires pour élaborer des tests, des plans de test et des artefacts bien formés (par exemple, des jeux de données, des appareils et des simulateurs de trafic ou de réseau). Une stratégie de test efficace permet de déterminer clairement comment, quand, où et pourquoi exécuter différents types de test (y compris des tests unitaires, des tests d'interface utilisateur et des tests de régression) dans diverses combinaisons et conditions afin de déterminer le comportement de votre système et de toute modification en vol. Une stratégie de test efficace produit des tests qui montrent la conformité d'un système à des exigences non fonctionnelles, telles que l'évolutivité, la fiabilité et la convivialité, qui peuvent être difficiles à mesurer avec un seul type de test. Pour créer des stratégies de test efficaces pour Salesforce : - **Testez de façon itérative, fréquente et automatisée autant que possible**. Concevez et implémentez une automatisation des tests qui permet aux équipes d'exécuter divers types de test sur diverses charges de travail. Orchestraz automatiquement diverses exécutions de test lorsque des modifications entrent dans le contrôle de la source. Cette approche permet aux équipes d'identifier proactivement et de traiter les régressions à un stade précoce. Utilisez l'intégration continue/livraison continue (CI/CD) pour cet effort si possible. Sinon, établissez des plans de test clairs qui permettent aux équipes d'exécuter des séquences de tests tôt et souvent, en libre-service. Pour les agents Agentforce testant, s'appuyer sur le Centre de test pour effectuer des tests rigoureux par lot sur les agents IA avec diverses entrées afin de s'assurer qu'ils fonctionnent correctement dans différents scénarios. - **Reconnaissez que chaque modification ne nécessite pas tous les types de test**. De la même façon qu'un pipeline de versions efficace prend en charge les parcours pour les applications à risque élevé, moyen et faible, une stratégie de test efficace est également disponible. Indiquez clairement aux équipes comment sélectionner et suivre un régime de test approprié pour des applications présentant divers types de risque, de cas d'utilisation ou de complexité. Voir [Stratégie environnementale](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-environnementale). - **Déterminez quels tests peuvent être effectués dans différents types d'environnement**. La fidélité à la production est un élément clé d'un test précis, mais cela signifie des choses différentes pour différents types de test. Par exemple, le test de régression nécessite la fidélité à la production en termes de métadonnées et, dans une certaine mesure, de données. Assurez-vous de définir le type de fidélité à la production requis pour une série de tests donnée, et de classer clairement les types d'environnement qui peuvent prendre en charge les conditions appropriées pour différents tests. Pour une vue d'ensemble des types de travail qui correspondent à chaque type d'environnement, consultez [Stratégie environnementale](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-environnementale). - **Utilisez des tests d'endurance, de contrainte, de performance et d'échelle pour évaluer en permanence la maturité d'application**. Ces tests montrent la préparation d'une application par rapport aux besoins au niveau de la production. Pour de nouvelles fonctionnalités majeures, exécutez ces tests à plusieurs intervalles dans le cycle de développement d'applications. Il est anti-modèle de considérer ces tests comme faisant partie d'une seule phase ou étape de développement au lieu de faire partie de tâches en cours. Il est très utile pour les équipes de recueillir rapidement et souvent des commentaires sur les performances de l'application, ce qui les aide à mieux comprendre la proximité ou la distance entre l'application et la préparation au niveau de la production. La capacité de mieux identifier et résoudre les problèmes avant la mise en production des modifications vaut la complexité supplémentaire d'exécuter fréquemment des tests plus sophistiqués. - **Savoir quels tests comptent**. Vous aurez probablement un délai fixe pour effectuer votre test d'échelle ou de performance, ce qui rend difficile de tester chaque facette de votre système. Les fonctionnalités ne sont pas toutes utilisées de la même façon et les goulets d'étranglement à l'échelle n'impacteront pas tous l'activité de la même façon. Assurez-vous que vos tests à l'échelle ciblent les parties les plus utilisées et les plus appréciées du système. Définissez et comprenez les opportunités les plus importantes pour vérifier et améliorer l'échelle et les performances dans votre organisation. - **Sachez à quoi ressemble « assez bien ».** La définition des critères de réussite de vos tests d'échelle et de performance est essentielle. Assurez-vous que vous et vos équipes de développement utilisez les critères de réussite comme critères de test. Assurez-vous également qu'ils informent les équipes de développement des exigences fonctionnelles. Généralement, ces critères comprennent la prise en charge d'un nombre spécifique d'utilisateurs simultanés avec des temps de réponse inférieurs à une valeur convenue, et vos [objectifs de niveau de service](/docs/architect/fr-fr/well-architected/guide/resilient#temps-de-récupération) (SLO). Définissez vos critères cibles clés, puis concevez des tests d'échelle et de performance qui vérifient que les critères sont remplis. - **Assurez-vous d'avoir des environnements adéquats.** Les tests d'échelle et de performance nécessitent une fidélité particulière à la production. Vos jeux de données, vos données démographiques de demande, vos taux de demande et vos caractéristiques de charge de travail dans vos environnements de non-production doivent correspondre autant que possible à ce que vous voyez en production. Pour les tests d'échelle, vous devez utiliser une Sandbox Full . Si votre organisation n'a pas de sandbox Full pour les tests à l'échelle, vous ne pouvez pas exécuter des tests à l'échelle adéquats. - **Assurez-vous que les charges de travail de test vous aident à mesurer les exigences non fonctionnelles**. Pensez à prendre en compte : - **Données d'essai** \- Chaque type d'essai devrait être effectué par rapport à des données isolées de la production. Dans les tests unitaires Apex, mettre en œuvre des [modèles d'usine](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm) de données pour s'assurer que le code génère ses propres données d'essai, isolées des données d'environnement. Vous pouvez également créer et gérer des jeux de données de test sous divers formats afin de tester les comportements de chargement de données, remplir des environnements de développement avec des données pour des tests basés sur l'interface utilisateur et faciliter les tests d'intégration. Toutes les données d'essai, qu'elles soient gérées en tant que jeux de données externalisés ou créées à la demande par un code d'usine de données, doivent être nettoyées des données confidentielles et d'identification. Il doit inclure des données corrompues, incomplètes et malformées pour prendre en charge les comportements de test unitaire négatifs et aux frontières. - **Services fictifs et** stub : pour des tests d'intégration, vous pouvez utiliser des services fictifs et stub pour simuler des réponses d'API. Apex prend en charge une [API Stub](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) pour créer des infrastructures fictives à utiliser dans des tests Apex. Mocking pour créer des infrastructures mocking qui peuvent être utilisées dans des tests Apex. Les simulations et les talons peuvent aider à valider les comportements de traitement des données d'un système, en s'appuyant moins sur des usines de données complexes ou des jeux de données tests externes. Il est parfois plus approprié d'utiliser des simulations et des stubs dans des tests où le trafic de production ou les volumes de données ne sont pas pertinents. - **Appareils et technologies** d'assistance - Un élément clé de l'élaboration d'applications [intéressantes](/docs/architect/fr-fr/well-architected/guide/engaging) et [accessibles](/docs/architect/fr-fr/well-architected/guide/compliant#accessibilité) est de s'assurer qu'elles répondent aux attentes des utilisateurs dans une variété d'appareils et avec différents types de technologies d'assistance. Un test d'utilisation efficace peut nécessiter plus d'investissements et différents types d'expertise, mais il est essentiel de connaître le degré d'architecture de vos applications accessibles aux utilisateurs lors de leur publication. - **Simulateurs** : lorsque vous devez répliquer des volumes de requêtes utilisateur de type production, un trafic d'API ou des variations de vitesse réseau, vous pouvez avoir besoin d'outils qui simulent ces conditions. Les tests n'ont pas tous besoin d'un tel niveau d'investissement. Ces outils sont souvent très utiles pour les tests d'évolutivité et de performance. - **Le test IA et** les agents - Un objectif principal du test est de réduire les hallucinations IA, qui sont des réponses convaincantes fabriquées et incorrectes . Assurez-vous que les cas d'utilisation de l'IA sont testés pour mettre en évidence les problèmes courants dus à une compréhension incomplète du client, à des données manquantes, à des champs avec des métadonnées incomplètes et à des données obsolètes. Utilisez le Centre de test pour faciliter la création des données de test nécessaires à ces tests. ### Modèles ALM et anti-modèles Le tableau ci-dessous présente une sélection de schémas à rechercher ou à élaborer dans votre organisation, et des anti-schémas à éviter ou à cibler pour la correction. ✨ Découvrez plus de modèles pour ALM dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/adaptable-application-lifecycle-management) et anti-modèle.
Modèles Anti-Patterns
Gestion des versions En production :
- Les métadonnées montrent l'utilisation de mécanismes de publication stables, tels que :
-- Organisation des métadonnées dans des packages déverrouillés
-- DevOps Center étant actif et installé
-- Déploiements via l'API de métadonnées en utilisant le format source
- Les journaux de déploiement n'affichent aucun déploiement échoué dans l'historique disponible.
- L'historique de déploiement affiche des cadences de publication claires et des clusters de déploiement assez uniformes dans les fenêtres de publication.
En production :
- Les métadonnées indiquent l'utilisation de mécanismes de publication basés sur l'organisation, tels que :
-- Utilisation active d'ensembles de modifications
-- Les déploiements via l'API de métadonnées utilisent le format package.xml
- Les journaux de déploiement affichent les cas répétés d'échec de déploiement dans l'historique disponible.
- Les déploiements n'ont pas de cadence perceptible ou montrent des clusters de déploiements inégaux, qui sont des signes de correctifs et de restaurations ad hoc).
- DevOps Center n'est pas activé et installé.
Dans votre feuille de route et votre documentation :
Les noms de version sont clairs.
- Les fonctionnalités sont clairement liées à une version spécifique nommée.
- Les noms de version peuvent être recherchés et découverts.
- Les équipes peuvent trouver et suivre des consignes claires pour baliser les artefacts, les éléments de développement et d'autres travaux avec les noms de version corrects.
- Il est possible d'extraire une vue claire d'un manifeste de version par un nom de version.
- Des seuils de qualité pour les applications IA génératives sont définis pour différentes étapes de développement.
Dans votre feuille de route et votre documentation :
- Les noms de version ne sont pas inclus.
- Les fonctionnalités ne sont pas clairement liées à une version spécifique.
- Les noms de version sont utilisés de façon ad hoc ou n'existent pas.
- Les équipes désignent les artefacts, les éléments de développement et d'autres travaux de différentes façons.
- Il n'est pas possible d'obtenir une vue claire d'un manifeste de version en utilisant un nom de version.
- Les seuils de qualité des applications d'IA générative ne sont pas définis ou, s'ils sont définis, ne le sont pas pour différentes étapes de développement.
Stratégie environnementale Dans vos organisations :
- Un modèle de développement et de publication piloté par la source est adopté.
- Le suivi de la source est activé pour les sandbox Developer et Developer Pro.
- Les métadonnées dans un environnement donné sont indépendantes des artefacts de publication.
- Les environnements ne correspondent pas directement à un chemin de publication.
- Les parcours de publication d'une modification dépendent du type de modification (risque élevé, risque moyen ou risque faible).
Les environnements surpeuplés n'existent pas.
- Les changements de configuration risqués ne sont jamais effectués directement en production.
- Aucune publication n'a lieu pendant les heures ouvrables de pointe.
- Les sandbox Data 360 sont utilisées pour tester correctement les cas d'utilisation agentiques qui nécessitent la Bibliothèque de données Einstein, des articles Knowledge, et des données non structurées
Dans vos organisations :
- Un modèle de développement et de version basé sur l'organisation est adopté.
- Le suivi de la source n'est pas activé pour les sandbox Developer et Developer Pro.
- Les métadonnées dans un environnement donné sont un artefact de version.
- Les environnements correspondent directement à un parcours de publication.
- Le chemin de publication de chaque modification est le même, quel que soit le type de modification.
- Des environnements surpeuplés existent. - Les changements de configuration risqués sont effectués directement en production.
- Les sorties ont lieu pendant les heures ouvrables de pointe.
- Les agents Agentforce qui nécessitent la Bibliothèque de données Einstein, les articles Knowledge et les données non structurées ne sont pas testés en utilisant des sandbox Data 360
Stratégie de signalisation Dans vos organisations :
- Les équipes collaborent sur la définition et la normalisation des API de contrôle d'intégrité et des SLO.
- L'examen et le perfectionnement réguliers des stratégies de signalisation font partie des examens post mortem et de préparation opérationnelle.
En production :
- Des contrôles sanitaires sont mis en place pour toutes les applications.
- Les applications fournissent des signaux explicites sur leur état de santé, tels que leur charge et leurs capacités.
- Les applications sont conçues pour se dégrader gracieusement lorsque les dépendances sont malsaines.
- Le délestage est utilisé pour éviter les pannes en cascade.
Dans votre conception :
- Les mécanismes de contre-pression et de délestage évitent que les services soient submergés par le trafic.
On suppose que les dépendances finissent par échouer. Les gestionnaires de signal sont conçus pour améliorer les pannes.
Dans vos organisations :
- Les équipes fonctionnent en vase clos, créant des mécanismes de signalisation sanitaire incohérents et incompatibles.
- Les stratégies de signalisation sont une réflexion a posteriori, qui ne s'applique qu'en cas d'incident.
En production :
- Les composants tombent en panne silencieusement sans indiquer leur état de santé.
- Les applications réessayent indéfiniment les demandes de services insalubres.
- Toutes les demandes sont traitées avec la même priorité, quelle que soit leur importance.
- Pour identifier les problèmes, les opérateurs s'appuient uniquement sur des mesures réactives, telles que des plaintes d'utilisateurs ou des défaillances critiques du système.
Dans votre conception :
- Il est supposé que toutes les dépendances seront toujours disponibles, et les partitions réseau, les pics de latence ou d'autres problèmes courants ne sont pas pris en compte.
- Les applications acceptent toutes les requêtes entrantes, même lorsqu'elles sont surchargées, ce qui augmente la latence et la probabilité d'échec
Stratégie de test Dans votre entreprise :
- Les tests d'utilisation emploient une variété d'appareils et de technologies d'assistance.
- Les simulateurs sont utilisés pour répliquer des conditions de production pour des tests d'évolutivité et de performance.
- Les tests sont automatisés pour être exécutés lorsque des modifications entrent dans le contrôle de la source.
- Les tests d'endurance, de stress, de performance et d'échelle sont exécutés à plusieurs intervalles dans le cycle de développement de l'application et considérés comme des tâches en cours.
- Vous incluez le test à l'échelle dans votre processus d'assurance qualité lorsque vous avez des applications à l'échelle B2C, des volumes d'utilisateurs importants ou des volumes de données importants.
- Vos tests à l'échelle sont axés sur les aspects prioritaires du système.
- Vos tests à l'échelle ont des critères bien définis.
- Vous effectuez des tests d'échelle dans une Sandbox Full .
- L'ingénierie des invites inclut un contrôle de qualité par un humain.
- Centre de test Agentforce est utilisé pour les tests robustes des agents.
Dans votre entreprise :
- Les tests d'utilisation ne sont pas effectués, ou s'ils sont effectués sur un ensemble limité d'appareils.
- Les volumes de requêtes utilisateur, le trafic d'API et les variations de vitesse réseau de type production ne sont pas testés.
L'automatisation des tests n'est pas en place.
- L'endurance, le stress, les performances, les tests à l'échelle sont considérés comme une phase ou une étape de développement.
- Vous n'effectuez pas de tests à l'échelle dans le cadre de votre processus d'assurance qualité, et vous avez des applications à l'échelle B2C, de grands volumes d'utilisateurs ou des volumes de données importants.
Vos tests à l'échelle ne sont pas prioritaires.
- Vos tests à l'échelle n'ont pas de critères bien définis.
- Vous effectuez des tests à l'échelle dans une organisation sandbox Partial Copy ou Developer Sandbox.
- L'ingénierie des invites n'inclut pas l'examen de la qualité par un humain.
- Les agents Agentforce ne sont pas testés, ou s'ils le sont, testés uniquement de façon ponctuelle en utilisant Agent Builder.
Dans votre organisation :
- Toutes les données de test sont nettoyées des données confidentielles et d'identification.
Dans votre organisation :
- Les données de test sont identiques aux données de production.
Dans Apex :
- Les modèles d'usine de données sont utilisés pour des tests unitaires
- Des simulacres et des stubs sont utilisés pour simuler des réponses d'API.
Dans Apex :
- Les tests unitaires s'appuient sur les données de l'organisation.
Les faux et les talons ne sont pas utilisés.
Dans vos normes de conception et votre documentation :
- Les environnements sont classés par les types de tests qu'ils peuvent prendre en charge.
- Les régimes de test appropriés sont spécifiés en fonction du risque, du cas d'utilisation ou de la complexité.
Dans vos normes de conception et votre documentation :
- Les types de test pris en charge par chaque environnement ne sont pas clairs.
- Les régimes de test ne sont pas classés par risque, cas d'utilisation ou complexité.
## Réponse à l'incident En ingénierie de la sécurité et de la fiabilité du site (SRE), la réponse aux incidents se concentre sur la façon dont les équipes identifient et traitent les événements qui impactent la disponibilité globale ou la sécurité d'un système, ainsi que sur la façon dont les équipes travaillent pour traiter les causes profondes et prévenir les problèmes futurs. La réponse à un incident implique les processus, les outils et les comportements organisationnels requis pour résoudre les problèmes en temps réel et après un problème. En tant qu'architecte, vous n'êtes peut-être pas la personne qui surveille les opérations quotidiennes de votre solution une fois qu'elle est mise en ligne. Une partie de l'architecture de la résilience consiste à concevoir des capacités de récupération permettant aux équipes de support d'effectuer un diagnostic de premier niveau, de stabiliser les systèmes et de transférer efficacement l'investigation et l'atténuation des causes profondes aux équipes de développement ou de maintenance. Les équipes qui assistent directement les utilisateurs au quotidien peuvent ne pas avoir une compréhension approfondie ou une expertise approfondie de l'architecture du système. Il est essentiel que ces équipes disposent des outils et des processus nécessaires pour surveiller les opérations quotidiennes, accéder aux informations du système lors du diagnostic d'un incident potentiel et être des premiers intervenants efficaces pour tout problème impactant la disponibilité. Vous pouvez améliorer la réponse des équipes aux incidents dans vos solutions Salesforce en vous concentrant sur votre [temps de récupération](/docs/architect/fr-fr/well-architected/guide/resilient#temps-de-récupération), [votre capacité de tri](/docs/architect/fr-fr/well-architected/guide/resilient#capacité-de-tri), et [la surveillance et](/docs/architect/fr-fr/well-architected/guide/resilient#surveillance-et-alerte) les alertes. ### Temps de récupération En cas d'incident, la première priorité doit être de rétablir un état opérationnel stable des systèmes. Souvent, les entreprises pensent que le seul moyen de se remettre d'un incident est de « corriger le problème ». Cette hypothèse est juste dans la mesure où l'analyse précise des causes premières et la résolution des problèmes critiques dans un système sont les moyens ultimes de les résoudre. Cependant, « corriger le problème » pendant les premières étapes de la réponse à la crise n'est pas l'approche la plus pratique. Selon la gravité d'un incident, chaque seconde et son impact peuvent entraîner une perte de chiffre d'affaires ou de réputation pour l'entreprise. Souvent, la tentative de diagnostiquer et de traiter les causes profondes retarde les efforts de restauration d'un système. Sur le plan logistique, l'adoption d'une approche qui demande aux intervenants de s'attaquer aux causes profondes exerce une pression considérable sur les experts en la matière (PME) et le personnel de support de votre entreprise. Pour rechercher et corriger les causes profondes \_d'\_un incident, les PME doivent être de garde à chaque incident, ce qui peut empêcher le personnel de support de première ligne et en contact avec les clients d'agir. Cela peut également entraîner la publication par les équipes de modifications qui, à leur tour, créent plus d'incidents. Au final, une telle approche augmente les coûts, consomme de la bande passante entre les équipes, et entraîne en temps de crise des comportements qui peuvent éroder la Trust client et la réputation de la marque. Le paradigme de gestion des incidents approprié consiste à prioriser et à se concentrer sur la reprise en tant que première étape. Une fois le système rétabli dans la stabilité, vous pouvez effectuer un suivi avec des post-mortems irréprochables, des enquêtes sur les incidents, des mesures correctives pour les causes premières et des activités similaires. Cet ordre d'opérations permet mieux au personnel d'intervention en cas d'incident de trier, de diagnostiquer et d'exécuter des tactiques de récupération, en alertant les PME concernées de ne prêter assistance que si nécessaire. Il permet également aux PME d'identifier et de corriger les causes profondes d'un incident en réduisant la pression d'un tic-tac. Pour adopter un état d'esprit de reprise avant tout en réponse à un incident : - **Établir et atteindre des objectifs de niveau de service SLO**. Les SLO sont des normes que vous développez avec vos parties prenantes pour des exigences non fonctionnelles spécifiques (NFR) d'un système, telles que les performances ou le temps de fonctionnement. Ces objectifs sont mesurés par des indicateurs de niveau de service (SLI) sur une période donnée. Sans SLO, la plupart des tâches liées à la réponse aux incidents et au dépannage des problèmes complexes peuvent sembler désorganisées et réactives, par exemple inciter à agir rapidement pour « mettre fin à cette erreur spécifique, pour cette poignée d’utilisateurs qui l’ont signalée ». C'est souvent ce cycle qui pousse les équipes à rapprocher l'analyse des causes profondes de la réponse aux incidents, car il semble que cela aidera à arrêter les comportements réactifs. Établir des SLO et des SLI est une méthode plus efficace pour commencer. Pour établir des SLO, tenez compte des questions ci-dessous. - **Quel est le NFR de votre système pour les 1 à 3 prochaines années ?** Par exemple, votre NFR peut inclure les temps de réponse, les taux de requête de pointe et les utilisateurs simultanés que votre système doit pouvoir prendre en charge. - **Que voulez-vous que vos clients et leurs utilisateurs vivent ?** Basez vos SLO sur la réponse à cette question, qui peut être « Les utilisateurs peuvent exécuter rapidement des rapports dans Salesforce ». - **Que pouvez-vous mesurer et pendant quelle période devez-vous le mesurer?** Basez vos SLI sur la réponse à cette question. Un SLI correspondant à l'exemple précédent peut être « _x_ % des rapports sont chargés en _n_ secondes en moyenne, mesurés sur une période de 30 jours ». - **Définir et standardiser les tactiques de récupération.** Les annulations de modification et les implémentations de contournement peuvent aider à rendre un système opérationnel et à minimiser l'impact d'un incident. Tactiques et protocoles de récupération de documents qui peuvent être exécutés par les membres appropriés de votre équipe de support ou d'exploitation. Les tactiques de récupération diffèrent selon le type d'incident. Le tableau suivant présente un cadre général qui mappe les types d'incident avec des tactiques de récupération. Pour plus d'informations sur l'identification des points de défaillance et la définition de stratégies d'atténuation, consultez [Disponibilité](/docs/architect/fr-fr/well-architected/guide/reliable#disponibilité).
Type d'incident Déclencheur apparent Tactiques de récupération
Panne système Connexions corrompues ou problèmes d'accès au compte Une stratégie de récupération de compte
Indisponibilité du service Activation d'un service de sauvegarde redondant, contournements manuels
Bogue de production Un changement récent Déploiement annulé ou déploiement de la version précédente
Un bogue émergent, inexpliqué contournements manuels, désactivation des fonctionnalités non essentielles, escalade vers les PME
- **Définissez des critères clairs** de sortie. Utilisez vos SLO pour déterminer si votre système n'a pas de statut d'incident ou d'impact. - **Définissez des processus pour les examens postérieurs à un incident et la réparation des causes profondes.** Prenez le temps d'examiner les incidents une fois le service rétabli. Pendant les examens, adoptez une approche _post-mortem irréprochable_. Collaborer avec les intervenants pour établir des faits clairs sur _ce qui_ s'est produit et _comment_ cela s'est produit, plutôt que de tenter d'attribuer une faute ou un blâme à des individus. Utilisez différents formats d'examen pour examiner les moyens de résoudre les problèmes à long terme. - Un _examen postérieur_ à l'intervention est axé sur la réponse à l'incident. Il est utile pour déterminer si les processus et les tactiques de réponse appropriés sont en place. - Une _analyse des causes_ profondes de l ' incident est axée sur cette dernière. Il peut aider à identifier les bogues ou les problèmes de conception et d'implémentation de votre système qui ont entraîné l'incident. - **Appliquez périodiquement vos protocoles de récupération convenus**. Pratiquez les protocoles de reprise pour vous assurer que tout le monde sait comment gérer les incidents. Utilisez des environnements sandbox et de test pour offrir aux équipes des emplacements où pratiquer la simulation d'incident et la reprise. Exercez-vous également sur vos examens post-incident. En faisant tout cela, la récupération fait partie de votre culture d'ingénierie et de support. Les [modèles et anti-modèles de réponse](/docs/architect/fr-fr/well-architected/guide/resilient#modèles-de-réponse-aux-incidents-et-anti-modèles) aux incidents montrent à quoi ressemble l'architecture pour prioriser la reprise dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce qui facilitent la récupération, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Capacité de tri Dans le contexte de la technologie, le tri consiste à attribuer des catégories et des niveaux de sévérité aux problèmes et aux demandes de support. Quelle que soit la planification de votre solution, des problèmes et des demandes de support utilisateur vont survenir. Ces problèmes peuvent provenir d'un manque de formation ou de gestion des changements, de lacunes dans l'interface utilisateur/UX, de comportements inattendus de l'utilisateur et de problèmes système urgents qui ne sont pas détectés par [la surveillance ou](/docs/architect/fr-fr/well-architected/guide/resilient#surveillance-et-alerte) l'alerte. Les équipes de support et d'exploitation doivent être en mesure d'étudier efficacement les requêtes de support utilisateur et de les diagnostiquer rapidement. Le tri des problèmes afin d'éliminer les problèmes moins graves et de détecter rapidement les incidents système critiques est une compétence clé pour ces équipes. Un mauvais tri ralentit tous les niveaux de support utilisateur, prolonge les incidents critiques et augmente le risque d'interruptions supplémentaires pour vos clients et votre activité. Bien que vous ne soyez pas impliqué dans les opérations quotidiennes et le support, en tant qu'architecte, il est de votre responsabilité de vous assurer que vos équipes de support et d'exploitation peuvent trier efficacement les problèmes dans n'importe quelle solution que vous créez sur Salesforce Platform. Pour permettre aux équipes de résoudre efficacement les problèmes dans vos solutions Salesforce : - **Assurez-vous que les équipes de support ont accès à des informations utiles**. - **Documentez votre système et vos modèles de conception**. Garantir [la lisibilité](/docs/architect/fr-fr/well-architected/guide/intentional#lisibilité) et la cohérence de votre solution est un élément clé pour permettre au personnel de support de comprendre le système qu'il est responsable de soutenir. Dans votre documentation, tenez compte de la façon dont les équipes trouveront des informations sur la priorité des problèmes ou des incidents avec les différentes parties du système. Assurez-vous également que les équipes peuvent consulter rapidement des informations techniques sur les tactiques de récupération en fonction de la zone d'impact. Fournissez des guides de dépannage pertinents pour les problèmes courants Agentforce, tels que la Classification des rubriques et la Sélection d'actions, qui peuvent aider les équipes à trier rapidement les problèmes liés aux autorisations ou à la configuration. - **Concevez en tenant** compte du débogage. Les équipes de support et les administrateurs d'organisation devront activer le débogage et les diagnostics afin de trier correctement les problèmes des utilisateurs dans divers environnements. Parmi les modèles _de débogage_, on peut citer ceux qui intègrent des messages d'erreur de consignation et personnalisés dans des parcours d'exécution à travers le système. Activez les équipes de support sur les approches courantes de débogage Agentforce avec des outils tels que les journaux d'événements et la vue de raisonnement d'Agent Builder. - **Identifier les PME et les parties prenantes** concernées par les incidents. Créez une liste de PME ou de parties prenantes pertinentes qui devraient être disponibles pour soutenir le rétablissement après un incident, et qui devraient être impliquées pendant l'analyse post-incident. - **Faites attention** aux transferts. Garantissez la qualité de chaque transfert de solution aux équipes de support ou d'exploitation dans le cadre de la mise en ligne. Offrir une formation au personnel de support pour qu'il puisse parcourir l'architecture système appropriée et des exercices fictifs d'intervention en cas d'incident. Pensez aux transferts postérieurs à l'incident, notamment à la façon dont les équipes doivent documenter les informations qui ne sont pas consignées dans les journaux ou les notes de requête, ainsi qu'à la façon dont les intervenants en cas d'incident peuvent contribuer aux enquêtes sur les causes profondes ou effectuer des tests d'acceptation des utilisateurs pour toute mesure corrective. - **Si vous êtes consulté, gardez tout le monde concentré sur le rétablissement comme préoccupation principale**. - **Répondez rapidement.** Répondez rapidement aux demandes de support utilisateur, aux notifications de surveillance et aux alertes que vous recevez. - **Aidez à distinguer les symptômes des problèmes.** Déterminez si un incident système réel doit être corrigé. Essayez d'identifier les composants avec les problèmes réels. Assurez-vous que les [tactiques de reprise](/docs/architect/fr-fr/well-architected/guide/resilient#temps-de-récupération) convenues sont suivies afin de libérer rapidement le système du statut d'incident. - Pour les agents Agentforce qui prennent en charge des cas d'utilisation critiques, assurez-vous que des contournements viables et pertinents sont en place et peuvent être activés avec un court préavis en tant que mesure de redondance. Il peut s'agir par exemple de basculer vers la manipulation manuelle ou de rediriger vers la documentation pertinente pour un examen manuel. Les [modèles et anti-modèles de réponse](/docs/architect/fr-fr/well-architected/guide/resilient#modèles-de-réponse-aux-incidents-et-anti-modèles) aux incidents montrent à quoi ressemble une architecture pour un tri efficace dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce pour faciliter le tri, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Surveillance et alerte _La surveillance_ et _l'alerte_ sont des termes très utilisés dans l'ingénierie de fiabilité des sites. Dans le contexte de la résilience du système, la surveillance consiste à évaluer en permanence l'état actuel d'un système, et l'alerte automatise les notifications aux parties prenantes sur les préoccupations potentielles concernant l'état du système. Une surveillance et une alerte efficaces sont essentielles pour dissocier l'échelle et la croissance de votre système de l'échelle et de la croissance de votre personnel de support. Salesforce fournit diverses capacités intégrées pour surveiller les comportements dans votre système. Salesforce offre également une [surveillance en temps](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm) réel des événements en complément ou dans le cadre de [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). Dans n'importe quelle solution Salesforce, les conceptions conçues pour la surveillance et les alertes fournissent : - Capacités de réponse automatisée aux incidents - Informations pertinentes pour les utilisateurs appropriés, au moment opportun - Informations claires pour les vues historiques et l'analyse des tendances Pour concevoir une surveillance et des alertes efficaces dans vos solutions Salesforce : - **Faire de l'automatisation une priorité**. Bien que notifier les utilisateurs des changements d'état critiques soit un élément crucial pour maintenir vos systèmes stables et opérationnels, dans une architecture idéale, le système corrige automatiquement les problèmes lorsque possible et envoie des alertes uniquement en cas de problèmes urgents et irrécupérables. Même sans capacités d'autocorrection, l'automatisation peut rendre vos alertes et vos rapports plus utiles. - **Commencez par ce que Salesforce fournit déjà**. Salesforce Platform fournit des journaux et des API pertinents qui permettent de surveiller les opérations de votre solution par rapport aux limites du gouverneur. De plus, la plate-forme envoie des alertes en cas d'infraction aux limites du gouverneur et autres problèmes similaires. Utilisez ces journaux et alertes comme base pour explorer les moyens d'automatiser plus complètement l'auto-reprise du système, les rapports d'incident et les alertes. Par exemple, vous pouvez implémenter une automatisation qui surveille le journal, puis prendre une mesure de récupération lorsqu'un type d'événement particulier est consigné. - **Classez de façon prévisible** les changements d'état du système. Créez des catégories spécifiques et pertinentes pour les états clés que vous souhaitez surveiller et dont vous souhaitez générer des rapports. Alignez ces catégories sur les catégories que vous définissez pour gérer l'état dans vos [composants d'application](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-états). Adoptez un état d'esprit [orienté API](/docs/architect/fr-fr/well-architected/guide/composable#gestion-des-api) pour gérer les informations sur les changements d'état. Des formats de message et des catégories d'état cohérents simplifient l'automatisation, la génération de rapports et les alertes. - **Alignez votre logique d'automatisation sur les autres parties de votre système**. Si vous avez élaboré un [traitement des erreurs](/docs/architect/fr-fr/well-architected/guide/automated#traitement-des-erreurs) d'automatisation approprié, vous pouvez étendre ces modèles à la classification des changements d'état et à la réponse avec l'automatisation. Pour les changements d'état considérés comme récupérables, vous pouvez automatiser les comportements de réessai. Pour les changements d'état considérés comme critiques ou mortels, automatisez les alertes aux utilisateurs. - **Évite de faire du bruit**. Lorsque les utilisateurs reçoivent un nombre excessif d'alertes, en particulier des alertes qui ne nécessitent aucune action, ils commencent généralement à désactiver ou à ignorer toutes les alertes. Ce scénario sape tous les efforts visant à créer des alertes [utiles](/docs/architect/fr-fr/well-architected/guide/engaging#utile). Pour mieux définir qui reçoit les alertes, ce qui les déclenche et quand elles sont déclenchées, procédez comme suit. - **Élaborer des cartes** des parties prenantes. Pour vous assurer que votre système envoie les alertes appropriées aux parties prenantes appropriées au moment opportun, commencez par identifier et classer vos groupes de parties prenantes. - **Acheminez les messages en fonction des privilèges utilisateur**. Envoyez des alertes uniquement aux destinataires qui ont la capacité et l'autorité de répondre. Les utilisateurs professionnels peuvent recevoir des alertes sur les problèmes qu'ils peuvent corriger en corrigeant les problèmes dans les enregistrements auxquels ils ont accès. Si un problème nécessite une intervention technique plus impliquée, les alertes doivent être adressées au personnel de support. - **Soyez clair** sur la réponse attendue. Envoyez des alertes uniquement dans les scénarios qui nécessitent une intervention humaine. Structurez les messages pour indiquer clairement l'action attendue du destinataire. Si vous envoyez une alerte à une partie prenante pour la visibilité et qu'aucune mesure n'est requise de sa part, indiquez-le clairement dans la version du message qu'elle reçoit. - **Déclarez les alertes opportunes et pertinentes**. Les alertes envoyées en réponse à des échecs rencontrés et qui doivent encore être corrigés) ne sont pas aussi utiles que les alertes relatives à un échec potentiel. Idéalement, le personnel de support est alerté dès que des problèmes se produisent dans le système, ce qui permet de [régler](/docs/architect/fr-fr/well-architected/guide/resilient#capacité-de-tri) les problèmes avant qu'ils n'aient des répercussions négatives sur les opérations commerciales. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/resilient#modèles-de-réponse-aux-incidents-et-anti-modèles) montre à quoi ressemble l'architecture pour une surveillance et des alertes efficaces dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées. Pour plus d'informations sur les outils Salesforce de surveillance et d'alerte, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Modèles de réponse aux incidents et anti-modèles Le tableau ci-dessous présente une sélection de modèles à rechercher ou à élaborer dans votre organisation, ainsi que des anti-modèles à éviter ou à cibler. ✨ Découvrez d'autres modèles de réponse aux incidents dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/adaptable-incident-response) et anti-modèle.
Modèles Anti-Patterns
Temps de récupération Dans votre entreprise :
- Les protocoles de récupération sont pratiqués à intervalles réguliers.
- Les équipes connaissent les services en production qui leur appartiennent et dont elles sont responsables.
- Les équipes comprennent les outils pertinents pour appuyer le diagnostic des problèmes.
Dans votre entreprise :
- Les protocoles de récupération n'existent pas ou ne sont pas pratiqués à intervalles réguliers.
-Les équipes propriétaires et responsables des différents services en production ne sont pas claires.
- Les équipes n'ont aucune directive ni norme sur l'outillage pour appuyer le diagnostic des problèmes.
Dans votre documentation :
- Les tactiques de récupération sont définies et classées par type d'incident et déclencheur.
- Les critères de sortie pour les réponses aux incidents sont inclus dans les SLO et sont clairs.
- Les critères d'activation et la logique d'attribution des autorisations élevées pendant les incidents sont clairs.
- Les ensembles d'autorisations et les autorisations de réponse à un incident sont clairement répertoriés.
- Il existe un guide de dépannage pour faciliter l'identification et le diagnostic des problèmes courants.
Dans votre documentation :
- La réponse à l'incident est effectuée au cas par cas.
- Les critères de sortie des réponses aux incidents n'existent pas.
- Les autorisations élevées ne sont pas attribuées ou, si elles le sont, sont attribuées de façon ad hoc.
- Les ensembles d'autorisations et les autorisations de réponse à un incident ne sont pas répertoriés.
Dans votre organisation :
- Des ensembles d'autorisations basés sur la session existent pour la réponse à un incident et peuvent être attribués au personnel de support pendant la récupération.
- Le Journal d'audit de configuration indique que les testeurs de récupération désignés se sont connectés à l'environnement de test à l'heure convenue et ont suivi les scripts de test de récupération.
Dans votre organisation :
- Les ensembles d'autorisations basés sur la session n'existent pas pour la réponse à un incident, ou s'ils existent, le personnel de support n'est pas autorisé à les utiliser.
- Le Journal d'audit de configuration indique que les testeurs de récupération désignés ne se sont pas connectés à l'environnement de test ou n'ont pas suivi les scripts de test de récupération
Dans vos plans de test :
- Des scripts de test de récupération existent et sont répétitifs.
- Les environnements pour les simulations d'incident sont clairement répertoriés.
Dans vos plans de test :
- Les scripts de test de récupération n'existent pas.
- Les environnements pour les simulations d'incident ne sont pas établis.
Capacité de tri Dans votre entreprise :
- les PME ou les intervenants qui devraient être alertés pour appuyer des questions complexes sont identifiés avant qu'un incident ne se produise.
- La transmission entre les équipes de livraison et de support fait partie de la mise en ligne.
- S'ils sont consultés, les architectes Salesforce répondent rapidement et aident l'équipe à se concentrer sur la récupération.
Dans votre entreprise :
- Les PME ou les parties prenantes qui doivent être alertées ne sont identifiées qu'après un incident.
-Le transfert entre les équipes de livraison et les équipes de support ne fait pas partie du processus de publication.
- Les architectes Salesforce considèrent que la réponse aux incidents ne relève pas de leur champ d'activité.
Dans votre documentation :
- Les modèles de système et de conception utilisés dans une solution donnée peuvent être découverts et lus par le personnel de support.
Dans votre documentation :
- Les modèles de système et de conception utilisés dans une solution donnée ne sont pas facilement disponibles pour le personnel de support.
Dans votre organisation :
- La consignation et les messages d'erreur personnalisés sont incorporés dans les chemins d'exécution à travers le système.
Dans votre organisation : - La consignation et les messages d'erreur personnalisés ne sont pas utilisés.
Surveillance et alerte Dans votre organisation :
- Les alertes sont utilisées uniquement pour informer les utilisateurs des scénarios qui nécessitent une intervention humaine; les autres échecs sont consignés et signalés.
- Des alertes sont envoyées aux utilisateurs capables d'y répondre.
- Dans la mesure du possible, des alertes sont délivrées avant une défaillance potentielle.
Dans votre organisation :
- Des alertes sont envoyées lorsque n'importe quel type d'échec se produit, que des actions de suivi soient nécessaires ou non.
- Des alertes sur les problèmes nécessitant des solutions techniques sont transmises aux utilisateurs professionnels.
- Les alertes sont envoyées uniquement en réponse à des échecs déjà rencontrés.
Dans votre documentation :
- Les critères d'entrée pour les alertes d'ajustement d'invites sont définis en fonction des métriques de commentaires directs et indirects sur l'IA générative.
Dans votre documentation :
- Aucun critère n'est défini pour déclencher des alertes d'ajustement d'invite pour les applications d'IA générative.
## Planification de la continuité La planification de la continuité est un élément clé de la résilience de l'entreprise, qui met l'accent sur la façon de permettre aux personnes et aux systèmes de fonctionner à travers les problèmes causés par un événement imprévu. Les plans de continuité des activités (PCA) adoptent une vision orientée vers les personnes pour faire avancer les processus pendant les crises. Les aspects techniques de la planification de la continuité sont inclus dans les parties Reprise après sinistre d'un PCA. Consultez [Continuité technologique](/docs/architect/fr-fr/well-architected/guide/resilient#continuité-technologique). Sans plans de continuité adéquats, votre organisation peut désormais savoir comment agir, et donc ne pas agir du tout, en cas de crise ou de panne du système. Une planification de continuité inefficace peut avoir un impact catastrophique sur les clients, les parties prenantes et l'entreprise. À la suite d'un événement indésirable, chaque instant qui passe sans maintenir ou récupérer des processus critiques risque de causer des dommages financiers, des dommages à la réputation, à la sécurité des employés et même à la conformité réglementaire. Vous pouvez améliorer la planification de la continuité dans vos systèmes en concentrant vos efforts sur trois domaines : la [définition de la continuité opérationnelle pour Salesforce](/docs/architect/fr-fr/well-architected/guide/resilient#continuité-des-affaires), [la planification de](/docs/architect/fr-fr/well-architected/guide/resilient#continuité-technologique) la continuité technologique et [le renforcement des capacités](/docs/architect/fr-fr/well-architected/guide/resilient#renforcement-des-capacités-de-sauvegarde-et-de-restauration) de sauvegarde et de restauration. ### Continuité des affaires Votre entreprise a peut-être déjà mis en place un PCA. Dans ce cas, assurez-vous que Salesforce y est inclus. Si votre entreprise n'a pas de PCA, créez avec vos parties prenantes un PCA qui couvre vos organisations Salesforce. Salesforce est souvent considéré comme une source de vérité pour les données clients et les processus métiers essentiels dans de nombreuses divisions commerciales. Ainsi, le rôle joué par Salesforce dans un PCA peut différer de celui des autres systèmes. Il est probable que Salesforce intervienne dans de nombreux domaines prioritaires pour la récupération. Pour créer une planification de la continuité des opérations pertinente pour les systèmes Salesforce : - **Clarifier les priorités de relèvement** Comme dans le cas de l'approche générale de l'[intervention en cas](/docs/architect/fr-fr/well-architected/guide/resilient#réponse-à-lincident) d'incident, le relèvement doit être la priorité absolue des systèmes en période de crise. De nombreux services critiques sont exécutés dans et avec Salesforce. Vous devez aider les parties prenantes à identifier la priorité correcte pour récupérer diverses fonctions et capacités métiers. Un cadre général pourrait être : - Stabiliser l'infrastructure commerciale essentielle. - Stabiliser les services clients. - Stabiliser les services des employés et des partenaires. - **Comptabilisez votre écosystème dans vos PCA**. Salesforce n'est pas le seul système dans votre paysage. Assurez-vous d'identifier les écarts dans votre PCA autour des systèmes qui s'intègrent à Salesforce, des solutions installées par des fournisseurs AppExchange et de tout autre système qui se connecte à des données ou des processus dans Salesforce. Si votre capacité à livrer dépend des fournisseurs, demandez-leur leurs plans de continuité. Évaluez leurs capacités et planifiez la disponibilité de vos systèmes. - **Intégrez les préoccupations de PCA à votre stratégie de test**. Créez des plans de test pour votre PCA et réalisez-les. Il est particulièrement important de tester les zones de votre PCA associées aux processus ou aux personnes, qui sont souvent négligées. Incorporez les éléments pertinents de votre PCA à votre [stratégie de test](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-de-test) ALM globale. Créez et suivez une planification de maintenance pour réviser les tests et vous assurer que votre plan reste à jour. Les [modèles et anti-modèles de planification](/docs/architect/fr-fr/well-architected/guide/resilient#schémas-de-planification-de-continuité-et-anti-schémas) montrent à quoi ressemble une planification de continuité correcte et médiocre dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés. Pour plus d'informations sur les outils Salesforce pour définir la continuité des activités, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Continuité technologique L'objectif de la continuité technologique est de s'assurer que les problèmes de composants dans un système n'empêchent pas l'entreprise de maintenir les opérations essentielles. Salesforce accorde la priorité au maintien de nos services au niveau de disponibilité le plus élevé et fournit des informations transparentes sur tout problème. Vous pouvez consulter sur [trust.salesforce.com](https://trust.salesforce.com/) des informations en temps réel sur les performances et les problèmes du système Salesforce. En tant qu'architecte s'appuyant sur Salesforce, vos solutions bénéficient des capacités de fiabilité, de sécurité et de performance du site que Salesforce fournit sur l'ensemble de la plate-forme. Cependant, la continuité globale de vos solutions Salesforce va au-delà des services intégrés que Salesforce fournit. D'un point de vue architectural, la planification de la continuité technologique de Salesforce doit commencer par poser et répondre à des questions sur la façon dont Salesforce s'intègre dans votre paysage d'entreprise plus large. Quels types de système s'intègrent à Salesforce ? Comment les systèmes externes dépendent-ils des processus ou des informations dans Salesforce ? Dans vos organisations Salesforce, quels processus ou fonctionnalités s'appuient sur les solutions AppExchange ? Vos utilisateurs accèdent-ils à Salesforce via des services d'identité tiers ou l'authentification unique ? Pour améliorer la continuité technologique dans vos systèmes Salesforce : - **Évaluez votre infrastructure.** La stratégie de réparation la plus courante pour les pannes ou les problèmes technologiques consiste à élaborer des services ou des systèmes redondants auxquels vous pouvez vous rabattre en cas d'incident. Chez Salesforce, nous avons une architecture volontairement redondante, ce qui signifie que nous conservons des copies des systèmes et des services de nos clients à différents emplacements physiques. Nous utilisons plusieurs techniques de reprise après sinistre, notamment le basculement de site, qui nous permet d'orienter le trafic utilisateur d'un centre de données à un autre si nécessaire. Pour identifier où il peut être nécessaire d'élaborer une redondance intentionnelle, posez-vous les questions ci-dessous. - Que se passe-t-il pendant une interruption du service \[X] ? Pouvons-nous basculer de ce service à un autre ? - Combien de temps faut-il pour récupérer \[X] ? Quel est l'impact pour nos clients ? Quel est l'impact pour nos partenaires ? Quel est l'impact pour les équipes internes ? - Qu'en est-il des [sauvegardes](/docs/architect/fr-fr/well-architected/guide/resilient#renforcement-des-capacités-de-sauvegarde-et-de-restauration) et de leur fréquence ? Les sauvegardes peuvent-elles fournir les données nécessaires pour soutenir l'entreprise ? - Avons-nous des dépendances vis-à-vis des fournisseurs ? Quels sont leurs plans de PCA ? - **Apporter un soutien opérationnel.** Le support opérationnel consiste à remettre en route les équipes le plus rapidement possible. Réfléchissez à la façon dont votre système peut gérer les augmentations significatives des exigences en capacité et la demande résultant de changements imprévus, y compris des changements à l'échelle de l'industrie, de la région ou mondiale. Assurez-vous que votre PCA tient compte des ressources supplémentaires ou des procédures de bris de verre dont l'ingénierie de la fiabilité du site (SRE) ou les équipes de support peuvent avoir besoin pour réagir efficacement aux incidents. Les questions à poser au sujet du soutien opérationnel comprennent : - En cas de panne, nos équipes techniques disposeraient-elles des outils nécessaires pour poursuivre leur travail ? Avons-nous simulé une panne pour valider des plans ou identifier des écarts ? - Si une catastrophe se produit dans une zone spécifique, avons-nous des plans de couverture pour cette zone? - Nos clients sont-ils mondiaux ? Fonctionnent-ils 24/7 ? - Avons-nous une [surveillance et une alerte](/docs/architect/fr-fr/well-architected/guide/resilient#surveillance-et-alerte) appropriées pour aviser les personnes appropriées en cas de défaillance? - **Automatisez et testez vos tactiques de récupération.** Lorsqu'un problème est corrigé, identifiez son emplacement et comment il a été corrigé. Si possible, en fonction de la correction, automatisez vos tactiques de récupération et ajustez les problèmes de processus. De nombreuses entreprises planifient des simulations d'incident pour un sous-ensemble de services afin de tester la résilience du système. Par exemple, simuler un compte d'administrateur système verrouillé ou compromis, ou simuler une panne ou un problème avec un fournisseur AppExchange. Consultez [Réaction aux incidents](/docs/architect/fr-fr/well-architected/guide/resilient#réponse-à-lincident).)Les questions à poser sur la façon dont les tests et l'automatisation peuvent accélérer la restauration des services comprennent : - À quelle fréquence planifions-nous et exécutons-nous des simulations d'incident ? - Sait-on combien de temps il faut pour rétablir un état stable des services? - Avons-nous mis en place des processus de livraison stables? - Savons-nous où nous pouvons automatiser le basculement et la récupération ? Traitez tous les éléments issus de vos examens postérieurs à l'incident comme vos autres éléments de développement. Ajoutez-les à vos systèmes de planification pour pouvoir les prioriser et les utiliser. Les [modèles et anti-modèles de planification](/docs/architect/fr-fr/well-architected/guide/resilient#schémas-de-planification-de-continuité-et-anti-schémas) montrent à quoi ressemble une planification de continuité technologique correcte et médiocre dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés. Pour plus d'informations sur les outils Salesforce pour la planification de la continuité technologique, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Renforcement des capacités de sauvegarde et de restauration La restauration de copies sauvegardées de données ou de métadonnées peut aider à rétablir votre organisation dans son dernier état stable connu. Il peut également fournir un système de basculement lors d'une panne système catastrophique ou d'une interruption de service. La sauvegarde régulière de vos données et métadonnées et le stockage de vos copies cryptées et sauvegardées à un emplacement sécurisé ajoutent une couche de résilience supplémentaire à votre architecture. Sans stratégies de sauvegarde et de restauration, vous ne pouvez pas restaurer des versions propres de vos données et métadonnées de production lorsqu'elles sont corrompues par des actes malveillants, lorsque des défauts sont involontairement introduits en production ou lorsqu'une défaillance pendant un chargement de données volumineux corrompt les données de production. L'un de ces scénarios peut entraîner la corruption ou même la perte définitive de vos données de production critiques. La mise en place d'une technologie de sauvegarde et de restauration offre plusieurs avantages en plus de la planification de la continuité, notamment l'aide aux stratégies de réduction des volumes de données importants et le respect des politiques de rétention liées à la conformité. Pour garantir la continuité des stratégies de sauvegarde et de restauration dans vos solutions Salesforce : - **Commence.** La première étape pour avoir une bonne stratégie de sauvegarde et de restauration est d'avoir une stratégie en premier lieu. Même une opération aussi simple que la sauvegarde nocturne de toutes les données et métadonnées de votre organisation peut éviter à votre entreprise de perdre des informations ou des fonctionnalités critiques en cas de sinistre. - **Limitez l'accès aux sauvegardes.** Les administrateurs système sont les seuls utilisateurs qui doivent avoir accès à des copies sauvegardées de vos données. Cette restriction d'accès empêche un utilisateur professionnel d'afficher des enregistrements dans une copie de sauvegarde qu'il n'est pas autorisé à afficher dans votre organisation. - **Testez régulièrement votre processus de restauration.** Quelle que soit la stratégie de sauvegarde et de restauration que vous implémentez, [testez](/docs/architect/fr-fr/well-architected/guide/resilient#stratégie-de-test) régulièrement votre processus de restauration dans une organisation sandbox Full ou Partial Copy pour vous assurer qu'il fonctionnera correctement lorsque vous en aurez besoin. - **Alignez votre stratégie de sauvegarde et de restauration sur votre stratégie d'archivage de données.** Déterminez ce qui doit se passer dans vos sauvegardes ou archives lorsque des enregistrements sont archivés ou purgés de votre système. Consultez [Volume de données](/docs/architect/fr-fr/well-architected/guide/reliable#volume-de-données)). Une stratégie de sauvegarde plus précise peut s'avérer nécessaire si vos volumes de données sont si importants qu'une sauvegarde complète n'a pas le temps de se terminer avant le début de l'exécution de la sauvegarde suivante. Une stratégie de sauvegarde plus précise peut également être nécessaire si les données de votre organisation changent si souvent que les mises à jour sont essentielles à votre organisation. Pour rendre votre stratégie de sauvegarde plus précise : - **Étendez vos sauvegardes à des objets spécifiques**. Cette stratégie implique de sauvegarder les enregistrements de différents objets à différents intervalles de temps. Notez que les objets enfants doivent être sauvegardés aux mêmes intervalles que leurs parents pour préserver la cohérence des données. - **Sauvegardes partielles** de **la case horaire**. Cette stratégie consiste à différencier les sauvegardes complètes (de toutes les données et métadonnées) et partielles (uniquement des métadonnées et des enregistrements ajoutés ou modifiés depuis la dernière sauvegarde). **\* N'arrêtez jamais d'effectuer des sauvegardes complètes**. Il est important de noter que vous ne devez jamais éliminer complètement les sauvegardes complètes, même si les volumes de données entraînent de longues durées d'exécution. Pour des volumes de données importants, planifiez des sauvegardes complètes régulières mais peu fréquentes (par exemple, des sauvegardes hebdomadaires). Prévoyez également des sauvegardes partielles ou spécifiques à un objet plus fréquentes (par exemple, des sauvegardes nocturnes ou des sauvegardes toutes les X heures). Cette approche offre la flexibilité nécessaire pour reconstruire le jeu de données le plus complet et le plus précis à utiliser dans vos processus de restauration.\* Les [modèles et anti-modèles de planification](/docs/architect/fr-fr/well-architected/guide/resilient#schémas-de-planification-de-continuité-et-anti-schémas) montrent à quoi ressemblent les capacités de sauvegarde et de restauration correctes et médiocres dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés. ### Sauvegarde et restauration Salesforce Salesforce Backup and Recover, une solution Salesforce intégrée qui inclut Own Recover from the Own acquisition, protège les données importantes contre la perte ou la corruption. Notre solution hautement sécurisée, facile à configurer et toujours disponible garantit la continuité des activités et la résilience des données, et simplifie la conformité. Utilisez Sauvegarde et restauration Salesforce pour éviter la perte de données, récupérer rapidement après des incidents de données et simplifier votre stratégie globale de gestion des données. Vous pouvez créer des stratégies de sauvegarde pour des données importantes et réglementées, et restaurer ces données en quelques clics seulement. #### Déploiement de sauvegardes automatisées Les sauvegardes quotidiennes automatisées protègent toutes les données cruciales de votre organisation, notamment les métadonnées, les sandbox, les données de packages gérés, les pièces jointes, et davantage. Exécutez des sauvegardes aussi souvent que nécessaire pour atteindre vos objectifs de point de récupération (RPO) et protéger vos déploiements. Les sauvegardes sont toujours accessibles et stockées de façon sécurisée et conforme. La protection continue des données est également disponible pour des données encore plus confidentielles ou transactionnelles, ce qui accélère la récupération d'informations critiques en évolution rapide. #### Surveillance proactive des données Détectez les activités de données inhabituelles, la perte de données et la corruption avec des alertes proactives envoyées directement par e-mail. Recevez des alertes en temps réel pour identifier des valeurs statistiques aberrantes ou créer des règles qui vous informent de l'activité inhabituelle des données, ce qui vous aide à détecter les incidents plus rapidement que jamais. #### Restauration précise et rapide Salesforce Backup and Recover accélère la récupération en offrant une visibilité précise sur les modifications, ce qui permet d'identifier et de restaurer rapidement les données affectées. Des outils tels que des graphiques visuels mettent en évidence les modifications indésirables, tandis que des fonctionnalités de récupération faciles à utiliser restaurent avec précision les objets, les champs et les enregistrements affectés. #### Extension de l'utilisation de vos sauvegardes Nos outils permettent d'utiliser des sauvegardes pour les analytiques, les audits et la conformité, en offrant des données historiques recherchables, une fonctionnalité de recherche ouverte pour la visibilité des données passées et des capacités d'exportation pour les analytiques externes ou l'entreposage. Cela permet de redéfinir les sauvegardes sans avoir besoin d'API Salesforce supplémentaires. #### Gestion des données de sauvegarde unifiée Backup and Recover offre une console unique pour consolider toutes les sauvegardes, la gestion, les opérations et la conformité. Cette console permet d'accéder à, de gérer, de personnaliser et de surveiller les sauvegardes de toutes vos organisations de production et sandbox. Il permet également d'exécuter des requêtes de la personne concernée pour garantir la conformité des données de sauvegarde, et de contrôler entièrement la personnalisation des planifications de sauvegarde, de la fréquence et des stratégies de rétention. #### Principaux cas d'utilisation pour la sauvegarde et la restauration Salesforce - **Atténuer l'impact des incidents** de données. Salesforce Backup and Recover permet d'atténuer les incidents de données, tels que les cyberattaques ou les activités internes ou externes malveillantes, en permettant aux utilisateurs de restaurer l'état des enregistrements affectés avant l'incident. La fonctionnalité d'exportation de Backup and Recover garantit un accès continu aux données critiques des utilisateurs et leur utilisation. - **Évitez la perte permanente** de données. L'erreur humaine reste la principale cause de perte de données. Backup and& Recover offre une solution précise et rapide à ces erreurs. - **Satisfaire plus facilement aux exigences légales** et de conformité des données. Salesforce Backup and Recover prend en charge le modèle de responsabilité partagée, ce qui active la fonctionnalité en libre-service pour les oublis en masse ou la rectification des données dans vos données de sauvegarde. Pour plus d'informations sur les outils Salesforce de sauvegarde et de restauration, consultez [Outils Salesforce pour la résilience](/docs/architect/fr-fr/well-architected/guide/resilient#outils-salesforce-pour-la-résilience). ### Schémas de planification de continuité et anti-schémas Le tableau ci-dessous présente une sélection de modèles à rechercher ou à élaborer dans votre organisation, ainsi que des anti-modèles à éviter ou à cibler. ✨ Découvrez d'autres modèles de planification de la continuité dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/adaptable-continuity-planning) et anti-modèle.
Modèles Anti-Patterns
Continuité des affaires Dans votre entreprise :
- Un état d'esprit « récupération d'abord » est adopté, l'accent étant mis sur l'élimination le plus tôt possible de l'impact des fonctions et capacités commerciales prioritaires.
- Il y a un calendrier de maintenance pour l'examen des plans de test de PCA.
Dans votre entreprise :
- Une mentalité « corriger le problème » est la seule approche de la gestion des incidents.
- Les plans de test BCP ne sont pas actualisés à intervalles réguliers.
Dans votre documentation :
- Un PCA contient des étapes de traitement ou de tri des données si Salesforce n'est plus disponible, une liste d'événements qui déclenchent l'utilisation du PCA, ainsi que des étapes et des intervalles pour les tests du PCA.
- Le PCA comprend les systèmes et les dépendances en amont et en aval.
Dans votre documentation :
- Un PCA n'existe pas, n'est pas complet ou inclut uniquement Salesforce.
Dans vos plans de test :
- Les domaines de votre PCA liés aux processus et aux personnes sont pris en compte.
Dans vos plans de test :
- Les zones de votre PCA associées aux processus et aux personnes ne sont pas prises en compte.
Continuité technologique Dans votre entreprise :
- Vous avez évalué si vous devez élaborer des systèmes de redondance intentionnelle ou de basculement
- Les tactiques de reprise après incident sont automatisées dans la mesure du possible.
Dans votre entreprise :
- Vous n'avez pas évalué la nécessité d'une redondance intentionnelle ou de systèmes de basculement
- Les tactiques de reprise après incident sont toutes manuelles.
Dans votre documentation :
- Le PCA tient compte des ressources supplémentaires ou des procédures de bris de verre dont les équipes pourraient avoir besoin pour réagir efficacement aux incidents.
Dans votre documentation :
- Le PCA n'inclut pas les besoins de soutien opérationnel.
Sauvegarde et restauration Dans votre documentation :
- Une stratégie de sauvegarde et de restauration existe pour les données et les métadonnées.
Dans votre documentation :
- Une stratégie de sauvegarde et de restauration n'existe pas, ou si elle existe, est incomplète, s'appliquant uniquement aux données ou uniquement aux métadonnées, pas aux deux.
Dans votre entreprise :
- Les sauvegardes sont stockées à un emplacement sécurisé auquel seuls les utilisateurs autorisés ont accès.
- Les plans de test et les journaux de test montrent que les restaurations de données sont testées dans une sandbox Full ou Partial Copy au moins deux fois par an.
Dans votre entreprise :
Les sauvegardes ne sont pas lisibles.
- Les sauvegardes sont stockées à des emplacements auxquels les utilisateurs professionnels non autorisés peuvent accéder.
- Il n'y a pas de processus de restauration des données ou le processus de restauration des données n'est pas testé.
## Outils Salesforce pour la résilience
OutilDescriptionGestion du cycle de vie des applicationsRéponse à l'incidentPlanification de la continuité
Apex Hammer Tests Découvrez les tests Apex Salesforce dans les versions actuelles et nouvelles. X
API Apex Stub Élaborez une infrastructure fictive pour rationaliser les tests. X
Sauvegarde et récupération Générez automatiquement des sauvegardes pour éviter la perte de données. X
Gros objets Stockez et gérez des volumes de données importants sur la plate-forme. X
Suivi de l'historique des champs Suivez et affichez l'historique des champs. X
Recueil de connaissances sur l'adoption et la sécurité pour votre organisationOuvrir le lien dans une nouvelle fenêtre Surveillez l'adoption et l'utilisation de Lightning Experience dans votre organisation. X
Gérer les tâches de chargement de données en masse Créez une mise à jour ou supprimez des volumes importants d'enregistrements avec l'API de transfert en masse. X
Gérer les événements de Surveillance des événements en temps réel Gérez les paramètres de streaming et de stockage de la surveillance des événements. X
Ressources de données et de stockage Visualisez les limites en stockage et l'utilisation de votre organisation Salesforce. X
Surveiller les journaux de débogage Surveillez les journaux et définissez des indicateurs pour déclencher la consignation. X
Surveillance de l'activité de connexion avec Login Forensics Identifiez le comportement qui peut indiquer une fraude d'identité. X
Surveillance des modifications de configuration avec le Journal d'audit de configuration Suivez les récentes modifications apportées à la configuration par les administrateurs. X
Surveiller l'historique de formation Visualisez les cours de formation Salesforce que vos utilisateurs ont suivis. X
Surveillance des tâches en arrière-plan Surveillez les tâches en arrière-plan dans votre organisation. X
Surveillance des tâches planifiées Visualisez les instantanés de rapport, les tâches Apex planifiées et les actualisations de tableau de bord. X
Test de l'évolutivité Testez les performances du système et interprétez les résultats. X
Proactive Monitoring Limitez les interruptions en utilisant les services de surveillance de Salesforce. X
Salesforce Data Mask Masquez automatiquement les données dans une organisation sandbox. X
La page Vue d'ensemble du système Visualisez les données d'utilisation et les limites de votre organisation. X
Utiliser force:lightning:lint Analysez et validez le code via la Salesforce CLI. X
## Ressources pertinentes pour Résilient
RessourceDescriptionGestion du cycle de vie des applicationsRéponse à l'incidentPlanification de la continuité
7 anti-modèles dans les tests de performance et d'échelle Évitez les anti-modèles courants dans les tests de performance et d'échelle. X
Analyse des performances et des points chauds d'échelle dans les applications Salesforce complexes Découvrez une approche pour résoudre les problèmes de performance et d'évolutivité dans votre organisation. X
Élaboration d ' un plan de reprise après sinistre (Trailhead) Élaborez un plan de reprise après sinistre. X
La continuité des affaires est plus qu’une sauvegarde et une restauration Observez une vue complète de la PCA. X
Modèle Design Standards Créez des normes de conception pour votre organisation. X
Outils de diagnostic et de surveillance dans Salesforce Apprenez à améliorer la qualité et les performances de vos implémentations. X
Principes directeurs de la planification de la continuité des activités Examinez les principes de base qui sous-tendent une PCA efficace. X
Comment Test de l'évolutivité dans Salesforce Découvrez les cinq phases du cycle de vie des tests à l'échelle. X
Introduction aux tests de performance Apprenez à développer une méthode de test des performances. X
Surveiller votre organisation Découvrez les options de surveillance en libre-service. X
Modèle de stratégie de test Créez et personnalisez des plans de test d'échelle et de performance. X
Modèle de stratégie de test Assurez-vous que votre stratégie de test est terminée. X
Compréhension du développement piloté par la source (Trailhead) Découvrez le développement de packages et les organisations tests. X
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. > Découvrez [ici](/docs/architect/fr-fr/well-architected/guide/contributors) nos planifications de mise à jour. ## Introduction Un système sécurisé protège les parties prenantes et les données d'une organisation. Les architectures sécurisées vérifient l'identité des utilisateurs, limitent l'accès aux données uniquement aux informations nécessaires et empêchent la compromission des données. Salesforce priorise Customer Trust et la sécurité des données. Salesforce Platform garantit la confidentialité et la sécurité. [Salesforce Trust](https://trust.salesforce.com/) fournit des informations en temps réel sur les performances et la sécurité du système. La protection des données de votre organisation et de vos clients est la base de l'élaboration de solutions Salesforce sécurisées. En tant qu'architecte Salesforce, vous êtes responsable de la sécurité des données de votre organisation et de vos clients en utilisant les fonctionnalités de sécurité intégrées de Salesforce. Tenez compte de la distribution géographique, du secteur d'activité, des procédures opérationnelles de l'entreprise et des types de données clients en prenant ces décisions. Vous pouvez renforcer la sécurité de vos solutions en vous concentrant sur trois domaines : la sécurité organisationnelle, la sécurité des sessions et la sécurité des données. ## Sécurité organisationnelle La sécurité de l'organisation protège les systèmes contre tout accès non autorisé en garantissant que seuls les utilisateurs validés et autorisés peuvent accéder à un système, et uniquement aux fonctionnalités et aux données nécessaires. Les signes que vous avez une sécurité organisationnelle problématique comprennent : - Processus ad hoc d'activation ou de désactivation d'utilisateurs - Étapes imprécises de mise à jour de l'autorisation pour les changements de rôle utilisateur ou système - S'appuyer sur la Knowledge institutionnelle des individus pour des attributions correctes en matière de sécurité des utilisateurs - Non-conformité avec les cadres de sécurité établis ou les meilleures pratiques de l'industrie - Absence de cadre structuré de gouvernance des données et de politiques de soutien Vous pouvez améliorer les contrôles de sécurité organisationnels pour vos organisations Salesforce en vous concentrant sur l'authentification et l'autorisation. ### Authentification L'authentification est cruciale pour la sécurité et la gestion des accès, car elle vérifie l'identité des utilisateurs qui tentent d'accéder à votre système. Cela s'applique aussi bien aux utilisateurs humains (employés, clients) qu'aux utilisateurs automatisés (systèmes externes, intégrations), chaque type d'utilisateur nécessitant des schémas d'authentification spécifiques. Pour garantir un accès sécurisé à tous les points d'entrée Salesforce de votre organisation, vous devez configurer diverses méthodes d'authentification. Pour créer des flux d'authentification sécurisés dans Salesforce : - **Créez des utilisateurs Salesforce basés sur des individus, pas sur des personnes**. Les capacités d'audit intégrées de Salesforce sont plus efficaces lorsque chaque compte utilisateur correspond à un seul individu qui accède à la plate-forme. L'utilisation de comptes utilisateur partagés compromet l'efficacité de ces audits, introduit des failles de sécurité supplémentaires, escalade l'impact potentiel des violations de compte et complique votre capacité à créer des schémas d'autorisation efficaces. Cela inclut les comptes utilisateur des utilisateurs de l'intégration. - **Scénarios d'accès** basés sur l'interface utilisateur sécurisés. La plupart des utilisateurs humains ont besoin d'un accès basé sur l'interface utilisateur (souvent appelé accès à la connexion) pour une organisation Salesforce. Salesforce fournit plusieurs niveaux de protection pour ces scénarios de connexion, notamment : - **Stratégies de mot de passe.** Les cybercriminels ciblent souvent les noms d'utilisateur et les mots de passe pour obtenir un accès non autorisé aux applications. Bien que la configuration de [stratégies de mot](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5) de passe soit une étape fondamentale dans la protection de l'accès à la connexion, il est important de noter que cela ne suffit pas, car Salesforce autorise le remplacement de ces stratégies par utilisateur. - **Authentification multifacteur (MFA)**. Salesforce [exige la MFA](https://help.salesforce.com/s/articleView?id=000352937&type=1) pour toutes les connexions utilisateur basées sur l'interface utilisateur. La MFA fournit une protection essentielle contre les fuites d'identifiants et les attaques par force brute en demandant aux utilisateurs de fournir une forme supplémentaire d'identification, ou facteur, après avoir saisi leur nom d'utilisateur et leur mot de passe. Ce facteur supplémentaire prend généralement une forme physique, par exemple un appareil mobile, une clé de sécurité ou un marqueur biométrique. - **Single-sign on (SSO)**. Dans les scénarios d'authentification unique, les utilisateurs utilisent un seul jeu d'identifiants dans les applications d'une organisation. L'accès aux systèmes est provisionné et géré à partir d'un emplacement central, ce qui renforce la sécurité. Salesforce peut agir en tant que fournisseur de services ou fournisseur d'identité dans des [scénarios d'authentification](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5) unique. Assurez-vous d'autoriser certains administrateurs ou tous les administrateurs à se connecter directement à Salesforce pour leur permettre de résoudre les pannes ou les problèmes liés à votre implémentation de l'authentification unique. - **Étapes postérieures à la connexion.** Pour certains cas d'utilisation, vous pouvez demander aux utilisateurs de suivre des étapes supplémentaires avant d'accéder à votre système. Des flux de connexion personnalisés peuvent être implémentés pour guider les utilisateurs à travers ces étapes de processus supplémentaires. Exemples : - Acceptation des conditions d'utilisation - [Scénarios de découverte de la connexion et de connexion sans mot de passe](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5) - Limitation du nombre de sessions Salesforce simultanées par utilisateur afin de réduire la probabilité d'attaques basées sur la session (consultez [Sécurité de session](/docs/architect/fr-fr/well-architected/guide/secure#sécurité-de-la-session)). - Connexion aux services de géorepérage - **Scénarios d'accès** basés sur l'API sécurisés. Tout utilisateur peut demander un accès basé sur l'API pour une organisation Salesforce. Salesforce fournit plusieurs couches de protection pour les scénarios basés sur l'API, notamment : - **Contrôle d'accès** API. Sans [contrôle d'accès](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5) API, toute personne disposant d'un ensemble d'identifiants valides peut exploiter n'importe quelle application pour se connecter à votre organisation, même si l'application connectée n'est pas déployée dans l'organisation. Les contrôles d'accès aux données resteront en vigueur, mais les utilisateurs pourraient accéder aux informations de manière incontrôlée. Par exemple, une application peut être utilisée pour télécharger des volumes de données importants, ou même charger des informations corrompues, sans l'approbation d'un administrateur système. - **Autorisations API uniquement**. Vous pouvez configurer des autorisations utilisateur API uniquement dans Salesforce. Attribuez-le dans le cadre d'un ensemble d'autorisations à tous les utilisateurs automatisés ou [d'intégration](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm) pour bloquer entièrement l'accès basé sur l'interface utilisateur. - **Certificats et clés**. Les [certificats et clés](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5) permettent à Salesforce de valider que les demandes proviennent d'entreprises ou de sociétés autorisées. Si vous souhaitez utiliser [SSO avec Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5), vous devez configurer des certificats et des clés. - **Applications connectées**. La configuration d'[applications connectées](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5) dans Salesforce permet de contrôler l'accès système externe à Salesforce, notamment les protocoles d'authentification requis, l'étendue d'autorisation et le comportement de session dans une définition unique. - **Identifiants nommés**. Les [identifiants nommés](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5) permettent de contrôler les points d'accès externes et les protocoles d'authentification dans une définition unique dans Salesforce. Utilisez-les pour définir et gérer en toute sécurité l'authentification des appels externes depuis Apex, des services externes et des sources de données Salesforce Connect. - **Authentification des utilisateurs Agentforce Agent.** Les agents Agentforce, élaborés sur Salesforce, utilisent des objets agent-utilisateur avec des autorisations gérables de la même façon que celles des utilisateurs réels. Lors de la configuration d'un agent, adaptez soigneusement l'accès au rôle de l'agent, en limitant l'accès aux données uniquement aux éléments nécessaires pour servir les utilisateurs. Tout aussi important, les agents peuvent être configurés avec des actions publiques et privées. Pour des actions privées, validez et authentifiez les utilisateurs, en les mappant avec le contexte de l'agent. Cela permet à l'agent d'usurper l'identité de l'utilisateur et d'agir dans le cadre de ses contrôles d'accès, en maintenant la sécurité et Trust. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/secure#schémas-de-sécurité-organisationnels-et-anti-schémas) ci-dessous montre à quoi ressemble une architecture d'authentification correcte (et mauvaise) dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les opportunités d'amélioration. Pour plus d'informations sur les outils d'authentification disponibles dans Salesforce, consultez [Outils pertinents pour](/docs/architect/fr-fr/well-architected/guide/secure#outils-pertinents-pour-sécuriser) sécuriser. ### Autorisation L'autorisation définit les fonctionnalités, les fonctionnalités et les données auxquelles un utilisateur peut accéder, ainsi que les actions qu'il peut exécuter avec ces ressources, une fois [authentifié](/docs/architect/fr-fr/well-architected/guide/secure#authentification). Les contrôles d'autorisation ne s'adressent pas uniquement aux utilisateurs humains, ils doivent également être adaptés aux Utilisateurs Agentforce, en particulier aux Agents fournissant des services à des utilisateurs finaux non authentifiés. Bien que la limitation des utilisateurs autorisés à s'authentifier dans votre organisation soit une première étape cruciale, il est tout aussi vital de coupler une authentification forte à une autorisation robuste. Sans contrôles d'autorisation adéquats, les utilisateurs pourraient créer, modifier et supprimer des enregistrements ou accéder aux fonctionnalités du système d'une manière préjudiciable à votre activité et à vos parties prenantes. Un contrôle inadéquat des autorisations peut également rendre les systèmes plus difficiles à utiliser. En contrôlant ce que les utilisateurs peuvent faire dans le système, vous favorisez des niveaux de Trust plus élevés, en protégeant à la fois votre système et vos utilisateurs. Pour élaborer des schémas d'autorisation sécurisés pour Salesforce : - **Suivez le principe du moindre privilège**. Adoptez le principe du moindre privilège (PoLP) en attribuant aux utilisateurs uniquement les autorisations requises pour leurs tâches. Pour suivre ce principe, concevez des ensembles d'autorisations granulaires et modulaires. Cela permet des contrôles d'accès sophistiqués via des groupes d'ensembles d'autorisations, ce qui permet une gestion précise des autorisations, notamment la possibilité de [mettre en sourdine](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5), [de définir des dates](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238) d'expiration, et davantage. Alignez vos [unités fonctionnelles](/docs/architect/fr-fr/well-architected/guide/composable#unités-fonctionnelles) système avec les capacités métiers pour définir des autorisations précises et des groupes d'ensembles d'autorisations efficaces. Notez que les autorisations s'appliquent à l'accès _aux métadonnées_ dans Salesforce. Pour plus d'informations sur la configuration de PoLP pour l'accès aux _données_ Salesforce, consultez [Partage et visibilité](/docs/architect/fr-fr/well-architected/guide/secure#partage-et-visibilité). - **Considérez l'accès des utilisateurs en termes de personnes, pas d'individus**. La réflexion sur l'autorisation (ou la sécurité en général) en termes d'utilisateurs individuels ne mettra pas votre système à l'échelle et n'évoluera pas. À la place, concevez et gérez des personnes qui représentent des groupes d'utilisateurs. Les solutions Salesforce sécurisées utilisent des individus pour l'authentification et des personnes pour l'autorisation. En définissant des configurations de sécurité pour des personnes distinctes, vous contrôlez avec précision l'accès et les privilèges dans votre modèle de sécurité, ce qui réduit la nécessité de refactoriser à long terme. Insérez les personnes de sécurité que vous définissez dans vos [normes et documentations](/docs/architect/fr-fr/well-architected/guide/intentional#lisibilité) de conception. - **Contrôlez l'accès des utilisateurs aux métadonnées en utilisant des ensembles d'autorisations et des groupes d'ensembles d'autorisations**. Les ensembles d'autorisations et les groupes d'ensembles d'autorisations régissent les métadonnées auxquelles les utilisateurs ont accès et ce qu'ils peuvent faire avec ces métadonnées. Pour plus d'informations sur les métadonnées Salesforce, consultez [Métadonnées par rapport](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#métadonnées-par-rapport-aux-données) aux données. Configurez les attributions d'applications, les activations de licences de fonctionnalité, l'accès au package géré, les autorisations système, l'accès [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) et l'accès au niveau du champ via des ensembles d'autorisations et des groupes d'ensembles d'autorisations. Insérez cet accès dans vos [normes et documentations](/docs/architect/fr-fr/well-architected/guide/intentional#lisibilité) de conception. - **Utilisez les paramètres par défaut de l'organisation (OWD) et le partage pour contrôler l'accès aux données des utilisateurs**. Les [données et métadonnées](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#métadonnées-par-rapport-aux-données) sont des entités distinctes dans Salesforce, qui nécessitent des contrôles d'accès distincts pour chacune d'elles. Utilisez des OWD et des outils de partage intégrés pour configurer l'accès aux données Salesforce (enregistrements individuels, fichiers et documents). Pour plus d'informations, consultez [Sécurité des données](/docs/architect/fr-fr/well-architected/guide/secure#sécurité-des-données). - **Utilisez des étendues OAuth pour contrôler l'accès des applications connectées**. Lors de la configuration d'une application connectée, vous définissez l'[étendue](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) ou les autorisations d'accès des utilisateurs de l'application aux ressources Salesforce. Pour plus d'informations sur la gestion des jetons OAuth, consultez [Gestion des sessions](/docs/architect/fr-fr/well-architected/guide/secure#gestion-des-sessions). - **Créez un utilisateur Salesforce pour chaque intégration**. Pour respecter le principe du moindre privilège, créez un [utilisateur d'intégration](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm) Salesforce unique pour chaque intégration. Vous pouvez ainsi attribuer un accès à des données spécifiques, ce qui améliore le contrôle des opérations, garantit la traçabilité des transactions et minimise l'impact des failles de sécurité potentielles. - **Implémentez des comptes uniques avec le PoLP pour tous les utilisateurs Agent**. Chaque Utilisateur Agentforce doit être unique et ne pas être réutilisé entre plusieurs Agents. Les autorisations de ces comptes doivent respecter strictement le principe du moindre privilège. Notez que les actions exécutées par un utilisateur agent peuvent fonctionner dans un contexte de sécurité élevé dans Salesforce ou contre des systèmes externes qui ne respectent pas les contrôles d'accès Salesforce. Cela peut entraîner l'accès ou la divulgation d'informations confidentielles aux utilisateurs par Actions. - **Réduisez l'utilisation de profils et migrez tous les contrôles d'accès hors des profils**. Les profils permettent de limiter l ' accès aux [plage d &apos](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5); adresses IP, aux [heures de connexion](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) et aux fonctionnalités propres à l ' interface utilisateur Salesforce Classic héritée (en particulier les types d ' enregistrement par défaut et les attributions de présentation de page). Toute autre fonctionnalité actuellement présente dans des profils doit être migrée vers une fonctionnalité équivalente dans des [ensembles d'autorisations et](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm) des groupes d'ensembles d'autorisations. Les fonctionnalités de vos profils liées aux fonctionnalités de l'interface utilisateur Salesforce Classic doivent être ciblées pour la correction. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/secure#schémas-de-sécurité-organisationnels-et-anti-schémas) ci-dessous montre les pratiques d'autorisation appropriées (et médiocres) dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les opportunités d'amélioration. Pour plus d'informations sur les outils d'autorisation disponibles dans Salesforce, consultez [Outils pertinents pour sécuriser](/docs/architect/fr-fr/well-architected/guide/secure#outils-pertinents-pour-sécuriser). ### Schémas de sécurité organisationnels et anti-schémas Le tableau ci-dessous présente une sélection de schémas à rechercher (ou à élaborer) dans votre organisation et d'anti-schémas à éviter ou à cibler pour la correction. ✨ Découvrez d'autres modèles de sécurité organisationnelle dans l'[explorateur Pattern & Anti-Pattern](/docs/architect/fr-fr/well-architected-tools/guide/trusted-organizational-security).
Modèles Anti-Patterns
Authentification Dans vos normes de conception et votre documentation :
- Les personnes de sécurité approuvées sont clairement définies et répertoriées
- Le mappage entre les personnes de sécurité et les schémas d'authentification autorisés (interface utilisateur, API) existent dans une matrice de sécurité
Si des normes de conception et des documents existent, ils :
- Ne pas inclure les personnes de sécurité
- Ne pas inclure une matrice de sécurité avec des mappages clairs pour les personnes de sécurité et les schémas d'authentification autorisés
Dans votre organisation :
- Configurations de connexion alignées sur le contrôle Salesforce MFA
- La relation entre les utilisateurs et les entités qui se connectent à Salesforce est de 1:1 (aucun utilisateur partagé)
- Le Contrôle d'accès API empêche les utilisateurs de s'authentifier via une application connectée non autorisée
- Si l'authentification unique est activée, les utilisateurs administrateurs approuvés ont un accès direct à la connexion
Dans votre organisation :
- Les configurations de connexion ne sont pas alignées avec le contrôle Salesforce MFA
- La relation entre les utilisateurs et les entités qui se connectent à Salesforce n'est pas 1:1 (il existe des comptes utilisateur partagés)
- Si les utilisateurs accèdent à Salesforce depuis un pare-feu, le pare-feu utilise des adresses IP codées en dur pour sécuriser les communications vers/depuis Salesforce
- Contrôle d'accès API n'est pas activé
- Si l'authentification unique est activée, aucun utilisateur administrateur approuvé n'a un accès direct à la connexion
Dans LWC, Apex, Aura :
- Les méthodes qui exécutent l'authentification utilisent des identifiants nommés pour gérer les flux nom d'utilisateur/mot de passe
- Aucun nom d'utilisateur ou mot de passe n'est affiché dans le code sous des formats lisibles (pas de valeurs ou de chaînes codées en dur)
- Si des flux de connexion personnalisés existent, tous les codes personnalisés associés utilisent les méthodes SessionManagement appropriées
Dans LWC, Apex, Aura :
- L'authentification est gérée ad hoc
- Noms d'utilisateur et mots de passe affichés dans le code
Autorization Dans vos normes de conception et votre documentation :
- Chaque utilisateur et système ayant accès à Salesforce est mappé avec une ou plusieurs personnes dans une matrice de sécurité
- La matrice de sécurité répertorie clairement les autorisations de métadonnées et les personnes utilisateur attribuées
- Les cas d'utilisation pour accorder des privilèges élevés sont clairement énumérés, notamment :
-- Autorisations Modifier toutes les données
-- Autorisations Afficher toutes les données
Si des normes de conception et des documents existent, ils :
- Ne pas inclure de matrice de sécurité
- Ne pas répertorier clairement les autorisations
- Ne pas énumérer clairement les cas d'utilisation pour accorder des privilèges élevés
Dans votre organisation :
- Des ensembles d'autorisations et des groupes d'ensembles d'autorisations sont utilisés pour contrôler l'accès aux métadonnées
- Les ensembles d'autorisations et les groupes d'ensembles d'autorisations s'alignent sur les capacités métiers
- Les autorisations attribuées aux utilisateurs suivent les définitions de matrice de sécurité
- Les profils sont utilisés de façon minimale et uniquement pour contrôler les plages IP de connexion et les heures de connexion
- Un utilisateur d'intégration API-only unique est configuré pour chaque intégration
Dans votre organisation :
- Les groupes d'ensembles d'autorisations ne sont pas configurés pour autoriser l'accès en fonction des capacités métiers
- Les ensembles d'autorisations sont configurés ad hoc
- Les ensembles d'autorisations sont redondants ou fortement dupliqués; il est difficile de comprendre une logique fonctionnelle claire et les différences entre les ensembles
- Les autorisations attribuées aux utilisateurs ne suivent pas les définitions de matrice de sécurité
- Les profils contiennent des contrôles d'accès pour les métadonnées
- Les utilisateurs d'API uniquement ne sont pas configurés ou sont partagés entre plusieurs intégrations
Dans Apex :
- Les opérations de base de données effectuent les contrôles d'accès appropriés au niveau du champ et de l'objet, notamment :
-- Les instructions DML et Database DML déclarent le mode utilisateur ou système pour les opérations de données ET/OU
-- Les instructions DML et Database DML utilisent des méthodes stripInaccessible avant les opérations sur les données
-- Les instructions SOQL et SOSL utilisent les mots-clés WITH USER_MODE et WITH SYSTEM_MODE AND/OR
-- Des méthodes stripInaccessible sont utilisées pour filtrer les résultats de requêtes et de sous-requêtes
-- Les méthodes de résultat describe sObject (c.-à-d. isAccessible, isCreateable, isUpdateable et/ou isDeletable) sont utilisées avec précaution
Dans Apex :
- DML, méthodes Database Class, SOQL et SOSL exécutés en mode système par défaut
- Les opérations de base de données n'effectuent pas les contrôles d'accès appropriés, notamment :
-- Les méthodes DML ou Database Class utilisent exclusivement les contrôles isAccessible, isCreateable, isUpdateable et/ou isDeletable pour l'accès sObject et au niveau du champ
-- Les requêtes SOQL utilisent exclusivement des mots-clés WITH SECURITY_ENFORCED pour les restrictions d'accès
Dans les flux (Considérations de sécurité pour la conception de flux):
- Les flux utilisent le Contexte d'exécution le plus restrictif possible, idéalement Mode utilisateur
- L'accès aux données confidentielles ou privilégiées de sécurité est effectué par des flux secondaires afin de minimiser le contexte d'exécution
- Logique de limitation exécutée dans des flux déclenchés par un enregistrement
- Les entrées de flux sont validées pour garantir que seules les charges utiles autorisées sont transmises en entrée
Dans des flux :
- Les flux sont exécutés en mode système ou en mode système sans partage, quelles que soient les actions exécutées par le flux
- Toute la logique de flux est exécutée dans un flux unique et volumineux
- Les entrées de flux ne sont pas validées et sont transmises aux consommateurs sans vérification
## Sécurité de la session Une session est la série de requêtes et de réponses associées à un utilisateur sur une période donnée. Une session est initiée lorsqu'un utilisateur réussit son authentification à Salesforce. La [sécurité de session](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm) est la pratique qui consiste à configurer votre système pour empêcher l'accès non autorisé et les violations de données en empêchant les interférences de session ou le piratage. Toute l'activité des utilisateurs dans votre système se produit dans le contexte d'une session. Par conséquent, il est essentiel de prendre en compte la façon dont les sessions sont initiées, ce qui peut se dérouler pendant une session, les appareils que les utilisateurs vont (et doivent) utiliser, et comment détecter et réagir aux comportements de session suspects ou anormaux. Vous pouvez renforcer la sécurité des sessions dans Salesforce en vous concentrant sur trois clés : la gestion des sessions, l'accès aux appareils, et la détection et la réponse aux menaces. ### Gestion des sessions Les sessions sont initiées lorsqu'un utilisateur réussit à s'authentifier et à accéder à Salesforce. Ces sessions permettent à la plate-forme d'associer des demandes et des réponses spécifiques à cet utilisateur particulier. Le protocole HTTPS facilite la communication entre un client frontal et Salesforce Platform. Les clients peuvent inclure des navigateurs, des applications mobiles, des applications locales, etc. HTTPS est un protocole sans état, ce qui signifie que chaque communication est discrète et sans rapport avec les communications précédentes ou futures. Cette approche sans état accélère les communications réseau et élimine les erreurs causées par les liens rompus entre les paquets. Cependant, les applications Web doivent toujours avoir un moyen de suivre l'identité de chaque utilisateur et d'autres informations associées dans plusieurs interactions de requête et de réponse. Salesforce, comme la plupart des applications Web, utilise des sessions et [des jetons](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5) pour cela. - Les **sessions** permettent à Salesforce d'associer des demandes et des réponses à des utilisateurs. Lorsqu'un utilisateur est authentifié, la plate-forme renvoie un ID de session à l'application cliente, qui inclut cet ID avec toutes les requêtes de l'utilisateur (notamment la navigation, la recherche et la soumission de données). - **Les jetons** permettent aux utilisateurs et aux applications connectées de vérifier leur identité une fois et d'utiliser ensuite un jeton d'accès unique. Les jetons ont une durée de vie limitée et fournissent uniquement l'accès à des ressources spécifiques (pour plus d'informations sur la configuration des niveaux d'accès, consultez [Autorisation](/docs/architect/fr-fr/well-architected/guide/secure#autorisation)). Les jetons permettent d'accéder aux ressources autorisées sans demander aux utilisateurs de se connecter. Si les sessions et les jetons ne sont pas correctement sécurisés, les mauvais acteurs peuvent potentiellement interférer avec eux et usurper l'identité des utilisateurs ou exécuter un code malveillant dans votre système. Pour élaborer une gestion des sessions sécurisée pour Salesforce : - **Comprenez comment Salesforce classe les types de session**. Identifiez et mappez les [types de session](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5) approuvés avec des utilisateurs de sécurité, puis enregistrez-les dans votre documentation. - **Contrôlez l'origine des sessions et le trafic de session**. Lorsque vous avez identifié les types de session que divers utilisateurs sont autorisés à initier, configurez des contrôles pour bloquer les sessions provenant de sources ou de contextes non approuvés. Salesforce fournit plusieurs méthodes pour contrôler l'origine des sessions et le trafic, notamment : - **Protection de session** intégrée. Salesforce active automatiquement les protections de l'organisation contre les activités malveillantes basées sur la session, notamment les scripts inter-site, la falsification de requêtes inter-site, [le reniflage de contenu](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), [le détournement de](https://owasp.org/www-community/attacks/Clickjacking) clics, etc. Ces protections ne doivent jamais être désactivées; certaines ne peuvent pas être désactivées. - **Domaines et plages IP**. [Mon domaine](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5) est activé par défaut dans toutes les organisations Salesforce, ce qui crée un sous-domaine spécifique à l'entreprise pour l'accès Salesforce. Vous pouvez personnaliser ou modifier le nom associé à une organisation via Mon domaine. De plus, Salesforce prend en charge des [configurations de domaine](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5) supplémentaires pour les sites Experience Cloud et d'autres pages d'application. Remarque : Si vos utilisateurs doivent accéder à Salesforce depuis un pare-feu d'entreprise, ajoutez les [domaines requis](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5) à vos listes d'autorisations de pare-feu. Vous pouvez configurer des [plages IP de](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm) connexion et [des plages IP approuvées](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm) pour contrôler les requêtes de connexion et de session entrantes à Salesforce. - **Heures de connexion**. Si certains utilisateurs ont défini des heures de travail, vous pouvez limiter leur accès à Salesforce en dehors des [heures de connexion](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) définies. - **Contrôlez les activités qui nécessitent une sécurité au niveau de la session** supplémentaire. Par défaut, les sessions peuvent avoir deux types de [niveau de sécurité](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5) : standard et assurance élevée. Utilisez ces niveaux de sécurité pour contrôler comment les utilisateurs peuvent et ne peuvent pas exécuter des activités telles que l'accès aux rapports et aux tableaux de bord, ou la gestion des configurations de sécurité dans une organisation Salesforce. Les stratégies de sécurité au niveau de la session peuvent obliger les utilisateurs à établir des [sessions d'assurance élevée](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5) pour effectuer des opérations ou empêcher les utilisateurs d'effectuer des opérations confidentielles. - **Contrôlez les activités qui nécessitent des autorisations basées sur la session** supplémentaires. Salesforce prend en charge les activations d'autorisations [basées sur la session](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5) afin d'accorder temporairement aux utilisateurs une autorisation ou un accès supérieur aux autorisations pendant une session particulière. Vous pouvez activer et désactiver des autorisations basées sur la session via des flux ou des API Salesforce. - **Gérez les sessions utilisateur inactives à travers des expirations**. L'arrêt des sessions inactives est un élément clé de la gestion de la sécurité des sessions. Cela permet de protéger votre système lorsque, par exemple, un utilisateur laisse une session Salesforce ouverte sous un onglet de navigateur, mais travaille activement dans une autre application, ou lorsque l'appareil mobile d'un utilisateur est connecté à Salesforce, mais sans surveillance. Salesforce a une expiration d'inactivité de session par défaut de deux heures. Vous pouvez augmenter ou diminuer les niveaux d'expiration d'inactivité de session, mais l'augmentation des expirations ne doit être effectuée qu'avec une justification convaincante et bien documentée. - **Gérez les sessions d'application connectée via la configuration de jetons.** Lorsque vous configurez une application connectée, vous définissez également l'étendue, ou le niveau d'autorisation, qui sera accordé aux utilisateurs accédant à Salesforce via l'application connectée. Cette étendue est automatiquement appliquée au niveau de la session via [des jetons OAuth](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US), qui sont émis lorsqu'un utilisateur d'une application connectée s'authentifie avec succès. Vous pouvez contrôler la durée de vie d'un jeton via des [politiques d'actualisation](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) de jeton. Les administrateurs d'organisation peuvent révoquer manuellement des jetons par utilisateur et par organisation, si nécessaire. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/secure#schémas-de-sécurité-de-session-et-anti-schémas) ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion des sessions dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les opportunités d'amélioration. Pour plus d'informations sur les outils de gestion de session disponibles dans Salesforce, consultez [Outils pertinents pour sécuriser](/docs/architect/fr-fr/well-architected/guide/secure#outils-pertinents-pour-sécuriser). ### Accès à l'appareil Dans le contexte actuel, un _appareil_ est tout équipement électronique qu'un individu utilise pour accéder à Salesforce, par exemple une station de travail de bureau, un ordinateur portable, une tablette ou un téléphone mobile. Les appareils portables offrent aux utilisateurs la flexibilité nécessaire pour accéder à Salesforce depuis n'importe quel emplacement. Cependant, cette commodité introduit potentiellement des vecteurs d'attaque supplémentaires pour les acteurs malveillants. Ces vecteurs de menace vont de simples tactiques, comme le surf à l'épaule dans un lieu public pour voler des identifiants, à des méthodes plus sophistiquées comme l'installation de logiciels malveillants sur un appareil ou la création d'un réseau Wi-Fi public bidon pour intercepter les transmissions de données. Par conséquent, la sécurité des appareils, en particulier des appareils portables, est essentielle à la sécurité générale du système. Pour sécuriser l'accès des appareils à Salesforce : - **Utilisez les solutions d'application mobile fournies par Salesforce**. Demandez aux utilisateurs d'appareils mobiles qui doivent accéder à Salesforce d'utiliser les [applications Salesforce](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5) officielles disponibles pour iOS et Android. Si les besoins métiers nécessitent une solution mobile personnalisée, vous devez utiliser le [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm), qui fournit des méthodes d'authentification et d'autorisation sécurisées. - **Concevez l'utilisation d'appareils mobiles dans votre gestion des sessions**. Les niveaux de sécurité de session, les expirations de session et les autres contrôles de contexte de session doivent tenir compte de tout accès anticipé des utilisateurs sur les appareils mobiles. Déterminez quels appareils doivent et ne doivent pas être autorisés à accéder à Salesforce, et quels types d'utilisateur doivent avoir accès aux sessions mobiles. Insérez des normes d'accès mobile dans la documentation de votre agent de sécurité. Pour plus d'informations à ce sujet, consultez [Gestion des sessions](/docs/architect/fr-fr/well-architected/guide/secure#gestion-des-sessions). - **Complétez la sécurité au niveau de l'appareil avec la technologie MDM (Mobile Device Management).** Les applications Salesforce pour iOS et Android sont [compatibles avec de nombreuses suites MDM](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5) populaires. Vous pouvez configurer des contrôles d'accès supplémentaires pour l'application Salesforce sur les appareils utilisateur via votre solution MDM préférée. - **Complétez la sécurité au niveau de l'application avec la technologie MAM (Mobile Application Management)**. La technologie MAM prend en charge les contrôles au niveau de l'application sur les appareils mobiles. Salesforce offre un [complément MAM](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5) payant pour les applications mobiles Salesforce. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/secure#schémas-de-sécurité-de-session-et-anti-schémas) ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion des appareils dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les opportunités d'amélioration. Pour plus d'informations sur les outils de gestion des appareils disponibles dans Salesforce, consultez [Outils pertinents pour sécuriser](/docs/architect/fr-fr/well-architected/guide/secure#outils-pertinents-pour-sécuriser). ### Détection et réponse aux menaces La détection des menaces est le processus d'identification de modèles de comportement dans votre système qui peuvent indiquer une activité malveillante. Cela peut inclure des volumes de données téléchargés supérieurs à la moyenne ou la modification par un utilisateur de champs contenant des données confidentielles dans plusieurs enregistrements dans un délai plus court que la moyenne. Les réponses aux menaces peuvent inclure l'expiration automatique de la session, des alertes et d'autres notifications. L'objectif de la détection des menaces est d'identifier les problèmes potentiels et d'y répondre le plus rapidement possible. Prendre des mesures basées sur la détection des menaces en temps réel peut arrêter les comportements malveillants dans son parcours. Salesforce offre une [surveillance en temps](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5) réel des événements en complément ou dans le cadre de [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). Utilisez l'une de ces solutions si vous avez des applications hautement confidentielles ou si vous avez besoin de capacités robustes de détection et de réponse en temps réel aux menaces. Pour élaborer une stratégie efficace de détection des menaces et de réponse à vos solutions Salesforce : - **Utilisez les capacités d'audit** intégrées. Salesforce offre divers [outils intégrés](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5) qui facilitent le suivi et l'audit des modifications apportées à votre organisation. Par exemple, le [Piste d'audit](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5) de configuration permet d'afficher l'historique d'audit des actions administratives. Salesforce suit par défaut les modifications au niveau du champ pendant une période limitée, mais vous pouvez activer le [Suivi historique des](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5) champs pour afficher les modifications de champ pendant 18 mois maximum dans l'interface utilisateur et 24 mois maximum via l'API. Vous pouvez également activer [le Journal d'audit](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5) des champs afin de conserver indéfiniment l'historique des modifications au niveau du champ (jusqu'à la suppression manuelle des données). - **Établir des examens** réguliers. L'audit est crucial pour identifier les modifications anormales que la détection des menaces en temps réel peut manquer. Prenons l'exemple d'un utilisateur disposant d'un accès légitime qui supprime régulièrement un petit nombre d'enregistrements par jour sur une longue période. Comme cet utilisateur dispose d'identifiants de connexion valides, est autorisé à supprimer des enregistrements et ne supprime pas un grand nombre d'enregistrements à la fois, il est peu probable que l'activité soit détectée comme une menace en temps réel. Cependant, une équipe d'audit examinant les rapports d'activité des utilisateurs identifierait clairement cette tendance à la suppression excessive d'enregistrements par un seul utilisateur au fil du temps, ce qui faciliterait la résolution de ce problème. Dans le cadre de vos [politiques de gouvernance](/docs/architect/fr-fr/well-architected/guide/intentional#gouvernance), définissez des intervalles réguliers pour auditer l'historique des connexions, l'activité des sessions utilisateur et l'utilisation des applications connectées. - **Développez une stratégie de réponse aux menaces et incluez-la dans vos stratégies de sécurité**. Créez une stratégie de réponse aux menaces qui couvre : - Les définitions de type de réponse aux menaces (par exemple, alertes et automatisations) et tous les [groupes d'](/docs/architect/fr-fr/well-architected/guide/resilient#réponse-à-lincident)intervenants. Pour plus d'informations sur la conception de messages ou d'alertes, consultez [Erreurs et notifications](/docs/architect/fr-fr/well-architected/guide/engaging#notifications-et-messages). - Catégories spécifiques de modifications ou d'activités en temps réel qui pourraient être considérées comme des menaces et type de réponse associé pour chaque - Une liste claire de toutes les réponses automatisées aux menaces (telles que la révocation de jetons, la fin de sessions, la désactivation de comptes utilisateur ou le blocage de l'accès aux ressources) et des déclencheurs d'automatisation Event Monitoring fournit les données nécessaires pour appliquer ce principe en activant la détection et la réponse en temps réel aux menaces. La Sécurité des transactions applique les actions pilotées par la stratégie de votre entreprise, et les types d'événement prennent en charge la surveillance de l'accès des utilisateurs et des applications au fil du temps. Le service natif de détection des menaces de Salesforce utilise des modèles statistiques et d'apprentissage machine pour identifier les comportements suspects. Ce service génère des événements spécifiques qui protègent contre les cyberattaques et l'accès suspect aux données. La Sécurité des transactions va plus loin en matière de sécurité, car elle fournit une infrastructure qui intercepte les événements clés qui se produisent dans votre organisation et applique les actions pilotées par la stratégie de votre entreprise. Cela transforme la Surveillance des événements d'un outil de consignation en composant important d'une défense de sécurité automatisée. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/secure#schémas-de-sécurité-de-session-et-anti-schémas) ci-dessous montre à quoi ressemblent la détection et la réponse correctes (et médiocres) aux menaces dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les opportunités d'amélioration. Pour plus d'informations sur les outils d'automatisation de la détection des menaces, des alertes et des réponses disponibles dans Salesforce, consultez [Outils pertinents pour sécuriser](/docs/architect/fr-fr/well-architected/guide/secure#outils-pertinents-pour-sécuriser). ### Schémas de sécurité de session et anti-schémas Le tableau ci-dessous présente une sélection de schémas à rechercher (ou à élaborer) dans votre organisation et d'anti-schémas à éviter ou à cibler pour la correction. ✨ Découvrez d'autres modèles de sécurité de session dans l'[Explorateur de modèle](/docs/architect/fr-fr/well-architected-tools/guide/trusted-session-security) et anti-modèle.
Modèles Anti-Patterns
Gestion des sessions Dans vos normes de conception et votre documentation :
- Les personnes de sécurité répertorient clairement les types de session approuvés et les paramètres d'expiration/durée pour chaque personne
- Les heures de connexion ont été spécifiées (ou identifiées comme inutiles)
- Les opérations qui nécessitent une sécurité ou des autorisations au niveau de la session élevées sont claires et accessibles
- Les stratégies de gestion de l'étendue et des jetons de l'application connectée sont claires et accessibles
Dans vos normes de conception et votre documentation :
- Les personnes de sécurité n'existent pas ou manquent d'informations sur les types de session et les paramètres d'expiration/durée
- Les stratégies de sécurité ne contiennent pas d'informations sur les étendues d'application connectée ou la gestion des jetons
Dans votre organisation :
- Les audits de session montrent que les utilisateurs accèdent à Salesforce uniquement via les types de session attendus
- Il existe un ensemble d'autorisations clair et actif pour l'accès « Utilisateur API uniquement » (avec l'ensemble d'autorisations « API uniquement » défini sur TRUE) et tous les utilisateurs d'intégration et automatisés sont attribués
- Si les utilisateurs accèdent à Salesforce depuis un pare-feu, le pare-feu utilise une liste d'autorisations de domaines requis au lieu d'adresses IP pour sécuriser les communications vers/depuis Salesforce
- Les intervalles d'expiration de session inactifs ne dépassent pas le délai par défaut (2 heures)
- Tous les paramètres suivants sont activés :
-- Protection contre le détournement de clic pour les pages de configuration
-- Protection contre le détournement de clics pour les pages Salesforce hors Configuration
-- Protection contre la falsification de requête inter-site (CSRF)
-- Protection contre les scripts inter-site (XSS)
-- Activer la protection contre le reniflage de contenus
-- Protection des URL de référent
-- Avertir les utilisateurs avant qu'ils soient redirigés hors de Salesforce
Dans votre organisation :
- Il n'y a pas d'audit de session régulière
- Il n'y a pas de définition des types de session que les utilisateurs doivent avoir
- Les autorisations « API uniquement » ne sont pas claires ou sont manquantes dans l'intégration et les utilisateurs automatisés
- Si les utilisateurs accèdent à Salesforce depuis un pare-feu, le pare-feu utilise des adresses IP codées en dur pour sécuriser les communications vers/depuis Salesforce
- Les intervalles d'expiration de session inactifs dépassent le délai par défaut (2 heures)
- L'un des paramètres suivants est désactivé :
-- Protection contre le détournement de clic pour les pages de configuration
-- Protection contre le détournement de clics pour les pages Salesforce hors Configuration
-- Protection contre la falsification de requête inter-site (CSRF)
-- Protection contre les scripts inter-site (XSS)
-- Activer la protection contre le reniflage de contenus
-- Protection des URL de référent
-- Avertir les utilisateurs avant qu'ils soient redirigés hors de Salesforce
Dans LWC, Apex, Aura :
- Si des flux de connexion personnalisés existent, tous les codes personnalisés associés utilisent les méthodes SessionManagement appropriées pour attribuer la sécurité au niveau de la session
Dans LWC, Apex, Aura :
- Si des flux de connexion personnalisés existent, il n'y a aucune logique pour attribuer la sécurité au niveau de la session
Accès à l'appareil Dans vos normes de conception et votre documentation :
- Les stratégies de l'appareil sont claires et accessibles
- Les personnes de sécurité sont clairement mappées avec les utilisations et les politiques appropriées de l'appareil
Dans vos normes de conception et votre documentation :
- Les stratégies de sécurité n'existent pas ou ne contiennent pas d'informations sur l'accès à l'appareil
Dans votre organisation :
- La configuration de l'application mobile connectée Salesforce nécessite le déverrouillage par code PIN/passcode après l'inactivité
- Si les besoins métiers nécessitent un contrôle strict des utilisateurs qui peuvent accéder à Salesforce Mobile, le Contrôle d'accès API est activé et des ensembles d'autorisations sont attribués à tous les utilisateurs des applications mobiles Salesforce
Dans votre organisation :
- L'application mobile connectée Salesforce n'est pas configurée pour demander le déverrouillage du code PIN/passcode en cas d'inactivité
– Les besoins métiers nécessitent un contrôle strict des utilisateurs qui peuvent accéder à Salesforce Mobile, mais le Contrôle d'accès API n'est pas activé ou des ensembles d'autorisations ne sont pas utilisés pour contrôler l'accès aux applications mobiles Salesforce
Détection et réponse aux menaces Dans vos normes de conception et votre documentation :
- Les stratégies de sécurité contiennent une liste d'événements qui doivent déclencher une réponse avec le type de réponse approprié
- Les niveaux d'audit ont été spécifiés pour tous les objets de votre modèle de données
- Les étapes de révision des journaux disponibles dans Salesforce sont documentées
- Toutes les réponses automatisées sont clairement documentées
Dans vos normes de conception et votre documentation :
- Les stratégies de sécurité n'existent pas ou ne contiennent pas d'informations sur la détection des menaces et les alertes
- La documentation sur les réponses automatisées n'existe pas ou n'est pas claire
Au sein de votre entreprise :
- Données d'audit disponibles dans les rapports que les parties prenantes peuvent comprendre et accéder
- Examen régulier de l'historique et des rapports d'audit
Au sein de votre entreprise :
- Les données d'audit sont disponibles uniquement via des fichiers journaux qui nécessitent une expertise en la matière pour accéder à et interpréter
- Aucun processus n'existe pour examiner l'information de vérification
Dans votre organisation :
- Des automatisations sont en place pour répondre aux menaces en désactivant les comptes utilisateur ou en bloquant l'accès aux ressources en temps réel si une utilisation anormale est détectée
- Les notifications et les alertes sont configurées pour notifier les utilisateurs appropriés des activités anormales
- Le suivi Historique des champs est activé pour tous les champs contenant des données privées ou confidentielles
Dans votre organisation :
- Aucune automatisation n'est en place pour répondre aux menaces
- Les notifications et alertes ne sont pas configurées pour notifier les utilisateurs appropriés d'une activité anormale, ou certaines notifications et alertes liées à une activité anormale existent, mais elles sont ponctuelles
- Le suivi Historique des champs n'est pas activé de façon cohérente pour les champs contenant des données privées ou confidentielles
## Sécurité des données La sécurité des données est la pratique qui consiste à protéger vos données contre tout accès non autorisé, corruption ou suppression involontaire. La sécurité des données implique la protection des données en transit et au repos. Une solide sécurité des données réduit les risques et les dommages potentiels liés à l'accès non autorisé à votre système. Une sécurité des données inadéquate expose les systèmes à des violations de données, qui peuvent impacter gravement les clients et votre entreprise. Par conséquent, la protection de vos données est fondamentale pour élaborer des architectures sécurisées. Pour renforcer la sécurité des données, il faut d'abord bien comprendre ce qui est considéré comme une donnée dans Salesforce, ainsi que sa classification. Les enregistrements, fichiers et documents individuels stockés dans une organisation Salesforce sont ses données. Pour plus d'informations sur la distinction entre les métadonnées et les données, consultez [Salesforce Architecture Basics](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#métadonnées-par-rapport-aux-données). Vous pouvez renforcer la sécurité des données dans vos solutions Salesforce en vous concentrant sur le partage et la visibilité ainsi que sur l'utilisation du cryptage. > Remarque : Lors de la conception pour la sécurité des données, assurez-vous de prendre en compte la [confidentialité des données](/docs/architect/fr-fr/well-architected/guide/compliant#confidentialité-des-données) ainsi que l'[archivage et la purge](/docs/architect/fr-fr/well-architected/guide/resilient#planification-de-la-continuité), car ces deux concepts affectent la sécurité générale des données de vos solutions. ### Classification des données Identifiez et classez toutes les données stockées sur Salesforce Platform en fonction de leur nature confidentielle (p. ex. publiques, internes, confidentielles, restreintes). Définissez une **politique de classification** claire qui indique comment chaque type de données doit être traité et protégé. Mettez en œuvre les contrôles de sécurité appropriés, tels que la sécurité au niveau du champ, le cryptage et le masquage des données, pour appliquer la stratégie et protéger les données confidentielles contre tout accès ou exposition non autorisé. Examinez et auditez régulièrement ces classifications et contrôles pour vous assurer qu'ils respectent les exigences métiers et de conformité. ### Partage et visibilité Le partage et la visibilité impliquent de configurer votre système pour contrôler l'accès des utilisateurs aux données dans Salesforce. Il est important de noter que le partage et la visibilité contrôlent les enregistrements individuels auxquels un utilisateur peut accéder, mais ces paramètres ne contrôlent pas à eux seuls ce qu'un utilisateur peut faire avec un enregistrement particulier, ni les champs spécifiques de cet enregistrement qui sont visibles. Les autorisations d'exécution d'opérations sur les données (telles que [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm)) sont attribuées aux utilisateurs via des contrôles d'accès aux métadonnées, qui peuvent être configurés pour un utilisateur au niveau de l'objet individuel et du champ. Pour plus d'informations, consultez [Autorisation](/docs/architect/fr-fr/well-architected/guide/secure#autorisation). Les actions Agentforce peuvent exposer des données à des utilisateurs authentifiés et anonymes qui n'ont généralement pas directement accès. Lors de l'élaboration d'Agents Agentforce, tenez compte et documentez attentivement toutes les Actions attribuées à l'Agent. Pour chaque action, vous devez comprendre : - Les données auxquelles les Actions peuvent accéder. - Dans quel contexte de sécurité les actions sont exécutées. - Indique si les Actions ont des capacités de récupération Knowledge ou autres qui peuvent incorporer des données confidentielles ou restreintes dans la session Agent. Pour configurer un partage et une visibilité efficaces dans Salesforce : - **Concevez un accès basé sur des fonctions** significatives. Créez une matrice de sécurité qui mappe vos [utilisateurs](/docs/architect/fr-fr/well-architected/guide/secure#authentification) avec les fonctions qu'ils doivent exécuter. Utilisez ce [modèle](/docs/architect/fr-fr/resources/guide/security-policy-template) comme base pour concevoir votre partage et votre visibilité. Pour plus d'informations sur l'identification des fonctions métiers significatives, consultez [Unités fonctionnelles](/docs/architect/fr-fr/well-architected/guide/composable#unités-fonctionnelles). - **Choisissez la voie la plus simple pour appliquer le principe du moindre privilège**. En appliquant le [principe du moindre privilège](/docs/architect/fr-fr/well-architected/guide/secure#autorisation) dans la conception de schémas de partage et de visibilité, procédez de la manière la plus simple. Évitez les restrictions et les schémas de partage de données trop élaborés, qui peuvent entraîner des problèmes en aval de maintenabilité, d'évolutivité et d'adaptabilité du système. À la place, tirez parti du partage de données [flexible et superposé dans Salesforce](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf) pour configurer des règles précises d'accès des utilisateurs au niveau des données. - **Définissez les paramètres par défaut _internes_ de l'organisation (OWD) sur Accès public en lecture seule, sauf si votre entreprise traite des données confidentielles, puis utilisez Privé**. Les OWD contrôlent le niveau de « moindre » privilège des utilisateurs au niveau des données. Vous ne pouvez pas restreindre l'accès sous le niveau de votre mot de passe à usage unique. Bien que les OWD privés puissent sembler idéaux dans tous les cas d'utilisation, les utilisateurs de l'entreprise peuvent souvent se retrouver à répliquer involontairement un OWD plus permissif à travers des schémas de partage complexes. De plus, les OWD privés peuvent amener les utilisateurs à créer des données dupliquées. La réalisation des calculs de partage (et des recalculs) peut prendre un temps considérable selon le volume de données et l'asymétrie parent-enfant ou propriétaire — les OWD privés aggravent cette situation. Il est important de noter que les OWD ne contrôlent pas les autorisations CRUD et la visibilité au niveau du champ. Choisissez une OWD de Privé uniquement lorsque les besoins métiers le justifient – le plus souvent, ces justifications sont liées à [la conformité](/docs/architect/fr-fr/well-architected/guide/compliant). - **Définissez les paramètres par défaut _externes_ de l'organisation (OWD) sur Privé, sauf si vous avez des raisons professionnelles impérieuses d'accorder un meilleur accès**. [Les OWD externes](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5) s'appliquent aux utilisateurs qui accèdent aux données Salesforce à partir de sites Experience Cloud, de portails, etc. Cela permet de configurer des références OWD séparées pour les utilisateurs internes et externes, afin de permettre différents types de privilège « le moins ». Définissez toujours la valeur OWD pour les utilisateurs externes sur Privé — les exceptions pour un niveau plus ouvert doivent être clairement justifiées par les besoins métiers. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/secure#modèles-de-sécurité-des-données-et-anti-modèles) ci-dessous montre à quoi ressemble le partage et la visibilité corrects (et médiocres) dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les opportunités d'amélioration. Pour plus d'informations sur les outils de partage et de visibilité de Salesforce, consultez [Outils pertinents pour sécuriser](/docs/architect/fr-fr/well-architected/guide/secure#outils-pertinents-pour-sécuriser). ### Utilisation du cryptage Le cryptage convertit les données lisibles en un format codé et indéchiffrable. Les données cryptées peuvent être décryptées, ou traduites à leur forme d'origine, via une clé. Par conséquent, le cryptage est l'une des méthodes les plus efficaces pour sécuriser les données au repos et en transit, garantissant que même si des parties non autorisées accèdent aux données, il sera illisible. Pour concevoir une bonne utilisation du cryptage dans vos solutions Salesforce : - **Toujours crypter correctement les données en transit**. Salesforce [utilise la Sécurité de la couche de transport (TLS)](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5) pour toutes les sessions qui se déroulent dans un [navigateur pris en](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5) charge par Salesforce, et exige que les appels sortants utilisant HTTPS respectent des normes de sécurité spécifiques. Les API de plate-forme utilisent également HTTPS par défaut. De plus, les données envoyées entre un site Experience Cloud Salesforce ou un portail et son organisation Salesforce associée sont cryptées [par défaut](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5) en transit. Si vous utilisez les [services de messagerie intégrés](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5) de Salesforce, le protocole TLS (Transport Layer Security) utilisé par Salesforce pour [envoyer et tenter](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5) de livrer des e-mails existe à des niveaux par défaut. Vous devez au minimum vous assurer que les paramètres de l'organisation ne sont pas inférieurs aux paramètres par défaut, sauf si vous avez une justification métier claire. Selon la classification et la confidentialité de vos données, vous pouvez exploiter une connexion réseau privée à Salesforce via AWS Direct Connect ou Salesforce Private Connect. Vos données ne transitent pas par l'Internet public, mais transitent en toute sécurité sur une connexion réseau privée pour l'accès des utilisateurs et les intégrations. - **Si l'entreprise l'exige, cryptez les données au repos**. Salesforce offre différentes méthodes de cryptage des données au repos. - **Hyperforce**. Les données sont cryptées au repos dans les organisations qui utilisent [Hyperforce](/docs/architect/fr-fr/fundamentals/guide/platform-multitenant-architecture#hyperforce). Le cryptage est géré pour votre organisation par Salesforce. Vous ne pouvez pas créer (ou détruire) vos propres clés de cryptage. - **Salesforce Shield**... [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) permet de crypter les données au repos dans une organisation Salesforce à des couches supplémentaires, y compris les couches application et base de données. Shield offre des capacités de gestion complètes des clés de cryptage de votre locataire, notamment des options robustes « Bring Your Own Key » (BYOK). Vous pouvez également crypter des données non structurées (notamment des fichiers, des pièces jointes, des index de recherche et des événements). Les instances basées sur Hyperforce offrent la possibilité d'utiliser un gestionnaire de clés externe, ce qui permet d'apporter son propre KMS AWS. Grâce à cette capacité, vous gardez le contrôle total des clés de cryptage de votre KMS utilisées pour crypter et décrypter les données stockées dans Salesforce, ce qui renforce la sécurité et répond aux exigences de conformité de votre organisation. La liste des [modèles et anti-modèles](/docs/architect/fr-fr/well-architected/guide/secure#modèles-de-sécurité-des-données-et-anti-modèles) ci-dessous montre l'utilisation correcte (et mauvaise) du cryptage dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer, ou identifiez les opportunités d'amélioration. Pour plus d'informations sur les outils de cryptage disponibles dans Salesforce, consultez [Outils pertinents pour sécuriser](/docs/architect/fr-fr/well-architected/guide/secure#outils-pertinents-pour-sécuriser). ### Modèles de sécurité des données et anti-modèles Le tableau ci-dessous présente une sélection de schémas à rechercher (ou à élaborer) dans votre organisation et d'anti-schémas à éviter ou à cibler pour la correction. ✨ Découvrez d'autres modèles de sécurité des données dans l'[explorateur Pattern & Anti-Pattern](/docs/architect/fr-fr/well-architected-tools/guide/trusted-data-security).
Modèles Anti-Patterns
Partage et visibilité Dans vos normes de conception et votre documentation :
- Une matrice de sécurité indique les données auxquelles chaque utilisateur est autorisé à accéder
- Des normes d'accès aux données différentes sont utilisées pour les utilisateurs externes et les utilisateurs internes, si applicable
Dans vos normes de conception et votre documentation :
- Les normes de conception et la documentation n'existent pas ou ne contiennent pas de matrice de sécurité
- Si une matrice de sécurité existe, elle ne définit pas l'accès aux données pour les utilisateurs
Dans votre organisation :
- Les paramètres par défaut de l'organisation (OWD) pour les utilisateurs internes sont définis sur Accès public en lecture ou sur Privé pour les utilisateurs internes, en raison des exigences de conformité
- OWDs pour utilisateurs externes est Privé
- L'IA générative fonctionne uniquement en mode utilisateur, ou certaines utilisations pour l'accès système ont une justification métier claire
Dans votre organisation :
- OWDs pour les utilisateurs internes est défini sur Privé sans justification métier ou OWDs pour les utilisateurs internes est défini sur Accès public en lecture/écriture
- Les OWD pour utilisateurs externes sont définis sur autre chose que Privé sans justification métier
- L'IA générative fonctionne en mode système sans justification métier
Dans Apex :
- Tous les codes accédant aux données (SOQL/SOSL) ou effectuant des opérations sur les données (méthodes DML/Database Class) utilisent avec le partage de mots-clés
Dans Apex :
- avec partage les mots-clés sont utilisés de façon incohérente
Utilisation du cryptage Dans vos normes de conception et votre documentation :
- Les cas d'utilisation pour le cryptage des données en transit et (si nécessaire) au repos sont clairs et découvrables
- Les protocoles de cryptage approuvés sont clairement répertoriés
- La documentation sur le code indique clairement où le cryptage est utilisé et quels protocoles sont utilisés
Dans vos normes de conception et votre documentation :
- Les protocoles de cryptage approuvés ne sont pas clairs ou ne sont pas répertoriés
- Le code n'est pas documenté ou la documentation n'est pas claire sur l'emplacement et la façon dont le cryptage est utilisé dans le code
Dans votre organisation :
- Si des risques de sécurité sont identifiés qui nécessitent une plus grande protection des données au repos, soit Hyperforce soit Salesforce Shield assurent le cryptage au repos
Dans votre organisation :
- Les besoins métiers nécessitent une plus grande protection des données au repos, mais ni Hyperforce ni Salesforce Shield ne sont utilisés
Dans Apex :
- Si les besoins métiers nécessitent une plus grande protection des données en transit, tout le code impliqué dans l'intégration exécute une logique en utilisant des méthodes Classe Crypto pour crypter les données avant transmission ou décrypter les données dès réception
Dans Apex :
- Les besoins métiers nécessitent une plus grande protection des données en transit, mais le code impliqué dans l'intégration exécute une logique sans cryptage des données avant la transmission ou à la réception, ou des méthodes de classe Crypto sont utilisées ad hoc
## Outils pertinents pour sécuriser
OutilDescriptionSécurité organisationnelleSécurité de la sessionSécurité des données
Apex Crypto ClassCrypter et décrypter les données dans ApexX
Contrôle d'accès APIGérer l'accès à vos API Salesforce et applications connectéesX XX
Événement d'anomalie d'APISuivre les anomalies dans les appels d'API des utilisateursX
Paramètres de sécurité du navigateurProtéger les données confidentielles et surveiller les certificats SSLX
Authentification basée sur le certificatAuthentifier des individus avec des certificats numériques uniquesXX
Certificats et clésVérifier les requêtes à des sites Web externes depuis SalesforceXX
Scanner de codeScanner le code Apex pour détecter les failles de sécuritéXX
Applications connectéesIntégration via des API et des protocoles standardXX
Événement de bourrage d'identifiantsSuivre les tentatives de connexion qui utilisent des identifiants utilisateur volésX
Site de confiance CSPEmpêcher les attaques par injection de code (c.-à-d. script inter-site)X
Flux de connexion personnalisésContrôler les processus métiers de connexion pour les utilisateursX
Identité du clientContrôler les connexions et la vérification des sites Web et des applicationsX
Data MaskMasquer automatiquement les données confidentielles dans les organisations sandboxX
Journaux de débogageSuivre les événements qui se produisent dans votre organisationX
Administration déléguéeAttribuer des privilèges administratifs limités aux utilisateurs non administrateursXX
Activation de l'appareilVérifier les connexions à partir de navigateurs, appareils ou plages IP non approuvésX
Sécurité des transactions avancéeIntercepter les événements, surveiller et contrôler l'activité des utilisateursX
Accès aux champsContrôler l'accès aux données au niveau du champX
Piste d'audit des champsDéfinir une stratégie pour conserver les données historiques des champs archivésX
Suivi de l'historique des champsSuivre et afficher l'historique des champsX
Frontdoor.jspAutoriser l'accès avec un ID de session et une URL de serveur existantsX
Heroku ConnectSynchronisation bidirectionnelle entre Heroku et SalesforceX
Heroku ShieldÉlaborer des applications conformes HIPAA ou PCIX
Sécurité de la session Assurance élevéeDemander une sécurité supplémentaire pour les opérations confidentiellesX
Identity ConnectMapper des enregistrements utilisateur avec des comptes Active DirectoryX
Historique de vérification de l'identitéAudit des tentatives de vérification de l'identité des utilisateursX
Licence utilisateur IntegrationAccordez l'accès aux données et aux fonctionnalités uniquement via l'API.XX
Lightning LoginEmpêcher les mots de passe faibles ou oubliés et les comptes verrouillésX
Accès à la connexionAutoriser les utilisateurs de support à se connecter au nom d'un autre utilisateurX
Login ForensicsIdentifier le comportement qui peut indiquer une usurpation d’identitéX
Historique des connexionsSurveiller les tentatives de connexion à une organisation et à un site Experience CloudX
Suivi des appareils mobilesSuivre et surveiller l'accès des appareils mobiles à votre organisationX
Mobile SDKConnexion à Salesforce Platform dans des applications mobiles autonomesXXX
Surveiller les autorisations utilisateur (Shield)Modifications de l'ensemble d'autorisations et du groupe d'ensembles d'autorisationsXX
Authentification multifacteurDemander deux méthodes de vérification ou plus pour la connexionXX
Authentification mutuelleForcer l'authentification mutuelle SSL ou TLS
Mon domaineConfigurer des pages et des stratégies de connexion, des connexions SSO et socialesX
Identifiants nommésSpécifier des URL de point de terminaison et des paramètres d’authentificationX
Autorisation OAuthAutoriser l'accès à l'application cliente via un échange de jetons X
Stratégies de mot de passeDéfinir l'historique, la longueur et la complexité du mot de passeX
Expiration de l'attribution d'ensembles d'autorisationsDéfinir des expirations pour les attributions d'ensembles d'autorisations et de groupes d'ensembles d'autorisationsXX
Événement d'ensemble d'autorisationsSurveiller les modifications apportées aux ensembles d'autorisations et aux groupes d'ensembles d'autorisationsXX
Groupes d'ensembles d'autorisationsEnsembles d'autorisations d'empaquetage pour prendre en charge des exigences d'accès complexesX
Ensembles d'autorisationsContrôler l'accès des utilisateurs aux métadonnées, aux fonctionnalités et aux applicationsX
Private ConnectIntégrations sécurisées entre Salesforce et Amazon Web ServicesX
ProfilsContrôler les plages IP de connexion et les heures de connexionX
Surveillance des événements en temps réelSurveillance et détection des événements standard dans Salesforce X
Paramètres du site distantEnregistrer des sites externes pour des appels Apex ou JavaScriptX
Événement d'anomalie de rapportSuivre les anomalies dans l'exécution ou l'exportation de rapports par les utilisateursX
Règles de restrictionEmpêcher les utilisateurs d'accéder aux enregistrements inutilesX
Salesforce Code AnalyzerScannez le code via IDE, CLI ou CI/CD pour vous assurer qu'il respecte les meilleures pratiquesXX
Règles d'étendueContrôlez les enregistrements par défaut que vos utilisateurs peuvent afficherX
Centre de sécuritéVisualisez les paramètres de sécurité dans toutes vos organisations et configurez des alertes pour les changements de postureXX
Contrôle d'intégrité de sécuritéIdentifier les vulnérabilités dans vos paramètres de sécuritéX
Événement de piratage de sessionIdentifier les accès non autorisés via des identifiants de session volésX
Classe de gestion des sessionsPersonnaliser les paramètres de sécurité d'une session activeX
Paramètres de sécurité de sessionConfigurer des sessions de protection contre les attaques malveillantesX
Piste d'audit de configurationSuivre les récentes modifications de configuration effectuées par les administrateursX
Paramètres de partageContrôler l'accès aux données au niveau de l'enregistrementX
B Shield Platform EncryptionCryptage des données confidentielles au repos et en transitX
Authentification uniqueAccorder l'accès à plusieurs applications via une seule connexionXX
Système de gestion des identités inter-domaines (SCIM)Gérer les identités entre les systèmes via des API RESTX
Détection des menacesUtiliser les statistiques et l'apprentissage machine pour détecter les menacesX
Plages IP approuvéesDéfinir des adresses IP qui ne nécessitent aucune vérification supplémentaireX
Rapport sur l'accès utilisateurObtention d'une vue unifiée de l'accès aux objets, aux enregistrements et aux autorisations de vos utilisateursXX
## Ressources pertinentes pour sécuriser
RessourceDescriptionSécurité organisationnelleSécurité de la sessionSécurité des données
Guide d'architecture de partageEn savoir plus sur les outils d'accès, les modèles de partage et les cas d'utilisationX
Modèle Design StandardsCréer des normes de conception pour votre organisationXXX
Comment élaborer un modèle de sécurité utilisateurMeilleure compréhension des modèles de sécurité utilisateurXX
Comment implémenter le principe du moindre privilège dans SalesforceApprentissage de l'application des contrôles d'accès aux données PoLP dans SalesforceXX
Surveiller les sessions utilisateurExaminer les sessions actives et mettre fin aux sessions suspectesX
Authentification multifacteurAccéder aux ressources MFA officielles depuis SalesforceX
Groupes d'ensembles d'autorisations (Trailhead)Pratique des groupes d'ensembles d'autorisationsXX
Architecture REST APIComprendre les termes et concepts de l'API RESTXXX
Sécurité et API SOAPCompréhension des termes et concepts de l'API SOAPXXX
Meilleures pratiques de sécurité pour les utilisateurs d'API et de système interneSécuriser l'accès des utilisateurs d'API et des utilisateurs système internes à SalesforceX
Guide d'implémentation de la sécuritéExaminez une vue complète de Salesforce SecurityXXX
Modèle de politique de sécuritéDéfinition de stratégies de sécurité pour votre organisationXXX
Types de sessionIdentifier les types de session utilisés pour accéder à votre organisationX
Concepts fondamentaux de la modélisation des menaces (Trailhead)Découvrez les menaces de sécurité et comment les prévenir.X
## Dites-nous ce que vous pensez Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre [sondage](https://sfdc.co/bxNtvh) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite. ## Introduction Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable Salesforce Well-Architected Framework vous montre à quoi ressemble la santé et où passer votre temps à cartographier et concevoir des solutions avec Salesforce Customer 360 Platform. Il partage des conseils prescriptifs et des exemples de schémas et d'anti-schémas à rechercher dans votre paysage, basés sur Knowledge des équipes produits et des experts en implémentation dans Salesforce et notre écosystème. Salesforce Well-Architected est organisé pour vous aider à élaborer des solutions fiables, faciles et adaptables. Des solutions **de confiance** protègent les parties prenantes.
Les solutions **faciles** offrent rapidement de la valeur.
Les solutions **adaptables** évoluent avec l'entreprise.
Salesforce Well-Architected est conçu pour vous aider à franchir les étapes de la réflexion architecturale requise pour élaborer des solutions saines sur Customer 360 Platform. Un défi unique pour les architectes qui créent des solutions avec Salesforce est la flexibilité fondamentale de la plate-forme. Une solution peut étendre une solution prédéfinie offerte par Salesforce (c.-à-d. Sales Cloud, Service Cloud, différentes verticales Industries Cloud). Une autre solution peut être une application entièrement personnalisée. Ce que vous pouvez faire avec Salesforce est vaste et profond, et les choix technologiques spécifiques les plus adaptés à votre implémentation dépendront des besoins métiers. Il peut être extrêmement difficile de déterminer ce qui créera les meilleures chances de santé à long terme pour chaque solution Salesforce possible. Salesforce Well-Architected fournit des connaissances et des conseils d'architectes hautement expérimentés selon vos besoins. Vous pouvez utiliser les opinions et les recommandations pour valider (ou remettre en question) votre réflexion, et recueillir des connaissances sur les domaines à prendre en considération ou la technologie qui peut être nouvelle pour vous. Il peut également être difficile de comprendre s'il existe des repères architecturaux communs à toutes les solutions saines, compte tenu de la grande diversité des implémentations. Chez Salesforce, tout ce que nous faisons en tant qu'entreprise et en tant que personnes est guidé par nos valeurs fondamentales. Nous pensons que cela peut également s'appliquer à l'architecture. C'est pourquoi Salesforce Well-Architected s'appuie sur une base de confiance, facile et adaptable. En évaluant des détails architecturaux complexes et des compromis, vous pouvez revenir à ces capacités de base et les utiliser comme points de boussole pour guider votre prise de décision. Vous trouverez ci-dessous des détails sur des thèmes individuels à explorer dans notre infrastructure approuvée, facile et adaptable. ## Organisation des rubriques Nous utilisons deux niveaux pour organiser les informations dans Salesforce Well-Architected. Le niveau supérieur est ce que devraient être des solutions bien architecturées: Confiance, facilité et adaptabilité. Le deuxième niveau approfondit les considérations, les schémas à élaborer (ou les anti-schémas à éviter) et les directives relatives à des aspects spécifiques des solutions approuvées, faciles et adaptables. L'alignement de vos conceptions sur les conseils fournis dans ce cadre devrait favoriser une meilleure qualité et une santé plus durable dans vos applications Salesforce Customer 360. 💡 Vous voulez commencer avec des modèles et des anti-modèles rapidement? Visitez l'[explorateur Pattern & Anti-Pattern](/docs/architect/fr-fr/well-architected-tools/guide/patterns). Vous pouvez voir ci-dessous une vue d'ensemble de l'organisation des rubriques :
Confiance
Une solution de confiance protège votre entreprise et vos parties prenantes.
Sécurisé Conforme Fiable
Sécurité organisationnelle
Sécurité de la session
Sécurité des données
Adhésion juridique
Normes éthiques
Accessibilité
Disponibilité
Performances
Évolutivité
Facile
Une solution simple offre rapidement de la valeur métier.
Intentional Automatisé Engagement
Stratégie
Maintenabilité
Lisibilité
Efficacité
Intégrité des données
Rationalisation
Utile
Adaptable
Une solution adaptable évolue avec votre activité.
Résilient Composable
Gestion du cycle de vie des applications
Réponse à l'incident
Planification de la continuité
Séparation des préoccupations
Interopérabilité
Emballage