Équité

Dans les architectures Salesforce, l’équité signifie élaborer des solutions qui servent équitablement les utilisateurs à travers des interfaces accessibles, la détection et l’atténuation des biais, des décisions transparentes et une gouvernance éthique. Les prédictions Einstein influencent les résultats qui affectent les clients et les employés, ce qui signifie que les architectes devraient concevoir des systèmes qui produisent des résultats équitables à travers les groupes démographiques tout en restant accessibles aux utilisateurs handicapés.

Salesforce fournit des capacités de plate-forme spécialement conçues pour l’équité, et nous nous efforçons de nous conformer à WCAG 2.2 AA. Lorsqu’il est utilisé correctement, le système de conception Salesforce Lightning (SLDS) fournit des composants conçus pour soutenir cet objectif. Examinons de plus près chaque composant.

Shield Platform Encryption protège les attributs sensibles tels que les données démographiques, et Event Monitoring fournit les pistes d’audit qui prennent en charge le traitement transparent des données.
Einstein Trust Layer (ETL) capture un journal d’audit sécurisé pour les invites et les réponses d’IA générative à des fins de surveillance et de conformité.
Experience Cloud inclut des contrôles d’accessibilité.
Le Journal d’audit des champs fournit une rétention à long terme de l’historique des modifications des données au niveau du champ, qui prend en charge la responsabilité algorithmique lorsque les données de décision IA sont stockées dans des champs suivis.

Ces capacités permettent de réduire les coûts opérationnels des pratiques d’équité de Salesforce.

Chez Salesforce, l’équité s’articule autour de trois dimensions pour apporter des solutions. La conception inclusive permet de rendre les Composants Web Lightning (LWC), les pages Visualforce et les sites Experience Cloud entièrement accessibles, grâce à une navigation au clavier transparente, à la compatibilité des lecteurs d’écran et à des aménagements de conception cognitive. Les pratiques d’équité en IA aident les prédictions Einstein à produire des résultats équitables en utilisant la détection des biais, diverses données d’entraînement et une surveillance continue. La gouvernance fournit les processus et les contrôles nécessaires pour maintenir l’équité à mesure que les modèles évoluent et que les cas d’utilisation se développent.

Négliger l’équité crée un risque supplémentaire. Les sites Experience Cloud inaccessibles peuvent exposer les organisations à des litiges en vertu de l’Americans with Disabilities Act (ADA) et, pour les organismes fédéraux et leurs sous-traitants, à des infractions à l’article 508 du Règlement. Selon la classification des risques du système et les nouvelles lois algorithmiques sur la responsabilité, les prédictions Einstein biaisées peuvent enfreindre les exigences de la loi IA de l’UE. Les décisions exclusivement automatisées pilotées par l’IA ayant des effets juridiques ou similaires importants, qui manquent d’informations significatives sur la logique de décision, peuvent violer les droits à l’information de l’article 22 et de l’article 15(1)h) du RGPD.

Les organisations qui œuvrent en faveur de l’équité ont tendance à réduire les dommages prévisibles pour les clients, les employés et les communautés affectés par leurs systèmes. Les manquements à l’équité peuvent causer des dommages tangibles et matériels aux personnes touchées, notamment des dommages économiques, des opportunités refusées, une détresse émotionnelle et le renforcement de la discrimination systémique. L’harmonisation réglementaire a tendance à découler du fait qu’elle sert bien les personnes touchées.

Utilisez ces principes pour guider vos décisions architecturales en matière d’équité sur la plate-forme.

Concevez des modèles d’accessibilité Lightning. Lors de l’élaboration, utilisez dans la mesure du possible le système de conception Lightning et les composants Web Lightning standard conçus pour prendre en charge l’accessibilité WCAG 2.2 AA. Lorsque vous élaborez avec SLDS, vous tirez parti d’une bibliothèque où l’accessibilité est un principe de conception de base. Les composants SLDS font l’objet d’une vérification de l’accessibilité du clavier et de la compatibilité avec les technologies d’assistance, et beaucoup incluent une section Accessibilité avec des conseils pour développeur. Si un composant personnalisé est requis, l’implémentation WAI-ARIA (Accessible Rich Internet Applications), le code HTML sémantique et les schémas de navigation clavier explicites doivent être validés par des tests de technologie d’assistance.
Réduisez et surveillez les biais avec les outils adaptés à chaque type de modèle. Valider les résultats IA pour des résultats équitables entre les groupes démographiques avant le déploiement et en production continue. Pour des modèles prédictifs, capturez des données de décision via Einstein Discovery et une instrumentation personnalisée et analysez-les dans CRM Analytics pour mesurer des métriques d’équité; pour l’IA générative et les fonctionnalités Agentforce, utilisez le journal d’audit ETL (Einstein Trust Layer) des invites et des réponses. Documenter les décisions pour satisfaire aux exigences réglementaires de transparence.
Exploiter Shield Platform Encryption pour les contrôles de protection des données. Utilisez Shield Platform Encryption avec des schémas déterministes pour les attributs sensibles qui nécessitent des requêtes de correspondance exacte tout en protégeant les données personnelles. Acheminez les journaux de Surveillance des événements vers un système SIEM (Security Information and Event Management) externe pour prendre en charge les pistes d’audit inviolables, lorsque le SIEM applique une ségrégation en écriture unique du stockage et de l’accès qui dépasse les fenêtres de rétention natives de Salesforce pour les réglementations requises.
Concevez des workflows de révision pour des prédictions à fort enjeu. Configurez des processus d’approbation et des mécanismes de révision dans Salesforce Flow pour vous assurer que les prédictions Einstein affectant les décisions corrélatives font l’objet d’un examen humain approprié. Utilisez des seuils de confiance et des règles métiers pour déterminer quand les prédictions doivent être validées avant d’agir.
Appliquer les paramètres par défaut de l’organisation (OWD) et la sécurité au niveau du champ (FLS) pour la non-discrimination. Architectez les modèles d’accès aux données en utilisant OWD et FLS pour restreindre l’accès par défaut, et accordez uniquement l’accès supplémentaire dont chaque rôle a besoin en utilisant des règles de partage. Évitez d’accorder aux profils un accès excessif qui pourrait exposer des attributs confidentiels et permettre une prise de décision discriminatoire.
Activez l’agence utilisateur avec le consentement de la plate-forme. Utilisez les capacités de gestion du consentement dans Data 360 ou des objets de consentement personnalisés avec le Journal d’audit des champs pour suivre un consentement IA précis par cas d’utilisation. Permettez aux utilisateurs de se désabonner des fonctionnalités pilotées par l’IA et offrez des alternatives humaines (si possible).

Les décisions de l’architecture de données déterminent les populations qui deviennent visibles et invisibles dans les systèmes Salesforce. La mauvaise qualité des données n’est pas uniquement un problème technique. L’équité devient un problème lorsque les écarts dans les données désavantagent systématiquement des groupes démographiques spécifiques.

Vérifiez les champs obligatoires pour la disponibilité des données. Lorsque les champs obligatoires supposent que les informations disponibles varient selon les données démographiques, l’exhaustivité des données devient discriminatoire. Les utilisateurs qui ne peuvent pas fournir les informations requises deviennent invisibles dans les systèmes qui rejettent les enregistrements incomplets.
- L’exigence d’adresses e-mail exclut les populations qui n’ont pas un accès Internet fiable ou des adresses e-mail personnelles.
- L’exigence de numéros de sécurité sociale américains (SSN) exclut les clients internationaux et les immigrants récents qui n’ont pas encore reçu de SSN.
- L’exigence d’adresses postales exclut les populations sans domicile fixe et les utilisateurs qui ont des adresses non traditionnelles.
Vérifier les justifications métiers des champs obligatoires. Pour chaque champ obligatoire, il est important de documenter les raisons pour lesquelles les informations sont obligatoires plutôt que facultatives. Si les processus peuvent fonctionner sans certaines données via d’autres approches, rendez ces champs facultatifs et concevez des systèmes pour gérer gracieusement les valeurs manquantes. Cela permet de s’assurer que les utilisateurs qui ne peuvent pas fournir ces données ne sont pas exclus.

Les champs de nom qui suivent les conventions de nommage occidentales (Prénom, Nom) peuvent exclure des cultures avec des pratiques de nommage différentes.

De nombreuses cultures utilisent :

Noms uniques (ou mononymes) sans nom de famille
Systèmes de patronyme où le “nom” change de génération en génération
Prénoms ou noms de famille multiples
Noms qui changent en fonction des événements de vie ou du contexte social
Noms où « premier » et « dernier » sont des distinctions culturellement vides de sens

Concevez une architecture de noms en utilisant un seul champ de nom complet ou une structure flexible en plusieurs parties qui respecte les conventions de nommage courantes. Évitez de faire des hypothèses sur l’ordre des noms, les modèles d’héritage ou les normes culturelles.

Testez l’architecture des noms en utilisant divers noms internationaux pour vous assurer que les champs de nom acceptent :

Noms à mot unique (par exemple, Sukarno, Cher et Teller)
Noms longs qui dépassent les limites de longueur de champ courantes
Noms avec diacritiques, apostrophes, tirets et espaces
Noms avec des écritures non latines (par exemple, arabe, chinois, cyrillique et devanagari)

Lorsque la validation du nom rejette le nom légitime d’un utilisateur, il rencontre un rejet système basé sur son identité culturelle.

Les services de validation d’adresse sont souvent optimisés pour les formats aux États-Unis et en Europe de l’Ouest et ne reconnaissent souvent pas :

Formats d’adresse internationale avec différents ordres de champ
Adresses rurales sans nom de rue
Adresses militaires (par exemple, APO et FPO)
Boîtes postales et autres lieux de livraison
Terres tribales avec des systèmes d’adresse uniques
Pays avec des écritures non latines pour les composants d’adresse

Lorsque les validations d’adresse rejettent les formats d’adresse non traditionnels, elles empêchent la création de comptes, l’expédition et la livraison de services pour les utilisateurs dont l’adresse ne correspond pas aux attentes de la base de données de validation.

Voici quelques méthodes pour concevoir des validations d’adresse en tenant compte de l’accessibilité :

Implémentez la validation d’adresse permissive.
Acceptez la saisie d’adresse en forme libre lorsque les validations structurées échouent.
Stockez les adresses telles qu’elles sont saisies par les utilisateurs au lieu de les forcer à apporter des corrections non valides.
Utilisez la validation de l’adresse pour l’enrichissement des données et la détection des duplications, pas pour valider la mise en forme des adresses.

Au lieu de bloquer les captures de données à l’avance, intégrez la vérification de l’adresse dans des processus d’exécution où la précision de l’adresse est importante sur le plan opérationnel.

Les hypothèses d’accès universel pour des canaux de communication spécifiques excluent les populations qui ont des préférences ou un accès technologique différent.

La communication par e-mail exclut :

Utilisateurs sans accès fiable à Internet
Populations âgées moins à l’aise avec l’utilisation de la messagerie
Utilisateurs dans les régions où les applications SMS ou de messagerie sont la principale méthode de communication

La communication par téléphone exclut :

Utilisateurs sourds et malentendants
Utilisateurs sans accès téléphonique ou ceux utilisant des téléphones partagés

Concevez une architecture de communication omnicanal qui permet aux utilisateurs de contrôler les préférences de canal. Stockez les méthodes de communication préférées dans les enregistrements Contact et respectez systématiquement les préférences de tous les systèmes de communication sortants. Offrez diverses alternatives de communication au lieu de supposer que les méthodes à canal unique fonctionnent universellement.

La collecte de données démographiques pour la surveillance de l’équité nécessite une architecture soignée afin d’éviter tout abus.

La collecte et le traitement des données démographiques dépendent de la juridiction et sont soumis à des restrictions légales (dans l’UE, l’article 9 du RGPD les traite comme des données de catégorie spéciale nécessitant une base juridique spécifique ; aux États-Unis, la surveillance des biais repose généralement sur l’auto-identification volontaire des OEE). Lorsqu’il existe une base légale, les organisations utilisent des données démographiques pour :

Surveiller les métriques d’équité stratifiées par groupes protégés
Détecter les biais dans les systèmes d’automatisation et d’IA
Démontrer la conformité réglementaire aux exigences antidiscrimination

La collecte de données démographiques entraîne certains risques :

Les données peuvent être utilisées à des fins discriminatoires si les contrôles d’accès échouent
Les utilisateurs peuvent se méfier des méthodes de collecte et fournir des données imprécises
La collecte peut sembler envahissante ou discriminatoire

Organisez l’auto-identification volontaire et concevez la collecte de données démographiques en utilisant les informations suivantes :

Explicité clairement dans un but transparent (par exemple, surveillance de l’équité ou rapports sur la conformité)
Volontaire et inclut une option « Préférer ne pas répondre » toujours disponible
Séparé des données opérationnelles avec un FLS strict pour empêcher un accès inapproprié
Agrégé pour les rapports et les analytiques et non lié à des décisions individuelles
Surveillé via Shield Event Monitoring pour l’audit du schéma d’accès

Il est important de documenter dans les politiques de confidentialité comment les données démographiques seront utilisées et ne seront pas utilisées. Violer la Trust des utilisateurs en utilisant des données non divulguées peut gravement nuire à la crédibilité, ce qui peut s’avérer difficile à récupérer.

L’enrichissement de données tierces qui ajoute des données démographiques, firmographiques ou comportementales à des enregistrements Salesforce peut introduire des biais via :

Inférences inexactes basées sur des stéréotypes
Couverture incomplète avec des écarts corrélés aux données démographiques
Algorithmes propriétaires qui utilisent des propriétés d’équité inconnues
Données provenant d’enregistrements historiques biaisés

Avant d’implémenter des services d’enrichissement des données, il est important d’auditer :

Tests d’équité des fournisseurs et pratiques d’atténuation des biais
Couverture et précision des données entre les groupes démographiques
Méthodes et fonctionnalités d’inférence utilisées pour créer des prédictions
Restrictions contractuelles d’utilisation des données et stratégies de rétention

Notez que lorsque des données tierces entrent dans votre organisation Salesforce, elles peuvent affecter les décisions, créant des biais introduits par le fournisseur qui se reflètent également dans votre organisation.

Dans les contextes Salesforce, l’accessibilité désigne l’architecture de composants Web Lightning, de pages Visualforce et de sites Experience Cloud qui fonctionnent pour les utilisateurs handicapés. Les composants Lightning standard offrent une accessibilité de base lorsqu’ils sont correctement utilisés; cependant, le développement personnalisé et la configuration Experience Cloud nécessitent une implémentation explicite de l’accessibilité.

Les composants Lightning Design System sont conçus pour prendre en charge la conformité WCAG 2.2 AA lorsqu’ils sont utilisés tels que conçus. Salesforce s’efforce d’obtenir une conformité totale, mais ne la certifie pas. S’écarter des modèles SLDS ou élaborer des composants personnalisés sans tenir compte de l’accessibilité crée des obstacles pour les utilisateurs handicapés.

Les composants Web Lightning standard offrent une accessibilité intégrée. Les composants tels que Lightning, Lightning, Lightning et Lightning contiennent automatiquement les attributs ARIA appropriés, les associations d’étiquettes, la navigation au clavier et la gestion du focus. Dans la mesure du possible, utilisez des composants standard plutôt que d’élaborer des alternatives personnalisées qui se ressemblent, mais qui peuvent ne pas avoir l’infrastructure d’accessibilité appropriée.

Utiliser le code HTML sémantique dans des composants Web Lightning personnalisés. Lors de l’élaboration de composants personnalisés, utilisez des éléments HTML sémantiques (<en-tête>,
,
,
,
,
) plutôt que des composants
imbriqués de façon confuse. Les lecteurs d’écran utilisent la structure sémantique pour transmettre l’organisation des pages et activer la navigation dans les repères. Évitez d’utiliser un balisage purement visuel qui retire un sens de la hiérarchie des contenus.
Implémentez ARIA dans des composants personnalisés. Appliquez des repères, des rôles et des propriétés ARIA lorsque le code HTML sémantique ne peut pas transmettre le comportement de l’interface. Les mises à jour de contenu dynamiques nécessitent des zones aria-live qui annoncent les modifications apportées aux lecteurs d’écran. Les composants interactifs personnalisés nécessitent des définitions de rôle explicites adaptées à leur comportement. Les composants de base Lightning gèrent automatiquement ARIA ; cependant, les composants personnalisés nécessitent une validation manuelle ARIA via un test de lecteur d’écran.
Essai avec une technologie d’assistance : Validez les composants Lightning en utilisant des lecteurs d’écran réels (par exemple, JAWS et NVDA pour Windows, VoiceOver pour macOS et iOS, et TalkBack pour Android). D’après l’étude à grande échelle de Deque, les outils automatisés tels que la hache-noyau capturent environ 57 % des problèmes d’accessibilité en volume. Les autres problèmes nécessitent des tests manuels avec une technologie d’assistance par des personnes qui comprennent les modèles de navigation des lecteurs d’écran.
Utilisez la gestion du focus dans des flux Lightning. Lorsque des fenêtres modales s’ouvrent, que des contenus dynamiques sont chargés ou que des utilisateurs terminent des flux à plusieurs étapes, vous devez gérer le focus par programmation pour guider les utilisateurs de clavier vers de nouveaux contenus. Les composants Lightning modaux et contextuels fournissent une gestion de base du focus, mais les flux complexes nécessitent une logique explicite de focus pour déplacer le focus de façon appropriée à mesure que le contenu change.

Les sites Experience Cloud desservent des utilisateurs externes, notamment des clients, des partenaires et des audiences publiques, qui nécessitent une conception accessible pouvant répondre aux exigences de l’ADA, de la section 508 et/ou de la loi européenne sur l’accessibilité (selon la juridiction, l’audience et le type d’organisation).

Utilisez des modèles accessibles. Les modèles Experience Cloud élaborés en utilisant Lightning Web Runtime (LWR) incluent l’accessibilité de base. Les modèles standard tels que Portail de compte client et Centre d’aide fournissent les bases WCAG 2.2 AA lorsqu’ils sont correctement configurés. Les modèles personnalisés nécessitent une implémentation explicite de l’accessibilité, notamment le balisage sémantique, la navigation au clavier et la compatibilité avec le lecteur d’écran.
Vérifiez la conformité WCAG dans le thème. Les thèmes personnalisés et les sites de marque nécessitent une validation par contraste de couleur. Les paramètres Thème du Générateur d’expérience contrôlent les couleurs, la typographie et l’espacement. Assurez-vous que tout le texte respecte le contraste 4,5:1 pour le texte normal (moins de 18pt pour le texte normal ou moins de 14pt pour le texte gras), et 3:1 pour le texte volumineux (18pt ou plus pour le texte normal ou 14pt ou plus pour le texte gras) et les composants de l’interface utilisateur. Utilisez des outils de développement de navigateur ou des contrôleurs de contraste en ligne pour valider la conformité. Testez le zoom du navigateur à 200 % pour vous assurer que le texte s’adapte sans perdre de contenu ou de fonctionnalité.
Utilisez la navigation au clavier dans les menus de navigation. Les composants de navigation Experience Cloud doivent prendre en charge le fonctionnement au clavier uniquement sans dépendance à la souris. Les utilisateurs doivent naviguer dans et hors des menus déroulants, des méga menus et de la navigation aérienne en utilisant les touches Tabulation, Entrée, Échap et Flèche sans piège de focus. Testez tous les chemins de navigation en utilisant uniquement le clavier pour valider l’accessibilité.
Activez l’accessibilité des formulaires dans Experience Cloud. Associez explicitement des étiquettes à toutes les entrées de formulaire en utilisant les éléments label appropriés ou aria-labelledby. À lui seul, le texte de l’espace réservé ne satisfait pas aux exigences d’accessibilité, car il disparaît dès que la saisie des données commence, ce qui laisse les utilisateurs de lecteurs d’écran sans contexte permanent suffisant. Les composants d’entrée Lightning fournissent une association d’étiquette intégrée lorsqu’ils sont configurés en utilisant les attributs d’étiquette requis. Les formulaires Visualforce personnalisés nécessitent une association étiquette-saisie explicite.
Testez les sites Experience Cloud en utilisant une technologie d’assistance. Avant de lancer des sites Experience Cloud accessibles au public, vous devez effectuer des tests d’accessibilité complets en utilisant des lecteurs d’écran, la navigation clavier uniquement et le zoom du navigateur. Il est important d’inclure les utilisateurs handicapés dans les tests d’utilisation afin de révéler les obstacles pratiques et vécus que les examens d’experts peuvent souvent manquer. Tester uniquement les pages Lightning internes sans valider l’accessibilité Experience Cloud externe rend les sites publics vulnérables aux plaintes et litiges relatifs à l’accessibilité.
Utilisez un texte alternatif pour les images et les icônes. Toutes les images, icônes et contenus graphiques informatifs dans Experience Cloud nécessitent un texte alt. Les images décoratives utilisent un texte alt vide (alt=""), qui permet aux lecteurs d’écran de les ignorer. Les images informatives fournissent un texte alt significatif qui décrit le contenu et la fonction. Lorsque vous écrivez un texte alt pour des icônes, mettez l’accent sur l’action ou l’objet de l’icône plutôt que sur son aspect visuel (par exemple, au lieu de décrire une icône de loupe comme « loupe », le texte alt doit indiquer son utilité fonctionnelle, par exemple « Site de recherche »). Lors de la gestion des images, le CMS doit inviter les auteurs de contenu à saisir un texte alt ou à marquer explicitement l’image comme décorative (qui définit alt=""). Cela garantit l’accessibilité en empêchant le texte alt manquant et les descriptions forcées pour les images esthétiques.

L’accessibilité complète au clavier signifie que les utilisateurs peuvent accéder à toutes les fonctionnalités en utilisant leur clavier sans avoir à interagir avec la souris ou le toucher à aucun moment.

Utilisez l’ordre de focus logique dans les pages Lightning. Assurez-vous que l’ordre de focus suit la présentation visuelle et le flux d’interaction. Lorsque les utilisateurs appuient sur Tabulation, le focus visuel doit parcourir les éléments interactifs dans l’ordre dans lequel ils s’attendent en fonction de la conception visuelle. Le Générateur d’applications Lightning et le Générateur d’expérience établissent un ordre de focus basé sur l’emplacement des composants. Les composants personnalisés nécessitent une gestion explicite des tabindex pour garantir une progression logique du focus.
Utilisez des indicateurs de focus visibles pour satisfaire aux exigences de contraste. Lightning Design System fournit des styles de focus pour répondre aux exigences WCAG de la plupart des composants. Les composants personnalisés peuvent avoir besoin d’indicateurs de focus avancés pour satisfaire à l’exigence de contraste 3:1 par rapport au contenu environnant. Les indicateurs de focus doivent être clairement visibles pour permettre aux utilisateurs malvoyants de naviguer avec le clavier. Ne retirez jamais les indicateurs de focus avec CSS (plan : none) sans fournir un style alternatif de focus visible.
Utilisez des mesures d’atténuation du piège clavier dans les fenêtres modales et les superpositions. Les dialogues modaux doivent emprisonner le focus dans la fenêtre modale lorsqu’elle est ouverte, ce qui empêche les utilisateurs de clavier d’accéder à un contenu en arrière-plan masqué. Le piège du focus doit être relâché lors de la fermeture de la fenêtre modale et renvoyer le focus vers l’élément déclencheur. Le contenu incorporé, y compris les iframes et les widgets tiers, ne doit pas capturer définitivement le focus clavier sans mécanisme d’échappement.
Utilisez des touches de raccourci sans conflit. Lightning fournit des raccourcis clavier standard qui sont documentés dans l’aide de Salesforce. Les raccourcis clavier personnalisés doivent être conçus pour éviter les conflits avec les commandes standard du navigateur et les commandes de navigation du lecteur d’écran. Conformément aux critères de réussite du WCAG, les raccourcis à un caractère (par exemple, appuyer sur une seule lettre ou un signe de ponctuation) ne doivent pas déclencher d’actions globales. Ils doivent limiter l’activation au moment où un composant spécifique a le focus actif, ou fournir aux utilisateurs un moyen de désactiver ou de remapper entièrement le raccourci.

Intégrez la validation de l’accessibilité dans les pipelines CI/CD afin de détecter automatiquement les problèmes structurels à chaque déploiement, plutôt que de traiter l’accessibilité comme des audits manuels périodiques.

Utilisez sa11y pour les tests d’accessibilité des composants Web Lightning. Les bibliothèques sa11y de Salesforce (le package @sa11y/jest) enveloppent le moteur d’accessibilité de base de la hache afin d’ajouter un mappeur toBeAccessible() pour les tests unitaires Jest. Écrivez automatiquement des tests d’accessibilité qui valident l’utilisation correcte d’ARIA, les associations d’étiquettes, les rapports de contraste et le balisage sémantique dans le cadre de tests unitaires. Configurez l’échec des builds lorsque des problèmes d’accessibilité critiques sont détectés.
Utilisez Lighthouse CI pour Experience Cloud. Google Lighthouse audite l’accessibilité des pages Web, y compris les sites Experience Cloud. Intégrez Lighthouse CI dans des pipelines de déploiement pour analyser les problèmes d’accessibilité dans les pages publiques. Configurez des seuils de score pour demander des scores d’accessibilité minimum avant les approbations de déploiement.
Utilisez l’agent d’accessibilité, disponible via le package Salesforce DX MCP. Dans les environnements compatibles MCP ou dans Agentforce Vibes, il examine le code par rapport aux normes WCAG, expose les correctifs ciblés et peut générer une requête d’extraction pour qu’un ingénieur puisse réviser, valider et fusionner.

Les biais existaient dans l’automatisation déterministe de Salesforce bien avant que l’IA n’entre en scène. Les règles d’attribution, les décisions de flux, les règles de validation et la conception de territoires codent le jugement humain qui peut perpétuer la discrimination. Contrairement aux biais IA – que les architectes examinent de près – les biais d’automatisation passent souvent inaperçus, car la logique déterministe semble objective.

Suivez les règles d’attribution de pistes et de requêtes. Distribuez le travail entre les équipes commerciales et de service. Lorsque la logique d’attribution utilise des critères corrélés à des caractéristiques protégées, l’automatisation crée des disparités systématiques dans la qualité du service et l’accès aux opportunités.
Les règles d’attribution qui utilisent des caractéristiques de territoire, de code postal ou de compte peuvent acheminer les opportunités à valeur élevée de façon disproportionnée vers des équipes spécifiques tout en acheminant les travaux à valeur moindre ailleurs. Si les frontières des territoires sont corrélées aux données démographiques des clients et aux structures de rémunération qui diffèrent entre les territoires, l’automatisation des attributions crée une discrimination économique.
Auditez régulièrement les résultats des règles d’attribution. Calculez les distributions d’attribution entre les territoires et les équipes stratifiés par les données démographiques des clients. Si les comptes Enterprise sont concentrés dans des territoires spécifiques alors que les comptes SMB sont distribués ailleurs (et si les territoires Enterprise reçoivent une meilleure rémunération ou de meilleures ressources), les règles d’attribution peuvent entraîner des résultats inéquitables qui justifient un examen équitable.
Vérifiez l’acheminement basé sur les compétences monocanal. Cela peut affecter la qualité du service à travers les populations de clients. Si la logique d’acheminement suppose implicitement que certaines compétences sont corrélées avec la valeur du client ou la complexité du problème, les clients peuvent recevoir différents résultats de service basés sur des approximations démographiques.

Il est important de surveiller le délai moyen de traitement, les résolutions au premier contact et la satisfaction client à travers les parcours d’acheminement. Les disparités peuvent indiquer si certains segments de clients reçoivent systématiquement des agents moins expérimentés ou moins d’options d’acheminement.

Vérifiez les automatisations de flux Salesforce. La prise de décisions d’approbation, les déterminations d’éligibilité ou les octrois d’accès peuvent encoder une logique discriminatoire à travers des règles métiers apparemment anodines. Certains flux créent une discrimination indirecte lorsque les critères sont corrélés à des caractéristiques protégées.
Examinez les décisions de flux avec équité. Pour chaque flux qui prend des décisions conséquentes qui affectent les utilisateurs, il est important de se demander :
Que deviennent les utilisateurs qui ne correspondent pas au profil client typique ?
Les critères de décision sont-ils en corrélation avec les caractéristiques démographiques ?
Les exceptions et les requêtes périphériques sont-elles traitées équitablement ou désavantagent-elles systématiquement des groupes spécifiques ?

Il est important de documenter les considérations relatives à la logique de décision et à l’équité des flux dans les enregistrements de décision d’architecture, et de soumettre les flux à fort enjeu aux mêmes politiques d’examen éthique que les systèmes IA.

Vérifiez les règles de validation. Empêcher la saisie de données peut exclure les données valides des utilisateurs dont les informations ne correspondent pas aux hypothèses système. Les règles de validation qui rejettent les données légitimes créent des populations invisibles. Les utilisateurs dont les données ne correspondent pas aux modèles de validation ne peuvent pas interagir avec certains systèmes. Les échecs de validation ne sont souvent pas signalés, car les utilisateurs abandonnent leurs requêtes plutôt que de signaler des erreurs techniques. Voici plusieurs modèles de biais de validation courants :
Les validations de noms qui nécessitent des caractères latins peuvent exclure les noms avec des caractères diacritiques et non latins.
Les validations de numéro de téléphone utilisent souvent les formats US/Western, ce qui exclut les numéros internationaux et les méthodes de communication alternatives.
Les validations d’adresse ne reconnaissent pas les adresses non standard (par exemple, les boîtes postales, les routes rurales, les terres tribales et les formats internationaux).
Les validations d’e-mail qui nécessitent des adresses e-mail personnelles peuvent créer un désavantage pour les utilisateurs qui n’ont pas accès à la messagerie personnelle.
Testez les règles de validation en utilisant diverses données. Insérez des adresses internationales, des noms non occidentaux et des formats de téléphone alternatifs dans les tests de validation. Lorsque la validation rejette des données légitimes, vous devez élargir la logique de validation pour ne pas exclure les utilisateurs valides.

Vérifiez les conceptions de territoires de vente. Les stratégies de segmentation des clients et la conception des territoires de vente déterminent l’allocation des ressources entre les populations de clients. Lorsque les limites du territoire ou les critères de segmentation sont corrélés avec des données démographiques qui entraînent une allocation inégale des ressources, cette allocation peut produire des résultats discriminatoires. Les conceptions de territoires qui utilisent des frontières géographiques sont souvent corrélées avec des données démographiques raciales, ethniques et économiques en raison des modèles de ségrégation résidentielle. Si la rémunération, les niveaux de dotation en personnel ou les investissements en ressources diffèrent d’un territoire à l’autre, la géographie peut devenir un mécanisme d’affectation discriminatoire des ressources.
Analysez les données démographiques des territoires avant de finaliser les conceptions. Mappez les données démographiques des clients à travers les limites de territoire proposées. Lorsque des concentrations démographiques apparaissent, déterminez si l’allocation des ressources est équitable dans tous les territoires, quelle que soit la composition démographique. Si la justification commerciale nécessite différents niveaux de ressources entre les territoires (par exemple, maturité du marché, intensité concurrentielle et potentiel de croissance), documentez explicitement cette justification et surveillez les résultats pour vous assurer que les territoires mal desservis reçoivent des opportunités d’investissement adéquates afin d’éviter des disparités profondes.

Maintenir la transparence dans la logique d’automatisation. Documentez les règles métiers, les critères d’attribution et la logique de décision de flux dans Salesforce Knowledge ou des enregistrements de décision d’architecture. L’automatisation transparente permet de vérifier l’équité d’une manière que la logique cachée empêche.
Audit régulièrement les résultats. Planifiez des audits trimestriels pour analyser les résultats d’automatisation qui peuvent être stratifiés par les données démographiques des clients. Notez que les disparités déclenchent des enquêtes et des mesures correctives potentielles.
Il est important de suivre :
Distribution des attributions entre les équipes et les territoires
Taux d’approbation des flux qui prennent des décisions d’éligibilité
Taux de rejet des règles de validation par modèle de données
Performances du territoire et allocation de ressources
Examinez les automatisations à fort enjeu sous un angle éthique. Soumettez les flux et les règles d’attribution qui affectent l’emploi, le crédit, l’accès aux services ou d’autres résultats consécutifs au même processus d’examen éthique que les systèmes IA. Les biais d’automatisation nécessitent le même niveau d’examen que les biais algorithmiques.

Chez Salesforce, l’équité en IA se concentre sur l’utilisation d’Einstein pour valider que les prédictions produisent des résultats équitables dans tous les groupes démographiques. Einstein Discovery et l’instrumentation personnalisée capturent des données de décision de modèle prédictif qui permettent la détection des biais. Les tableaux de bord CRM Analytics suivent les métriques d’équité. Le Journal d’audit des champs et la Surveillance des événements capturent les données de décision pour la responsabilité algorithmique.

Les prédictions Einstein qui affectent des décisions conséquentes (par exemple, le score des pistes, les prévisions d’opportunités et la segmentation des clients) nécessitent des évaluations d”équité préalables au déploiement qui fonctionnent comme une étape équivalente obligatoire (semblable aux examens de sécurité).

Analysez toutes les fonctionnalités du modèle prédictif pour la corrélation avec les caractéristiques protégées en utilisant des méthodes statistiques. Retirez ou transformez les fonctionnalités proxy après avoir évalué si leur valeur prédictive justifie l’inclusion malgré les effets proxy.

Auditez les données Salesforce CRM avant la formation. Les organisations Salesforce contiennent des décennies de décisions humaines basées sur des pratiques historiques. Si les équipes commerciales passées donnaient la priorité à certaines données démographiques, le Score des pistes Einstein apprend ces modèles et les perpétue. Avant d’entraîner des modèles prédictifs sur des données historiques, il est important d’auditer ces données pour détecter les écarts de représentation démographique et les incohérences de mesure entre les segments de clients.
Calculer des métriques d’équité à travers les groupes démographiques. Avant de déployer des modèles prédictifs, il est important de calculer la parité démographique, l’égalité des chances et des ratios d’impact différents entre les groupes protégés, où vous disposez d’une base légale pour collecter et traiter les données démographiques requises. Si le Score des pistes Einstein attribue des scores élevés au segment A 50 % du temps, mais seulement 30 % du temps au segment B, un ratio de 60 % échoue à la règle des quatre cinquièmes (80 %) et nécessite une enquête et une atténuation. Le chiffre de 80 % est un déclencheur de dépistage, pas une ligne de réussite/échec légale : la règle des quatre cinquièmes est une règle empirique fédérale des États-Unis pour la sélection de l’emploi, et la supprimer n’est pas une sphère de sécurité — une disparité statistiquement significative peut justifier un examen à des ratios plus élevés, et d’autres régimes mesurent différemment l’impact négatif (la législation européenne sur la discrimination indirecte, par exemple, détermine si une pratique crée un « désavantage particulier », sans seuil fixe). Étalonner les seuils d’enquête en fonction des juridictions et des cas d’utilisation dans lesquels vous opérez.
Capturez des données de décision de modèle prédictif pour la détection des biais. Pour détecter les biais dans les modèles prédictifs tels que le Score des pistes et le Score des opportunités, capturez les données de décision via Einstein Discovery et une instrumentation personnalisée : stocker les entrées, les sorties et les versions de modèle de prédiction dans des champs suivis et activer le Journal d’audit des champs. Analysez ces données dans CRM Analytics pour suivre les modèles de décision à travers les groupes démographiques au fil du temps, et élaborez des tableaux de bord qui alertent lorsque les métriques de parité démographique ou d’égalité des chances dépassent les seuils acceptables.
Détecter les fonctionnalités proxy dans les modèles prédictifs. Les caractéristiques corrélées aux caractéristiques protégées permettent une discrimination indirecte, même lorsque les caractéristiques protégées sont exclues des modèles.
- Les données Salesforce contiennent généralement des fonctionnalités proxy :
Territoire ou code postal (proxies pour la race, l’origine ethnique et le revenu)
Modèles de nom de compte (proxies pour la taille de l’organisation et les données démographiques du secteur d’activité)
Calendrier des activités de communication (renseignements sur les fuseaux horaires, la religion et les responsabilités soignantes)
Type d’appareil ou navigateur dans Données d’activité (proxies du niveau de revenu)

Lorsque des biais sont détectés dans les prédictions Einstein, vous devez appliquer une atténuation à l’étape appropriée du pipeline (en fonction de la cause première et des contraintes techniques).

Équilibrez les données avant l’entraînement du modèle. Rééquilibrez les données Salesforce CRM en suréchantillonnant les segments de clients sous-représentés ou en sous-échantillonnant les segments surreprésentés avant d’entraîner les modèles prédictifs. Utilisez Data 360 pour agréger des données entre plusieurs organisations afin de garantir divers ensembles de formations. La génération de données synthétiques peut compléter les segments clairsemés tout en préservant la confidentialité grâce à des techniques de confidentialité différentielles.
Retirez les proxy dans l’ingénierie des fonctionnalités. Lorsque des fonctionnalités proxy sont identifiées, remplacez-les par des fonctionnalités alternatives qui fournissent une puissance prédictive sans corrélation démographique. Si le territoire sert de proxy démographique, considérez la classification par secteur d’activité ou la taille de l’entreprise comme alternatives. Si les modèles de nom de compte sont corrélés aux données démographiques, utilisez à la place des attributs firmographiques.
Ajustez les seuils pendant le post-traitement. Ajustez les seuils de décision par segment démographique pour égaliser les taux de résultat après les modèles d’entraînement. Pour les décisions liées à l’emploi, cela est purement et simplement interdit: Le titre VII (Civil Rights Act of 1991) interdit d ’ ajuster les scores ou d ’ utiliser différents scores de seuil par catégorie protégée, et aucune justification documentée ne rend la pratique licite. Lorsque cela n’est pas interdit, documentez les ajustements de seuil avec une justification métier pour le traitement différentiel lorsque les prédictions informent les décisions automatisées.
Entraînez périodiquement les modèles en utilisant des données mises à jour. Planifiez un réentraînement trimestriel du modèle (ou lorsque des changements importants se produisent dans la distribution des données). Le réentraînement sur des données actualisées détecte les modèles de biais émergents et corrige tout écart par rapport aux normes d’équité initiales. Revalidez les métriques d’équité de chaque version de modèle avant le déploiement en production pour vous assurer que le recyclage n’introduit pas de nouveaux biais.

La couche Trust Einstein capture les invites, les réponses et les signaux Trust pour l’IA générative et les fonctionnalités Agentforce, prenant en charge la transparence et la conformité réglementaire pour l’IA générative. Pour les modèles prédictifs, la transparence et le lignage décisionnel proviennent d’Einstein Discovery et du Gestionnaire de modèle, qui nécessitent une instrumentation personnalisée pour conserver les données d’audit.

Intégrez l’explicabilité dans les solutions Einstein depuis l’architecture initiale au lieu d’adapter les explications aux systèmes opaques après le déploiement.

Exposer les explications Einstein Discovery aux points de décision. Einstein Discovery fournit des explications de facteurs de prédiction qui montrent quelles variables ont le plus influencé des prédictions spécifiques ayant un impact directionnel. Les composants Lightning architecturaux qui affichent ces explications aux utilisateurs au point de décision plutôt que de nécessiter une navigation vers des tableaux de bord CRM Analytics séparés. Lorsque les décisions affectent les utilisateurs, elles nécessitent de la transparence, pas des métriques de performance de modèle abstraites.
Explications en couches pour différentes audiences. Fournissez une profondeur d’explication adaptée à chaque audience :
Utilisateurs professionnels : « Cette avance a obtenu un score élevé, car le chiffre d’affaires annuel dépasse 1 M$ et le score d’engagement est dans les 10 % les plus élevés. »
Utilisateurs techniques : Fournissez une carte modèle Einstein Discovery avec des pondérations de fonctionnalité, des caractéristiques de données d’entraînement et des métriques de validation.
Clients : « Cette recommandation est basée sur vos achats récents et vos clients ayant des préférences similaires. »
Auditeurs : Fournissez la lignage décisionnel d’Einstein Discovery et du Gestionnaire de modèle (version du modèle, valeurs d’entrée et facteurs qui ont conduit à la prédiction) capturés à l’aide d’instrumentations personnalisées.
Communiquer la confiance de façon appropriée. Affichez la confiance dans les prédictions en termes appropriés pour l’utilisateur et évitez les scores de probabilité bruts que les utilisateurs peuvent mal interpréter. Au lieu d’afficher une « confiance de 73 % », communiquez-la en utilisant des catégories (par exemple, Confiance élevée, Confiance modérée et Examen requis) avec des explications sur ce que chaque niveau de confiance signifie pour la fiabilité des décisions, ainsi que sur les examens supplémentaires qui auront lieu.

Gérez des pistes d’audit complètes et immuables qui prennent en charge la responsabilité, le débogage et la conformité réglementaire pour toutes les décisions pilotées par l’IA qui affectent les utilisateurs.

Capturez des données d’audit prédictif avec les outils appropriés. Stockez les données d’audit de modèle prédictif (entrées, sorties et versions de modèle de prédiction) dans des champs suivis avec le Journal d’audit des champs activé. Architectez des politiques de rétention des données pour satisfaire aux exigences réglementaires, qui varient selon le secteur d’activité et la juridiction :
- Les règles relatives aux services financiers définissent la conservation par règlement (par exemple, la règle FINRA 4511(b) définit une période de conservation par défaut de six ans pour les documents qui n’ont pas de période de conservation spécifiée par ailleurs en vertu des règles FINRA ou de la règle 17a-4 de l’EES).
- La rétention des soins de santé est également régie par des règles spécifiques (par exemple, l’HIPAA exige au moins six ans pour la documentation de conformité; la rétention des dossiers médicaux est fixée par les lois de chaque État) plutôt que de couvrir les mandats de rétention illimitée.
Analysez les données de décision du modèle prédictif avec CRM Analytics. Élaborez des tableaux de bord CRM Analytics sur les données de décision de modèle prédictif que vous capturez (entrées, sorties et versions de modèle de prédiction dans les champs suivis) pour analyser les modèles de décision, les métriques d’équité et les performances du modèle au fil du temps. Créez des perspectives qui montrent les distributions de prédiction par niveau de confiance, segment démographique et type de résultat. Configurez des récits Einstein Discovery qui identifient les modèles anormaux qui nécessitent une investigation supplémentaire.
Utilisez le Journal d’audit des champs pour la rétention à long terme. L’historique des champs standard suit les modifications pendant 18 mois dans l’interface utilisateur et jusqu’à 24 mois via l’API. Le Journal d’audit des champs permet de conserver indéfiniment l’historique des champs pour les objets personnalisés qui stockent des données de décision IA. Il archive par défaut l’historique au bout de 18 mois, puis conserve les données archivées jusqu’à ce que vous les supprimiez. Activez le Journal d’audit des champs dans les objets qui contiennent des enregistrements de consentement, des décisions de remplacement et des rapports de biais pour satisfaire aux exigences réglementaires de rétention.
Utilisez la Surveillance des événements pour les interactions Agentforce. Event Monitoring capture les événements au niveau de l’invocation pour Agentforce, par exemple lors de l’exécution des actions et des flux. Exportez les données de Surveillance des événements vers un SIEM externe (données standard du fichier journal des événements via l’API et sous-ensemble d’événements Surveillance des événements en temps réel via Événements de plate-forme) pour un stockage qui dépasse la période de rétention native de Salesforce. Les preuves d’altération dépendent du comportement SIEM particulier qui applique la ségrégation du stockage et de l’accès en écriture unique. Configurez des requêtes SIEM afin de détecter des modèles de biais dans de grands volumes d’interactions Agentforce.
Audit les conversations Agentforce avec la couche Trust Einstein. La couche Trust Einstein capture le journal d’audit des invites et des réponses de conversation Agentforce, stockées dans Data 360, fournissant l’enregistrement au niveau de la transcription pour la transparence et la conformité réglementaire.

Examinons de plus près les capacités de transparence de l’architecte qui sont positionnées pour la conformité aux réglementations IA actuelles et émergentes dans plusieurs juridictions.

Exigences de transparence de la loi IA de l’UE. Les systèmes d’IA à haut risque en vertu de la loi IA européenne nécessitent une documentation sur la transparence, une documentation technique, des capacités de surveillance humaine et des métriques de précision/équité. Les parcours d’audit Einstein Trust Layer et les cartes de modèle Einstein Discovery fournissent les bases de ces exigences. Documentez les données démographiques d’entraînement du modèle, les approches de validation et les limitations connues dans les enregistrements de décision d’architecture.
Droit à l’explication du RGPD. Le RGPD accorde aux personnes concernées par les données de l’UE le droit à des informations pertinentes sur la logique d’une décision lorsque celle-ci repose uniquement sur un traitement automatisé et produit des effets juridiques ou similaires importants. Ce droit découle des articles 15, paragraphe 1, point h), et 22, paragraphe 3, lus conjointement avec le considérant 71, et a été précisé par la CJUE dans l’affaire Dun & Bradstreet (2025). Concevez des systèmes qui génèrent des explications cohérentes à la demande pour toute décision historique dans les délais de demande d’accès à la personne concernée, qui varient (selon la juridiction) entre 15 et 45 jours. Les données de décision du modèle prédictif que vous capturez (entrées, sorties, versions du modèle et facteurs d’explication Einstein Discovery) permettent de reconstituer les explications lorsqu’elles sont stockées avec une rétention suffisante.
Lois sur la responsabilité algorithmique. Les lois américaines sur la responsabilité algorithmique au niveau des États exigent de plus en plus des évaluations d’impact et des rapports de transparence pour les systèmes de décision automatisés. Les données de décision basées sur un modèle prédictif que vous capturez et les tableaux de bord de surveillance de l’équité CRM Analytics fournissent les bases de données de ces rapports. Effectuez des évaluations d’impact algorithmiques avant de déployer l’IA conséquente en tant que conformité proactive plutôt qu’en tant que réponse réactive aux demandes réglementaires.

Les OWD, les règles de partage et la Sécurité au niveau du champ (FLS) déterminent les modèles d’accès aux données qui déterminent les informations que les utilisateurs peuvent consulter et utiliser pour prendre des décisions. Une configuration correcte empêche l’accès discriminatoire aux attributs confidentiels tout en garantissant un service équitable.

Concevez OWDs et Field-Level Security pour restreindre l’accès par défaut. Pour les règles de partage, utilisez le principe du moindre privilège (PoLP) afin d’accorder uniquement l’accès supplémentaire dont chaque rôle a légitimement besoin, ce qui empêche la prise de décision discriminatoire basée sur des caractéristiques protégées.

Activez la motricité restrictive par défaut. Utilisez des OWD privés pour les objets qui contiennent des données clients confidentielles, et accordez l’accès par hiérarchie des rôles et règles de partage. Les OWD en lecture/écriture publique rendent la restriction de l’accès plus tard perturbatrice — le renforcement du paramètre par défaut déclenche un recalcul du partage et prend effet uniquement lorsqu’il est terminé — plutôt qu’impossible. Les OWD privés avec des subventions de partage explicites créent des modèles d’accès vérifiables qui favorisent le respect de la non-discrimination.
Appliquez la Sécurité au niveau du champ pour les attributs confidentiels. Masquez les champs confidentiels qui contiennent des caractéristiques protégées (par exemple, l’origine ethnique, la religion et le statut de handicap) pour les utilisateurs qui n’ont pas besoin d’accéder à des fins professionnelles légitimes. Configurez FLS pour retirer l’accès en lecture aux champs confidentiels dans la plupart des profils. Lorsque ces champs sont requis à des fins spécifiques (par exemple, rapports sur la diversité et mesures d’adaptation raisonnables), accordez un accès minimal en utilisant des ensembles d’autorisations avec une justification métier documentée.
Concevoir des règles d’attribution et de partage pour des résultats équitables. Utilisez des règles d’attribution, des files d’attente et l’acheminement Omni-Channel pour distribuer équitablement le travail entre les territoires, les équipes et les agents de service. Évitez le partage manuel qui concentre les opportunités à valeur élevée ou les clients avec des groupes d’utilisateurs spécifiques sans justification métier documentée. Configurez des règles de partage automatiques basées sur des critères objectifs (par exemple, secteur d’activité, zone géographique et gamme de produits) plutôt que sur la discrétion subjective du responsable, qui peut activer des biais.
Fournissez des ensembles d’autorisations pour l’accès temporaire. Accordez un accès temporaire à des données confidentielles via des ensembles d’autorisations plutôt que de modifier des profils, ce qui affecte définitivement tous les utilisateurs. Lorsque les utilisateurs doivent accéder aux données démographiques de projets spécifiques (par exemple, analyse de la diversité et demandes d’adaptation), attribuez des ensembles d’autorisations avec des expirations documentées. Les flux planifiés peuvent révoquer automatiquement des ensembles d’autorisations après des périodes définies.

Utilisez la Surveillance des événements Shield et les rapports pour détecter les modèles d’accès aux données qui indiquent une discrimination ou un biais potentiel dans l’utilisation des données.

Utilisez Shield Event Monitoring pour auditer l’accès aux données confidentielles. Utilisez la Surveillance des événements pour capturer les événements d’accès au niveau de l’objet (exportations de rapports, requêtes d’API et vues de page) dans les objets qui contiennent des caractéristiques protégées ou des attributs confidentiels. Configurez des requêtes sur ces événements pour exposer qui a accédé à l’objet, quand et dans quel contexte, et traitez les modèles anormaux (par exemple, pics soudains et accès par des utilisateurs inattendus) comme des déclencheurs d’enquête.
Rapport sur les distributions de règles de partage. Élaborez des rapports qui analysent la distribution des enregistrements entre les utilisateurs, les équipes et les territoires. Calculez des statistiques de distribution par données démographiques des clients pour vous assurer que les comptes et les opportunités à forte valeur sont distribués équitablement. Identifiez les concentrations dans lesquelles des groupes d’utilisateurs spécifiques reçoivent un accès disproportionné à des enregistrements importants sans justification métier documentée.
Vérifier les infractions CRUD et FLS. Consultez le Journal d’audit de configuration pour les modifications apportées aux paramètres OWD, aux règles de partage, aux configurations FLS et aux ensembles d’autorisations. Des modifications non autorisées des contrôles d’accès aux données peuvent indiquer des tentatives d’accès inapproprié à des données confidentielles. Utilisez des stratégies de sécurité des transactions pour agir sur les événements de Surveillance des événements en temps réel à haut risque (par exemple, activité anormale de l’API, connexions suspectes et exportations importantes de rapports ou de vues de liste de données confidentielles). Comme la Sécurité des transactions fonctionne uniquement sur ces événements d’exécution plutôt que sur les modifications DML ou FLS au niveau de l’enregistrement, vous devez vous appuyer sur le Journal d’audit de configuration et les approbations de gestion des modifications documentées pour le FLS et le partage des modifications.

Chez Salesforce, l’agence utilisateur signifie que les clients et les employés gardent un contrôle significatif sur l’impact de l’IA sur leur expérience. Les capacités de gestion du consentement de Salesforce, le consentement Data 360 et les objets de consentement personnalisés permettent un contrôle précis des interactions IA.

Concevez le suivi du consentement en utilisant la gestion du consentement Data 360, le consentement Marketing Cloud ou des objets de consentement personnalisés qui utilisent le Journal d’audit des champs pour les exigences de consentement spécifiques à l’IA.

Activez le consentement granulaire par cas d’utilisation d’IA. Activez le consentement par cas d’utilisation IA au lieu d’utiliser un consentement IA général. Les clients peuvent consentir aux recommandations de produits Einstein mais refuser les décisions de crédit pilotées par l’IA. Activez Journal d’audit des champs dans les objets Consentement pour la rétention à long terme et le respect des exigences réglementaires. Concevez des objets Consentement personnalisés avec des champs qui suivent :
Motif du consentement (par exemple, Score des pistes Einstein, Recommandations de réponses Einstein et Générateur de recommandations Einstein)
Date d’octroi du consentement et méthode d’octroi (par exemple, formulaire Web, API, téléphone et e-mail)
Date de retrait du consentement (le cas échéant)
ID d’utilisateur ou de contact associé
Utilisez le consentement Data 360 pour la personnalisation. Utilisez la gestion du consentement Data 360 pour les fonctionnalités de personnalisation Einstein. Data 360 ingère et stocke les préférences de consentement des systèmes en amont via des connecteurs mappés avec le Modèle de données de confidentialité, qui permet d’utiliser ces attributs de consentement en tant que critères de filtrage dans la segmentation et lors de l’activation. Mappez les attributs de consentement avec des cas d’utilisation d’IA spécifiques afin de permettre aux utilisateurs de se désabonner de la personnalisation tout en maintenant les services de base
Activez l’intégration du consentement Marketing Cloud. Intégrez le consentement Marketing Cloud aux Connaissances de Messagerie Einstein et aux fonctionnalités marketing pilotées par l’IA. Respectez le statut d’abonnement et le consentement Marketing Cloud dans toutes les communications pilotées par l’IA.

Offrez un désabonnement significatif des fonctionnalités pilotées par l’IA avec des contrôles accessibles qui respectent les préférences des utilisateurs via des alternatives humaines de qualité comparable.

Fournissez des désabonnements accessibles dans les paramètres du profil. Permettez aux utilisateurs de se désabonner des interactions pilotées par l’IA via des contrôles de préférence accessibles dans les paramètres de profil Experience Cloud ou Mes paramètres dans les applications internes. Fournissez des descriptions claires de ce que signifie chaque désabonnement et de l’expérience alternative que les utilisateurs recevront en se désinscrivant. Stockez les préférences dans les enregistrements Utilisateur ou Contact.
Offrez des options de préférences permanentes à travers les canaux. Stockez les préférences IA dans des enregistrements Utilisateur ou Contact pour garantir la cohérence entre les canaux (par exemple, Web, mobile, téléphone et e-mail). Interrogez les préférences de façon cohérente dans tous les flux d’interaction afin d’éviter aux utilisateurs de répéter à répétition leurs préférences dans différents canaux.

La gouvernance éthique de l’IA fournit des structures organisationnelles qui aident à garantir que l’équité persiste à mesure que les modèles évoluent, que les données changent et que les cas d’utilisation se développent. Sans gouvernance, les efforts initiaux d’équité se détériorent à mesure que l’attention de l’organisation change.

Établissez la documentation obligatoire et vérifiez les points de contrôle avant le déploiement Einstein. Considérez cela comme une barrière aussi importante que les contrôles de sécurité.

Fournissez la documentation du modèle. Stockez la documentation sur le modèle dans Salesforce en utilisant un objet Modèle personnalisé, ou Salesforce Files joint à Projects pour activer la recherche et le contrôle de version. Documentez chaque modèle prédictif de production en utilisant :
Données démographiques d’entraînement et écarts de représentation connus (pour des modèles prédictifs entraînés par le client tels que Einstein Discovery et le Générateur de prédiction)
Métriques d’équité avant le déploiement calculées par groupe démographique
Cas d’utilisation prévus et utilisations inappropriées connues
Stratégies d’atténuation des biais appliquées pendant le développement
Approche de surveillance de l’équité et seuils d’alerte
Exigences de surveillance humaine et workflows d’approbation
Examiner les calendriers et les parties responsables
Considérations réglementaires et positionnement en matière de conformité
Activez Portes d’équité avant le déploiement. Les modèles qui échouent à un test de barrière ne doivent pas passer en production. Traitez les barrières d’équité avec la même rigueur que les barrières de sécurité. En d’autres termes, ils ont le pouvoir de bloquer les déploiements. Avant de déployer les prédictions Einstein en production, vous devez :
Examinez les audits des données de formation. Tous les écarts de représentation doivent être analysés et documentés.
Examiner les métriques d’équité (par exemple, la parité démographique, l’égalité des chances et l’impact différent doivent être calculés et confirmés pour atteindre les seuils).
Examiner les évaluations d’impact. Évaluer les dommages potentiels entre les populations touchées.
Concevez avec la surveillance humaine. Tous les modèles d’escalade, les workflows d’approbation et les mécanismes de remplacement doivent être conçus et testés de façon appropriée.
Exécuter un examen de transparence. Les capacités d’explication doivent être validées pour tous les types de décision.
Documentation complète. Tous les artefacts de documentation sur le modèle requis doivent être approuvés.

Établir des processus d’examen pour les applications d’IA à enjeux élevés qui fournissent une surveillance interfonctionnelle et ont un pouvoir d’application.

Vérifiez la composition du conseil. Incluez des experts techniques (par exemple, des architectes et des scientifiques des données), des intervenants commerciaux (par exemple, des propriétaires de produits et du personnel des opérations), des conseillers juridiques, des spécialistes de la protection de la vie privée et des représentants des collectivités touchées (si possible). N’oubliez pas que les diverses perspectives exposent des problèmes d’équité que les groupes homogènes manquent souvent.
Examinez tous les déclencheurs qui nécessitent l’approbation du comité d’éthique. Définissez les cas d’utilisation IA qui nécessitent un examen éthique avant le déploiement :
Décisions qui affectent l’emploi, le crédit, le logement, la santé ou les droits légaux
Systèmes automatisés qui affectent plus de 10 000 utilisateurs ou transactions par an
Applications IA qui utilisent des données personnelles confidentielles, notamment des données de santé, financières ou démographiques
Nouveaux cas d’utilisation sans précédent organisationnel établi
Systèmes dans lesquels des biais potentiels peuvent causer des dommages importants à des individus ou à des groupes
Examinez et déterminez qui est autorisé à bloquer les déploiements. Les comités d’éthique devraient avoir le pouvoir d’exiger des changements, d’imposer des conditions de surveillance ou de bloquer les déploiements qui ne respectent pas les normes d’éthique. Les examens consultatifs seulement (sans pouvoir d’application) peuvent limiter l’efficacité du processus de gouvernance. Documentez toutes les révisions dans des objets personnalisés Salesforce qui suivent : nom de la demande, date d’examen, préoccupations soulevées, exigences d’atténuation et conditions d’approbation.

La surveillance de l’équité est un processus continu qui nécessite une attention continue pour détecter les écarts de biais à mesure que les distributions de données changent et que les populations d’utilisateurs changent.

Créez des tableaux de bord d’équité CRM Analytics. Élaborez des tableaux de bord qui suivent les métriques d’équité en utilisant les données de décision du modèle prédictif que vous capturez. Surveillez la parité démographique, l’égalité des chances, les ratios d’impact différent et les métriques de qualité des prédictions par segments de clients. Configurez des alertes CRM Analytics qui se déclenchent lorsque des métriques d’équité enfreignent les seuils définis et nécessitent une enquête.
Activez la surveillance personnalisée des signaux d’équité. Élaborez une surveillance personnalisée de l’équité afin de détecter des signaux (par exemple, des changements soudains dans la distribution des décisions par groupe démographique, des pics dans les enregistrements de requêtes liés à des biais ou une dégradation des performances du modèle pour des populations spécifiques).
Planifiez des audits d’équité. Effectuer des audits d’équité trimestriels complets pour les systèmes d’IA à enjeux élevés (par exemple, crédit, emploi et santé), et des audits semestriels pour les systèmes à enjeux faibles (par exemple, recommandations et personnalisation). Les audits devraient examiner les métriques d’équité actuelles, examiner les modèles de remplacement dans l’historique des approbations, analyser les commentaires des utilisateurs et les rapports de biais, et vérifier si les contrôles de gouvernance demeurent efficaces.
Mettre en œuvre une réponse en cas d’incident pour manquement à l’équité. Établissez des processus clairs documentés dans Salesforce Knowledge détaillant comment réagir lorsque des biais sont détectés:
Immédiat : Évaluez la sévérité et la portée en interrogeant les données de décision du modèle prédictif dans CRM Analytics. Si l’incident est grave, suspendez toute prise de décision automatisée en attendant une enquête.
À court terme : Mettre en œuvre des stratégies d’atténuation temporaires (par exemple, une surveillance humaine accrue par le biais de seuils de confiance ajustés, la désactivation de fonctionnalités ou la suspension complète de l’agent).
Enquête : Effectuez une analyse des causes profondes (RCA) pour identifier comment le biais est entré dans le système ou a évolué. Pendant le RCA, analysez les données d’entraînement, les versions de modèle et les changements de configuration via le Journal d’audit des champs.
Remédiation : Implémentez un correctif permanent via la correction des données, le réentraînement du modèle ou des changements de processus.
Communication : Notifiez les utilisateurs affectés par requêtes, e-mail ou annonces Experience Cloud.
Prévention : Traitez les modifications pour éviter les récurrences et documentez les méthodes de prévention dans des runbooks.

Utilisez cette liste de contrôle lors des examens d’architecture, avant le déploiement en production et périodiquement pour une évaluation continue.

Qualité des données et équité de la représentation

Définissez des champs facultatifs dans lesquels un processus peut fonctionner sans les données, et concevez des processus en aval pour gérer les valeurs manquantes, afin de ne pas exclure les utilisateurs qui ne peuvent pas fournir d’informations (e-mail, SSN, adresse postale).
Les champs Nom de l’architecte sont des champs de nom complet uniques ou une structure flexible à plusieurs parties qui accepte les mononymes, les écritures non latines, les diacritiques et les noms longs, plutôt que d’accepter l’ordre occidental prénom/nom.
Implémentez une validation d’adresse permissive qui accepte les formats de forme libre et internationaux, en stockant les adresses telles que saisies au lieu de bloquer la création d’enregistrements en cas d’inadéquation de format.
Stockez les préférences de canal de communication dans les enregistrements Contact et prenez en charge les alternatives monocanal (e-mail, SMS, téléphone, poste, chat, voix) plutôt que de supposer qu’un canal unique atteint tous les utilisateurs.
Recueillez des données démographiques par auto-identification volontaire avec l’option « Préférer ne pas répondre », stockées séparément sous Private OWD with FLS, agrégées pour la génération de rapports et surveillées via Shield Event Monitoring.
Auditez les fournisseurs d’enrichissement tiers pour les tests d’équité, la couverture démographique et la méthodologie d’inférence avant d’ajouter des données démographiques ou comportementales à des enregistrements.

Accessibilité et conception inclusive

Utilisez des composants Lightning Design System, conçus pour prendre en charge l’accessibilité WCAG 2.2 AA. Notez que Salesforce vise la conformité, mais que les composants nécessitent une utilisation correcte.
Validez des composants Web Lightning personnalisés avec des tests de lecteur d’écran (par exemple, JAWS, NVDA et VoiceOver).
Assurez-vous que la navigation complète au clavier est présente dans les pages Lightning et les sites Experience Cloud sans dépendance à la souris.
Vérifiez que les rapports de contraste respectent 4,5:1 pour un texte normal en utilisant des outils de développement de navigateur ou des vérificateurs de contraste.
Intégrez la numérisation de l’accessibilité sa11y ou Lighthouse dans les pipelines CI/CD qui échouent s’appuie sur des problèmes critiques.
Testez les sites Experience Cloud en utilisant une technologie d’assistance avant le lancement public.
Vérifiez les commentaires auditifs en confirmant que toutes les modifications dynamiques (par exemple, états d’erreur, chargement de toupies ou menus élargis) sont clairement annoncées et que le contenu parlé correspond à l’intention visuelle de l’interface utilisateur.

Équité dans Salesforce Automation

Examinez les règles d’attribution et d’acheminement pour déterminer la corrélation avec les caractéristiques protégées qui pourraient concentrer les résultats favorables ou défavorables dans des groupes démographiques spécifiques.
Flux d’audit et logique de décision processus-automatisation pour les biais, documentant les règles métiers et les critères dans Salesforce Knowledge ou les enregistrements de décision d’architecture.
Évaluez les règles de validation des taux de rejet qui affectent de façon disproportionnée des modèles de données ou des populations spécifiques.
Analyser la corrélation démographique dans les conceptions de territoires et de segmentation, en documentant les justifications métiers explicites et en surveillant l’allocation équitable des ressources dans les territoires mal desservis.
Soumettez les flux et les règles d’attribution à fort enjeu (emploi, crédit, accès aux services) au même processus d’examen éthique que les systèmes IA, et planifiez des audits trimestriels des résultats de l’automatisation stratifiés par données démographiques.

Équité IA et détection des biais

Auditez les écarts de représentation démographique dans les données Salesforce CRM avant l’entraînement au modèle prédictif.
Calculez la parité démographique, l’égalité des chances et des ratios d’impact différents par groupe démographique avant le déploiement.
Implémentez des évaluations de l’équité en tant que portail de déploiement obligatoire (considérez que cela équivaut à un contrôle de sécurité).
Élaborez des tableaux de bord CRM Analytics qui suivent les métriques d’équité en utilisant des données de décision de modèle prédictif capturées avec le Journal d’audit des champs.
Analysez les fonctionnalités du modèle prédictif pour la corrélation proxy avec des caractéristiques protégées (par exemple, les modèles de nom de territoire et de compte).
Planifiez des audits d’équité trimestriels complets pour tous les systèmes d’IA à fort enjeu.

Transparence et auditabilité

Exposer des explications de prédiction Einstein Discovery aux points de décision dans les composants Lightning.
Configurez des captures d’audit Einstein Trust Layer en utilisant des méthodes de rétention qui répondent aux exigences réglementaires.
Activez Journal d’audit des champs dans tous les objets personnalisés qui stockent les données de décision IA pour une rétention à long terme.
Exportez les données de Surveillance des événements vers un SIEM externe (données du fichier journal des événements via l’API et événements de Surveillance des événements en temps réel via des événements de plate-forme) pour un stockage qui dépasse la rétention native, avec des contrôles d’écriture unique côté SIEM pour les preuves d’altération.
Offrez une communication de confiance adaptée à l’utilisateur (par exemple Élevée, Modérée et Faible) plutôt que des probabilités brutes.

Surveillance humaine avec Salesforce Automation

Configurez des seuils d’escalade basés sur la confiance dans Flux et acheminez les prédictions de faible confiance vers un examen humain.
Utilisez des processus d’approbation Salesforce pour les décisions à fort enjeu qui nécessitent des chaînes d’examen à plusieurs étapes.
Intégrez Agentforce et l’acheminement Omni-Channel pour permettre une escalade transparente vers les agents humains.
Prévoyez une option persistante ” Se connecter à un agent humain ” dans les interfaces Agentforce pour respecter l’agence utilisateur.
Exiger un suivi de la justification documentée et de l’historique des approbations pour les remplacements Agentforce capturés dans des champs personnalisés.

Non-discrimination avec les contrôles d’accès aux données

Activez Private OWD, puis accordez un accès supplémentaire via la hiérarchie des rôles et des règles de partage.
Configurez la Sécurité au niveau du champ pour masquer les champs démographiques confidentiels pour les utilisateurs qui n’ont pas besoin d’accès.
Surveillez les événements d’accès au niveau de l’objet (exportations de rapports et requêtes d’API) pour les données confidentielles via Shield Event Monitoring, et analysez-les pour détecter les modèles d’accès anormaux.
Élaborez des rapports qui analysent les distributions de règles de partage pour garantir une allocation d’enregistrement équitable entre les territoires.
Consultez Journal d’audit de configuration pour les modifications non autorisées de configuration OWD, règle de partage ou FLS.

Agence utilisateur et consentement

Concevez des objets Consentement personnalisés en utilisant le Journal d’audit des champs pour suivre un consentement IA précis et par cas d’utilisation.
Intégrez le consentement Data 360 ou Marketing Cloud aux fonctionnalités Personnalisation Einstein et Agentforce.
Stockez les préférences IA dans des enregistrements Utilisateur ou Contact pour garantir la cohérence entre les canaux (par exemple, Web, mobile et téléphone).
Offrez des désabonnements accessibles dans les paramètres de profil et des alternatives humaines via l’acheminement Omni-Channel.
Interrogez les enregistrements de consentement dans Flux avant que les prédictions Einstein ou l’engagement Agentforce affectent les utilisateurs.

Gouvernance IA éthique

Documentez tous les modèles prédictifs de production, y compris les métriques d’équité et les stratégies d’atténuation; pour les modèles prédictifs entraînés par le client (tels que Einstein Discovery et le Générateur de prédiction), documentez également les données démographiques de formation-données.
Établissez des barrières d’équité obligatoires avant le déploiement qui bloquent le déploiement jusqu’à ce que tous les critères d’équité soient remplis.
Créez un comité d’éthique de l’IA en tant qu’autorité d’application pour toutes les applications IA à fort enjeu.
Élaborez des tableaux de bord CRM Analytics pour surveiller les métriques d’équité dans une cadence planifiée via des alertes CRM Analytics.
Définissez des procédures de réponse aux incidents pour les manquements à l’équité et documentez le processus dans Salesforce Knowledge.
Planifiez des audits d’équité trimestriels qui analysent les modèles de remplacement et les commentaires des utilisateurs pour tous les systèmes à fort enjeu.

Partagez vos commentaires sur l'infrastructure bien archivée.