Prenons un hypothétique Agent de prêt Agentforce stratifié sur Data 360 pour décrire un exemple de flux d'architecture. Supposons que l'agent de prêt est un agent qui contacte les clients (consommateurs) pour demander des prêts et obtenir instantanément des approbations de prêt.
Data 360 exécute ces étapes comme prévu, en préparant les données à utiliser par l'agent de prêt.
- Data 360 ingère les données structurées Compte client à partir de CRM et les stocke dans le lac de données.
- Data 360 traite les données non structurées des prêts et des politiques financières de l'entreprise.
- Data 360 fédère les données personnelles à partir d'une source de données externe telle que Snowflake.
- Data 360 transforme et modélise les données ingérées et fédérées.
- Data 360 élabore et gère le graphique des données de profil.
Chaque fois qu'un client fait une demande de prêt, les actions ci-dessous sont exécutées.
- Un client se connecte à l'agent de prêt, qui commence une session client dans la couche en temps réel. Le profil unifié du client est extrait dans la couche en temps réel.
- Le client remplit une demande de prêt en fournissant les informations requises.
- Le client charge des documents financiers (tels que des déclarations fiscales, des investissements, des relevés bancaires) dans Data 360 pour un traitement de données non structuré.
- Les données chargées sont segmentées et vectorisées (génération incorporée), et des index (mot-clé et vecteur) sont créés.
- Ensuite, le client remplit le document de demande de prêt et le charge. Data 360 extrait en temps réel le montant et la durée du prêt.
- L'agent de prêt récupère les données financières pertinentes en utilisant la requête Data 360 et la recherche hybride sur le profil et d'autres index précréés.
- L'agent de prêt active un agent d'approbation avec des données de prêt et d'autres données de profil financier pour prendre la décision d'approbation de prêt.
- L'agent de prêt répond au client avec une décision.
- Cette interaction complète entre le client et l'agent de prêt est également capturée et stockée dans Data 360.
L'exemple ci-dessus présente une vue d'ensemble des composants d'architecture Data 360 utilisés pour élaborer une application Agentic telle qu'un agent de prêt. Dans la section suivante, nous décrivons les couches et les composants de l'architecture Data 360.
## Architecture Data 360
Dans cette section, nous allons explorer les blocs de construction de base de Salesforce Data 360, en commençant par son modèle de stockage robuste, puis en explorant les mécanismes de connexion, d'ingestion et de préparation des données. Nous examinerons ensuite comment les données structurées et non structurées sont stockées, modélisées et traitées, pour aboutir à une compréhension de leur harmonisation, unification, récupération et capacités d'activation intelligente.
### Stockage Data 360
Salesforce Data 360 repose sur un modèle de stockage hiérarchisé mais intégré qui combine les avantages d'une maison de lac avec le stockage en temps réel. La couche Lakehouse fournit un stockage évolutif et économique pour de grands volumes de données historiques et par lot, ce qui permet des analytiques avancées et des cas d'utilisation d'apprentissage machine. Le stockage en temps réel, quant à lui, est optimisé pour l'accès à faible latence et les mises à jour à haute fréquence, ce qui garantit que les interactions, les profils et les signaux d'engagement des clients sont toujours à jour. Ensemble, ces niveaux fonctionnent de façon transparente, ce qui permet aux données de circuler de façon fluide entre les contextes historiques et en temps réel, offrant à la fois profondeur et immédiateté dans une fondation de données unifiée pour la personnalisation, l'IA et l'activation.
#### Lakehouse
Data 360 propose une architecture Lakehouse native basée sur Iceberg/Parquet, conçue pour gérer la gestion et le traitement des données à grande échelle pour des scénarios par lot, en continu et en temps réel prenant en charge des données structurées et non structurées, essentielles pour les applications d'IA et d'analyse.
Dans les lacs de données basés sur le cloud tels que Azure, AWS ou GCP, l'unité de stockage de base est un fichier, généralement organisé en dossiers et en hiérarchies. Lakehouse améliore cette structure en introduisant des abstractions structurelles et sémantiques de niveau supérieur pour faciliter des opérations telles que l'interrogation et le traitement IA/ML. L'abstraction principale est un tableau avec des métadonnées qui définit sa structure et sa sémantique, incorporant des éléments de projets open-source tels que Iceberg ou Delta Lake, avec des couches sémantiques supplémentaires ajoutées par Data 360.
Couches d'abstraction dans Lakehouse :
1. **Parquet File Abstraction**: À la base, le stockage est composé de fichiers lac de données (par exemple S3 dans AWS ou Blob dans Azure) au format Parquet. Les données d'un tableau source sont stockées dans plusieurs partitions sous forme de fichiers Parquet, chaque tableau étant une collection de ces fichiers.
2. **Abstraction de tableau iceberg**: Les tableaux sont organisés en dossiers, avec des partitions de données stockées sous forme de fichiers Parquet dans ces dossiers. Les modifications apportées à une partition entraînent de nouveaux fichiers Parquet sous forme de clichés instantanés. Iceberg gère un fichier de métadonnées pour chaque tableau, détaillant des schémas, des spécifications de partition et des clichés instantanés.
3. **Salesforce Cloud Table Abstraction**: Basée sur Iceberg, cette couche ajoute des métadonnées sémantiques telles que les noms de colonne et les relations, ainsi que des configurations telles que la taille de fichier cible et la compression. Il extrait des tableaux sur diverses plates-formes telles que Snowflake et Databricks, protégeant les applications Data 360 des spécificités de la plate-forme de stockage sous-jacente.
4. **Bibliothèque d'accès au lac**: Cette bibliothèque permet d'accéder au tableau Salesforce Cloud, en gérant les données et les métadonnées, et d'extraire les mécanismes de stockage sous-jacents pour les développeurs d'applications.
5. **Big Data Service Abstraction**: Cela inclut des infrastructures de traitement telles que Hyper pour l'interrogation et Spark pour le traitement sur n'importe quelle plate-forme de tableau cloud.
#### Stockage en temps réel
Pour prendre en charge les analytiques en temps réel et les applications agentiques, Data 360 augmente le stockage de Big Data Lakehouse avec Low Latency Store. Data 360 Real-Time Layer traite les signaux en temps réel et les données d'engagement en mémoire. Cependant, comme la capacité de stockage basée sur la mémoire est limitée, toutes les données ne peuvent pas tenir et le traitement peut ne pas être effectué en temps réel. Data 360 ajoute un magasin à faible latence (LLS) pour supprimer ces limitations, ce qui permet un traitement en temps réel évolutif.
Le magasin à faible latence est une couche de stockage NVMe (SSD) à l'échelle du pétaoctet dans Lakehouse. Les données ne doivent pas toutes être conservées dans le magasin à faible latence. C'est un cache durable. La plupart des données finissent par arriver à Lakehouse pour la persistance à long terme. Les données en session dans la couche temps réel peuvent être vidées vers le magasin à faible latence pour un accès rapide ultérieur. Par exemple, dans une conversation Agentic, les messages récents peuvent être traités en mémoire ; les anciens messages peuvent être vidés dans le magasin à faible latence. Si une conversation précédente est requise, elle est accessible en quelques millisecondes depuis le magasin à faible latence. Le stockage basé sur NVMe permet de stocker de grandes quantités de données et d'y accéder à des latences en millisecondes. Les données peuvent se frayer un chemin vers le stockage cloud Lakehouse pour la persistance à long terme. De plus, les données Lakehouse requises pour le traitement en temps réel ou pour augmenter les expériences en temps réel sont récupérées et conservées dans le magasin à faible latence. Par exemple, le contexte du profil client est pré-récupéré ou apporté depuis Lakehouse et mis en cache dans le magasin à faible latence. De plus, tous les objets Lakehouse et les autres objets requis pour le traitement en temps réel pendant le traitement en session peuvent également être mis en cache dans le magasin à faible latence.
Le magasin à faible latence Data 360 active la couche Real Timer dans une véritable hiérarchie de stockage avec des couches de stockage Lakehouse à mémoire (SSD), avec une migration transparente des données entre ces couches. Nous abordons la couche Data 360 Real Time plus loin dans ce document.
### Organisation des données
Salesforce Data 360 est conçu pour standardiser, harmoniser et activer toutes les données clients, structurées et non structurées, en suivant un cycle de vie rigoureux qui transforme l'entrée brute en un modèle de données unifié et actuel.
#### Cycle de vie des données et types d'objet
Le cycle de vie se concentre sur l'utilisation de diverses entrées de données externes et leur structuration en objets modélisés persistants. Les données modélisées peuvent être harmonisées dans des profils unifiés Customer 360.
**Données brutes ingérées et transformations initiales**
Le processus commence par les données brutes ingérées telles quelles à partir de systèmes sources (CRM, Marketing, fichiers, etc.). Cela inclut les chargements complets de données et les événements de modification continue (deltas), qui sont gérés et fusionnés avec des données persistantes pour maintenir un état actuel.
Les **transformations en ligne** (p. ex. rogner, normaliser, concaténer) sont immédiatement appliquées pendant l'ingestion afin d'assurer la qualité et la propreté préliminaires des données.
##### Objets lac de données (DLO) : La couche persistante
Les **objets lac de** données (DLO) forment la couche de stockage permanente principale dans Data 360. Ils stockent les données propres et transformées et servent de référentiel organisé à long terme pour toutes les informations sur les clients.
Des **transformations de données avancées** (p. ex. jointures, agrégations, connaissances calculées) sont appliquées aux objets lac de données sources pour produire de nouveaux objets lac de données dérivés hautement organisés.
Les données disponibles via la Fédération des données Zero Copy sont représentées directement sous forme d'objets lac de données.
**Organisation des données et métadonnées non structurées**
Pour des contenus non structurés (texte, média, documents), Data 360 incorpore les données en extrayant et en conservant ses métadonnées structurées dans des objets lac de données spécifiques appelés Objets lac de données non structurés (UDLO).
Ces objets lac de données spécialisés fonctionnent comme des tableaux d'annuaire, fournissant une carte de l'emplacement physique et du contexte des actifs non structurés. Cette capacité permet aux architectes d'associer de façon transparente les métadonnées de données non structurées avec le reste des données clients structurées, ce qui permet une interrogation et harmonisation unifiées.
##### Objets modèle de données (DMO) : La couche harmonisée
**Les objets modèle** de données (DMO) représentent la couche de données finale, harmonisée et structurée.
Ils sont créés en mappant des champs d'objet lac de données (à partir d'objets lac de données sources, dérivés et non structurés) avec le modèle standard Customer 360 Data Model.
La couche DMO agit en tant que source unique de preuve pour toutes les données des clients, permettant la création, la segmentation et l'activation de profils unifiés dans l'écosystème élargi.
#### Espace de données : Le conteneur logique
Un espace de données est le conteneur logique fondamental pour organiser toutes les données et métadonnées dans Data 360, y compris tous les objets lac de données (structurés et non structurés) et les objets modèle de données. Les espaces de données offrent un environnement sécurisé et isolé pour le traitement et la modélisation des données.
Les espaces de données agissent comme des frontières logiques et de gouvernance, permettant la multilocation interne en séparant les données d'entités distinctes telles que des unités commerciales, des régions ou des marques, tout en préservant la visibilité, la lignage et la conformité à l'échelle de l'entreprise, servant de base à la définition d'un contrôle d'accès grossier.
L'isolement dans les espaces de données est appliqué à plusieurs couches de la plate-forme :
- **Isolation au niveau des données**: Chaque objet lac de données/objet modèle de données appartient à un espace de données unique, ce qui garantit que les requêtes, les transformations et les mappages d'objets ne peuvent pas franchir les limites de l'espace de données, sauf autorisation explicite.
- **Intégration du contrôle d'accès**: Les ensembles d'autorisations sont liés nativement à des espaces de données, ce qui permet de contrôler les opérations de lecture, d'écriture et administratives. Ainsi, seuls les utilisateurs et les services autorisés peuvent accéder aux objets, aux connaissances et aux activations dans un espace de données.
- **Gouvernance et audit**: Toutes les opérations dans un espace de données sont consignées avec des pistes d'audit de niveau entreprise, ce qui permet la traçabilité de la conformité, de la gérance et des rapports réglementaires.
L'accès et les autorisations sont gérés via des ensembles d'autorisations, ce qui garantit une visibilité précise, des mises à jour contrôlées et la prévention des fuites de données entre les domaines. En intégrant les frontières de l'espace de données à l'architecture de sécurité et de gouvernance de Data 360, les architectes peuvent implémenter en toute confiance des stratégies de gouvernance centralisées et décentralisées tout en préservant la cohérence entre plusieurs clouds et domaines métiers.
#### Calculer le tissu
Data 360 Compute Fabric fournit une couche unifiée pour gérer et exécuter toutes les charges de travail Big Data, ce qui simplifie les complexités sous-jacentes de l'infrastructure. Son composant principal est le contrôleur de traitement des données (DPC).
DPC est un service complet d'orchestration du traitement des données à charges de travail multiples qui fournit des capacités de travail en tant que service (JaaS) dans divers environnements de calcul cloud. Il élimine la complexité de l'infrastructure et unifie l'exécution des tâches pour des infrastructures telles que Spark (EMR sur EC2 et EMR sur EKS) et les charges de travail Kubernetes Resource Controller (KRC). En servant de passerelle de plan de contrôle centralisée, DPC orchestre, planifie et surveille les tâches à travers plusieurs plans de données, garantissant fiabilité, évolutivité, rentabilité et expérience cohérente pour les développeurs.
Le besoin de DPC découle des limitations de l'interaction directe avec les systèmes de gestion de clusters natifs tels que le DME.
##### Abstraction de l'infrastructure et du cloud
EMR offre des API pour les clusters, les tâches et les étapes, mais il charge les équipes clientes avec des tâches de gestion d'infrastructure critiques telles que le provisionnement, la mise à l'échelle, l'ajustement des performances et l'optimisation des coûts. DPC y répond en offrant une API simplifiée au niveau de la plate-forme pour la soumission de tâches. Il prend en charge le traitement automatique des échecs, les tentatives et l'équilibrage de charge dynamique. Fournit un bon rapport coût-efficacité à travers les nœuds binpacking, spot et graviton. Fournit une sécurité renforcée avec l'isolation TLS, PKI, IAM et le correctif automatisé. Gère les mises à niveau de version d'exécution Spark et EMR pour améliorer les performances, les correctifs de sécurité et les fonctionnalités.
De plus, DPC fournit une interface cloud agnostique unifiée pour la soumission et la gestion des tâches de données, en faisant abstraction des complexités et des API propriétaires du substrat cloud sous-jacent (AWS, futurs fournisseurs). Cela garantit que les équipes clientes interagissent uniquement avec une interface de soumission de tâches basée sur l'API Data 360 commune qui élimine les complexités des gestionnaires de ressources sous-jacents tels que Kubernetes et YARN. Cela permet aux équipes clientes de soumettre des tâches Spark via une API simple et unifiée sans avoir à gérer directement les pods, les pools de nœuds ou les configurations de cluster Spark.
L'ajustement manuel des paramètres Spark nécessite des compétences spécialisées et des configurations incorrectes peuvent ralentir l'exécution des tâches. L'équipe DPC centralise cette expertise, en fournissant des configurations optimisées pour éviter les problèmes de performance courants. Cette équipe spécialisée intègre en permanence Knowledge de la communauté open-source afin de garantir des performances optimales à travers toutes les charges de travail gérées par le contrôleur.
DPC n'est pas limité à Spark, il prend en charge un large éventail de charges de travail. Il s'agit notamment de :
- Charges de travail de traitement en temps réel
- Fonctionnalité Livraison d'événements pour Actions de données
- Gestion de Milvus (la base de données vectorielle pour l'indexation des données non structurées)
- Infrastructure de stockage à faible latence
DPC exploite également l'infrastructure **Kubernetes Resource Controller (KRC)**, qui prend en charge des charges de travail telles que Trino pour les requêtes, Event Delivery pour les actions de données, les tâches d'extraction de données pour les connecteurs et le traitement en temps réel. Pour toutes les charges de travail KRC, DPC fournit des capacités centrales de travail en tant que service, qui gèrent le provisionnement, le déploiement et la gestion du calcul à un niveau élevé d'abstraction des tâches.
##### Avantages et architecture JaaS
Le modèle Job-as-a-Service, fourni par DPC, garantit un pipeline de traitement des tâches économique et résilient.
Les utilisateurs fournissent des spécifications de cluster simples, en se concentrant sur le processeur, la mémoire, le stockage, le nombre d'instances, ainsi que le nombre de clusters Min/Max et les balises de correspondance de cluster. DPC gère ensuite automatiquement les détails abstraits de l'infrastructure, notamment la sélection d'UGS de machine virtuelle optimales, la gestion des flottes d'instances, la détermination du ratio Core/SKU. Nœuds de tâche et gestion à la demande par rapport à Repérez les instances en fonction des entrées. Il gère également la gestion des DME et des versions de composants, ainsi que les mises à niveau sans temps d'arrêt.
Essentiellement, DPC prend en charge la multilocation, conçue pour comprendre et appliquer les limites de la location Data 360 et la séparation des ressources. Il garantit également la sécurité et la conformité en appliquant automatiquement les images machine certifiées Salesforce, en gérant les rôles IAM spécifiques au service et en garantissant le cryptage en transit et au repos. Pour l'acheminement et le contrôle de la capacité, la correspondance tâche à cluster est gérée en utilisant des Balises de cluster, et l'acheminement basé sur la capacité utilise un paramètre de concurrence de tâches maximum pour contrôler efficacement l'utilisation des ressources.
L'expérience client Cloud Agnostic est un avantage essentiel, car la complexité des environnements Cloud sous-jacents est masquée pour les services clients, ce qui leur permet de se concentrer uniquement sur la logique métier. Cela atteint l'objectif de l'abstraction des fournisseurs de cloud. Enfin, DPC facilite le suivi de l'utilisation et des coûts, ce qui permet de segmenter l'utilisation et les coûts des clusters par service pour une comptabilité précise. Globalement, DPC suit une architecture enfichable qui permet d'intégrer de façon transparente de nouveaux moteurs d'exécution (par exemple Flink, Ray) et des substrats cloud (GKE/Dataproc) sans exposer aux utilisateurs les détails sous-jacents de l'infrastructure. Cette conception découple le plan de contrôle de la couche d'exécution, ce qui garantit une API et une expérience opérationnelle cohérentes, quel que soit le back-end.
### Traitement des données dans Data 360 : De brut à actionnable
Data 360 affine et enrichit les données brutes, en comblant le fossé entre les informations brutes et la consommation métier actionnable. Il complète le cycle de vie des objets de données en préparant des données complexes pour une activation et une analyse sophistiquées. Data 360 prend en charge divers types de traitement, notamment les Transformations de données par lot et en continu, les Connaissances calculées par lot et en continu, le Traitement des données non structuré et la Résolution de l'identité. Pour permettre efficacement ces diverses opérations, en particulier en temps quasi réel et à travers des jeux de données massifs, un mécanisme sophistiqué est nécessaire pour gérer efficacement les modifications des données.
#### Alimentation du traitement incrémentiel
Pour obtenir un traitement efficace et en temps quasi réel des données, en particulier avec des tableaux de taille en téraoctets et des millions de mises à jour potentielles, Data 360 avait besoin d'une percée. Elle nécessitait un moyen de notifier les systèmes avec précision lorsque les données changeaient, puis d'identifier efficacement les données modifiées afin que seules les mises à jour pertinentes soient traitées et uniquement lorsqu'elles sont mises à jour. Ce défi a conduit à deux innovations complémentaires : Événements de modification natifs du stockage (SNCE) pour notifier une modification et Fil de données de modification (CDF) pour identifier les modifications.
##### Événements de modification natifs du stockage (SNCE)
SNCE a fondamentalement transformé Data 360 en une plate-forme de données réactive et incrémentielle. Ce changement implique de passer d'une interrogation active du lac de données à une surveillance passive des événements d'engagement atomique, en utilisant un format d'événement standardisé et un système de livraison de messages à haut débit.
Chaque opération d'écriture réussie (INSÉRER, METTRE À JOUR, SUPPRIMER) dans un tableau Iceberg aboutit à un échange atomique du pointeur de fichier de métadonnées actuel du tableau dans le catalogue. La couche de stockage d'objet sous-jacente (par exemple S3) est configurée pour émettre un événement de notification natif (par exemple un événement S3) chaque fois qu'un nouvel instantané de métadonnées est écrit dans le répertoire du tableau.
La bibliothèque SNCE offre une méthode standardisée pour consommer ces événements, et peut également les enrichir avec des métadonnées de clichés instantanés sur demande.
Cela permet aux pipelines de données en aval, tels que les connaissances calculées en continu, la résolution de l'identité et la segmentation, de s'abonner et d'agir uniquement lorsque les données ont changé, ce qui augmente considérablement l'efficacité en évitant les analyses coûteuses de tableaux complets.
##### Modification du fil de données (CDF)
En s'appuyant sur SNCE, le Fil de données de modification (CDF) fournit un mécanisme rationalisé pour consommer et traiter progressivement les modifications.
CDF exploite les clichés instantanés Iceberg pour générer efficacement le flux de modifications. L'éditeur Iceberg optimisé de Data 360 calcule et conserve les modifications dans le cadre de l'opération d'écriture elle-même, ce qui rend la génération de CDF très efficace et réduit les surcharges supplémentaires. Cela permet aux tâches de traitement (telles que les transformations en continu ou les connaissances calculées en continu) de traiter sélectivement uniquement les enregistrements altérés, ce qui évite le calcul coûteux des différences de clichés instantanés.
Cette stratégie incrémentielle offre plusieurs avantages pour les jeux de données volumineux, notamment des économies, une latence réduite et une efficacité accrue. Il active des fonctionnalités telles que les transformations en continu et la résolution incrémentielle de l'identité, qui entraînent à leur tour des connaissances plus rapides, des charges système plus prévisibles, des performances améliorées et une réduction des dépenses opérationnelles.
### Connexion, ingestion et préparation
Data 360 offre des capacités d'ingestion robustes avec la prise en charge native des produits Salesforce, ce qui garantit un flux de données transparent. Pour des sources externes, il fournit une connectivité étendue via plus de 270 connecteurs, API, kits de développement et MuleSoft. De plus, Data 360 offre une fédération sans copie, ce qui permet d'effectuer des analyses analytiques sans duplication des données.
#### Infrastructure du connecteur Data 360
L'infrastructure de connecteur Data 360 (DCF) est la base de la plupart des connectivités Data 360. Il permet l'ingestion, la fédération et la sortie à travers une architecture unifiée. DCF définit les normes d'élaboration et de gestion des connecteurs, depuis l'interface utilisateur pour la configuration et l'administration jusqu'à la persistance des métadonnées, l'extraction et la livraison de données dans Lakehouse ou via des requêtes live avec des sources externes. Il prend également en charge les options de connectivité privées (telles que les liens privés, les VPN et les tunnels sécurisés) pour garantir la sécurité et la conformité des données de niveau entreprise lors de la connexion à des environnements clients ou partenaires. En offrant une approche cohérente à travers tous les connecteurs, DCF permet à Data 360 de se connecter de façon transparente à l'écosystème élargi en garantissant l'extensibilité, la fiabilité et l'intégration sécurisée.
#### Connecteurs Data 360
Data 360 fournit une connectivité robuste à un vaste écosystème de sources de données, prenant en charge les produits Salesforce natifs et de nombreux systèmes externes. Cette connectivité étendue est cruciale pour unifier les données d'entreprise cloisonnées et activer les applications IA/ML et Agentic.
Data 360 offre plus de 270 connecteurs en natif ou via MuleSoft, des API et des kits de développement pour prendre en charge ses capacités de pipeline de données de bout en bout avec l'ingestion par lot, en continu ou en temps réel. Ces connecteurs peuvent être classés globalement par type de système source qu'ils intègrent.
**Connecteurs Salesforce Native**
Ces connecteurs garantissent un flux de données transparent et natif à partir des produits Salesforce.
Par exemple, les connecteurs Salesforce CRM, Data Cloud One , Marketing Cloud Engagement, Marketing Cloud Account Engagement et B2C Commerce.
**Applications externes et SaaS**
Les connecteurs pour diverses applications métiers et services cloud permettent l'ingestion de données à partir de plates-formes logicielles externes.
Adobe Marketo Engage, Microsoft Dynamics 365, Mailchimp et Airtable en sont des exemples.
**Bases de données et entrepôts de données**
Data 360 se connecte à une variété de plates-formes de stockage de données relationnelles et basées sur le cloud.
Amazon Redshift, Amazon DynamoDB, Amazon RDS (MySQL, PostgreSQL, Oracle), Google BigQuery et Microsoft SQL Server en sont des exemples.
**Systèmes de stockage et de fichiers d'objets Cloud**
Ces connecteurs s'intègrent à des solutions de stockage hyperscaler pour des données structurées et non structurées.
Amazon S3, Google Cloud Storage (GCS) et Azure Blob Storage en sont des exemples.
**Services de streaming et de messagerie**
Les connecteurs qui gèrent des flux de données continus et en temps réel sont essentiels pour les scénarios pilotés par l'événement et le traitement en temps réel.
Un exemple est le connecteur Amazon Kinesis.
**Plateformes d'intégration**
Le connecteur MuleSoft Anypoint étend la portée de Data 360 en l'intégrant à un plus grand nombre d'applications et de bases de données via Anypoint Exchange.
**Connecteurs de stockage de données et d'objets Cloud non structurés**
Ces connecteurs sont essentiels pour ingérer et référencer des données non structurées (données sans modèle prédéfini) afin d'alimenter les capacités d'IA générative.
Tous ces connecteurs sont construits sur l'infrastructure de connecteur Data 360 offrant une expérience cohérente.
#### Transformations de données
La transformation des données est un composant architectural fondamental dans Data 360, conçu pour nettoyer, enrichir et mettre en forme les données ingérées brutes en actifs de données normalisés et actionnables alignés sur le modèle de données Customer 360. Ce processus est essentiel à l'harmonisation, à l'amélioration de la qualité et à la préparation des données pour des cas d'utilisation en aval tels que l'unification, la segmentation et l'activation de profils. Les transformations exploitent les objets lac de données sources (DLO) et les objets modèle de données (DMO) en entrée, produisant les résultats respectivement vers de nouveaux objets lac de données ou objets modèle de données.
Data 360 fournit deux paradigmes de transformation principaux pour répondre à différentes exigences de vitesse des données : les transformations de données par lot et les transformations de données en continu.
##### Transformations de données par lot
Les transformations de données par lot sont conçues pour le traitement à haut volume basé sur une planification définie ou un déclencheur à la demande. Ce moteur est optimisé pour gérer les opérations de restructuration complexes et gourmandes en ressources.
Le processus de transformation par lot est configuré en utilisant une zone de dessin visuelle à faible code du pipeline qui permet aux utilisateurs de définir une logique de transformation à plusieurs étapes. Ce moteur prend en charge de façon unique les opérations de restructuration complexes essentielles à l'alignement canonique des modèles de données : la structuration et la normalisation des données. Cela inclut le pivotement (décomposition des enregistrements dénormalisés en plusieurs enregistrements normalisés) et l'aplatissement (restructuration des données hiérarchiques, par exemple JSON, en tableaux structurés). Le mode d'exécution du système prend en charge la synchronisation complète (traitement de tous les enregistrements) et un mode de traitement incrémentiel très efficace. Le mode incrémentiel réduit considérablement le temps de traitement et la consommation de ressources en traitant uniquement les enregistrements qui ont changé depuis la dernière exécution réussie. Les transformations par lot sont idéales pour les tâches dans lesquelles les mises à jour en temps réel ne sont pas essentielles, par exemple les agrégations périodiques et la restructuration de données complexes.
##### Transformations de données en continu
Les données en continu transforment les données de traitement de façon continue et incrémentielle en temps quasi réel à mesure qu'elles entrent dans le système, ce qui les rend essentielles pour les cas d'utilisation à faible latence.
L'interface principale est une approche SQL-first, dans laquelle les transformations sont définies en tant que requête SQL SELECT qui s'exécute en permanence contre le flux entrant de modifications d'enregistrement. Ce moteur prend en charge les principales fonctions de transformation, notamment le nettoyage et la normalisation des données (par exemple, la validation des informations d'identification personnelle et la normalisation des formats de données), ainsi que l'enrichissement et la fusion des données (en utilisant des jointures et des unions). Il prend en charge les Streaming Lookup JOINS pour activer l'enrichissement des données en temps réel et les références aux données de référence statiques ou en évolution lente, ce qui garantit des mises à jour instantanées du profil. Pour optimiser le rapport coût-service, l'architecture utilise une conception de tâche Haute densité (HD), qui regroupe plusieurs définitions de transformation en continu pour un locataire unique dans une seule tâche de calcul sous-jacente, ce qui optimise l'utilisation des ressources. Les transformations en continu sont essentielles pour des cas d'utilisation tels que la surveillance des événements, la personnalisation immédiate et les mises à jour de profil en temps réel.
### Fédération de données zéro copie et partage de données
Data 360 révolutionne la gestion des données en prenant en charge la fédération Zero Copy et le partage de données, ce qui élimine la nécessité de déplacer ou de dupliquer les données. Cette capacité permet aux utilisateurs d'accéder de façon transparente et directe aux données de diverses sources externes et de partager des données avec des environnements externes, ce qui réduit considérablement la complexité, réduit les coûts de stockage et garantit que toutes les décisions sont basées sur les informations les plus récentes et les plus fiables.
Pour y remédier, Data 360 prend en charge la connectivité privée au niveau du réseau avec des sources de données gérées par les clients à travers les clouds. Dans AWS, cette fonctionnalité est activée via AWS PrivateLink, qui permet à Data 360 de se connecter directement à des points de terminaison provisionnés par le client, soit dans ses propres comptes, soit dans des environnements de lac de données tiers (par exemple Snowflake), sans passer par l'Internet public.
Cette architecture garantit que tout le trafic reste entièrement sur le backbone AWS, en utilisant l'adressage IP privé et des chemins réseau non-routiers, satisfaisant ainsi aux exigences strictes de sécurité et de conformité tout en permettant un accès transparent aux données des clients.
#### Interconnexion privée
Pour les clients qui ont des architectures multicloud, Data 360 étend la connectivité privée au-delà d'AWS grâce à la prise en charge de l'interconnexion inter-clouds. Cela permet de sécuriser les chemins réseau backbone uniquement depuis Data 360 vers des lacs de données et des services hébergés dans Azure ou Google Cloud, en préservant les mêmes principes que AWS PrivateLink : adressage IP privé, acheminement non public et exposition à Internet nulle.
Les clients peuvent choisir entre deux modèles de déploiement :
- **Interconnexion gérée par les clients**: Intégrez des circuits privés existants tels que Azure ExpressRoute, Google Cloud Interconnect ou Equinix Fabric directement aux VPC de Data 360.
- **Interconnexion gérée par Salesforce**: Utilisez une connexion clé en main entièrement gérée dans laquelle Salesforce provisionne et exploite la liaison inter-clouds, exposant les points de terminaison privés dans le cloud cible.
Dans les deux modèles, l'expérience est cohérente : Les services Data 360 se connectent à des sources de données externes à travers des hyperscalers comme s'ils étaient locaux, ce qui permet une ingestion, une activation et une interrogation sécurisées sans passer par l'Internet public.
### Gouvernance des données dans Data 360 : Une fondation de Trust et de Contrôle
Pour les architectes d'entreprise, une gouvernance des données robuste n'est pas seulement une case à cocher de conformité mais un pilier fondamental pour élaborer une Intelligence client fiable, évolutive et actionnable. Salesforce Data 360 est conçu avec un cadre de gouvernance complet qui garantit la qualité des données, la sécurité et le respect des mandats réglementaires tout au long de leur cycle de vie.
Data 360 fonctionne comme une plate-forme de gouvernance centralisée, garantissant que toutes les données, depuis l'ingestion brute jusqu'aux connaissances activées, sont gérées avec intégrité et contrôle.
#### Contrôle d'accès avancé : Pourquoi le contrôle d'accès basé sur l'attribut (ABAC)
Alors que l'espace de données fournit un contrôle d'accès approximatif pour déterminer l'accès à tous les objets d'un espace de données, les stratégies basées sur ABAC fournissent un contrôle d'accès précis aux objets, aux champs et aux lignes individuels d'un espace de données. Data 360 a adopté le Contrôle d'accès basé sur l'attribut (ABAC) comme modèle d'autorisation principal pour le contrôle d'accès précis. Ce choix stratégique offre une flexibilité et une évolutivité supérieures au Contrôle d'accès basé sur le rôle (RBAC) traditionnel, particulièrement crucial pour les environnements d'entreprise dynamiques et complexes avec de grandes quantités de données et des besoins d'accès variés. ABAC permet de prendre des décisions en matière d'accès en fonction des attributs de l'utilisateur (p. ex., service, rôle, emplacement), des données (p. ex., informations d'identification personnelle, sensibilité, espace de données) et de l'environnement (p. ex., heure du jour), plutôt que de simples rôles prédéfinis. Cela permet des stratégies d'accès très précises et contextuelles qui s'adaptent à mesure que les données et les attributs utilisateur changent.
- **CEDAR Policy Language**: L'utilisation du langage de stratégie CEDAR est au cœur de l'implémentation ABAC de Data 360. Ce langage de politique formel spécialement conçu fournit une méthode précise et vérifiable pour définir des règles d'autorisation complexes, garantissant que les politiques sont sans ambiguïté et peuvent être évaluées de façon cohérente à l'échelle.
#### Architecture de gouvernance : Informations sur la politique, application et points de décision
Le système de gouvernance de Data 360 respecte une architecture ABAC robuste et standard :
- **Marquage, classification et rédaction de politiques (point d'information sur les politiques - PEP)**:
- Data 360 fournit des mécanismes automatisés de balisage et de classification, en exploitant le LLM (grand modèle de langage) et le ML (apprentissage machine) pour identifier des catégories de données confidentielles (par exemple, PII.Email, PII.Phone, PII.Name) et d'autres taxonomies spécialement conçues (PHI, FinancialData) à la fois dans les Données structurées (par exemple, tableau Contacts) et dans les Données non structurées (par exemple depuis Google Drive).
- Essentiellement, la propagation des balises se produit le long du Lignage de données (DLO -> DLO -> DMO), ce qui garantit que les classifications suivent automatiquement les transformations et les dérivations des données, depuis les données ingérées brutes jusqu'à la couche DMO harmonisée et via les données dérivées créées à partir de définitions de processus.
- Enfin, le volet de création de stratégies offre une expérience simple qui permet d'exploiter les données et les attributs utilisateur afin de définir des règles d'accès dynamiques pour une organisation.
- Ces métadonnées enrichies (y compris les balises, les classifications, les politiques et la lignée) alimentent le Point d'information sur les politiques (PIP).
- **Service d'autorisation (Policy Enforcement Point - PEP)**:
- Le service d'autorisation agit en tant que point d'application de la politique (PEP). Il intercepte toutes les requêtes d'accès aux données de diverses couches de consommation (Requête structurée/non structurée hybride, Récupérateurs et invites GenAI RAG, Enrichissement CRM) et consulte le Point de décision de la politique pour déterminer si l'accès est autorisé.
- **Moteur d'évaluation des politiques (point de décision de politique - PDP)**:
- Ce moteur sert de point de décision stratégique (PDP). Il prend le contexte de la demande d'accès du PPE, avec les définitions de politique (dans CEDAR) et les attributs du PEP, pour prendre une décision d'accès faisant autorité.
#### Application et intégration des politiques clés
- **Stratégies de sécurité granulaire**: Les politiques définies dans CEDAR appliquent divers niveaux de sécurité, notamment :
- **Sécurité au niveau objet**: Contrôle de l'accès à des objets lac de données ou objets modèle de données complets en fonction des balises associées à ces objets.
- **Sécurité au niveau champ**: Limitation de l'accès à des champs sensibles spécifiques dans un objet en fonction des balises.
- **Sécurité au niveau**: ligne Filtrage des données sur des objets spécifiques pour afficher uniquement les lignes pertinentes en fonction des attributs utilisateur.
- **Masquage dynamique des données**: Masquez dynamiquement certaines données (basées sur des balises) au point d'accès, sans altérer les données sous-jacentes. Cela garantit la protection des informations confidentielles tout en permettant une large utilité. Cela s'applique au masquage de champs dans des données structurées ainsi que de contenus dans des données non structurées.
- **Application cohérente**: L'infrastructure ABAC complète garantit l'application cohérente des politiques dans tous les modèles de consommation de Data 360, qu'il s'agisse d'interrogation directe de données, de récupération pour des applications d'IA générative (RAG) ou d'enrichissement des expériences Salesforce CRM via des listes associées, par exemple.
- **Intégration approfondie à Salesforce Platform**: Les capacités de gouvernance de Data 360 sont définies et administrées directement depuis la plate-forme principale de Salesforce. Cette intégration permet aux administrateurs de gérer les stratégies d'accès, l'identité des utilisateurs et la gestion des attributs en utilisant des outils Salesforce familiers, ce qui garantit une couche de gouvernance unifiée et cohérente dans l'ensemble de l'écosystème Salesforce.
En élaborant cette infrastructure ABAC sophistiquée avec des politiques CEDAR, Data 360 offre aux architectes un niveau de contrôle et de flexibilité inégalé, garantissant que les données des clients sont non seulement actionnables, mais également sécurisées, conformes et fiables dans l'ensemble de l'entreprise.
### Data 360 Encryption : Bring Your Own Key
Dans tous les secteurs d'activité, les organisations mettent davantage l'accent sur la sécurité des données de bout en bout afin d'assurer la protection contre les fuites de données, les accès non autorisés, l'altération ou la destruction. La plupart des plates-formes de données, y compris Data 360 aujourd'hui, fournissent le cryptage au repos en utilisant une clé de cryptage gérée par le fournisseur. Cependant, les entreprises (en particulier celles des secteurs réglementés) exigent de plus en plus des capacités de cryptage gérées par les clients pour les données au repos et en transit.
Ce modèle permet aux entreprises de contrôler leurs propres clés de cryptage, ce qui garantit que même dans le cas très improbable d'une violation au niveau de la plate-forme ou d'un accès non autorisé, les données restent protégées cryptographiquement. Sans la clé propriétaire du client, aucune entité (y compris le fournisseur de la plate-forme) ne peut décrypter ou reconstruire les données, préservant ainsi une confidentialité et un contrôle complets.
### Stockage et traitement des données non structurées
Data 360 prend en charge le stockage et la gestion des données structurées (tableaux), semi-structurées (JSON) et non structurées de façon transparente à travers les mécanismes d'ingestion, de traitement, d'indexation et de requête des données. Data 360 prend en charge divers types de données non structurés au-delà du texte, notamment le son, la vidéo et les images, ce qui élargit la portée du traitement et de l'analyse des données. La figure ci-dessous illustre les deux côtés de l'ancrage (ingestion et récupération).
Le processus principal est géré par un service d'orchestration de tâches qui contrôle le cycle de vie du segment, générant la configuration de tâches nécessaire et déclenchant l'exécution. Cette couche d'orchestration conserve l'état et les métadonnées dans une base de données sharded pour l'évolutivité.
Bien que Data 360 Query gère les calculs de décompte de segmentation, la couche de calcul Spark est responsable du calcul de l'appartenance réelle au segment. L'application Spark exécute des requêtes Spark SQL sur de nombreuses données clients. Ces données peuvent résider dans Data 360 Lakehouse, dans des systèmes externes via la fédération de données Zero Copy, ou dans une combinaison des deux.
Le système est hautement optimisé grâce à la génération intelligente de requêtes, qui affine la requête Spark SQL sous-jacente. Cela inclut des techniques telles que l'élagage intelligent des partitions afin de minimiser l'analyse des données et l'élimination des sous-expressions redondantes. Pour garantir la fiabilité du service, l'architecture offre une gestion adaptative des ressources qui ajuste dynamiquement les ressources de calcul en fonction de la taille et de la complexité de la charge de travail. De plus, l'adhésion à la SLO est gérée proactivement avec des durées adaptatives et une logique de nouvelle tentative. Pour une expérience utilisateur rapide, les décomptes de segments accélérés utilisent une approche basée sur l'échantillonnage afin de fournir des estimations de taille rapides pendant la création de segments, évitant ainsi une exécution de requête complète.
Enfin, l'accent est mis sur l'observabilité et l'attribution des causes premières grâce à des métriques d'exécution Spark complètes et à la classification automatisée des erreurs (par exemple, problèmes côté client ou système), ce qui réduit considérablement le temps de diagnostic et garantit une plate-forme de données hautement résiliente.
### Activation
L'activation est la dernière étape critique du cycle de vie de Data 360. Sa fonction principale est de transformer des profils clients statiques, segmentés et unifiés en données actionnables et enrichies, et de livrer ces données à des points de terminaison internes et externes (tels que Marketing Cloud, Commerce Cloud et les plates-formes Adtech). Ce processus est conçu pour déclencher des parcours clients personnalisés et des interactions en temps quasi réel. Il prend en charge des capacités avancées telles que les attributs associés, le filtrage des appartenances d'activation, le filtrage du consentement, la limitation et le classement.
L'activation offre trois méthodes distinctes pour la livraison externe et la conformité du canal :
- **Activation par lot**: Conçu pour les opérations planifiées à haut volume, telles que les campagnes par e-mail à grande échelle et les actualisations d'audience publicitaire. Les données sont livrées en les organisant dans des compartiments internes sécurisés (Cloud Object Storage) ou via un transfert de fichiers sécurisé, suivi d'un processus d'ingestion d'API initié par le système cible. Les activations par lot peuvent utiliser un mode d'actualisation spécial - incrémentiel - pour réduire les volumes envoyés à et traités par les partenaires Salesforce.
- **Activation en continu**: Optimisé pour les cas d'utilisation en temps quasi réel nécessitant une automatisation pilotée par l'événement. La livraison est réalisée par des appels d'API directs envoyés au point de terminaison de destination.
- **Flux déclenchés par l'activation**: Ce canal hautement plate-forme fournit une approche sans code/code faible pour intégrer les données d'audience à des centaines de plates-formes d'engagement activées par l'API client. Une fois l'activation terminée, Data 360 remplit un objet modèle de données Audience, qui déclenche ensuite un flux à grande échelle. Le moteur de flux consomme ensuite les données d'audience et utilise les capacités de la plate-forme telles que les Services externes et les destinations Mule Outbound pour passer des appels vers la destination finale basée sur l'API. Cette méthode réduit considérablement le temps nécessaire pour intégrer de nouvelles cibles d'activation.
L'activation utilise les mêmes modèles que la segmentation pour la gestion des tâches, l'exécution distribuée et la surveillance. Cela inclut les principes du service d'orchestration des tâches pour la gestion du cycle de vie et de la couche de calcul (Spark) pour le traitement, et s'appuie sur la télémétrie des tâches pour l'observabilité des performances et l'adhésion aux objectifs de niveau de service (SLO).
En plus de cela, l'activation a -
**Activation Target Management** supervise les connexions, les identifiants et les configurations sécurisés pour tous les points de terminaison de destination. Il garantit la normalisation des formats de données et des protocoles de sécurité, ce qui garantit une livraison sortante fiable à diverses plates-formes, notamment Marketing Cloud, des partenaires Adtech et d'autres applications externes.
L'activation adapte la charge de travail à des objectifs spécifiques. Pour Salesforce Marketing Cloud, cela inclut le filtrage sensible aux unités commerciales (BU), la prise en charge des ID multiples et les contrôles de pollinisation croisée.
La **Gouvernance des communications** agit en tant que gardienne, en veillant à ce que l'utilisation et la communication des données soient conformes aux préférences des clients et aux exigences légales. Le modèle de consentement centralisé unifie toutes les préférences des clients, depuis le désabonnement global jusqu'au consentement spécifique au canal et à l'objet, et sont stockées dans le profil Individu unifié. Pendant l'exécution, la plate-forme applique strictement ces stratégies en utilisant le filtrage d'exclusion pour retirer automatiquement les individus non consentants de la charge utile finale. De plus, le système applique des règles de sélection de points de contact pour s'assurer d'utiliser le point de contact unique, le plus conforme et le plus préféré pour le canal prévu avant la transmission des données. Ce mécanisme d'application est sécurisé par le cadre de gouvernance sous-jacent, qui utilise des mesures de protection telles que le masquage dynamique des données et des contrôles d'accès afin de sécuriser les champs de données confidentielles tout au long du processus d'activation.
### Requête unifiée : Accès transparent à toutes les données des clients
La véritable valeur d'une plate-forme de données unifiée réside dans sa capacité à fournir un accès cohérent et sans effort à tous ses actifs de données, quelle que soit leur origine ou leur structure. La capacité Requête unifiée de Salesforce Data 360 est précisément conçue pour fournir cette fonctionnalité, en éliminant les complexités sous-jacentes des divers magasins de données pour fournir une interface de requête unique et puissante.
La couche Requête unifiée offre un accès sophistiqué à divers modèles de consommation :
- **Interrogation hybride structurée et non structurée**: Il fournit une prise en charge SQL étendue pour interroger de façon transparente à la fois les données structurées et les métadonnées structurées de données non structurées. L'extensibilité de l'opérateur via des fonctions de tableau permet d'effectuer des recherches spécialisées dans les types de texte, d'image et d'espace.
- **Accélération des performances avec Hyper**: Exploitant Hyper, un moteur en mémoire très performant, Data 360 accélère les requêtes analytiques complexes et les tableaux de bord interactifs, en fournissant des réponses quasi instantanées sur des jeux de données massifs.
- **Approche unifiée pour l’IA et la personnalisation**: Cet accès unifié est crucial pour générer des résultats ciblés et personnalisés, facilitant directement des réponses LLM plus précises en utilisant la génération augmentée de récupération (RAG) en ancrant les modèles IA dans des données d’entreprise enrichies.
- **Intégration à la consommation en aval**: Il sert de couche d'accès aux données de base pour les expériences pilotées par l'interface utilisateur, les API robustes, les workflows d'IA générative et l'enrichissement CRM, en connectant de façon transparente les données à l'activation.
En fournissant une interface de requête unique, intelligente et très performante, la requête unifiée de Data 360 permet aux architectes de créer des applications agiles pilotées par les données qui exploitent pleinement leur éventail complet d'informations sur les clients.
### Actions de données
Data 360 est une plate-forme active qui prend en charge l'activation de pipelines en réponse à des événements de données. Par exemple, un événement important, par exemple une baisse du solde du compte d'un client, peut déclencher un flux Salesforce pour orchestrer une action correspondante. De la même façon, les mises à jour des métriques clés, telles que la durée de vie, peuvent être automatiquement propagées aux applications appropriées.
Les Actions de données surveillent en permanence les données incrémentielles des modifications en utilisant les événements de modification natifs du stockage (SNCE) et le fil de données de modification (CDF). Ces données sont évaluées par rapport aux règles d'action configurées par le client, telles que la surveillance du seuil ou les changements d'état. Lorsque ces règles sont remplies, un événement d'action de données est généré. Cet événement est enrichi d'informations supplémentaires (par exemple, le statut de fidélité client) et immédiatement envoyé à sa destination configurée, par exemple Salesforce Flow ou une application externe, pour déclencher des orchestrations métiers.
#### Plate-forme des données clients
Data 360 prend en charge les fonctionnalités natives de CDP (Customer Data Platform), notamment les capacités avancées de résolution de l'identité, la création d'identifiants et de profils individuels unifiés, ainsi que des historiques d'engagement complets. Cette plate-forme est capable de gérer les infrastructures entreprise à entreprise (B2B) et entreprise à consommateur (B2C) en prenant en charge la résolution de l'identité et les graphiques d'identité qui utilisent des règles de correspondance exactes et partielles, comme décrit ci-dessus. Ces graphiques d'identité sont enrichis avec les données d'engagement de divers canaux, ce qui aide à élaborer des graphiques de profil détaillés avec des connaissances analytiques et des segments précieux.
Un concept clé qui prend en charge le profil client est le graphique des données. Data 360 offre un graphique de données d'entreprise au format JSON, qui est un objet dénormalisé dérivé de divers tableaux Lakehouse et de leurs interrelations. Cela inclut un graphique de données « Profil » créé par CDP qui inclut l'historique d'achat et de navigation, l'historique des requêtes, l'utilisation des produits et d'autres connaissances calculées d'une personne, et qui est extensible par les clients et les partenaires. Ces Graphiques de données sont adaptés à des applications spécifiques et améliorent la précision des invites d'IA générative en fournissant un contexte client ou utilisateur pertinent. La couche en temps réel de Data 360 utilise le graphique Profil pour la personnalisation et la segmentation en temps réel. Nous envisageons de modéliser Contexte Agentforce qui englobe sous forme de Graphiques de données Conversations, Sessions et Mémoire Agentique.
De plus, le CDP permet une segmentation et une activation efficaces sur différentes plates-formes telles que Marketing Cloud, Facebook et Google de Salesforce. Il traite les profils clients par lot, en temps quasi réel et en temps réel, ce qui permet une prise de décision et une personnalisation immédiates. Cette fonctionnalité améliore les interactions dans les scénarios B2C et B2B, ce qui permet aux entreprises de répondre rapidement et avec précision aux besoins et aux comportements des clients.
### Couche en temps réel
La couche temps réel de Data 360 est soutenue par Data 360 CDP et étend ses concepts pour des cas d'utilisation en temps réel. La couche en temps réel de Data 360 est conçue pour traiter des événements tels que les flux de clics Web et mobiles, les visites, les données de panier d'achat et les paiements à des latences en millisecondes, ce qui améliore la personnalisation de l'expérience client. Il surveille en permanence l'engagement des clients et met à jour le profil client depuis Customer 360 avec des données d'engagement en temps réel, des segments, et des calculs pour une personnalisation immédiate.
Par exemple, lorsqu'un consommateur achète un article sur un site Web d'achat, la couche en temps réel détecte et ingère rapidement cet événement, identifie le consommateur et enrichit son profil avec des informations actualisées sur les dépenses à vie. Cela permet de personnaliser leur expérience sur le site en quelques secondes. De plus, cette couche inclut des capacités de déclenchement et de réponse en temps réel, qui permettent des actions immédiates basées sur les interactions des clients.
La plate-forme Sub-Second Real-Time pilote cette transformation à travers plusieurs fonctionnalités clés :
1. **Graphiques de données en temps réel**: Un profil Customer 360 est construit en utilisant un graphique dénormalisé qui inclut les objets clés et les champs les plus pertinents pour les marques. Ces Graphiques de données permettent le traitement des données en temps réel et fournissent des contenus et des connaissances actionnables en quelques millisecondes
2. **Ingestion et transformation en temps réel**: Ingérez des événements utilisateur et un profil en millisecondes à partir de sources Web et mobiles.
3. **Résolution de l'identité en temps réel**: Fusionnez les profils clients entre les appareils, en unifiant instantanément les utilisateurs inconnus et connus.
4. **Connaissances calculées en temps réel**: Calculez des métriques telles que la valeur de durée de vie (LTV) ou l'historique des visites utilisateur en millisecondes pour activer Personnalisation ou Offres pour le Web, ChatBot ou Agent de service.
5. **Segmentation en temps réel**: Segmentez les audiences en temps réel, en personnalisant les messages et les interactions.
6. **Actions en temps réel**: Permettez aux marques d'évaluer chaque engagement des utilisateurs et de prendre des mesures via Salesforce Flow ou d'autres canaux de communication appropriés.
Dans Data 360, nous avons élaboré une nouvelle plate-forme en temps réel avec un pipeline en temps réel, un stockage à faible latence et une couche de traitement des données de moins de deux secondes. Comme les données interactives rapides sont ingérées à partir de canaux Web et mobiles, elles passent par une série de processus rapides.
Nos kits de développement Web et mobiles et nos API en temps réel collectent les données d'applications Web/mobiles (dans les futures interactions Agentic) et les envoient à notre serveur de balise. Ces données sont ensuite acheminées vers la couche Temps réel pour le traitement en millisecondes et la couche Lakehouse pour l'intégration à des données par lot/streaming. La couche Temps réel traite les données en temps réel entrantes dans le contexte d'un profil utilisateur (anonyme ou connecté), par exemple la mise à jour de la dépense totale ou de la valeur de durée de vie de l'utilisateur, etc., pour une personnalisation en session et en temps réel. La couche en temps réel est soutenue par la mémoire principale et le stockage NVme (SSD) pour stocker des données en temps réel et des profils clients. Une fois les données dans la couche Temps réel, elles suivent les processus suivants avant d'être mises à jour dans le graphique de données en temps réel :
- **Ingestion simple et transformations**: Les données sont ingérées et transformées pour un traitement ultérieur.
- **Résolution de l'identité**: Des règles de correspondance exactes sont appliquées pour unifier les profils avec tous les jeux de règles de correspondance existants. Par conséquent, les spécialistes des données n'ont pas à créer de nouveaux jeux de règles de résolution de l'identité spécialement conçus pour le temps réel.
- **Connaissances calculées**: Chaque engagement est évalué, de simples calculs tels que la somme et le nombre en millisecondes sont exécutés, et les données sont mises à jour dans le graphique des données en temps réel.
- **Segments en temps réel**: Chaque donnée d'engagement est évaluée pour déterminer si elle remplit les critères des segments en temps réel définis, et les utilisateurs sont ajoutés aux segments qualifiants en millisecondes.
- **Actions et déclencheurs en temps réel**: Chaque engagement est évalué par rapport à des règles définies afin de déclencher des actions sur une plage de cibles en temps réel lorsque les règles sont remplies en millisecondes.
- **Graphique de données et API en temps réel**: Le graphique des données en temps réel, qui inclut également une API en temps réel, permet aux marques de récupérer des données au format JSON mises à jour pour chaque utilisateur, ce qui garantit que toutes les interactions des clients sont informées par les données les plus récentes.
#### Personnalisation
La personnalisation consiste à savoir qui cibler, quand et où livrer des contenus et des recommandations pertinents, quoi dire et à quelle fréquence. La Plate-forme des services de personnalisation est l'orchestre des décisions prises pour optimiser l'atteinte des objectifs grâce à des expériences personnalisées.
Les **Services de personnalisation** offrent les capacités suivantes :
- Ensemble cohérent de modèles et de méthodes d'interprétation des données de profil, d'activité et d'actif dans Data 360
- Expérimentation intégrée de la plate-forme (A/B/n, Multi-Arm Bandit)
- Intégration d'objectifs lors de la conception (configuration), temps d'entraînement ML et exécution (inférence ML)
- Prise en charge des interactions en temps réel et par lot à l'échelle B2C (utilisateurs anonymes, externe interactif/temps réel haut volume, lot interne haut volume)
- Analytics pilotée par Data 360
- Modèles d’intégration du modèle IA et du service d’autres parties (internes et externes)
- Intégration à l'écosystème de métadonnées de base (caractéristiques de PLATE)
- Implémentations OOTB de cas d’utilisation pilotés par l’IA à haute valeur ajoutée (Recommandations/décisions avec divers algorithmes ML, y compris des bandits contextuels pour la promotion/sélection de contenus, recommandations de produits, décisions de tarification, etc.)
- **Encours décisionnel**
- Servir les demandes externes de décisions de personnalisation, notamment l'augmentation du profil, l'expérimentation et les recommandations.
- **Moteur de recommandation**
- Service à l'exécution de recommandations basées sur des règles ou ML.
- **Gestionnaire d'index**
- Gère/Orchestre le workflow pour les processus asynchrones, y compris les formations ML pour les modèles de recommandation
- **Service d'objet de processus**
- Responsable de la synchronisation des métadonnées de personnalisation entre core et off-core
- **Moteur d'attribution et expérimentation**
- Attribution Analytics et expérimentation de recommandations de personnalisation
### Recherche Agentic Enterprise
Data 360 est conçue comme une plate-forme robuste et riche spécifiquement pour prendre en charge les expériences agentiques émergentes. Nous réalisons ces capacités en nous appuyant sur divers services Data 360 existants et grâce à une intégration profonde avec Agentforce.
#### Exploiter les forces principales de Data 360
Notre approche de la Recherche d'entreprise Agentic repose sur les principes suivants :
- Les données d'entreprise sont conservées dans des services ou des magasins cloisonnés, avec les autorisations sécurisées requises pour l'accès. La possibilité d'accéder à ces données et de les traiter tout en conservant les autorisations sources est vitale pour garantir Trust.
- Le classement croisé et la pertinence dans le corpus complet de données permettent d'obtenir de meilleurs résultats, ce qui peut à son tour fournir un meilleur contexte pour les expériences des agents.
Pour offrir ces expériences, la Recherche d'entreprise Agentic s'appuie sur les principaux composants architecturaux suivants :
- **Connecteurs**: Le large ensemble de connecteurs disponibles dans Data 360 permet d'accéder à et d'ingérer des données à partir d'une grande variété de sources.
- **Traitement des données non structuré**: Ceci est fondamental pour gérer les contenus non tabulaires, permettant au système de dériver un sens et un contexte à partir de diverses données.
- **Gouvernance**: Garantir la sécurité, la conformité et les contrôles d'accès de niveau entreprise pour toutes les données consommées par la recherche. La prise en charge des autorisations de visibilité de la source garantit que les données sont accessibles uniquement aux utilisateurs autorisés, aussi bien pour la simple recherche que pour les expériences des agents. Pour accélérer la récupération, les autorisations de sécurité sont évaluées et appliquées nativement par les back-ends de recherche dès la première étape de l'accès aux données.
- **Couche de récupération unifiée**: Pour relever le défi des données cloisonnées, les connecteurs alimentent une couche complète de récupération unifiée. Cette couche fournit un point d'accès unique à toutes les données, qu'elles restent dans des systèmes externes accédés via la Recherche fédérée ou qu'elles soient gérées nativement via des index avancés pour des données sans copie et ingérées.
- **Compréhension intelligente des requêtes**: Avant la récupération, le système utilise des mécanismes pilotés par l'IA pour interpréter l'intention de l'utilisateur. En plus d'incorporer des représentations de la requête pour la correspondance vectorielle sémantique, il peut réécrire et élargir les recherches basées sur des mots-clés pour plus de précision.
- **Recherche hybride et interrogation avancée**: Pour trouver les informations les plus pertinentes, la plate-forme utilise plusieurs stratégies en parallèle. La recherche hybride fournit une correspondance précise par mot-clé avec la recherche vectorielle sémantique sur des segments de données optimisés, tandis que la recherche complète récupère simultanément des documents complets. Les deux sont combinés pour garantir à la fois la pertinence sémantique et une couverture complète des contenus.
- **Classement hiérarchique**: Une fois les données récupérées, une architecture de classement hiérarchique à plusieurs étapes calcule le score, fusionne et reclasse les résultats de chaque source et méthode. Ce processus crée une liste unique et unifiée qui présente les informations les plus pertinentes pour l'utilisateur ou l'agent.
#### Applications de recherche agentique
L’IA générative déplace le principal consommateur de la recherche en entreprise des utilisateurs humains vers les grands modèles de langage (LLM). La recherche Data 360 est entièrement conçue pour servir les deux. Il est optimisé pour gérer les requêtes plus longues et plus complexes des agents et renvoyer les résultats contextuels enrichis nécessaires pour les boucles de consommation et de raisonnement par programmation. En même temps, le système peut gérer les requêtes plus courtes et souvent ambiguës typiques des utilisateurs humains, en fournissant des fonctionnalités telles que des extraits de code et en surlignant pour une évaluation rapide dans une interface utilisateur.
La livraison ultime d'expériences de recherche d'agents combine les deux approches :
1. **Résultats de recherche** directe : l'application peut afficher une liste traditionnelle de résultats classés en utilisant une API pilotée par les métadonnées élaborée sur la fondation de recherche unifiée Data 360.
2. **Réponses conversationnelles** multiples : les réponses sont implémentées par l'intégration native à Agentforce. Cette expérience conversationnelle est pilotée par un agent principal qui orchestre les actions et les requêtes, déléguant toutes les tâches de récupération d'informations à un agent de recherche interne spécialisé.
Cet agent de recherche spécialisé est optimisé pour la récupération d'informations d'entreprise. Il utilise une boucle de raisonnement pour formuler et exécuter des recherches parallèles afin d'explorer différentes facettes de la requête d'un utilisateur. Il utilise un ensemble puissant d'outils, notamment la recherche unifiée Data 360 pour tous les types de données et les langages de requête structurés pour récupérer des données précises à partir de tableaux et d'entités.
Grâce à cette synthèse architecturale, Data 360 permet de créer des expériences de recherche d'entreprise hautement intelligentes, sensibles au contexte et actionnables.
### Extension de Data 360 avec un code personnalisé
L'extensibilité est une fonctionnalité clé de Salesforce Platform. L'extension de code offre l'extensibilité dans Data 360, permettant aux utilisateurs pro-code d'exécuter une logique Python personnalisée directement dans l'environnement Data 360, en plus de ses fonctionnalités déclaratives enrichies et à faible code. En utilisant l'extension de code, les utilisateurs peuvent étendre en toute sécurité les capacités de base de Data 360, notamment Transformations et Pipelines de données non structurés (chunking personnalisé).
Notre conception de l'extension Code privilégie la flexibilité, la sécurité, l'efficacité et une expérience de développement rationalisée. Il prend en charge deux modèles d'exécution principaux, chacun adapté à des besoins architecturaux spécifiques :
- **Modèle de script**:
- **Objet**: Pour une logique personnalisée complète nécessitant une interaction directe avec Data 360 Lakehouse.
- **Fonctionnalité**: Les clients écrivent des scripts Python complets en utilisant le kit de développement Code Extension SDK, qui permet d'accéder en lecture et en écriture à Lakehouse via des API SDK. Idéal pour la préparation de données personnalisées/complexes, ou la manipulation de données sur mesure.
- **Isolement et sécurité**: Lorsque les scripts accèdent à Lakehouse, leur exécution est limitée à un environnement sécurisé et isolé pendant l'exécution de Data 360, ce qui empêche toute interférence avec d'autres processus ou accès système non autorisé.
- **Modèle de fonction**:
- **Objet**: Analogue à une fonction sans serveur, pour des calculs modulaires sans état invoqués à partir de pipelines Data 360 existants (par exemple, segmentation personnalisée dans un pipeline non structuré).
- **Fonctionnalité**: Les fonctions fournies par le client prennent l'entrée, calculent et renvoient la sortie.
- **Isolement et sécurité**: Ces fonctions sont conçues pour une isolation stricte; elles n'ont pas d'accès direct à Lakehouse. Leur exécution est sandbox, sans état et limitée en ressources, ce qui les rend adaptés à des étapes de traitement ciblées et sans état, garantissant la sécurité, une exécution prévisible et réduisant le rayon d'explosion.
Les modèles Script et Fonction visent à exécuter en toute sécurité un code client, en empêchant le code d'un locataire d'affecter d'autres locataires ou d'obtenir un accès non autorisé aux données, aux ressources Salesforce ou aux ressources externes d'autres locataires. Cette sécurité est obtenue grâce à une architecture en couches (défense en profondeur). Cette architecture fournit un environnement d'exécution isolé pour le code personnalisé de chaque locataire, incorporant divers garde-fous. Il s'agit notamment de l'isolation logique au niveau des Kubernetes (K8), de l'isolation du réseau, de l'exécution sandbox et des autorisations de moindre privilège, le tout complété par une surveillance opérationnelle et une préparation aux incidents pour la détection et la réponse.
#### Expérience du développeur et visibilité opérationnelle
Pour prendre en charge un cycle de vie de développement robuste, Code Extension offre :
- **Rédaction et débogage externes**: Les développeurs peuvent élaborer et déboguer du code Python dans des environnements familiers tels que VSCode, en exploitant le kit de développement.
- **Déploiement flexible**: Un code personnalisé peut être empaqueté et déployé en utilisant des utilitaires SDK, l'interface utilisateur Data 360 ou l'API, ce qui permet l'intégration dans CI/CD.
**Journaux opérationnels**: L'accès à des journaux d'exécution détaillés offre de la transparence et facilite le dépannage en production.
En offrant ces capacités d'extension de code sécurisées et flexibles, Data 360 permet aux architectes d'adapter la plate-forme à leurs exigences de traitement des données les plus uniques et complexes, renforçant ainsi véritablement son rôle de tissu de données d'entreprise extensible.
### Extension de Data 360 en intégrant vos propres modèles IA
À mesure que les entreprises accélèrent l'adoption de l'IA, la plupart gèrent des écosystèmes ML hétérogènes, notamment Amazon SageMaker, Google Vertex AI et des environnements Python personnalisés, qui hébergent des modèles qui pilotent des prédictions critiques, telles que le score de risque de crédit, la propension à l'attrition, les recommandations de produits et les décisions Next Best Action.
Traditionnellement, l'intégration de ces modèles externes dans Salesforce nécessitait des couches d'API sur mesure, des pipelines ETL ou une orchestration middleware, introduisant la duplication des données, les frais généraux de gouvernance, la latence et la complexité opérationnelle, des défis qui sont en conflit avec une vision Customer Data Platform (CDP) unifiée, conforme et en temps réel.
**Apportez votre propre modèle (BYOM)**: Proposé via Einstein Studio dans Data 360, répond à ces défis en activant l'invocation directe de modèles formés en externe dans les workflows Salesforce, la logique Apex et les outils d'automatisation, sans déplacer ni répliquer les données. Grâce à la fédération zéro copie, Data 360 agit en tant que source unique de vérité régie, exposant les données Customer 360 harmonisées pour l'inférence à des points de terminaison externes. Les sorties de prédiction remontent en temps réel, alimentant les processus métiers avec une intelligence évolutive.
BYOM réduit efficacement l'écart entre la science des données et l'exécution opérationnelle en découplant le développement de modèles, les données régies et les couches de consommation. Il préserve l'indépendance de la plate-forme, réduit la complexité de l'intégration, accélère le déploiement de l'IA et maintient la gouvernance sur les données confidentielles.
L'architecture fonctionne comme suit : Data 360 fournit une fondation de données Customer 360 unifiée, tandis qu'Einstein Studio orchestre les connexions à des plates-formes ML externes (SageMaker, Vertex AI, ou des points de terminaison personnalisés). Les modèles externes exécutent l'inférence en temps réel, par lot ou en mode streaming. Les couches Salesforce (API Flow, Apex et Query) consomment des sorties pour fournir des connaissances personnalisées, automatisées et analytiques dans Sales Cloud, Service Cloud, Marketing Cloud et Industry Cloud.
D'un point de vue d'entreprise, BYOM offre :
- **Intégrité des données et gouvernance**: Élimine les copies de données incontrôlées et applique la conformité aux politiques.
- **Démocratisation IA**: Rendre les modèles complexes accessibles aux utilisateurs non techniques via des outils Salesforce.
- **Accélération du temps de mise en valeur**: Les modèles externes sont immédiatement activés dans les processus Salesforce.
- **Prise en charge de l'évolutivité et de l'architecture hybride**: Active le déploiement multicloud des charges de travail IA.
- **Architecture IA prête pour le futur**: Prend en charge les stratégies IA composables, le découplage des couches données, modèle et consommation pour plus d’agilité opérationnelle.
**Bring Your Own LLM (BYO-LLM)**: Offre le même mécanisme d'extensibilité que pour les modèles génératifs. En activant l'invocation directe de LLM externes, nous permettons aux clients de les utiliser dans Agentforce Platform à la place des modèles fournis par Salesforce. Pour les entreprises BYO-LLM permet:
- Accès aux modèles ajustés
- Intégration de modèles non fournis actuellement par Salesforce
- Utilisation de modèles dans des comptes fournis par des clients
### Collaboration de données
Les entreprises modernes opèrent dans un paysage de données complexe caractérisé par deux défis architecturaux majeurs :
1. **Fragmentation intra-entreprise**: Les grandes organisations utilisent fréquemment plusieurs organisations Salesforce (souvent segmentées par région, unité commerciale ou acquisition historique) et de nombreux autres systèmes de données. Cette fragmentation crée des silos de données internes, rendant impossible l'établissement d'une vue unique, fiable et unifiée du client pour un engagement en temps réel dans l'ensemble de l'entreprise. Le défi consiste à unifier ces données sans les consolider ni les dupliquer physiquement dans tous les systèmes, afin de préserver la gouvernance.
2. **Collaboration inter-entreprises**: Les entreprises ont souvent besoin de partager des données avec des partenaires et des fournisseurs pour des activités conjointes de marketing, de mesure et de veille économique. Le défi est de permettre cette collaboration tout en protégeant les données confidentielles et propriétaires et en adhérant aux réglementations relatives à la protection de la vie privée telles que le RGPD et la CCPA, ainsi qu’aux obstacles concurrentiels.
Salesforce Data 360 répond à ces défis avec une infrastructure Trust by Design zéro copie construite sur le principe du partage de l'accès et des connaissances plutôt que de déplacer ou dupliquer les données.
#### Mécanismes de collaboration Data 360
Salesforce Data 360 résout les problèmes de fragmentation des données et de collaboration avec Data Cloud One, le Partage de données entre Data 360 et les Salles blanches de données. Ces solutions unifient les données des clients, permettent un échange de données sécurisé et fournissent des connaissances sur la protection de la vie privée. Avec une approche Trust by Design sans copie, les organisations peuvent exploiter le potentiel des données pour un engagement en temps réel, des partenariats renforcés et une prise de décision intelligente. Chacune de ces options de collaboration de données sert des objectifs différents.
##### Activation interne de l'entreprise avec Data Cloud One
Data Cloud One est la solution architecturale de base pour les entreprises qui exploitent plusieurs organisations Salesforce. Son objectif va au-delà du simple partage de données. Il est conçu pour établir une vue client unique et de confiance et activer toutes les capacités de la plate-forme Data 360 dans toute l'organisation.
Ce mécanisme est centré sur une instance Home Org Data 360 désignée, qui sert d'autorité centrale pour la gestion des données et l'élaboration du profil client unifié. L'organisation d'accueil est l'organisation dans laquelle Data 360 est provisionnée. Une connexion Data Cloud One est établie entre Data 360 et d'autres organisations Salesforce, appelées Organisations Compagnons. Dans le cadre de la connexion Data Cloud One, Data 360 partage un ou plusieurs de ses espaces de données avec chaque organisation partenaire, ce qui permet d'accéder aux données et aux métadonnées de chaque espace de données partagé. Cela est possible grâce à un modèle de fédération sans copie et à la synchronisation des métadonnées inter-organisations.
Data Cloud One permet également aux organisations compagnes d'exploiter l'instance Data 360 de l'organisation d'origine pour leurs propres besoins en activation, personnalisation et intelligence. Cette stratégie est essentielle pour éliminer la fragmentation des données internes et garantir que toutes les unités commerciales s'activent avec le même profil client, gouverné et unifié, afin d'optimiser le retour sur investissement de l'implémentation principale de Data 360.
##### Partage de données entre des organisations Data 360
Pour les environnements internes distribués (où la centralisation complète n'est pas possible) et pour la collaboration avec des partenaires externes de confiance, le partage de données Data 360 vers Data 360 connecte des instances Data 360 indépendantes.
Ce modèle de partage sans copie établit une connexion entre des locataires Data 360 distincts provisionnés dans différentes organisations Salesforce afin de sécuriser l'échange d'objets de données (DLO, DMO et CIO). Une fois connecté, l'objet de données complet devient accessible dans Data 360 destinataire. L'administrateur de Data 360 destinataire peut ensuite définir des règles de gouvernance pour gérer l'accès des utilisateurs à ces données.
##### Collaboration Priorité à la confidentialité avec Data 360 Clean Room
Lorsque la collaboration nécessite les plus hauts niveaux de confidentialité et de conformité, ou lorsque des préoccupations concurrentielles interdisent le partage de données brutes, les salles blanches Data 360 sont architecturalement mandatées.
D'un point de vue architectural, la collaboration en salle blanche Data 360 repose sur l'infrastructure de partage zéro copie utilisée par le partage de données Data 360 vers Data 360, mais avec des couches supplémentaires de contraintes de gouvernance et de calcul appliquées. La salle blanche Data 360 offre un environnement de calcul sécurisé et contrôlé dans lequel les parties peuvent joindre leurs jeux de données sur la base de clés anonymisées. Son objectif principal est de permettre une analyse conjointe et la génération de connaissances sans exposer les données propriétaires sous-jacentes. L'environnement applique des règles strictes et programmables telles que des seuils d'agrégation minimum et des identifiants non exportables. Ces règles garantissent que seules les connaissances approuvées, améliorant la confidentialité et agrégées sont dérivées et partagées. Cela rend les Salles blanches essentielles pour des cas d'utilisation tels que la mesure de campagnes multiplate-forme et l'analyse des chevauchements d'audience sensibles.
## Conclusion : Salesforce Data 360 : L'épine dorsale de données indispensable pour l'entreprise Agentic
Data 360 est conçu comme un tissu de données intelligent, extensible et fiable nécessaire pour piloter l’IA de nouvelle génération. Sa conception architecturale répond au problème de la fragmentation des données, permettant aux organisations d'unifier, de traiter et d'activer toutes les données clients à l'échelle, en utilisant la Fédération de données Zero Copy pour garantir l'efficacité.
Son organisation robuste des données établit une vue harmonisée des objets lac de données (y compris les données non structurées) aux objets modèle de données, le tout sécurisé dans des espaces de données partitionnés. Les capacités polyvalentes de traitement des données de Data 360, notamment les transformations par lot et en continu, les connaissances calculées, le traitement des données non structuré et la résolution de l'identité, sont pilotées par l'architecture incrémentielle SNCE et CDF, ce qui garantit un traitement efficace et en temps quasi réel et des économies importantes.
L'extensibilité est fournie par l'architecture Code Extension, qui active en toute sécurité une logique Python personnalisée via des scripts ou des fonctions isolées pour des exigences uniques. De plus, un cadre de gouvernance des données complet, basé sur le contrôle d'accès basé sur l'attribut (ABAC) avec des politiques CEDAR, garantit une sécurité granulaire, un masquage dynamique des données et une application cohérente dans l'ensemble de la consommation de données. Cela aboutit à des capacités sophistiquées de segmentation et d'activation, qui traduisent des profils clients unifiés en stratégies d'engagement multicanal dynamiques et réactives en temps réel.
La capacité de Data 360 à unifier des données vastes et diverses, à fournir un contexte en temps réel via sa requête unifiée (y compris la recherche structurée/non structurée hybride et l'accélération Hyper) et à appliquer une gouvernance stricte est essentielle pour piloter les agents IA intelligents. Il fournit les données fiables, actualisées et pertinentes nécessaires pour ancrer les workflows IA générative (RAG) et pour alimenter les capacités multitours orientées action des agents pilotés par Agentforce, en garantissant leur fonctionnement avec précision et précision.
En fournissant une plate-forme à l'épreuve du temps où les données sources sont transformées en connaissances actionnables, Data 360 est une fondation architecturale indispensable pour les organisations qui élaborent des expériences client Agentic. C'est l'épine dorsale vitale qui transforme les données des clients en expériences client sophistiquées et personnalisées qui favorisent la réussite des organisations modernes d'aujourd'hui.
## De l'intégration composable à une entreprise Agentic régie
La transition vers Agentic Enterprise représente le changement architectural le plus important depuis l'aube du cloud. Il promet des niveaux de productivité et d'automatisation sans précédent, mais il introduit également de profonds défis liés à la gouvernance, à la sécurité et à la complexité opérationnelle. Utiliser une approche fragmentaire - déployer des agents en silos sans stratégie rassembleuse - est une voie directe vers la dette technique et le chaos organisationnel.
Le déploiement d'agents sans plan de gestion central entraîne des risques opérationnels importants, notamment des failles de sécurité liées à l'accès direct au système, un manque d'observabilité dans les interactions et les actions des agents, et des coûts élevés dus à des intégrations point à point redondantes. Cette stratégie de déploiement cloisonnée crée un environnement fragile et difficile à gérer à grande échelle. Un modèle durable nécessite une plate-forme unifiée pour l'intégration et la gouvernance des agents.
_MuleSoft_ fournit une plate-forme complète, unifiée et ouverte pour guider en toute confiance les entreprises tout au long de leur parcours. Il exploite le paysage d'API existant de l'entreprise en tant que fondation pour les actions des agents, et accélère la création de nouveaux actifs prêts pour les agents à travers un cycle de vie de développement de confiance piloté par l'IA. Grâce à la prise en charge au niveau de l'entreprise de normes ouvertes telles que le protocole Model Context Protocol (MCP) et les protocoles Agent2Agent (A2A), ces actifs peuvent être exploités à la fois pour des commandes simples et une collaboration multi-agents complexe, quelle que soit l'évolution du paysage de l'IA. [_MuleSoft Agent Fabric_](https://docs.mulesoft.com/agent-fabric/) fournit une solution pour découvrir, orchestrer, gouverner et observer l'écosystème complet des agents. Grâce à cette approche intégrée, _MuleSoft Agent Fabric_ fournit une base éprouvée pour adapter un réseau d’agents d’Intelligence artificielle approuvés, qui transforme les promesses de l’IA en résultats commerciaux tangibles et automatisés et exploite tout le potentiel de l’entreprise intelligente.
## **La fondation composable pour l’IA actionnable**
L'approche à trois niveaux établie de la connectivité pilotée par l'API - API système, API processus et API Experience - fournit un cadre puissant pour structurer l'actionnabilité des agents.
- Les **API système** offrent une interface cohérente, sécurisée et abstraite aux systèmes d'enregistrement sous-jacents. Ils découplent les agents de la complexité des protocoles back-end et des modèles de données, ce qui garantit que toutes les actions des agents sont exécutées sur des points de terminaison gouvernés et fiables.
- Les **API de processus** encapsulent une logique métier complexe à plusieurs étapes. Les agents n'ont pas besoin de comprendre l'orchestration complexe qui se cache derrière la création de commandes, la vérification de l'inventaire ou l'initiation d'expéditions. Ils peuvent utiliser des API Process (par exemple, « Process Order ») sans avoir à gérer les complexités sous-jacentes. Les API de processus offrent aux agents un mécanisme sûr, transactionnel et auditable pour exécuter des processus métiers, ce qui réduit considérablement le raisonnement des agents et garantit l'application cohérente des règles métiers.
- **Les API Experience** étaient traditionnellement conçues pour servir des applications d'interface utilisateur spécifiques (par exemple, Order Management App). Cependant, elles peuvent également être redéfinies en actions riches en contexte pour les agents. Cela fournit aux agents des informations essentielles pour réaliser une tâche donnée sans avoir à appeler plusieurs systèmes en aval.
## **1\. Création générative : Accélération du développement d'actifs prêts pour l'agent**
Pour répondre à la demande croissante d'outils et de capacités prêts à être utilisés par les agents, les entreprises doivent accélérer le développement des API et des intégrations qui forment la base composable. _MuleSoft_ relève ce défi en incorporant l’IA générative directement au cycle de vie du développement, ce qui crée un cycle vertueux qui utilise l’IA pour élaborer les actifs de haute qualité que les autres agents consomment.
### **1.1 MuleSoft Vibes**
Pour les développeurs, [MuleSoft Vibes](https://www.mulesoft.com/platform/api/anypoint-code-builder/announcing-mulesoft-vibes) agit comme un partenaire intelligent en automatisant les aspects les plus répétitifs du développement de l'intégration et en fournissant une interface unifiée et agentique pour tout le cycle de vie du développement logiciel. Grâce à MuleSoft Vibes dans [Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/), les développeurs interagissent avec les capacités génératives pilotées par les [ _Pipelines IA Einstein_ de confiance](https://blogs.mulesoft.com/automation/how-mulesoft-turns-generative-output-into-value/), ce qui rend le processus de développement assisté par l’IA fluide et efficace. Ce pipeline - le _Service d'exécution de graphiques d'inférence (IGES)_ \- est un processus à plusieurs étapes utilisé pour obtenir des résultats de grande qualité. Il comprend l'ancrage, la validation, la correction des erreurs et une évaluation rigoureuse.
- Dans _MuleSoft Vibes_, les capacités de [**flux génératifs**](https://blogs.mulesoft.com/dev-guides/einstein-for-acb/) reposent sur l ' infrastructure _Agentforce AI_. Il transforme la logique métier en langage naturel (invites utilisateur) en applications Mule fonctionnelles. Le _pipeline IGES_ comprend les étapes suivantes :
- **Résumé de l'historique des conversations :** Le LLM analyse l'invite actuelle et les messages précédents de l'utilisateur pour créer une invite résumée qui capture l'intention de l'utilisateur et l'historique des conversations. Cette invite consolidée améliore la précision des étapes suivantes de récupération et de génération de données.
- **Récupération sémantique de flux à partir d'une base de données vectorielle :** Le système reprend l'invite résumée de l'étape précédente et effectue une recherche sémantique dans une base de données vectorielle qui contient plus de 200 connecteurs, plus de 7000 opérations de connecteur et plus de 7000 exemples d'extrait de code. Il récupère les connecteurs, les opérations et les exemples de code les plus pertinents pour ancrer le processus de génération en utilisant des données précises, et garantit que les sorties sont alignées avec le vaste écosystème de connecteurs de MuleSoft. Comme MuleSoft est la norme de l'industrie pour les connecteurs et les opérations, cet ancrage fournit au modèle un contexte riche et une précision de domaine qui font défaut aux grands modèles de langage génériques.
- **Augmentation :** Le contenu récupéré et les messages d'historique des conversations sont ensuite combinés à l'invite résumée. Cette invite augmentée guide le LLM à réduire les hallucinations. Il comprend également des instructions pour empêcher la génération de contenu toxique.
- **Génération de flux :** Cette étape exploite le modèle _Einstein AI LLM_ pour générer un code XML brut basé sur le contexte et les exemples fournis. C'est l'étape principale du pipeline de génération.
- **Post-traitement et validation :** Le post-processeur et le validateur vérifient le code pour s'assurer de la syntaxe correcte et de l'utilisation d'opérations de connecteur valides, tandis qu'un contrôle de toxicité séparé signale un contenu nocif.
- **Correction d'erreur à plusieurs étapes :** Si toutes les générations initiales ne sont pas valides, le mécanisme automatisé de correction d'erreur analyse les messages d'erreur pour détecter des modèles. Il soumet ensuite de nouveau l'invite au grand livre avec des messages d'erreur enrichis et des métadonnées correctives.
- **Configurer la génération de fichiers :** Cette étape extrait les métadonnées pertinentes du connecteur, augmente l'invite et l'envoie au grand livre pour générer des configurations de connecteur précises. Enfin, tous les espaces de noms POM et XML sont générés de façon déterministe en utilisant la dernière version de chaque dépendance, ce qui élimine les hallucinations et garantit la cohérence.
- La transformation de données [**DataWeave Transformation Generation**](https://blogs.mulesoft.com/dev-guides/dataweave-generative-transformation/)**:** est souvent la partie la plus chronophage du développement de l'intégration. _MuleSoft Vibes_ s'attaque à ce processus en utilisant l'approche à plusieurs étapes similaire à la génération _XML Flux mulet_.
- **Raisonnement de l'intention :** Le LLM analyse les échantillons de données d'entrée et de sortie des utilisateurs pour déduire et articuler une logique de transformation de haut niveau en langage naturel. Cette étape sépare l'objectif de l'utilisateur des valeurs de données littérales qui peuvent avoir été fournies dans l'invite.
- **Récupération sémantique DataWeave :** Pour trouver la documentation sur les fonctions DataWeave la plus pertinente sur le plan sémantique et des exemples de transformation complets, le système utilise l'invite générée à l'étape précédente en tant que requête à la base de données vectorielle. Le processus de génération repose ainsi sur des informations vérifiées et de haute qualité.
- **Augmentation :** Les fonctions et les exemples récupérés sont combinés à l'invite utilisateur d'origine afin de créer une série d'instructions contextuelles pour l'appel LLM suivant, qui influence le comportement du LLM pour réduire les hallucinations.
- **Génération DataWeave :** Cette étape exploite le modèle LLM pour générer un script de transformation DataWeave et une explication d'accompagnement basée sur le contexte fourni et des exemples. C'est l'étape principale du pipeline de génération.
- **Post-traitement et validation** Le script généré est évalué par rapport à deux métriques spécifiques : validité et exactitude. Le script doit compiler sans erreur de syntaxe (validité) et produire la sortie attendue lorsqu'il est exécuté en utilisant l'entrée exemple (correct).
- **Correction d'erreur à plusieurs étapes :** Si la validation initiale échoue, ce plug-in identifie les catégories d'erreur et corrige les problèmes dans le script généré. Cette amélioration contribue à améliorer le taux de réussite global et la précision du système.
- **Post-traitement et validation** finaux Le script corrigé du module de correction d'erreur est soumis à un processus de re-validation pour s'assurer qu'il est syntaxiquement valide et fonctionnel. Cette porte de qualité finale garantit la précision et la fiabilité de la sortie avant de la renvoyer à l'utilisateur.
- Les développeurs [**de spécification d'API**](https://docs.mulesoft.com/anypoint-code-builder/api-ai-create-spec) **et de [génération de documentation](https://docs.mulesoft.com/exchange/generating-documentation-with-ai):** peuvent générer des spécifications _OpenAPI (OAS)_ ou _RAML_ entièrement validées en décrivant l'API souhaitée en langage naturel. _MuleSoft Vibes_ ingère l'invite (qui contient des détails sur les ressources, les méthodes, les schémas de sécurité et les paramètres) et produit une définition d'API valide et syntaxiquement correcte. Après la génération, il peut créer une documentation pour l'API dans _Anypoint Exchange_, qui couvre tous les aspects, depuis l'authentification jusqu'aux détails des points de terminaison et le traitement des erreurs, libérant ainsi les développeurs de ces types de tâches fastidieuses.
- **Génération d'unités assistées par l'IA :** L'assurance qualité est primordiale pour les actifs consommés par des agents autonomes. _MuleSoft Vibes_ aide à générer des requêtes de test MUnit directement depuis le code de flux Mule. Cela permet de simuler les dépendances et les assertions externes, et d'identifier les écarts de test courants, ce qui réduit considérablement les efforts manuels nécessaires pour atteindre une couverture de test élevée et garantir la fiabilité de la logique d'intégration.
### **1.2 MuleSoft à votre façon**
Les développeurs prospèrent dans leurs environnements préférés. C'est pourquoi _MuleSoft_ rencontre les développeurs là où ils se trouvent, ce qui leur permet d'élaborer des intégrations dans l'IDE IA de leur choix. [Le serveur MCP](https://www.npmjs.com/package/@mulesoft/mcp-server) (Model Context Protocol) de MuleSoft expose les capacités de développement, de déploiement et de gestion en tant qu'outils MCP que tout IDE natif basé sur l'IA basée sur un code VS (par exemple, Cursor, Windsurf ou Trae) peut consommer pour interagir avec la _plate-forme Anypoint_ en langage naturel.
En empaquetant sa fonctionnalité IDE de base dans une [extension VS Code standard](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-extension-pack), _MuleSoft_ découple ses outils d'un shell IDE de marque, ce qui permet à l'outillage de développement d'être agnostique IDE. Au lieu de concurrencer l'évolution rapide des IDE, ce choix d'architecture permet aux outils de développement de MuleSoft de rester compatibles et accessibles dans l'écosystème croissant des IDE modernes pilotés par l'IA.
## **2\. Activer Actionability : Transformation des API en outils pour les agents**
Dans une entreprise Agentic, disposer d'une base solide d'API composables est nécessaire, mais insuffisant. L’étape critique suivante consiste à s’assurer que ces actifs sont découvrables, compréhensibles et invocables par les agents IA. Cela nécessite une « couche actionnable » basée sur des normes ouvertes conçues spécifiquement pour la communication des agents. _MuleSoft_ fournit un outillage de niveau entreprise pour les deux protocoles émergents dominants :
- **MCP** pour les interactions agent à système
- **A2A** pour les interactions agent à agent
### **2.1 Modèle de protocole de contexte (MCP)**
_MCP_ s'est rapidement imposé comme la norme de l'industrie pour la communication agent-à-outil, ce qui est analogue à ce que _REST_ est devenu pour les services Web. _MCP_ permet aux agents IA de découvrir dynamiquement les capacités d'un système, de comprendre ses entrées et sorties, et de l'invoquer pour exécuter une action, le tout sans nécessiter de logique préprogrammée ou codée en dur.
Le [connecteur MCP MuleSoft](https://docs.mulesoft.com/mcp-connector/latest/) permet de publier en tant que serveur MCP n'importe quelle API implémentée en tant qu'application Mule. Comme _MuleSoft_ fournit des centaines de connecteurs prédéfinis à pratiquement tous les grands systèmes d'entreprise (par exemple, SaaS, hérités et bases de données), cela transforme instantanément les API et les applications d'une organisation en un ensemble d'outils prêts pour l'agent. Une API conçue pour vérifier l'inventaire dans SAP, un flux qui traite une nouvelle piste dans Salesforce ou une application personnalisée connectée via _MuleSoft_ peuvent tous être mis à la disposition des agents IA en tant qu'outils atomiques et gouvernés en utilisant le _connecteur MCP_.
### **2.2 Protocole agent à agent (A2A)**
Bien que le _MCP_ excelle dans les interactions hiérarchiques invoquant un outil, les processus métiers complexes nécessitent souvent la collaboration de plusieurs agents spécialisés. Le protocole _Agent à agent_ est la norme ouverte émergente conçue pour faciliter la communication pair à pair qui permet des workflows multi-agents sophistiqués.
La prise en charge d'A2A par MuleSoft permet aux entreprises de concevoir et de construire des systèmes avancés avec le même niveau de gouvernance et de fiabilité que celui attendu pour leurs API. Le [connecteur MuleSoft A2A](https://docs.mulesoft.com/a2a-connector/latest/) permet aux développeurs d'exposer aisément n'importe quel agent en tant que serveur A2A ou d'invoquer n'importe quel agent conforme A2A à partir d'une application Mule. Par exemple, un processus de demande de prêt immobilier peut être orchestré entre un « agent de vérification du crédit », un « agent de signature de document » et un « agent de conformité réglementaire », chaque agent découvrant et invoquant les capacités des autres (au besoin) pour faire avancer la demande.
En fournissant un outillage robuste de niveau entreprise pour MCP et A2A, MuleSoft prend en charge la création d'un écosystème flexible qui comprend des interactions directes agent à système (via des outils MCP) et des interactions agent à agent (A2A). Quelle que soit l’évolution du paysage de l’IA, cette approche positionne _MuleSoft_ comme la fondation sous-jacente qui connecte toutes les formes de communication des agents.
## **3\. Tissu MuleSoft Agent: Le système nerveux central de l'entreprise Agentic**
À mesure que les entreprises adoptent l’IA agentique, elles sont inévitablement confrontées au défi de l’étalement des agents. Pour éviter que cela ne dégénère en chaos, une couche d'orchestration dédiée est requise. [MuleSoft Agent Fabric](https://docs.mulesoft.com/agent-fabric/) ([demo](https://www.youtube.com/watch?v=GAqwPie16ic)) est une solution architecturale complète conçue pour relever ce défi. Il fournit un plan de gestion central pour découvrir, gouverner, orchestrer et observer l'ensemble du réseau d'agents IA, quel que soit leur lieu de construction ou leur mode d'exploitation. Fonctionnant comme le « contrôleur aérien » de la force de travail numérique de l'entreprise, _MuleSoft Agent Fabric_ transforme une collection d'agents fragmentés et cloisonnés en un réseau d'intelligence cohérent, sécurisé et hautement performant.
_MuleSoft Agent Fabric_ repose sur quatre piliers intégrés qui couvrent la gestion complète du cycle de vie des agents en tant qu'actifs d'entreprise de premier ordre.
### **3.1 Registre des agents (découvrir)**
La base de tout écosystème géré est la découvrabilité. Le _Registre des agents_ sert de catalogue universel et centralisé pour chaque actif agent au sein de l'entreprise. Cela comprend les agents personnalisés, les agents incorporés à des applications SaaS, les serveurs MCP qui exposent des systèmes hérités et les points de terminaison A2A pour la collaboration inter-agents. En fournissant une source de preuve unique, le _Registre des agents_ résout le problème critique de découverte en empêchant les équipes de développer des capacités redondantes, et en permettant aux développeurs humains et aux autres agents IA de rechercher et de réutiliser dynamiquement des actifs existants à grande échelle.
Le _Registre des agents_ s'appuie sur _Anypoint Exchange_ et ajoute trois nouveaux types d'actif : Agents, serveurs MCP et LLM. Il capture des informations sur ces actifs, notamment les outils MCP, les protocoles de transport et les cartes d'agent, ainsi que les dépendances entre les agents et les serveurs et outils MCP qu'ils consomment. Les développeurs peuvent créer et gérer des actifs directement dans le registre. Ils peuvent également découvrir et réutiliser par programmation des actifs existants dans MuleSoft Vibes (via l'outil search*asset \_de MuleSoft MCP Server*) en créant de nouvelles orchestrations. Cela fournit aux développeurs toutes les informations dont ils ont besoin pour comprendre et consommer ces actifs.
### **3.2 Agent Broker (Orchestrer)**
Une fois que les actifs peuvent être découverts, ils doivent être orchestrés pour accomplir un travail utile. L'_agent Broker_ est un service d'orchestration qui exécute des processus métiers à plusieurs étapes. Il utilise un LLM configurable pour interpréter les tâches principales et générer des workflows correspondants. L'_agent Broker_ découvre, séquence et invoque dynamiquement les agents et les outils requis pour mener à bien ces processus.
La connectivité est gérée via le _MCP_ pour les outils et un protocole _A2A_ pour les agents. Cela permet au système d'organiser les agents dans des domaines spécifiques à l'entreprise (par exemple, Supply Chain ou Finance) et d'acheminer les tâches à travers tous ces domaines. Une invite unique en langage naturel (par exemple « Embarquez un employé ») est décomposée en une séquence d'actions discrètes exécutées par différents agents ou outils à travers plusieurs systèmes back-end. L'orchestration du courtier de l'agent comprend :
- **Modèle d'orchestration dynamique :** Il s'agit d'un modèle Agent-Boucle qui détermine les sous-tâches et les orchestre à travers les agents et les outils les plus appropriés pour atteindre l'objectif global. En exploitant ce schéma, [les agents collaboratifs](/docs/architect/fr-fr/fundamentals/guide/agentic-patterns#15-agents-collaboratifs-essaims-dagents) peuvent être élaborés pour résoudre des cas d'utilisation complexes (par exemple, [gérer une escalade de service](/docs/architect/fr-fr/fundamentals/guide/agentic-patterns#35-cas-dutilisation-de-lagent-collaboratif--escalade-de-service-complexe) complexe).
- **Raisonnement propulsé par le LLM :** Utilise un LLM pour interpréter les objectifs en langage naturel et générer des plans d'exécution, ce qui élimine la nécessité d'une logique de workflow rigide et codée en dur.
- **Modèle LLM configurable :** Permet aux développeurs de spécifier le modèle LLM à utiliser, ce qui permet de contrôler les coûts, les performances et les capacités.
- **Développement du langage naturel :** La logique _Agent Broker_ peut être définie en langage naturel via _MuleSoft Vibes_.
- **Observabilité :** _Anypoint Monitoring_ fournit la consignation et le traçage lors du déploiement pour aider les utilisateurs à comprendre et à déboguer le raisonnement et les interactions de Agent Broker avec les outils _MCP_ et les agents _A2A_.
- **Déploiement géré :** _Agent Broker_ est une application conteneurisée soutenue par _Mule Runtime_, qui gère la disponibilité et l'évolutivité du déploiement.
### **3.3 Passerelle Flex pour MCP et A2A (Gouverner)**
La _passerelle Flex Anypoint_ est le mécanisme par lequel certaines politiques sont appliquées techniquement. _MuleSoft Agent Fabric_ exploite la _passerelle Flex Anypoint_ pour [sécuriser, inspecter et gérer chaque interaction](https://docs.mulesoft.com/gateway/latest/flex-agent-secure) agentique qui se produit via les protocoles _MCP_ et _A2A_. Cela permet aux organisations d'appliquer une riche [série de stratégies](https://docs.mulesoft.com/gateway/latest/flex-agent-policies) à l'ensemble du trafic des agents pour s'assurer que chaque action est sécurisée, conforme et auditable avant son exécution. Pour adapter l’adoption de l’IA de façon sûre et responsable, ces garde-fous sont essentiels.
| Nom de la police | Protocole(s) | Description |
| :------------------------------------------------------------------------------------ | :----------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Politique de validation JWT/Politique d'application automatique de l'ID de client** | A2A, MCP | La **politique de validation JWT** sécurise les agents _A2A_ et les serveurs _MCP_ en limitant l'accès aux appelants authentifiés. |
| **Validation du schéma** | A2A, MCP | La **Validation du schéma** garantit que les requêtes d'agent entrantes sont conformes à la spécification _A2A_ ou _MCP_, ce qui évite tout trafic déformé. |
| **Détecteur PII A2A** | A2A | **A2A PII Detector** identifie les _informations d'identification personnelle_ dans les requêtes et les réponses, et permet de consigner ou de bloquer pour satisfaire aux exigences de conformité. |
| **A2A Décorateur d'invite** | A2A | **A2A Prompt Decorator** injecte un contexte personnalisé ou des instructions dans des invites envoyées aux agents pour guider leur comportement et appliquer des garde-fous. |
| **Contrôle d'accès basé sur l'attribut MCP** | MCP | Le **Contrôle d'accès** basé sur l'attribut MCP régule l'accès à des outils et des ressources spécifiques exposés par un serveur _MCP_ en fonction des attributs utilisateur (par exemple, niveaux, IP ou réclamations JWT). |
| **Consignation SSE** | A2A, MCP | **La consignation SSE** enregistre le contenu des flux _Événements envoyés par_ le serveur (SSE) utilisés par les protocoles agents pour un audit complet et la traçabilité. |
| **Limitation tarifaire et contrôle de pointe** | A2A, MCP | Le **contrôle de limitation** tarifaire et de pointe protège les agents back-end et les systèmes contre les augmentations de trafic et les attaques par déni de service en appliquant automatiquement les limites en requêtes. |
| **A2A Agent Card** | A2A | La **carte Agent A2A** réécrit l'URL de la carte Agent pour s'assurer que tout le trafic est correctement acheminé via l'instance de passerelle Flex régie. |
**Stratégies de gouvernance d'entreprise pour les protocoles Agentic**
En plus de régir les requêtes entrantes, la _passerelle Flex Anypoint_ gère également toutes les connexions sortantes et les requêtes d'un agent à des services externes (par exemple, les serveurs et outils _MCP_ ou d'autres agents). Cela comprend :
- **Consignation :** Fournit un point d'observabilité centralisé pour surveiller et consigner toutes les demandes d'audit et de dépannage des agents sortants.
- **Sécurité :** Empêche la fuite de données confidentielles en inspectant le trafic sortant.
- **Authentification :** Gère les identifiants de systèmes externes en appliquant des mécanismes d'authentification sortants, notamment des clés d'API, OAuth et ClientId/ClientSecret à partir d'un point unique.
Le _kit Anypoint Flex Gateway_ [**Policy Development Kit (PDK**)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview) permet aux utilisateurs de créer des stratégies personnalisées lorsque les stratégies prêtes à l'emploi ne remplissent pas des exigences spécifiques. En utilisant le _PDK_, les développeurs peuvent écrire une logique de stratégie dans le langage de programmation _Rust_ et la compiler dans un module _WebAssembly (WASM)_. Le module autonome est ensuite chargé dans _Anypoint Flex Gateway_ pour appliquer des règles de sécurité uniques, des transformations de données personnalisées ou une logique d'intégration spécialisée directement à la périphérie de l'API. Cela offre une méthode puissante et performante pour étendre les fonctionnalités de la passerelle à des cas d'utilisation uniques ou complexes.
Voici les quatre composants clés du _PDK_:
- **Plugin Anypoint CLI PDK :** Ce plug-in crée le projet _PDK_ et charge la stratégie compilée dans _Exchange_. Il génère également un _fichier Makefile_ qui simplifie le processus de développement en fournissant un ensemble clair de commandes pour élaborer et gérer la stratégie.
- **Modèle de politique :** Lors de la création d'un projet, le _PDK_ génère un échafaudage ou un modèle de base. Cette structure inclut tous les fichiers et la configuration nécessaires pour réussir à compiler la stratégie, ce qui donne aux développeurs un point de départ pour une logique personnalisée.
- **Outils de construction SDK :** Ces outils extraient l'architecture complexe pilotée par l'événement du proxy _Envoyé_ sous-jacent. En utilisant des modèles de réacteur et d'exécuteur, le _SDK_ fournit une méthode de codage linéaire et simple. Cela permet de réduire la complexité, d'améliorer le débogage et de réduire la courbe d'apprentissage pour les développeurs.
- **Gestion des politiques :** Le [serveur MCP MuleSoft](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools) fournit des outils _MCP_ pour aider les utilisateurs à gérer le cycle de vie des stratégies personnalisées. Voici quelques exemples d'outils :
- get_flex_gateway_policy_example
- manage_api_instance_policy
- manage_flex_gateway_policy_project
### **3.4 Visualiseur de l'agent (observer)**
L'_Agent Visualizer_ fournit une carte dynamique en temps réel de l'ensemble du réseau d'agents, transformant ce qui pourrait être une « boîte noire » d'interactions IA en un système entièrement observable. Les architectes et les équipes d'exploitation peuvent utiliser le _visualiseur d'agent_ pour examiner comment les agents sont connectés, suivre leurs flux de décision, surveiller leur santé et leurs performances, et identifier les dépendances. Ce niveau de visibilité est crucial pour optimiser les performances, dépanner efficacement les pannes, détecter les blocages et renforcer la confiance dans les agents déployés.
## **4\. Unification** de Salesforce Platform
### **4.1 Catalogue d'API et centre de rubriques**
Le _catalogue d'API MuleSoft_ et le _centre thématique_ sont conçus pour améliorer la découverte, l'utilisation et la gestion des API, en particulier conjointement avec _Agentforce_
Toutes les API _MuleSoft_ conçues et publiées peuvent être découvertes et consommées via le [catalogue d'API](https://help.salesforce.com/s/articleView?id=platform.api_catalog.htm&type=5) dans _Salesforce Platform_. Le _catalogue d'API_ sert de référentiel centralisé et unifie toutes les API d'une organisation depuis _MuleSoft_, _Salesforce_, _Heroku_ et d'autres clouds dans une vue unique. Cela facilite la découverte, la compréhension et la réutilisation des API existantes pour les développeurs et les administrateurs en permettant leur utilisation dans des automatisations (par exemple, _Agentforce_, _Flow_ et _Apex_).
[MuleSoft pour Agentforce : Le Centre](https://blogs.mulesoft.com/news/mulesoft-for-agentforce-topic-center/) des rubriques permet aux développeurs d ' articuler leurs API autour de cas d ' utilisation métiers spécifiques en définissant des métadonnées Agentforce **Rubriques** et **Actions** dès la conception. Cela comprend :
- **Actions**, qui sont les tâches qu'un agent peut effectuer
- **Instructions**, qui guident l'agent sur la façon d'appliquer certaines actions
En [ajoutant cette couche sémantique](https://docs.mulesoft.com/anypoint-code-builder/ai-enabling-api-project-topic-center), le _Centre thématique_ rend les API compréhensibles et consommables par _Agentforce_, ce qui lui permet d'interagir efficacement avec les systèmes d'entreprise.
### **4.2 Agentforce Gateway**
_Agentforce Gateway_ est une couche de gouvernance centralisée conçue pour gérer et sécuriser les interactions au sein de l'écosystème _Agentforce_ en expansion. Comme _Agentforce_ intègre des API et des outils tiers supplémentaires via des protocoles tels que _MCP_, la fonction principale de l’_Agentforce Gateway_ est d’appliquer des politiques (par exemple, des limitations de taux et des restrictions d’outils) à tout le trafic sortant initié par _Agentforce_, et d’auditer toutes les requêtes sortantes.
_Agentforce Gateway_ exploite le moteur de politique de gouvernance de l ' API _MuleSoft_, qui est intégré nativement à _Salesforce Platform_. Ce moteur de stratégie basé sur _Envoy_ intercepte le trafic des agents, applique des stratégies configurées (par exemple, contrôle d'accès basé sur l'attribut et limites en quotas), et gère l'authentification et l'autorisation, le tout sans demander aux clients d'installer une infrastructure de passerelle supplémentaire.
### **4.3 Intelligence de l'intégration**
Le déploiement d'un réseau régi d'agents est une réalisation historique. Il introduit toutefois de nouveaux défis opérationnels "Jour 2". Elle nécessite un niveau d'intelligence opérationnelle amélioré pour surveiller, mesurer et dépanner un système dynamique et distribué d'acteurs autonomes. La vision architecturale ultime est un système où l’IA est utilisée non seulement pour exécuter des processus métiers, mais aussi pour surveiller, gérer et soigner l’infrastructure même sur laquelle elle fonctionne.
_La_ vision de MuleSoft pour l'intelligence de l'intégration exploite la puissance de l'écosystème _Salesforce_ élargi pour fournir des connaissances approfondies et personnalisables sur les performances du tissu d'intégration et du réseau agentique. En capturant et en stockant des données [conformes OpenTelemetry (OTEL)](https://opentelemetry.io/) \- la nouvelle norme d'observabilité - dans **Salesforce Data 360**, les organisations peuvent créer un référentiel unifié pour les journaux, les métriques et les traces dans l'ensemble de leur paysage. Ces données peuvent être visualisées dans **Tableau** via des tableaux de bord prédéfinis et des visualisations personnalisées pour recueillir des connaissances détaillées sur les performances des API, les modèles d'interaction des agents et l'intégrité générale du système.
Ce système comprend trois composants clés :
1. **Ingestion :** Le service d'ingestion est le point d'entrée centralisé pour la collecte et le traitement des données télémétriques de diverses applications _Mule_, _agents courtiers_ et _passerelles flexibles_. Il effectue la validation du schéma, la normalisation des données et le filtrage afin de maintenir la qualité et la cohérence des données entre diverses applications. En outre, il applique des contrôles (par exemple, l'authentification, le cryptage, l'équité du locataire et la limitation du taux) dans le pipeline d'ingestion.
2. **Stockage :** Une tâche de streaming haut débit exécutée dans _Data 360_ lit les données des rubriques _Kafka_ multi-locataires et les transforme au format _OTEL_. Les données OTEL sont ensuite engagées dans _Data 360_ du locataire dans les _objets modèle de_ données TelemetryTraceSpan, _TelemetryLogs_ et _TelemetryMetrics_ du _Lakehouse_.
3. **Visualisation/Consommation :** Avec les données télémétriques disponibles dans _Data 360_, les clients peuvent consulter l'intégrité du système et recueillir des connaissances en utilisant des tableaux de bord prédéfinis ou personnalisés via _Tableau Suivant_. Les clients peuvent également utiliser [Tableau Concierge](https://help.salesforce.com/s/articleView?id=analytics.tua_metric_questions.htm&type=5), une compétence analytique prédéfinie et agentique dans _Tableau Next_, qui permet aux utilisateurs de poser des questions sur les données télémétriques en langage naturel et de recevoir des réponses fiables et actionnables avec des visualisations. Les clients peuvent également exporter les données vers des systèmes existants de _Gestion des performances applicatives_ (par exemple, _DynaTrace_, _Datadog_, _Splunk_, etc.).
## **Conclusion**
La transition vers une entreprise Agentic n'est pas seulement une mise à niveau informatique, c'est un point d'inflexion architectural fondamental. Un déploiement fragmenté et cloisonné d’agents IA est une voie directe vers le chaos opérationnel, le shadow IT et la dette technique ingérable. La seule voie durable à suivre est une architecture unifiée et composable. En s'appuyant sur les bases éprouvées de la connectivité pilotée par l'API, le _tissu MuleSoft Agent_ fournit le « système nerveux central » requis pour gérer cette nouvelle force de travail numérique. Il fournit les capacités critiques de découverte, d'orchestration, de gouvernance d'entreprise et d'observabilité de bout en bout. C’est ainsi que nous dépassons l’expérimentation de l’IA et commençons à concevoir une entreprise réellement intelligente, automatisée et sécurisée, transformant un potentiel autonome en résultats métiers tangibles et gouvernés.
## **Guides techniques et références**
- [Premiers pas avec le Générateur de code Anypoint](https://docs.mulesoft.com/anypoint-code-builder/start-acb)
- [Guide technique d'Einstein pour Anypoint Code Builder: Flux](https://blogs.mulesoft.com/dev-guides/einstein-for-acb/) génératifs
- [DataWeave Generative Transformation Deep Dive : Innovation IA pour une transformation rapide des données](https://blogs.mulesoft.com/dev-guides/dataweave-generative-transformation/)
- [Création de spécifications d'API avec MuleSoft Dev Agent](https://docs.mulesoft.com/anypoint-code-builder/api-ai-create-spec)
- [Génération de documentation sur les API avec l'IA générative Einstein](https://docs.mulesoft.com/exchange/generating-documentation-with-ai)
- [Vue d'ensemble du serveur MCP MuleSoft](https://docs.mulesoft.com/mulesoft-mcp-server/)
- [Outils MuleSoft MCP Server](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools)
- [Connecteur MCP](https://docs.mulesoft.com/mcp-connector/latest/)
- [Connecteur A2A](https://docs.mulesoft.com/a2a-connector/latest/)
- [Premiers pas avec Agent Fabric](https://docs.mulesoft.com/agent-fabric/learning-map-agent-fabric)
- [Sécurisation des interactions des agents avec Flex Gateway](https://docs.mulesoft.com/gateway/latest/flex-agent-secure)
- [Stratégies Flex Gateway Agent](https://docs.mulesoft.com/gateway/latest/flex-agent-policies)
- [Vue d'ensemble du kit de développement de stratégie (PDK) Flex Gateway](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)
- [Catalogue d'API MuleSoft pour Salesforce](https://help.salesforce.com/s/articleView?id=platform.api_catalog.htm&type=5)
- [Activation d'un projet d'API pour les rubriques et les actions des agents](https://docs.mulesoft.com/anypoint-code-builder/ai-enabling-api-project-topic-center)
- [Utilisation de Tableau Next](https://help.salesforce.com/s/articleView?id=analytics.tua_consume.htm&type=5)
- [OpenTelemetry](https://opentelemetry.io/)
- [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Protocole Agent2Agent (A2A)](https://a2a-protocol.org/latest/)
## À propos de l'auteur
Nikhil Aggarwal est architecte principal chez Salesforce, où il dirige l'architecture pour MuleSoft et Salesforce Automation Cloud. Nikhil apporte plus de 18 ans d'expérience dans la livraison de produits à grande échelle et est passionné par l'architecture évolutive, les expériences intuitives de développement et la création d'équipes très performantes. Avant Salesforce, il a dirigé plusieurs initiatives dans Microsoft Power Platform, Dataverse et Office 365, du concept au lancement. Son travail continue de façonner la façon dont les entreprises modernes connectent les systèmes, automatisent les workflows et libèrent la valeur métier à l’ère de l’IA.
## Introduction
Le modèle de partage Salesforce est un élément essentiel de la capacité de votre organisation à fournir un accès sécurisé aux données des applications. Par conséquent, il est crucial d'architecturer correctement votre modèle de partage pour répondre à vos exigences actuelles et futures en matière d'accès aux données. Dans ce document, nous allons examiner les composants d'accessibilité des données, les cas d'utilisation de modèle de partage et les vraies solutions de partage client, et nous allons fournir quelques consignes de dépannage.
### Public cible et prérequis
Ce document est destiné aux administrateurs système et aux architectes avancés. Pour comprendre les concepts, vous devez avoir une Knowledge pratique du modèle de sécurité et de partage Salesforce. Les prérequis à ce guide sont les suivants :
- Aide [de Salesforce : Paramètres de partage](https://help.salesforce.com/s/articleView?id=sf.managing_the_sharing_model.htm)
- [Trailhead Module: Sécurité des données](https://trailhead.salesforce.com/en/content/learn/modules/data_security)
- [Conception de l'accès aux enregistrements pour Enterprise Scale](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_preface.htm)
- [Salesforce bien architecturée - sécurisée](/docs/architect/fr-fr/well-architected/guide/secure)
### Accès aux données non couvert
Ce guide présente les principales fonctionnalités utilisées pour contrôler l'accès au niveau de l'enregistrement aux objets standard et personnalisés. Les sujets non abordés dans ce guide comprennent :
- Accès au dossier
- Accès au contenu
- Accès Chatter
- Accès à la base de Knowledge
- Accès Idées, Questions/Réponses
- Accessibilité des données mobiles
## Types d'accès aux données
La sécurité au niveau de l'enregistrement permet d'accorder aux utilisateurs l'accès à certains enregistrements d'objet, mais pas à d'autres. Comme dans la plupart des applications, l'accès aux données commence par un utilisateur. L'application doit connaître l'utilisateur avant d'accorder l'accès. Pour Salesforce, il existe différents types d'utilisateur et, parfois, le niveau d'accès est différent selon le type. Au lieu de passer en revue chaque attribut de chaque type de licence, nous allons nous intéresser ici aux attributs intéressants qui ont un impact important sur l'accès aux données. La propriété de l'enregistrement et l'accès complet sont synonymes et interchangeables, et offrent à l'utilisateur le niveau d'accès le plus élevé à un enregistrement.
### Utilisateurs et licences
**_Utilisateurs haut volume_**
Les utilisateurs haut volume (y compris les utilisateurs détenteurs des types de licence Customer Community, High Volume Customer Portal et Authenticated Website) n'utilisent pas le modèle de partage, car leurs types de licence ne prennent pas en charge les rôles. Ces licences ont leur propre modèle de partage qui fonctionne par correspondance de clé étrangère entre l'utilisateur (titulaire de la licence) et les données des références Compte et Contact. Les administrateurs peuvent créer des ensembles de partages ou des groupes de partage pour accorder aux utilisateurs haut volume l'accès aux enregistrements.
**_Licences Chatter Free et Chatter External_**
Les licences Chatter Free et Chatter External ne suivent pas le modèle de partage standard. Ces licences n'ont pas accès aux enregistrements CRM (objets standard ou personnalisés) et à la fonctionnalité Contenu, et ne prennent pas en charge les rôles. Par conséquent, il n'y a pas de partage.
Pour la suite de ce document, nous supposons un type d'utilisateur Salesforce utilisant un modèle de partage complet. Pour plus d'informations sur chaque type de licence disponible, consultez [Licences utilisateur](https://help.salesforce.com/apex/HTViewHelpDoc?id=users_understanding_license_types.htm).
### Composants
**_Profils et ensembles d'autorisations_**
Les profils et les ensembles d'autorisations offrent une sécurité au niveau de l'objet en déterminant les types de données que les utilisateurs affichent et s'ils peuvent modifier, créer ou supprimer des enregistrements. Pour chaque objet, les autorisations « Afficher tout » et « Modifier tout » ignorent les règles et les paramètres de partage, ce qui permet aux administrateurs d'accorder rapidement l'accès aux enregistrements associés à un objet donné dans l'ensemble de l'organisation. Ces autorisations sont souvent préférables aux autorisations administratives « Afficher toutes les données » et « Modifier toutes les données », qui permettent aux utilisateurs d'afficher ou de modifier toutes les applications et données.
Les profils et les ensembles d'autorisations contrôlent également la sécurité au niveau du champ, qui détermine les champs de chaque objet auquel les utilisateurs ont accès. Par exemple, un objet peut inclure 20 champs, mais la sécurité au niveau du champ peut être configurée pour empêcher les utilisateurs d'afficher cinq des 20 champs.
Nous recommandons vivement d'utiliser des ensembles d'autorisations et des groupes d'ensembles d'autorisations au lieu de profils pour gérer les autorisations d'objet de vos utilisateurs. Comme vous pouvez réutiliser de plus petits blocs de construction d'ensembles d'autorisations, vous pouvez éviter de créer des dizaines, voire des centaines de profils pour chaque utilisateur et fonction.
**_Propriété des enregistrements et files d'attente_**
Chaque enregistrement doit appartenir à un seul utilisateur ou à une file d'attente. Le propriétaire a accès à l'enregistrement, en fonction des Paramètres d'objet de son profil. Par exemple, si le profil du propriétaire dispose de l'autorisation Créer et Lire sur un objet, mais pas de l'autorisation Modifier ou Supprimer, le propriétaire peut créer un enregistrement pour l'objet et afficher le nouvel enregistrement. Cependant, le propriétaire ne peut pas modifier ni supprimer l'enregistrement. Les utilisateurs de rang supérieur dans une hiérarchie (rôle ou territoire) héritent du même accès aux données que leurs subordonnés pour les objets standard. Si le subordonné a accès en lecture seule, les utilisateurs de rang supérieur dans la hiérarchie des rôles le seront également. Cet accès s'applique aux enregistrements appartenant à des utilisateurs, ainsi qu'aux enregistrements partagés avec eux.
Les files d'attente aident à prioriser, à distribuer et à attribuer des enregistrements aux équipes qui partagent des charges de travail. Les membres de file d'attente et les utilisateurs de rang supérieur dans la hiérarchie des rôles peuvent accéder aux files d'attente à partir de vues de liste et s'approprier les enregistrements d'une file d'attente.
Si un seul utilisateur possède plus de 10 000 enregistrements, la meilleure pratique consiste à :
- L'enregistrement utilisateur du propriétaire ne doit pas avoir de rôle dans la hiérarchie des rôles.
- Si l'enregistrement utilisateur du propriétaire doit contenir un rôle, placez-le en haut de la hiérarchie dans sa propre branche de la hiérarchie des rôles.
Pour plus d'informations, consultez [Salesforce Well-Architected - Reliable](/docs/architect/fr-fr/well-architected/guide/reliable#volume-de-données).
**_Paramètres par défaut de l'organisation_**
Les paramètres de partage de l'organisation spécifient le niveau d'accès par défaut des utilisateurs aux enregistrements des autres utilisateurs. Vous utilisez les paramètres de partage de l'organisation pour verrouiller vos données au niveau le plus restrictif. Utilisez les autres outils de sécurité et de partage au niveau de l'enregistrement pour accorder sélectivement l'accès à d'autres utilisateurs. Par exemple, les utilisateurs disposent d'autorisations au niveau de l'objet pour lire et modifier les opportunités, et le paramètre de partage à l'échelle de l'organisation est Lecture seule. Par défaut, ces utilisateurs peuvent lire tous les enregistrements d'opportunité, mais ne peuvent pas les modifier, sauf s'ils sont propriétaires de l'enregistrement ou s'ils disposent d'autres autorisations.
Les paramètres par défaut de l'organisation peuvent être modifiés d'un paramètre à l'autre (Privé à Contrôlé par parent, puis de nouveau à Privé). Cependant, ces modifications nécessitent un recalcul du partage et peuvent entraîner de longs délais de traitement selon le volume.
Pour des objets personnalisés uniquement, vous pouvez configurer le paramètre Octroyer l'accès en utilisant des hiérarchies. Si cette option n'est pas cochée (par défaut cochée), les utilisateurs de rang supérieur dans la hiérarchie des rôles ne peuvent pas hériter de l'accès. Ce paramètre se trouve dans les paramètres par défaut de l'organisation.
**_Hiérarchie des rôles_**
Une hiérarchie des rôles représente un niveau d'accès aux données dont un utilisateur ou un groupe d'utilisateurs a besoin. La hiérarchie des rôles garantit que les responsables ont toujours accès aux mêmes données que leurs employés, quels que soient les paramètres par défaut de l'organisation. Les hiérarchies de rôles ne doivent pas correspondre exactement à votre organigramme. À la place, chaque rôle dans la hiérarchie devrait représenter un niveau d'accès aux données dont un utilisateur ou un groupe d'utilisateurs a besoin.
Dans les organisations Salesforce créées dans Spring ’21 ou supérieur, vous pouvez créer jusqu'à 5000 rôles. Dans les organisations créées avant Spring ’21, vous pouvez créer jusqu'à 500 rôles et contacter le Support client de Salesforce pour augmenter cette limite. La meilleure pratique recommande de limiter le nombre de rôles internes à 25 000 et le nombre de rôles externes à 100 000.
La meilleure pratique consiste à limiter la hiérarchie des rôles à 10 niveaux maximum dans la hiérarchie.
Lorsque le rôle d'un utilisateur change, toutes les règles de partage pertinentes sont évaluées pour corriger l'accès si nécessaire. Les pairs d'un même rôle ne leur garantissent pas l'accès aux données des autres.
La modélisation de la hiérarchie des rôles commence par comprendre la structure de l'organisation. Cela est généralement construit à partir de la compréhension de la portée d'un responsable, en commençant par le haut. Le PDG supervise l'ensemble de l'entreprise. Le PDG a généralement des subordonnés directs qui peuvent ensuite être segmentés par unité commerciale (ventes ou support) ou région géographique (EMEA, APAC). Cette personne a alors des subordonnés directs qui pourraient être segmentés davantage, et ainsi de suite. Bien que cela ressemble beaucoup à un organigramme RH, lors de la modélisation de l'accès aux données, mettez l'accent sur l'accessibilité des données en tenant compte des rapports RH.
Les superpositions sont toujours la partie délicate de la hiérarchie. S'ils sont dans leur propre agence, ils ont besoin de règles de partage, d'équipes ou de gestion de territoire pour obtenir l'accès requis. S'ils sont intégrés dans la hiérarchie, cela peut avoir des répercussions sur les rapports.
Il est important de passer le temps à configurer la hiérarchie des rôles, car c'est l'un des aspects fondamentaux du modèle de partage.
| Cas d'utilisation de hiérarchie des rôles |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Accès à la gestion : la possibilité pour les responsables de voir et de faire tout ce que leurs subordonnés peuvent voir et faire. |
| Rapports de gestion : la possibilité de cumuler les rapports de façon hiérarchique afin d'afficher plus de données pour tous les utilisateurs de rang supérieur dans la hiérarchie que pour les utilisateurs de rang inférieur. |
| Séparation entre les branches de l'organisation : les différentes unités commerciales n'ont pas besoin d'afficher les données des autres. Une hiérarchie dans laquelle vous pouvez définir des branches distinctes permet de séparer la visibilité au sein des unités commerciales, tout en continuant à cumuler la visibilité jusqu'aux niveaux de direction supérieurs à ces unités. |
| Ségrégation au sein d'un rôle : dans de nombreuses organisations/applications, les personnes qui jouent toutes le même rôle ne doivent pas nécessairement afficher les données des autres. Avoir des rôles hiérarchiques permet de définir un nœud « feuille » dans lequel toutes les données sont essentiellement privées, tout en cumulant ces données dans un rôle parent qui peut toutes afficher. |
**_Groupes publics_**
Un groupe public est un ensemble d'utilisateurs individuels, de rôles, de territoires, etc., qui ont tous une fonction en commun. Les groupes publics peuvent comprendre :
- Utilisateurs
- Utilisateurs du portail client
- Utilisateurs partenaires
- Rôles
- Rôles et subordonnés internes
- Rôles, subordonnés internes et du portail
- Rôles du portail
- Rôles et subordonnés du portail
- Territoires
- Territoires et subordonnés
- Autres groupes publics (imbrication)
Les groupes peuvent être imbriqués (groupe A imbriqué dans groupe B), mais ne pas imbriquer plus de cinq niveaux. L'imbrication a un impact sur la maintenance et les performances du groupe en raison du calcul de l'appartenance au groupe. La meilleure pratique consiste à limiter le nombre total de groupes publics pour une organisation à 100 000.
| Cas d'utilisation de groupes publics |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Lorsque vous devez accorder l'accès à un groupe arbitraire de personnes, vous créez un groupe public pour les collecter, puis utilisez d'autres outils de partage pour accorder l'accès nécessaire au groupe. L'appartenance à un groupe seule ne fournit pas l'accès aux données. |
| Les groupes peuvent également être imbriqués les uns dans les autres, ce qui permet à un groupe imbriqué d'obtenir le même accès que le groupe dans lequel il est inclus. Cela permet de créer des hiérarchies ad hoc plus petites qui n'interagissent pas nécessairement avec les hiérarchies de rôles ou de territoires. Si le Groupe A est membre du Groupe B, les membres du Groupe A auront accès aux données partagées avec le Groupe B au même niveau d'accès que les membres du Groupe B. |
| Les groupes ont également la possibilité de protéger les données partagées dans le groupe contre l'accès des personnes de rang supérieur dans la hiérarchie des rôles. Ceci (et traitant de l'accès des propriétaires d'enregistrement et de leur hiérarchie de gestion) permet de créer des groupes dans lesquels des informations très confidentielles peuvent être partagées - les données seront accessibles UNIQUEMENT aux membres du groupe, et à personne d'autre dans l'organisation. Pour ce faire, utilisez le paramètre Octroyer l'accès en utilisant des hiérarchies. |
**_Règles de partage basées sur le propriétaire_**
Les règles de partage basées sur le propriétaire autorisent des exceptions aux paramètres par défaut de l'organisation et à la hiérarchie des rôles qui accordent à des utilisateurs supplémentaires l'accès aux enregistrements dont ils ne sont pas propriétaires. Les règles de partage basées sur le propriétaire sont basées uniquement sur le propriétaire de l'enregistrement.
Les règles de partage basées sur le propriétaire du contact ne s'appliquent pas aux contacts privés ou aux contacts qui ne sont pas associés à un compte.
La limite en nombre total de règles de partage par objet est de 300.
| Cas d'utilisation de règle de partage basée sur le propriétaire |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Gestion matricielle basée sur le rôle ou situations de superposition : une personne dans Service doit pouvoir afficher certaines données commerciales, mais elle vit dans différentes branches de la hiérarchie. Par conséquent, vous pouvez créer une règle qui partage des données entre des rôles dans différentes branches. |
| Pour accorder l'accès aux données à des pairs qui ont le même rôle ou territoire. |
| Accorder l'accès aux données à d'autres groupes d'utilisateurs (groupes publics, portail, rôles, territoires). Les membres des groupements propriétaires des enregistrements peuvent être partagés avec les membres d'autres groupements. |
**_Règles de partage basées sur des critères_**
Les règles de partage basées sur des critères permettent d'accéder aux enregistrements en fonction de leurs valeurs de champ (critères). Si les critères sont remplis (une ou plusieurs valeurs de champ), un enregistrement de partage est créé pour la règle. La propriété de l'enregistrement n'est pas une considération.
La limite en règles de partage basées sur des critères et pour utilisateurs invités par objet est de 50.
| Cas d'utilisation de règle de partage basée sur des critères |
| -------------------------------------------------------------------------------------------------------------------------------- |
| Pour accorder l'accès aux données à des utilisateurs ou à des groupes en fonction de la valeur d'un champ dans l'enregistrement. |
**_Règles de partage pour utilisateurs invités_**
Une règle de partage pour utilisateurs invités est un type spécial de règle de partage basée sur des critères utilisé pour accorder l'accès aux enregistrements aux utilisateurs invités non authentifiés. La limite en règles de partage basées sur des critères et pour utilisateurs invités par objet est de 50.
> **Avertissement :** Le type de règle de partage utilisateur invité accorde l'accès aux utilisateurs invités sans identifiant de connexion. En créant une règle de partage pour utilisateurs invités, vous autorisez l'accès immédiat et illimité à tous les enregistrements correspondant aux critères de la règle de partage pour tous les utilisateurs. Pour sécuriser vos données Salesforce et accorder à vos utilisateurs invités l'accès aux informations dont ils ont besoin, tenez compte de tous les cas d'utilisation et implications de la création de ce type de règle de partage. Mettez en œuvre les contrôles de sécurité que vous jugez appropriés pour la confidentialité de vos données. Salesforce n'est pas responsable de l'exposition de vos données à des utilisateurs non authentifiés en fonction de cette modification des paramètres par défaut.
| Cas d'utilisation de règle de partage pour les utilisateurs invités |
| ---------------------------------------------------------------------------- |
| Pour accorder l'accès aux données aux utilisateurs invités non authentifiés. |
**_Partage manuel_**
Il est parfois impossible de définir un groupe cohérent d'utilisateurs qui doivent accéder à un ensemble d'enregistrements particulier. Les propriétaires d'enregistrements ou d'autres utilisateurs disposant de privilèges adéquats, tels que les administrateurs système, peuvent utiliser le partage manuel pour accorder des autorisations de lecture et de modification aux utilisateurs qui n'ont pas accès autrement. Le partage manuel n'est pas automatisé, comme les paramètres de partage de l'organisation, les hiérarchies de rôles ou les règles de partage. Il offre toutefois aux propriétaires d'enregistrement la flexibilité nécessaire pour partager des enregistrements avec les utilisateurs qui doivent les afficher.
Le partage manuel est retiré lorsque le propriétaire de l'enregistrement change ou lorsque l'accès en partage accordé n'accorde pas un accès supplémentaire au-delà du niveau d'accès par défaut en partage de l'organisation. Cela s'applique également aux partages manuels créés par programmation.
Les enregistrements de partage manuel sont définis comme des enregistrements de partage avec la cause de ligne définie sur partage manuel.
Tous les enregistrements de partage (objets standard et personnalisés) avec une cause de ligne définie sur _partage manuel_ peuvent être modifiés et supprimés par le bouton **_Partager_** de la présentation de page de l'objet, même si l'enregistrement de partage a été créé par programmation.
| Cas d'utilisation du partage manuel |
| ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Permettre à l'utilisateur d'accorder l'accès (lecture seule ou lecture/écriture) à l'enregistrement actuel à d'autres utilisateurs, groupes ou rôles. |
**_Équipes_**
Une équipe est un groupe d'utilisateurs qui travaillent ensemble sur un compte, une opportunité commerciale ou une requête. Les propriétaires d'enregistrement peuvent créer une équipe pour chaque enregistrement qui leur appartient. Le propriétaire de l'enregistrement ajoute les membres de l'équipe et spécifie le niveau d'accès de chaque membre à l'enregistrement. Certains membres de l'équipe peuvent avoir accès en lecture seule, tandis que d'autres ont accès en lecture/écriture.
Seuls les propriétaires, les personnes de rang supérieur dans la hiérarchie et les administrateurs peuvent ajouter des membres à l'équipe et accorder un accès supérieur au membre. Un membre de l'équipe qui a accès en lecture/écriture peut ajouter un autre membre qui a déjà accès à l'enregistrement auquel l'équipe est associée. Le membre de l'équipe ne peut pas lui accorder un accès supplémentaire.
La création d'un membre d'équipe dans l'application crée deux enregistrements : un enregistrement d'équipe et un enregistrement de partage associé. Si vous créez des membres d'équipe par programmation, vous devez gérer l'enregistrement de l'équipe et l'enregistrement de partage associé. Il n'y a qu'une seule équipe par enregistrement (Compte, Opportunité ou Requête). Si plusieurs équipes sont nécessaires, selon vos besoins spécifiques, pensez à la gestion des territoires ou au partage par programmation.
| Cas d'utilisation d'équipe |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Offrir à l'utilisateur la possibilité d'accorder l'accès (lecture seule ou lecture/écriture) à un seul groupe d'utilisateurs (l'équipe). |
| Si les équipes sont gérées en externe, par exemple via une commission externe ou un système de gestion des territoires, l'intégration peut être utilisée pour gérer l'équipe du compte. Dans certains cas, la gestion des territoires dans un système externe peut correspondre à une solution d'équipe dans Salesforce. |
| Plusieurs propriétaires d'un compte peuvent être gérés par l'équipe du compte. |
| Un seul groupe d'utilisateurs (équipe) nécessite un accès en lecture seule ou en lecture/écriture à un enregistrement d'opportunité. (Équipe d'opportunité) |
**_Hiérarchie du territoire_**
Lors de l'utilisation de la Gestion des territoires d'entreprise, vous configurez une hiérarchie de territoires qui montre la structure des territoires d'un modèle et sert de point d'interaction principal. Si la Gestion des territoires d'entreprise est activée, vous devez gérer la hiérarchie des rôles et la hiérarchie des territoires. Pour plus d'informations, consultez [Gestion des territoires](https://help.salesforce.com/articleView?id=sf.tm2_intro.htm) d'entreprise dans l'aide de Salesforce.
**_Partage géré Apex_**
Le partage géré Apex (également appelé partage par programmation) permet d'utiliser un code pour élaborer des paramètres de partage sophistiqués et dynamiques lorsqu'une exigence d'accès aux données ne peut être satisfaite par aucun autre moyen.
Si vous créez un enregistrement de partage par programmation et que la cause de ligne prête à l'emploi (_partage manuel_) est utilisée, vous pouvez gérer cet enregistrement de partage avec le bouton **_Partager_** dans l'application. L'enregistrement de partage est soumis à toutes les règles qui entraînent le partage manuel de la ligne, par exemple la suppression lors du transfert du propriétaire.
Vous pouvez également créer vos propres motifs de partage Apex pour des objets personnalisés afin de suivre les raisons d'un enregistrement avec un utilisateur ou un groupe d'utilisateurs et simplifier le codage requis pour effectuer des mises à jour et des suppressions d'enregistrements de partage.
Pour plus d'informations, consultez [Partage d'un enregistrement avec Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing_creating_with_apex.htm) avant d'envisager le partage par programmation.
| Cas d'utilisation de partage géré Apex |
| ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Aucune autre méthode de partage (déclarative) ne répond aux besoins d'accès aux données. |
| Il existe un système de vérité externe pour les attributions d'accès utilisateur qui continuera à piloter l'accès et à être intégré à Salesforce. |
| Performances médiocres en utilisant des composants de partage natifs. (s'applique généralement à des volumes de données très importants) |
| Fonctionnalité de l'équipe sur des objets personnalisés. |
**_Règles de restriction_**
Dans votre configuration d'accès aux données, vous pouvez empêcher les utilisateurs d'afficher les enregistrements qui peuvent contenir des données confidentielles ou qui ne sont tout simplement pas essentiels à leur travail. Vous pouvez utiliser des règles de restriction pour autoriser les utilisateurs à accéder uniquement aux enregistrements qui remplissent les critères que vous spécifiez. Lorsqu'une règle de restriction est appliquée à un utilisateur, les enregistrements auxquels il a accès via les paramètres par défaut de l'organisation, les règles de partage et d'autres mécanismes de partage sont filtrés par les critères que vous spécifiez. Les règles de restriction fonctionnent de la même façon que les composants de partage abordés dans cette rubrique. Au lieu d'ouvrir l'accès aux utilisateurs, elles le limitent davantage.
Les règles de restriction sont disponibles pour les objets personnalisés, les objets externes, les contrats, les événements, les tâches, les feuilles de temps et les entrées dans les feuilles de temps. Vous pouvez créer jusqu'à deux règles de restriction actives par objet dans les éditions Enterprise et Developer, et jusqu'à cinq règles de restriction actives par objet dans les éditions Performance et Unlimited. Des règles de restriction sont appliquées aux fonctionnalités Salesforce suivantes :
- Vues de liste
- Références
- Listes associées
- Rapports
- Recherche
- SOQL
- SOSL
| Cas d'utilisation de règles de restriction |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Vous souhaitez que certains utilisateurs affichent uniquement un ensemble spécifique d'enregistrements. |
| Pour simplifier le contrôle de l'accès aux enregistrements contenant des informations confidentielles ou confidentielles. |
| Rendre l'accès aux contrats, aux tâches et aux événements vraiment privé, car cela peut s'avérer difficile en utilisant les paramètres par défaut de l'organisation. |
**_Partage implicite_**
Le partage implicite est automatique. Vous ne pouvez ni la désactiver ni l'activer, elle est native de l'application. En d'autres termes, le partage implicite n'est pas un paramètre configurable. Cependant, il est important pour tout architecte de le comprendre. Le partage implicite parent permet d'accéder aux enregistrements parents (compte uniquement) lorsqu'un utilisateur a accès à des opportunités, des requêtes ou des contacts enfants pour ce compte. Salesforce a une stratégie d'accès aux données qui indique si un utilisateur peut afficher un contact (ou une opportunité, une requête ou une commande), l'utilisateur affiche implicitement le compte associé. Le partage implicite enfant permet au propriétaire du compte d'accéder aux enregistrements enfants d'un compte. Cet accès est défini au rôle du propriétaire dans la hiérarchie des rôles. Le partage implicite enfant s'applique uniquement aux objets contact, opportunité et requête (enfants du compte). Les niveaux d'accès qui peuvent être fournis sont Afficher, Modifier et Aucun accès pour chaque objet enfant lors de la création du rôle. En définissant sur Afficher, le propriétaire du compte peut implicitement afficher les enregistrements d'objet associés (contact, opportunité ou requête). En définissant Modifier, le propriétaire du compte peut implicitement modifier l'objet associé (contact, opportunité ou requête).
Le partage implicite ne s'applique pas aux objets personnalisés.
## Scénarios d'implémentation client
Il n'existe pas de modèle de partage adapté à toutes les organisations Salesforce. Chaque organisation a des exigences et des défis différents en essayant d'architecturer le meilleur modèle de partage. Il est essentiel d'utiliser les composants d'accès aux données les plus adaptés aux exigences de partage de l'organisation. Les scénarios suivants sont des défis courants lorsque vous essayez d'élaborer un modèle de partage.
### Attribution d'équipe gérée en externe via le système principal client
| **Exigences ou défis** | **Solution** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Deux dans une boîte: un responsable commercial d'une zone de couverture géographique souhaite également accéder à une autre zone de couverture géographique afin d'aider. | Règle de partage basée sur le propriétaire : Une règle de partage basée sur le propriétaire fonctionne ici, car il s'agit de cas marginaux et non de la norme. Il est également acceptable que la règle de partage basée sur le propriétaire accorde un accès supérieur à ce qui est réellement nécessaire, car il s'agit d'un responsable - une personne de confiance. |
| Les utilisateurs des opérations basées sur un pays doivent avoir accès à toutes les données commerciales du pays. | Règle de partage basée sur le propriétaire : Une règle de partage est souvent utilisée lorsqu'un autre service (autre que commercial) doit accéder aux données commerciales. |
| Au moins 80 % du temps, il y a une équipe « core 4 » sur un compte (Account Executive, Inside Sales Rep, Sales Consultant, Technical Sales Rep). Le système d'enregistrement de l'attribution de l'équipe de compte est externe. Un compte ne contient toujours qu'une seule équipe. | Équipes : Comme il n'y a toujours qu'une seule équipe par compte, même si de nombreux membres ont des rôles différents, la fonctionnalité de l'équipe de compte répond à cette exigence. |
| Les responsables de l'équipe doivent avoir le même accès que leurs subordonnés. | Hiérarchie des rôles : La hiérarchie des rôles résout cette exigence en permettant aux responsables d'accéder aux données de leurs subordonnés. |
| L'équipe de compte attribuée ne doit pas être modifiable. | Équipes : Cette exigence n'est pas réellement satisfaite avec la fonctionnalité d'équipe de compte. Cependant, cela ne doit pas non plus vous empêcher d'utiliser des équipes de compte. Il existe cependant plusieurs façons de verrouiller les équipes. Dans ce cas, le retrait de la présentation de page de l'équipe de compte est utilisé. |
| Il doit y avoir une fonctionnalité « copain » afin que lorsqu'une personne est malade ou en vacances, une personne sans accès standard à un compte ou à une opportunité puisse être accédée et couverte pendant ses congés. | Équipes : Un « copain » peut simplement être un rôle dans l'équipe qui répond à cette exigence. Cependant, le défi vient de l'exigence précédente dans laquelle les équipes ne doivent pas être modifiables. La seule solution est d'avoir un groupe défini de personnes qui peuvent modifier les équipes pour créer le rôle de copain lorsque nécessaire. |
| Lorsqu'une affaire nécessite une solution personnalisée, des personnes supplémentaires (qui ne sont pas nécessairement dans l'organisation commerciale) doivent avoir accès à l'affaire. | Équipes : Une utilisation assez standard de l'équipe d'opportunité en ajoutant manuellement un nouveau membre à l'équipe d'opportunité (via une liste associée). Peut également être réalisé via un déclencheur si vous savez toujours qui doit être ajouté. Dans ce cas, il s'agit d'opportunité par opportunité. |
### Gestion des territoires prête à l'emploi
| **Exigences ou défis** | **Solution** |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Deux équipes d'opportunité différentes de deux unités commerciales distinctes (Ventes au détail et Remarketing) doivent accéder au même enregistrement de compte. Ils doivent partager des contacts et être informés de toutes les activités du compte. Ces deux unités commerciales ont leur propre hiérarchie et leurs propres cumuls. | Gestion des territoires : La meilleure façon de concevoir cette exigence est d'avoir deux branches d'une hiérarchie qui peuvent être structurées différemment. Ce qui justifie la gestion des territoires, c'est qu'il y a deux niveaux de ces deux branches différentes (les deux niveaux avec des membres = l'équipe d'opportunité de cette unité commerciale) qui doivent accéder au compte. Vous auriez pu satisfaire à cette exigence avec un concept Teaming, mais c'était trop granulaire. La segmentation des ventes n'était pas au niveau du compte, mais dans une hiérarchie. |
| Il existe un groupe distinct de développeurs commerciaux attribués et qui doivent accéder à des comptes spécifiques pour une équipe d'opportunité spécifique (un territoire). Les développeurs commerciaux sont des ressources partagées pour les équipes d'opportunité, ce qui signifie que chaque développeur commercial peut être attribué à un ou plusieurs comptes pour une ou plusieurs équipes d'opportunité. | Gestion des territoires : Comme il s'agit d'un groupe d'utilisateurs (ou d'une équipe), et que chaque équipe de développement commercial peut être différente selon le compte, et que la gestion des territoires était nécessaire pour une autre raison, la meilleure approche consiste probablement à établir des sous-territoires ou des succursales distinctes qui représentent ces équipes de développement commercial. |
| Certains rôles de support commercial non basés sur la commission doivent accéder aux comptes de façon ponctuelle. | Équipes : La partie clé de l’exigence est « unique ». Cela signifie qu'il est effectué compte par compte, donc les équipes de compte fournissent cela en natif. |
| Le service de crédit doit accéder à tous les comptes d'une unité commerciale donnée. | Règle de partage basée sur le propriétaire : C'est une situation où dans l'ensemble, pour une unité commerciale donnée, un groupe d'utilisateurs doit tout afficher. Cette exigence pourrait être satisfaite avec une règle de partage pour un rôle auquel le groupe appartient, une branche de la hiérarchie des rôles à laquelle le groupe appartient (rôle et subordonnés) ou même un groupe public.Gestion de territoire : Vous pouvez également satisfaire à cette exigence en modélisant le service de crédit en tant que territoire avec la même logique pour l'unité commerciale donnée. |
| Les responsables doivent avoir le même accès que leurs subordonnés. | Hiérarchie des rôles : La hiérarchie des rôles résout cette exigence en permettant aux responsables d'accéder aux données de leurs subordonnés. |
## Considérations
### Considérations relatives à l'implémentation de la Gestion des territoires d'entreprise
- Que devient la hiérarchie des rôles ?
- La hiérarchie des rôles n'est pas affectée si vous utilisez également une hiérarchie de territoires. Cependant, si vous utilisez ensemble les prévisions basées sur le territoire et les prévisions basées sur le rôle, vous devez gérer deux hiérarchies. Dans ce cas, nous recommandons d'utiliser la hiérarchie des rôles pour modéliser la structure hiérarchique des RH, puis d'utiliser la hiérarchie des territoires pour modéliser la hiérarchie commerciale réelle. La hiérarchie des territoires est plus efficace pour modéliser une structure hiérarchique matricielle, dans laquelle une personne peut rendre compte à plusieurs responsables.
Si vous n'utilisez pas ensemble les prévisions basées sur le territoire et les prévisions basées sur le rôle, vous pouvez utiliser uniquement la hiérarchie des territoires en tant que hiérarchie commerciale. Dans ce scénario, il est préférable de simplifier ou d'aplatir autant que possible la hiérarchie.
Nous recommandons de ne pas définir une hiérarchie des rôles et une hiérarchie des territoires identiques, car cela entraîne une activité de partage inutile.
- Peut-on encore utiliser Teams ?
- Oui. Cependant, si vous pouvez satisfaire à vos exigences d'accès dans la hiérarchie des territoires (par exemple des superpositions), il est préférable de le faire ici plutôt que d'utiliser des équipes. Vous gérez déjà plusieurs hiérarchies (rôle et territoire). Par conséquent, en essayant de simplifier les choses, implémentez des équipes uniquement si aucun autre composant de partage existant ne répond à l'exigence.
### Autres considérations
- Réalignement et réattribution
- Deux types de changement se produisent : l'appartenance à des rôles, des équipes ou des territoires, et la structure de la hiérarchie. Les changements d'appartenance peuvent généralement se produire tous les jours, voire toutes les heures. Les changements structurels (réalignements) de la hiérarchie se produisent généralement moins souvent (trimestriels, semestriels ou annuels) et peuvent coûter cher en ressources. Il faut tenir compte du volume de modifications et du nombre de modifications en cascade que chaque modification entraînera. En règle générale, les changements structurels ne doivent pas se produire plus d'un trimestre et tous les changements de volume élevé (changements en masse ou en masse) doivent être bien planifiés, testés et coordonnés.
- Volumes de données importants
- Que vous modélisiez pour le déploiement initial ou planifiez un changement de réalignement, vous devez prendre sérieusement en compte le volume de données. Il existe des seuils dans lesquels les performances peuvent devenir un facteur. Par conséquent, il est vivement recommandé de tester vos modifications dans une organisation sandbox avant la production. Ces tests vous donneront également une base de référence pour la durée de la modification.
Si vous avez plus de deux millions de comptes, et avez implémenté des équipes ou la Gestion des territoires d'entreprise, vous devez particulièrement faire attention aux performances. Ce sont des composants de modèle de partage complexes qui peuvent générer un volume énorme d'enregistrements de partage et, par conséquent, de longues transactions.
- Report des calculs de partage
- Si vous avez un objet qui utilise le partage et un volume d'enregistrements important (par exemple plus de deux millions de comptes), et que vous devez effectuer une modification en masse (par exemple un réalignement trimestriel nécessitant un changement de hiérarchie), le Support client de Salesforce peut activer une fonctionnalité qui reporte les calculs de partage automatiques. En natif, chaque modification individuelle de la hiérarchie des rôles, de la hiérarchie des territoires, des groupes, des règles de partage, des rôles utilisateur, de l'appartenance à une équipe ou de la propriété d'enregistrements peut initier des calculs de partage automatiques. Lorsqu'une modification en masse est effectuée, un certain nombre de recalculs de partage automatiques commencent. En suspendant provisoirement ces recalculs, vous pouvez effectuer la modification et effectuer les calculs de partage en même temps. Cette méthode est généralement plus efficace et plus performante pour les modifications en masse.
- Données et propriétés biaisées
- Les biais de données sont définis comme quelques enregistrements parents avec de nombreux enregistrements enfants. Ces biais peuvent vraiment vous nuire lorsque quelques comptes ont de nombreux contacts, opportunités ou requêtes. Le ratio où nous commençons à observer une dégradation des performances est de 1:10 000. La meilleure pratique recommande de garder le ratio aussi proche que possible (il est préférable de le réduire).
Les asymétries de propriété sont similaires aux asymétries de données, sauf que nous faisons référence à un utilisateur, un rôle ou un groupe unique possédant de nombreux enregistrements pour un objet. De la même façon que les asymétries de données, elles peuvent également entraîner de longues transactions en cours, entraînant une dégradation des performances en cas de changement. Le ratio recommandé entre le propriétaire et le nombre d'enregistrements est également de 1:10 000.
Si un seul utilisateur possède plus de 10 000 enregistrements, la meilleure pratique consiste à :
- L'enregistrement utilisateur du propriétaire ne doit pas avoir de rôle dans la hiérarchie des rôles.
- Si l'enregistrement utilisateur du propriétaire doit contenir un rôle, placez-le en haut de la hiérarchie dans sa propre branche de la hiérarchie des rôles.
- Impact des hiérarchies de comptes sur l'accès aux données
- De nombreuses personnes font une mauvaise hypothèse en implémentant une hiérarchie de comptes. Ils considèrent que les utilisateurs qui ont accès à un compte parent peuvent également accéder aux comptes enfants. Le simple fait d'avoir une relation parent/enfant uniquement entre deux enregistrements ne détermine pas l'accès. Bien que la hiérarchie des rôles et la hiérarchie des territoires fonctionnent de cette façon, pas la hiérarchie des comptes.
## Dépannage
Une fois l'architecture de votre modèle de partage terminée, vous serez probablement confronté aux raisons pour lesquelles un utilisateur peut ou ne peut pas afficher un enregistrement. Généralement, vous n'entendrez pas quand les utilisateurs peuvent afficher quelque chose qu'ils ne devraient pas, mais si nécessaire, vous pouvez afficher chaque utilisateur qui a accès à un enregistrement et pourquoi.
Le défi le plus difficile, et probablement le plus fréquent, est la raison pour laquelle un utilisateur ne peut pas afficher un enregistrement. Les couches de sécurité que vous avez conçues déterminent votre point de départ. Si vous connaissez bien le modèle de partage, vous saurez probablement quel composant aurait dû fournir l'accès et peut commencer là. Cependant, si vous êtes moins familier avec le modèle de partage, commencez par la hiérarchie des rôles et épluchez chaque couche pour déterminer laquelle doit accorder l'accès. Voici un flux de dépannage.
1. Vérifiez que l'utilisateur dispose des autorisations d'accès à l'objet.
2. Identifiez le rôle de l'utilisateur qui ne peut pas afficher l'enregistrement et notez-le.
3. Identifiez le propriétaire du rôle de l'enregistrement et notez-le.
4. Vérifiez la hiérarchie des rôles et vérifiez que ces deux rôles appartiennent à deux branches différentes (ils devraient l'être).
5. Vous devez maintenant vérifier les règles de partage de l'objet et vous assurer qu'aucune règle n'accorde l'accès à l'utilisateur. Si nécessaire, examinez également les groupes publics. Peut-être l'utilisateur a-t-il été exclu d'un groupe dans lequel il existe une règle de partage, ou est-il logique de créer une nouvelle règle de partage pour lui accorder l'accès ? Ce choix dépend de l'architecture que vous essayez de gérer et s'applique aux règles de partage basées sur le propriétaire et aux règles de partage basées sur des critères.
6. Si vous utilisez des équipes, cet utilisateur doit-il faire partie de l'équipe pour cet enregistrement ? Comment les équipes sont-elles entretenues et comment la loupe s'est-elle produite ?
7. Si le partage manuel est utilisé, l'utilisateur peut avoir perdu l'accès en raison du changement de propriétaire de l'enregistrement. Les actions manuelles sont abandonnées lorsque la propriété change. Le partage manuel aurait également pu être retiré en utilisant le bouton **Partager**.
8. Si vous utilisez la Gestion des territoires d'entreprise, l'utilisateur est-il absent de l'un des territoires ? Où l'appartenance aux territoires est-elle maintenue et comment s'est produite la non-adhésion? Ou bien l'enregistrement n'a pas été attribué au territoire dont l'utilisateur est membre.
9. Si vous créez des partages par programmation et qu'il existe des critères pour créer le partage dans un code, vérifiez le code pour comprendre pourquoi cet utilisateur a été omis.
## Vue d'ensemble
Salesforce Data 360 transforme la façon dont les entreprises connectent, harmonisent et activent les données des clients à grande échelle. Sa véritable force réside cependant dans la sécurité avec laquelle ces données sont gérées tout au long de leur cycle de vie. Cette architecture de référence de sécurité fournit un schéma pratique et complet pour la protection des environnements Data 360. Nous y parvenons grâce aux principes fondamentaux de moindre privilège, de conception zéro Trust et de gouvernance par défaut.
À la base, la sécurité dans Data 360 est un modèle de responsabilité partagée. Salesforce sécurise l'infrastructure, le réseau, les services de cryptage, la plate-forme, la conformité et l'application elle-même avec les normes internationales telles que ISO 27001, SOC 2 et le Règlement général sur la protection des données (RGPD). Les administrateurs Salesforce sécurisent les données de leur organisation sur la plate-forme en définissant l'accès, en appliquant la confidentialité et en gérant les intégrations. Cela comprend la mise en œuvre d’une solide gestion de l’identité et de l’accès (IAM) qui accorde uniquement l’accès nécessaire, l’application automatique de l’authentification à deux facteurs (2FA) et l’adhésion au principe du moindre privilège et aux mandats d’entreprise et réglementaires.
Data 360 Governance connecte ces niveaux de responsabilité, ce qui garantit l'alignement de la sécurité et de la conformité. Il garantit que les rôles, les politiques, les autorisations et les règles de traitement des données sont définis et appliqués en permanence tout au long du processus, depuis l'ingestion jusqu'à l'activation. Le lignage des données, la classification des métadonnées et la sensibilisation au consentement sont intégrés à chaque objet et processus. Cela transforme la gouvernance d'une fonction de surveillance manuelle en plan de contrôle opérationnel.
Salesforce offre une base résiliente et conforme dans laquelle les entreprises gardent toute autorité sur leur dispositif de données, leurs paramètres de confidentialité et les frontières de l'intégration. Ensemble, ils créent un tissu de sécurité et de gouvernance dans lequel chaque jeu de données, stratégie et action des utilisateurs est traçable, cohérent et ancré dans Trust.
La sécurité dans Data 360 dépasse les contrôles statiques. Il est incorporé à chaque phase du cycle de vie des données. Dès l'ingestion, les données sont cryptées, validées et classées sous les stratégies d'entreprise. À mesure qu'ils sont unifiés et enrichis, les attributs de lignage et de consentement des métadonnées sont conservés pour garantir la responsabilité. Lorsque les connaissances sont activées pour l'entreprise ou l'intelligence artificielle, les flux sortants sont protégés par des canaux cryptés, une authentification et une autorisation fortes, une gouvernance sensible aux politiques et l'application automatique du consentement, ce qui garantit que les données restent fiables, conformes et sécurisées de l'ingestion à l'activation.
## La fondation de sécurité de Data 360
### Construit sur Hyperforce
Salesforce Data 360 est une plate-forme de données native du cloud entièrement construite sur l'architecture Hyperforce de Salesforce, qui fournit une fondation sécurisée, conforme et évolutive pour les opérations mondiales.
### Fondation Secure by Design
- Hyperforce offre la sécurité et la conformité en tant que capacités intégrées, pas en tant que compléments. Il fournit un ensemble commun de contrôles de base profondément intégrés à travers les plates-formes et les applications Salesforce, garantissant que chaque couche, de l'infrastructure à l'expérience de l'application, est conçue avec la sécurité, la confidentialité et la conformité au cœur.
- Data 360 hérite des contrôles d'accès robustes, du cryptage, et des infrastructures de conformité réglementaire directement des contrôles de base d'Hyperforce.
- Ce modèle sécurisé par défaut réduit les vulnérabilités et simplifie la livraison de services de données fiables et conformes.
### Architecture native du cloud
- Data 360 s'exécute au sein d'un domaine fonctionnel dédié hébergé au-dessus d'Hyperforce, qui est une plate-forme cloud unifiée assurant l'isolation, les performances et la sécurité multi-locataires.
- Data 360 utilise une architecture de microservices, avec tous les services conteneurisés et orchestrés via Kubernetes.
- Appliquant les principes du zéro Trust, le maillage de services Istio gère la communication inter-services sécurisée et assure la gestion du trafic, l'observabilité et l'application des politiques.
### Déploiement évolutif et modulaire
- Les services Data 360 sont provisionnés et fonctionnent avec le cloud privé virtuel géré (VPC) Salesforce, ce qui permet la ségrégation, un contrôle efficace et une mise en réseau interne optimisée.
- L'architecture prend en charge l'évolutivité horizontale, ce qui permet à Data 360 de gérer les charges de travail de traitement des données à l'échelle du pétaoctet.
### Intégration et extensibilité
- Data 360 expose des API bien définies pour l'intégration à des applications Salesforce CRM et à d'autres sources de données.
- Il prend en charge les organisations Salesforce CRM tierces (1P) et Hyperforce, ce qui garantit une large compatibilité entre les environnements.
- Data Cloud One permet aux clients de connecter plusieurs organisations Salesforce CRM à une seule instance Data 360.
### Le modèle de responsabilité partagée
La sécurité dans Salesforce Data 360 fonctionne selon [un modèle de responsabilité](https://compliance.salesforce.com/en/documents/a006e000010nW2FAAU) partagée, une infrastructure également utilisée par les principaux fournisseurs de cloud tels que Amazon Web Services (AWS), Microsoft Azure et Google Cloud.
Ce modèle définit une frontière claire : Salesforce est responsable de la sécurité **du** cloud et les clients sont responsables de la sécurité **dans** le cloud. Comprendre et rendre opérationnelle cette distinction est essentiel pour maintenir un écosystème de données résilient, conforme et sécurisé.
#### Salesforce : Sécurité du Cloud
Salesforce est responsable de la sécurité et du maintien de l'intégrité de la plate-forme Data 360 et de son infrastructure mondiale. Cela comprend :
- **Sécurité physique et environnementale :** Hyperforce est hébergé sur l'infrastructure AWS et Amazon a la responsabilité déléguée de la protection de leurs centres de données mondiaux via des contrôles d'accès, la surveillance, et des sauvegardes environnementales.
- **Défense du réseau et du périmètre :** Atténuation du déni de service distribué (DDoS), détection des intrusions et cryptage pour tout le trafic en transit (TLS 1.2 et supérieur) et au repos (AES-256).
- **Rendrissage de la plate-forme et gestion des correctifs :** Gestion continue des vulnérabilités, déploiement de correctifs et référence de sécurité au niveau du système d'exploitation.
- **Conformité et certification :** Audits continus par rapport aux normes telles que SOC 1/2/3, ISO 27001, ISO 27017, ISO 27018, et préparation aux référentiels tels que GDPR .
Ces contrôles garantissent que la plate-forme Data 360 reste sécurisée, fiable et conforme, ce qui permet aux clients de se concentrer sur la logique métier et la gestion des données plutôt que sur la défense de l'infrastructure.
#### Client : Sécurité dans le Cloud
Les clients sont responsables de la sécurité de leurs données, configurations et processus opérationnels dans leur organisation Salesforce Data 360. Les principaux domaines de responsabilité comprennent :
- **Gestion des identités et des accès (IAM) :** Définissez des rôles, appliquez automatiquement l'authentification multifacteur (MFA) et l'authentification unique (SSO) et appliquez le principe du moindre privilège.
- **Gouvernance des données :** Classez les données confidentielles, appliquez le masquage lorsque nécessaire et appliquez des contrôles d'accès au niveau de l'objet, du champ et de l'enregistrement.
- **Sécurité de l'intégration :** Gérez l'accès API via OAuth 2.0, JSON Web Token JWT et d'autres normes d'authentification en utilisant des identifiants nommés et des identifiants externes.
- **Surveillance et intervention :** Utilisez la surveillance des événements et les pistes d'audit, et transmettez les journaux à un système SIEM (Security Information and Event Management) pour la détection avancée des menaces.
Salesforce fournit la base sécurisée, mais les clients déterminent leur dispositif de sécurité réel en fonction de leurs configurations, contrôles et vigilance.
#### Responsabilité centrée sur l'humain
La sécurité n’est pas seulement une construction technique, c’est une discipline organisationnelle. La protection des données dans Salesforce Data 360 est assurée par la collaboration entre l'architecture, les opérations et les équipes de gouvernance.
**Les entreprises devraient :**
- Vérifiez et retirez en permanence les comptes inutilisés ou trop privilégiés.
- Automatisez l'application en utilisant des stratégies en tant que pipelines de code et de CI/CD.
- Organisez des exercices sur table simulant des incidents tels que l'activation non autorisée de données ou l'exfiltration afin de renforcer la préparation aux interventions.
L'efficacité de Data 360 ne dépend pas uniquement des fonctionnalités, mais de la responsabilité avec laquelle les clients les rendent opérationnelles.
#### Sécurisé par défaut : Une posture de sécurité proactive
Salesforce Data 360 adopte une philosophie de sécurité par défaut, qui consiste à passer d'un contrôle réactif à une conception préventive. Au lieu de commencer à s'ouvrir et de se resserrer plus tard, chaque nouvelle organisation Data 360 commence désormais dans un état « Refuser tout », appliquant les principes de Trust zéro dès le premier déploiement.
#### Du contrôle réactif à la conception préventive
Dans les anciens environnements, les clients héritaient d'un modèle permissif « Autoriser tout » pour accélérer l'intégration. Bien que pratique, cela créait un risque de surexposition accidentelle et de configuration incorrecte.
La nouvelle architecture sécurisée par défaut inverse cette approche :
- Aucun utilisateur ou système n'a un accès implicite.
- Toutes les autorisations doivent être explicitement accordées.
- Les contrôles d'accès aux données, d'intégration et de gouvernance s'appliquent à partir du Jour 0.
Cela applique le moindre privilège par conception, réduisant considérablement le risque d'exposition accidentelle ou d'escalade des privilèges.
#### Impact opérationnel et de gouvernance
Ce modèle a des implications à la fois techniques et comportementales :
- Les équipes doivent planifier délibérément des modèles d'accès, en alignant les autorisations sur la conformité et les limites métiers.
- La gouvernance devient une exigence de conception intégrée, pas une exigence a posteriori.
- La propriété et la responsabilité des données sont définies dès le départ.
Pour les organisations Data 360 héritées qui continuent d'opérer sous « Autoriser tout », les administrateurs doivent resserrer manuellement les configurations pour les adapter à la nouvelle référence, une étape critique dans toute modernisation de la sécurité ou tout programme de maturité Data 360.
#### Trust by Design
En appliquant par défaut l'accès zéro et en exigeant des définitions de stratégie explicites, Salesforce Data 360 établit Trust by Design, une évolution fondamentale dans la sécurité des données d'entreprise.
Cette approche garantit que :
- Les risques d'accès non autorisé et de fuite de données sont réduits.
- Les cadres de gouvernance sont appliqués de façon structurelle, pas facultative.
- Les entreprises bénéficient d'un dispositif de sécurité plus prévisible, auditable et résilient dans tous les environnements.
Essentiellement, la sécurité n'est plus une fonctionnalité que vous ajoutez. C'est la base avec laquelle vous commencez.
## Gestion des identités et des accès : La passerelle vers vos données
La Gestion des identités et des accès (IAM) dans **Salesforce Data 360** est la première couche de défense et la plus critique. Il régit **qui** peut accéder à la plate-forme et **les** actions qu'il peut exécuter une fois à l'intérieur. Une infrastructure IAM bien implémentée est le contrôle le plus fort qu'une entreprise ait pour protéger les données de ses clients et garantir l'intégrité opérationnelle.
### Authentification : Vérification de « Qui vous êtes »
L'authentification établit **digital Trust,** confirmant que chaque utilisateur, service ou système externe accédant à Salesforce Data 360 est légitime.
### Gestion de l'identité fédérée
Data 360 prend en charge l'**authentification fédérée** avec des fournisseurs d'identité (IdP) de niveau entreprise tels que [**Microsoft Entra ID (Azure AD)**](https://learn.microsoft.com/en-us/entra/identity/saas-apps/salesforce-tutorial), [**Okta**](https://help.okta.com/en-us/content/topics/provisioning/salesforce/sfdc-provision.htm) ou [**Ping Identity**](https://docs.pingidentity.com/configuration_guides/salesforce/config_saml_salesforce_pf.html) en utilisant [**SAML 2.0**](https://help.salesforce.com/s/articleView?id=xcloud.sso_saml.htm&type=5), OpenID Connect ([**OIDC**](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_openid_connect.htm&type=5)) ou le système de gestion des identités inter-domaines ([**SCIM**](https://help.salesforce.com/s/articleView?id=xcloud.identity_scim_overview.htm&type=5)).
Cette fédération étend le cycle de vie de votre identité d'entreprise directement dans Salesforce. Lorsqu’un employé rejoint, transfère ou quitte l’entreprise, son accès s’ajuste automatiquement, réduisant ainsi les comptes orphelins et améliorant la préparation à la conformité.
### Authentification unique (SSO)
Avec l'[**authentification unique (SSO)**](https://help.salesforce.com/s/articleView?id=xcloud.sso_about.htm&type=5), les utilisateurs s'authentifient une fois à l'aide de leurs identifiants d'entreprise et obtiennent un accès sécurisé aux applications Salesforce sans mot de passe séparé. Cela réduit la fatigue des identifiants et réduit les risques de réutilisation du mot de passe ou d'hameçonnage.
### Accès adaptatif et conditionnel
Le fournisseur d'identité (IdP) devient l'autorité unique pour les décisions d'authentification, appliquant l'authentification multifacteur (MFA), l'accès conditionnel et les contrôles basés sur le risque. L'authentification évolue d'un événement unique à une évaluation continue de Trust, réactive au comportement et au contexte des utilisateurs.
L'authentification fédérée fournit :
- **Application centralisée des politiques :** Les normes d'authentification sont gérées à un emplacement unique dans tous les environnements Salesforce.
- **Traçabilité de bout en bout :** Les parcours d'audit unifiés lient chaque action à une identité vérifiée.
- **Expérience centrée sur l'humain :** Un processus de connexion sécurisé et sans friction permet aux équipes de se concentrer sur les connaissances, pas sur les identifiants.
### Autorisation : Définition de « Ce que vous pouvez faire »
Une fois l'utilisateur vérifié, l'autorisation définit les éléments auxquels il peut accéder, afficher ou modifier. Il définit les limites opérationnelles qui protègent les données confidentielles et appliquent le moindre privilège.
**Principe du moindre privilège (PoLP) :** Chaque utilisateur et système reçoit uniquement les autorisations nécessaires à sa fonction, rien de plus. Ce principe limite considérablement les dommages potentiels dus à des identifiants compromis ou à des configurations incorrectes.
**Contrôle d'accès basé sur le rôle (RBAC) :** Salesforce Data 360 utilise des ensembles d'autorisations et des groupes d'ensembles d'autorisations pour attribuer des capacités précises alignées sur les rôles métiers. Par exemple :
- Un ingénieur de données peut gérer les pipelines d'ingestion et les transformations avec l'ensemble d'autorisations Architecte Data 360.
- Un analyste marketing peut interroger des données harmonisées, mais ne peut pas altérer les modèles avec l'ensemble d'autorisations Gestionnaire d'activation Data 360.
- Un Gestionnaire d'activation peut exécuter des campagnes sortantes, mais ne peut pas accéder aux données sources avec l'ensemble d'autorisations Gestionnaire d'activation Data 360
L'accès est géré de façon centralisée et vérifiable, ce qui garantit la responsabilité tout au long du cycle de vie des données. Lorsqu'elles sont intégrées à des fournisseurs d'identité tels que Entra ID, Okta ou Ping Identity, les stratégies d'accès s'étendent de façon transparente dans l'entreprise via le provisionnement SCIM et la fédération SAML/SSO.
### Compréhension des rôles et des autorisations standard dans Data 360
Salesforce fournit des ensembles d'autorisations prédéfinis qui regroupent les meilleures pratiques de séparation des tâches et de conformité aux normes de l'industrie telles que ISO 27001.
### La gouvernance en tant que plan de contrôle
Data 360 est conçu autour d'un modèle axé sur la gouvernance, qui garantit que chaque interaction de données, depuis l'ingestion jusqu'à l'activation des connaissances, est sensible aux politiques, auditable et conforme. La gouvernance fonctionne comme le plan de contrôle central, gérant la découverte, la classification et la protection des données tout au long de leur cycle de vie.
Ce plan de contrôle unifié garantit :
- L'**accès aux données est contextuellement autorisé** : seuls les utilisateurs appropriés, dans le cadre des politiques appropriées, peuvent agir sur les données appropriées.
- La **gouvernance est intégrée aux couches sémantique et opérationnelle**, ce qui garantit la cohérence entre la modélisation des données et leur protection.
- Les principes **Zero Trust et Least Privilege** sont appliqués: où l'identité, le contexte et la politique sont évalués en temps réel avant d'accorder l'accès.
Avec cette architecture, Salesforce Data 360 transforme la gouvernance de la gestion des autorisations statique en une couche d'orchestration dynamique pilotée par les politiques. Une solution qui s'adapte en permanence au contexte, applique automatiquement la conformité dès la conception et maintient Trust à l'échelle de l'entreprise.
### Ségrégation de données logique avec des espaces de données
Au niveau macro, les espaces de données permettent de séparer et d'isoler logiquement les domaines de données d'entreprise, ce qui permet aux organisations qui ont des modèles d'exploitation multimarques, multirégions ou multilocataires de gérer les données sur une plate-forme unifiée unique. Les espaces de données peuvent être alignés sur des domaines métiers (tels que Ventes, Marketing ou Customer Success) ou sur des frontières réglementaires et géographiques (telles que UE, AMER ou APAC), ce qui permet aux contrôles de gouvernance et d'accès de refléter la structure d'exploitation et de conformité de l'organisation sans fragmenter la plate-forme de données sous-jacente.
- Chaque espace de données agit comme une frontière virtuelle, définissant les collections de données qu'un utilisateur ou une équipe peut afficher ou avec lesquelles interagir.
- L'accès dans un espace de données est explicitement accordé, ce qui garantit l'absence d'autorisations implicites ou de contamination croisée de la visibilité des données.
- Cela permet la propriété fédérée : chaque unité commerciale peut régir son domaine de façon indépendante tout en maintenant une surveillance et une conformité centralisées.
Par conception, les espaces de données offrent la première couche de gouvernance, établissant la clarté structurelle et la responsabilité à travers les jeux de données d'entreprise.
### De RBAC à ABAC : Progression vers l'autorisation contextuelle
Dans Salesforce Data 360, RBAC et ABAC servent des objectifs distincts mais complémentaires, et sont appliqués à différentes couches de la plate-forme.
Le RBAC est utilisé principalement pour l'accès à la plate-forme et aux capacités. Il détermine qui peut accéder aux constructions et fonctionnalités Data 360, telles que les espaces de données, la création de processus, les capacités administratives et l'accès aux outils. Le RBAC est implémenté via des autorisations et des ensembles d'autorisations, par exemple en attribuant aux utilisateurs l'accès à un espace de données avec des fonctionnalités spécifiques activées.
ABAC est utilisé pour l'application automatique de l'accès aux données. Les stratégies ABAC sont entièrement responsables de la détermination des utilisateurs autorisés à accéder aux objets et aux attributs de données, y compris la sécurité au niveau de l'objet (OLS), l'accès au niveau du champ et les contraintes au niveau de la ligne. Ces décisions sont prises dynamiquement en évaluant l'action, les attributs utilisateur et les attributs de ressource à l'exécution.
Dans ABAC, les autorisations font toujours partie du modèle, mais la stratégie elle-même détermine l'accès, pas seulement le rôle. Les politiques évaluent le contexte, par exemple l'unité commerciale, la région, la confidentialité des données, l'objet de l'utilisation ou les contraintes réglementaires pour autoriser ou refuser l'accès.
Par exemple :
- RBAC permet à un utilisateur d'accéder à un espace de données Data 360 et aux fonctionnalités d'analyse.
- ABAC détermine si le même utilisateur peut lire un jeu de données client spécifique, quelles lignes il peut afficher et quels attributs sont masqués ou restreints.
Cette séparation claire permet à Data 360 d'évoluer en toute sécurité :
- Le RBAC fournit un accès contrôlé aux capacités et aux workflows de la plate-forme.
- ABAC offre un accès précis aux données piloté par les politiques, conforme aux exigences de conformité, de résidence et de protection des données.
Ensemble, ils activent la démocratisation des données régie sans amalgamer les autorisations de plate-forme avec une logique d'autorisation des données.
Essentiellement, le RBAC applique automatiquement l'accès en fonction de l'attribution d'autorisations, tandis que le RBAC évalue les autorisations dans leur contexte, en combinant des attributs d'action, d'utilisateur et de ressource pour offrir un contrôle d'accès adaptatif et précis dans Salesforce Data 360.
### ABAC : Une hiérarchie de sécurité à plusieurs niveaux
Le contrôle d'accès basé sur l'attribut (ABAC, piloté par le langage de stratégie CEDAR) est au cœur du contrôle d'accès précis de Salesforce Data 360.
Contrairement aux autorisations statiques basées sur le rôle, ABAC évalue dynamiquement _qui_ demande l'accès, _ce_ à quoi il tente d'accéder et _dans quelles conditions_ \- en s'assurant que chaque interaction de données respecte les politiques de l'entreprise et les limites Trust.
#### Évaluation dynamique des politiques
Le moteur ABAC de Data 360 évalue les décisions d'accès en fonction d'une combinaison de trois types d'attribut principaux :
- **Attributs utilisateur:** service, emplacement, niveau d'autorisation
- **Attributs de données:** classification, confidentialité (PII, PHI, données financières), espace de données
Ce modèle flexible, piloté par les politiques, permet d'adapter automatiquement l'application à mesure que les rôles des utilisateurs, les classifications des données ou les conditions d'exploitation évoluent, ce qui est essentiel pour les grandes entreprises distribuées et réglementées.
#### Composants d'architecture ABAC dans Salesforce Data 360
Salesforce Data 360 implémente une architecture ABAC (Attribute-Based Access Control) basée sur des normes alignée sur les meilleures pratiques de l'industrie en matière de gouvernance des données pilotée par des politiques. Il est composé de trois composants fonctionnels principaux:
- **Point d'information stratégique (PIP) - Politiques, métadonnées enrichies et classification :**
- Accueille les définitions de stratégie elles-mêmes, notamment les stratégies d'accès aux données, de classification, de masquage, de rétention et d'utilisation qui régissent les données d'entreprise.
- Gère des métadonnées enrichies telles que les balises, les classifications, le contexte métier et la lignée de bout en bout.
- Utilise la classification pilotée par LLM et ML pour baliser automatiquement des données confidentielles (par exemple, PII.Email, PII.Phone, PHI).
- La propagation des balises garantit le flux automatique des classifications le long du lignage des données (DLO → DLO → DMO).
- Préserver la sensibilité et la conformité entre les transformations.
- **Point de décision politique (PDP)**: Le PDP est le moteur de décision qui interprète les politiques du CEDAR.
- Ingère les entrées contextuelles du PEP (identité de l'utilisateur, métadonnées de requête) et les attributs de référence du PEP.
- Évalue les politiques de façon déterministe pour prendre des décisions d'accès cohérentes, explicables et évolutives.
- Prend en charge les évaluations en temps réel et par lot, ce qui garantit des performances et une précision même dans les environnements à haut volume.
- **Policy Enforcement Point (PEP)**: Le PEP est l'endroit où les décisions d'autorisation sont appliquées à l'exécution.
- Intercepte les requêtes d'accès aux données à travers tous les canaux d'interaction tels que les API, les requêtes d'interface utilisateur, l'enrichissement CRM ou les pipelines GenAI Retrieval-Augmented Generation (RAG).
- Applique instantanément les résultats PDP, en s'assurant que chaque requête et récupération est conforme aux stratégies d'accès de l'entreprise.
Ensemble, la triade PIP–PDP–PEP forme un tissu de gouvernance distribué, appliquant un contrôle cohérent basé sur la politique à travers tous les services et modes d'accès Data 360.
Fait important, [ABAC](https://help.salesforce.com/s/articleView?id=data.c360_a_policy_based_governance_dg.htm&type=5) dans Data 360 est configuré, pas élaboré. Les architectes n'assemblent pas de plans de contrôle personnalisés ni de logique d'application automatique. À la place, ils remplissent et connectent trois composantes architecturales natives qui fonctionnent ensemble comme un tissu de gouvernance unifié.
Sur le plan pratique, l'implémentation suit une simple progression : classer les données, définir les stratégies et laisser la plate-forme les appliquer automatiquement. Une fois configuré, le contrôle d'accès devient un comportement système plutôt qu'un processus manuel ou procédural.
Cette structure de gouvernance répartie garantit l ' application **cohérente des politiques** dans tous les canaux d ' accès, créant un Trust unifié dans Data 360.
#### Application des politiques à plusieurs niveaux
L'infrastructure ABAC de Data 360 prend en charge les limites d'accès en couches, ce qui garantit la protection des données non seulement au niveau de l'objet, mais également dans des champs et des enregistrements spécifiques.
- **Sécurité au niveau de l'objet (OLS)**: La limite la plus extérieure du contrôle d'accès.
Gouverne l'accès à des structures de données complètes telles que des objets lac de données (DLO) ou des objets modèle de données (DMO).
Exemple : Accorder l'accès à l'objet _Client_, mais pas aux _Transactions_.
- **Sécurité au niveau du champ (FLS)**: Contrôle l'accès à des champs spécifiques dans un objet.
Exemple : Un utilisateur marketing peut afficher les noms de clients, mais il n'est pas autorisé à afficher les numéros de carte de crédit ou les identifiants nationaux.
- **Sécurité au niveau de l'enregistrement (RLS) :** La couche de contrôle la plus granulaire.
Détermine les enregistrements individuels d'un jeu de données qu'un utilisateur peut afficher ou modifier.
Exemple : Un responsable régional peut accéder uniquement aux données clients liées à sa région attribuée.
- **Masquage dynamique des données (DDM) :** Active la protection des données en temps réel. Complémentaire à ABAC, DDM applique automatiquement la masquage des informations confidentielles piloté par la politique sans altérer le jeu de données sous-jacent. Au moment de la requête, DDM masque automatiquement les champs tels que les informations d'identification personnelle ou les données financières en fonction du rôle de l'utilisateur, du contexte ou des règles de conformité.
- Les données confidentielles restent protégées dans les vues d'interface utilisateur, les API et les workflows IA.
- Réduit les risques de fuite de données en garantissant un masquage cohérent dans toutes les couches de consommation.
- Maintient l'auditabilité. Chaque requête masquée est consignée et traçable dans le cadre de gouvernance de Data 360.
Cette architecture transforme le contrôle d'accès d'un modèle d'autorisation statique en un tissu de stratégies dynamique et sensible au contexte. En combinant la simplicité structurée de RBAC à la profondeur contextuelle d'ABAC, Salesforce Data 360 réalise :
- Application cohérente des politiques par ingestion, harmonisation et activation.
- Une gouvernance adaptative qui évolue avec les données, les rôles et les besoins en conformité.
- Limites Trust unifiées à travers le cycle de vie complet des données, de l'ingestion à l'activation de l'IA.
#### Intégration approfondie à Salesforce Platform
Le modèle de gouvernance de Salesforce Data 360 est incorporé nativement à Salesforce Platform, ce qui permet d'unifier la sécurité, la conformité et le contrôle d'accès dans les données opérationnelles et analytiques. En héritant des principales capacités de gestion des identités et des accès de Salesforce, telles que la fédération de l'identité, les ensembles d'autorisations, la création de stratégies centralisée et le cryptage de la plate-forme, Data 360 applique des politiques Trust cohérentes à travers les clouds sans introduire de piles de gouvernance parallèles. Plutôt que de traiter l'isolation, l'autorisation et le lignage comme des préoccupations distinctes, la plate-forme les intègre dans un tissu Trust unique sensible à l'exécution qui couvre tout le cycle de vie des données.
Au niveau structurel, ce tissu de gouvernance est formé de trois couches complémentaires travaillant de concert:
- **Espaces de données**, qui établissent des frontières logiques claires pour l'isolation des données et la segmentation réglementaire
- **ABAC (Attribute-Based Access Control)**, qui permet des décisions d'autorisation précises et sensibles au contexte basées sur l'identité, l'objet et les attributs de données
- **Lignage sémantique**, qui préserve le sens métier, la sensibilité et la traçabilité lorsque les données passent de l'ingestion à la connaissance et à l'activation
Ensemble, ils créent un modèle de gouvernance dans lequel les décisions en matière d'accès peuvent être expliquées, l'application automatique et la conformité est continue plutôt que rétrospective. Il en résulte une plate-forme où la gouvernance n'est plus un facteur limitatif ou une réflexion a posteriori. À la place, il devient une couche habilitante, permettant aux architectes de concevoir des produits de données et des workflows pilotés par l'IA en toute confiance, la Trust et les exigences réglementaires sont appliquées par le système lui-même.
Cette approche compositionnelle garantit que les données d'entreprise restent non seulement utilisables, mais aussi actionnables de manière responsable, en prenant en charge les connaissances, l'activation et l'automatisation à grande échelle sans compromettre la transparence, la sécurité ou le contrôle.
## Sécurisation du cycle de vie des données : De l'ingestion à l'activation
À l’ère des entreprises pilotées par l’IA, la sécurisation des données n’est pas un événement unique mais un processus continu qui protège les informations depuis leur entrée dans l’écosystème jusqu’à leur activation pour l’entreprise ou l’IA.
Salesforce Data 360 incorpore des contrôles de sécurité et de gouvernance à chaque phase du cycle de vie des données, ce qui garantit que l'intégrité, la confidentialité et Trust des données sont préservés de l'ingestion à l'activation des connaissances.
### Fondation de protection : Cryptage au repos et en transit
Au cœur du modèle de protection de Salesforce Data 360 se trouve Platform Encryption for Data 360, une infrastructure de cryptage transparente et performante qui sécurise les données au repos et en transit, sans compromettre la convivialité ni l'évolutivité.
#### Cryptage au repos : Sécurité de la couche de stockage
Les données conservées dans Data 360 Data Lake sont **automatiquement cryptées au niveau** du stockage, ce qui garantit qu'elles restent illisibles même en cas d'accès physique ou non autorisé. Les capacités clés comprennent :
- **Cryptage transparent du lac de données :** Toutes les données conservées dans le lac de données sont cryptées au niveau du stockage en utilisant des clés gérées par le client (CMK). Cela garantit que même en cas d'accès non autorisé au stockage physique, les données restent illisibles et indéchiffrables.
- **Clés gérées par le client (CMK) :** Les clients gardent un contrôle total sur les clés de cryptage, une capacité cruciale pour les secteurs réglementés tels que les services financiers, la santé et le gouvernement. CMK permet un audit, un contrôle et une preuve précis de la souveraineté des données, en conformité directe avec les mandats réglementaires tels que GDPR, HIPAA et ISO 27001.
- **Gestion des clés externes (EKM) :** Avec la Gestion des clés externes, une fonctionnalité de Cryptage de la plate-forme pour Data 360, les clients pourront crypter les données dans Data 360 en utilisant des clés stockées dans les comptes AWS KMS des clients. Cela offre plus de flexibilité aux clients tout en sécurisant et en protégeant leurs données dans Data 360.
- **Apportez votre propre clé (BYOK):** En s'appuyant sur CMK et EKM, Data 360 permet désormais aux clients de charger leur propre matériel de clé directement dans Salesforce pour crypter les données au repos et les index de recherche. Cette amélioration offre une couche de protection supplémentaire pour les informations d'identification personnelle, les données confidentielles et propriétaires, sans demander aux clients de créer ou de gérer des clés dans AWS KMS.
- **Gestion de la rotation des clés et du cycle de vie :** La rotation des clés est gérée avec grâce. Les nouvelles données sont cryptées avec la nouvelle clé, alors que les anciennes restent cryptées avec sa clé d'origine, ce qui évite les temps d'arrêt ou la dégradation des performances. Ce mécanisme de rotation renforce la conformité sans interruption opérationnelle.
#### Cryptage en transit : Sécurité au niveau du réseau
Chaque élément de données transmis entre les services, les API et les connecteurs Data 360 est protégé en utilisant le protocole TLS (Transport Layer Security) 1.2 ou supérieur, qui fournit un cryptage de bout en bout en mouvement.
Cela garantit que :
- Les données ne peuvent pas être interceptées ni altérées pendant le transfert.
- Les communications entre les services Salesforce, les connecteurs de confiance et les points de terminaison clients restent privées et vérifiables.
- La sécurité s'étend de façon cohérente entre les pipelines d'ingestion, les processus d'harmonisation, les workflows d'activation et les intégrations d'API externes.
En combinant le cryptage géré au repos par le client et le cryptage continu en transit, Salesforce Data 360 crée une architecture de défense en profondeur qui protège les données des clients contre les attaques externes et les menaces d'infrastructure interne.
### Sécurisation de l'intégration système à système (intégration de données) dans Data 360
Bien que le cryptage et les contrôles d'accès protègent les données dans Salesforce Data 360, la sécurité des mouvements de données entre les systèmes est tout aussi essentielle. Les entreprises modernes fonctionnent dans des environnements multicloud et hybrides, où les données confidentielles circulent entre Salesforce, les plates-formes d'analyse, les API externes et les lacs de données.
Pour y remédier, Salesforce a conçu une infrastructure d'intégration sécurisée centrée sur les identifiants nommés (NC) et les identifiants externes (EC), qui offre une base de connectivité sécurisée pilotée par la politique et conforme à la confiance zéro.
#### Infrastructure d'intégration sécurisée de Salesforce
Salesforce a construit une **[infrastructure d'intégration](https://developer.salesforce.com/docs/platform/named-credentials/guide/get-started.html)** robuste, centrée sur les identifiants nommés (NC) et les identifiants externes (EC). Ensemble, ils éliminent la complexité des identifiants, appliquent l'accès avec le moindre privilège et permettent une gestion de l'authentification cohérente dans toutes les intégrations, sans révéler de secrets dans le code ou la configuration.
Ce cadre élimine les complexités en matière de sécurité, applique les meilleures pratiques et établit un **plan de contrôle** piloté par la politique pour toutes les connexions externes — aligné sur les principes **Zero Trust** et **security by design** de Salesforce.
##### Identifiants nommés
Les identifiants nommés (NC) sont la pierre angulaire de l'architecture d'intégration sécurisée de Salesforce. Ils fournissent un mécanisme déclaratif et centralisé pour définir des points de terminaison externes et leurs paramètres d'authentification, éliminant ainsi la nécessité de coder en dur des identifiants confidentiels tels que des noms d'utilisateur, des mots de passe ou des jetons dans un code Apex ou des fichiers de configuration. À la place, les développeurs et les administrateurs référencent simplement un alias d'identifiant nommé (par exemple SnowflakeConnector_NC), et Salesforce gère automatiquement l'authentification sous-jacente et la gestion des connexions.
**Avantages architecturaux et de sécurité :**
- **Maintenance simplifiée :** Les CN regroupent les URL de point de terminaison externe et les paramètres d'authentification dans un enregistrement géré unique. Toutes les mises à jour, telles que la modification d'un point de terminaison ou la permutation des identifiants, nécessitent de modifier uniquement l'enregistrement CN, ce qui évite le redéploiement de code ou de flux entre les environnements.
- **Sécurité avancée :** Les identifiants sont stockés en toute sécurité dans le magasin secret crypté de Salesforce, ce qui empêche l'exposition dans des référentiels de code, des fichiers de configuration ou des journaux. Le processus d'authentification lui-même est géré automatiquement à l'exécution, ce qui réduit les erreurs humaines et les risques de fuite.
**Adhérence à la conformité :** La séparation des identifiants de la logique métier simplifie la conformité aux réglementations de protection des données telles que le **RGPD, HIPAA et PCI DSS**. Les auditeurs peuvent aisément vérifier que l'accès aux données externes respecte les politiques de sécurité et de gouvernance de l'entreprise.
- **Contourne les paramètres du site distant :** Les commandes numériques éliminent l'exigence héritée de paramètres de site distant, en rationalisant la configuration et le déploiement, en particulier pour les implémentations d'entreprise à grande échelle ou à environnements multiples.
#### Identifiants externes
Les identifiants externes (EC) définissent le protocole et le flux d'authentification que Salesforce utilise lors de la connexion à un service externe. Ils répondent efficacement à la question « comment s'authentifier ». Une seule CE peut être réutilisée dans plusieurs CN qui partagent le même type d'authentification, ce qui favorise la réutilisation de la configuration et une application cohérente de la sécurité.
**Protocoles d'authentification pris en charge :**
- OAuth 2.0 (toutes les variantes prises en charge)
- JWT (jeton Web JSON)
- Authentification de base
- AWS Signature v4
- Authentification personnalisée
- Aucune authentification (pour des API ouvertes ou des points de terminaison publics)
Les Identifiants externes et les Identifiants nommés sont conçus en fonction d'une séparation claire des tâches. Un identifiant externe définit comment s'authentifier, en spécifiant le protocole d'authentification, le type de jeton et le comportement d'actualisation pour la connexion à des systèmes externes. Un identifiant nommé, quant à lui, définit l'emplacement de connexion - l'URL du point de terminaison et l'identifiant externe à utiliser pour cette connexion. Cette conception garantit le découplage de la logique d'authentification et de la configuration du point de terminaison, ce qui permet à Salesforce de prendre en charge divers protocoles d'intégration en toute sécurité tout en préservant une gestion centralisée et cohérente des identifiants dans l'ensemble de l'entreprise.
### Comment les connecteurs Data 360 exploitent cette infrastructure
Bien que l'interface utilisateur de Data 360 extrait une grande partie de la configuration sous-jacente, l'infrastructure Identifiant nommé et Identifiant externe est fréquemment utilisée en arrière-plan par ses connecteurs natifs et ses flux de données. Cela signifie que, même lorsque les administrateurs « ajoutent simplement une connexion de données » via une interface utilisateur guidée, Data 360 continue d'appliquer ce modèle de sécurité standardisé en arrière-plan.
Implications architecturales :
- **Modèle de sécurité unifié :** Chaque connecteur, que ce soit vers une base de données externe , AWS S3 ou une API d'entreprise, bénéficie des mêmes normes de cryptage, d'authentification et de gestion des clés appliquées par les identifiants nommés et externes.
- **Developer Abstraction :** Les développeurs et les administrateurs n'ont pas besoin de gérer manuellement les flux d'authentification ou la rotation des identifiants. Salesforce gère automatiquement le cycle de vie, l'expiration et l'actualisation des jetons.
- **Application cohérente des politiques :** Cette infrastructure garantit que tous les connecteurs respectent des politiques d'authentification, d'audit et de consignation cohérentes, essentielles pour l'ingestion multisource à grande échelle dans les secteurs réglementés.
- **Extensibilité à l'épreuve du temps:** À mesure que Salesforce améliore sa pile d'authentification (par exemple pour prendre en charge les nouveaux flux OAuth ou les normes FIDO2), ces améliorations se propagent automatiquement à travers tous les connecteurs sans nécessiter de refactorisation ni de redéploiement.
### Sécurité et gouvernance du connecteur Data 360
Salesforce Data 360 offre une large suite de connecteurs prêts à l'emploi qui rationalisent l'intégration de données de diverses sources. Les entreprises peuvent ainsi consolider et utiliser efficacement leurs données. Salesforce fournit plusieurs types de connecteur, notamment des connecteurs Salesforce natifs, des connecteurs de stockage cloud, des connecteurs de base de données, et des connecteurs d'application et d'API. En plus des connecteurs offerts, les outils zero ETL sont également pris en charge. Les connecteurs Salesforce permettent une intégration transparente entre les produits Salesforce, tels que Sales Cloud, Service Cloud et Marketing Cloud, avec Data 360. De plus, une gamme de connecteurs à des fournisseurs de stockage cloud, notamment Amazon S3, Google Cloud Storage et Azure Data Lake, sont offerts. Les connecteurs prédéfinis pour des bases de données telles que Snowflake, Redshift et BigQuery permettent aux entreprises de lier leurs entrepôts de données existants à Data 360. En outre, Data 360 fournit des connecteurs pour diverses applications et API tierces, telles que Google ads, Facebook ads et d'autres plates-formes marketing. Pour plus de flexibilité, Data 360 s'intègre aux outils ETL tels que MuleSoft et Informatica.
#### Connecteurs Data Security et Salesforce Data 360
La sécurité des données stockées dans Salesforce Data 360 est au cœur de nombreuses conversations associées à Data 360. Dans le cadre de l'engagement de Salesforce en faveur d'une approche de sécurité en profondeur de la défense, une importance égale est accordée à la sécurité de l'ingestion des données dans l'environnement Data 360.
Salesforce reconnaît que les entreprises opèrent dans divers écosystèmes de données, couvrant souvent plusieurs plates-formes cloud, solutions de stockage et outils d'analyse. Nos connecteurs Data 360 servent de pont entre ces environnements. Le connecteur permet une intégration de données sécurisée, évolutive et efficace tout en maintenant les normes de sécurité élevées de Salesforce. Ces connecteurs facilitent le flux de données transparent sans compromettre l'intégrité ou la confidentialité.
Les trois composants essentiels de la sécurité du connecteur Data 360 sont les suivants :
- **Mappage authentification/autorisation**: La gestion de l'accès sécurisé est fondamentale pour la sécurité des données. Différents connecteurs Cloud utilisent divers mécanismes d'authentification et d'autorisation pour valider et contrôler l'accès des utilisateurs. L'authentification garantit que les utilisateurs ou les systèmes sont des entités légitimes, tandis que l'autorisation définit le niveau d'accès accordé. Salesforce s'assure que, dans la mesure du possible, ses connecteurs respectent les normes de l'industrie.
- **Interopérabilité des fonctionnalités ZETL (Zero Copy)**: La duplication des données présente des défis de sécurité et opérationnels. Cela entraîne également des coûts de stockage inutiles, des incohérences dans les données et une exposition accrue aux risques. L'approche ZETL (Zero Extratract, Transformation and Load) de Salesforce garantit le partage de données en temps réel entre les plates-formes sans nécessiter de réplication physique des données. Cela signifie que les données peuvent rester dans leur environnement d'origine tout en restant accessibles pour le traitement, la génération de rapports et l'analyse. De plus, cela réduit considérablement la surface d'attaque et améliore la conformité potentielle aux lois sur la résidence des données.
- **Prise en charge de Data Federation**: Dans les environnements multiclouds actuels, les organisations doivent avoir un accès complet aux données sans mouvement inutile de données. Le modèle de données fédéré Connecteur Data 360 prend en charge la fédération de données basée sur des fichiers et basée sur des requêtes, ce qui permet aux entreprises d'exploiter en temps réel des sources de données externes. Que ce soit en accédant à des bases de données structurées, à des journaux semi-structurés ou à des fichiers non structurés, les connecteurs Salesforce garantissent la sécurité des données pendant tout leur cycle de vie.
Salesforce vise à fournir à ses clients la transparence nécessaire pour faciliter la navigation dans les complexités de la sécurité et de la conformité des données, même avec nos intégrations. Qu'ils s'intègrent à AWS S3, Google Cloud Storage, Snowflake ou à d'autres plates-formes, nos connecteurs Data 360 sont conçus pour garantir Trust, transparence et contrôle des données métiers critiques.
##### Mappage de la sécurité et de l'authentification du connecteur Salesforce Data 360
Toutes les communications restent dans le backbone AWS, en utilisant l'adressage IP privé et les chemins réseau non-routiers, éliminant ainsi le risque d'interception des données en transit et répondant aux exigences de sécurité strictes de l'entreprise et de la réglementation.
Cette architecture garantit :
- **Zéro exposition Internet :** Les données ne quittent jamais le réseau privé AWS.
- **Communication IP privée :** Le trafic reste isolé et impossible à traiter en externe.
- **Alignement de conformité :** Satisfait aux normes de sécurité telles que ISO 27001, SOC 2 et FedRAMP.
#### Interconnexion privée : Extension de la sécurité à travers les clouds
Pour prendre en charge les clients opérant dans des environnements multicloud, Salesforce étend les mêmes principes de sécurité au-delà d'AWS via Private Interconnect. Cette capacité permet la connectivité privée inter-clouds entre Data 360 et les lacs de données hébergés dans Azure ou Google Cloud, en maintenant les mêmes garanties d'acheminement privé, de traversée d'Internet nulle et de trafic backbone crypté uniquement.
Deux modèles de déploiement architectural sont disponibles :
- **Interconnexion gérée par les clients :** Les clients intègrent leurs circuits réseau privés existants, tels que Azure ExpressRoute, Google Cloud Interconnect ou Equinix Fabric, directement aux VPC Data 360.
- **Interconnexion gérée par Salesforce :** Salesforce provisionne et gère le lien inter-cloud, en exposant les points de terminaison de service privés dans l'environnement cloud cible du client pour une configuration clé en main.
### Sécurisation des portes : Capacités de sécurité d'API dans Salesforce Data 360
Salesforce Data 360, puissante plate-forme d'unification des données d'entreprise, est conçue avec des contrôles de sécurité robustes à plusieurs niveaux. Pour les clients, la gestion de la sécurité des API est un élément essentiel d'une stratégie globale de protection des données, qui leur permet de contrôler l'accès, de gérer les intégrations et de surveiller efficacement l'utilisation.
Voici les principales capacités et fonctionnalités disponibles pour permettre aux clients de configurer, de contrôler et de gérer la sécurité des API dans Salesforce Data 360.
#### Fonctionnalités et capacités clés de sécurité de l'API
Les clients peuvent exploiter plusieurs fonctionnalités Salesforce intégrées pour garantir un accès API sécurisé à leurs instances Data 360 :
##### 1\. Authentification et autorisation robustes (OAuth 2.0)
Salesforce impose une authentification stricte pour ses API Data 360, OAuth 2.0 étant le protocole standard et recommandé.
- **Applications connectées**: Les clients créent et configurent des applications connectées pour gérer l'accès aux applications externes. Il s'agit du principal mécanisme d'authentification et d'octroi de l'accès aux API Ingestion et Requête Data 360.
- **Étendues OAuth**: Les administrateurs peuvent définir des étendues OAuth spécifiques (par exemple, cdp_ingest_api, api) pour demander les autorisations minimales requises, en respectant le principe du moindre privilège.
- **Authentification multifacteur (MFA)**: Salesforce Authenticator et d'autres solutions de MFA peuvent être appliquées, ce qui ajoute une couche de sécurité vitale et garantit que seuls les utilisateurs vérifiés peuvent accéder au système, y compris via des connexions d'API.
##### 2\. Contrôle d'accès granulaire et autorisations
Les clients ont un contrôle précis sur les utilisateurs et les applications autorisés à accéder aux données et sur les actions qu'ils peuvent exécuter.
- **Contrôle d'accès API (fonctionnalité)**: Une fois activée par le Support Salesforce, cette fonctionnalité permet aux administrateurs d'approuver explicitement les applications connectées qui peuvent être utilisées pour accéder aux API. Toutes les applications non approuvées sont automatiquement bloquées, ce qui réduit considérablement le risque d'extraction de données non autorisée.
- **Ensembles d'autorisations et profils**: Les administrateurs gèrent l'accès API en attribuant l'autorisation « API activée » via des profils utilisateur ou des ensembles d'autorisations dédiés. Cela garantit que les utilisateurs ont accès uniquement à leurs fonctions.
- **Contrôle d'accès basé sur le rôle (RBAC)**: Dans Data 360, les clients peuvent créer et gérer des stratégies de contrôle d'accès basées sur le rôle afin de définir des niveaux d'accès aux données (sécurité au niveau de l'objet, du champ et de l'enregistrement), ce qui garantit la cohérence et le contrôle à travers la plate-forme.
- **Utilisateurs d'intégration dédiés**: Les meilleures pratiques recommandent de créer des utilisateurs « API uniquement » spécifiques pour les intégrations, en limitant leurs autorisations uniquement aux éléments nécessaires à l'appel d'API, plutôt qu'en utilisant un compte d'administrateur système.
##### 3\. Contrôles de sécurité réseau
- **Plages IP de liste blanche/connexion**: Les clients peuvent restreindre l'accès API à une plage définie d'adresses IP approuvées. Toute tentative de connexion à partir d'une plage IP non approuvée peut être refusée ou contestée pour vérification.
- **Private Connect**: Élaborée sur AWS PrivateLink, cette fonctionnalité permet aux administrateurs de gérer les données confidentielles sans exposer les points de terminaison à l'Internet public, éliminant ainsi le risque d'attaques contre les points de terminaison visibles publiquement.
- **Cryptage en transit et au repos**: Toutes les données sont cryptées en transit (par TLS) et au repos, ce qui protège les informations confidentielles contre tout accès non autorisé, même si elles sont interceptées.
##### 4\. Surveillance, audit et gouvernance
La visibilité est la clé de la sécurité. Salesforce fournit des outils complets de surveillance et d'audit de l'activité des API.
- **Surveillance des événements**: Fournit un suivi en temps quasi réel de divers événements, notamment les appels d'API et les tentatives de connexion. Les clients peuvent utiliser ces données pour effectuer des audits et créer des stratégies de sécurité des transactions.
- **Centre de sécurité**: Cette fonctionnalité offre une vue unique et consolidée des métriques d'intégrité de sécurité, de conformité et de gouvernance dans toutes les organisations Salesforce, ce qui simplifie la surveillance et la gestion.
- **Piste d'audit des champs**: Aide les clients à suivre l'historique des connexions et des champs, à surveiller les modifications apportées à la configuration et à respecter les obligations d'audit et de conformité à la rétention des données.
- **Fonctionnalités de gouvernance des données**: Inclut le balisage et la classification des données, l'application des politiques et le masquage dynamique des données pour garantir l'application de politiques de gouvernance cohérentes à tous les points de contact des données, y compris ceux accédés via des API.
#### Configuration et gestion de la sécurité d'API : Un parcours client
1. Activer les contrôles principaux : Commencez par activer les paramètres par défaut de l'organisation tels que la MFA et les restrictions IP.
2. Demander le contrôle d'accès API : Consignez une requête auprès du Support Salesforce pour activer la fonctionnalité « Contrôle d'accès API » dans votre organisation.
3. Configurer des applications connectées : Créez des applications connectées spécifiques pour chaque intégration, en définissant les étendues OAuth requises et en les attribuant à des profils/ensembles d'autorisations autorisés.
4. Implémenter le moindre privilège : Assurez-vous que tous les utilisateurs de l'intégration disposent des autorisations « API uniquement » et d'un accès minimal aux données.
5. Surveillance et audit : Utilisez régulièrement Event Monitoring and Security Center pour examiner l'utilisation de l'API, détecter les anomalies et effectuer des évaluations de vulnérabilité.
6. Appliquer les meilleures pratiques : Appliquez toujours le protocole TLS, stockez en toute sécurité les jetons d'actualisation, permutez les ID de session et validez les entrées de données.
En exploitant ces fonctionnalités robustes et configurables par les clients, les entreprises peuvent maintenir un environnement sécurisé et conforme pour toutes les interactions d'API dans Salesforce Data 360.
### Conformité, audit et surveillance continue
#### Disponibilité du service et résidence des données
Salesforce Data 360 est conçu pour répondre aux exigences mondiales de résidence et de souveraineté des données via son modèle de déploiement géographiquement distribué. Le service est actuellement disponible dans plusieurs régions réglementées, notamment aux États-Unis, au Canada, au Brésil, en Allemagne, en Inde, en Australie et au Japon.
La résidence des données est déterminée en mappant l'instance principale de chaque client avec l'instance régionale Data 360 correspondante la plus proche. Par exemple, les organisations principales situées aux États-Unis ou au Canada sont associées à une instance Data 360 aux États-Unis, alors que les organisations principales de l'Union européenne sont mappées avec une instance hébergée en Allemagne. De la même façon, les organisations principales en Inde, en Australie, en Nouvelle-Zélande ou à Singapour sont associées à une instance Data 360 hébergée en Inde.
L'infrastructure Hyperforce de Salesforce sous-tend ce modèle, fournissant les bases du contrôle des données géographiques, de l'isolation de la sécurité et de la conformité réglementaire. Hyperforce garantit que les données des clients, y compris les métadonnées, les sauvegardes et les jeux de données dérivés, restent dans les limites régionales définies. Cette architecture permet aux entreprises de respecter les obligations locales en matière de résidence et de conformité des données, telles que le RGPD, la FFIEC, HIPAA et les lois régionales sur la protection de la vie privée dans l’ensemble de l’APAC et de la EMEA.
Salesforce continue d'étendre la disponibilité de Data 360 à d'autres régions Hyperforce pour l'aligner sur l'évolution des normes mondiales de confidentialité, les exigences régionales de conformité et les attentes des clients en matière de contrôle souverain des données.
#### Activation de la conformité réglementaire
Salesforce Data 360 est conçu pour aider les entreprises à satisfaire aux exigences strictes de confidentialité et de réglementation internationales telles que le RGPD et la CCPA. La plate-forme fournit des capacités natives de gestion des droits de la personne concernée (DSR), y compris l'accès, l'exportation et la suppression des données (« Droit à l'oubli »), garantissant un traitement conforme des données personnelles tout au long de leur cycle de vie.
Bien que le client conserve la responsabilité ultime de la conformité, Salesforce opère en tant que « fournisseur de services » certifié en vertu de réglementations telles que la CCPA, en fournissant les contrôles au niveau de la plate-forme, les garanties de sécurité et les mécanismes contractuels qui permettent aux organisations d'implémenter leurs cadres de conformité efficacement et à grande échelle.
#### Trust de base : Certifications et attestations
Trust est la pierre angulaire de la plate-forme de Salesforce. Cette Trust est gagnée par une validation indépendante. Salesforce gère un large portefeuille de certifications et d'attestations de sécurité internationales qui témoignent de son engagement continu à protéger les données des clients et à respecter les normes les plus strictes de sécurité cloud.
Ces certifications ne sont pas de simples cases à cocher. Elles représentent des audits rigoureux et récurrents qui vérifient la solidité et la cohérence des contrôles de sécurité, des processus et de l'infrastructure de Salesforce. Ensemble, ils forment la colonne vertébrale du modèle de Trust fondamental de Salesforce.
**Les principales certifications et attestations comprennent :**
- **ISO/IEC 27001:** Valide le système complet de gestion de la sécurité de l'information de Salesforce.
- **ISO/IEC 27017:** Établit les meilleures pratiques pour les contrôles de sécurité spécifiques au cloud.
- **ISO/IEC 27018:** Met l'accent sur la protection des informations d'identification personnelle (PII) dans le cloud.
- **SOC 1, SOC 2 et SOC 3 :** Rapports indépendants confirmant la conception et l'efficacité opérationnelle des contrôles de sécurité et de confidentialité de Salesforce.
- **PCI DSS :** Garantit le traitement et le stockage sécurisés des informations de carte de paiement.
- **FedRAMP High & DoD Impact Level 4:** Certifie Salesforce Government Cloud à utiliser par les agences fédérales américaines qui gèrent les charges de travail confidentielles.
En maintenant cet ensemble complet de certifications, Salesforce donne aux clients la confiance que leurs données sont gérées sur une plate-forme qui répond – et souvent dépasse – les attentes mondiales en matière de conformité et de sécurité.
### Optimisation de la visibilité : Consignation, surveillance et observation dans Salesforce Data 360
Dans le paysage numérique actuel en pleine effervescence, il est crucial d'avoir une vue complète de vos données clients, mais il est tout aussi important d'avoir une vue complète de la plate-forme qui gère ces données. Salesforce Data 360 fournit des fonctionnalités robustes et intégrées de consignation, de surveillance et d'observabilité qui permettent aux clients d'assurer la qualité, la sécurité et les performances des données.
Ces outils vous aident à passer de la résolution réactive des problèmes à la gestion proactive, afin de garantir un fonctionnement fluide et efficace de votre implémentation Data 360.
#### Détection et réponse proactives aux menaces
La sécurité ne se termine pas par la prévention, elle évolue avec vigilance. Dans un paysage des menaces en constante évolution, Salesforce combine des capacités avancées de surveillance de la plate-forme à des processus d'examen gérés par les clients pour garantir une protection proactive et continue.
Salesforce fournit des outils natifs puissants pour la visibilité et la détection des menaces :
- **Le Journal d'audit** de configuration capture un historique complet des modifications administratives, ce qui aide les équipes à suivre les mises à jour de configuration ou de stratégie.
- **La Surveillance des événements** fournit des connaissances approfondies sur le comportement des utilisateurs, l'activité des API et les modèles d'accès aux données. Cette télémétrie peut être intégrée de façon transparente à une solution **SIEM (Security Information and Event Management)** pour l'analyse centralisée et la corrélation.
#### 1\. Surveillance des événements : Le pouls de votre organisation
Event Monitoring, qui fait partie de l'offre Salesforce Shield, est la plate-forme centrale de suivi des données détaillées sur l'activité des utilisateurs et les performances système dans votre organisation Salesforce, notamment les actions spécifiques à Data 360. Il capture un large éventail d'événements dans des fichiers journaux et des objets pour votre analyse.
- **Fichiers journaux des événements (ELF) :** Ils fournissent des détails précis sur l'activité des utilisateurs et les événements système, disponibles en téléchargement après un court délai (heure par heure ou tous les jours). Vous pouvez accéder à jusqu'à 30 jours de données via l'API ou le navigateur Fichier journal des événements, avec la possibilité d'exporter pour un stockage à plus long terme.
- **Surveillance des événements en temps réel :** Pour des connaissances immédiates, les événements en temps réel sont diffusés en tant qu'événements de plate-forme, ce qui permet de surveiller et de détecter l'activité en temps quasi réel. Ceci est essentiel pour la sécurité et les performances, vous permettant de prendre des mesures immédiates si nécessaire.
- **Événements spécifiques à Data 360 :** La Surveillance des événements inclut des types d'événement spécifiques à l'utilisation de Data 360, tels que Vue de page Lightning, Interaction Lightning et Événement de rapport associés aux pages et aux données Data 360.
- **Intégration à des outils externes :** Salesforce facilite l'intégration transparente à des solutions de surveillance tierces populaires telles que Splunk, Datadog, New Relic et Sumo Logic. Vous pouvez diffuser ou exporter des données de Surveillance des événements vers ces plates-formes pour une observabilité consolidée dans l'ensemble de votre pile technologique.
#### 2\. Surveillance et optimisation des performances
Comprendre les performances de votre implémentation Data 360 est essentiel pour une expérience utilisateur hors pair.
- **Application Lightning Usage :** Cette application intégrée fournit une vue agrégée des métriques de performance, telles que les temps de chargement de page (Experienced Page Time ou EPT) et les performances du navigateur, pour les pages Data 360 dans Lightning Experience.
- **Rapports et tableaux de bord personnalisés :** Vous pouvez élaborer des rapports et des tableaux de bord personnalisés en utilisant des objets Data 360 et des données Event Monitoring, notamment en utilisant une application CRM Analytics basée sur un modèle gratuite appelée Event Monitoring Plus. Ces visualisations aident à identifier rapidement les tendances et les obstacles aux performances.
Mais la technologie seule ne suffit pas. Une véritable résilience nécessite un partenariat discipliné entre la détection automatisée et l'examen humain. Les alertes automatisées peuvent révéler des anomalies en temps réel, mais les menaces subtiles ou à long terme, telles que l'exfiltration lente et non autorisée de données par un utilisateur valide, sont souvent mieux identifiées par des audits périodiques et une analyse des tendances.
Salesforce fournit la télémétrie, les journaux d'audit et les hooks d'intégration. Les clients apportent la rigueur du processus, la cadence opérationnelle et l'intelligence spécifique au contexte. Ensemble, ils forment un **modèle de défense** mêlant automatisation, analytique et surveillance humaine pour détecter, examiner et répondre aux menaces avant qu'elles ne deviennent des incidents.
### Conduire des décisions informées : Rapports, tableaux de bord, métriques et notifications dans Salesforce Data 360
Salesforce Data 360 ne se limite pas à unifier les données de vos clients, mais rend ces données intelligentes et actionnables. Une partie essentielle de cette proposition de valeur est la génération de rapports robustes, de tableaux de bord puissants, de métriques pertinentes et de fonctionnalités de notification en temps réel. Ces outils permettent aux clients de surveiller l'intégrité des données, de suivre les performances et d'automatiser les actions basées sur des données unifiées, le tout dans l'environnement familier de Salesforce.
#### Rapports et tableaux de bord : Votre plate-forme de visualisation des données
Les capacités natives de génération de rapports et de tableaux de bord de Salesforce s'étendent de façon transparente dans Data 360, ce qui vous permet de visualiser et d'analyser vos données unifiées sans quitter la plate-forme.
#### Élaboration de rapports sur des données unifiées
Vous pouvez créer des rapports standard et personnalisés sur les données stockées dans Data 360, y compris des données unifiées de diverses sources et des connaissances calculées.
- **Types de rapport standard et personnalisé :** Data 360 introduit de nouveaux types de rapport spécifiques aux objets Data 360, tels que Flux de données, Segments, Activations, Résolution de l'identité et Connaissances calculées. Vous pouvez ainsi interroger vos données unifiées avec des générateurs de rapport Salesforce standard.
- **Analyse granulaire :** Les rapports prennent en charge jusqu'à 10 regroupements de lignes, ce qui permet une segmentation plus fine et une analyse détaillée des attributs et des tendances des clients.
- **Formules et résumés :** Vous pouvez exploiter des formules récapitulatives et au niveau de la ligne pour évaluer chaque enregistrement ou groupe d'enregistrements, ce qui facilite le suivi des métriques détaillées et des résumés agrégés généraux dans un seul rapport.
#### Tableaux de bord dynamiques pour des vues globales
Les tableaux de bord présentent visuellement les métriques clés et les tendances à travers votre implémentation Data 360.
- **Vue unifiée :** Combinez les données de plusieurs rapports Data 360, ou même de rapports Data 360 avec des rapports CRM standard, dans un tableau de bord unique pour une vue globale de vos opérations et des connaissances des clients.
- **Widgets personnalisables :** Utilisez divers types de graphique (barres, lignes, secteurs, jauge, etc.) et tableaux pour afficher efficacement les données des rapports.
- **Connaissances en temps réel :** Les tableaux de bord peuvent être actualisés pour fournir des informations à jour, ce qui facilite la prise de décision rapide et pilotée par les données.
#### Métriques et indicateurs de performance clés : Mesure de la réussite
Data 360 permet de définir et de suivre des indicateurs de performance clés (KPI) pertinents pour vos objectifs métiers. Ils peuvent être générés via :
- **Connaissances calculées :** Créez des métriques puissantes en utilisant des données traitées par lots à haut volume. Par exemple, calculez des métriques telles que « Valeur moyenne de durée de vie des clients » ou « Chiffre d'affaires total des contrats actifs », puis utilisez-les en tant que dimensions ou mesures dans vos rapports et tableaux de bord.
- **Connaissances en continu :** Traitez les données de sources en continu en temps quasi réel pour élaborer des agrégations temporelles, par exemple des données d'engagement de site Web ou mobiles. Ces métriques peuvent piloter des orchestrations immédiates et des actions de données.
#### Notifications et alertes : Rester informé et proactif
Salesforce offre de puissantes fonctionnalités d'automatisation et de notification pour vous informer des événements critiques ou des modifications des données dans Data 360.
- **Notifications basées sur le flux :** Vous pouvez configurer des flux de processus pour déclencher des actions et envoyer des notifications basées sur des événements dans des objets Data 360 tels que des flux de données, des segments et des activations.
- **Alertes personnalisées :** Créez des notifications personnalisées qui déclenchent un e-mail ou sont affichées dans la cloche de notification Salesforce lorsque des conditions spécifiques sont remplies. Par exemple, vous pouvez recevoir une alerte en cas d'échec d'un flux de données, d'erreur d'une règle de résolution de l'identité ou de franchissement d'un seuil par une métrique clé.
- **Service de notification des événements (ENS) :** Pour les développeurs, le service de notification des événements API-first permet aux systèmes externes de recevoir des notifications lorsque certains événements se produisent, ce qui permet une intégration transparente et des réactions en temps réel dans votre pile technologique.
- **Actions de données :** En fonction des connaissances en continu, vous pouvez déclencher des actions de données, qui peuvent être configurées pour envoyer des alertes, invoquer des événements de plate-forme ou s'intégrer à d'autres applications SaaS via des webhooks.
En exploitant ces capacités complètes, les clients de Salesforce Data 360 peuvent surveiller efficacement leur écosystème de données, visualiser des métriques clés et recevoir des alertes en temps opportun pour favoriser l'engagement proactif et l'excellence opérationnelle.
### Recommandations stratégiques pour l'adoption en entreprise
L'adoption de Salesforce Data 360 à l'échelle de l'entreprise nécessite plus qu'une activation technique, elle exige une architecture délibérée, axée sur la sécurité. Les recommandations stratégiques suivantes fournissent aux directeurs techniques et aux architectes d'entreprise une feuille de route pour renforcer Trust, résilience et conformité dans chaque couche de leur déploiement Data 360.
- **Appliquer une approche « sûreté par conception » :** La sécurité ne doit pas être modernisée, elle doit être fondamentale. Commencez par la stratégie par défaut de Salesforce _« Refuser tout »_ et accordez explicitement l'accès si nécessaire. Définissez des infrastructures de gouvernance, de stratégie et d'accès avant d'ingérer ou d'activer des données. Le renforcement de la sécurité dès le premier jour élimine le risque d'exposition cachée et simplifie la conformité à long terme.
- **Appliquer une stratégie robuste de gestion de l'identité et de l'accès (GIA) :** Centralisez l'identité via l'authentification unique fédérée et appliquez automatiquement l'authentification multifacteur (MFA) pour limiter les compromissions d'identifiants. Limitez l'accès par plages IP de connexion et utilisez les capacités du fournisseur d'identité (IdP) de Salesforce pour établir la responsabilité de bout en bout entre les utilisateurs et les intégrations. Une couche IAM unifiée réduit la complexité opérationnelle et durcit votre surface d'authentification.
- **Appliquer le principe du moindre privilège :** Concevez des rôles précis, pas pratiques. Utilisez les ensembles d'autorisations standard de Salesforce comme fondement de la séparation des tâches, afin de garantir que les utilisateurs accèdent uniquement aux éléments nécessaires. Évitez la personnalisation excessive des autorisations : chaque écart augmente les frais de maintenance et le risque d'accès involontaire.
- **Établir un cadre de gouvernance des données à plusieurs niveaux :** Séparez les données par unité commerciale ou marque en utilisant des espaces de données, et appliquez automatiquement le contrôle d'accès basé sur l'attribut (ABAC) avec la sécurité au niveau de l'objet, du champ et de l'enregistrement (OLS, FLS, RLS). Utilisez le masquage dynamique des données pour protéger les informations confidentielles en temps réel sans entraver les analytiques ou la convivialité. Ce modèle en couches garantit la cohérence de la gouvernance à mesure que les données évoluent entre les domaines.
- **Exploiter stratégiquement le cryptage et les intégrations sécurisées :** Pour des charges de travail confidentielles, déployez le Cryptage de la plate-forme avec des clés gérées par le client (CMK) afin de préserver la souveraineté sur votre cycle de vie de cryptage. Utilisez Identifiants nommés et Private Connect pour sécuriser toutes les intégrations système à système, en éliminant les secrets codés en dur et en garantissant que tout le trafic reste privé, conforme et auditable.
- **Élaboration d'un programme d'opérations de sécurité continues :** La sécurité ne s'arrête pas à la configuration, elle repose sur la discipline opérationnelle. Complétez la surveillance automatisée par des audits réguliers des journaux des événements et des parcours d'accès. Établissez une fonction SecOps (Opérations de sécurité) dédiée pour identifier les anomalies, examiner les menaces et valider la conformité. Le but: détecter précocement, répondre rapidement et améliorer continuellement la posture.
### Chemin à suivre : Élaboration d'une Data 360 résiliente et fiable
Le parcours vers une entreprise sécurisée et intelligente ne se termine pas par un déploiement. Il évolue par discipline, design et Trust. Salesforce Data 360 fournit les fondations architecturales, mais la véritable valeur émerge lorsque les organisations mettent en œuvre la sécurité, la gouvernance et l'intelligence dans un mouvement unifié.
Les entreprises doivent aborder Data 360 non pas comme une autre plate-forme de données, mais comme une couche Trust sécurisée et composable qui connecte les données, l'IA et l'engagement des clients dans un cadre de gouvernance unique. En adoptant une philosophie _sécurisée par conception_, en appliquant le moindre privilège à chaque couche et en étendant la connectivité privée à tous les flux de données, les organisations transforment la conformité d'une case à cocher en avantage concurrentiel.
L'étape suivante est la modernisation continue, en incorporant l'automatisation de l'audit, l'application des politiques et la gestion du cycle de vie du cryptage dans les opérations quotidiennes. À mesure que les entreprises évoluent vers des architectures pilotées par l’IA, les mêmes principes qui protègent les données aujourd’hui formeront demain la colonne vertébrale de la gouvernance de l’IA, garantissant que chaque modèle, agent et décision est explicable, sensible aux politiques et conforme par sa conception.
En définitive, Trust devient la nouvelle devise de la transformation numérique. Avec Salesforce Data 360, les entreprises peuvent adapter en toute confiance leur écosystème de données, en sachant que chaque octet, chaque connexion et chaque connaissance est sécurisé, gouverné et activé avec intégrité.
## À propos des auteurs
**Krishna Chalamasandra** est une experte en cybersécurité chevronnée avec plus de 25 ans d'expérience en technologie de la sécurité de l'information et en conformité. Chez Salesforce, il agit à titre de conseiller de confiance auprès des clients et de leader clé dans la fonction Sécurité et conformité Customer Trust au sein de l'organisation CISO. Auparavant, Krishna a passé 10 ans chez Cisco, dirigeant l'architecture de sécurité à travers l'IAM, la sécurité réseau et l'ICP, et pilotant les certifications de clés, notamment ISO 27001, SOC 1–3, PCI, FedRAMP et FIPS 140-2. Il a également passé plus de 8 ans chez Novell à mettre en œuvre des contrôles au niveau de l’infrastructure et à prendre en charge des examens de sécurité complexes pour des clients réglementés internationaux.
**Yugandhar Bora** est architecte en génie logiciel chez Salesforce, spécialisé dans l'architecture de données au sein de la plate-forme Data & Intelligence Applications. Il dirige les initiatives du comité d'examen de l'architecture d'entreprise (EARB) axées sur la gouvernance des données et les modèles de données unifiés, tout en contribuant aux solutions de provisionnement de plate-forme automatisé.
Chaque jour, des [centaines de milliers d'entreprises et des millions d'utilisateurs](https://www.salesforce.com/customer-stories/) exploitent leur activité dans le cloud en utilisant des applications pilotées par Salesforce Platform. Pourquoi la plate-forme est-elle si réussie ? Pourquoi pouvez-vous lui Trust pour soutenir votre entreprise? Quels avantages uniques la plate-forme offre-t-elle aux entreprises comme la vôtre ?
Ce brief technique explique comment Salesforce Platform offre des expériences utilisateur fiables, évolutives et faciles à personnaliser en utilisant son architecture logicielle unique pour le cloud computing. Après avoir lu ce brief, vous comprendrez mieux la technologie sous-jacente qui fait de Salesforce Platform un choix attrayant pour vos applications métiers.
## Présentation de la plate-forme
Salesforce Platform est l'exemple prééminent d'une plate-forme cloud computing réussie et de l'écosystème d'applications associé. Depuis le début du millénaire, la plate-forme est la base habilitante pour :
- De nombreuses [applications métiers](http://www.salesforce.com/products/) populaires pour des cas d'utilisation courants tels que les ventes et le service client
- [Applications spécifiques au](https://www.salesforce.com/solutions/industries/) secteur d'activité pour des cas d'utilisation plus spécialisés tels que la finance et la santé
- Des millions d'[applications personnalisées et](https://www.salesforce.com/products/platform/overview/) d'extensions pour des cas d'utilisation uniques
En grande partie, Salesforce Platform connaît un grand succès et est populaire parce que son architecture logicielle unique prend en charge des applications faciles à élaborer, à utiliser, à personnaliser et à étendre avec des [performances et une fiabilité](http://trust.salesforce.com/trust/) exceptionnelles. Le cœur de l'architecture logicielle de la plate-forme est sa conception multilocataire pilotée par les métadonnées.
| Mesures de sélectivité préalables aux requêtes | Écrire une requête d'accès final à la base de données, forçant... | |
| Utilisateur | Filtre | |
| Faible | Faible | ... boucles imbriquées joindre, conduire en utilisant la vue des lignes que l'utilisateur peut voir |
| Faible | Élevée | ... utilisation de l'index associé au filtre |
| Élevée | Faible | ... jointure de hachage ordonnée, conduire en utilisant MT_DATA |
| Élevée | Élevée | ... utilisation du filtre associé à l'index |
| Comportement | Données | Métadonnées |
|---|---|---|
| Copié depuis la production vers des environnements sandbox | Non* | Oui |
| Migration par API de métadonnées | Non | Oui** |
| Migrer par chargement de données | Oui | Non |
| Peut être inclus dans des packages | Non | Oui** |
| Compte tenu des limites en stockage de données | Oui | Non |
| * Les sandbox Full copy et Partial copy permettent la réplication des données en production. **Certains types de métadonnées ne peuvent pas être utilisés avec l'API de métadonnées et/ou des packages. Vous trouverez des exceptions dans le rapport de couverture des métadonnées. |
||
| Boutique d'objets en mémoire | Magasin d'objets persistants v2 | |
|---|---|---|
| Emplacement des données | Local uniquement dans l'application. | Dans la région où l'application MuleSoft a été déployée pour la première fois. |
| Partagé entre les répliques ? | Non | Oui |
| Récupération de magasin d'objets dans les applications | Les données sont perdues. Toutes les données en mémoire sont perdues au redémarrage de l'application, lors d'un nouveau déploiement ou lors d'un échec de réplique. | Les données ne sont pas perdues, sauf si l'application est supprimée. |
| Récupération de magasin d'objets dans la région | Les données sont perdues (identique à ci-dessus). | Les données ne sont pas perdues (identique à ci-dessus). |
| Relèvement régional | Comme ci-dessus. | Les données ne sont pas disponibles. Même avec une configuration DR actif-actif, Object Store est disponible uniquement dans la région de déploiement d'origine. |
| Mitigation | Externalisez les données pour la récupération régionale. | Les données restent disponibles tant que la zone de déploiement d'origine est disponible. Pour une HA ou DR inter-régions, externalisez les données hors du magasin d'objets. |
Les composants de base de l'architecture réseau CloudHub 2.0 sont les suivants :
- Un équilibreur de charge HTTP
- Enregistrements DNS réplique mule
- Espaces privés
- Services régionaux
Pour plus d'informations, consultez [Architecture réseau CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide).
**Vanity Domains**
Lorsqu'un espace privé est créé, il reçoit un nom de cible DNS sous le format: \
CloudHub 2.0 prend également en charge les domaines personnalisés ou vanités en les configurant dans un espace privé en utilisant des contextes TLS et des enregistrements DNS. Pour créer un contexte TLS dans le Gestionnaire d'exécution pour un espace privé, chargez le certificat public et la clé privée, puis ajoutez un point de terminaison personnalisé dans les paramètres de votre application pour utiliser ce domaine. Créez un enregistrement DNS (tel qu'un CNAME) qui pointe votre domaine de vanité vers le nom d'hôte par défaut de votre espace privé.
Par exemple, une application nommée test-api déployée dans us-west-2 avec le DNS par défaut 42y52r.usa-w2.cloudhub.io a un point de terminaison d'API de :
https://test-api-mwsklu-42y52r.usa-w2.cloudhub.io
Cette URL n'utilise pas de domaine vanity ou personnalisé. Pour utiliser [acme.com](https://acme.com) afin d'afficher les URL d'API sous le format [https://test-api.acme.com](https://test-api.acme.com), procédez comme suit.
1. Créez un contexte TLS dans Runtime Manager avec des clés publiques et privées.
2. Ajoutez un domaine vanity dans les paramètres de l'application pour utiliser ce domaine.
3. Créez un enregistrement DNS dans AWS Route 53, puis configurez une simple stratégie d'acheminement (par exemple, CNAME) afin de définir le domaine vanity sur le nom d'hôte par défaut de l'espace privé.
Pour des domaines personnalisés, vous pouvez utiliser AWS Route 53 ou tout autre service CDN global avec des stratégies d'acheminement. Dans le diagramme ci-dessous, AWS Route 53 est utilisé avec une stratégie d'acheminement « simple ». Lorsqu'un consommateur d'un réseau public (externe) demande acme.com, AWS Route 53 achemine la demande vers le contrôleur d'entrée de l'espace privé MuleSoft.
## Stratégie de basculement
Utilisez cette option lorsque des applications nécessitent un basculement : déployez une instance dans la région principale (par exemple, us-west-2) et une autre dans une région secondaire (par exemple, us-east-1).
Utilisez un environnement existant dans la région secondaire lorsque cela est possible; la création d'un nouvel environnement nécessite des efforts supplémentaires.
**Exemple d'applications déployées dans une région (Ouest des États-Unis 2) avec un basculement vers une autre région (Est des États-Unis 1)**
| Nom de l'enregistrement | Valeur/Acheminement du trafic vers | Stratégie d'acheminement | ID de contrôle d'intégrité |
| :---------------------: | :--------------------------------: | :----------------------: | :------------------------: |
| acme.com | 42y52r.usa-w2.cloudhub.io | Basculement | 31s3wseq121 |
| acme.com | 31e51s.usa-e1.cloudhub.io | Basculement | 43e131s131sq |
Dans cette configuration, AWS Route 53 achemine le trafic vers les contrôleurs d'entrée pour les espaces privés dans US West 2 et US East 1. Une stratégie d'acheminement de basculement est configurée avec un contrôle d'intégrité.
## Haute disponibilité et faible latence
Pour une latence plus faible et une disponibilité élevée, utilisez la stratégie de déploiement décrite dans le diagramme. Avec cette stratégie, les applications peuvent être déployées dans deux régions (us-west-2 et us-east-1 dans cet exemple).
Utilisez la stratégie d'acheminement de latence dans AWS Route 53 pour acheminer les requêtes vers la région qui offre la latence la plus faible tout en conservant une disponibilité élevée. Stratégie d'acheminement de « latence » dans AWS Route 53 pour acheminer la requête pour une latence plus faible avec une disponibilité élevée.
**Applications déployées dans les deux régions (US West 2 et US East 1) pour une latence plus faible et une disponibilité élevée**
| Nom de l'enregistrement | Valeur/ Acheminer le trafic vers | Stratégie d'acheminement | ID de contrôle d'intégrité |
| :---------------------: | :------------------------------: | :----------------------: | :------------------------: |
| acme.com | 42y52r.usa-w2.cloudhub.io | Latence | 31s3wseq121 |
| acme.com | 31e51s.usa-e1.cloudhub.io | Latence | 43e131s131sq |
## Conclusion
MuleSoft CloudHub 2.0 fournit une base solide pour la résilience intra-région, principalement en exploitant la redondance automatisée des répliques et l'équilibrage de charge intelligent. Dans une seule région cloud, le déploiement d'applications avec plusieurs répliques garantit que si une instance échoue, d'autres peuvent immédiatement prendre en charge la charge de travail. L'équilibreur de charge intégré distribue efficacement le trafic entrant entre ces répliques saines, ce qui réduit les temps d'arrêt et garantit une disponibilité continue du service dans des conditions d'exploitation normales.
Cependant, s'appuyer exclusivement sur cette architecture monorégion, même fortement redondante, présente un risque important de panne régionale généralisée et catastrophique. L'histoire a montré que même les fournisseurs de cloud les plus fiables et les plus avancés technologiquement sont susceptibles d'incidents perturbateurs qui peuvent affecter toute une région géographique. Ces points d'échec uniques, bien que rares, peuvent découler de divers événements, notamment :
- Incidents d'infrastructure à grande échelle
- Pannes de courant majeures
- Interruptions réseau généralisées
Par conséquent, pour atteindre la véritable haute disponibilité (HA) et la reprise après sinistre (DR), une architecture doit être conçue pour transcender les limitations d'un modèle à zone unique. La stratégie recommandée est le déploiement dans plusieurs régions géographiquement distinctes. Cette résilience inter-régions garantit que si une région cloud entière n'est pas disponible en raison d'un sinistre inattendu, le trafic peut échouer de façon transparente vers une instance d'application exécutée dans une région séparée et non affectée, ce qui garantit une interruption minimale du service et atteint les objectifs de temps de fonctionnement maximum.
## Références
[Architecture réseau CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide)
[Configuration du basculement inter-régions pour les files d'attente standard](https://docs.mulesoft.com/mq/mq-failover)
[Zones de déploiement d'Object Store V2](https://docs.mulesoft.com/object-store/osv2-faq#osv2-regions)
[Votre zone de déploiement Magasin d'objets](https://docs.mulesoft.com/object-store/osv2-faq#is-object-store-v2-persistent-in-the-same-region-as-the-worker)
## À propos des auteurs
Gulal Kumar est architecte en génie logiciel chez Salesforce, spécialisé dans l'architecture de données et d'intégration. Avec plus de 20 ans d'expérience dans l'intégration et les API, les programmes de modernisation, la sécurité et les initiatives AIML, il apporte une riche expertise. Gulal s’est engagé à faire progresser les initiatives de transformation métier, à renforcer la sécurité et la résilience, à promouvoir l’excellence en architecture et à piloter des initiatives AIML dans divers domaines.
Ajay Nagaraju est architecte d'entreprise et directeur principal chez MuleSoft avec plus de 28 ans d'expérience dans l'architecture d'entreprise, l'intégration de systèmes et la transformation numérique à grande échelle. Il a dirigé l'architecture et la livraison de programmes complexes de plusieurs millions de dollars dans les organisations Fortune 100 et Fortune 500, avec une expertise approfondie dans la connectivité pilotée par l'API, la SOA, les technologies cloud et les modèles d'intégration d'entreprise. Ajay a travaillé en étroite collaboration avec la direction exécutive pour moderniser les processus métiers, les plates-formes de données et les écosystèmes d'intégration, et est passionné par l'élaboration d'architectures évolutives, le mentorat d'équipes et la génération de résultats commerciaux mesurables grâce à la technologie.
## Introduction
Ce document présente un point de vue décrivant l'architecture informatique dont les entreprises auront besoin au cours des 3 à 5 prochaines années pour capturer pleinement la valeur d'une force de travail agentique. Il décrit la transformation informatique requise pour soutenir le déploiement à grande échelle d'agents IA. L'objectif est de fournir un guide stratégique et une architecture de référence pour aider les DSI, les CDO et les responsables informatiques à planifier leur parcours vers le statut d'Entreprise Agentique.
De puissants modèles d’IA permettent de créer une force de travail agent capable de détecter l’environnement, de raisonner sur les données, de prendre des décisions autonomes, d’exécuter des tâches et de collaborer efficacement avec les travailleurs humains. Cette nouvelle force de travail promet un changement radical en matière d’innovation, de productivité et d’agilité, créant de la valeur pour les actionnaires et les clients. Pour réaliser cette vision, les organisations doivent subir une transformation métier et informatique pour devenir des Entreprises Agentiques.
## Capacités métiers de l'entreprise Agentic
Aujourd'hui, l'entreprise traditionnelle est confrontée à des inefficacités opérationnelles dues aux cloisonnements de l'information, aux employés ensevelis dans un travail manuel, aux incitations mal alignées dans les structures organisationnelles et aux boucles de rétroaction disjointes entre les stratégies et les résultats. Ces problèmes entraînent des expériences clients sous-optimales, des processus inefficaces et des opportunités de croissance manquées.
L’entreprise Agentic surmonte ces limitations en intégrant une force de travail numérique composée d’agents IA intelligents à des travailleurs humains. Avec cette nouvelle force de travail augmentée par l’IA, une organisation peut favoriser l’innovation pour la croissance, favoriser l’excellence opérationnelle et renforcer la résilience de l’entreprise avec plusieurs types de nouvelles capacités métiers.
**Nouvelles capacités commerciales pour favoriser l'innovation :**
- Productivité humaine augmentée : La vitesse, l'échelle et la nature toujours active des agents IA permettent aux entreprises d'automatiser les tâches répétitives, et de libérer les travailleurs humains pour se concentrer sur des tâches à valeur ajoutée et plus créatives.
- Amélioration de la capacité adaptative : Comme le raisonnement des agents IA peut être observé, ils peuvent apprendre et déployer dynamiquement de nouvelles compétences, permettant à l’entreprise d’améliorer continuellement ses performances pour atteindre ses objectifs métiers et s’adapter rapidement aux nouvelles opportunités du marché.
_Exemple en action — Innovation de l'expérience client dans les services financiers :_ Une société de gestion de patrimoine peut utiliser un agent IA pour réinventer son modèle d’engagement client. L'agent surveille de façon autonome les portefeuilles, identifie les moments importants pour un examen client et prépare le plan préalable à l'appel pour le conseiller, ajustant le plan à mesure que des nouvelles apparaissent. Cela permet au conseiller humain d'offrir une expérience client proactive et personnalisée à grande échelle, en renforçant les relations et en découvrant de nouvelles opportunités.
**Nouvelles capacités commerciales pour protéger et garantir la résilience organisationnelle :**
- Capacité de la force de travail élastique : Les entreprises peuvent rapidement adapter leur capacité à faire face aux augmentations de charge de travail en fonction de l'évolution de la conjoncture, sans les coûts et les délais liés à l'augmentation de la force de travail entièrement humaine.
- Résilience opérationnelle prédictive : La nature 24/7 des agents IA leur permet d'anticiper, de modéliser et d'atténuer de façon autonome et en temps réel les risques opérationnels, de conformité et de sécurité, garantissant ainsi à l'entreprise de maintenir la Trust de ses clients et parties prenantes.
_Exemple en action - Protection des données des clients :_ Une grande entreprise peut déployer un agent de gouvernance des données IA pour analyser l'environnement réglementaire afin de détecter les modifications apportées aux lois sur la confidentialité des données, découvrir et classer les informations confidentielles dans les jeux de données d'entreprise, puis appliquer la politique de gouvernance appropriée. L'agent peut examiner les demandes d'accès aux données et acheminer les exceptions vers un analyste humain pour examen, ce qui réduit les risques de conformité tout en permettant d'utiliser les données de manière fiable.
**Nouvelles capacités métiers qui optimisent l'excellence opérationnelle :**
- Exécution de processus autonome : Une force de travail numérique peut exécuter des tâches complexes en plusieurs étapes 24 heures sur 24 et 7 jours sur 7 à la vitesse de la machine (avec des êtres humains dans la boucle), réduisant ainsi les coûts et les processus d'échelle efficacement.
- Orchestration transfrontière : Les agents IA peuvent travailler à travers les silos d’information et d’incitation qui contraignent habituellement les travailleurs humains, favorisant l’agilité des processus transversaux.
_Exemple en action — Optimisation de l'entonnoir marketing dans le commerce de détail :_ Une équipe marketing de détail peut déployer un agent IA pour accélérer son processus de campagne en réponse aux nouvelles tendances de consommation. L'agent peut générer des plans marketing, collaborer avec des équipes marketing, produit et commerciales pour examen, puis créer automatiquement des garanties numériques et les exécuter sur plusieurs canaux, ajustant dynamiquement la campagne en fonction des commentaires en temps réel.
## Architecture informatique de l'entreprise Agentic
### Les limites de l'architecture informatique traditionnelle
L'architecture informatique de l'entreprise peut être représentée en utilisant une construction de couche. Les couches regroupent logiquement les fonctionnalités techniques associées et facilitent le raisonnement structuré, mais n'impliquent pas nécessairement des implémentations spécifiques ou le degré de conception d'une couche de façon monolithique ou plus hétérogène. Dans cette vue de couche (Figure 1), l'architecture informatique traditionnelle comprend cinq couches principales : Infrastructure, Données, Intégration, Application et Expérience. Deux niveaux intercalaires, Sécurité et Opérations TI, couvrent ces niveaux pour garantir la gouvernance, la surveillance et la protection.
L'architecture informatique traditionnelle a été conçue pour un paradigme où l'intelligence de l'entreprise résidait dans les travailleurs humains qui prenaient des mesures dans les applications pour accéder aux données, appliquer une logique métier, faciliter la collaboration et exécuter des workflows. Il n'est pas conçu pour un paradigme où les agents IA peuvent raisonner et prendre des mesures pour certains cas d'utilisation précédemment effectués par des humains (ou pas effectués du tout) alors que les humains supervisent les agents IA et se concentrent sur des tâches plus créatives et ambiguës.
Bien que l'architecture traditionnelle puisse prendre en charge les déploiements à l'échelle secondaire d'agents IA aujourd'hui, elle ne peut pas fournir pleinement les capacités métiers de l'entreprise Agentic décrites ci-dessus. La réalisation de ces capacités nécessite une architecture TI conçue pour le déploiement généralisé d'agents IA puissants, capables de gérer de larges cas d'utilisation, au lieu d'être limitée à des déploiements ciblant des cas d'utilisation étroits.
Les agents IA vont continuer à s’améliorer au cours des 5 prochaines années, et l’architecture TI devra évoluer afin de prendre conscience de la valeur d’agents IA plus puissants et intelligents, pour devenir une preuve future. Premièrement, les agents deviendront plus intelligents à mesure que les modèles IA sous-jacents (tels que les LLM multimodaux) et les architectures cognitives des agents évolueront (par exemple, planification à plusieurs étapes, décomposition des tâches, etc.). Deuxièmement, les agents IA auront des capacités d’apprentissage et d’adaptation améliorées avec des améliorations de la mémoire, des capacités d’auto-réflexion et la possibilité d’apprendre à partir de commentaires. Troisièmement, les agents IA auront une plus grande capacité à interagir avec d'autres agents, outils et données, comme en témoigne l'écosystème en évolution rapide des normes de technologie ouvertes (par exemple Model Context Protocol, Agent2Agent, etc.). Ces trois tendances technologiques vont permettre aux agents IA d’être plus puissants en exécutant des tâches plus abstraites et complexes, mais elles vont également introduire de nombreux défis pour l’architecture informatique d’aujourd’hui.
Premièrement, les agents IA s’appuient fondamentalement sur des modèles IA, développés en interne et de source externe, qui évoluent rapidement et nécessitent une gestion sophistiquée, partagée et normalisée des modèles IA/ML. Aujourd'hui, les modèles d'IA sont intégrés à des cas d'utilisation spécifiques dans une application, pas en tant que capacités partagées de réutilisation avec des outils communs pour la formation, le déploiement, la gouvernance et la gestion des risques. À l'avenir, les entreprises devront être en mesure d'utiliser différents modèles d'IA pour divers cas d'utilisation d'agents, ce qui nécessite un outillage permettant aux agents d'échanger des modèles sous-jacents (p. ex. modèle de base ou modèle plus petit spécifique au domaine) en fonction du contexte commercial. Cela nécessite de gérer les modèles IA développés en interne ou hébergés avec un outillage de cycle de vie unifié pour garantir la cohérence, la réutilisation, l'évolutivité et l'efficacité. De la même façon, l'accès aux modèles IA hébergés en externe nécessite un cadre de contrôle à l'échelle de l'entreprise pour garantir des performances, une sécurité, une conformité, une disponibilité et une fiabilité optimales.
Deuxièmement, les agents IA ont des modèles d'échelle et des exigences opérationnelles distincts tels que l'hébergement, le développement, le raisonnement, l'apprentissage, la gestion de la mémoire et les opérations, qui nécessitent une frontière architecturale séparée et dédiée pour les agents. L'incorporation de cette fonctionnalité directement dans l'architecture d'application statique et déterministe actuelle entraînerait une complexité architecturale et des risques inutiles. De plus, les agents IA doivent interagir avec les applications existantes via des interfaces standardisées ou des systèmes de messagerie pour une interaction en temps réel.
Troisièmement, les agents IA doivent être capables de raisonner sur des jeux de données disparates et de collaborer entre eux, souvent à travers des piles d'applications cloisonnées, mais dans l'architecture actuelle, il n'existe aucune fonctionnalité sémantique commune pour fournir une compréhension partagée permettant à ces agents de raisonner sur différents jeux de données. Par conséquent, bien que les agents à usage unique puissent être déployés avec succès, leur adaptation pour qu'ils puissent travailler en grand nombre sur des tâches complexes et inter-silos reste difficile et risquée.
Enfin, l'architecture informatique d'entreprise actuelle manque d'un moyen efficace d'orchestrer, d'optimiser et de régir les processus métiers de bout en bout qui incluent les workflows dynamiques exécutés par des agents plus puissants, ce qui augmentera et dans certains cas remplacera le rôle joué par les travailleurs humains dans ce processus. Aujourd'hui, les outils d'automatisation sont exploités pour gérer des workflows linéaires et déterministes qui suivent généralement une séquence prédéfinie, documentés dans des langages spécifiques au processus, et s'appuient sur une logique statique qui change rarement. Les technologies IA peuvent améliorer certains de ces processus linéaires (par exemple, en utilisant des modèles ML au lieu de règles métiers codées en dur pour calculer les seuils d’approbation de prêt), mais les aspects stratégiques et d’exécution de la plupart des processus métiers critiques restent par nature dynamiques et flexibles. Les tâches telles que le développement de stratégies marketing, la résolution de problèmes clients complexes ou la prospection de clients ont des objectifs clairs (satisfaction client, vitesse de résolution des requêtes, etc.) mais ne suivent pas une séquence d'exécution fixe et prédéfinie.
Actuellement, les entreprises traditionnelles comptent principalement sur l'humain pour coordonner et exécuter ces processus métiers complexes (tels que l'établissement d'une stratégie et la gestion de programmes complexes). À mesure que les agents de l’IA continueront d’évoluer (plus d’intelligence, d’apprentissage et de capacités d’interaction) au cours des 3 à 5 prochaines années, leur capacité à exécuter ces processus dynamiques de façon autonome s’élargira considérablement, introduisant des complexités et des défis d’intégration dépassant de loin les capacités des outils d’intégration et d’automatisation existants. La nature adaptative et dynamique des agents IA crée un fort besoin de nouvelles capacités d’orchestration pour garantir un contrôle au niveau de l’entreprise, une visibilité complète et un alignement cohérent avec les objectifs stratégiques de l’entreprise, en particulier dans la gestion de workflows complexes, longs et à plusieurs étapes qui englobent les agents IA, les humains, les outils d’automatisation et d’autres systèmes déterministes.
L'architecture informatique de l'entreprise Agentic établit une plate-forme pour des actions intelligentes en intégrant de façon transparente les travailleurs humains, les agents IA et les systèmes déterministes. Cette architecture permet à la fois aux agents humains et IA d'accéder dynamiquement à et d'exploiter Knowledge entreprise unifié à partir de diverses sources de données, enrichies du contexte sémantique pour exécuter efficacement des workflows et des processus complexes alignés avec les objectifs métiers stratégiques. L'architecture informatique existante d'un ensemble de plates-formes cloisonnées et de solutions ponctuelles évoluera vers un ensemble de services applicatifs composables, d'outils sémantiques et de données, et de réseaux d'agents IA supervisés et régis par de nouveaux outils intelligents d'orchestration de processus métiers.
Cette architecture permet aux agents de détecter, de raisonner et d'agir dans leurs périmètres respectifs, de travailler dans et entre les domaines métiers, et d'apprendre, de s'améliorer et de s'adapter en permanence. Cela nécessite une conception axée sur des mécanismes robustes pour accéder aux données et Knowledge (compréhension sémantique), des protocoles et des interfaces de communication flexibles et standardisés (tels que agent à agent, agent à systèmes déterministes et agent à humain) et de manière critique, orchestrer les workflows et les processus entre les agents, les humains, et les outils d'automatisation et les systèmes déterministes.
### Principes d'architecture
Pour réaliser la vision architecturale d'une plate-forme pour des actions intelligentes, les principes de conception suivants sont recommandés comme meilleure pratique:
- **Composabilité et modularité :** Concevez des éléments architecturaux en tant que composants modulaires avec des interfaces standardisées afin de permettre un assemblage rapide et dynamique des capacités des agents, des workflows et des surfaces à visage humain. Donnez la priorité à des contrats d’interface clairs et à l’abstraction afin de permettre aux agents IA de composer des workflows avec la plus grande flexibilité.
- **Données et sémantique d'abord :** Garantissez un accès complet, précis, rapide, sécurisé et économique aux données, avec une compréhension sémantique partagée permettant aux agents de raisonner efficacement à travers les systèmes cloisonnés. Cela nécessite de traiter les données (et les métadonnées) comme un produit, avec des outils pour garantir la qualité, la filiation, la gouvernance et l'accès, ainsi qu'un moyen de fournir une compréhension sémantique partagée entre les agents et les humains.
- **Observabilité informatique et métier incorporée :** Incorporez des capacités de surveillance, de traçage, d'évaluation et d'explicabilité de bout en bout à l'architecture complète pour recueillir des connaissances sur le raisonnement, les comportements, les interactions système et l'impact des agents sur les indicateurs de performance clés métiers afin d'optimiser en permanence les performances des agents. Cela inclut l'optimisation des coûts (FinOps), les métriques de développement durable et la télémétrie opérationnelle tout en maintenant Trust, conformité et consommation responsable des ressources. Comme les agents IA sont intrinsèquement non déterministes, l’observabilité est primordiale pour garantir que les agents IA peuvent opérer de façon fiable, conforme et vérifiable avec une surveillance humaine.
- **Trust-throughout:** Appliquez des autorisations dynamiques et précises basées sur l'intention des tâches de l'agent (accès aux données, actions, etc.) et implémentez des pratiques de sécurité complètes, notamment l'équipe rouge, l'analyse CVE automatisée, la détection des vulnérabilités et des contrôles de validation basés sur le risque. Des contrôles plus précis et dynamiques sont nécessaires compte tenu du risque que les agents entraînent des risques en cascade dus à leur capacité à fonctionner à des vitesses de machine. Assurez-vous que tous les résultats générés par l’IA (à partir d’agents ou de modèles) sont rigoureusement validés par rapport aux politiques définies de conformité, de sécurité, de toxicité et de biais avant utilisation ou livraison, ce qui nécessite des mécanismes de consignation et d’explicabilité avec des pistes d’audit vérifiables pour les décisions, les actions, les contenus et les prédictions en IA.
- **Agent d'abord avec surveillance humaine :** Permettez aux agents IA d'être l'outil par défaut pour résoudre les cas d'utilisation métiers, sauf autres considérations (par exemple, coût, adéquation technique), et concevez des systèmes informatiques accessibles pour les workflows des agents. Cela inclut la capacité des humains à surveiller, intervenir et remplacer n'importe quelle étape du processus d'un agent. Les agents ont besoin de capacités autoréfléchissantes pour rechercher proactivement des conseils humains si leur confiance dans la prise de décision est inférieure aux seuils préprogrammés.
- **Interaction réactive et multimodale :** Activez l'architecture pour prendre en charge des mécanismes complets d'invocation et de réponse des agents dans tous les types d'interaction, y compris les protocoles agent à agent, les entrées multimodales humaines (voix, texte, visuel), les événements métiers, les signaux système et les données en continu. Activez les capacités de traitement piloté par l'événement et en temps réel pour permettre aux agents de réagir à tout signal opportun de n'importe quelle source ou format.
- **Infrastructure prête pour l’IA :** Assurez-vous que l'infrastructure peut évoluer élastiquement avec la redondance intégrée pour gérer les charges de travail IA fluctuantes, et intégrez des pipelines ML/LLM dans l'architecture des données et des applications, tout en préservant la conformité aux exigences de résidence des données.
- **Écosystème ouvert :** Privilégiez l'interopérabilité et évitez le verrouillage technologique en privilégiant des normes ouvertes, des protocoles et des interfaces bien définies (API, événements) pour bénéficier de l'écosystème technologique.
## Couches d'architecture
Pour réussir à activer et à adapter la transformation agentique, les entreprises doivent aller au-delà de la simple amélioration des couches actuelles ; elles doivent envisager explicitement d’introduire quatre couches architecturales supplémentaires (figure 2) conçues spécifiquement pour répondre aux besoins des agents IA.
La **couche Agentic** est dédiée au développement et à la gestion des agents IA, englobant les capacités cognitives telles que la planification, le raisonnement, la mémoire, l'utilisation des outils, la gestion des états et le contrôle du cycle de vie. Cette couche répond aux exigences techniques et opérationnelles uniques des agents IA, garantit l'interopérabilité entre les applications et les magasins de données grâce à des protocoles standardisés, et facilite la collaboration entre agents. La couche applicative existante évoluera vers des services applicatifs à composer dynamiquement pour les workflows des agents.
La **couche sémantique** est introduite pour résoudre la déconnexion entre les données brutes d’entreprise et la compréhension sémantique dont les agents IA ont besoin. Il code et gère explicitement les entités métiers, les concepts, les définitions et les inter-relations, créant une ontologie d'entreprise et une représentation de Business Knowledge pour permettre une compréhension sémantique partagée qui propulsent des workflows multi-agents plus complexes exécutant des tâches de niveau supérieur. Au-delà d'un catalogue de données, la couche sémantique traduit une requête en langage naturel en requêtes précises sur des magasins de données spécifiques, harmonise les résultats et renvoie une réponse contextuelle et enrichie pour l'agent. La couche de données existante s'unifie en adoptant des lacs centralisés tout en élargissant l'accès aux données via un tissu de données prêt pour l'IA afin de prendre en charge les principes du modèle d'exploitation du maillage de données.
La **couche IA/ML** centralise la gestion des capacités IA d'entreprise, notamment les grands modèles de langage, les grands modèles d'action et les modèles ML spécifiques au domaine, en gérant à la fois les modèles IA développés en interne tout au long de leur cycle de vie et l'accès/l'utilisation contrôlée aux services IA externes. Contrairement aux architectures traditionnelles dans lesquelles les modèles IA sont incorporés dans des applications, cette couche établit les modèles IA en tant que composants de première classe et services partagés dans l'entreprise. Il se concentre sur les capacités IA contrôlées par l'entreprise (pas sur les capacités IA fournies par des fournisseurs externes). Cette couche fournit l'intelligence pour divers agents et autres charges de travail IA dans l'entreprise avec des mécanismes standardisés de Trust, de sécurité, de conformité et de déploiement.
La **couche d'orchestration** d'entreprise est l'abstraction fonctionnelle qui permet de coordonner, de gouverner et d'optimiser des workflows complexes à plusieurs étapes et des processus métiers qui couvrent les agents IA, les humains, les outils d'automatisation et les systèmes déterministes. Cette couche exploite un modèle d'orchestration mixte qui permet aux agents individuels et aux systèmes de gérer de façon autonome les tâches chorégraphiées localement en utilisant des protocoles ouverts tels que MCP et A2A tout en assurant une supervision et une coordination centralisées de bout en bout de l'ensemble du processus. Pour implémenter le modèle d'orchestration fusionnée, cette couche représente les processus métiers critiques sous des formats sémantiquement riches lisibles par machine qui définissent à la fois les étapes déterministes (modélisées pendant la conception) et les étapes dynamiques (décidées par les agents à l'exécution) d'un processus métier, créant ainsi la fondation du modèle de processus pour la gouvernance et l'optimisation.
Traditionnellement, une grande partie des processus métiers pilotés par l'homme restent non documentés ou inaccessibles sous des formes lisibles par machine. Cependant, l'observabilité détaillée des activités des agents IA, y compris les données enrichies et les métadonnées sur leurs tâches et leurs actions, permet de capturer, de documenter et d'intégrer un travail dynamique, auparavant non structuré, avec des workflows linéaires déterministes pour créer des modèles de processus complets. La documentation détaillée sur les processus capture les interdépendances des tâches et les parcours d'exécution auparavant invisibles, ce qui permet à l'entreprise d'optimiser en permanence l'efficacité opérationnelle, de résoudre efficacement les blocages et de codifier systématiquement les meilleures pratiques identifiées par les agents dans des playbooks réutilisables à l'échelle de l'entreprise. Il en résulte un jumeau numérique holistique de processus individuels et, à l'échelle, de toute l'entreprise.
Par exemple, des processus complexes tels que l'exécution de stratégies commerciales complètes ou l'intégration de nouveaux employés impliquent de nombreuses étapes interdépendantes dans lesquelles la couche d'orchestration peut garantir des niveaux appropriés d'implication humaine (par exemple, traitement des exceptions), une autonomie limitée pour les agents IA et imposer la conformité. Tout au long de ces processus, la couche d'orchestration descendante ajoute de la prévisibilité et de la gouvernance, suit et évalue en permanence les indicateurs de performance clés (KPI), garantit l'intégrité transactionnelle des workflows et de la logique de restauration, et maintient la visibilité sur chaque étape du workflow pour garantir l'alignement avec les objectifs métiers globaux. Pour implémenter cette fonctionnalité, cette couche consomme des stratégies, des règles et des garde-fous de la couche de sécurité et de gouvernance (via policy-as-code) et des objectifs métiers et des indicateurs de performance clés stockés dans la couche sémantique. Compte tenu de la nature autonome et rapide des interactions pilotées par l’IA, le seul fait de s’appuyer sur une chorégraphie décentralisée risque d’entraîner un désalignement stratégique ou des infractions à la conformité, en particulier dans les workflows longs et à plusieurs étapes. L'approche d'orchestration mixte atténue ces risques en incorporant des règles métiers à l'échelle de l'entreprise, des contrôles de conformité et l'application des politiques directement dans des workflows complexes, et intègre la supervision humaine à des moments critiques.
Chacune de ces 11 couches contribue à une fonctionnalité spécifique pour déployer les agents IA à grande échelle de façon sécurisée, fiable et efficace, afin d'exploiter tout le potentiel de l'IA agentique pour transformer le travail dans une entreprise. La section ci-dessous présente la fonction de la couche, les changements inédits dus à la montée en puissance des agents IA et ses capacités technologiques clés.
### Couche Experience
**Fonction :** La Couche d'expérience sert d'interface principale pour les utilisateurs humains. Elle permet l'interaction multimodale en capturant les entrées (texte, voix, visuel) et en fournissant des réponses contextuelles pertinentes sur plusieurs appareils. Il transmet de façon transparente les intentions des utilisateurs à la Couche Agentic pour action, tout en fournissant l'interface utilisateur dynamique et des visualisations qui facilitent les escalades humaines et les approbations dans les workflows des agents.
**Ce qui est différent par rapport à aujourd'hui :** L'IA va augmenter les interfaces basées sur l'interface graphique traditionnelles avec le traitement en langage naturel, la sensibilisation contextuelle et l'aide proactive à la décision. Les agents IA seront en mesure d’initier proactivement des interactions, en fournissant des recommandations personnalisées et en temps réel à travers tous les canaux et toutes les modalités.
**Principales capacités technologiques :**
- **IA conversationnelle et assistants numériques :** Activez l'UX par défaut pour offrir une assistance IA afin de prendre en charge les utilisateurs humains.
- **Interface utilisateur Attribution et transparence :** Rendre les réponses explicites dans l'interface utilisateur, par exemple afficher les citations, les sources des fichiers/systèmes et l'approche/la justification des décisions.
- **Service de notification proactive et ambiante :** Permet aux agents d'envoyer proactivement des connaissances ou des alertes aux utilisateurs sur le canal et le facteur de forme les plus appropriés, en fonction du contexte actuel de l'utilisateur.
- **Expériences Omnichannel :** Fournit une expérience transparente, cohérente et unifiée à travers tous les canaux avec la continuité du parcours, où les conversations et les tâches suivent la personne au lieu de l'application.
- **Capacités multimodales :** Permet aux humains d'interagir avec les agents et les applications par texte, voix, image, toucher, vidéo et AR/VR afin de permettre aux agents de comprendre et de présenter des informations dans la modalité la plus efficace.
- **Personnalisation sensible au contexte et interface utilisateur dynamique :** Active les expériences utilisateur en temps réel contextuelles (temps, localisation, actions utilisateur) pour activer la personnalisation, y compris la génération d'interface utilisateur sur le champ.
### Couche agentique
**Fonction :** La couche Agentic agit en tant qu'environnement d'exécution par défaut pour travailler dans l'entreprise où les agents IA décomposent les tâches de la couche d'expérience et exécutent les tâches en assemblant dynamiquement des workflows à l'aide des outils de la couche applications et services d'application et de la couche de données. L'état de configuration des agents IA est stocké et géré dans cette couche. Les agents sont instanciés pour des tâches spécifiques et les instances d'agent spécifiques sont ensuite décommissionnées. Cette implémentation permet aux agents d'être toujours invoqués à partir du dernier état de configuration basé sur des optimisations hors ligne (en utilisant les fonctionnalités des couches IA/ML, observabilité et orchestration). Cette couche est responsable de la gestion complète du cycle de vie, de la coordination et de la gouvernance des agents IA.
**Ce qui est différent par rapport à aujourd'hui :** Cette couche va émerger la série disparate actuelle de pilotes et de déploiements agents limités. Bien qu'il existe des robots basés sur des règles, il existe peu de logiciels adaptatifs, non déterministes et orientés vers des objectifs déployés à grande échelle.
**Principales capacités technologiques :**
- **Environnement d'exécution de l'agent :** Gère le cycle de vie, l'exécution et l'allocation de ressources pour les agents IA.
- **Suite de gestion du cycle de vie des agents :** Inclut des infrastructures de développement, des outils de développement et de test, et des systèmes de gestion pour les activités des agents et le contrôle des versions.
- **Moteur de raisonnement de l'agent :** Un cadre cognitif permettant aux agents de décomposer des objectifs, de planifier et de décider des outils à utiliser pour résoudre des problèmes complexes.
- **Magasin de mémoire et de contexte de l'agent :** Permet aux instances d'agent de rappeler et de gérer le contexte des interactions précédentes, afin de garantir la cohérence et la personnalisation.
- **Protocoles d'interopérabilité des agents :** Interfaces standardisées pour la communication d'agent à agent (A2A) et pour l'interface des agents avec des systèmes externes (par exemple via le protocole Model Context Protocol).
- **Registre d'outils :** Un ensemble organisé d'outils pris en charge en interne et en externe que les agents peuvent invoquer pour réaliser une tâche particulière.
- **Registre des agents :** Un écosystème organisé de solutions et d'agents IA prédéfinis qui prend en charge la découverte et la correspondance des capacités.
- **Application de la politique de l'agent distribué :** Permet la gouvernance à l'échelle de l'entreprise en permettant aux agents de vérifier eux-mêmes la conformité avant de prendre des mesures.
- **Cadre d'auto-réflexion et d'adaptation des agents :** Fournit un mécanisme permettant à un agent d'analyser ses propres performances et, avec l'approbation humaine, de déclencher des améliorations ou de suggérer des modifications à lui-même.
### Couche IA/ML
**Fonction :** Cette couche fonctionne comme une plate-forme d'intelligence centralisée, offrant des modèles d'IA sous forme d'ensemble de services partagés à consommer par la couche Agentic (et les applications) pour alimenter ses capacités de raisonnement et de prise de décision avec des infrastructures de sécurité et de surveillance intégrées.
**Ce qui est différent par rapport à aujourd'hui :** Traditionnellement, les modèles IA étaient incorporés à des applications spécifiques. Dans l'architecture informatique d'Agentic Enterprise, la couche IA/ML sera un ensemble de services centralisés de première classe qui propulse de nombreuses applications et agents, prenant en charge tout le cycle de vie du modèle, depuis le développement jusqu'au service en temps réel à grande échelle.
**Principales capacités technologiques :**
- **Modèles de base prédéfinis :** Modèles ML volumineux entraînés sur un large spectre de données, capables d'effectuer une grande variété de tâches générales.
- **Génération augmentée par récupération (RAG) :** Un pipeline centré sur l’IA qui ancre les modèles de base dans des données spécifiques à l’entreprise pour améliorer la précision et réduire les hallucinations.
- **AI Trust, Safety, & Governance Hub:** Une série d'outils intégrés au cycle de vie du modèle pour appliquer les principes d'IA responsable tels que la détection des biais, l'explicabilité et la surveillance de la sécurité.
- **Passerelle du modèle :** Un moteur d'acheminement qui agit en tant que point d'entrée unique pour toutes les requêtes d'inférence de modèle, en gérant les appels à divers modèles internes et externes afin d'optimiser les coûts, les performances et la conformité.
- **Système de développement de modèle :** Un environnement de développement intégré pour les scientifiques des données avec des outils de prétraitement des données, d'entraînement au modèle et d'expérimentation.
- **MLOps & Lifecycle Automation Pipeline:** Le moteur CI/CD pour l'apprentissage machine, qui automatise le cycle de vie complet des modèles, depuis l'entraînement jusqu'au déploiement et au retrait.
- **Exécution de service et d'inférence du modèle :** Un environnement évolutif et à faible latence pour déployer des modèles entraînés en tant que points de terminaison d'API sécurisés pour la consommation en temps réel.
- **Registre de modèle et d'actif :** Un référentiel centralisé et contrôlé par version pour tous les actifs IA/ML, y compris les modèles, les jeux de données et le code source, qui garantit la reproductibilité et l'auditabilité.
- **Génération et gestion de données synthétiques :** Outil permettant de générer et de gérer des données synthétiques qui conservent les propriétés statistiques des données réelles sans exposer d'informations confidentielles.
### Couche d'orchestration Enterprise
**Fonction :** La couche d'orchestration Enterprise est le plan de contrôle du travail de bout en bout dans une entreprise agentique. Il garantit que les workflows et les interactions des agents respectent les objectifs de l'entreprise et les politiques de gouvernance. Il consomme la télémétrie d'observabilité d'autres couches pour élaborer des modèles de processus métier complets, permettant l'optimisation par rapport aux indicateurs de performance clés tirés de la couche sémantique. Cette couche fournit le contexte partagé et la mémoire à long terme à chaque nouvelle instance d'un agent IA pour les workflows critiques.
**Ce qui est différent par rapport à aujourd'hui :** Cette couche offre une visibilité unifiée sur les processus métiers en créant des modèles lisibles par la machine qui capturent à la fois des étapes structurées et déterministes, et le travail non structuré et dynamique effectué par les humains et les agents. Il va au-delà des modèles actuels de collaboration et de gouvernance centrés sur l'humain en encodant par programmation des objectifs métiers et des règles de conformité en tant que contraintes dans les workflows des agents pour régir leur force de travail.
**Principales capacités technologiques :**
- **Moteur d'exécution de workflow hybride :** L'exécution principale qui exécute le « modèle d'orchestration mixte », fournissant une supervision centralisée tout en permettant la chorégraphie des agents locaux.
- **Gouvernance des processus et moteur de contraintes :** Un service de gouvernance en temps réel qui consomme et applique des règles métiers déclaratives, des politiques et des contraintes à tous les processus en vol.
- **Gestion de la mémoire partagée et du contexte :** Une couche mémoire partagée accessible à tous les acteurs d'un workflow pour maintenir la continuité et la cohérence à travers plusieurs étapes.
- **Process Modeling Studio :** Un environnement de conception permettant de créer et de gérer des modèles de processus lisibles par la machine et riches en sémantique, qui définissent des étapes déterministes et dynamiques orientées vers des objectifs.
- **Optimisation des processus et simulation :** Une capacité qui construit des simulations numériques de processus métiers pour l'analyse avancée, les simulations what-if et l'optimisation prédictive.
- **Découverte des processus et surveillance de l'état de santé :** Ingère des modèles de processus et des données en temps réel pour générer des rapports sur les métriques métiers d'intégrité des processus.
- **Modélisation numérique des processus jumelés :** Un miroir en temps réel des workflows live pour tester, simuler des modifications et optimiser sans impacter la production.
### Couche Application et Services d'application
**Fonction :** Cette couche expose les fonctionnalités d'application métier existantes en tant qu'outils et services composables et modulaires que les agents peuvent utiliser. Il sert également d'exécution de présentation pour incorporer des capacités agentiques à l'expérience utilisateur. Les applications continuent d'être le système d'enregistrement, mais sont repensées pour être des capacités « headless » pour les agents.
**Ce qui est différent par rapport à aujourd'hui :** Les applications vont évoluer des interfaces utilisateur monolithiques vers des « services back-end » que les agents peuvent appeler dynamiquement via des API et des événements. Cette couche sera intégrée nativement aux agents et modèles IA, et la prolifération des grands modèles de langage à usage unique de génération de code entraînera une augmentation du nombre de micro-applications personnalisées élaborées par des agents.
**Principales capacités technologiques :**
- **Services d'application modulaires :** Logique métier décomposée à partir d'applications traditionnelles, publiée sous forme d'actions lisibles par machine que les agents peuvent appeler.
- **Agent Embedding SDKs :** Boîtes à outils et bibliothèques qui permettent aux développeurs d'incorporer en toute sécurité des agents directement dans des interfaces utilisateur d'application.
- **Services de génération d'interface utilisateur dynamique :** Les services qui permettent à un agent IA de générer ou de modifier des composants d'interface utilisateur en temps réel en fonction du contexte de l'utilisateur.
- **Infrastructures d'interface utilisateur natives de l'IA :** Infrastructures frontales conçues avec la prise en charge intégrée pour gérer les interfaces utilisateur pilotées par l'IA, telles que la gestion des données probabilistes et les réponses de texte en continu.
- **Systèmes d'engagement perfusés par l'agent :** Applications de productivité et de collaboration d'entreprise qui intègrent les capacités des agents IA via des composants visuels.
- **Développement d'applications low-code / no-code avancé par l'IA :** Outils qui permettent aux utilisateurs et aux agents de créer des applications et des services personnalisés en langage naturel et en invites.
- **Garde-fous de l'application pour l'utilisation de l'agent :** Contrôles côté application pour l'utilisation des agents, tels que la limitation de taux, les autorisations étendues et la télémétrie.
### Couche sémantique
**Fonction :** La couche sémantique offre une compréhension unifiée des données et Knowledge dans l'entreprise, permettant aux humains et aux agents IA d'interpréter et d'agir de façon cohérente sur les informations. Il utilise des outils de représentation Knowledge tels que des ontologies et des graphiques Knowledge pour traduire les requêtes en langage naturel en requêtes de données précises et sensibles au contexte.
**Ce qui est différent par rapport à aujourd'hui :** Alors que les entreprises d'aujourd'hui ont des magasins de métadonnées disparates, l'architecture informatique de l'entreprise Agentic nécessite un Enterprise Knowledge Graph (EKG) centralisé qui associe les données entre les domaines avec des relations sémantiques explicitement définies. Cela fournit le contexte riche que les agents IA peuvent traverser pour effectuer des raisonnements complexes, créant des exigences pour un ensemble de capacités techniques afin d'alimenter les graphiques Knowledge qui couvrent plusieurs domaines fonctionnels.
**Principales capacités technologiques :**
- **Service de métadonnées :** Fournit des métadonnées descriptives, notamment le lignage des données, la propriété et les classifications.
- **Glossaire d'entreprise et gestion de la taxonomie :** Un outil permettant aux utilisateurs professionnels de définir et d'accepter des conditions métiers standard.
- **Gestion du modèle sémantique :** Un système permettant aux ingénieurs Knowledge de créer, gérer et régir des modèles sémantiques et des ontologies.
- **Enterprise Knowledge Graph (EKG):** Une instanciation à l'exécution de l'ontologie d'entreprise qui stocke et mappe les relations entre les entités commerciales.
- **Moteur Ingestion de métadonnées et harmonisation :** Un pipeline automatisé qui remplit et maintient l'Enterprise Knowledge Graph à partir de divers systèmes sources.
- **Moteur de requête sémantique**: Interprète les requêtes en langage naturel et construit des requêtes structurées basées sur l'EKG pour récupérer des données de diverses sources.
- **Moteur de raisonnement sémantique :** Analyse et dérive Knowledge implicite et relations cachées à partir de l'EKG.
### Couche de données
**Fonction :** La couche de données est la source fondamentale de vérité. Elle gère et fournit un accès sécurisé et régi à toutes les données de l'entreprise que la couche sémantique peut interpréter, la couche IA/ML à utiliser pour la formation, les applications à utiliser pour les transactions et les agents pour le raisonnement.
**Ce qui est différent par rapport à aujourd'hui :** La couche de données évolue pour être plus unifiée, en temps réel et axée sur la gouvernance, souvent centrée sur un lac de données à l'échelle du cloud. Il doit gérer un volume et une variété de données plus importants et passer du traitement par lot à la diffusion en temps réel pour prendre en charge les agents réactifs. La gouvernance et la qualité des données revêtent une importance encore plus grande pour empêcher les données pauvres de créer des sorties IA défectueuses.
**Principales capacités technologiques :**
- **VectorDB :** Une base de données spécialisée optimisée pour le stockage et l'interrogation d'incorporations vectorielles à haute dimension, critique pour le RAG.
- **Pipelines de données analytiques intelligentes :** Un service automatisé piloté par les métadonnées pour l'ingestion, la transformation et le chargement de données (ETL/ELT) dans la couche de données.
- **Enterprise Data Lakehouse :** Un référentiel central de données structurées, semi-structurées et non structurées, optimisé pour les analytiques et les charges de travail IA.
- **Fédération et recherche de données zéro copie :** Techniques d'accès, d'interrogation et de recherche de données dans plusieurs magasins sans mouvement physique des données.
- **Natural Language to SQL :** Une technique de conversion de requêtes en langage naturel en SQL.
- **Service de catalogue de données et de découverte d'entreprise :** Un inventaire centralisé et recherchable de tous les actifs de données de l'entreprise.
- **Gestion des données principales et de référence (MDM) :** Gère le « disque d'or » pour les entités commerciales critiques telles que Client et Produit.
- **Service de qualité des données adaptative :** Un service de surveillance continue qui utilise l'IA pour détecter automatiquement et corriger en temps réel les Problèmes de qualité des données.
- **Contrats de données :** Accords lisibles par ordinateur entre producteurs de données et consommateurs qui spécifient le schéma, la sémantique et les accords de niveau de service d'échange de données.
- **Magasins de données spécialisés en IA :** Bases de données conçues pour des cas d'utilisation spécifiques de l'IA, par exemple des séries temporelles ou des bases de données de graphiques.
- **Tissu de données prêt pour l'IA :** Une couche d'abstraction de données logique qui fournit une vue unifiée et virtualisée des données à travers différents systèmes physiques.
- **Traitement des données en temps réel :** Capacités de traitement et d'analyse des flux de données multimodaux en continu à des vitesses machine.
### Couche Infrastructure
**Fonction :** La couche Infrastructure sous-tend toutes les autres couches, fournissant les capacités de calcul, de stockage, de réseau et de cloud requises pour exécuter les charges de travail IA et agents à grande échelle de manière résiliente et économique.
**Ce qui est différent par rapport à aujourd'hui :** Les charges de travail IA nécessitent plus d'évolutivité et d'élasticité pour gérer la nature probabiliste des systèmes agentsiques. L'infrastructure doit prendre en charge le provisionnement rapide, le matériel spécialisé tel que les GPU et le trafic réseau à faible latence et haut débit pour la communication inter-agents.
**Principales capacités technologiques :**
- **Infrastructure en tant que code :** Provisionnement et gestion automatisés de l'infrastructure avec des pipelines de déploiement CI/CD.
- **Infrastructure IA hybride et multi-cloud :** Tire parti de l'élasticité du cloud public et de l'infrastructure spécialisée pour les charges de travail d'IA générative.
- **Computation, stockage et réseau optimisés pour l'IA :** Alloue et adapte dynamiquement les ressources d'infrastructure en fonction de la demande variable des charges de travail IA.
- **Infrastructure IA Edge :** Permet de déployer des modèles et des agents IA à la périphérie du réseau pour des cas d'utilisation avec des exigences de latence ou de confidentialité uniques.
- **Infrastructure d'autoguérison :** Utilise l'IA pour gérer la récupération du système sans saisie manuelle, ce qui garantit une haute disponibilité.
- **Calcul IA durable :** Des approches éconergétiques pour atténuer l’impact environnemental des charges de travail IA.
- **Autoscaling sensible aux coûts et au carbone :** Utilise les FinOps et les signaux de développement durable pour piloter l'échelle et le placement de la capacité.
### Couche d'intégration
**Fonction :** La couche d'intégration sert de trame de communication universelle pour tous les systèmes (hérités et nouveaux) à travers des API, des événements, des protocoles et des middlewares pour permettre aux agents de découvrir et d'interagir de façon transparente avec des services, des données et des outils.
**Ce qui est différent par rapport à aujourd'hui :** L'intégration doit évoluer pour prendre en charge les modèles de communication dynamiques, plusieurs-à-plusieurs, des agents IA, plutôt que de gérer uniquement des interactions statiques prédéterminées entre quelques systèmes connus. Il nécessite un traitement des données en temps réel, et doit permettre la découverte ponctuelle et la collaboration entre les agents.
**Principales capacités technologiques :**
- **Connexion des données opérationnelles :** Outils assistés par l'IA pour le mappage automatique de schémas, la transformation de données et la génération de workflows, notamment les capacités pilotées par l'API, pilotées par l'événement et l'ETL inverse.
- **Gestion d'API adaptative et maillage de service :** Passerelles d'API et technologie de maillage de service qui peuvent enregistrer, découvrir et régir dynamiquement des services avec l'application adaptative des politiques pour les agents.
- **Semantic Knowledge Adapters:** Un composant d'intégration qui fournit un vocabulaire et un modèle de données partagés entre les agents et les applications pour une interprétation cohérente des données.
- **Tissu d'intégration pilotée par l'événement :** Un backbone de messagerie et de streaming à haut débit et faible latence qui permet une communication asynchrone et découplée.
- **Passerelle du protocole de l'agent :** Une passerelle pour les services MCP qui permet aux agents de découvrir en toute sécurité des outils et de déclencher des actions, reliant MCP à des API et des événements internes.
- **Catalogue et place de marché des capacités composables :** Un catalogue centralisé et gouverné pour toutes les capacités de l'entreprise (API, services, compétences des agents, modèles et jeux de données) annotées avec des métadonnées sémantiques pour la composition à la demande.
### Couche Opérations informatiques et Observabilité
**Fonction :** Cette couche surveille et gère la santé et les performances opérationnelles des agents et de l'ensemble du système (principe incorporé de l'observabilité), offrant transparence et contrôle en générant des connaissances permettant l'audit, le débogage, l'explicabilité, le coût et l'optimisation des ressources de la force de travail des agents de l'entreprise.
**Ce qui est différent par rapport à aujourd'hui**: Cette couche devient d’autant plus cruciale que les agents IA risquent de créer des erreurs à la vitesse de la machine. Il doit s'étendre au-delà de la surveillance de l'infrastructure pour inclure le comportement imprévisible des agents autonomes, nécessitant de nouveaux types de télémétrie et la capacité de comprendre la justesse sémantique, pas seulement les performances techniques.
**Principales capacités technologiques :**
- **Plate-forme de surveillance et d'observabilité en temps réel :** Recueille en permanence des journaux, des métriques et des traces dans tout l'environnement informatique, avec des extensions pour les métriques ML et le comportement des agents.
- **Gestion des coûts FinOps & Cloud :** Responsable du suivi, de l'analyse et de l'optimisation des coûts d'infrastructure associés à l'IA et aux charges de travail des agents.
- **Surveillance spécifique aux agents et aux ML :** Consigne chaque étape de l'exécution d'un agent dans un journal d'audit immuable et profile en permanence les comportements des agents afin de détecter les écarts par rapport aux normes établies.
- **AIOps, Gestion des incidents et des changements :** Utilise l'IA/ML pour prédire les problèmes informatiques potentiels, identifier les causes profondes et créer des workflows de correction.
- **Boucle de rétroaction d'apprentissage fermée :** Intègre la télémétrie d'observabilité des agents dans les pipelines MLOps, ce qui permet un réentraînement automatique du modèle ou un ajustement rapide.
- **Moteur d'observabilité sémantique :** Intègre l'observabilité à la couche sémantique pour la contextualisation afin de permettre la détection d'anomalies sémantiques dans le comportement des agents.
### Couche Sécurité et gouvernance
**But :** Cette couche incorpore Trust et sécurité dans toute l'architecture en protégeant les actifs de l'entreprise contre les menaces, en gérant les risques et en garantissant la conformité aux exigences réglementaires. Il comprend la gestion de l'identité, la détection des menaces, la GRC et des mesures de sécurité spécifiques à l'IA.
**Ce qui est différent par rapport à aujourd'hui :** La couche de sécurité doit évoluer pour répondre aux nouvelles surfaces d'attaque présentées par les modèles et les agents IA, telles que l'injection rapide et l'empoisonnement du modèle. La gestion de l'identité et de l'accès doit passer de contrôles statiques basés sur le rôle à des autorisations dynamiques basées sur l'intention, accordées juste à temps et révoquées immédiatement après leur utilisation.
**Principales capacités technologiques :**
- **Sécurité des entrées/sorties LLM et garde-fous :** Des garde-fous d'entreprise appliqués à l'invite et à l'heure de réponse pour bloquer les contenus dangereux, les fuites d'informations d'identification personnelle et les jailbreaks.
- **Architecture Zero Trust avec vérification IA :** Authentification continue améliorée par l'analyse comportementale basée sur l'IA, avec un accès précis et juste à temps pour les agents en fonction de leur tâche spécifique.
- **Infrastructure de sécurité des agents :** Modèles d'autorisation précis, surveillance des comportements nocifs et mécanismes de confinement pour interrompre en toute sécurité les activités des agents.
- **Sécurité du modèle IA :** Une stratégie de défense en profondeur avec des contrôles à chaque étape du cycle de vie du modèle pour protéger contre l'empoisonnement, l'extraction et les attaques adverses.
- **IA de protection de la vie privée :** Techniques telles que l'apprentissage fédéré et la confidentialité différentielle pour protéger les données confidentielles.
- **Gendarmerie royale du Canada :** Utilisation d'agents IA pour surveiller en permanence la conformité de l'architecture TI avec les contrôles.
- **Moteur de politique en tant que code :** Une source de vérité unique pour définir des règles métiers et des contraintes de conformité sous un format déclaratif et lisible par machine afin de définir des garde-fous pour le comportement des agents.
- **Équipe rouge continue :** Tests contradictoires automatisés et continus des modèles et des agents d’IA afin d’identifier les vulnérabilités avant que les assaillants ne les exploitent.
## Une feuille de route architecturale de référence pour l'entreprise Agentic
Pour se transformer en Agentic Enterprise, il faut suivre un parcours en plusieurs étapes en jetant les bases technologiques tout en créant une valeur métier tangible (voir la figure 3 ci-dessous). Bien que la feuille de route précise dépende de la stratégie, de la culture, du modèle de gouvernance de l’IA et du point de départ de l’architecture TI de l’entreprise, la plupart des organisations doivent adopter une approche progressive en tant qu’agents puissants de la poursuite des investissements TI avec une portée, une complexité et une création de valeur croissantes. Le [modèle de maturité](https://www.salesforce.com/news/stories/agentic-maturity-model/) agentique de Salesforce offre un cadre utile de niveaux de maturité permettant aux entreprises d'élaborer une stratégie de transformation. Il montre comment les capacités des agents peuvent évoluer depuis la recherche d'informations de base (niveau 1) jusqu'à l'orchestration de workflows multidomaines (niveaux 2 et 3) et multiagents (niveau 4). Pour réussir à franchir ces étapes, l'architecture TI doit évoluer de manière concertée, avec des investissements ciblés dans différentes couches de l'architecture à chaque phase afin de répondre aux besoins des déploiements d'agents IA plus complexes et à plus forte valeur ajoutée. Pour chaque niveau de maturité, les capacités technologiques spécifiques requises dans les 11 couches architecturales sont identifiées avec une justification de l'investissement.
**Niveau de maturité 1 : Agents** de récupération d'informations
**Objectif commercial et valeur : Augmenter la productivité des travailleurs humains en fournissant une interface conversationnelle de confiance pour interroger Knowledge Enterprise.** La valeur première est d'augmenter les capacités humaines, pas de les remplacer. Ces agents aident les humains en récupérant des informations et en recommandant des actions.
**Concentration architecturale :** L'accent est mis sur la mise en place d'une fondation de données sûre et fiable et sur les composants IA de base nécessaires à la récupération d'informations. La gouvernance et l'observabilité sont essentielles dès le premier jour pour renforcer la Trust des utilisateurs et contrôler les coûts.
**Investissements technologiques clés (figure 4) :**
À ce stade, les TI devraient se concentrer sur la création d'un pipeline de données à agent fiable et d'autres capacités de base. Les technologies de la **couche de données**, telles que le **VectorDB**, sont essentielles pour activer les techniques de génération augmentée de récupération (RAG) qui propulsent les agents de récupération d'informations. Il s ' accompagne d ' une **couche IA/ML** centralisée qui comprend une **passerelle modèle** permettant d ' accéder en toute sécurité et à un coût contrôlé aux modèles de base et une **plateforme IA Trust, Safety & Governance** permettant de surveiller les produits dangereux et d ' en garantir la conformité. La **gestion des données** et **les glossaires métiers** de la **Couche** **sémantique** sont essentiels pour permettre aux agents de récupérer des informations précises. Les capacités d'exécution et de cycle de vie des agents sont requises pour garantir que les agents élaborés à cette étape peuvent être modifiés et étendus pour de futurs cas d'utilisation. Pour générer de la valeur et renforcer la confiance des utilisateurs, la **couche d'expérience** doit inclure une **interface utilisateur Attribution et transparence**, qui rend les réponses des agents explicables en montrant des citations et les sources de ses informations. Les investissements fondamentaux en matière d ' observabilité et de sécurité (par exemple **zero** **Trust**) doivent commencer à être mis en œuvre pour préparer les futurs déploiements d ' agents.
**Niveau de maturité 2 : Orchestration simple, agents** de domaine unique
**Objectif commercial et valeur : Automatisez les tâches courantes et orchestrez les workflows peu complexes dans un seul domaine métier.** Cela améliore l'efficacité opérationnelle et réduit le travail manuel, ce qui permet aux travailleurs humains de se concentrer sur des activités à plus forte valeur.
**Concentration architecturale :** Le changement architectural clé est la récupération de données en lecture seule vers l'exécution d'actions. Cela nécessite d'entamer un long parcours pour modulariser les fonctionnalités applicatives (souvent exposées sous forme d'API) auxquelles les agents ont accès, de mettre en œuvre une sécurité robuste pour les actions des agents, et d'élaborer des fonctionnalités de développement sémantique et IA pour renforcer l'intelligence des agents IA.
**Investissements technologiques clés (figure 5) :**
Les investissements sont axés thématiquement sur la capacité des agents IA à agir avec une gouvernance appropriée en place. La **couche Applications et services** d'application subit un changement critique, car la logique métier monolithique est décomposée en **services d'application** (API) modulaires que les agents peuvent appeler. Ils sont protégés par des **garde-fous d'application** pour empêcher les agents de submerger les systèmes, avec des intégrations dans les outils d'observabilité. Pour piloter ces agents, il faut investir dans le raisonnement des agents, les protocoles d'outils (tels que MCP) et **les registres**. Cela introduit de nouveaux risques, rendant un **infrastructure de sécurité des agents et un modèle IA dédiés et des capacités de surveillance des agents** essentielles pour la gouvernance et la sécurité. Enfin, les entreprises peuvent commencer à adapter leurs capacités IA/ML pour des modèles personnalisés afin de piloter ces agents qui s'attaquent à des tâches spécifiques au domaine.
**Niveau de maturité 3 : Agents d'orchestration** multidomaines
**Objectif commercial et valeur :** **Automatisez des processus métiers complexes de bout en bout qui dépassent les frontières organisationnelles et fonctionnelles** (tels que « devis-encaissement », « piste à commande »). La valeur réside dans la suppression des silos, l'accélération des temps de cycle de processus et l'optimisation de chaînes de valeur complètes au sein de l'entreprise. Des changements d’étape plus importants dans la productivité des travailleurs humains sont possibles à mesure que les barrières organisationnelles commencent à tomber et que les humains commencent à se concentrer davantage sur la supervision des agents IA.
**Concentration architecturale :** L'architecture doit désormais prendre en charge des questions techniques transversales. Une compréhension sémantique partagée dans l'entreprise, un moteur d'orchestration centralisé pour la gouvernance et un tissu d'intégration découplé et piloté par les événements deviennent les facilitateurs critiques.
**Investissements technologiques clés (figure 6) :**
Les investissements technologiques sont axés sur l'orchestration de processus à l'échelle de l'entreprise à travers les humains, les agents et les systèmes déterministes. La **couche d'orchestration** devient un centre d'investissement, nécessitant un **Moteur d'exécution** de workflow hybride pour coordonner les activités, et un **Moteur de gouvernance et de contraintes** des processus pour appliquer des règles métiers et des politiques de conformité sur les processus en vol, car les agents travaillent dans différents domaines, souvent avec des politiques et des définitions sémantiques différentes. Cette coordination interdomaines n ' est possible qu ' avec une **couche sémantique** mature dotée d ' un **Enterprise Knowledge Graph (EKG)**, qui crée une compréhension commune des relations entre les entités commerciales dans les différents domaines. La **couche d'intégration** doit évoluer pour inclure un **tissu d'intégration** piloté par l'événement, qui utilise une colonne vertébrale en continu pour découpler les systèmes et permettre la communication résiliente et asynchrone typique des processus d'entreprise à long terme. Compte tenu de la valeur plus élevée de ces workflows et des risques associés, des investissements supplémentaires dans la sécurité et la surveillance deviennent essentiels (par exemple **AIOps, policy-as-code**). Enfin, d’autres investissements doivent être réalisés dans la couche Applications et services (par exemple, LCNC **activée par l’IA, expériences utilisateur plus dynamiques et multimodales**) à mesure que les utilisateurs humains commencent à surveiller et à collaborer avec des agents IA plus compétents.
Niveau **de maturité 4 : Orchestration** multi-agents et multi-domaines
**Objectif commercial et valeur : Reconcevez et optimisez les opérations commerciales dans tous les domaines afin de favoriser les changements d'étapes dans la productivité et l'efficacité.** Cette étape progresse vers la création d'une simulation numérique globale (jumeau numérique) de l'entreprise pour l'amélioration continue et la planification stratégique à travers les principaux processus métiers et workflows.
**Concentration architecturale :** La dernière étape vise à favoriser une collaboration dynamique et émergente entre les agents. Cela nécessite des protocoles de communication d'agent à agent (A2A) avancés, des capacités d'auto-apprentissage des agents, un investissement supplémentaire dans la maturation des couches Orchestration, Données et Sémantique, et une infrastructure entièrement dynamique et auto-guérison pour répondre aux besoins croissants des charges de travail IA dynamiques à mesure que les agents sont déployés dans l'ensemble de l'entreprise.
**Investissements technologiques clés (figure 7) :**
Les investissements thématiques visent à créer un système autonome et auto-amélioré. Dans la **couche Agentic**, une **infrastructure d'auto-réflexion et d'adaptation** de l'agent fournit le mécanisme permettant à un agent d'analyser ses propres journaux de performance et de déclencher des améliorations. Cet apprentissage est pris en charge par la **couche Opérations TI et Observabilité**, qui implémente une **boucle de rétroaction** d'apprentissage fermée afin de renvoyer automatiquement les données d'observabilité dans les pipelines MLOps pour le réentraînement du modèle, qui peut également exploiter la génération de données synthétiques pour optimiser davantage les performances du modèle. Avec le déploiement de réseaux d'agents à travers les services et les efforts continus de modularisation des applications, d'autres investissements dans la sécurité et, surtout, un **catalogue de capacités composable** deviennent nécessaires pour permettre aux agents de composer dynamiquement des capacités afin de résoudre des tâches plus abstraites et plus importantes. Ces processus sont tous orchestrés et optimisés via une nouvelle **capacité Digital Twin Process Modeling** qui utilise des données en temps réel pour créer des simulations d'analyse « what-if » et d'optimisation prédictive, permettant à l'entreprise de tester et de déployer en toute sécurité de nouveaux déploiements agents.
**Conclusion**
La feuille de route vers une Entreprise Agentique traverse une évolution architecturale TI. Les architectes d'entreprise seront les moteurs cruciaux de cette transformation, car ils guideront les décisions d'investissement critiques, avec d'autres partenaires de l'entreprise et de l'informatique, nécessaires à l'organisation pour tirer parti des nouvelles capacités commerciales de l'entreprise Agentic.
## Introduction
Dans le développement logiciel traditionnel, le cycle de vie du développement logiciel (SDLC) fournit une approche structurée et progressive pour élaborer des applications. Il établit la qualité, réduit les risques et fournit une feuille de route claire depuis l'idée jusqu'à la publication. Le cycle de vie de développement de l'agent (ADLC) est une méthodologie similaire qui est spécifiquement adaptée pour répondre aux complexités uniques de l'élaboration d'agents autonomes.
Les agents ne sont pas des applications passives, mais des systèmes qui raisonnent, agissent et apprennent dans des environnements d'exécution dynamiques. Leur comportement non déterministe rend l'AQ traditionnel insuffisant. Le cycle de vie de développement des agents (ADLC), défendu par des plates-formes comme Agentforce, répond à ce problème à travers cinq phases: Idéation et conception, Développement (la « boucle interne »), Test et validation, Déploiement, et Surveillance et réglage continus (la « boucle externe »).
Ce document sert de guide complet pour les développeurs et les architectes d'entreprise qui connaissent déjà les subtilités du cycle de vie de développement logiciel (SDLC) et qui cherchent à élargir leur expertise aux systèmes basés sur l'agent. Notre objectif principal est de faciliter une compréhension rapide du cycle de vie de développement des agents (ADLC) en mettant en évidence ses principales distinctions par rapport aux méthodologies SDLC traditionnelles et en fournissant un cadre structuré pour conceptualiser l'ensemble du processus de construction, de déploiement et de gestion des agents intelligents.
Le document est organisé en trois chapitres distincts, chacun conçu pour construire progressivement votre Knowledge et vos compétences pratiques:
- **Chapitre 1: L'infrastructure ADLC.** Ce chapitre présente le cycle de vie de développement des agents (ADLC), détaillant sa divergence par rapport au SDLC en raison des défis uniques du développement d'agents autonomes. Il établit un cadre pour concevoir, développer, tester et déployer des agents.
- **Chapitre 2: Agentforce Platform.** Ce chapitre explore Agentforce, une plate-forme unifiée qui rationalise et accélère le cycle de vie complet du développement des agents. Agentforce offre des outils de conception d'agents, de traitement des données, d'entraînement de modèles, de déploiement et de surveillance continue, ce qui simplifie les tâches complexes et améliore l'efficacité.
- **Chapitre 3: Implémentation pro-code.** Ce guide utilise les outils pro-code d'Agentforce pour fournir des instructions pratiques, pas à pas et des exemples concrets pour le développement des agents. Il couvre l'ensemble du cycle de vie de développement des agents, depuis le prototypage et l'ingénierie des fonctionnalités jusqu'au déploiement du modèle, en passant par l'ajustement des performances et la maintenance, et permet aux développeurs d'acquérir les compétences requises pour élaborer des agents prêts à travailler en production.
Ce document a pour but de vous doter des Knowledge théoriques et pratiques des outils pro-code d'Agentforce. Vous apprendrez à élaborer, déployer et surveiller les agents de façon efficace, sûre et fiable, en acquérant une compréhension complète de l'ADLC et en optimisant le potentiel d'Agentforce dans le développement intelligent des agents.
## Chapitre 1 : Introduction du cycle de vie de développement des agents
La nature non déterministe des agents IA nécessite un cadre de développement spécialisé. Ce chapitre décrit ce cadre en introduisant le cycle de vie de développement des agents (ADLC). Ce chapitre présente un aperçu complet des cinq phases principales de l'ADLC, depuis l'idée et la conception initiales jusqu'à la surveillance et le réglage continus. Ce chapitre établit les Knowledge fondamentales requises pour construire des agents robustes et fiables.
Cette section mappe les concepts du SDLC avec les cinq phases du ADLC.
#### Phase 1 : Idéation et design
Il s'agit de la phase fondamentale de définition de l'objectif stratégique et des limites opérationnelles d'un agent. Une phase de conception bien structurée est l'étape la plus critique pour réussir, car elle traduit un besoin métier en avant-projet technique. Le processus de conception garantit que l'agent est non seulement opérationnel, mais aussi responsable et conforme aux attentes des utilisateurs. C'est là que le "quoi" et le "pourquoi" sont établis avant l'écriture d'un code.
1. **Définition des objectifs et des capacités des agents**: Tout d'abord, vous devez clairement articuler l'objectif principal de l'agent et les tâches spécifiques et mesurables qu'il accomplira. Il s'agit de définir son rôle (p. ex. « adjoint au service à la clientèle »), ses fonctions principales (p. ex. « prendre des rendez-vous », « répondre à des questions sur les produits ») et les métriques de réussite de chacun.
2. **Établir une personnalité et des garde-fous éthiques**: Cette étape consiste à concevoir la personnalité de l'agent et à définir ses limites éthiques pour garantir sa fiabilité et sa sécurité. Il établit le ton de l'agent (p. ex. « formel », « amical ») et implémente des règles strictes pour empêcher les réponses préjudiciables, biaisées ou inappropriées.
3. **Contexte et compréhension de la carte**: Vous devez déterminer les informations que l'agent doit comprendre et retenir pour être efficace. Il s'agit notamment de définir la portée de sa base Knowledge et de sa mémoire conversationnelle, ce qui lui permet d'avoir des conversations cohérentes, à plusieurs tours de rôle.
4. **Identifier les outils et les intégrations système**: Cela implique d'inventorier les systèmes externes, les API et les sources de données avec lesquels l'agent doit se connecter pour exécuter les tâches. Chaque outil (par exemple, une API de réservation, une base de données de clients) est identifié et sa fonction est mappée avec une capacité d'agent spécifique.
5. **Plan d'escalade humaine**: Il est essentiel de définir les conditions dans lesquelles un agent passe à l'humain. Cela implique d'examiner les points d'échec potentiels et les « impasses » conversationnelles afin de déterminer quand un agent doit escalader vers un opérateur humain. La conception devrait décrire comment ce transfert sera effectué pour s'assurer qu'un contexte suffisant est transféré, afin qu'il puisse être rapidement consommé pour garantir une expérience client transparente.
#### Phase 2 : Développement
Il s'agit de la phase de construction pratique où le plan de conception est transformé en agent fonctionnel. Les développeurs élaborent l'agent, le connectent à ses outils et lui fournissent les données dont il a besoin pour remplir ses fonctions. Cette « boucle interne » itérative de construction et d'affinage est l'endroit où l'agent prend véritablement vie.
1. **Configuration de la logique et de la prise de décision de l'agent**: Cette étape consiste à façonner le raisonnement de l'agent en connectant son cadre décisionnel au contexte, aux outils et aux sources de données. Le rôle du développeur est de définir le comportement de l'agent en créant des API ou en réutilisant des API existantes, en définissant des garde-fous opérationnels et en spécifiant comment l'agent sélectionne et utilise les outils disponibles pour réaliser des tâches complexes à plusieurs étapes.
2. **Invites de l'ingénieur et ajustement des modèles**: La personne, les instructions et les contraintes de l'agent sont codifiées par une ingénierie rapide méticuleuse. Ce processus consiste à élaborer l'invite principale qui guide le Grand modèle de langage (LLM) et, pour des cas d'utilisation plus avancés, à ajuster le modèle sur des données spécifiques au domaine afin d'améliorer ses performances.
3. **Intégration et sécurisation des outils IA**: Les fonctions et les API identifiées pendant la phase de conception sont connectées à l'agent. En utilisant un kit de développement, les développeurs enveloppent les fonctions existantes ou en créent de nouvelles, ce qui les rend accessibles en toute sécurité par l'agent et garantit qu'ils disposent de l'authentification appropriée et du traitement des erreurs.
4. **Élaboration de pipelines de données et RAG**: Pour permettre à l'agent d'acquérir des Knowledge externes, les développeurs élaborent les pipelines de données pour la génération augmentée par récupération (RAG). Cela implique de connecter et d'indexer des données à partir de sources telles que des magasins de vecteurs, des bases de données relationnelles, des bases de données de graphiques ou des documents internes, afin de rendre ces informations accessibles à l'agent pour fournir des réponses précises et sensibles au contexte.
#### Phase 3 : Test et validation
Le test des agents IA introduit un changement de paradigme par rapport à la validation déterministe des logiciels traditionnels. Bien qu'une application classique soit testée pour son exactitude (une entrée spécifique doit produire une sortie unique et attendue), la nature non déterministe d'un agent nécessite une approche plus sophistiquée. L'objectif n'est pas de valider une seule bonne réponse, mais de s'assurer que le comportement de l'agent correspond à son objectif, qu'il est robuste face à des entrées inattendues et qu'il reste fiable dans un éventail de résultats acceptables.
1. **Test unitaire**: Cette couche se concentre sur les composants déterministes non-IA de l'agent. Il implique des tests unitaires traditionnels pour vérifier que chaque outil et chaque fonction fonctionne correctement de façon isolée, garantissant une base fiable avant l'application du raisonnement complexe de l'agent.
2. **Essais de bout en bout (E2E)**: Cette étape évalue la capacité de l'agent à atteindre ses objectifs dans des scénarios réalistes, ce qui est essentiel étant donné sa nature non déterministe. Au lieu de vérifier une sortie exacte, ces tests de bout en bout vérifient que l'agent effectue les tâches avec succès et que ses performances ne se dégradent pas à mesure que des modifications sont apportées.
3. **Tests contradictoires et de robustesse**: C'est la pratique qui consiste à essayer intentionnellement de casser l'agent pour découvrir proactivement ses faiblesses. Les testeurs utilisent des requêtes ambiguës, des invites malveillantes et d'autres requêtes Edge pour exposer les vulnérabilités et s'assurer que l'agent reste résilient et en sécurité sous pression.
4. **Évaluation Human-in-the-Loop (HITL)**: Les tests automatisés ne peuvent pas mesurer des qualités nuancées telles que le ton ou le flux conversationnel. Par conséquent, cette étape dépend des commentaires humains. Les testeurs interagissent avec l'agent pour évaluer ses réponses en termes d'utilité et d'expérience utilisateur globale, en fournissant des données essentielles pour ajuster son comportement.
5. **Essais de performance et d'échelle**: Il s'agit d'une étape essentielle pour éviter les blocages de performance avant qu'ils n'impactent les utilisateurs. Ce processus simule des scénarios réalistes de pic d'utilisation pour s'assurer que les agents et les applications peuvent gérer des volumes élevés de façon fluide et prévisible. Il vérifie que la solution est non seulement correcte, mais aussi évolutive.
#### Phase 4 : Déploiement et publication
Le déploiement d'un agent IA est un processus géré qui vise à garantir que l'agent validé est celui avec lequel les utilisateurs interagissent de manière fiable et reproductible. Cela nécessite une approche structurée qui déplace l'agent depuis un actif contrôlé par la version vers un service live et surveillé.
1. **Empaquetage et contrôle de version**: La définition complète de l'agent, y compris ses invites et ses outils, est capturée sous forme de métadonnées dans un fichier et stockée dans un système de contrôle de code source tel que Git. Cela crée une source de preuve unique et un historique vérifiable de toutes les modifications.
2. **CI/CD Pipelines**: Le cheminement vers la production est automatisé pour éliminer les erreurs humaines et garantir la cohérence. Ces pipelines promeuvent automatiquement l'agent à travers des environnements de développement, de test et de production, en exécutant des tests de bout en bout à chaque étape pour agir comme une porte de qualité.
3. **Stratégies de déploiement progressif**: Pour limiter les risques, de nouvelles versions d'agent sont publiées pour une petite sélection d'utilisateurs en utilisant d'abord des stratégies telles que Canary Releases. Cela permet de surveiller les performances en temps réel avant un déploiement complet, avec la possibilité de résoudre rapidement les problèmes détectés.
4. **Activation et gouvernance**: L'étape critique du déploiement d'un agent consiste à l'activer en toute sécurité avec les autorisations appropriées et à s'assurer qu'il est connecté aux outils de surveillance. Cela permet de visualiser immédiatement la santé et les performances du nouvel agent déployé dès sa mise en ligne.
#### Phase 5 : Surveillance et réglage
Le déploiement n'est pas la fin du cycle de vie de développement de l'agent, c'est le début de sa « boucle externe » continue. Les agents sont des systèmes dynamiques qui fonctionnent dans des environnements imprévisibles et réels. Cette phase est dédiée à l'observation des performances live de l'agent, à la collecte de connaissances à partir de ses interactions, et à l'utilisation de ces données pour affiner et améliorer systématiquement son efficacité, sa sécurité et son efficience au fil du temps.
1. **Surveillance des performances en temps réel**: Il s'agit de la pratique qui consiste à suivre les métriques opérationnelles clés de l'agent lorsqu'il interagit avec les utilisateurs. Les tableaux de bord sont utilisés pour surveiller la latence, la consommation de jetons (coût) et les taux d'erreur d'API, offrant une vue d'ensemble immédiate de la santé et de l'efficacité de l'agent.
2. **Analyses: comportementales et de réussite** Il s'agit d'analyser les journaux conversationnels afin de comprendre comment l'agent s'acquitte _réellement_ de ses fonctions. Il se concentre sur le suivi des taux de réalisation des tâches, l'identification des points d'échec communs ou des « impasses » conversationnelles, et la mesure de la satisfaction des utilisateurs afin de déterminer si l'agent atteint ses objectifs. Par exemple, pour les agents de service, il peut fournir des métriques sur la fréquence et les raisons pour lesquelles un agent passe à un humain.
3. **Affinage et réglage intelligents**: Il s'agit du processus actif d'utilisation des connaissances de la surveillance pour améliorer l'agent. Cela peut aller de l'ingénierie rapide à l'optimisation des outils.
4. **Amélioration du RAG piloté par les données**: La qualité de la base Knowledge de l'agent est continuellement améliorée en fonction des requêtes réelles. La surveillance peut révéler que l'agent rencontre des difficultés avec certaines rubriques, ce qui entraîne une amélioration des sources de données ou du processus de récupération (RAG Refinement) pour améliorer la précision de ses réponses.
5. **Apprentissage continu et adaptation**: Cela implique de créer une boucle de rétroaction dans laquelle les données de production sont utilisées pour rendre l'agent plus intelligent. En étiquetant les journaux d'interaction (avec la supervision humaine ou l'étiquetage basé sur le LLM), un jeu de données organisé est élaboré, qui peut être utilisé pour ajuster le modèle sous-jacent et recommander d'autres améliorations.
## Chapitre 2 : Cycle de vie de développement d'_Agentforce_ Agent
Agentforce prend en charge chaque phase ADLC avec un outillage intégré pour la conception, le développement, le test, le déploiement, la surveillance et les analytiques, le tout dans une plate-forme unifiée unique pour élaborer et tester rapidement des agents robustes.
L'ADLC Agentforce repose sur les principes directeurs suivants:
- **Conçu pour les codes bas et pro-code**: Prise en charge du déploiement basé sur la configuration (code faible) et de l'extensibilité par programmation (code pro).
- **Assistance continue pilotée par l’IA et boucles de rétroaction**: Capture et analyse les données conversationnelles afin d'éclairer le réglage des agents pour une amélioration continue pilotée par l'IA.
- **Développement piloté par les essais à tous les niveaux**: Test rigoureux à travers toutes les étapes, validant les composants déterministes à travers les tests unitaires traditionnels, et fournissant de nouvelles approches pour tester le raisonnement des agents et le comportement non déterministe.
- **Executive and LOB Observability**: Fournir des métriques de coût, d'utilisation et de performance pour les parties prenantes opérationnelles et exécutives.
Le présent chapitre montre comment Agentforce prend en charge chaque phase de l'ADLC **sur une plate-forme unifiée unique.**
#### Phase 1 : Idéation et design
##### Idée
La phase d'idéation est l'étape fondamentale de la CLAD, où la vision initiale et les exigences des agents sont formulées. Il implique une exploration approfondie du problème, l'identification de solutions potentielles et l'esquisse des principales fonctionnalités de l'agent.
Démarrez le processus d'idéation de votre agent en définissant ses principaux attributs :
1. **But/Objectif**: Définissez clairement l'objectif principal de l'agent. Quel problème spécifique est-il conçu pour résoudre, ou quelle tâche est-il prévu d'accomplir? Qui doit servir l'agent ? Il devrait s'agir d'un énoncé concis et mesurable qui guide l'ensemble du processus de développement.
2. **Personne**: Développez une personne détaillée pour l'agent. Cela inclut la définition de son identité, de son style de communication et du rôle qu'il jouera dans l'interaction avec les utilisateurs ou d'autres systèmes. Tenez compte de son ton, de son niveau de formalité et de toutes les caractéristiques spécifiques qui le rendront efficace dans le contexte voulu.
3. **Modèle**: Identifiez et associez des schémas agentsiques et des stratégies d'implémentation pertinents. Cela implique des conceptions architecturales ou des meilleures pratiques qui peuvent informer la structure et le comportement de l'agent. «[ Schémas et implémentation des agents dans Salesforce Agentforce : A Technical Whitepaper](/docs/architect/fr-fr/fundamentals/guide/agentic-patterns)", est une ressource précieuse pour cette étape, offrant des connaissances sur la conception efficace des agents sur Salesforce Platform et Agentforce.
##### Conception
La phase de conception traduit les concepts de l'idéation en un plan détaillé pour la construction de l'agent. Cela implique de définir l'architecture, les flux utilisateur, les modèles d'interaction et les spécifications techniques de l'agent, notamment les rubriques, les outils et les garde-fous.
Pendant la phase de conception, vous allez créer un plan détaillé pour la construction de votre agent qui comprend :
- **Conception de l'agent**: Soulignez la structure interne de l'agent, y compris ses composants, ses modules et leur interaction. Il peut s'agir de définir la base de Knowledge, la configuration et la logique pour contrôler le comportement des agents, les composants de traitement en langage naturel (NLP) et les points d'intégration avec d'autres systèmes.
- **Flux utilisateur/Conception d'interaction**: Mappez le parcours utilisateur complet et les interactions de l'agent. Définissez des flux de conversation, des arbres de décision, un traitement des erreurs et des mécanismes de commentaires pour créer des expériences intuitives et efficaces.
- **Caractéristiques techniques**: Documentez les exigences techniques non fonctionnelles de l'agent, notamment les métriques de performance, les considérations relatives à l'évolutivité, les protocoles de sécurité et les spécifications d'intégration.
- **Prototypage et maquettes**: Créez des représentations visuelles ou des prototypes interactifs de l'interface et des interactions de l'agent. Cela permet de tester et de commenter rapidement, ce qui aide à affiner la conception avant le début du développement à grande échelle.
- **Données**: Lors de la détermination du type et des sources de données requis par un agent, identifiez les jeux de données, les API, les bases de données et les référentiels auxquels l'agent doit accéder. Pour Agentforce, déterminez quelles données sont fournies en tant que contexte, si elles sont structurées ou non, et si elles sont en temps réel ou par lot. La plate-forme Agentforce est construite avec une intégration profonde à Data 360, ce qui vous permet d'utiliser à la fois des données structurées et non structurées de Salesforce CRM et d'autres sources. Un contenu non structuré peut être segmenté et indexé en natif pour RAG. MuleSoft permet de se connecter à des systèmes externes.
- **Outils**: Identifiez les actions que l'agent doit exécuter. Utilisez Actions Agentforce pour exposer des outils qui atteignent des objectifs métiers. Ces actions exploitent les actifs Salesforce existants tels que les invites via le Générateur de répliques, MuleSoft, Apex, les flux et les API avec des spécifications OpenAPI. N'importe quelle action invocable peut être intégrée à Agentforce et utilisée par l'agent, ce qui rend tous les outils de développement Salesforce familiers facilement disponibles en tant qu'Actions Agentforce.
- **Données d'entrée pour les agents**: Dans SDLC traditionnel, les entrées sont spécifiées avec précision. Dans l'ADLC, les entrées sont souvent des énoncés naturels, non déterministes et de forme libre. Recueillez un corpus représentatif d'énoncés censés produire des réponses appropriées.
#### Phase 2 : Développement
La phase de développement se concentre sur la traduction de l'objet, des capacités et du périmètre opérationnel de l'agent défini déterminé à la phase Idéation et conception en un nouvel Agentforce.
Pour aider les développeurs à créer des agents, Agentforce fournit à la fois le **Générateur d'agent** et **Agentforce Developer Experience (AFDX).** Ces outils de base servent d'environnement principal pour construire et configurer l'agent.
- **Agent Builder** fournit une expérience d'interface utilisateur pour définir les fonctionnalités principales de l'agent.
- **AFDX** fournit une interface programmatique de personnalisation et d'intégration à d'autres systèmes.
Le développement et l'élaboration d'un agent impliquent les étapes suivantes qui peuvent être exécutées en utilisant le Générateur d'agent ou AFDX :
1. **Définition de la personne**: Un aspect crucial de la conception d'un agent est d'établir une personne distincte. Cela implique de configurer :
- **Description de l'agent**: Une description détaillée du rôle de l'agent, de ses objectifs et des tâches de service client spécifiques pour lesquelles il est conçu.
- **Ton**: Le style de communication de l'agent, son niveau d'empathie et toutes les consignes de marque spécifiques qu'il doit respecter.
2. **Définition de rubriques et d'actions pour les agents**: Pour rendre un agent sophistiqué et capable de gérer une gamme variée de tâches, il est essentiel de diviser ses capacités en rubriques distinctes avec les actions correspondantes.
- **Rubriques**: Chaque rubrique peut être conceptualisée comme son propre agent spécialisé avec un ensemble unique d'instructions et d'outils.
- **Architecture modulaire.** L'approche modulaire des rubriques permet une organisation et une évolutivité accrues. En définissant plusieurs rubriques, l'agent peut gérer un plus grand nombre de scénarios complexes. Par exemple, un agent peut avoir des rubriques distinctes pour « Gestion des commandes », « Foire aux questions », « Support technique » et « Demandes de facturation ».
- **Instructions de rubrique (garde-fous)**: Chaque rubrique contient des instructions spécifiques qui agissent comme des garde-fous, définissant la portée des discussions ou des actions que l'agent peut effectuer dans cette rubrique. Ces instructions empêchent l'agent de s'égarer hors sujet ou de fournir des informations non pertinentes. Ils aident également à maintenir la cohérence et la précision des réponses.
- **Actions**: Les rubriques sont également équipées d'« outils », qui représentent les actions que l'agent peut exécuter. Ces outils peuvent être :
- **Actions d'information**: Récupération de données à partir d'une base Knowledge ou d'un système externe pour répondre à une requête.
- **Actions transactionnelles**: Exécution d'actions au nom de l'utilisateur, par exemple passer une commande, mettre à jour un enregistrement client ou initier un processus de remboursement. Ces actions sont souvent intégrées à d'autres systèmes (p. ex. CRM, ERP).
#### Phase 3 : Test et validation
Lors de l'évaluation des performances et de la fiabilité des agents IA, les testeurs rencontrent souvent une série de défis qui peuvent dégrader l'expérience utilisateur. Ces problèmes vont d'une mauvaise interprétation de l'intention de l'utilisateur à l'incapacité d'exécuter correctement les tâches.
##### Scénarios d'échec courants des agents
Élaborer un agent robuste nécessite de comprendre comment et où il peut échouer. Le tableau ci-dessous classe les problèmes courants rencontrés pendant le cycle de vie de l'agent, depuis le raisonnement erroné jusqu'à la récupération Knowledge médiocre. Utilisez-le comme guide stratégique pendant le développement et comme liste de contrôle pendant les tests pour vous assurer que votre agent est non seulement opérationnel, mais aussi fiable et intuitif pour l'utilisateur. Ces scénarios d'échec devraient vous aider à définir des cas de test.
| Catégorie | Description | Exemples d'échec |
|---|---|---|
| Classification des rubriques | L'agent ne parvient pas à identifier correctement l'intention ou l'objectif de l'utilisateur. |
|
| Qualité de réponse | Échecs dans le contenu, l'exactitude et le format des réponses de l'agent. |
|
| Exécution d'action | L'agent échoue lorsqu'il tente d'exécuter une fonction ou une tâche spécifique. |
|
| Garde-fous et instructions | L'agent enfreint des règles, des contraintes ou des limites conversationnelles prédéfinies. |
|
| Récupération de Knowledge | L'agent rencontre des problèmes pour trouver et présenter des informations à partir de sa base Knowledge. |
|
| Guide structuré | L'agent peine à guider les utilisateurs à travers les processus à plusieurs étapes. |
|
| Objet lac de données/Objet modèle de données | Description |
|---|---|
| AIAgentSession | Un conteneur global qui capture les interactions contiguës avec un ou plusieurs agents IA. |
| AIAgentSessionParticipant | Une entité (humaine ou IA) qui prend part à une AIAgentSession. |
| AIAgentInteraction | Un segment dans une session. Elle commence généralement par la demande d'un utilisateur et se termine lorsque l'agent IA fournit une réponse à cette demande. |
| AIAgentInteractionStep | Une action discrète ou une opération exécutée pendant une interaction pour répondre à la demande de l'utilisateur. |
| AIAgentInteractionMessage | Une communication unique fournie par l'utilisateur ou générée par l'agent IA pendant une session. |
##### Analyse des énoncés
L'analyse des énoncés montre comment les utilisateurs Agentforce (par défaut) utilisent les agents, ce qu'ils demandent et si l'agent a pu gérer ces demandes. Ces rapports personnalisables peuvent vous aider à affiner vos rubriques et actions afin de permettre à vos agents de répondre avec plus d'efficacité et de précision.
##### Agentforce Python SDK : Surveillance avec les intégrations Data 360
L'implémentation du kit de développement Agent utilise la surveillance et les analytiques avancées avec le connecteur Python Data 360, établissant la connexion à Salesforce Data 360, interrogeant les métriques de performance des agents et créant des tableaux de bord de surveillance complets.
Le système suit les temps de réponse, les taux de réussite, la satisfaction des utilisateurs et les métriques de coût afin de fournir des connaissances actionnables pour l'optimisation des agents.
```py
# Data 360 Python Connector Integration
from salesforce_cdp_connector import SalesforceCDPConnector
# Initialize Data 360 Connector
cdp_connector = SalesforceCDPConnector(
client_id='your_client_id',
client_secret='your_client_secret',
username='your_username@example.com',
password='your_password'
)
# Query agent performance data
performance_data = cdp_connector.query("""
SELECT timestamp, response_time_ms, success_rate, user_satisfaction
FROM AgentPerformanceMetrics
WHERE agent_id = 'Coral_Cloud_Resorts_Resort_Manager'
""")
# Create monitoring dashboard
def create_monitoring_dashboard(performance_data):
fig = go.Figure()
fig.add_trace(go.Scatter(
x=performance_data['timestamp'],
y=performance_data['response_time_ms'],
mode='lines+markers'
))
return fig
```
##### Agentforce DX : Surveillance des agents
L'implémentation utilise des commandes AFDX standard avec la gestion des agents basée sur la CLI, qui informent l'agent des modifications apportées à la plate-forme et intègrent les commentaires des utilisateurs pour une amélioration continue.
```zsh
# List all agents and their status
sf agent list --target-org "production-org"
# Get detailed agent information
sf agent get \
--api-name "Resort_Manager" --target-org "production-org"
# Activate agent if needed
sf agent activate --api-name "Resort_Manager" --target-org "production-org"
# Query agent performance data
sf data query \
--query "SELECT Id, Name, Status, LastModifiedDate FROM BotDefinition WHERE DeveloperName = 'Resort_Manager'" \
--target-org "production-org"
```
```python
# AgentforceDX Dashboard Creation (Similar to Agent SDK)
import pandas as pd
import plotly.graph_objects as go
from salesforce_cdp_connector import SalesforceCDPConnector
# Initialize Data 360 Connector for AgentforceDX
cdp_connector = SalesforceCDPConnector(
client_id='your_client_id',
client_secret='your_client_secret',
username='your_username@example.com',
password='your_password'
)
# Query agent performance data from Data 360
performance_data = cdp_connector.query("""
SELECT timestamp, agent_id, response_time_ms, success_rate, user_satisfaction
FROM AgentPerformanceMetrics
WHERE agent_id = 'Resort_Manager'
AND timestamp >= CURRENT_DATE - 30
ORDER BY timestamp DESC
""")
```
Reportez-vous [ici](https://github.com/akshatasawant9699/ADLC_Whitepaper) au référentiel GitHub pour l'implémentation d'ADLC en utilisant le kit de développement Agent SDK et AFDX.
## Meilleures pratiques
La maîtrise du cycle de vie de développement des agents nécessite d'adhérer à un ensemble de principes fondamentaux qui garantissent l'efficacité, la fiabilité et l'alignement stratégique. Les lignes directrices suivantes synthétisent les principales leçons tirées de chaque phase du CLDA dans un cadre stratégique pour les architectes et les promoteurs.
**1\. Planification et idées**
Cette phase initiale est axée sur l'alignement de l'objectif de l'agent avec les objectifs métiers et sur la construction d'une base solide.
- **Priorité à l'impact commercial**: Commencez par mapper des cas d'utilisation potentiels directement avec des objectifs métiers stratégiques. Utilisez une matrice de priorisation pour évaluer leur impact potentiel et commencez par un cas d'utilisation unique et ciblé avec des indicateurs de performance clés clairs.
- **Impliquer les parties prenantes tôt**: Recueillez des connaissances sur les points douloureux et assurez l'alignement.
- **Exploiter les connaissances des données**: Un agent est aussi bon que ses données. Utilisez Data 360 pour explorer les données structurées et non structurées disponibles afin d'informer le contexte et les capacités de l'agent. Examinez les rapports et les tableaux de bord existants pour identifier les tendances actuelles qui peuvent éclairer votre sélection de cas d'utilisation.
- **Utilisation d'infrastructures pour l'idée**: Appliquez des méthodes d'idéation structurées pour réfléchir et affiner les applications potentielles, telles que la conception ou l'analyse SWOT.
**2\. Agents de construction**
Cette phase couvre les meilleures pratiques pour construire un agent performant et efficace.
- **Éviter trop de rubriques**: Limitez le nombre de rubriques afin de réduire le risque de créer des rubriques similaires ou superposées qui pourraient désorienter l'agent.
- **Concision des instructions et des invites**: Utilisez un langage simple et direct et fournissez des exemples d'énoncés pour guider efficacement l'agent.
- **Exploitation des variables et actions déterministes**: Utilisez ces outils pour guider le comportement de l'agent et optimiser ses performances pour des résultats plus prévisibles.
- **Garder les sorties d'action petites et concises**: Assurez-vous que les réponses de l'agent sont brèves et pertinentes. Les sorties plus longues utilisent plus de contexte et sont plus lentes à générer.
- **Optimisation des actions pour accélérer**: Concevez des flux et des classes Apex pour renvoyer un minimum de données requises. Essayez de réduire le nombre d'actions nécessaires pour générer une réponse en prétraitant si possible.
- **Définition d'une portée claire**: Écrivez des descriptions appropriées, des instructions et l'étendue des actions pour empêcher l'agent d'appeler RAG (Retrieval-Augmented Generation) pour des questions hors champ.
- **Utilisation de la recherche hybride avec précaution**: Utilisez la recherche hybride uniquement si elle est absolument nécessaire, car elle peut impacter négativement la latence.
**3\. Test, surveillance et réglage**
Cette phase itérative est cruciale pour affiner la précision et les performances de l'agent.
- **Établir un flux de test**: Suivez un cycle de test cohérent :
1. **Exécuter un test par lot**: Exécutez une série complète de tests.
2. **Afficher les scores/erreurs**: Analysez les métriques de performance et identifiez les échecs.
3. **Inspecter les échecs**: Examinez chaque ligne d'échec pour comprendre l'écart.
4. **Agent de mise**: à jour Apportez les ajustements nécessaires à l'agent ou à ses données d'évaluation.
- **Examen des informations de traçage de session**: Utilisez le modèle de données de trace de session et l'Explorateur d'interaction Agentforce pour effectuer une analyse des causes premières lorsque des problèmes ou des comportements inattendus sont identifiés. Ajustez votre agent en fonction des informations et continuez à itérer votre agent.
## Conclusion
Le _cycle de développement_ des agents représente une évolution critique des principes traditionnels de développement de logiciels, conçus pour l'ère des systèmes intelligents et autonomes.
- **Évolution, pas remplacement**: Le cycle de vie de développement des agents étend et améliore la Gestion du cycle de vie des applications traditionnelle sans la remplacer.
- **Les données en tant que citoyens de première classe**: Les données jouent un rôle beaucoup plus dynamique et central dans le développement des agents.
- **Outillage spécialisé et compétences**: Nécessite de nouveaux outils et un ensemble élargi de compétences spécialisées dans les sciences des données, l'ingénierie ML et le développement des agents.
- **Apprentissage continu**: Le développement des agents ajoute _l'apprentissage_ continu et _l'adaptation_ du système lui-même.
- **Impact futur**: L’IA agentique promet d’automatiser et d’optimiser davantage les opérations informatiques complexes et les workflows de développement de logiciels.
## À propos de ce livre blanc
**Enterprise Agentic Architecture and Design Patterns** structure les possibilités des architectures multi-agents, en identifiant et en mettant en évidence comment combiner des capacités nouvelles pour les agents IA afin de fournir des solutions agents fiables, répétitives, évolutives et gérables. En nous inspirant des « Design Patterns » pour la programmation orientée objet, nous exposons des modèles qui peuvent être combinés et étendus pour résoudre les nombreux défis passionnants qui, avant les technologies agentiques, se situaient hors du périmètre des systèmes métiers construits sur des technologies déterministes traditionnelles.
Après avoir discuté de la justification des architectures multi-agents, nous introduisons de nombreux schémas agentsiques, depuis les schémas simples qui exploitent le traitement en langage naturel pour déterminer l'intention de l'utilisateur, jusqu'aux schémas multi-agents qui permettent de séparer les préoccupations entre les agents, en passant par les schémas agentsiques UX qui apportent le raisonnement agentique à la présentation et à l'interaction avec les systèmes, les informations et les contenus.
## Que tirerez-vous de ce document?
Tout d'abord et avant tout, vous obtiendrez une nouvelle façon de concevoir les agents - les agents en tant que composants, les agents en tant que compositeurs, les agents en tant qu'acteurs, les agents en tant que collaborateurs, et surtout les agents dans une architecture plus large qui agissent avec intention et agissent dans leur champ de préoccupations individuel.
Vous obtiendrez les pointeurs dont vous avez besoin pour concevoir des solutions agentiques riches qui couvrent les parcours utilisateur et informent les expériences agentiques significatives, des expériences qui n'ont jamais été possibles auparavant.
Les sections initiales de ce document fournissent la justification des architectures muti-agents. Lisez-les pour mieux comprendre les défis et les opportunités que présentent les architectures multi-agents.
Voici des définitions et des descriptions de schémas agentsiques, de simples à complexes, couvrant les schémas qui prennent en charge les interactions, les schémas pour les agents spécialisés, les schémas pour les opérations en arrière-plan et les schémas à long terme. Chaque modèle inclut un diagramme des principaux composants qui réalisent le modèle, plus des recommandations d'utilisation et des cas d'utilisation représentatifs.
Enfin, l'annexe comprend des exemples de combinaison de ces modèles dans des solutions globales pour les agents, qui favorisent une expérience plus vaste pour les agents, par exemple pour le service à la clientèle ou les ventes intermédiaires. Consultez cette section pour voir comment une expérience agentique riche exploite la décomposition et la séparation des préoccupations au niveau de l'agent et de l'action pour favoriser la réutilisation au niveau de l'interaction, les agents partagés prenant en charge les administrés internes et externes, en mode d'assistance et autonome.
## 1\. Architecture système multi-agents
En intégrant l’IA générative à leurs écosystèmes, les architectes d’entreprise doivent répondre à un ensemble commun de questions de conception :
- Combien d'agents sont requis ?
- Comment les agents vont-ils interagir ?
- Quelle est la division du travail entre les agents et les humains ?
- Comment ces composants sont-ils assemblés dans un système cohérent ?
Ce document présente une méthodologie basée sur un schéma pour concevoir et élaborer des solutions agentiques.
Les agents _monolithiques_ sont le point de départ de la plupart des solutions agentiques. Les agents, et plus particulièrement les agents Agentforce, sont performants dans de nombreux domaines. Pour des cas d'utilisation courants, commencez par un seul agent.
À mesure que votre organisation se développe, les architectures multi-agents sont l'approche préférée. L'_architecture multi-agents_ offre une échelle, un contrôle et une flexibilité supérieurs aux systèmes monolithiques à agent unique.
L'architecture multi-agents offre les principaux avantages suivants :
- **Accroissement des performances et de la complexité**: Un système d'agents multiples et spécialisés augmente les capacités et simplifie l'adhésion aux instructions.
- **Modularité et extensibilité** : Les agents individuels peuvent être ajoutés, remplacés, modifiés et testés avec plus de facilité, ce qui favorise l'agilité.
- **Résilience et tolérance aux pannes**: La défaillance d'un seul composant ne compromet pas l'ensemble du système, ce qui entraîne une meilleure résilience globale.
- **Gouvernance décentralisée**: Le dépannage et la gestion peuvent être isolés pour des agents spécifiques et leurs applications correspondantes, ce qui simplifie la maintenance et la surveillance.
## 2\. Principes architecturaux fondamentaux
La rationalisation d'une architecture multi-agents commence par projeter les principes architecturaux fondamentaux sur les capacités et la structure des agents. Les architectures multi-agents qui en résultent sont alors une manifestation des principes fondamentaux de conception et d'architecture système alignés sur le « grain » unique des technologies IA.
Les principes clés qui guident cette architecture comprennent :
- Gérer la complexité par la décomposition
- Améliorer la résilience et réduire la fragilité en découplant
- Amélioration de la fiabilité et de l'efficacité en réutilisant le code
- Améliorer la fiabilité des agents en limitant l'étendue des préoccupations d'un agent
- Améliorer la maintenance et l'évolution du système grâce à la modularité et à l'extensibilité
- Simplification de la gestion et de la responsabilité des agents grâce à la spécialisation
Contrairement aux architectures agentiques plus primitives (par exemple, celles qui se concentrent sur les grands modèles de langage en tant que construction architecturale principale), _Agentforce a été conçu pour l'orchestration multi-agents dès sa création_. L'orchestration multi-agents sous-tend le moteur de raisonnement Atlas et le raisonnement agentique pour créer des parcours de programmation dynamiques et efficaces dans une réponse agentique afin d'élargir considérablement la capacité à offrir une augmentation large et profonde de l'expérience utilisateur (UX).
Dans Agentforce ce type de coordination est activé par les protocoles ouverts clés, interopérables et les Produits Salesforce suivants :
- **Agentforce** fournit un sous-système Agent pour encapsuler tous les éléments clés d'un agent: rubriques, instructions, actions, garde-fous, contexte, invocations, sorties, détails d'exécution, journaux, etc.
- **Actions** : fournir des hooks pour accéder aux données, appeler des flux, invoquer des systèmes externes et appeler d'autres agents.
- **Data 360** : fournit une couche de virtualisation des données qui fournit à l'agent un contexte spécifique et individualisé (en exploitant le profil unifié et le porte-clés de Data 360 pour extraire des informations spécifiques de l'ensemble de l'entreprise).
Pour les agents de l'ensemble de l'entreprise ou pour accéder à des agents ou à des ressources, nous prenons en charge :
- **Model Context Protocol (MCP)**: est une couche de communication sécurisée qui connecte les agents aux outils, données et Knowledge d'entreprise pour garantir l'exactitude du contexte.
- **Protocole A2A** (agent à agent) : est une poignée de main standardisée pour la délégation inter-agents qui permet une coordination sécurisée et régie entre les systèmes, les organisations et les fournisseurs.
Ces principes jettent les bases d'un système d'intelligence orchestrée évolutif et gouvernable.
### Considérations supplémentaires
Les solutions agentsiques robustes nécessitent des approches claires des exigences non fonctionnelles qui sous-tendent une livraison efficace de la technologie :
- Sécurité et gouvernance (gestion des identités et des accès, confidentialité des données, sécurité des données et modélisation des menaces).
- Observabilité et surveillance (traçage distribué, consignation centralisée, métriques et tableaux de bord).
- Opérationnalisation et gestion du cycle de vie (spécification, génération de requêtes de test, tests, commentaires, apprentissage continu, dépréciation).
Ce sont des considérations architecturales clés pour élaborer des solutions Enterprise Agentic qui ne sont pas abordées dans ce livre blanc. Elles seront toutefois abordées dans de futures publications.
## 3\. Taxonomie de l'agent d'entreprise
Pour gérer un paysage agentique à l'échelle de l'entreprise, les architectes doivent classer les agents à travers deux perspectives complémentaires : la fonction technique et l'impact métier.
### 3.1 Classification des rôles fonctionnels
Cette taxonomie catégorise les rôles fonctionnels que les agents peuvent assumer dans une architecture.
- **Rôles Canal/UX**: Définissez la modalité d'interaction (par exemple, Headless, Invite, Chats et messages, ou Espaces de travail gérés par l'IA).
- **Specialist Roles**: Encapsulez deep-domain Knowledge (par exemple, Expert de domaine, Knowledge Minion, Assistant ou Planificateur).
- **Rôles de service utilitaire**: Effectuez des tâches transactionnelles discrètes (par exemple, Génération, Résumé, Transformation ou Configuration).
- **Rôles de maintenance et de service proactif**: Mettez l'accent sur l'intégrité et la qualité des données (par exemple, Curation, Configuration, Qualité des données ou Enrichissement des données).
- **Rôles de longue durée**: Gérez les processus sur de longues périodes (par exemple, Concierge, Chef de projet, Nourrisseur ou Surveillant/Alerteur).
## 4\. Le modèle de carte Agentic
Pour faciliter la conception et la communication claires, la **carte agentique** est le modèle standard qui décrit les solutions des agents. Il définit les entités, les systèmes et les interactions clés dans un modèle de conception spécifique.
Voici les composants de modèle de carte Agentic :
- Les **couches utilisateur** définissent les acteurs humains du système (par exemple, les clients, les employés authentifiés (SF-Users) et les employés non authentifiés).
- Les **couches d'agents** décrivent les agents requis, les modèles exposés, les relations entre eux et les instructions utilisées pour actualiser des modèles spécifiques.
- **Contexte/Actions** sont les ressources, les capacités ou les actions que l'agent gère ou auxquelles il accède.
- Les **sources** sont les données, applications, bases Knowledge et autres systèmes sous-jacents auxquels les agents se connectent.
Les annexes A et B illustrent les modèles d'agents au niveau du système en démontrant leur composition dans les lames natatoires du modèle de carte des agents.
## 5\. Infrastructures de schéma agentique
Chez Salesforce, nous utilisons une bibliothèque de modèles d'agent pour organiser et fournir des solutions agentsiques fiables et prévisibles. Ces modèles sont nos plans pour résoudre des problèmes architecturaux courants.
Ils sont regroupés en quatre catégories principales :
- **Modèles d'interaction**: Mettez l'accent sur l'engagement des agents et l'expérience utilisateur (UX).
- **Modèles de spécialiste/travailleur**: Encapsuler des deep Knowledge ou des compétences spécifiques au sein d'un domaine particulier.
- **Schémas d'utilitaires et de gestion des données**: Exécutez des tâches spécifiques, souvent répétitives, qui prennent en charge d'autres agents ou processus.
- **Schémas de longue durée**: Gérez les processus et les workflows qui se produisent sur de longues périodes, impliquant plusieurs étapes.
Les sections suivantes détaillent les principaux modèles de chaque catégorie. Chaque description de schéma fournit une **Vue d'ensemble**, **un Type de** sortie, **un Guide d'utilisation** du schéma, **des Cas d'utilisation** représentatifs et un **Diagramme de solution**, ainsi qu'un mappage avec la **rubrique de maturité** Salesforce Agentic.
## 6\. Modèles d'interaction
Les _modèles d'interaction_ sont des conceptions fondamentales qui se concentrent sur l'engagement des agents et l'expérience utilisateur.
### Modèle Greeter
- **Vue d'ensemble**: Le _modèle Greeter_ est un modèle simple et facile à implémenter qui utilise le langage naturel pour déterminer l'intention de l'utilisateur. Il achemine ensuite l'utilisateur vers l'agent humain approprié.
- **Type de sortie**: Transférer/escalader à la ressource suivante.
- **Valeur métier**: Facilitez un premier contact transparent et efficace pour les clients tout en maximisant la résolution des intentions et la collecte du contexte pour les fournisseurs de services.
- **Guide d'utilisation**: Configurez l'agent en tant que ressource d'engagement principale pour les canaux de marque. Fournissez des instructions sur la marque, les produits et les services associés à des instructions d'acheminement basées sur l'intention de l'utilisateur. L'agent recueille et résume l'intention de livrer un transfert chaleureux.
- **Cas d'utilisation représentatif**: Imaginez une page Web qui utilise un robot de chat pour présenter un menu d'options dans lequel les utilisateurs doivent cliquer sur toutes les options avant d'être dirigés vers un humain. Pour améliorer la productivité et l'efficacité du back-office, les chatbots utilisent souvent des parcours de travail et des interactions complexes et complexes. Cela entraîne un scénario de fatigue « Remplir, choisir et cliquer » pour les clients, qui entraîne souvent une frustration si leur contexte est extérieur aux options de menu disponibles. En remplaçant les chatbots traditionnels par la _porte d'entrée_ Agentic, qui utilise des interactions en langage naturel, elle allège le fardeau et offre une interaction de type humain.
- **Agentforce Recipe**:
- Agent de service Agentforce : [Construire un agent de service](https://trailhead.salesforce.com/content/learn/projects/quick-start-build-your-first-agent-with-agentforce)
- L'agent de service empaqueté a des capacités de transfert configurables qui prennent en charge le transfert:
- Aux agents humains
- Aux agents IA
- Aux agents externes
- Modèles spécifiques au secteur d'activité qui contiennent des exemples de code
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 1 (ou Niveau 0 si vous utilisez l'agent de service prêt à l'emploi avec transfert et escalade intégrés)
### Modèle d'opérateur
- **Vue d'ensemble**: Le _schéma Opérateur_ s'inspire du _schéma Plus Grand_ en acheminant les demandes vers l'agent spécialisé approprié ou l'intention humaine et de négociation (si nécessaire).
- **Type de sortie**: Transférer à la ressource suivante.
- **Guide d'utilisation**: Associez des instructions spécifiques à la marque et au service à des instructions indiquant où envoyer l'utilisateur en fonction de son intention. Définissez des ressources d'escalade, qui peuvent être humaines ou d'autres agents.
- **Cas d'utilisation représentatif**: Utilisez la _porte d'entrée_ Agentic pour les scénarios où le degré de spécialisation des représentants humains ou IA est élevé.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 2
### Modèle d'orchestrateur
- **Vue d'ensemble**: Le _schéma Orchestrateur_ gère un « essaim » d'agent IA. Lorsqu'il reçoit une demande de l'utilisateur, il transmet l'énoncé à un ou plusieurs agents spécialisés, puis agrège les réponses pour l'utilisateur. Contrairement au _modèle Opérateur_, il reste le premier point de contact (POC).
- **Type de sortie**: Réunissez et préparez les réponses des agents.
- **Guide d'utilisation**: Configuré en tant qu'engagement principal. Fournissez des instructions à chaque agent de support (par exemple, une PME Prioritaire ou Domaine) afin de permettre à l'orchestrateur de leur transmettre les énoncés.
- **Cas d'utilisation représentatif**: Utilisez le _modèle Orchestrateur_ comme porte d'entrée agentique pour assister les clients qui doivent discuter de plusieurs sujets par conversation, ce qui nécessite des solutions multi-agents et des interactions cohérentes. Dans une architecture multi-systèmes, tenez compte du _modèle Orchestrateur_ pour coordonner les réponses entre les systèmes et avec la collaboration d'agents externes.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 3
### Schéma Écouteur/Fil
- **Vue d'ensemble**: Le _modèle Écouteur/Fil_ expose le contexte et les connaissances pendant le flux d'une conversation. L'_écouteur_ est déclenché à chaque tour de conversation pour rechercher et afficher des informations pertinentes pour un employé.
- **Type de sortie**: Fournissez un contexte pertinent basé sur la conversation, qui peut être mis en forme pour l'effet (par exemple, faire des comparaisons ou mettre en évidence des points clés).
- **Guide d'utilisation**: Joignez l'écouteur à un canal au tour par tour (par exemple, chat, voix ou SMS). Définissez des rubriques pour chaque domaine. L'agent consomme la transcription, identifie les rubriques et invoque des actions pour rechercher et publier du contenu pertinent dans un fil actif pour l'employé.
- **Cas d'utilisation représentatif**: Utilisez l'_assistant universel_ pour assister le service client ou les commerciaux.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 3
### Modèle d'espace de travail (Radar O'Reilly)
- **Vue d'ensemble**: Le _modèle Workspace (Radar O’Reilly)_ gère une fenêtre UX unique réactive dans le flux d’une conversation. Il traite chaque énoncé pour mettre à jour des parties de l'UX avec le contenu approprié.
- **Type de sortie**: Fournissez un contexte pertinent situé dans un portlet dans une vue panoramique élargie.
- **Guide d'utilisation**: Un agent _Orchestrateur_ transmet des énoncés à une série d'agents _de rubriques_. Chaque agent de rubrique évalue l'instruction afin de déterminer si une mise à jour de l'expérience utilisateur est nécessaire. Dans ce cas, il envoie automatiquement des mises à jour dynamiques aux composants Web Lightning correspondants.
- **Cas d'utilisation représentatif**: Cela fonctionne comme une porte d'entrée agentique avancée.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 3
## 7\. Modèles de spécialiste
Les _schémas spécialisés_ englobent des Knowledge ou des compétences approfondies dans un domaine particulier, et sont généralement orchestrés par _des schémas Interaction_.
### Modèle de robot de réponse
- **Vue d'ensemble**: Le _modèle Answerbot_ est un modèle efficace pour le libre-service qui utilise GenAI pour déterminer le langage naturel pour la récupération Knowledge, pas seulement des mots-clés.
- **Type de sortie**: Knowledge résumé et références/citations à des documents d'appui.
- **Guide d'utilisation**: Organisez et ingérez des documents sources fiables (par exemple, Knowledge Stores ou FAQ) pour configurer l'agent. Positionnez l'agent sur les sites Web de l'entreprise ou dans des portails internes. Surveillez les questions pour identifier et combler les lacunes Knowledge.
- **Cas d'utilisation représentatif**: Faciliter les recherches en langage naturel sur un site Web d'entreprise, interagir avec un robot des avantages sociaux des RH et fournir des composants en libre-service à tous les administrés.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 1
### Schéma PME du domaine
- **Vue d'ensemble**: Le _schéma Domaine PME_ est un schéma de base qui fournit un frontal en langage naturel pour un domaine métier (par exemple, Commandes ou Déclarations).
- **Type de sortie**: Fournissez des contenus, des rubriques, des données et des informations mises en forme pertinents sur le domaine.
- **Guide d'utilisation**: Utilisez ce modèle pour encapsuler un sujet ou un domaine métier. Configurez l'agent capable d'effectuer les opérations CRUD appropriées. Rendez ces agents disponibles via [_des modèles Interaction_](/docs/architect/fr-fr/fundamentals/guide/enterprise-agentic-architecture#6-modèles-dinteraction) (par exemple Orchestrateur ou Écouteur).
- **Cas d'utilisation représentatif**: Garantir un domaine de données métier, fournir un « Agent de commande » ou un « Agent d'inventaire » et fournir une interface agentique pour un domaine métier.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 2
### Modèle d'interrogateur
- **Vue d'ensemble**: Le _modèle Interrogateur_ est un agent de PME qui peut être interrogé sur une rubrique afin d'assembler le contexte de plusieurs sources pour répondre à des questions. La capacité agentique clé exploitée est la capacité d'extraire le contexte et de connecter des concepts à travers un ensemble de contenus, de la même façon qu'un humain le ferait après avoir lu et internalisé le contenu. Ce modèle réduit le besoin d'une « intégration fauteuil-pivot ».
- **Type de sortie**: Saisissez des réponses aux questions.
- **Guide d'utilisation**: Il est souvent configuré en tant que widget de console connecté au contexte actuel de l'utilisateur pour lui permettre de poser des questions directement. Il est également utilisé conjointement avec des ressources Knowledge telles que des FAQ, des Polices et des catalogues de produits. Associez le _modèle Interrogateur_ à des invites standard pour adapter les réponses communes aux questions courantes.
- **Cas d'utilisation représentatif**: Utilisez-le en tant qu'agent d'assistance contractuelle, assistant de demande de prestations ou agent spécialisé dans les schémas multi-agents (par exemple, Écouteur ou Espace de travail).
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 2
### Modèle de prioriseur
- **Vue d'ensemble**: Le _modèle Priorizer_ est utilisé pour organiser une série de tâches ou d'objets de travail en fonction d'un objectif défini. Il exploite GenAI pour l'analyse qualitative, l'analyse de données non structurées ou l'analyse intégrative dans plusieurs domaines de données.
- **Type de sortie**: Fournissez des connaissances génératives.
- **Guide d'utilisation**: Utilisez le langage naturel pour décrire les qualités souhaitées pour la priorisation. Ancrez l'agent en utilisant une série d'options sélectionnables. Combinez-le au modèle Listener pour créer une « Next Best Action » réactive dans le flux de travail.
- **Cas d'utilisation représentatif**: Utilisez-le en tant que générateur _Next Best Action_ ou agent spécialisé dans les modèles à long terme ou multi-agents.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 2
## 8\. Modèles d'utilitaires et de données
Les _modèles d'utilitaires_ exécutent des tâches spécifiques et répétitives qui prennent en charge d'autres agents ou processus.
### Modèle de générateur
- **Vue d'ensemble**: Le _modèle Générateur_ est un modèle de base pour créer du contenu (par exemple, des résumés de requête ou des brouillons d'e-mails) à partir d'entrées et de normes existantes. Elle est souvent implémentée en tant qu'invite et peut être incorporée à d'autres agents.
- **Type de sortie**: Fournissez un contenu généré qui respecte le format et l'intention demandés.
- **Guide d'utilisation**: Le _modèle Générateur_ peut être utilisé dans la plupart des autres modèles ou en tant que modèle autonome. Le contexte peut être fourni par la demande, l'hydratation pendant l'exécution ou des étapes d'enrichissement supplémentaires.
- **Cas d'utilisation représentatif**: Fournissez des résumés de requête, des brouillons d'e-mails, des articles Knowledge ou des propositions/réponses aux QBR.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 1
### Schéma de Data Steward
- **Vue d'ensemble**: Le _modèle Data Steward_ est un modèle autonome en arrière-plan qui introduit une étape agentique dans les opérations de données pour garantir la qualité, la conformité et l'enrichissement cohérents des données.
- **Type de sortie**: Saisissez des champs d'enregistrement et de données mis à jour avant l'enregistrement.
- **Guide d'utilisation**: Incorporez la qualité des données au point de création des données en ajoutant des gestionnaires de données qui enregistrent les flux déclencheurs avant d'enregistrer les données. Aide à garantir une application cohérente des données de catégorie, de résumé et d'état.
- **Cas d'utilisation représentatif**: Garantir des mises à jour cohérentes du style « Pizza-Tracker », enrichir les données des comptes et éliminer les codes postaux et les adresses non concordants.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 2
### Modèle Zen Data Gardener
- **Vue d'ensemble**: Le _modèle Zen Data Gardener_ est un modèle planifié en arrière-plan utilisé pour toiletter et standardiser les données, en exploitant un raisonnement peu coûteux pour valider, enrichir et conformer les données dans des domaines de données autrement non connectés.
- **Type de sortie**: Fournissez des enregistrements mis à jour et/ou des tâches de gestion des données.
- **Guide d'utilisation**: Utilisez le modèle pour activer l'examen et la validation réguliers et périodiques des données. Pour des données à évolution lente, planifiez l'agent sur une cadence lente (par exemple mensuelle). Combinez-les au [modèle Data Steward](/docs/architect/fr-fr/fundamentals/guide/enterprise-agentic-architecture#schéma-de-data-steward) pour fournir des opérations prospectives et rétrospectives de qualité des données.
- **Cas d'utilisation représentatif**: Garantir l'alignement entre les garanties vendues et le système de déclaration, ainsi que la validation périodique des licences de courtier par rapport aux registres nationaux.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 4
### Schéma du configurateur
- **Vue d'ensemble**: Le _modèle Configureur_ génère des artefacts de configuration (par exemple, SQL/SOQL, JSON et CSV) à partir des exigences en langage naturel. Il peut également être exécuté à l'envers pour valider une configuration existante par rapport aux exigences.
- **Type de sortie**: Fournissez des enregistrements mis à jour, des tâches de gestion des données ou créez des problèmes/erreurs pour les corrections.
- **Guide d'utilisation**: Ancrez l'agent en utilisant des normes, des consignes ou des exemples spécifiques. Configurez des exigences d'élaboration en utilisant des sources telles que des contrats ou des spécifications produit. Connectez le _modèle Configureur_ au système cible pour envoyer automatiquement la configuration générée.
- **Cas d'utilisation représentatif**: Générer des enregistrements de configuration de produits pour les produits d'assurance maladie et valider les conditions de contrat/paiement pour les prestataires de soins.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 4
### Modèle de juge et de jury
- **Vue d'ensemble**: Le _modèle Juge et Jury_ est conçu pour minimiser les hallucinations en utilisant un ensemble d'agents « jurés » et un agent « juge » qui évalue la congruence des réponses pour s'assurer qu'elles sont matériellement cohérentes et fondées.
- L ' _approche intégrée_ est intégrée à Agentforce et au moteur de raisonnement Atlas pour vérifier la véracité et la pertinence des réponses. Le _schéma Juge et Jury_ s'appuie sur cette capacité lorsque des niveaux élevés de précision sont essentiels.
- La combinaison de l'_ancrage des données_ (par exemple, « recherchez votre réponse dans ces enregistrements/documents ») et de l'_ingénierie des invites_ (par exemple, « renvoyez une réponse uniquement si elle se trouve dans ces enregistrements » ou « validez votre réponse par rapport à cette source externe ») est également efficace pour réduire les hallucinations.
- **Type de sortie**: Fournissez des connaissances génératives.
- **Guide d'utilisation**: Utile lorsqu'il existe un fort besoin de résultats génératifs cohérents et ancrés. Un _juge_ compile une invite ancrée et la transmet à deux _jurés_ ou plus, puis le juge évalue les réponses. Pour de meilleurs résultats, utilisez différents modèles (par exemple, un modèle OpenAI et un autre modèle Anthropic) pour chaque agent Juré.
- **Cas d'utilisation représentatif**: Fournissez des réponses de haute fidélité et factuelles pour minimiser les hallucinations.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 2
### Modèle de modèle
- **Vue d'ensemble**: Le _modèle des modèles_ exploite plusieurs agents experts pour générer un large éventail de perspectives, puis extrait le consensus. Contrairement au [modèle Juge & Jury](/docs/architect/fr-fr/fundamentals/guide/enterprise-agentic-architecture#modèle-de-juge-et-de-jury), ce modèle embrasse plusieurs points de vue pour augmenter la richesse.
- Ce modèle peut également être appelé modèle Panel of Experts lorsqu'il existe des modèles experts avec différents points de vue (POV) qu'il peut être utile de toucher.
- Contrairement au schéma Juge et Jury où l'intention est de s'assurer que la réponse de l'agent converge vers une « vérité » accessible à tous, le _modèle de modèles_ élargit la portée de la réponse en tirant parti de la diversité dans l'environnement de l'agent.
- Ce schéma suppose que d'autres agents ont un POV distinct. Par exemple, dans un environnement multi-organisations, multi-agents ou avec plusieurs agents fournis par des fournisseurs à travers des piles technologiques, le _modèle de modèles_ fournit une structure pour intégrer plusieurs POV.
- Lors de l'examen de ce schéma, tenez également compte d'autres approches, souvent plus légères :
- Au lieu de définir plusieurs agents experts, spécifiez plusieurs invites et faites fonctionner le système comme un ensemble d'invites.
- Tirez parti de l'« ancrage » à l'aide d'actions qui accèdent aux données adaptées au contexte.
- **Type de sortie**: Fournissez des connaissances génératives.
- **Guide d'utilisation**: Le rôle d'un agent _agrégateur_ est de former et de renvoyer un POV enrichi basé sur les concepts clés renvoyés par les agents Modèle. Les agents modèle déterminent une réponse en fonction de leur POV unique.
- **Cas d'utilisation représentatif**: Utiliser dans des situations qui peuvent bénéficier de la réunion de points de vue différents pour ajouter à la qualité des réponses.
Par exemple, un environnement agentique multisystème dans lequel les agents privilégiés (par exemple, un _agent ERP_) peuvent avoir un POV précieux et inaccessible.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 2
## 9\. Modèles de processus à long terme
Les _modèles Processus long_ gèrent les processus qui se produisent sur de longues périodes et impliquent plusieurs étapes et acteurs.
### Modèle de gestionnaire de projet
- **Vue d'ensemble**: Le _modèle Chef de_ projet est un modèle complexe qui supervise un projet à long terme. Il coordonne les activités, suit la réalisation, notifie les utilisateurs et représente le statut du projet pour les parties prenantes.
- **Type de sortie**: Il existe plusieurs sorties (par exemple, requêtes, tâches, mises à jour de statut et notifications).
- **Guide d'utilisation**: Utilisez-le comme modèle de parapluie pour prendre en charge des activités régulières, répétées et à plusieurs étapes. Le _modèle Gestionnaire de projet_ reprend un modèle d'entrée/plan d'un projet (y compris des tâches, des rôles et des dépendances), puis instancie les requêtes et les activités et les attribue aux utilisateurs.
- **Cas d'utilisation représentatif**: Utilisé pour la gestion de l'installation de comptes et l'engagement commercial d'entreprise.
- **Diagramme**:
- **Maturité Salesforce Agentic**: Niveau 4
## 10\. Archétypes d'orchestration d'entreprise
Alors que les schémas décrivent les rôles des agents, les _archétypes d'orchestration_ définissent les schémas au niveau du système pour la collaboration d'une flotte d'agents. Ces archétypes précisent les rôles d'_Agentforce_ comme cerveau d'orchestration et _de MuleSoft_ comme connecteur et adaptateur universels.
**Archétype 1 : SOMA (organisation unique, agents multiples)**
- **Définition**: Plusieurs agents collaborent au sein d'une organisation Salesforce qui utilise une gouvernance et des données partagées.
- **Flux architectural**: Dans Agentforce, un _agent superviseur_ joue le rôle d ' une porte d ' entrée unique, acheminant les requêtes vers _des agents spécialisés_ au sein de l ' organisation. Pour les fonctionnalités externes, les agents utilisent le _client Agentforce MCP_, MuleSoft servant d ' enveloppe MCP pour les API non activées par MCP.
- **Considérations clés**: Ce schéma centralise la logique d'orchestration dans Salesforce (de la même façon que le contexte CRM et Data 360) afin de préserver la gouvernance, l'identité, les autorisations et l'observabilité unifiées.
**Archétype 2 : MOMA (organisation multiple, agents multiples)**
- **Définition**: Les agents collaborent entre plusieurs organisations Salesforce, ce qui nécessite une coordination sécurisée entre les limites en données et en autorisations.
- **Flux architectural**: Un _agent superviseur_ d'une organisation délègue une tâche à un agent d'une autre organisation via le protocole standardisé _agent à agent_ (A2A). Cette poignée de main garantit Trust au niveau de l'organisation, flux d'identité utilisateur et contexte de conversation partagée.
- **Considérations clés**: Ce schéma préserve l'autonomie de l'organisation tout en activant les workflows à l'échelle de l'entreprise, qui constituent une base pour des opérations agentiques cohérentes dans des domaines complexes et multi-organisations.
**Archétype 3 : A2A (Orchestration dirigée par Salesforce)** multi-fournisseurs
- **Définition**: Un _agent superviseur_ dans Salesforce coordonne le travail entre un mélange d'agents natifs de Salesforce et d'agents d'autres fournisseurs (par exemple, Google/Vertex ou LangGraph) via le protocole A2A.
- **Flux architectural**: L'_agent superviseur_ traite la demande et orchestre un plan, en invoquant des agents fournisseurs internes et externes via le protocole A2A. Pour les systèmes externes qui ne sont pas compatibles A2A, _MuleSoft_ peut exposer une «façade d'agent léger» qui enveloppe l'outil existant et communique avec l'A2A.
- **Considérations clés**: Cet archétype maintient le cerveau d'orchestration proche de CRM et Data 360 en utilisant A2A pour produire une composition propre et gouvernable sans niveau d'orchestration séparé.
**Archetype 4 : A2A (MuleSoft-led Orchestration)** multi-fournisseurs
- **Définition**: L'orchestration est initiée à partir d'un point d'entrée non-Salesforce, qui nécessite un orchestrateur externe neutre pour effectuer le raisonnement et l'acheminement.
- **Flux architectural**: Un _agent de l'\_interface utilisateur d'un système externe transmet la requête à un service d'orchestration (conceptualisé en tant que \_MuleSoft Conductor_), qui interprète l'intention et planifie la tâche. Le chef de train utilise ensuite l'A2A pour acheminer les appels vers les agents fournisseurs, y compris les agents Agentforce pour des actions CRM ou de service.
- **Considérations clés**: Ce modèle est destiné aux points d'entrée non-Salesforce dans lesquels un orchestrateur neutre est préférable sur le plan architectural. Il garde l'UX dans le système de domaine tout en centralisant le raisonnement, la gouvernance, la politique et l'observabilité dans MuleSoft.
## 11\. Assemblage de solutions : Composition de motifs
Ces modèles individuels et archétypes d'orchestration sont des blocs de construction architecturaux conçus pour être composés en solutions de bout en bout. La Carte de solution agentique est utilisée pour visualiser comment ces composants sont câblés ensemble.
- Une _solution Member Services_ pour un prestataire de soins est une implémentation standard de l'archétype SOMA. Il utilise un Answerbot pour les utilisateurs anonymes, un _Orchestrateur_ pour les membres authentifiés et plusieurs _agents de PME_ (par exemple, Requête, Réclamations et Avantages) pour gérer des demandes spécifiques.
- Un _portail B2C Broker_ est une composition complexe qui utilise un agent _Orchestrateur_ de portail pour invoquer un _agent Gestionnaire de projet_ de longue date dans le cadre d'un processus de demande de propositions, lequel utilise à son tour _Headless_, _Data Steward_ et _Interrogator_ pour les opérations de back-office sur les données.
## 12\. Conclusion
Une méthodologie de schéma de conception agentique fournit la discipline architecturale requise pour élaborer des systèmes d’IA d’entreprise robustes, évolutifs et maintenables. En réduisant la complexité et en favorisant la modularité, ces modèles permettent aux architectes de fournir des solutions agentsiques fiables et prévisibles.
Le choix d'un archétype d'orchestration est une décision stratégique basée sur l'endroit où les utilisateurs travaillent, le contexte et comment l'entreprise régit l'interaction entre les humains, les agents et les systèmes. En comprenant la distinction entre les agents d'élaboration et leur orchestre, et en exploitant des protocoles ouverts tels que _MCP_ et _A2A_, les architectes peuvent dépasser la création de robots isolés pour concevoir un système de raisonnement d'entreprise cohérent, gouverné et distribué. Cette approche fournit un langage partagé et une série de plans réutilisables pour élaborer une architecture agentique durable.
## Annexe : Cartes de solutions et architectures système
L'annexe ci-dessous présente des exemples concrets de la composition des schémas agentiques en solutions au niveau du système.
### Annexe A : Exemple de composition de schéma de base
Ce diagramme illustre comment cinq modèles de base peuvent être connectés ensemble pour créer un workflow de service client commun.
1. **Answerbot**: Un utilisateur anonyme pose une question, qui est traitée par un agent basé sur Knowledge.
2. **Opérateur**: La question d'un employé est triée par un Opérateur, qui consigne la conversation et la transmet à un agent plus spécialisé.
3. **Orchestrateur**: Un utilisateur authentifié (Utilisateur SF) interagit avec un Orchestrateur qui coordonne plusieurs agents pour gérer une demande à facettes multiples.
4. **Domaine PME**: Des agents spécialisés (par exemple, des agents RH ou des agents des avantages sociaux) sont invoqués par l'orchestrateur pour effectuer des mises à jour sur le sujet et récupérer des données spécifiques.
5. **Générateur**: Les agents utilitaires sont utilisés pour résumer les détails du compte ou conclure une requête une fois l'interaction terminée.
### Annexe B : Carte des solutions Agentic - Services aux membres
Cette carte de solution détaille une architecture agentique pour un cas d'utilisation des Services des membres, en montrant la composition de plusieurs modèles.
- **Profils utilisateur**: La solution sert trois types d'utilisateur distincts : Utilisateur anonyme, Membre authentifié et Utilisateur SF (par exemple, un représentant du service client humain).
- **Modèles d'interaction**: Un _Answerbot_ gère les requêtes anonymes « Find-A-Doc », tandis qu'un Orchestrateur (Agentic Front Door) gère les requêtes des utilisateurs authentifiés. Un _modèle Listener/Feed_ assiste l'utilisateur SF.
- **Réutilisation de l'agent de domaine**: Les _agents PME_ spécialisés (par exemple, Agent de requête, Agent de réclamation ou Agent de garanties) sont réutilisés dans différents flux d'interaction.
- **Autonome et assistance**: Le système combine des _agents autonomes_ (pour diriger l'interaction des utilisateurs) et _des agents d'assistance_ (pour augmenter les RSE humains).
- **Sources de données**: L'architecture intègre une combinaison de sources de données publiques et d'entreprise, avec une utilisation intensive de _Data 360_ et _MuleSoft_ pour la connectivité.
### Annexe C : Architecture système - Centre de contact
Ce diagramme illustre une architecture logique pour une solution d'IA d'assistance dans un Centre de contact, organisée en couches fonctionnelles.
- **Orchestrator Agents**: Gérez les expériences utilisateur pour différentes personnes (par exemple Anonyme, Membre externe ou RSE) et orchestrez le flux d'interaction global.
- **Worker Agents**: _Plusieurs PME_ s ' intéressent à des domaines métiers essentiels tels que Knowledge, Case/Claims/Prestations et Provider Directory. Un agent _Next Best Action_ est également inclus.
- **Agents de service**: Effectuez des tâches spécifiques et réutilisables telles que la traduction, la conclusion de la requête et le résumé de l'appel.
Intégration et systèmes de base : L'ensemble du système agentique est connecté via une couche d'intégration multi-plate-forme à des ressources de données non structurées, des ressources de données structurées et des systèmes d'entreprise de base.
- **Gouvernance**: Une couche de gouvernance fournit l'observabilité, l'évaluation et la gestion des grands modèles de gestion de la vie utilisés par les agents.
Architecture système du Centre de contact 
### Annexe D : Carte des solutions Agentic - Portail Broker
Cette carte des solutions présente une interaction agentique complexe et de longue durée pour un portail de courtiers en assurance santé B2B. Le modèle comprend un _agent du portail_ (_Orchestrateur_) qui facilite le parcours du courtier à travers plusieurs étapes (par exemple, soumettre une DP et recevoir une proposition). Cet orchestrateur invoque un agent _Chef de projet_, qui coordonne ensuite plusieurs agents headless pour la qualité et les transformations des données back-office, par exemple un extracteur de DP, une transformation de recensement et un délégué aux données.
### Annexe E : Architecture système - B2C Broker Agents
Ce diagramme montre une architecture logique pour une solution B2C Broker, qui montre une approche similaire au Centre de contact. Il comprend les _agents orchestrateurs_ pour différents types d'utilisateurs, _les agents travailleurs_ réutilisables pour des domaines clés (par exemple, Knowledge, Services aux membres ou Commissions) et les _agents des services_ publics pour des fonctions spécifiques telles que la traduction et le résumé.
### Annexe F : Architecture système - Contrat de fournisseur
Le diagramme ci-dessous montre une architecture logique pour une solution de Contrat de fournisseur. Les agents _d'orchestre_ gèrent les interactions complètes, _les agents travailleurs_ gèrent des intentions spécifiques dans un domaine (par exemple, un agent PME contractante) et les agents _des services publics_ exécutent des tâches discrètes telles que la comparaison de contrats ou la génération de connaissances.
### Annexe G : Tableau récapitulatif des modèles d'interaction
Le tableau ci-dessous récapitule plusieurs modèles d'interaction clés, des expériences utilisateur typiques et des objectifs architecturaux principaux.
| Modèle | Expérience utilisateur (UX) | Objet |
|---|---|---|
| Greeter | Texte tour par tour (Chat, Voice, SMS, etc.) qui se termine par le transfert de l'interaction à un humain par le répondeur | Il s'agit d'un schéma simple utilisé pour déterminer l'intention de l'utilisateur, puis l'acheminer vers l'agent humain approprié. |
| Opérateur | Texte tour par tour (Chat, Voice, SMS, etc.) qui se termine par le transfert de l'interaction à un agent humain ou Spécialiste par l'intervenant | Il est utilisé pour acheminer les requêtes vers les agents hybrides appropriés. En s'appuyant sur le Greeter, c'est un schéma simple qui négocie l'intention, puis transfère l'interaction à un agent humain ou IA spécialisé. |
| Orchestrateur | Texte tour par tour (Chat, Voice, SMS, etc.) avec le répondeur qui collecte et agrège les réponses des agents spécialisés et les livre à l'UX | Il est utilisé pour coordonner un « essaim » IA-agent géré qui répond à une conversation pendant sa progression. Un agent Orchestrateur transmet le texte de chaque tour à un ou plusieurs agents spécialisés, puis agrège les réponses de chacun. |
| Answerbot | Invite et réponse | Il s'agit d'une interface en langage naturel qui utilise des ressources Knowledge, des FAQ, des stratégies, etc. pour former des réponses. |
| Interrogateur | Invite et réponse | Cette interface en langage naturel est utilisée pour poser des questions dans un domaine ou une zone spécifique. |
| Écouteur / Fil | Texte tour par tour (Chat, Voix, SMS, etc.) qui se termine par le modèle Orchestrateur alimentant un Fil linéaire | Il est utilisé pour exposer le contexte et les connaissances dans le flux de conversation. |
| Espace de travail (Radar O'Reilly) | Texte tour par tour (Chat, Voice, SMS, etc.) qui se termine par un affichage tête haute adaptatif à un seul panneau de verre | Il est utilisé pour gérer un UX réactif à vitre unique dans le flux de conversation. |
| Modèles | Scénario |
|---|---|
| Invocation de processus à distance : demande et réponse | Salesforce invoque un processus sur un système distant, attend la fin de ce processus, puis suit l'état en fonction de la réponse du système distant. |
| Invocation de processus à distance : incendie et oubli | Salesforce invoque un processus dans un système distant, mais n'attend pas la fin du processus. À la place, le processus distant reçoit et accepte la demande, puis restitue le contrôle à Salesforce. |
| Synchronisation des données par lot | Les données stockées dans Lightning Platform sont créées ou actualisées pour refléter les mises à jour d'un système externe, et lorsque les modifications de Lightning Platform sont envoyées à un système externe. Les mises à jour dans les deux sens sont effectuées par lot. |
| Appel distant | Les données stockées dans Salesforce Platform sont créées, récupérées, mises à jour ou supprimées par un système distant. |
| Mise à jour de l'interface utilisateur basée sur les modifications des données | L'interface utilisateur de Salesforce doit être automatiquement mise à jour suite aux modifications apportées aux données Salesforce. |
| Virtualisation des données | Salesforce accède en temps réel aux données externes. Cela élimine la nécessité de conserver les données dans Salesforce, puis de rapprocher les données entre Salesforce et le système externe. |
| Aspect | Description |
|---|---|
| Type | Spécifie le style d'intégration : Processus, Données ou Virtuel.
|
| Calendrier | Spécifie le style d'intégration : Processus, Données ou Virtuel.
|
| Type | Calendrier | Modèle clé à prendre en compte |
|---|---|---|
| Intégration de processus | Synchrone | Invocation de processus à distance : demande et réponse |
| Intégration de processus | Asynchrone | Invocation de processus à distance : incendie et oubli |
| Intégration de données | Synchrone | Invocation de processus à distance : demande et réponse |
| Intégration de données | Asynchrone | Mise à jour de l'interface utilisateur basée sur les modifications des données |
| Intégration virtuelle | Synchrone | Virtualisation des données |
| Type | Calendrier | Modèle clé à prendre en compte |
|---|---|---|
| Intégration de processus | Synchrone | Appel distant |
| Intégration de processus | Asynchrone | Appel distant |
| Intégration de données | Synchrone | Appel distant |
| Intégration de données | Asynchrone | Synchronisation des données par lot |
| Durée | Définition |
|---|---|
| Traitement des événements | Le traitement des événements est la réception d'un événement identifiable chez un destinataire désigné (« gestionnaire »). Les principaux processus impliqués dans le traitement des événements comprennent :
Notez que le gestionnaire d'événement peut transmettre l'événement à un consommateur d'événement. Les utilisations courantes de cette fonctionnalité avec un middleware peuvent être étendues pour inclure la capacité populaire « publier/s'abonner » ou « pub/sub ». Dans un scénario de publication/abonnement, le middleware achemine les requêtes ou les messages vers les abonnés actifs aux événements de données à partir d'éditeurs d'événements de données actifs. Ces consommateurs qui ont des auditeurs actifs peuvent ensuite récupérer les événements au fur et à mesure de leur publication. Dans les intégrations Salesforce utilisant un middleware, la couche middleware prend le contrôle de la gestion des événements. Il collecte tous les événements pertinents, synchrones ou asynchrones, et gère la distribution à tous les points de terminaison, y compris Salesforce. Alternativement, cette capacité peut être atteinte avec la plate-forme de messagerie d'entreprise Salesforce en utilisant le bus d'événement avec des événements de plate-forme. |
| Conversion du protocole | La conversion de protocole est généralement une application logicielle qui convertit le protocole standard ou propriétaire d'un appareil vers le protocole adapté à un autre appareil afin d'assurer l'interopérabilité. Dans le contexte du middleware, la connectivité à un système cible particulier peut être limitée par le protocole. Dans ce cas, le format du message doit être converti ou encapsulé dans le format du système cible, dans lequel la charge utile peut être extraite. Ceci est également appelé tunnel. Salesforce ne prend pas en charge la conversion de protocole natif. Par conséquent, il est supposé que ces exigences sont remplies par la couche middleware ou le point de terminaison. |
| Traduction et transformation | La transformation est la possibilité de mapper un format de données avec un autre afin d'assurer l'interopérabilité entre les divers systèmes intégrés. Généralement, le processus consiste à reformater les messages en route pour les adapter aux exigences de l'expéditeur ou du destinataire. Dans les cas plus complexes, une application peut envoyer un message sous son propre format natif et deux applications ou plus peuvent recevoir chacune une copie du message sous leur propre format natif. Les outils de traduction et de transformation Middleware incluent souvent la possibilité de créer des façades de service pour des points de terminaison hérités ou non standard. Ces façades de service permettent à ces points de terminaison d'apparaître comme accessibles au service. Avec les intégrations Salesforce, on considère que ces exigences sont remplies par la couche middleware ou le point de terminaison. La transformation des données peut être codée en Apex, mais nous ne la recommandons pas pour des raisons de maintenance et de performance. |
| Mise en file d'attente et tampon | La mise en file d'attente et la mise en tampon reposent généralement sur la transmission de messages asynchrone, contrairement à une architecture requête-réponse. Dans les systèmes asynchrones, les files d'attente de messages fournissent un stockage temporaire lorsque le programme de destination est occupé ou lorsque la connectivité est compromise. De plus, la plupart des systèmes middleware asynchrones offrent un stockage permanent pour sauvegarder la file d'attente des messages. Le principal avantage d'un processus de messagerie asynchrone est que si l'application du destinataire échoue pour une raison quelconque, les expéditeurs peuvent rester inchangés. Les messages envoyés s'accumulent simplement dans la file d'attente des messages pour un traitement ultérieur lorsque le récepteur redémarre. Salesforce fournit uniquement une capacité de mise en file d'attente explicite sous forme de messagerie sortante basée sur un workflow. Pour fournir une véritable mise en file d'attente des messages pour d'autres scénarios d'intégration, notamment l'orchestration, la chorégraphie des processus et la qualité du service, une solution middleware est requise. |
| Protocoles de transport synchrones | Les protocoles de transport synchrones désignent les protocoles qui prennent en charge les activités dans lesquelles « un seul thread dans l'appelant envoie le message de requête, bloque l'attente du message de réponse, puis traite la réponse... Le thread de requête en attente de réponse implique qu'il n'y a qu'une seule requête en attente ou que le canal de réponse de cette requête est privé pour ce thread ». |
| Protocoles de transport asynchrones | Les protocoles de transport asynchrones désignent les protocoles prenant en charge les activités dans lesquelles « un thread de l'appelant envoie le message de requête et configure un rappel pour la réponse. Un fil séparé écoute les messages de réponse. Lorsqu'un message de réponse arrive, le fil de réponse invoque le rappel approprié, qui rétablit le contexte de l'appelant et traite la réponse. Cette approche permet à plusieurs requêtes en attente de partager un seul fil de réponses. » |
| Acheminement de la médiation | L'acheminement de la médiation est la spécification d'un « flux » complexe de messages de composant à composant. Par exemple, de nombreuses solutions basées sur un middleware dépendent d'un système de file d'attente de messages. Si certaines implémentations permettent de fournir une logique d'acheminement par la couche de messagerie elle-même, d'autres dépendent d'applications clientes pour fournir des informations d'acheminement ou permettent une combinaison des deux paradigmes. Dans des cas aussi complexes, la médiation du middleware simplifie le développement, l'intégration et la validation. ordinateur [Médiateur] pourrait s’assurer que le bon message passe au bon consommateur. » |
| Chorégraphie de processus et orchestration de service | La chorégraphie de processus et l'orchestration de service sont des formes de « composition de service » dans lesquelles un nombre quelconque de points de terminaison et de capacités sont coordonnés.
La différence entre la chorégraphie et l'orchestration de service est :
Des parties des chorégraphies de processus métier peuvent être élaborées dans des workflows Salesforce ou en utilisant Apex. Nous recommandons d'implémenter toutes les orchestrations complexes dans la couche middleware en raison des valeurs d'expiration Salesforce et des limites du gouverneur, en particulier dans les solutions nécessitant un véritable traitement des transactions. |
| Transactionnalité (cryptage, signature, livraison fiable, gestion des transactions) | La transactionnalité peut être définie comme la capacité à prendre en charge des transactions globales qui englobent toutes les opérations nécessaires pour chaque ressource requise. La transactionnalité implique la prise en charge des quatre propriétés ACID, l'atomicité, la cohérence, l'isolement, la durabilité, où l'atomicité garantit des résultats tout ou rien pour l'unité de travail (transaction).
Bien que Salesforce soit transactionnelle en soi, elle ne peut pas participer à des transactions distribuées ou à des transactions initiées hors de Salesforce. Par conséquent, il est supposé que pour les solutions nécessitant des transactions complexes et multisystèmes, la transactionnalité et les mécanismes de restauration/compensation associés sont implémentés au niveau de la couche middleware. |
| Acheminement | L'acheminement peut être défini comme spécifiant le flux complexe de messages d'un composant à l'autre. Dans les solutions modernes basées sur des services, ces flux de messages peuvent être basés sur un certain nombre de critères, notamment l'en-tête, le type de contenu, la règle et la priorité.
Avec les intégrations Salesforce, on considère que ces exigences sont remplies par la couche middleware ou le point de terminaison. L'acheminement des messages peut être codé en Apex, mais nous le déconseillons pour des raisons de maintenance et de performance. |
| Extraire, transformer et charger | Extraire, transformer et charger (ETL) désigne un processus qui implique :
Salesforce prend désormais également en charge la Capture des données de modification, qui est la publication d'événements de modification représentant les modifications apportées aux enregistrements Salesforce. Avec la Capture des données de modification, le client ou le système externe reçoit en temps quasi réel les modifications des enregistrements Salesforce. Avec ces informations, le client ou le système externe peut synchroniser les enregistrements correspondants dans un magasin de données externe. |
| Sondage long | L'interrogation longue, également appelée programmation Comet, émule un push d'information depuis un serveur vers un client. De la même façon qu'un sondage normal, le client se connecte et demande des informations au serveur. Cependant, au lieu d'envoyer une réponse vide si les informations ne sont pas disponibles, le serveur garde la requête en attente et attend que les informations soient disponibles (un événement se produit). Le serveur envoie ensuite une réponse complète au client. Le client redemande ensuite immédiatement des informations. Le client maintient continuellement une connexion avec le serveur. Par conséquent, il attend toujours une réponse. Si le serveur expire, le client se reconnecte et recommence. L'API Salesforce Streaming utilise le protocole Bayeux et CometD pour les longues interrogations.
|
| Solution | Ajustement | Commentaires |
|---|---|---|
| Services externes invoque un appel d'API REST | Meilleur | Les Services externes permettent d'invoquer un service hébergé en externe de façon déclarative (aucun code requis). Cette fonctionnalité est préférable lorsque les conditions suivantes sont remplies :
|
| Salesforce Lightning : le composant ou la page Lightning initie un appel externe Apex REST ou SOAP synchrone.</ Si le point de terminaison distant présente un risque de réponse à latence élevée (consultez la dernière documentation sur les limites pour connaître les limites applicables ici), un appel externe asynchrone, également appelé continuation, est recommandé pour éviter d'atteindre les limites du gouverneur de transaction Apex synchrone. |
Meilleur | Salesforce permet de consommer un WSDL et de générer une classe Apex proxy qui en résulte. Cette classe fournit la logique nécessaire pour appeler le service distant. Salesforce permet également d'invoquer des services HTTP (REST) en utilisant les méthodes standard GET, POST, PUT et DELETE. Une action initiée par l'utilisateur dans une page Lightning appelle ensuite une action de contrôleur Apex qui exécute ensuite cette classe Apex proxy pour effectuer l'appel distant. Les pages Lightning nécessitent une personnalisation de l'application Salesforce. |
| Un déclencheur synchrone invoqué à partir de modifications de données Salesforce exécute un appel externe Apex SOAP ou HTTP asynchrone. | Suboptimal | Vous pouvez utiliser des déclencheurs Apex pour effectuer une automatisation basée sur les modifications des données d'enregistrement. Une classe proxy Apex peut être exécutée à la suite d'une opération DML en utilisant un déclencheur Apex. Cependant, tous les appels passés depuis le contexte du déclencheur doivent être exécutés de façon asynchrone depuis l'événement initiateur. Par conséquent, cette solution n'est pas recommandée pour ce problème d'intégration. Cette solution est plus adaptée au schéma Invocation de processus distant - Feu et oubli. |
| Une tâche Apex par lot effectue un appel externe SOAP Apex ou HTTP synchrone. | Suboptimal | Vous pouvez passer des appels à un système distant à partir d'une tâche par lot. Cette solution permet l'exécution de processus distants par lot et le traitement de la réponse depuis le système distant dans Salesforce. Cependant, un lot donné est limité au nombre d'appels. Pour plus d'informations, consultez Limites du gouverneur. Une exécution par lot donnée peut exécuter plusieurs contextes de transaction (généralement par intervalles de 200 enregistrements). Les limites du gouverneur sont réinitialisées par contexte de transaction. |
Diagramme de téléchargementDans ce scénario : - Une action est initiée dans la page Lightning (par exemple, un clic sur un bouton). - Le navigateur (via un contrôleur côté client dans le cas d'un composant Lightning) effectue un POST HTTP qui effectue à son tour une action sur le contrôleur Apex correspondant. - Le contrôleur invoque l'appel réel au service Web distant. - La réponse du système distant est renvoyée au contrôleur Apex. Le contrôleur traite la réponse, met à jour les données dans Salesforce si nécessaire et restitue de nouveau la page. Dans les cas où l'état suivant doit être suivi, le système distant renvoie un identifiant unique stocké dans l'enregistrement Salesforce. **Résultats** L'application des solutions associées à ce schéma permet d'invoquer des processus distants initiés par un événement dans lesquels Salesforce gère le traitement. **Mécanismes d'appel** Le mécanisme d'appel dépend de la solution choisie pour implémenter ce schéma.
| Mécanisme d'appel | Description |
|---|---|
| Service externe avancé incorporé à un flux ou Composant Lightning ou Contrôleurs Apex |
Utilisé lorsque le processus distant est déclenché dans le cadre d'un processus de bout en bout impliquant l'interface utilisateur, et que le résultat doit être affiché ou mis à jour dans un enregistrement Salesforce. Par exemple, la soumission d'un paiement par carte de crédit à une passerelle de paiement externe et les résultats de paiement sont immédiatement renvoyés et affichés pour l'utilisateur. |
| Déclencheurs Apex | Utilisé principalement pour l'invocation de processus distants utilisant des appels externes Apex à partir d'événements initiés par DML. Pour plus d'informations sur ce mécanisme d'appel, consultez Modèle Invocation de processus distant : incendie et oubli. |
| Classes par lot Apex | Utilisé pour l'invocation de processus distants par lot. Pour plus d'informations sur ce mécanisme d'appel, consultez Modèle Invocation de processus distant : incendie et oubli. |
| Solution | Considérations relatives aux points de terminaison |
|---|---|
| Appels externes HTTP Apex | Le point de terminaison doit pouvoir recevoir des appels HTTP. Salesforce doit pouvoir accéder au point de terminaison sur l'Internet public. Pour les communications privées et sécurisées, Salesforce a également commencé à prendre en charge Salesforce Private connect via la plate-forme Hyperforce en toute sécurité. Pour plus d'informations, consultez Salesforce Private Connect.
Vous pouvez utiliser des appels externes HTTP Apex pour appeler des services REST en utilisant les méthodes standard GET, POST, PUT, DELETE et PATCH. |
| Appels externes SOAP Apex | Le point de terminaison doit pouvoir recevoir des appels HTTP. Salesforce doit pouvoir accéder au point de terminaison sur l'Internet public. Pour les communications privées et sécurisées, Salesforce a également commencé à prendre en charge Salesforce Private connect via la plate-forme Hyperforce en toute sécurité. Pour plus d'informations, consultez Salesforce Private Connect.
Cette solution nécessite que le système distant soit compatible avec les normes prises en charge par Salesforce. Au moment d'écrire ces lignes, les normes de service Web prises en charge par Salesforce pour les appels externes SOAP Apex sont les suivantes:
|
- Salesforce stocke la clé de substitution primaire ou unique du système distant pour l'enregistrement distant.
- Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique.
| Maître | Système Description |
|---|---|
| Salesforce | Le système distant stocke le RecordId Salesforce ou une autre clé de substitution unique de l'enregistrement. |
| Système distant | L'appel au processus distant renvoie la clé unique de l'application, et Salesforce stocke cette valeur de clé dans un champ d'enregistrement unique. |
- Orchestration de processus métiers et de règles impliquant une logique de flux complexe
- Agrégation des appels et de leurs résultats entre les appels à plusieurs systèmes
- Transformation des messages entrants et sortants
- Maintien de l'intégrité transactionnelle entre les appels à plusieurs systèmes
| Propriété | Obligatoire | Désirable | Non requis |
|---|---|---|---|
| Traitement des événements | X | ||
| Conversion du protocole | X | ||
| Traduction et transformation | X | ||
| Mise en file d'attente et tampon | X | ||
| Protocoles de transport synchrones | X | ||
| Protocoles de transport asynchrones | X | ||
| Acheminement de la médiation | X | ||
| Chorégraphie de processus et orchestration de service | X | ||
| Transactionnalité (cryptage, signature, livraison fiable, gestion des transactions) | X | ||
| Acheminement | X | ||
| Extraire, transformer et charger | X | ||
| sondage long | X |
- Salesforce consomme le service de compte de facturation WSDL à partir d'une classe proxy Apex.
- Exécutez la classe proxy Apex avec les informations clients transmises au service Web externe depuis un contrôleur Apex personnalisé ou un service externe.
- Le contrôleur personnalisé analyse ensuite les valeurs renvoyées par l'appel externe Apex et stocke ces informations dans l'objet salesforce.
- L'état du client est suivi avec un numéro de compte stocké dans l'objet Compte Salesforce.
- Traitement ultérieur du message de réponse par l'appelant
- L'appel au système distant nécessite-t-il que Salesforce attende une réponse avant de poursuivre le traitement ? L'appel au système distant est-il synchrone ou asynchrone ?
- Si l'appel au système distant est synchrone, la réponse doit-elle être traitée par Salesforce dans le cadre de la même transaction que l'appel ?
- La taille du message est-elle petite ?
- L'intégration est-elle basée sur l'occurrence d'un événement spécifique, par exemple un clic sur un bouton dans l'interface utilisateur de Salesforce, ou sur des événements basés sur DML ?
- La livraison garantie de messages depuis Salesforce vers le système distant est-elle une exigence ?
- Le système distant peut-il participer à une intégration Priorité au contrat dans laquelle Salesforce spécifie le contrat ? Dans certaines variantes de solution (par exemple, la messagerie sortante), Salesforce spécifie un contrat que le point de terminaison système distant implémente.
- Le point de terminaison ou le bus de service Enterprise (ESB) prend-il en charge les longues interrogations ?
- Les méthodes de configuration déclaratives sont-elles préférées au développement Apex personnalisé ? Dans ce cas, les solutions telles que les événements de plate-forme sont préférées aux appels externes Apex.
| Solution | Ajustement | Commentaires |
|---|---|---|
| Événements de plate-forme pilotés par le flux | Meilleur | Créez des flux par déclaration pour implémenter des événements de plate-forme. La solution recommandée est lorsque le processus distant est invoqué à partir d'un événement d'insertion ou de mise à jour. Les événements de plate-forme sont les messages d'événement (ou notifications) que vos applications envoient et reçoivent pour prendre des mesures supplémentaires. Les événements de plate-forme simplifient le processus de communication des modifications et de réponse sans écrire une logique complexe. Un ou plusieurs abonnés peuvent écouter le même événement et exécuter des actions. Par exemple, un système logiciel peut envoyer des événements contenant des informations sur les cartouches d'encre d'imprimante. Les abonnés peuvent s'abonner aux événements pour surveiller les niveaux d'encre d'imprimante et passer des commandes pour remplacer les cartouches à faible niveau d'encre. Les applications externes peuvent écouter des messages d'événement en s'abonnant à un canal via CometD. Les applications de plate-forme, telles que les composants Lightning, peuvent également s'abonner à des messages d'événement avec CometD. L'API PubSub Salesforce qui est basé sur gRPC et HTTP/2 peut également être utilisé ici. Salesforce prend également en charge les flux déclenchés par un événement de plate-forme, ce qui permet de créer un écouteur en utilisant l'interface de Flow Builder. Ce type de flux démarre automatiquement lorsqu'un message d'événement de plate-forme spécifique est publié dans le Bus d'événement Salesforce. |
| API Pub/Sub | Meilleur | L'API Pub/Sub est la méthode recommandée pour les consommateurs externes de consommer les événements dans le Bus d'événement. L'API Pub/Sub basée sur gRPC :
Lorsqu'un événement de plate-forme est défini dans Salesforce, il devient disponible pour les consommateurs internes et externes. |
| Capture des données modifiées | Meilleur | La Capture des données de modification (CDC) publie les événements de modification des enregistrements Salesforce correspondant aux opérations de création, de mise à jour, de suppression et d'annulation de suppression. L'activation de la Capture des données de modification (CDC) dans Salesforce est un processus purement déclaratif, ne nécessitant aucun code Apex. Des messages de notification sont envoyés au bus d'événement auquel les clients peuvent s'abonner en utilisant l'API Pub/Sub ou des déclencheurs Apex. Les systèmes pilotés par l'événement rationalisent la communication entre les systèmes d'entreprise distribués, augmentent l'évolutivité et fournissent des données en temps réel. Par exemple, si les informations de commande résident dans votre système ERP et dans Salesforce, vous pouvez diffuser des événements de modification de commande depuis Salesforce vers une application d'intégration. L'application synchronise ensuite les modifications dans le système ERP |
| Procédures d'intégration Omnistudio | Bien | Utilisez les procédures d'intégration Omnistudio pour automatiser par déclaration les interactions de données entre Salesforce et des applications tierces externes. Les procédures d'intégration gèrent les transformations de données complexes, les appels d'API et l'automatisation pilotée par l'événement, et peuvent exécuter plusieurs actions dans un seul appel au serveur. Utilisez des procédures d'intégration lorsqu'aucune interaction utilisateur n'est requise pendant l'exécution et que vous souhaitez :
Consultez plus de détails sur les procédures d'intégration ici. |
| Événements de plate-forme pilotés par la personnalisation | Bien | Semblable aux événements de plate-forme pilotés par le flux, mais les événements sont créés par des déclencheurs Apex ou des classes. Vous pouvez publier et consommer des événements de plate-forme en utilisant Apex ou une API. Les événements de plate-forme s'intègrent à la plate-forme Salesforce via des déclencheurs Apex. Les déclencheurs sont les consommateurs d'événements sur Salesforce Platform qui écoutent les messages d'événements. Lorsqu'une application externe utilise l'API ou qu'une application Salesforce native utilise Apex pour publier le message d'événement, un déclencheur sur cet événement est déclenché. Les déclencheurs exécutent les actions en réponse aux notifications d'événement. |
| Messagerie sortante pilotée par le flux | Ajustement | La solution recommandée pour ce type d'intégration est lorsque le processus distant est invoqué à partir d'un événement insert ou update. Salesforce fournit une capacité de messagerie sortante pilotée par le flux qui permet d'envoyer des messages SOAP à des systèmes distants déclenchés par une opération d'insertion ou de mise à jour dans Salesforce. Ces messages sont envoyés de façon asynchrone et sont indépendants de l'interface utilisateur de Salesforce. Le message sortant est envoyé à un point de terminaison distant spécifique. Le service distant doit pouvoir participer à une intégration Priorité au contrat dans laquelle Salesforce fournit le contrat. À la réception du message, si le service distant ne répond pas avec un accusé de réception positif, Salesforce tente de nouveau d'envoyer le message, en fournissant une forme de livraison garantie. |
| Composant Lightning personnalisé qui initie un appel externe asynchrone Apex SOAP ou HTTP | Suboptimal | Cette solution est généralement utilisée dans des scénarios basés sur l'interface utilisateur, mais nécessite une personnalisation. De plus, la solution doit gérer la livraison garantie du message dans le code. De la même façon que la solution du schéma Invocation de processus distant - Demande et réponse qui spécifie l'utilisation d'un composant Lightning, avec un appel externe Apex. La différence est que dans ce schéma, Salesforce n'attend pas la fin de la requête avant de transférer le contrôle à l'utilisateur. Après avoir reçu le message, le système distant répond et indique la réception du message, puis traite le message de façon asynchrone. Le système distant renvoie le contrôle à Salesforce avant de commencer à traiter le message. Par conséquent, Salesforce n'a pas à attendre la fin du traitement. |
| Déclencheurs Apex pour passer un appel externe asynchrone SOAP Apex ou HTTP | Suboptimal | Vous pouvez utiliser des déclencheurs Apex pour effectuer une automatisation basée sur les modifications des données d'enregistrement. Une classe proxy Apex peut être exécutée à la suite d'une opération DML en utilisant un déclencheur Apex. Cependant, tous les appels passés depuis le contexte du déclencheur doivent être exécutés de façon asynchrone. |
| Déclencheurs Apex pour passer un appel externe asynchrone SOAP Apex ou HTTP | Suboptimal | Les appels à un système distant peuvent être effectués à partir d'une tâche par lot. Cette solution permet l'exécution de processus distants par lot et le traitement de la réponse du système distant dans Salesforce. Cependant, le nombre d'appels pour un contexte de lot donné est limité. Pour plus d'informations, consultez Référence rapide Salesforce Developer Limits and Allocations.
|
Diagramme de téléchargementDans ce scénario :
- Un système distant s'abonne à l'événement de plate-forme.
- Une mise à jour ou une insertion est effectuée dans un ensemble d'enregistrements donné dans Salesforce.
- Un flux Salesforce se déclenche lorsqu'un ensemble de conditions est rempli.
- Ce flux crée un événement de plate-forme.
- L'écouteur distant reçoit le message d'événement et le place dans une file d'attente locale.
- L'application en file d'attente transmet le message à l'application distante pour traitement.
- Invocations de processus distants initiées par l'interface utilisateur dans lesquelles le résultat de la transaction peut être affiché pour l'utilisateur
- Invocations de processus distant initiées par un événement DML dans lesquelles le résultat de la transaction peut être traité par le processus appelant
| Mécanisme d'appel | Description |
|---|---|
| Flux | Utilisé par les solutions pilotées par les processus et pilotées par la personnalisation. Les événements déclenchent le processus Salesforce, qui peut ensuite publier un événement de plate-forme pour l'abonnement par un système distant. |
| Pub / Sub API | L'API Pub/Sub fournit une interface unique pour la publication et l'abonnement à des événements de plate-forme, y compris des événements de surveillance des événements en temps réel, et des événements de capture des données de modification. Basée sur gRPC et HTTP/2, l'API Pub/Sub publie et livre efficacement des messages d'événement binaires sous le format Apache Avro. |
| Capture des données modifiées | Salesforce Capture des données de modification publie des événements de modification, qui représentent les modifications apportées aux enregistrements Salesforce. Les modifications comprennent la création d'un enregistrement, la mise à jour d'un enregistrement existant, la suppression d'un enregistrement et l'annulation de la suppression d'un enregistrement. |
| Composant Lightning et contrôleurs Apex | Utilisé pour invoquer un processus distant de façon asynchrone en utilisant un appel externe Apex. |
| Messagerie sortante pilotée par le flux | Utilisé uniquement pour la solution de messagerie sortante. Les événements DML Créer et Mettre à jour déclenchent les règles de workflow Salesforce, qui peuvent ensuite envoyer un message à un système distant. |
| Déclencheurs Apex | Utilisé pour les événements de plate-forme pilotés par le déclencheur et l'invocation de processus distants, en utilisant des appels externes Apex depuis des événements initiés par DML. |
| Classes par lot Apex | Utilisé pour l'invocation de processus distants en mode batch. |
| Solution | Gestion des erreurs et stratégie de récupération |
|---|---|
| Flux |
|
| Appels Apex |
|
| Capture des données de modification (CDC) / Événements de plate-forme |
|
| Solution | Considérations relatives à la sécurité |
|---|---|
| Appels Apex | Un appel à un système distant doit préserver la confidentialité, l'intégrité et la disponibilité de la demande. Les considérations de sécurité suivantes sont spécifiques à l'utilisation d'appels SOAP Apex et HTTP dans ce schéma.
|
| Capture des données de modification (CDC) / Événements de plate-forme | Pour les événements de plate-forme, le système externe abonné doit pouvoir s'authentifier à l'API Salesforce Streaming. Les événements de plate-forme sont conformes au modèle de sécurité existant configuré dans l'organisation Salesforce. Pour s'abonner à un événement, l'utilisateur doit avoir accès en lecture à l'entité de l'événement. Pour publier un événement, l'utilisateur doit disposer de l'autorisation « créer » sur l'entité de l'événement. |
| Solution | Considérations relatives aux points de terminaison |
|---|---|
| Appels externes SOAP Apex | Le point de terminaison doit pouvoir traiter un appel de service Web via HTTP. Salesforce doit pouvoir accéder au point de terminaison sur l'Internet public. Cette solution nécessite que le système distant soit compatible avec les normes prises en charge par Salesforce. Au moment d'écrire ces lignes, les normes de service Web prises en charge par Salesforce pour les appels externes SOAP Apex sont les suivantes:
|
| Appels externes HTTP Apex | Le point de terminaison doit pouvoir recevoir des appels HTTP et être accessible sur l'Internet public par Salesforce. Les appels externes HTTP Apex peuvent être utilisés pour appeler des services RESTful en utilisant les méthodes standard GET, POST, PUT et DELETE. |
| Capture des données de modification (CDC) / Événements de plate-forme |
|
- Salesforce stocke la clé de substitution primaire ou unique du système distant pour l'enregistrement distant.
- Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique.
| Maître | Système Description |
|---|---|
| Salesforce | Le système distant doit stocker le RecordId Salesforce ou une autre clé de substitution unique dans l'enregistrement Salesforce. |
| Système distant | Salesforce doit stocker une référence à l'identificateur unique dans le système distant. Comme le processus est asynchrone, le stockage de cet identifiant unique ne peut pas faire partie de la transaction d'origine. Salesforce doit fournir un ID unique dans l'appel au processus distant. Le système distant doit ensuite rappeler Salesforce pour mettre à jour l'enregistrement dans Salesforce avec l'identifiant unique du système distant, en utilisant l'ID unique Salesforce. Le rappel implique un traitement d'état spécifique dans l'application distante pour stocker l'identificateur unique Salesforce de cette transaction à utiliser pour le rappel lorsque le traitement est terminé, ou l'identificateur unique Salesforce est stocké dans l'enregistrement du système distant. |
| Solution | Considérations |
|---|---|
| Appels Apex | Dans certains cas, les solutions prescrites par ce schéma nécessitent d'implémenter plusieurs scénarios d'intégration complexes mieux servis en utilisant un middleware ou en demandant à Salesforce d'appeler un service composé. Ces scénarios comprennent :
|
| Capture des données de modification (CDC) / Événements de plate-forme | Étant donné la nature statique et déclarative des événements, aucun scénario d'intégration complexe, tel que l'agrégation, l'orchestration ou la transformation, ne peut être exécuté dans Salesforce. Le système distant ou middleware doit gérer ces types d'opération. |
| Procédures d'intégration OmniStudio | Les procédures d'intégration (OmniStudio) fournissent une orchestration sans état côté serveur pour coordonner plusieurs services back-end tout en exécutant des transformations de données complexes et déclaratives. Les procédures d'intégration enchaînent les étapes telles que les actions HTTP, l'extraction/transformation/chargement de DataRaptor, les références Définir des valeurs, Boucle/Si et Matrice pour normaliser, enrichir, agréger et mapper des charges utiles entre des contrats d'interface utilisateur et des API disparates. Ils prennent en charge des contrôles d'exécution robustes tels que la branchement conditionnel, la pagination, les expirations, les tentatives, le traitement des échecs partiels et la continuité des erreurs, ainsi que des optimisations des performances telles que la mise en cache côté serveur et la mise en forme des réponses. Les adresses IP peuvent être invoquées de façon synchrone à partir d'OmniScripts, ou headless via REST, ce qui active des « façades d'intégration » réutilisables et versionnées qui masquent la complexité back-end des canaux. |
| Solution | Considérations relatives à la messagerie fiable |
|---|---|
| Appels Apex | Salesforce ne prend pas explicitement en charge les protocoles de messagerie fiables (par exemple, WS-ReliableMessaging). Nous recommandons que le point de terminaison distant recevant le message Salesforce implémente un système de messagerie fiable, tel que JMS ou MQ. Ce système garantit une livraison complète et complète au système distant qui traite le message. Cependant, ce système ne garantit pas la livraison depuis Salesforce vers le point de terminaison distant qu'il appelle. La livraison garantie doit être gérée par des personnalisations dans Salesforce. Des techniques spécifiques, telles que le traitement d'un accusé de réception positif à partir du point de terminaison distant en plus d'une logique de nouvelle tentative personnalisée, doivent être implémentées. |
| Capture des données de modification (CDC) / Événements de plate-forme | Événements de plate-forme tente de fournir une messagerie fiable en maintenant temporairement les messages d'événement dans le bus d'événement. Les abonnés peuvent rattraper les messages d'événement manqués en relisant les messages depuis le bus d'événement en utilisant l'ID de relecture des messages d'événement. Le bus d'événement est un système distribué et n'offre pas les mêmes garanties qu'une base de données transactionnelle. Par conséquent, Salesforce ne peut pas fournir une réponse synchrone pour une requête de publication d'événement. Les événements sont mis en file d'attente et mis en mémoire tampon, et Salesforce tente de les publier de façon asynchrone. Dans de rares cas, le message d'événement peut ne pas être conservé dans le système distribué lors de la tentative initiale ou ultérieure. Cela signifie que les événements ne sont pas livrés aux abonnés et qu'ils ne peuvent pas être récupérés. |
| Propriété | Obligatoire | Désirable | Non requis |
|---|---|---|---|
| Traitement des événements | X | ||
| Conversion du protocole | X | ||
| Traduction et transformation | X | ||
| Mise en file d'attente et tampon | X | ||
| Protocoles de transport synchrones | X | ||
| Protocoles de transport asynchrones | X | ||
| Acheminement de la médiation | X | ||
| Chorégraphie de processus et orchestration de service | X | ||
| Transactionnalité (cryptage, signature, livraison fiable, gestion des transactions) | X | ||
| Acheminement | X | ||
| Extraire, transformer et charger | X | ||
| sondage long | X (obligatoire pour les événements de plate-forme) |
- Publier après l'engagement pour publier le message d'événement uniquement lorsqu'une transaction est engagée avec succès. Sélectionnez cette option si les abonnés dépendent des données que la transaction de publication engage. Par exemple, un processus publie un message d'événement et crée un enregistrement de tâche. Un deuxième processus abonné à l'événement est déclenché et attend de retrouver l'enregistrement de la tâche. Une autre raison pour laquelle vous choisissez ce comportement est lorsque vous ne souhaitez pas publier le message d'événement en cas d'échec de la transaction.
- Publiez immédiatement pour publier le message d'événement lors de l'exécution de l'appel de publication. Sélectionnez cette option si vous souhaitez publier le message d'événement, que la transaction réussisse ou non. Choisissez également cette option si l'éditeur et les abonnés sont indépendants et que les abonnés ne dépendent pas des données engagées par l'éditeur. Par exemple, le comportement de publication immédiate convient à un événement utilisé à des fins de consignation. Avec cette option, un abonné peut recevoir le message d'événement avant l'engagement des données par la transaction de l'éditeur.
- Seul le développement déclaratif peut être mis en œuvre.
- Il n'est pas nécessaire de notifier immédiatement le numéro de commande après la conversion de l'opportunité en commande.
- L'organisation a un ESB qui prend en charge le protocole CometD et peut s'abonner à des événements de plate-forme.
- Créez un flux pour initier l'événement de plate-forme (par exemple, lorsque le statut de l'opportunité change en Close-Won).
- Créez un événement de plate-forme qui publie les détails de l'opportunité.
- L'ESB s'abonne à l'événement de plate-forme Salesforce en utilisant le protocole CometD.
- L'ESB reçoit une ou plusieurs notifications indiquant que l'opportunité doit être convertie en commande.
- L'ESB transmet le message au système ERP back-end pour que la commande puisse être créée.
- Une fois la commande créée dans le système ERP, un thread séparé rappelle Salesforce en utilisant SessionId comme jeton d'authentification. Le rappel met à jour l'opportunité avec le numéro de commande et le statut. Vous pouvez effectuer ce rappel en utilisant des solutions de schéma documentées, telles que des événements de plate-forme Salesforce, l'API SOAP Salesforce, l'API REST ou un service Web Apex.
- Implémentation d'un processus distant invoqué de façon asynchrone
- Livraison garantie de bout en bout
- Rappel ultérieur à Salesforce pour mettre à jour l'état de l'enregistrement
- Extrayez et transformez les comptes, les contacts et les opportunités du système CRM actuel, puis chargez les données dans Salesforce (importation initiale des données).
- Extrayez, transformez et chargez des données de facturation client dans Salesforce à partir d'un système distant sur une base hebdomadaire (en continu).
- Extrayez les informations sur l'activité des clients de Salesforce et importez-les dans un entrepôt de données sur site sur une base hebdomadaire (en continu).
- Les données doivent-elles être stockées dans Salesforce ? Sinon, il existe d'autres options d'intégration qu'un architecte peut et doit prendre en compte (les mashups, par exemple).
- Si les données doivent être stockées dans Salesforce, les données doivent-elles être actualisées en réponse à un événement dans le système distant ?
- Les données doivent-elles être actualisées à une fréquence planifiée ?
- Les données prennent-elles en charge les processus métiers principaux ?
- Existe-t-il des exigences en matière d'analyse (rapports) qui sont impactées par la disponibilité de ces données dans Salesforce ?
| Solution | Ajustement | Maître de données | Commentaires |
|---|---|---|---|
| Réplication via un outil ETL tiers | Meilleur | Système distant | Lorsqu'un système externe doit envoyer une grande quantité de données dans Salesforce, tirez parti d'un outil ETL tiers qui permet d'exécuter la capture des données de modification par rapport aux données sources. L'outil réagit aux modifications du jeu de données source, transforme les données, puis appelle l'API de transfert en masse Salesforce pour émettre des instructions DML. Cela peut également être implémenté en utilisant les API REST Salesforce si le nombre d'enregistrements est inférieur. |
| Réplication via un outil ETL tiers | Bien | Salesforce | Tirez parti d'un outil ETL tiers qui permet d'exécuter la capture des données de modification par rapport aux jeux de données ERP et Salesforce. Dans cette solution, Salesforce est la source de données et vous pouvez utiliser les informations de temps/statut sur des lignes individuelles pour interroger les données et filtrer l'ensemble de résultats cible. Cela peut être implémenté en utilisant l'API de transfert en masse 2.0 ou des API REST standard (si le nombre d'enregistrements est inférieur à ). |
| Assistant d'importation de données et Data Loader | Ajustement | Salesforce / Système externe | L'assistant d'importation de données et Data Loader peuvent être utilisés pour importer, exporter et migrer des données. Les commandes Data Loader peuvent également être scriptées pour automatiser l'importation et l'exportation de données, mais l'interface de ligne de commande est uniquement pour Windows. Aucun de ces outils n'est recommandé pour une stratégie d'intégration de données. Ils doivent à la place compléter votre stratégie de gestion et de maintenance des données. Pour plus d'informations sur Data Loader, reportez-vous ici. |
| Appel distant | Suboptimal | Système distant | Il est possible pour un système distant d'appeler dans Salesforce en utilisant l'une des API et d'effectuer des mises à jour des données au fur et à mesure. Cependant, cela entraîne un trafic continu considérable entre les deux systèmes. Il convient de mettre davantage l'accent sur le traitement des erreurs et le verrouillage. Ce schéma peut entraîner des mises à jour continues, ce qui peut impacter les performances des utilisateurs. |
| Invocation de processus distant | Suboptimal | Salesforce | Salesforce peut appeler un système distant et mettre à jour les données au fur et à mesure. Cependant, cela entraîne un trafic continu considérable entre les deux systèmes. Il convient de mettre davantage l'accent sur le traitement des erreurs et le verrouillage. Ce schéma peut entraîner des mises à jour continues, ce qui peut impacter les performances des utilisateurs. |
Diagramme de téléchargementLe diagramme suivant illustre la synchronisation ultérieure des événements en temps quasi réel, où Salesforce est le maître des données.
**Résultats**
Vous pouvez intégrer des données provenant de sources externes à Salesforce dans les scénarios suivants :
- Le système externe est le principal des données : Salesforce est un consommateur de données fournies par un système source unique ou plusieurs systèmes. Dans ce scénario, il est courant d'avoir un entrepôt de données ou un datamart qui agrège les données avant leur importation dans Salesforce.
- Salesforce est le maître des données : Salesforce est le système d'enregistrement de certaines entités et les applications clientes Capture des données de modification Salesforce peuvent être informées des modifications apportées aux données Salesforce.
- Implémentez la capture des données de modification dans le jeu de données source.
- Implémentez une série de structures de base de données de support, appelées tableaux de contrôle, dans une base de données intermédiaire sur site.
- Lisez un tableau de contrôle pour déterminer l'heure de dernière exécution de la tâche et extraire les autres valeurs de contrôle requises.
- Utilisez les valeurs de contrôle ci-dessus comme filtres et interrogez le jeu de données source.
- Appliquez des règles de traitement prédéfinies, notamment la validation, l'enrichissement, etc.
- Utilisez les connecteurs et les capacités de transformation disponibles de l'outil ETL pour créer le jeu de données de destination.
- Écrivez le jeu de données dans des objets Salesforce.
- Si le traitement réussit, mettez à jour les valeurs de contrôle dans le tableau de contrôle.
- Si le traitement échoue, mettez à jour les tableaux de contrôle avec des valeurs qui activent un redémarrage et une sortie.
- Enchaînez et séquencez les tâches ETL pour fournir un processus cohérent.
- Utilisez les clés primaires des deux systèmes pour mapper les données entrantes.
- Utilisez des méthodes d'API spécifiques pour extraire uniquement les données mises à jour.
- Si vous importez des enregistrements enfants dans une relation principal-détails ou de référence, regroupez les données importées en utilisant leur clé parente à la source pour éviter le verrouillage. Par exemple, si vous importez des données de contact, assurez-vous de regrouper les données de contact par clé de compte parent afin de charger le nombre maximal de contacts pour un seul compte dans un seul appel d'API. L'échec du regroupement des données importées entraîne généralement le chargement du premier enregistrement de contact et l'échec des enregistrements de contact suivants pour ce compte dans le contexte de l'appel d'API.
- Tout traitement postérieur à l'importation, par exemple les déclencheurs, ne doit traiter les données que de façon sélective.
- Si votre scénario implique des volumes de données importants, suivez les meilleures pratiques de ce module Trailhead Best Practices for Deployments with Large Data Volumes .
| Emplacement de l'erreur | Gestion des erreurs et stratégie de reprise |
|---|---|
| Lire depuis Salesforce en utilisant Capture des données de modification |
|
| Lire depuis Salesforce en utilisant un système ETL tiers |
|
| Écrire à Salesforce |
|
| Système principal externe | Les erreurs doivent être traitées conformément aux meilleures pratiques du système principal. |
- Une licence Lightning Platform avec au moins les autorisations utilisateur « API uniquement » est requise pour autoriser l'accès API authentifié à l'API Salesforce.
- Nous recommandons d'utiliser le cryptage standard pour sécuriser l'accès par mot de passe.
- Utilisez le protocole HTTPS pour passer des appels aux API Salesforce. Vous pouvez également proxyer le trafic vers les API Salesforce via une solution de sécurité sur site, si nécessaire.
- Salesforce ne conserve pas l'état d'un enregistrement modifié par un utilisateur spécifique.
- À la lecture, il enregistre l'heure à laquelle les données ont été extraites.
- Si l'utilisateur met à jour l'enregistrement et l'enregistre, Salesforce vérifie si un autre utilisateur a mis à jour l'enregistrement entre-temps.
- Si l'enregistrement a été mis à jour, le système notifie l'utilisateur qu'une mise à jour a été effectuée et l'utilisateur doit récupérer la dernière version de l'enregistrement avant de procéder à ses mises à jour.
| Propriété | Obligatoire | Désirable | Non requis |
|---|---|---|---|
| Traitement des événements | X | ||
| Conversion du protocole | X | ||
| Traduction et transformation | X | ||
| Mise en file d'attente et tampon | X | ||
| Protocoles de transport synchrones | X | ||
| Protocoles de transport asynchrones | X | ||
| Acheminement de la médiation | X | ||
| Chorégraphie de processus et orchestration de service | X | ||
| Transactionnalité (cryptage, signature, livraison fiable, gestion des transactions) | X | ||
| Acheminement | X | ||
| Extraire, transformer et charger | X | ||
| Sondage long | X (obligatoire pour Capture des données de modification Salesforce) |
- Un planificateur de type cron exécute une tâche par lot qui attribue des prospects aux utilisateurs et aux équipes.
- Après l'exécution de la tâche par lot et la mise à jour des données, l'outil ETL reconnaît ces modifications par capture des données modifiées. L'outil ETL regroupe les modifications du magasin de données.
- Le connecteur ETL utilise l'API REST Salesforce pour charger les modifications dans Salesforce.
- L'appel distant à Salesforce a-t-il pour but de notifier Salesforce d'un événement qui s'est produit en externe en utilisant une architecture pilotée par l'événement ? Ou bien l'objectif est d'effectuer des opérations CRUD sur des enregistrements spécifiques ? Si vous utilisez une architecture pilotée par l'événement, le producteur d'événement (le processus distant) est découplé du consommateur d'événement Salesforce.
- L'appel à Salesforce nécessite-t-il que le processus distant attende une réponse avant de poursuivre le traitement ? Les appels distants à Salesforce sont toujours des requêtes-réponses synchrones, bien que le processus distant puisse abandonner la réponse s'il n'est pas nécessaire de simuler un appel asynchrone.
- Chaque transaction fonctionne-t-elle avec un seul objet Salesforce ou plusieurs objets associés ?
- Quel est le format du message (par exemple, SOAP ou REST, ou les deux sur HTTP) ?
- La taille du message est-elle relativement petite ou grande ?
- Si le système distant est compatible SOAP, le système distant peut-il participer à une approche axée sur le contrat, dans laquelle Salesforce dicte le contrat ? Elle est requise lorsque notre API SOAP est utilisée, pour laquelle un WSDL prédéfini est fourni.
- Le traitement des transactions est-il requis ?
- Dans quelle mesure tolérez-vous la personnalisation dans Salesforce ?
| Solution | Ajustement | Commentaires |
|---|---|---|
| API composée | Meilleur | Salesforce fournit une API composite qui est essentiellement une API REST et prend en charge les requêtes composées. Il peut être utilisé par des systèmes distants pour :
API synchrone : une fois l'appel d'API passé, l'application cliente distante attend de recevoir une réponse du service. Comportement de transaction/engagement : par défaut, l'API composite ne permet pas une réussite partielle si certains enregistrements sont marqués avec des erreurs. Cela peut être changé en marquant l'indicateur « tout ou rien » comme faux, ce qui permettra une réussite partielle. Traitement des erreurs : Le traitement approprié des erreurs doit examiner le corps de réponse, pas seulement les codes de statut HTTP. Un point de terminaison composite répond avec un code de statut HTTP 200, même si dans le corps de réponse il indique que l'une des sous-requêtes a échoué et que la transaction a dû être annulée. |
| API REST | Meilleur | Accessibilité : Salesforce fournit une API REST que les systèmes distants peuvent utiliser pour :
API synchrone : une fois l'appel d'API passé, l'application cliente distante attend de recevoir une réponse du service. L'API REST respecte la sécurité au niveau de l'objet et au niveau du champ configurée dans Salesforce en fonction du profil de l'utilisateur connecté. REST expose les ressources (entités/objets) sous forme d'URI et utilise des verbes HTTP pour définir des opérations CRUD sur ces ressources. Contrairement à SOAP, l'API REST ne nécessite aucun contrat prédéfini, utilise XML et JSON pour les réponses et a une saisie libre. L'API REST est légère et offre une méthode simple pour interagir avec Salesforce. Ses avantages comprennent la facilité d'intégration et de développement, et il est un excellent choix pour l'utilisation avec des applications mobiles et des applications Web. Comportement de transaction/engagement : par défaut, chaque enregistrement est traité comme une transaction séparée et engagé séparément. L'échec d'une modification d'enregistrement n'entraîne pas l'annulation d'autres modifications. Ce comportement peut être modifié en comportement « tout ou rien ». Utilisez les ressources composées de l'API REST pour effectuer une série de mises à jour en un seul appel d'API. Données en masse : toute opération de données qui contient plus de 2000 enregistrements est un bon candidat pour l'API de transfert en masse 2.0 afin de préparer, d'exécuter et de gérer avec succès un workflow asynchrone qui utilise l'infrastructure de transfert en masse. |
| API de transfert en masse 2.0 | Idéal pour les opérations en masse | L'API de transfert en masse 2.0 est l'API moderne et rationalisée de Salesforce pour gérer les opérations de données à grande échelle. L'API de transfert en masse 2.0 basée sur REST fournit une option par programmation pour insérer, mettre à jour/insérer, interroger ou supprimer de façon asynchrone des jeux de données volumineux dans votre organisation Salesforce. Il est conçu pour plus d'efficacité lorsque vous devez charger de grandes quantités de données dans Salesforce ou effectuer des requêtes en masse sur les données de votre organisation. Contrairement à l'API de transfert en masse 1.0, l'API de transfert en masse 2.0 traite toujours les lots en parallèle et ne prend pas en charge le mode série. Cela signifie que :
Chaque lot de l'API de transfert en masse 2.0 est traité comme sa propre transaction. Cela signifie :
Bien que l'API SOAP puisse également être utilisée pour traiter un grand nombre d'enregistrements, elle devient moins optimale lorsque les jeux de données contiennent des centaines de milliers à des millions d'enregistrements. Cela est dû à ses caractéristiques de frais généraux relativement élevés et de performance inférieure.
|
| API Pub/Sub | Meilleur |
L'API Pub/Sub est le moyen recommandé pour les éditeurs externes de publier des événements dans le Bus d'événements. L'API Pub/Sub est une API basée sur gRPC qui permet aux systèmes externes de publier des événements de plate-forme. L'API Pub/Sub :
Lorsqu'un événement de plate-forme est défini dans Salesforce, il devient disponible pour les consommateurs internes et externes. |
| Événements de plate-forme | Meilleur |
Les événements de plate-forme sont définis de la même façon que vous définissez les objets Salesforce. Les événements de plate-forme peuvent être publiés en utilisant différents mécanismes tels que les API REST, l'API de transfert en masse et les API SOAP.
La publication d'un événement via l'API REST revient à créer un enregistrement Salesforce. Format du point de terminaison : POST /services/data/vXX.X/sobjects/EventName__e/
Avec l'API de transfert en masse, seules les opérations de création et d'insertion sont prises en charge. Les événements d'un lot sont publiés dans le bus d'événement Salesforce de façon asynchrone à mesure que la tâche par lot est traitée. Les événements de plate-forme étant des SObjects, les opérations d'API SOAP standard sont prises en charge. |
| API SOAP | Ajustement |
Accessibilité : Salesforce fournit une API SOAP que les systèmes distants peuvent utiliser pour :
API synchrone : une fois l'appel d'API passé, l'application cliente distante attend de recevoir une réponse du service. Les appels asynchrones à Salesforce ne sont pas pris en charge. WSDL généré : Salesforce fournit deux WSDL pour des systèmes distants :
Sécurité : le client qui exécute l'API SOAP doit avoir une connexion valide et obtenir une session pour effectuer des appels d'API. L'API respecte la sécurité au niveau de l'objet et au niveau du champ configurée dans Salesforce en fonction du profil de l'utilisateur connecté. Comportement de transaction/engagement : par défaut, chaque appel d'API permet une réussite partielle si certains enregistrements sont marqués avec des erreurs. Il peut être modifié en comportement « tout ou rien » dans lequel tous les résultats sont annulés en cas d'erreur. Il n'est pas possible d'étendre une transaction à plusieurs appels d'API. Pour surmonter cette limitation, un seul appel d'API peut affecter plusieurs objets. |
| Services Web Apex | Suboptimal |
Les méthodes de classe Apex peuvent être exposées en tant que méthodes de service Web à des applications externes. Cette méthode est une alternative à l'API SOAP, et est généralement utilisée uniquement lorsque les exigences supplémentaires ci-dessous doivent être remplies.
L'avantage d'utiliser un service Web Apex doit être mis en balance avec le code supplémentaire qui doit être maintenu dans Salesforce. Non applicable aux événements de plate-forme, car la logique de pré-insertion de transaction chez le consommateur ne s'applique pas dans un architecture pilotée par l'événement. Pour notifier une organisation Salesforce d'un événement, utilisez l'API SOAP, l'API REST ou l'API de transfert en masse 2.0. |
| Services REST Apex | Suboptimal |
Une classe Apex peut être exposée sous forme de ressources REST mappées avec des URI spécifiques avec un verbe HTTP défini (par exemple, POST ou GET).
Vous pouvez utiliser les ressources composées de l'API REST pour effectuer plusieurs mises à jour dans une seule transaction. Contrairement à SOAP, il n'est pas nécessaire que le client consomme une définition de service/un contrat (WSDL) et génère des stubs client. Le système distant nécessite uniquement la capacité de former une requête HTTP et de traiter les résultats renvoyés (XML ou JSON). Non applicable aux événements de plate-forme, car la logique de pré-insertion de transaction chez le consommateur ne s'applique pas dans un architecture pilotée par l'événement. Pour notifier une organisation Salesforce d'un événement, utilisez l'API SOAP, l'API REST ou l'API de transfert en masse 2.0. |
_Système distant notifiant Salesforce avec des événements via l'API REST_
**Résultats**
Dans une architecture pilotée par l'événement, le système distant appelle Salesforce en utilisant l'API SOAP, l'API REST ou l'API de transfert en masse 2.0 pour publier un événement dans le bus d'événement Salesforce. La publication d'un événement notifie tous les abonnés. Les abonnés aux événements peuvent être sur Salesforce Platform tels que des flux, ou des composants Lightning, des déclencheurs Apex. Les abonnés aux événements peuvent également être externes à Salesforce Platform, par exemple des abonnés CometD.
Lors de l'utilisation directe d'objets Salesforce, les solutions associées à ce schéma permettent de :
- Le système distant appelle les API Salesforce pour interroger la base de données et exécuter des opérations sur un seul objet (créer, mettre à jour, supprimer, etc.).
- Le système distant qui appelle les ressources composées de l'API REST Salesforce pour effectuer une série d'opérations sur des objets.
- Système distant pour appeler des API Salesforce (services) personnalisées qui peuvent prendre en charge les opérations transactionnelles multi-objets et la logique de traitement préalable/post personnalisé.
| Mécanisme d'appel | Description |
|---|---|
| API SOAP | Le système distant utilise le WSDL Salesforce Enterprise ou Partner pour générer des stubs clients qui sont ensuite utilisés pour invoquer l'API SOAP standard. |
| API REST | Le système distant doit s'authentifier avant d'accéder à un service REST Apex. Le système distant peut utiliser OAuth 2.0 ou l'authentification par nom d'utilisateur et mot de passe. Dans les deux cas, le client doit définir l'en-tête HTTP d'autorisation avec la valeur appropriée (un jeton d'accès OAuth ou un ID de session peut être acquis via un appel de connexion à l'API SOAP). Le système distant génère ensuite des invocations REST (requêtes HTTP) avec les verbes appropriés et traite les résultats renvoyés (les formats de données JSON et XML sont pris en charge). |
| Service Web Apex | Le système distant consomme le service Web Apex personnalisé WSDL pour générer des stubs clients qui sont à leur tour utilisés pour invoquer le service Web Apex personnalisé. |
| Service REST Apex | Selon l'API REST, l'URI de la ressource et les verbes applicables sont définis en utilisant les annotations @RestResource, @HttpGet et @HttpPost. |
| API de transfert en masse 2.0 | L'API de transfert en masse 2.0 est une API basée sur REST. Par conséquent, les mêmes mécanismes d'appel que l'API REST s'appliquent. |
| API REST pour invoquer un flux | Utilisez l'API REST pour appeler un point de terminaison d'actions invocables personnalisées afin d'invoquer un flux lancé automatiquement. |
- Gestion des erreurs : toutes les méthodes d'appel distant, API standard ou personnalisées, nécessitent que le système distant gère les erreurs ultérieures, telles que les expirations et la gestion des tentatives. Middleware peut être utilisé pour fournir la logique de traitement des erreurs et de récupération.
- Récupération : un mécanisme de nouvelle tentative personnalisé doit être créé si les exigences de qualité de service l'exigent. Dans ce cas, il est important de garantir des caractéristiques de conception idempotentes. L'événement de plate-forme permet aux abonnés d'utiliser l'ID de relecture pour récupérer les messages pendant une période donnée après leur publication.
| Solution | Considérations de sécurité |
|---|---|
| API SOAP | alesforce prend en charge les protocoles SSL (Secure Sockets Layer v3) et TLS (Transport Layer Security). Les chiffrements doivent avoir une longueur de clé d'au moins 128 bits. Le système distant doit se connecter en utilisant des identifiants valides pour obtenir un ID de session. Si le système distant a déjà un ID de session valide, il peut appeler l'API sans connexion explicite. Il est utilisé dans les schémas de rappel décrits précédemment dans ce document, où un message sortant Salesforce précédent contenait un ID de session et un ID d'enregistrement pour une utilisation ultérieure. Nous recommandons aux clients qui appellent le cache de l'API SOAP et réutilisent l'ID de session pour optimiser les performances, plutôt que d'obtenir un nouvel ID de session pour chaque appel. |
| API REST | Nous recommandons au système distant d'établir un Trust OAuth pour l'autorisation. Des appels REST peuvent ensuite être effectués sur des ressources spécifiques en utilisant des verbes HTTP. Il est également possible de passer des appels REST avec un ID de session valide qui peut avoir été obtenu par d'autres moyens (par exemple, récupéré en appelant l'API SOAP ou fourni via un message sortant). Nous recommandons aux clients qui appellent le cache de l'API REST et réutilisent l'ID de session pour optimiser les performances, plutôt que d'obtenir un nouvel ID de session pour chaque appel. |
| Service Web Apex | Nous recommandons au système distant d'établir un Trust OAuth pour l'autorisation. |
| Service REST Apex | Nous recommandons au système distant d'établir un Trust OAuth pour l'autorisation. |
| API de transfert en masse 2.0 | Nous recommandons au système distant d'établir un Trust OAuth pour l'autorisation. |
- Expiration de la session : la session expire en l'absence d'activité basée sur le paramètre d'expiration de session de l'organisation Salesforce.
- Expiration de la requête : chaque requête SOQL a une limite d'expiration individuelle de 120 secondes.
| Solution | Type de communication | Limites |
|---|---|---|
| API SOAP ou API REST | Synchrone |
|
| API de transfert en masse 2.0 | Asynchrone | L'API de transfert en masse 2.0 est optimisée pour l'importation et l'exportation asynchrones de jeux de données volumineux. Toute opération de données qui inclut plus de 2000 enregistrements est un bon candidat pour l'API de transfert en masse 2.0 afin de préparer, d'exécuter et de gérer avec succès un workflow asynchrone qui utilise l'infrastructure de transfert en masse. Les tâches contenant moins de 2000 enregistrements doivent impliquer des appels synchrones « en masse » dans REST (par exemple, Composite) ou SOAP. L'API de transfert en masse 2.0 est synchrone lors de la soumission de la requête par lot et des données associées. Le traitement réel des données est asynchrone. Pour plus d'informations sur les limites en API et en traitement par lot, consultez Limites. |
| Solution | Considérations relatives au point de terminaison |
|---|---|
| API SOAP | Le système distant doit être capable d'implémenter un client capable d'appeler l'API SOAP Salesforce, sur la base d'un format de message prédéfini par Salesforce. Le système distant (client) doit participer à une mise en œuvre de premier ordre du contrat lorsque le contrat est fourni par Salesforce (par exemple, Enterprise ou Partner WSDL). |
| API REST | Le système distant doit pouvoir implémenter un client REST qui invoque des services REST définis par Salesforce et traite les résultats XML ou JSON. |
| Service Web Apex | Le système distant doit pouvoir implémenter un client capable d'invoquer des messages SOAP d'un format prédéfini, tel que défini par Salesforce. Le système distant doit participer à une implémentation code-first, dans laquelle le contrat est fourni par Salesforce après l'implémentation du service Web Apex. Chaque service Web Apex possède son propre WSDL. |
| Service REST Apex | Les mêmes considérations relatives au point de terminaison que l'API REST s'appliquent. |
- Salesforce stocke la clé de substitution primaire ou unique du système distant pour l'enregistrement distant.
- Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique. Il existe des considérations spécifiques pour gérer les clés d'intégration dans ce schéma synchrone.
| Maître | système Description |
|---|---|
| Salesforce | Dans ce scénario, le système distant stocke le RecordId Salesforce ou une autre clé de substitution unique de l'enregistrement. |
| Système distant | Dans ce scénario, Salesforce stocke une référence à l'identificateur unique dans le système distant. Comme le processus est synchrone, la clé peut être fournie dans le cadre de la même transaction en utilisant des champs ID externes. |
| Solution | Considérations |
|---|---|
| API SOAP ou API REST | L'API SOAP et l'API REST permettent de simples transactions sur des objets. Les scénarios d'intégration complexes, tels que l'agrégation, l'orchestration et la transformation, ne peuvent pas être exécutés dans Salesforce. Ces scénarios doivent être gérés par le système distant ou middleware, avec middleware comme méthode préférée. |
| Service Web Apex ou service REST Apex | Les services Web personnalisés peuvent fournir une fonctionnalité inter-objets, une logique personnalisée et une prise en charge des transactions plus complexe. Cette solution doit être utilisée avec précaution, et vous devez toujours considérer l'adéquation du middleware à une logique de transformation, d'orchestration et de traitement des erreurs. |
| Solution | Limites |
|---|---|
| API SOAP, API REST et API Apex personnalisées |
|
| API de transfert en masse 2.0 | Pour plus d'informations, consultez Menu latéral Volumes de données. |
| Événements de plate-forme |
|
| Propriété | Obligatoire | Désirable | Non requis |
|---|---|---|---|
| Traitement des événements | X | ||
| Conversion du protocole | X | ||
| Traduction et transformation | X | ||
| Mise en file d'attente et tampon | X | ||
| Protocoles de transport synchrones | X | ||
| Protocoles de transport asynchrones | X | ||
| Acheminement de la médiation | X | ||
| Chorégraphie de processus et orchestration de service | X | ||
| Transactionnalité (cryptage, signature, livraison fiable, gestion des transactions) | X | ||
| Acheminement | X | ||
| Extraire, transformer et charger | X (pour vrac/lots) |
- Le PMS peut participer à une intégration Priorité au contrat, dans laquelle Salesforce fournit le contrat et le PMS agit en tant que client (consommateur) du service Salesforce (défini via le WSDL Enterprise ou Partner).
- Il ne devrait pas y avoir de développement personnalisé dans Salesforce.
- Définissez un événement de plate-forme dans Salesforce pour inclure les données de notification provenant du PMS.
- Créez un flux déclenché par la notification d'événement d'imprimante. Le processus met à jour l'actif de l'imprimante et crée une commande (en utilisant un flux lancé automatiquement).
- Téléchargez le WSDL Enterprise ou Partner et fournissez-le au système distant.
- Créez un stub client à partir du WSDL Enterprise ou Partner.
- Authentifiez-vous à Salesforce (via un serveur Web OAuth ou un flux de jetons du porteur) en utilisant les identifiants de l'utilisateur de l'intégration.
- Lors d'un événement de statut d'imprimante, le PMS appelle l'API pour créer l'événement de plate-forme de statut d'imprimante (avec des statistiques d'utilisation d'imprimante). Le bus d'événement Salesforce notifie l'abonné au flux et tous les autres abonnés.
- Implémentation d'un client d'API synchrone Salesforce (consommateur).
- Un rappel à Salesforce pour publier un événement de plate-forme (conforme aux modèles d'événement de plate-forme de requêtes/réponses précédemment couverts).
**Résultats**
**Prestations**
L'application de la solution associée à ce schéma présente les avantages suivants:
- Élimine la nécessité d'écrire des mécanismes d'interrogation personnalisés
- Élimine la nécessité d'une boucle de rétroaction initiée par l'utilisateur
- La remise des notifications n'est pas garantie.
- L'ordre des notifications n'est pas garanti.
- Les notifications ne sont pas générées à partir des modifications apportées aux enregistrements par l'API de transfert en masse.
- Créez un déclencheur Apex PushTopic qui envoie un événement de plate-forme lorsqu'une requête est enregistrée avec un Statut « Fermé » et une Résolution « Réussi ».
- Créez une interface utilisateur personnalisée disponible pour les responsables du service client. Cette interface utilisateur s'abonne au bus d'événement pour consommer des événements de plate-forme.
- Implémentez une logique dans l'interface utilisateur personnalisée qui affiche les alertes générées par les agents du service client de ce responsable.
- Voulez-vous élaborer une intégration sortante déclarative/par pointer-cliquer ou un mashup d'interface utilisateur dans Salesforce ?
- Vous avez un volume de données important que vous ne souhaitez pas copier dans votre organisation Salesforce ?
- Avez-vous besoin d'accéder simultanément à de petites quantités de données système distantes ?
- Avez-vous besoin d'accéder en temps réel aux toutes dernières données ?
- Vous stockez vos données dans le cloud ou dans un système back-office, mais vous souhaitez afficher ou traiter ces données dans votre organisation Salesforce ?
- Vous avez des problèmes de résidence des données pour stocker certains types de données dans Salesforce ?
| Solution | Ajustement | Commentaires |
|---|---|---|
| Salesforce Connect | Meilleur | Utilisez Salesforce Connect pour accéder aux données de sources externes, avec vos données Salesforce. Extrayez en temps réel des données de systèmes tels que SAP, Microsoft, Oracle et d'autres systèmes basés sur le cloud tels que Snowflake sans copier les données dans Salesforce. Salesforce Connect mappe les tableaux de données de systèmes externes avec des objets externes de votre organisation. Les objets externes sont similaires aux objets personnalisés, mais ils sont mappés avec des données situées hors de votre organisation Salesforce. Salesforce Connect utilise une connexion live à des données externes pour toujours tenir les objets externes à jour. L'accès à un objet externe récupère en temps réel les données du système externe. Salesforce Connect permet de :
|
| Demande et réponse | Suboptimal |
Utilisez les API de service Web Salesforce pour effectuer des requêtes de données ad hoc afin d'accéder à et de mettre à jour des données système externes. Cette solution comprend les approches suivantes :
Utilisez l'API SOAP Salesforce. Une page ou un bouton personnalisé initie un appel externe REST/SOAP Apex de manière synchrone. Dans Salesforce, vous pouvez consommer un WSDL et générer une classe Apex proxy résultante. Cette classe fournit la logique nécessaire pour appeler le service distant. Une action initiée par l'utilisateur dans une page appelle ensuite une action de contrôleur Apex qui exécute cette classe Apex proxy pour effectuer l'appel distant. Les pages nécessitent une personnalisation de l'application Salesforce. Utilisez l'API REST Salesforce. Une page ou un bouton personnalisé initie un appel externe HTTP Apex (service REST) de manière synchrone. Dans Salesforce, vous pouvez invoquer des services HTTP en utilisant les méthodes standard GET, POST, PUT et DELETE. Pour plus d'informations sur cette solution, consultez Invocation de processus distant - Demande et réponse. |
Dans ce scénario :
- Le navigateur exécute un appel AJAX qui exécute à son tour une action sur l'adaptateur d'objet externe correspondant.
- L'adaptateur traduit l'action en requête OData et envoie une requête GET HTTP au système distant via les couches Integration et Services.
- Le système distant renvoie une réponse JSON à Salesforce via les couches Integration et Services.
- La réponse est traduite depuis Odata dans un objet externe et renvoyée au navigateur.
| Mécanisme d'appel | Description |
|---|---|
| Objets externes | Salesforce Connect mappe des objets externes Salesforce avec des tableaux de données dans des systèmes externes. Au lieu de copier les données dans votre organisation, Salesforce Connect accède aux données à la demande et en temps réel. Même si les données sont stockées hors de votre organisation, Salesforce Connect fournit une intégration transparente à Lightning Platform. Les objets externes sont disponibles pour les outils Salesforce, notamment la recherche globale, les relations de référence, les fils d'enregistrement et l'application mobile Salesforce. Les objets externes sont également disponibles pour les requêtes Apex, SOSL, SOQL, les API Salesforce, et le déploiement via l'API de métadonnées, des ensembles de modifications et des packages. |
| Composants d'éclairage | Utilisé lorsque le processus distant est déclenché dans le cadre d'un processus de bout en bout impliquant l'interface utilisateur, et que le résultat doit être affiché ou mis à jour dans un enregistrement Salesforce. Par exemple, un processus qui soumet des paiements par carte de crédit à une passerelle de paiement externe et renvoie immédiatement les résultats de paiement affichés pour l'utilisateur. L'intégration déclenchée à partir des événements de l'interface utilisateur nécessite généralement la création de composants Lightning personnalisés. |
- Cette solution ne consomme pas de stockage de données dans Salesforce.
- Les utilisateurs n'ont pas à se soucier de la synchronisation régulière des données entre le système externe et Salesforce.
- Une configuration déclarative qui peut être réalisée rapidement avec OData, ou un adaptateur inter-organisations, ou en utilisant un code minimal avec un adaptateur Apex personnalisé.
- Les utilisateurs peuvent accéder à des données externes avec les mêmes fonctionnalités que les objets personnalisés sous forme d'objets externes.
- Possibilité d'effectuer une recherche fédérée dans le système externe connecté en utilisant la recherche globale.
- Possibilité d'exécuter des rapports qui accèdent à des données externes à partir de sources cloud et sur site. Consultez les considérations relatives aux rapports ci-dessous.
- Les objets externes se comportent comme des objets personnalisés, mais certaines fonctionnalités ne sont pas disponibles pour les objets externes. Pour plus d'informations, voir Considérations relatives à la compatibilité Salesforce Connect
- Les objets externes peuvent impacter les performances des rapports. Pour plus d ' informations, voir Considérations relatives aux rapports Salesforce Connect
- Pour plus d'informations sur l'utilisation des adaptateurs Salesforce Connect, voir Considérations relatives à Salesforce Connect - Tous les adaptateurs.
- Si vous envisagez d'utiliser un adaptateur inter-organisations, consultez Considérations relatives à Salesforce Connect - adaptateur inter-organisations.
- Si vous envisagez d'utiliser un adaptateur Odata, consultez Considérations relatives à Salesforce Connect - adaptateurs Odata 2.0 et 4.0.
- Si vous envisagez d'utiliser un adaptateur Apex personnalisé, consultez Considérations relatives à Salesforce Connect - Adaptateur personnalisé.
- La requête est généralement invoquée depuis l'interface utilisateur. Par conséquent, le processus ne doit pas faire attendre l'utilisateur.
- Selon la disponibilité et la connexion au système externe, la récupération des données externes peut prendre du temps. Salesforce a une valeur d'expiration maximale configurable de 120 secondes pour attendre une réponse du système externe.
- L'exécution du processus distant doit se faire dans les délais impartis et dans les délais prescrits par Salesforce et dans les attentes des utilisateurs.
| Solution | Considérations relatives aux points de terminaison |
|---|---|
| Salesforce Connect | API Odata : utilisez le protocole Open Data pour accéder aux données stockées hors de Salesforce. Les données externes doivent être exposées via des producteurs Odata. Autres API : utilisez Apex Connector Framework pour développer votre propre adaptateur personnalisé lorsque les autres adaptateurs disponibles ne répondent pas à vos besoins. Un adaptateur personnalisé peut obtenir des données de n'importe quelle source. Par exemple, certaines données peuvent être récupérées sur Internet via des appels externes, tandis que d'autres données peuvent être manipulées ou même générées par programmation. Connecter à Salesforce : utilise l'API REST Lightning Platform pour accéder aux données stockées dans d'autres organisations Salesforce. Connexion via Middleware Connect via Middleware : l'écosystème de partenaires Salesforce Connect a travaillé en étroite collaboration avec Salesforce pour s'assurer que leurs passerelles middleware exposent les points de terminaison OData de leur service afin que Salesforce puisse se connecter avec eux sans écrire de code supplémentaire. |
| Demande et réponse | Appels externes SOAP Apex - Le point de terminaison doit pouvoir recevoir un appel de service Web via HTTP. Appels externes HTTP Apex - Le point de terminaison doit pouvoir recevoir des appels HTTP. Vous pouvez utiliser des appels externes HTTP Apex pour appeler des services RESTful en utilisant les méthodes standard GET, POST, PUT et DELETE |
- Salesforce stocke la clé de substitution primaire ou unique de l'enregistrement distant.
- Le système distant stocke l'ID d'enregistrement unique Salesforce ou une autre clé de substitution unique. Il existe des considérations spécifiques pour gérer les clés d'intégration dans ce schéma synchrone.
| Système principal | Description |
|---|---|
| Salesforce | Le système distant stocke l'ID d'enregistrement Salesforce ou une autre clé de substitution unique de l'enregistrement. |
| Système distant | L'appel au processus distant renvoie la clé unique de l'application, et Salesforce stocke cette valeur de clé dans un champ d'enregistrement unique. |
- Agrégation des appels et de leurs résultats entre les appels à plusieurs systèmes
- Transformation des messages entrants et sortants
- Maintien de l'intégrité transactionnelle entre les appels à plusieurs systèmes
- Autres activités d'orchestration de processus entre Salesforce et le système externe
| Propriété | Obligatoire | Désirable | Non requis |
|---|---|---|---|
| Traitement des événements | X | ||
| Conversion du protocole | X | ||
| Traduction et transformation | X | ||
| Mise en file d'attente et tampon | X | ||
| Protocoles de transport synchrones | X | ||
| Protocoles de transport asynchrones | X | ||
| Acheminement de la médiation | X | ||
| Chorégraphie de processus et orchestration de service | X | ||
| Transactionnalité (cryptage, signature, livraison fiable, gestion des transactions) | X | ||
| Acheminement | X | ||
| Extraire, transformer et charger | X | ||
| Sondage long | X |
| Relation | Objets enfants autorisés | Objets parents autorisés | Champ parent pour les enregistrements correspondants |
|---|---|---|---|
| Référence | Standard, Personnalisé, Externe | Standard, personnalisé | L'ID d'enregistrement Salesforce à 18 caractères |
| Référence externe | Standard, Personnalisé, Externe | Externe | Le champ standard ID externe |
| Référence indirecte | Externe | Standard, personnalisé | Sélectionner un champ personnalisé avec les attributs ID externe et Unique |
- Configurez votre source de données externe avec un point de terminaison Odata. Votre application distante peut inclure la prise en charge native d'Odata . Pour d'autres applications, les principaux fournisseurs d'intégration tels que Dell Boomi, Informatica, Jitterbit, MuleSoft et Progress Software se sont associés à Salesforce sur Salesforce Connect pour élaborer des adaptateurs.
- Pointez Salesforce Connect vers le point de terminaison OData, soit directement, soit via une solution middleware.
- Synchronisez vos tableaux de base de données externes avec des objets externes dans Salesforce. Lorsqu'un utilisateur accède à une page contenant les données de ces objets externes, Salesforce Connect passe des appels externes en temps réel à vos applications back-end.
| Niveau de schéma1 | Niveau de schéma2 | Modèle | Scénario |
|---|---|---|---|
| Modèles d'ingestion de données - Données entrantes | Modèles d'ingestion par lot | Ingestion de données en masse depuis Cloud Storage | Les données sont ingérées dans Data 360 à partir d'une source de stockage cloud d'entreprise telle que Amazon S3, Azure Blob ou Google Cloud Storage, sous forme de lots volumineux de données brutes (par exemple, des journaux de transactions ou de produits). |
| Ingestion de données en masse depuis Salesforce Clouds | Data 360 reçoit en masse les données CRM de plusieurs organisations Salesforce (par exemple Sales Cloud, Service Cloud) pour élaborer des profils clients unifiés. | ||
| Modèles d'ingestion en continu et en temps réel | Ingestion pilotée par l'événement via l'API Ingestion--Streaming | Data 360 s'abonne aux points de terminaison d'ingestion en continu qui reçoivent des charges de travail d'événements continus (par exemple, événements d'achat, télémétrie IoT) des systèmes d'entreprise pour des mises à jour de profil en temps réel. | |
| Ingestion du comportement Web et mobile en temps réel | Data 360 collecte et traite les données comportementales en temps réel des sites Web et des applications mobiles via des kits de développement pour enrichir les métriques d'engagement et les modèles de personnalisation. | ||
| Synchronisation CRM en temps quasi réel via Streaming | Data 360 reçoit les mises à jour des données CRM (p. ex., contact, requête, changements d'opportunité) en temps quasi réel via des flux d'événements pour maintenir une vue Customer 360 synchronisée en permanence. | ||
| Ingestion de flux d'événements à partir de plates-formes de messagerie Cloud - Kinesis et MSK | Data 360 consomme des données en continu directement à partir de plates-formes d'événements cloud telles que AWS Kinesis ou Kafka (MSK) pour traiter les événements opérationnels ou Internet des objets à haute fréquence. | ||
| Zéro modèle de copie - entrant et sortant | Inbound Zero Copy - Plates-formes externes dans Data 360 | Data 360 interroge des jeux de données externes (par exemple Snowflake, BigQuery) à la demande via Zero Copy Ingestion, sans déplacer physiquement les données dans Salesforce. | |
| Copie zéro sortante - Data 360 vers des plates-formes externes | Des systèmes externes tels que Databricks ou Tableau accèdent à des segments et à des connaissances enrichis dans Data 360 via des connexions Zero Copy Outbound sans réplication des données. | ||
| Plate-forme de données multi-organisations unifiée avec Data Cloud One | Data Cloud One unifie plusieurs organisations Salesforce et sources de données externes sous un modèle sémantique et de métadonnées partagées, offrant ainsi un Customer 360 cohérent sans duplication des données. | ||
| Modèles d'activation des données - Données sortantes | Modèles d'activation par lot | Activation de segments pour des plates-formes marketing et publicitaires | Data 360 active des segments de clients organisés directement dans Marketing Cloud, Meta, Google Ads ou d'autres plates-formes publicitaires pour une diffusion de campagnes personnalisées |
| Exportation de données vers Cloud Storage | Data 360 exporte des jeux de données unifiés ou filtrés (par exemple, des enregistrements clients consentis) sous forme de fichiers CSV ou Parquet vers le stockage cloud d'entreprise pour l'archivage d'analyses ou de conformité. | ||
| Activation basée sur l'API à la demande | Intégration d'application personnalisée via l'API Connect | Les applications externes invoquent l'API Data 360 Connect en temps réel pour récupérer ou déclencher des actions personnalisées (par exemple, contrôle du solde de fidélité ou génération d'offres IA) basées sur les données clients actuelles.Des applications Web ou mobiles personnalisées récupèrent des connaissances Data 360 harmonisées en toute sécurité via l'API REST Connect pour les afficher dans des interfaces utilisateur d'entreprise ou de partenaire. | |
| Récupération complète du profil client via l'API Data Graph | Un système récupère le profil unifié d'un client en utilisant l'API Data Graph, en renvoyant une représentation JSON en temps réel pré-jointe de la vue complète à 360° pour la prise de décision ou la personnalisation. | ||
| Actions de données en temps réel | Action de données en temps réel Transformation des signaux clients en action instantanée | Data 360 détecte et traite un événement en direct (par exemple, mise à jour du consentement, déclencheur d'achat) et invoque immédiatement un système connecté ou un flux Salesforce pour une action en aval.Un signal d'activité client (par exemple, risque d'attrition détecté) dans Data 360 déclenche une action instantanée en temps réel, par exemple mettre à jour CRM, invoquer le score Einstein ou lancer un parcours de rétention. |
| Type | Calendrier | Considérations sortantes |
|---|---|---|
| Intégration de données | Asynchrone | Activation de segments pour des plates-formes marketing et publicitaires |
| Intégration de processus/données | Synchrone | Intégration d'application personnalisée via l'API Connect Récupération complète du profil client via l'API Data Graph |
| Intégration de données | Synchrone | Action de données en temps réel Transformation des signaux clients en action instantanée |
| Intégration virtuelle (utilisation de Zero Copy) | Asynchrone | Copie zéro sortante - Data 360 vers des plates-formes externes |
| Intégration virtuelle | Asynchrone | Plate-forme de données multi-organisations unifiée avec Data Cloud One |
| Type | Calendrier | Considérations relatives aux entrées |
|---|---|---|
| Intégration de données | Asynchrone | Ingestion de données en masse depuis Cloud Storage Ingestion de données en masse depuis Salesforce Clouds |
| Intégration de données | Asynchrone | Ingestion de flux d'événements à partir de plates-formes de messagerie Cloud - Kinesis et MSK Synchronisation CRM en temps quasi réel via Streaming |
| Intégration de processus | Synchrone | Ingestion pilotée par l'événement via l'API Ingestion--Streaming Ingestion du comportement Web et mobile en temps réel |
| Intégration virtuelle | Asynchrone | Inbound Zero Copy - Plates-formes externes dans Data 360 |
| Durée | Définition |
|---|---|
| Gestion des événements | Le traitement des événements désigne la réception, l'acheminement et la réponse à des occurrences identifiables à partir d'un système source ou d'une application. Middleware gère les événements en identifiant le point de terminaison cible, en transmettant l'événement et en déclenchant l'action métier requise (par exemple, consignation, tentatives ou activation de services en aval). Dans les architectures Data 360, le traitement des événements est essentiel pour l'ingestion de données en temps réel, les déclencheurs d'activation et les modèles de publication/abonnement. Les événements peuvent provenir de systèmes externes (Kafka, AWS Kinesis) ou d'événements de plate-forme Salesforce, et sont acheminés par middleware ou bus d'événement Data 360 pour un traitement immédiat. |
| Conversion du protocole | La conversion de protocole permet de communiquer entre les systèmes en utilisant différentes normes de transport de données. Middleware traduit les protocoles propriétaires ou hérités (tels que AMQP, MQTT, FTP) en protocoles Data 360 pris en charge (REST, gRPC ou HTTPS). Cela garantit l'interopérabilité entre des systèmes hétérogènes. Comme Data 360 ne gère pas nativement la conversion de protocole, middleware fournit la couche d'adaptation, encapsulant ou transformant les messages dans un format que les API et les connecteurs Data 360 peuvent interpréter. |
| Traduction et transformation | La traduction et la transformation garantissent l'interopérabilité en mappant un format de données ou un schéma avec un autre. Middleware effectue ces transformations pour aligner diverses charges de travail de données (CSV, XML, JSON) avec des objets modèle de données (DMO) Data 360 et des objets couche de données unifiée (UDLO). Cela inclut le nettoyage, l'enrichissement et l'application d'un mappage sémantique ou basé sur l'ontologie avant l'ingestion. Si Salesforce propose des outils de transformation comme les Recettes de Préparation des données, il est préférable de gérer les transformations complexes (notamment pour l'harmonisation sémantique) dans les middlewares. |
| File d'attente et tampon | La mise en file d'attente et la mise en tampon s'appuient sur la transmission de messages asynchrones pour garantir une communication résiliente et découplée. Les plates-formes middleware (par exemple, MuleSoft, Kafka ou Azure Event Hub) fournissent des files d'attente permanentes qui stockent temporairement des données lorsque Data 360 ou des systèmes en aval sont occupés ou inaccessibles. Cela évite la perte de données et prend en charge les tentatives d'ingestion ou d'activation en temps quasi réel. Data 360 prend en charge l'ingestion en continu et la messagerie sortante basée sur le flux, mais la mise en file d'attente durable et la livraison garantie sont généralement gérées par un middleware. |
| Protocoles de transport synchrones | Les protocoles de transport synchrones impliquent des opérations de blocage/réponse en temps réel. L'expéditeur attend une réponse avant de continuer. Dans Data 360, ils sont utilisés pour les activations basées sur l'API à la demande, l'enrichissement en temps réel ou les références de profil, où des réponses sont requises immédiatement. Middleware garantit la fiabilité de la connexion et gère les tentatives ou le traitement de secours pour les appels d'API Data 360 synchrones. |
| Protocoles de transport asynchrone | Les protocoles de transport asynchrones prennent en charge la communication non bloquante et découplée dans laquelle l'expéditeur poursuit le traitement sans attendre une réponse. Middleware gère les flux asynchrones pour les activations par lot, l'ingestion en continu et l'activation pilotée par l'événement. Cela permet un débit et une résilience élevés, essentiels pour la diffusion en continu d'événements et les modèles d'ingestion de données en temps quasi réel dans Data 360. |
| Acheminement de médiation | L'acheminement de la médiation définit un flux de messages complexe entre les systèmes, garantissant que les données ou les événements appropriés parviennent au consommateur approprié. Middleware agit en tant que médiateur, gérant une logique d'acheminement basée sur des règles, des en-têtes, un contenu ou un type d'événement. Dans les intégrations Data 360, la médiation garantit que les événements et les mises à jour de profil de plusieurs systèmes sont correctement acheminés vers des API Ingestion de données, des points de terminaison d'activation ou des consommateurs externes. Cela simplifie l'orchestration et prend en charge la synchronisation des données multisystème. |
| Chorégraphie de processus et orchestration de service | La chorégraphie de processus et l'orchestration coordonnent les processus multi-systèmes. La chorégraphie prend en charge des flux autonomes pilotés par un événement, où les systèmes agissent sur la base de règles partagées sans contrôleur central. Orchestration est un flux géré de façon centralisée qui dirige l'exécution du service. Dans les architectures Data 360, le middleware gère l'orchestration pour l'ingestion et l'activation à travers les systèmes, tandis que les workflows Salesforce ou les flux gèrent les chorégraphies légères sur la plate-forme. Une orchestration complexe, nécessitant une coordination des transactions ou une gestion d'état, est recommandée au niveau de la couche middleware. |
| Transactionnalité (cryptage, signature, livraison fiable, gestion des transactions) | La transactionnalité garantit des opérations atomiques, cohérentes, isolées et durables (ACID) entre les systèmes. Salesforce et Data 360 sont transactionnelles dans leurs limites, mais ne prennent pas en charge les transactions distribuées à travers des systèmes externes. Middleware gère le contrôle global des transactions, notamment le cryptage, la signature de messages, l'annulation, la compensation et la livraison fiable. Pour les flux de données critiques (par exemple, les mises à jour financières ou de consentement), le middleware garantit l'intégrité et la récupération de bout en bout dans Data 360 et les systèmes externes. |
| Acheminement | L'acheminement spécifie le flux contrôlé de messages ou de données entre les composants. Il peut être basé sur des en-têtes, un type de contenu, une priorité ou des règles. Middleware gère la logique d'acheminement des événements et des activations impliquant Data 360, par exemple l'acheminement de segments d'audience enrichis vers différents systèmes en aval (plates-formes publicitaires, entrepôts, applications CRM). Bien que l'acheminement puisse être implémenté dans Salesforce (Apex, Flux), l'acheminement middleware est préféré pour l'évolutivité, la flexibilité et la gouvernance. |
| Extraction, transformation et chargement (ETL) | ETL consiste à extraire des données de systèmes sources, à les transformer en schéma cohérent et à les charger dans une cible (telle que Data 360). Les outils middleware ou ETL gèrent ces opérations avant l'ingestion de données. Data 360 peut recevoir des sorties ETL via des API, des connecteurs, ou des pipelines d'ingestion en masse, et prend également en charge la Capture des données de modification (CDC) pour la synchronisation en temps quasi réel. Les processus ETL Middleware sont essentiels pour intégrer des systèmes hérités et garantir la qualité des données avant l'unification dans Data 360. |
| Sondage long | L'interrogation longue (programmation Comet) est une méthode qui permet de maintenir une communication ouverte entre les systèmes pour des mises à jour en temps réel. Le client envoie une requête et le serveur la conserve jusqu'à ce qu'un événement se produise, puis répond et rouvre une nouvelle connexion. Salesforce l'utilise dans l'API Streaming et les protocoles CometD/Bayeux pour la synchronisation des données pilotée par l'événement. Middleware peut s'abonner à ces événements et les transmettre à Data 360 pour des déclencheurs d'ingestion ou d'activation en temps réel, ce qui garantit une latence minimale entre les systèmes d'entreprise. |
| Solution | Ajustement | Commentaires |
|---|---|---|
| Utilisation de connecteurs Native Cloud Storage (Amazon S3, Google Cloud Storage, Azure Blob Storage) | Meilleur | C'est le modèle recommandé et le plus fiable pour l'ingestion récurrente à grande échelle de fichiers dans Data 360\. Les connecteurs natifs fournissent une authentification gérée, un mappage de schémas et un mouvement sécurisé des données directement dans les objets lac de données (DLO) de Data 360. Idéal pour les chargements par lot planifiés où la latence n'est pas critique (par exemple, planification horaire ou quotidienne). |
| Traitement des jeux de données volumineux (au-delà des limites du connecteur) | Mieux avec le prétraitement | Chaque connecteur applique des limites en ingestion (par exemple, S3 : 100 M de lignes ou 50 Go par objet). Pour des jeux de données plus volumineux, implémentez une étape de prétraitement ETL afin de partitionner les données dans des fichiers/dossiers plus petits qui correspondent à ces seuils. Configurez ensuite plusieurs flux de données pour ingérer chaque partition en parallèle, puis utilisez le nœud append dans une transformation de données par lot) dans Data 360 pour recombiner les partitions dans un jeu de données unifié. |
| Sécurité et gouvernance | Meilleur | Tous les connecteurs prennent en charge l'authentification sécurisée via des méthodes natives du cloud (rôles IAM, comptes de service ou clés d'accès). Pour plus de contrôle, limitez l'accès aux plages IP Data 360 via la liste d'autorisations du fournisseur de cloud. Le transfert de données se fait sur des canaux cryptés, avec des fichiers stockés dans une couche intermédiaire temporaire et sécurisée pendant l'ingestion. |
| Quand ne pas utiliser | Suboptimal | Ce schéma n'est pas optimal pour :
|
Dans ce scénario :
- L'administrateur configure une connexion au stockage cloud via l'interface de configuration de Data 360 (en spécifiant l'authentification, les détails du compartiment, les rôles IAM et la liste blanche).
- L'interface de configuration de Data Cloud s'authentifie à Cloud Storage Platform, en vérifiant les identifiants et l'accès.
- L'administrateur crée un flux de données dans Data 360, liant le flux de données à l'objet/dossier dans Cloud Storage et définissant la planification de l'ingestion.
- À la planification du déclencheur, le flux de données demande des fichiers sources (par exemple, CSV, Parquet) depuis Cloud Storage Platform.
- Cloud Storage Platform livre des fichiers, y compris les fichiers valides requis schema_sample.csv et d'autres fichiers de données conformes aux conventions de nommage.
- Le flux de données transfère des fichiers vers l'environnement intermédiaire interne dans Data 360.
- Data 360 Pipeline traite les fichiers : Utilise la définition de schéma de schema_sample.csv Valide la structure, les noms de champ et divise la charge si elle dépasse les seuils d'ingestion (100 millions de lignes/50 Go par fichier). Si des fichiers volumineux sont détectés, une étape de partitionnement préalable au traitement (notifiée à l'administrateur pour la prochaine exécution) est effectuée en externe.
- Les enregistrements sont importés depuis Staging dans un objet lac de données (DLO).
- Si nécessaire et que les données sont partitionnées, utilisez le nœud append dans une transformation de données batch pour combiner plusieurs objets lac de données.
- Data 360 consigne les réussites/échecs, met à jour le statut de surveillance et indique que les données sont prêtes pour le mappage, l'harmonisation et l'unification.
##### Résultats
L'application de ce schéma permet d'ingestion sécurisée, planifiée et à grande échelle de fichiers structurés ou non structurés à partir de plates-formes de stockage cloud d'entreprise dans Data 360. Le processus est automatisé, évolutif et résilient. Il livre des données brutes dans des objets lac de données (DLO) qui servent de base d'harmonisation et de mappage avec le Customer 360 Data Model.
###### Mécanismes d'ingestion
Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.
| Mécanisme d'ingestion | Description |
|---|---|
| Connecteur Native Cloud Storage (Amazon S3, GCS, Azure) | Recommandé pour l'ingestion directe de fichiers au format CSV ou Parquet depuis le lac de données cloud de l'entreprise. Ces connecteurs prennent en charge les planifications d'actualisation incrémentielles et complètes. Par exemple, une banque peut configurer une synchronisation quotidienne des fichiers de transaction client depuis un compartiment S3 vers un objet lac de données. |
| Stratégie de fichiers partitionnés | Pour des jeux de données très volumineux (au-delà de 100 millions de lignes ou 50 Go par objet), les données sont partitionnées en jeux logiques plus petits (par exemple, par mois ou par région). Chaque partition est gérée comme un flux de données séparé, puis recombinée en utilisant une Transformation de données par lot avec un nœud Ajouter. |
| Synchronisation planifiée automatisée | Data 360 fournit un planificateur déclaratif (cadence horaire, quotidienne ou personnalisée) qui déclenche automatiquement des tâches d'ingestion, assurant l'actualisation des données sans intervention manuelle. |
| Type de connecteur | Exigences du point de terminaison |
|---|---|
| Connecteur Amazon S3 | Compartiment S3 avec la stratégie IAM appropriée et le fichier schema\_sample.csv définissant le schéma. |
| Connecteur Google Cloud Storage | Identifiants de compte de service et accès au compartiment avec des conventions de nommage uniformes. |
| Connecteur Azure Storage | Accéder à l'authentification basée sur la clé ou le jeton SAS ; la structure du blob ou du dossier doit respecter les conventions Data 360. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Solution adaptée | Meilleur | Utilisez le connecteur Salesforce CRM natif et le connecteur Marketing Cloud Engagement dans Data 360\. Commencez par les paquets de données de démarrage pour des cas d'utilisation standard et accélérez l'intégration. Utilisez la personnalisation manuelle des flux pour des modèles de données sur mesure ou spécifiques au domaine. |
| Gestion des instances CRM hautement personnalisées | Mieux avec l'atelier de mappage | Traitez les offres groupées de démarrage comme une référence et organisez un atelier de cartographie pour identifier : Objets et relations personnalisés. Champs de formule ou calculés. Extensions de package géré. Pour des champs de formule lourds, calculez des valeurs dans un ETL préalable à l'étape ou dans des Transformations Data 360 afin de limiter la charge d'API pour les organisations sources. |
| Quand ne pas utiliser | Scénarios sous-optimaux | Évitez ce schéma si : Vous avez besoin d'une ingestion d'événements à haute fréquence ou en temps réel (utilisez à la place Connecteurs en continu, Événements de plate-forme ou Fédération zéro copie). L'organisation source a une capacité d'API limitée et ne peut pas prendre en charge les extractions planifiées sans limitation ou délais de mise en file d'attente. |
| Sécurité et gouvernance | Contrôles obligatoires | Principe du moindre privilège : utilisez un utilisateur d'intégration dédié avec un accès en lecture minimal. N'utilisez jamais des administrateurs d'organisation. Authentification : utilisez OAuth 2.0 et des applications connectées, permutez régulièrement les secrets clients et surveillez l'utilisation de jetons d'actualisation. Audit et traçabilité : consignez toutes les exécutions d'ingestion, les changements de schéma et les événements de connecteur. Transmettez les journaux au SIEM ou aux systèmes de conformité pour la préparation à l'audit. Classification des données : appliquez le balisage PII/PHI et le Contrôle d'accès basé sur l'attribut (ABAC) en utilisant des stratégies CEDAR immédiatement après l'ingestion pour imposer le masquage, le consentement et la conformité en aval. |
Dans ce scénario :
- L'**administrateur provisionne les utilisateurs** de l'intégration et attribue des ensembles d'autorisations de connecteur dans les organisations sources.
- L'**administrateur configure les connecteurs** dans la Configuration de Data 360 (se connecte à Salesforce CRM et Marketing Cloud via OAuth/application connectée).
- **L'administrateur crée** des flux de données en sélectionnant des objets et des extensions de données, choisit l'actualisation complète ou delta, et définit des planifications.
- **À l'exécution planifiée**, Data 360 demande des jetons de schéma et delta à la ou aux sources.
- Les **systèmes sources renvoient des enregistrements** (delta ou charge utile complète). Marketing Cloud peut fournir des extractions, CRM peut renvoyer des résultats JSON/Query.
- **Data 360 met** en scène les fichiers dans sa zone intermédiaire sécurisée interne et les valide par rapport au schéma mappé.
- **Si la validation échoue**, l'erreur est consignée dans les journaux d'ingestion, l'administrateur est alerté et l'engagement est interrompu. Si la validation réussit, Data 360 engage atomiquement les enregistrements dans l'objet lac de données cible.
- Les **journaux de surveillance et** d'audit sont mis à jour avec le lignage, la durée d'exécution, le nombre de lignes et l'utilisation des identifiants. Alertes envoyées aux administrateurs en cas de déclenchement de seuils ou d'erreurs.
##### Résultats
Les principales données de relation client et d'engagement marketing sont ingérées dans Data 360 en tant qu'objets lac de données (DLO). Cela renvoie :
- **Jeu de données unifié** contenant des profils, des requêtes, des opportunités et des métriques d'e-mail/engagement.
- **Fondation pour la résolution** de l'identité et la construction de profils Individu unifié.
- **Préparation opérationnelle** à l'harmonisation, à l'enrichissement, à la modélisation et à l'activation de l'IA en aval tout en préservant la gouvernance et l'auditabilité.
###### Mécanismes d'ingestion
Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.
| Mécanisme | Quand utiliser |
|---|---|
| Connecteur Salesforce CRM (natif) | Idéal pour les objets CRM standard/personnalisés ; prend en charge l'actualisation complète et delta. |
| Connecteur Marketing Cloud Engagement (natif) | Idéal pour les extensions de données, les envois et les extractions de suivi ; prend en charge les modes full/delta. |
| Paquets de données de démarrage | Accélérez l'intégration pour les objets Sales/Service/Marketing courants. |
| Flux personnalisés + prétraitement | Utilisé lorsque des transformations complexes ou une normalisation de schéma lourde sont requises. |
| Connecteur | Exigences du point de terminaison |
|---|---|
| Connecteur Salesforce CRM | L'organisation source doit autoriser une application connectée, des jetons OAuth et un utilisateur d'intégration dédié avec des autorisations de lecture. |
| Connecteur Marketing Cloud | Identifiants d'API Marketing Cloud ou package installé ; les extensions de données doivent exposer les données via Extraits/API. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Solution adaptée | Meilleur pour la capture d'événements à faible latence | Utilisez l'API Data 360 Ingestion (JSON en continu) pour envoyer automatiquement des événements uniques ou des micro-batches. Configurez le connecteur d'API Ingestion avec un schéma OAS 3.0 strict (.yaml). Utilisez l'ingestion CSV en masse pour des synchronisations plus grandes et moins fréquentes. |
| Modifications du schéma de traitement | Strict / Géré | Les changements de schéma sont rompus : mettez à jour OAS .yaml, mettez le connecteur en version et effectuez des tests contractuels. Implémentez la migration du schéma glissant si les producteurs ne peuvent pas changer simultanément. |
| Quand ne pas utiliser | Suboptimal | Pas idéal si un prétraitement est nécessaire ( ex: déduplication, commande garantie etc. ) , ou pour des charges en masse extrêmement importantes (utilisez des connecteurs en masse natifs ou ETL par lot). Si la source ne peut pas produire de charges utiles valides pour le schéma ou ne peut pas s'authentifier en toute sécurité, utilisez des méthodes d'ingestion alternatives. |
| Sécurité et gouvernance | Obligatoire | Utilisez OAuth 2.0 avec des étendues à moindre privilège, permutez les clés, consignez l'utilisation de jetons. Appliquez le protocole TLS 1.2+, validez les adresses IP des clients si nécessaire et assurez-vous que les informations d'identification personnelle de la charge de travail sont balisées. Tous les événements doivent porter des métadonnées de provenance (source, horodatage, version du schéma, clé d'idempotence). |
**Dans ce scénario :**
- Le système externe demande l'authentification via OAuth/JWT au serveur d'authentification.
- Le serveur d'authentification renvoie le jeton d'accès au système externe.
- Le système externe envoie la requête POST d'ingestion de données à l'API Ingestion Data 360 avec autorisation et charge de travail JSON.
- L'API Ingestion valide le schéma de requête et l'authentification via le module Staging & Validation.
- En cas d'échec du schéma/de l'authentification :
- Erreur renvoyée dans Système externe.
- Refus consigné pour surveillance et alerte.
- Une fois la validation réussie :
- Enregistrements mis en scène et engagés dans Objet lac de données (DLO).
- Succès consigné pour la surveillance.
- Si cette option est activée, les données sont propagées vers le Graphique de données en temps réel (DMO) qui déclenche des workflows en aval.
- Sinon, les données sont traitées par lot standard ou pipeline à latence plus élevée.
- L'API Ingestion confirme le succès du système externe.
- Les composants de surveillance alertent l'administrateur sur les files d'attente en lettres mortes, les taux de rejet ou les problèmes de latence.
##### Résultats
Les données d'événements externes sont ingérées dans des objets lac de données Data 360 à faible latence. Lorsque l'objet modèle de données cible fait partie du graphique en temps réel, les données sont disponibles pour la segmentation instantanée, les workflows des agents, les modèles IA et l'activation opérationnelle. Cela permet de répondre rapidement aux événements provenant de n'importe quel système connecté.
###### Mécanismes d'ingestion
Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.
| Mécanisme | Quand utiliser |
|---|---|
| JSON en continu (API Ingestion) | Événements uniques, microbatches, événements comportementaux, flux de clics, télémétrie Internet des objets — lorsqu'une faible latence est requise. |
| CSV en masse (mode en masse de l'API Ingestion) | Chargements périodiques plus importants où les exigences de latence sont assouplies. |
| Edge / Middleware | Utilisez-le lorsque vous avez besoin de validation, de transformation, d'enrichissement ou de limitation de taux avant d'appliquer automatiquement l'API Ingestion. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Capture d'événement basée sur le kit de développement | Meilleur | Déployez le kit de développement Salesforce Interactions (web) ou le kit de développement natif (mobile). Ces bibliothèques légères capturent et sérialisent les interactions des utilisateurs en temps réel, en joignant des métadonnées (ID de session, horodatage, contexte). |
| Event Streaming Pipeline | Meilleur | Les événements sont envoyés au service de streaming d'événements Marketing Cloud Personalization sur HTTPS sécurisé. Cette couche est évolutive horizontalement et optimisée pour la transmission à faible latence (<2s). |
| Intégration Data 360 | Meilleur | Le connecteur de personnalisation de Data 360 s'abonne au fil en continu, ingérant chaque événement dans un objet lac de données (DLO) en temps quasi réel. |
| Mappage de modèle de données | Meilleures pratiques | L'objet lac de données ingéré est mappé avec des objets modèle de données Customer 360. Cela permet de lier des utilisateurs anonymes et connus via la Résolution de l'identité. |
| Activation du graphique en temps réel | Facultatif / Recommandé | Insérez des objets modèle de données mappés dans le graphique en temps réel pour une segmentation instantanée, déclenchant des actions personnalisées via des workflows Einstein ou Agentforce. |
| Quand ne pas utiliser | Suboptimal | Ce schéma n'est pas idéal lorsque : Les données sources sont client Web et événements (utilisez à la place l'API Ingestion). L'organisation ne contrôle pas les clients Web/mobile. Le suivi du comportement en temps réel n'est pas requis (utilisez l'ingestion par lot). |
| Gestion des modifications du schéma | Évolution gérée | Les schémas d'événements évoluent à mesure que de nouvelles interactions sont ajoutées. Les kits de développement doivent versionner les définitions d'événements. Les modifications rétrocompatibles (ajout de champs facultatifs) sont sûres. Les modifications de rupture nécessitent une reconfiguration du connecteur et des tests de contrat. |
**Dans ce scénario :**
- Déployez le kit de développement dans des canaux Web ou mobiles (capture de l'interaction utilisateur).
- Configurez SDK avec des contrôles d'ID de locataire, d'environnement et de consentement.
- Diffusez les événements JSON capturés (métadonnées + attributs) au point de terminaison en continu Marketing Cloud.
- Dans Configuration de Data 360, créez et configurez le connecteur de personnalisation pour le locataire.
- Ingérez des événements dans un objet lac de données et mappez l'objet lac de données → objet modèle de données dans Data 360.
- Activez l'objet modèle de données dans le graphique en temps réel pour une activation immédiate.
- Surveillez la latence, la conformité du schéma, les indicateurs de consentement, le débit, les taux d'erreur.
- Déployez en production et surveillez en permanence.
##### Résultats
Un flux continu et à faible latence d'événements comportementaux circule depuis les canaux numériques vers Data 360. En quelques secondes, chaque action utilisateur devient disponible pour la segmentation en temps réel, la modélisation prédictive ou la personnalisation déclenchée, ce qui permet des expériences clients réellement adaptatives.
###### Mécanismes d'ingestion
Le mécanisme d'ingestion dépend du connecteur et de la stratégie de planification définis dans Data 360.
| Mécanisme | Quand utiliser |
|---|---|
| Interactions SDK (Web) | Capture en temps réel à partir de navigateurs Web et de SPA. |
| Mobile SDK | Capture en temps réel à partir d'applications mobiles natives. |
| Connecteur de personnalisation | Abonnement géré entre Marketing Cloud et Data 360\. |
| Mappage de graphiques en temps réel | Active l'activation immédiate dans Segmentation, Einstein et Parcours. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Connecteur Streaming basé sur CDC | Meilleur | Mécanisme Salesforce natif, entièrement géré et intégré à l'infrastructure d'événements de plate-forme. |
| Abonnement et livraison d'événements | Meilleur | Le connecteur s'abonne aux canaux ChangeEvent (par exemple, /data/ContactChangeEvent) via des ID de relecture durables. |
| Mappage des données et évolution du schéma | Meilleure pratique | Mappez les charges utiles diffusées avec l'objet lac de données correspondant ; gérez la gestion des versions de schéma dans les métadonnées pour éviter les pauses dans l'ingestion. |
| Relecture et récupération de défaut | Recommandé | Utilisez des ID de relecture et des clés d'idempotence pour éviter les doublons et récupérer les erreurs temporaires. |
| Mode hybride (Streaming + Batch) | Optional | Pour des objets non pris en charge ou un chargement en masse initial, utilisez l'ingestion par lot combinée à la diffusion en continu de CDC. |
| Quand ne pas utiliser | Suboptimal | Ce schéma peut être sous-optimal lorsque : L'objet source n'est pas activé pour le CDC. Le cas d'utilisation ne nécessite pas de mise à jour en temps réel (un lot suffit). La sortie du réseau depuis l'organisation source est limitée ou les limites en événements sont dépassées. |
**Dans ce scénario :**
- La modification est effectuée dans Salesforce CRM (créer/mettre à jour/supprimer/annuler la suppression).
- CDC publie un ChangeEvent dans le Bus d'événement Salesforce interne.
- Le connecteur Data 360 CRM s'abonne au Bus d'événement en utilisant un curseur de relecture durable.
- La charge de travail des événements est validée pour le schéma, les autorisations et l'intégrité des données.
- Data 360 écrit l'événement validé dans l'**objet lac de données** mappé.
- Si cette option est activée, les **objets modèle de données** mappés sont mis à jour en temps quasi réel, ce qui favorise la segmentation et l'activation.
##### Résultats
Data 360 maintient un miroir synchronisé en continu des données CRM clés.
Cela active :
- Déclencheurs en temps réel (par exemple, le parcours est lancé lors de la création d'une requête).
- Segmentation à jour (p. ex. déplacer les clients vers le segment « Gold » lors d'un changement de statut du compte).
- Analyses et personnalisation plus précises basées sur le contexte CRM live.
###### Mécanismes d'ingestion
Le mécanisme d'ingestion de ce schéma est géré en natif via le connecteur Salesforce CRM avec la Capture des données de modification (CDC) activée. Data 360 agit en tant qu'abonné au flux d'événements CDC, garantissant une synchronisation fiable et à faible latence entre l'organisation CRM source et Data 360.
| Mécanisme | Quand utiliser |
|---|---|
| Streaming via CDC (préféré) | Pour tous les objets Salesforce standard et personnalisés pris en charge dans lesquels une synchronisation en temps quasi réel est requise. |
| Mode hybride (CDC + lot) | Pour les objets qui ne sont pas encore activés par le CDC ou pour lesquels un chargement historique initial est requis. |
| Mode d'abonnement relecture | Pour la resynchronisation après un temps d'arrêt ou un déploiement. |
| Mode d'isolation d'erreur | Pour les environnements de test et de validation. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Kinesis Native Connector | Meilleur | Intégration interne à AWS Kinesis; prend en charge l'ingestion continue à haut débit. |
| Connecteur natif MSK | Meilleur | Ingestion gérée de Kafka avec la prise en charge de l'authentification OIDC et basée sur la clé. |
| Mapping et validation de schéma | Meilleure pratique | Chargez le schéma (.json/.avro) qui définit la structure des événements ; applique la cohérence pendant l'ingestion. |
| Configuration IAM | Recommandé | Attribuez un rôle IAM à moindre privilège avec un accès en lecture seule au flux Kinesis cible ou à la rubrique MSK. |
| Acheminement réseau privé | Optional | Configurez des points de terminaison PrivateLink/VPC pour un acheminement interne sécurisé. |
| Modèle hybride (Streaming + Lot) | Optional | Utilisez le streaming pour les deltas et l'ingestion par lot pour les remplissages ou les chargements historiques. |
| Mode d'isolation d'erreur | Recommandé | Acheminer les rejets de schéma et les erreurs transitoires vers DLQ pour relecture |
**Dans ce scénario :**
- Les applications ou les appareils publient des événements dans Kinesis Stream ou MSK Topic.
- Le connecteur Data 360 s'authentifie en utilisant des identifiants AWS ou un jeton OIDC.
- Le connecteur interroge ou s'abonne continuellement au flux.
- Les événements sont organisés, validés pour le schéma et la stratégie, puis engagés dans Objet lac de données (DLO).
- S'ils sont mappés, les objets modèle de données (DMO) sont mis à jour en temps quasi réel pour l'activation.
- La couche de surveillance suit les métriques, les rejets de schéma et la latence.
##### Résultats
Ingestion continue et à faible latence de données structurées directement depuis AWS Kinesis ou MSK dans Data 360. Les données sont immédiatement disponibles pour :
- Résolution de l'identité
- Segmentation en temps réel
- Activation IA Einstein
- Déclencheurs pilotés par Agentforce
Élimine la dépendance à l'ETL par lot, en activant des architectures basées sur le flux alignées avec les conceptions pilotées par les événements d'entreprise.
###### Mécanismes d'ingestion
| Mécanisme | Quand utiliser |
|---|---|
| Connecteur Kinesis (préféré) | Pour les sources de streaming natives AWS nécessitant une ingestion continue de données structurées à haut volume. |
| Connecteur MSK | Pour les organisations qui exécutent des pipelines d'événements sur des plates-formes compatibles Kafka. |
| Hybride (Streaming + Batch) | Pour l'ingestion incrémentielle d'événements combinée à des charges en masse périodiques. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Connecteur Snowflake Zero Copy | Meilleur | Intégration native tierce; établit la fédération de requêtes live via les API Partage de données ou Tableau externe Snowflake. |
| Connecteur Databricks Zero Copy | Meilleur | Prend en charge l'accès direct en direct aux tableaux/vues dans Delta Lake. Les requêtes pushdown sont exécutées à l'exécution de Databricks. |
| Fédération de fichiers (Apache Iceberg / Delta / Parquet) | Meilleures pratiques émergentes | Data 360 lit directement les formats de tableau ouverts dans le stockage d'objets sans dépendance de calcul externe. Idéal pour les jeux de données massifs. |
| Configuration du réseau privé | Recommandé | Utilisez Salesforce Private Connect ou le peering VPC pour sécuriser la fédération au niveau du réseau. |
| Authentification et gestion des clés | Meilleures pratiques | Implémentez une authentification sécurisée basée sur la clé ou OAuth avec une rotation périodique et une gestion des coffres-forts. |
| Enregistrement du schéma | Obligatoire | Data 360 récupère le schéma externe et le mappe avec un objet lac de données externe (objet lac de données externe). |
| Métadonnées régies | Recommandé | Tous les objets lac de données externes héritent des métadonnées de classification, de consentement et de lignage pour la visibilité de la conformité. |
Dans ce scénario :
- L'administrateur configure une connexion Zero Copy dans la Configuration de Data 360 (Snowflake, Databricks ou Fédération de fichiers).
- L'authentification sécurisée et l'acheminement réseau sont établis (Private Connect / OAuth / Paire de clés).
- L'administrateur crée un flux de données en sélectionnant la source externe, en parcourant les bases de données live, les schémas et les tableaux.
- Au lieu de copier des données, Data 360 crée un objet lac de données externe (Objet lac de données), un pointeur de métadonnées référençant le tableau live ou le fichier Iceberg.
- Les objets lac de données externes sont mappés avec des entités Customer 360 (p. ex., Client, Transaction, Produit).
- Data 360 interroge la source en place pendant la segmentation, l'activation ou le calcul des connaissances.
- Tous les accès, lignages de requêtes et métadonnées sont audités dans Data 360 Trust Layer.
##### Résultats
- Les données externes sont conservées dans Snowflake, Databricks ou S3, pas d'ETL, pas de duplication, pas de stockage supplémentaire.
- Data 360 obtient un accès en temps réel et en lecture aux données de l'entreprise pour la résolution de l'identité, les connaissances calculées et l'activation.
- Les organisations gardent un contrôle total dans leurs cadres de gouvernance, de cryptage et de conformité existants.
- Ce schéma permet une véritable architecture Zero Copy, combinant les performances de l'accès local à la gouvernance du stockage fédéré.
###### Mécanismes d'appel
Le mécanisme d'appel dépend de la solution choisie pour implémenter ce schéma.
| Mécanisme | Quand utiliser |
|---|---|
| Snowflake Federation (préféré) | Pour une fédération de requêtes live et performante avec des entrepôts de données d'entreprise régis. |
| Databricks Federation | Pour des analytiques unifiées et des environnements Lakehouse avec des jeux de données pris en charge par Delta ou Parquet. |
| Fédération de fichiers (Apache Iceberg / Delta Lake) | Pour des jeux de données à grande échelle dans le stockage d'objets où le détachement du calcul et l'optimisation des coûts sont essentiels. |
| Mode hybride (zéro copie + ingestion) | Lorsque des données historiques nécessitent une ingestion unique, mais que les données live sont accédées via Zero Copy. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Création de partage de données | Meilleur | L'administrateur crée un Partage de données dans Data 360, en ajoutant les objets modèle de données et les DSI sélectionnés (par exemple Individu unifié, Score de santé client). |
| Configuration de cible | Meilleur | Créez une cible de partage de données en spécifiant les identifiants de compte et les paramètres d'authentification Snowflake ou Databricks. |
| Partager la publication | Meilleures pratiques | Liez le Partage de données à la Cible de partage de données pour le publier en toute sécurité. |
| Acceptation d'entrepôt | Obligatoire | L'administrateur externe accepte le partage et matérialise les objets partagés sous forme de vues/tableaux en lecture seule dans l'entrepôt. |
| Contrôle d'accès granulaire | Recommandé | Appliquez des autorisations basées sur l'objet et le rôle dans Data 360, alignez-vous sur le contrôle d'accès basé sur le rôle au niveau de l'entrepôt. |
| Accès aux requêtes fédérée | Meilleur | Les analystes interrogent les données partagées en direct via SQL standard, joint aux données natives de l'entrepôt pour les analytiques en aval et la ML. |
| Option Fédération de fichiers | Optional | Pour des jeux de données volumineux, exploitez la fédération basée sur Apache Iceberg pour des lectures directes S3 ou Delta Lake sans dépendance au calcul. |
**Dans ce scénario :**
- L'administrateur Data 360 définit un Partage de données comprenant les objets Client unifié et Connaissances calculées.
- Une cible de partage de données (compte Snowflake ou Databricks) est enregistrée avec des identifiants sécurisés et des stratégies de gouvernance.
- Data 360 publie le partage ; les administrateurs Snowflake/Databricks l'acceptent.
- Les données partagées sont affichées sous forme de tableaux sécurisés en lecture seule dans l'entrepôt.
- Les analystes, les outils de BI ou les pipelines ML interrogent les données client live et unifiées sans les copier ni les synchroniser.
- Tous les accès sont audités dans les journaux de gouvernance de Data 360 Trust Layer et d'entrepôt.
##### Résultats
- Les entrepôts externes obtiennent un accès en temps réel et interrogeable aux données Data 360 harmonisées.
- Élimine les pipelines ETL inverses, réduisant ainsi la charge opérationnelle et la latence.
- Active la formation IA/ML, la modélisation prédictive et la BI avancée directement sur des données unifiées.
- Maintient l'absence de duplication, une gouvernance solide et un contrôle d'accès sécurisé par conception.
- Termine la boucle bidirectionnelle Zero Copy, dans laquelle la fédération entrante et le partage sortant coexistent sous un modèle de gouvernance unique.
###### Mécanismes d'appel
Le mécanisme d'appel dépend de la solution choisie pour implémenter ce schéma.
| Mécanisme | Quand utiliser |
|---|---|
| Partage de données sécurisé Snowflake (préféré) | Utilisé lorsque votre entrepôt d'entreprise est Snowflake et que vous avez besoin d'un accès live et régi aux jeux de données Data 360 harmonisés sans mouvement de données ni duplication. Idéal pour les analytiques, l'IA et les charges de travail pilotées par la conformité qui nécessitent le partage sans latence et l'application automatique de la lignage native. |
| Databricks Delta Partager | Utilisé lorsque les consommateurs en aval travaillent dans des environnements Databricks ou Delta Lake et nécessitent un accès en temps réel et en lecture seule à des jeux de données unifiés ou activés via le protocole ouvert Delta Sharing. |
| Part de table externe (Iceberg Apache / Parquet) | Utilisez-les pour gérer des architectures de format ouvert dans le stockage d'objets (S3, ADLS ou GCS) et pour utiliser le partage interopérable et économique entre des moteurs d'analyse tels que Athena, BigQuery ou Snowflake-on-Iceberg. |
| API de partage de données (accès programmatique) | Utilisé lorsque des applications personnalisées ou des middlewares (par exemple, MuleSoft) doivent découvrir, s'abonner ou consommer des jeux de données partagés en toute sécurité via des API, avec des notifications d'actualisation basées sur l'événement et un contrôle d'accès précis. |
| Partage hybride (copie nulle + partage sortant) | Utilisez-les pour implémenter des modèles d'échange bidirectionnel, en exploitant Zero Copy pour les données entrantes et Outbound Data Share pour publier des connaissances, afin de garantir la cohérence sémantique et de gouvernance entre les plans de données de l'entreprise. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Provisionnement d'organisation domestique | Meilleur | Désignez une organisation Salesforce en tant qu'organisation d'accueil dans laquelle Data 360 est provisionnée, qui devient le référentiel de données central et la plate-forme de gouvernance. |
| Connexion de l'organisation compagnon | Meilleur | Configurez des connexions Compagnon depuis l'organisation d'origine vers une ou plusieurs organisations Compagnon via l'application Data Cloud One, sans code personnalisé. |
| Définition d'espace de données | Meilleures pratiques | Définissez des espaces de données dans l'organisation d'origine pour segmenter logiquement les données (par exemple, Retail, Service, Marketing) et isoler les limites d'accès. |
| Partage d'espace de données | Meilleur | Partagez explicitement les Espaces de données sélectionnés depuis l'organisation d'origine vers les organisations d'accompagnement, afin de garantir une visibilité des données unifiées régie et basée sur le rôle. |
| Configuration de l'accès | Obligatoire | Dans Organisations complémentaires, activez l'application Data Cloud One et attribuez des autorisations utilisateur pour l'accès au profil, aux connaissances et au segment. |
| Gouvernance et contrôle des politiques | Recommandé | Centralisez toutes les configurations d'ingestion, de résolution de l'identité et Trust dans l'organisation d'origine, en maintenant une gouvernance de bout en bout. |
| Synchronisation multi-organisations | Meilleur | Les modifications des données et les connaissances calculées dans l'organisation d'accueil sont reflétées en temps réel dans les organisations compagnes via des pipelines de synchronisation gérés. |
| Option de déploiement hybride | Optional | Pour les grandes entreprises, plusieurs organisations compagnes peuvent se connecter à une seule organisation d'origine tout en préservant le contexte local et les limites de conformité. |
**Dans ce scénario :**
- **Administrateur à domicile** : créez un espace de données et définissez Partage de données (sélectionnez DMO/CIO, segments).
- **Administrateur à domicile** : créer Cible de partage de données pour les organisations compagnes et configurer Trust (client OAuth, ID d'organisation autorisés).
- **Administrateur d'accueil** : publiez Partage de données sur cible, joignez des stratégies ABAC (CEDAR) et des contrôles de cryptage/clé (CMK si nécessaire).
- **Administrateur de l'organisation** compagne : reçoit l'invitation, valide le mappage d'identité et accepte le partage.
- **Organisation Compagnon**: Data Cloud One Bridge provisionne un utilisateur Data Cloud One et applique la visibilité Ensembles d'autorisations et Espace de données.
- **Applications d'organisation complémentaire (flux / Einstein / Apex)**: Interrogez un graphique de données ou appelez les API Data Cloud One pour lire des objets modèle de données ou des segments partagés.
- **Activation**: L'organisation compagne déclenche l'activation ou réécrit via des actions de données (si autorisé).
##### Résultats
- Une **source unique de vérité** pour les données clients (Client 360) dans toutes les organisations connectées — pas d'instances Data 360 redondantes.
- **Les** organisations compagnes peuvent accéder à des données unifiées et aux fonctionnalités pilotées par Data 360 en quelques minutes, pas en semaines de codage personnalisé.
- **Partage de données contrôlé.** Seuls les espaces de données autorisés sont partagés, ce qui préserve la sécurité et la gouvernance tout en permettant l'agilité métier.
- Les fonctions commerciales (ventes, service, marketing) fonctionnent sur la même fondation de données unifiée, ce qui permet des métriques, une activation et des connaissances cohérentes dans l'ensemble de l'entreprise.
###### Mécanismes d'appel
Le mécanisme d'appel dépend de la solution choisie pour implémenter ce schéma.
| Mécanisme | Quand utiliser |
|---|---|
| Partage natif Data Cloud One (préféré) | Utilisé lorsque plusieurs organisations Salesforce (Sales, Service ou Industry Cloud) ont besoin d'un accès en temps réel aux données clients unifiées directement depuis Data 360\. Cela élimine la réplication et active l'accès sans latence aux enregistrements Golden, aux segments et aux connaissances calculées. |
| Partage d'organisation à organisation via un pont Data Cloud One | Utilisé lorsque plusieurs unités commerciales ou filiales opèrent dans des organisations Salesforce distinctes, mais doivent avoir un accès partagé aux données et segments clients communs à partir d'une instance Data 360 centrale. Idéal pour les entreprises multi-organisations qui gèrent des systèmes opérationnels indépendants. |
| API Einstein 1 Platform Query | Utilisé lorsque les applications Salesforce, Flow ou Einstein Copilot doivent interroger ou activer des données Data 360 par programmation. Permet de récupérer en temps réel des profils, des métriques ou des résultats d'activation unifiés dans d'autres applications Salesforce sans exportation par lot. |
| Activation dans les canaux Salesforce | Utilisé lorsque les données Data 360 (segments, connaissances ou attributs) doivent être activées dans Marketing Cloud, Service Cloud ou Commerce Cloud pour des expériences de personnalisation, d'exécution de campagnes ou d'assistance des agents. |
| Accès aux graphiques de données (couche de requête sémantique) | Utilisé lorsque vous avez besoin d'un accès au niveau sémantique au modèle de données unifié via le Graphique de données Salesforce, qui prend en charge Copilot, les workflows IA et les analytiques inter-clouds en temps réel, sans jointures ni transformations manuelles. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Création de segments | Meilleur | Un marketeur ou un analyste élabore un segment dans la zone de dessin de segmentation visuelle en appliquant des filtres à n'importe quel objet modèle de données (DMO) ou objet connaissances calculées (CIO). Cela définit l'audience cible pour l'activation. |
| Configuration de l'activation | Meilleur | L'utilisateur crée une activation et sélectionne le segment qu'il vient d'élaborer en tant que source. Cela définit l'audience que Data 360 exportera vers des systèmes en aval. |
| Sélection de la cible d'activation | Meilleures pratiques | Le marketeur sélectionne une cible d'activation préconfigurée (par exemple Marketing Cloud, Google Ads, LinkedIn Ads). Chaque cible est enregistrée dans Data 360 avec des identifiants d'authentification et des mappages de champs. |
| Définition de charge utile | Obligatoire | Le marketeur définit la charge utile en choisissant des identifiants de contact (e-mail, appareil mobile, ID haché) et en sélectionnant des attributs de profil supplémentaires (prénom, niveau de fidélité ou CLV) pour l'enrichissement dans le système de destination. |
| Planification et fréquence | Recommandé | L'exécution des activations peut être planifiée une fois ou de façon récurrente (par exemple, quotidienne ou hebdomadaire). La planification garantit que les audiences en aval restent synchronisées et à jour. |
| Exécution et exportation | Meilleur | Lors de l'exécution de la tâche d'activation, Data 360 interroge le segment, collecte les attributs sélectionnés, applique des filtres de consentement et exporte les données vers la plate-forme cible. Pour Marketing Cloud, cela entraîne généralement la création ou la mise à jour d'une extension de données partagées. |
| Gouvernance et conformité | Obligatoire | La Trust Layer applique automatiquement la validation du schéma, les métadonnées de consentement et les contrôles de politique pour garantir la conformité aux réglementations relatives à la protection des données et au marketing (par ex. RGPD, CCPA). |
| Surveillance et auditabilité | Meilleures pratiques | Chaque exécution d'activation est suivie avec des métriques de réussite/échec, des journaux d'exécution et la visibilité de la lignée dans le tableau de bord Trust Layer Monitoring, ce qui permet la transparence opérationnelle et l'assurance SLA. |
##### Résultats
- Les segments d'audience ciblés et enrichis de Data 360 sont disponibles directement sur les plates-formes marketing et publicitaires en aval.
- Les audiences sont automatiquement actualisées et synchronisées avec les toutes dernières données clients unifiées, ce qui maintient la pertinence des campagnes en temps réel.
- Les marketeurs peuvent utiliser ces audiences activées comme sources d'entrée pour des parcours Marketing Cloud, des campagnes par e-mail ou des audiences personnalisées dans des plates-formes publicitaires numériques telles que Google Ads, Meta ou LinkedIn Ads.
- Chaque exécution d'activation maintient la lignée de bout en bout, garantissant la conformité, la traçabilité et la cohérence entre Data 360 et les systèmes externes.
- Les utilisateurs professionnels peuvent offrir des expériences hautement personnalisées pilotées par les données, pilotées par une vue Customer 360 complète et approuvée.
###### Mécanismes d'appel
Le mécanisme d'appel dépend de la plate-forme de destination et de la configuration de la cible d'activation.
| Mécanisme | Quand utiliser |
|---|---|
| Activation de Marketing Cloud Engagement (préféré) | Utilisé lors de l'exécution d'e-mails ou de parcours intercanaux qui nécessitent des segments dynamiques, des attributs personnalisés et des mises à jour en temps réel dans Marketing Cloud. Data 360 exporte directement dans Extensions de données partagées pour l'activation de campagnes. |
| Activation de la plate-forme publicitaire (Google Ads, LinkedIn Ads, Meta Ads) | Utilisé lors de l'activation de segments Data 360 en tant qu'audiences personnalisées dans des plates-formes publicitaires pour le reciblage ou la modélisation similaire. Prend en charge les identifiants hachés et la livraison consciente du consentement. |
| Activation CRM (Sales ou Service Cloud) | Utilisé lors du partage de données clients enrichies, de connaissances ou de scores de propension avec des utilisateurs CRM pour des interactions d'engagement commercial ou de service personnalisées. Les données sont disponibles sous forme d'enregistrements ou de connaissances enrichis via des Actions de données ou des composants Profil unifié. |
| Activation externe via MuleSoft ou l'API | Utilisé lorsque l'activation doit atteindre des systèmes non-Salesforce tels que des entrepôts de fidélité, d'e-commerce ou de données tiers. MuleSoft ou l'API d'activation Data 360 garantit une livraison sécurisée et régie par une stratégie avec des options d'actualisation basées sur l'événement. |
| Activation hybride (batch + déclenchée par un événement) | Utilisé lors de la combinaison d'activations par lot planifiées avec des déclencheurs basés sur l'événement, qui activent la personnalisation « toujours activée » pour des campagnes urgentes telles que des alertes de panier d'achat abandonné ou de risque d'attrition. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Sélection du segment | Meilleur | Les analystes sélectionnent une définition de segment ou de requête existante dans Data 360\. Le segment détermine les enregistrements et les attributs exportés. |
| Configuration de l'activation | Meilleur | Les utilisateurs créent une nouvelle Activation, en choisissant le Segment comme source et la Cible de stockage Cloud (par exemple, S3) comme destination. |
| Configuration de la cible d'activation | Obligatoire | Les administrateurs préconfigurent la cible avec des identifiants, des rôles IAM et un chemin de sortie. Les formats pris en charge comprennent CSV, Parquet et JSON. |
| Définition de charge utile | Meilleures pratiques | Définissez le schéma d'exportation en sélectionnant les attributs requis (par exemple, ID, Nom, Adresse e-mail, Région, Indicateur de consentement). Le système applique automatiquement la gouvernance au niveau de l'attribut. |
| Planification et fréquence | Recommandé | L'exécution des exportations peut être planifiée sur une cadence définie (quotidienne, hebdomadaire, mensuelle) ou déclenchée manuellement si nécessaire. |
| Exécution et livraison | Meilleur | Lors de l'exécution, Data 360 interroge le segment, compile le fichier d'exportation, le crypte et l'écrit dans le compartiment/dossier configuré en utilisant l'API du fournisseur de cloud. |
| Gouvernance et conformité | Obligatoire | La Trust Layer de Data 360 garantit que toutes les exportations respectent les stratégies de consentement, la validation du schéma et les filtres de conformité. |
| Surveillance et auditabilité | Meilleures pratiques | Chaque exportation est suivie dans le tableau de bord Trust Layer Monitoring avec les métadonnées de statut, d'exécution et de lignage. |
##### Résultats
- Les segments d'audience ciblés et enrichis de Data 360 sont disponibles directement sur les plates-formes marketing et publicitaires en aval.
- Les audiences sont automatiquement actualisées et synchronisées avec les toutes dernières données clients unifiées, ce qui maintient la pertinence des campagnes en temps réel.
- Les marketeurs peuvent utiliser ces audiences activées comme sources d'entrée pour des parcours Marketing Cloud, des campagnes par e-mail ou des audiences personnalisées dans des plates-formes publicitaires numériques telles que Google Ads, Meta ou LinkedIn Ads.
- Chaque exécution d'activation maintient la lignée de bout en bout, garantissant la conformité, la traçabilité et la cohérence entre Data 360 et les systèmes externes.
- Les utilisateurs professionnels peuvent offrir des expériences hautement personnalisées pilotées par les données, pilotées par une vue Customer 360 complète et approuvée.
###### Mécanismes d'appel
Le mécanisme d'appel dépend de la plate-forme de stockage cloud cible et de la configuration d'activation.
| Mécanisme | Quand utiliser |
|---|---|
| Activation Amazon S3 | Utilisé lorsque votre lac de données d'entreprise est hébergé sur AWS. Data 360 écrit directement dans un compartiment S3 en utilisant des rôles IAM ou des identifiants temporaires, ce qui garantit une exportation sécurisée et évolutive. |
| Activation du stockage Azure Blob | Utilisé lorsque votre organisation fonctionne sur Microsoft Azure. Data 360 utilise des jetons SAS ou des principaux de service pour écrire des fichiers cryptés dans des conteneurs Blob. |
| Activation de Google Cloud Storage (GCS) | Utilisé lorsque vos charges de travail de science des données ou d'analyse sont exécutées sur GCP. Data 360 utilise des identifiants OAuth pour exporter des fichiers vers des compartiments GCS au format CSV ou Parquet. |
| SFTP ou passerelle de fichiers externe | Utilisé lorsque des systèmes réglementaires ou hérités nécessitent une livraison sécurisée de fichiers via des points de terminaison SFTP ou des plates-formes de transfert de fichiers gérées par l'entreprise. |
| Exportation hybride (fichier + API) | Utile lorsqu'une application en aval a besoin à la fois d'une exportation basée sur un fichier pour les analytiques et d'un déclencheur d'API pour l'orchestration de workflow (p. ex. flux MuleSoft). |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Authentification et enregistrement d'application | Obligatoire | Créez une application connectée dans Salesforce pour l'authentification basée sur OAuth 2.0. Configurez des étendues pour l'accès à l'API Data 360. |
| Accès aux données (profils, segments, connaissances) | Meilleur | Utilisez les points de terminaison de l'API Connect (/services/data/vXX.X/connect) pour interroger des données Data 360 harmonisées, des profils unifiés et des connaissances calculées. |
| Intégration de l'interface utilisateur | Meilleur | Les applications frontales (React, Angular, iOS, Android) appellent l'API Connect pour restituer les données Data 360 dans des tableaux de bord, des portails ou des interfaces mobiles. |
| Interrogation de Data Graph | Recommandé | Combinez l'API Connect à l'API Data Graph pour des requêtes de niveau sémantique qui simplifient les jointures et les relations complexes. |
| Actualisation en temps réel | Optional | Utilisez l'API Connect avec WebSocket ou des extensions de streaming pour les mises à jour de données live. |
| Sécurité et gouvernance | Obligatoire | Appliquez la visibilité des données en utilisant les étendues OAuth, les stratégies Data 360 et l'infrastructure d'audit Trust Layer. |
##### Résultats
Les développeurs peuvent créer des applications sécurisées et personnalisées étroitement intégrées à Data 360. Ces applications peuvent :
- Exposer des profils et des connaissances clients harmonisés en temps réel.
- Affichez les données Data 360 avec des objets CRM ou personnalisés via des API unifiées.
- Tirez parti de contrôles d'authentification, d'autorisation et d'audit cohérents via la Trust Layer.
- Offrez aux utilisateurs professionnels ou aux partenaires un accès transparent et régi à Intelligence client fiable à travers les expériences.
##### Mécanismes d'appel
Le mécanisme d'appel dépend de la plate-forme de stockage cloud cible et de la configuration d'activation.
| Mécanisme | Quand utiliser |
|---|---|
| API REST Connect (préféré) | Utilisez-les pour élaborer des applications Web, mobiles ou tierces qui nécessitent un accès en temps réel aux données Data 360 sous un format JSON convivial pour l'interface utilisateur. |
| API Data Graph | Utilisé lorsque l'application doit effectuer des requêtes de niveau sémantique à travers plusieurs objets (par exemple, Client → Transactions → Campagnes). |
| API de requête | Utilisez-les lors de l'exécution de requêtes de type SOQL pour récupérer des jeux de données harmonisés avec une grande précision. |
| API Einstein 1 Platform | Utilisez-les pour intégrer des connaissances pilotées par l’IA ou des recommandations générées par Copilot dans des interfaces utilisateur personnalisées. |
| MuleSoft ou Apex Gateway Wrappers | Utilisée lorsque l'orchestration, la mise en cache ou l'application de stratégies supplémentaires sont requises entre l'application et l'API Connect. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Définition du graphique de données | Obligatoire | Les architectes définissent un Data Graph qui combine plusieurs objets modèle de données en une seule entité sémantique (par exemple, UnifiedCustomerProfile). |
| Récupération de référence de profil | Meilleur | Les applications appellent GET /api/v1/dataGraph/{entity}/{id} pour récupérer des profils complets et dénormalisés par ID ou clé unique. |
| Utilisation des paramètres live | Optional | Ajoutez ?live=true pour forcer un nouveau calcul plutôt qu'une récupération mise en cache; adapté aux décisions importantes. |
| Authentification | Obligatoire | Utilisez OAuth 2.0 via des applications connectées pour authentifier les appels d'API en toute sécurité. |
| Analyse des réponses | Meilleure pratique | Les applications analysent la réponse JSON directement dans leur interface utilisateur ou leur moteur de décision. Aucune jointure supplémentaire n'est requise. |
| Stratégie de mise en cache | Recommandé | Implémentez la mise en cache locale à court terme (par exemple en mémoire ou CDN) pour les références de profil répétées. |
| Monitoring & Observability | Obligatoire | Utilisez les tableaux de bord Trust Layer pour surveiller les performances des requêtes, les temps de réponse et l'adhésion aux stratégies. |
##### Résultats
Les applications peuvent désormais récupérer instantanément un profil client complet et pré-joint, ce qui permet des interactions en temps réel telles que la personnalisation, le service et l'automatisation des décisions.
Ce schéma garantit :
- Temps de réponse inférieur à la seconde pour la prise de décision instantanée.
- Récupération de données cohérente et régie alignée sur le modèle sémantique Data 360.
- Logique d'application simplifiée : aucune jointure, aucun rapprochement de schéma.
- Accès traçable et conforme via la Trust Layer pour l'audit et l'observabilité.
###### Mécanismes d'appel
Le mécanisme d'appel dépend de la plate-forme de stockage cloud cible et de la configuration d'activation.
| Mécanisme | Quand utiliser |
|---|---|
| API Data Graph (préféré) | Utilisé pour récupérer instantanément des profils prématérialisés complets par ID ou clé. |
| API Data Graph avec live=true | Utilisez-le pour des cas d'utilisation à valeur élevée (p. ex. détection de fraude, offres live) dans lesquels les données les plus récentes sont requises, en acceptant une latence légèrement plus élevée. |
| API Connect (Fallback) | Utilisé pour des scénarios d'application composite combinant des récupérations de Data Graph à d'autres données Salesforce. |
| API de requête | Utilisé lors de la construction de requêtes ad hoc ou de lectures analytiques plutôt que de la récupération instantanée de profils. |
| MuleSoft API Proxy | Utilisé lors de l'acheminement des appels Data Graph via des passerelles d'entreprise ou lorsqu'une orchestration/application de politiques supplémentaires est requise. |
| Zone de solution | Ajustement | Commentaires / Détails d'implémentation |
|---|---|---|
| Action Données en temps réel | Meilleur | Point de terminaison d'exposition pour les déclencheurs de lecture/écriture et d'action à enregistrement unique. Authentifiez-vous via OAuth/JWT. |
| Résolution de l'identité | Obligatoire | Résolvez les identifiants entrants (e-mail, externalId, cookie) dans ID d'individu unifié en ligne. Utilisez un résolveur déterministe avec cache. |
| Application des politiques (CEDAR) | Meilleures pratiques | Évaluez les politiques de consentement, d'ABAC et de masquage à la demande, refusez ou masquez les champs par décision de politique. |
| Couche Bord/Cache | Recommandé | Utilisez des caches TTL courts pour les fragments de profil et les connaissances calculées afin de réduire la latence; invalidez lors d'événements de modification. |
| Transformations légères | Recommandé | Appliquez de simples enrichissements ou des champs calculés dans le parcours d'action ; les transformations lourdes doivent être précalculées. |
| Orchestration d'action | Meilleur | Prenez en charge les actions synchrones à une étape (par exemple, jeton d'offre de retour) et les orchestrations asynchrones (file d'attente \+ webhook) pour les flux complexes. |
| Observabilité et traçabilité | Obligatoire | Consignez les demandes/réponses, les décisions stratégiques et la lignée dans la Trust Layer/SIEM pour vérification et débogage. |
| Limitation tarifaire et limitation | Obligatoire | Appliquez des quotas clients et des stratégies de dégradation gracieuses pour les moments à fort trafic. |
##### Résultats
- Les applications reçoivent un accès immédiat, régi par la politique, aux lectures/écritures de profil unifié et aux déclencheurs d'action avec une latence de la seconde à la seconde.
- La personnalisation en temps réel, la prise de décision et les workflows opérationnels (p. ex. offres, assistance de l'agent, mises à jour d'inventaire) sont activés sans délai par lot.
- Toutes les actions peuvent être auditées, sont sensibles au consentement et appliquent automatiquement le masquage au niveau de l'attribut pour préserver la confidentialité et la conformité.
###### Mécanismes d'appel
Le mécanisme d'appel dépend de la plate-forme de destination et de la configuration de la cible d'activation.
| Mécanisme | Quand utiliser |
|---|---|
| API RESTful Data Actions | Préféré pour les applications Web/mobiles et les middlewares qui nécessitent des lectures de profil ou des réponses d'action synchrones. |
| gRPC / Binary RPC | Utilisé pour les services d'entreprise à très faible latence ou les microservices internes avec des connexions permanentes. |
| Requêtes GraphQL à enregistrement unique | Utile lorsque les clients doivent sélectionner des champs flexibles et souhaitent réduire les charges utiles. |
| Webhooks déclenchés par un événement | Utilisé pour les workflows asynchrones dans lesquels une action déclenche des processus en aval (par exemple, démarrer un parcours). |
| Événements de plate-forme / PubSub | Utilisé pour les scénarios de déploiement dans lesquels plusieurs systèmes doivent réagir à un événement d'action unique. |
| Edge SDK (libs client) | Utilisé pour les clients à faible latence qui mettent en cache les fragments de profil et appellent l'API Actions de données uniquement en cas de besoin. |
_Architecte en chef, Salesforce_
## 2\. Présentation de l'architecture
Les principes architecturaux de Salesforce Platform ci-dessous capturent les fondements et la différenciation de la conception des fonctionnalités et des capacités :
- **Enterprise-Grade Trust**: Trust est la valeur n°1 de Salesforce, et nous donnons la priorité non seulement à la disponibilité et à la sécurité de nos services, mais nous élaborons également les fonctionnalités de contrôle d'accès, de conformité et de sécurité afin que nos clients puissent respecter leurs normes de conformité et de sécurité avec Salesforce Platform.
- **Multitenant**: Tous les services et infrastructures sont conçus pour héberger plusieurs clients. Cela fournit un modèle stratégique pour l'évolutivité avec l'utilisation, ainsi que la normalisation sur une barre élevée commune de disponibilité et de sécurité, quelle que soit la taille de nos clients.
- **Métadonnées pilotées**: Les métadonnées sont au cœur de la personnalisation de nos services multilocataires. Nos métadonnées sont extensibles afin de permettre aux administrateurs et aux développeurs de s'appuyer sur les travaux existants, et de bénéficier des futures mises à jour produits de Salesforce et de partenaires de l'écosystème.
- **API First :** Salesforce Platform donne la priorité à un portefeuille d'API riche et cohérent qui couvre tout ce qui peut être fait via des interfaces utilisateur natives de Salesforce. Cela permet aux développeurs et partenaires d'exploiter et de recomposer les fonctionnalités de la plate-forme pour intégrer des systèmes ou élaborer de nouvelles expériences utilisateur.
- **Ouvert et interopérable**: Salesforce Platform peut être intégrée à l'architecture d'entreprise de tous nos clients. Nous avons conçu Salesforce Platform pour fonctionner avec d'autres systèmes cloud et on-prem, et fournir des API, des outils et des normes d'intégration pour les systèmes externes à intégrer à Salesforce Platform.
- **Agent :** Salesforce Platform évolue rapidement pour devenir l'agent principal dans toute la suite d'applications. Nous souhaitons que les utilisateurs puissent interagir avec Salesforce à travers des expériences conversationnelles profondes qui leur permettent de travailler et d'interagir avec leurs données de façon de plus en plus naturelle.
L'actuelle Salesforce Platform représente la dernière étape de l"évolution des capacités de Salesforce depuis les débuts de 2008 de Force.com Platform. Les transformations clés récentes comprennent :
- Adoption d'Hyperforce et passage aux architectures basées sur le cloud.
- Évolution d'une architecture monolithique à une structure avec des services indépendants.
- Introduction des technologies Data 360 et Lakehouse aux côtés des magasins de données relationnelles traditionnels.
- Une intégration profonde des technologies d’IA, de l’apprentissage génératif et machine, et une évolution vers des expériences agentiques à travers la plate-forme.
Ces modifications ont étendu et affiné les capacités de la plate-forme sans interruptions importantes, grâce à des abstractions robustes qui permettent aux ingénieurs Salesforce de faire progresser nos technologies de façon transparente en limitant au maximum les interruptions avec les clients. L'abstraction robuste reste également essentielle à l'intérêt de Salesforce Platform, qui simplifie les complexités techniques des logiciels d'entreprise, notamment la sécurité, la disponibilité et les conventions technologiques, afin que les développeurs d'applications puissent se concentrer sur la résolution de leurs défis uniques. Les capacités de Salesforce Platform sont présentées ci-dessous :
Salesforce Platform est affichée sous la forme d'un ensemble de couches composant le système. Chaque couche représente un groupe de fonctionnalités associées importantes pour les applications élaborées sur la plate-forme. Les sous-encadrés de chaque couche fournissent des exemples de ces capacités. Les capacités de chaque couche inférieure sont intégrées à toutes les couches ci-dessus, ce qui garantit une expérience cohérente et cohérente dans toute la suite d'applications Salesforce.
Salesforce Platform incarne des transformations d'ingénierie étendues à travers toutes les couches d'une plate-forme technologique mature développée au cours des 20 dernières années. Sous l'impulsion de l'évolution des demandes des clients et des nouvelles technologies, ces modifications permettent de prendre en charge de nouveaux types d'application et de nouvelles solutions. Les transformations sont interconnectées, les changements dans les couches inférieures influençant l'évolution de toutes les couches suivantes ci-dessus.
Salesforce Platform est structurée en plusieurs couches, chacune contribuant à ses capacités complètes :
- **Hyperforce**: L'infrastructure de base a évolué de centres de données internes à des fournisseurs de cloud publics, améliorés avec les technologies Salesforce pour un hébergement sécurisé, conforme, hautement disponible et économique.
- **Infrastructure de métadonnées**: Fournit une abstraction stable sur laquelle les applications peuvent s'appuyer, même si les technologies dont nous disposons et que nous utilisons évoluent. Inclut un mappeur relationnel objet, un ordre d'exécution prescriptif et une exécution « principale » qui relie les définitions de métadonnées aux exécutions pilotées par les métadonnées.
- **Données**: Inclut une base de données relationnelle multilocataire et Lakehouse à l'échelle du pétaoctet pour gérer les données Salesforce et non-Salesforce, prenant en charge la gestion des données et des contenus non structurés, la recherche avancée, la gouvernance et les capacités de traitement analytique.
- **IA**: S'appuie sur la couche de données avec des technologies d'Intelligence artificielle approuvées qui exploitent l'IA prédictive et générative pour piloter les expériences des agents.
- **Services de plate-forme d'application :** Fournit des outils permettant aux administrateurs, développeurs et fournisseurs informatiques d'élaborer et de personnaliser des applications, en offrant une abstraction éclairée pour simplifier les tâches courantes et complexes.
- **Capacités commerciales**: Offre une gamme de capacités pour répondre à divers besoins métiers, permettant aux développeurs d'adapter les applications aux besoins.
- **API et gestion des API**: Garantit que toutes les capacités de la plate-forme sont accessibles via des API bien formées, ce qui facilite les interdépendances de service et de couche.
- **Expérience utilisateur et développeur**: Présente des interfaces conviviales pour les utilisateurs finaux et une gamme d'outils de développement allant du code faible au pro-code pour le développement et la personnalisation d'applications, avec la prise en charge du développement moderne piloté par l'IA.
- **Intégration**: Intègre à n'importe quelle architecture d'entreprise, ce qui permet la compatibilité avec Salesforce et les systèmes non-Salesforce via des connecteurs de données, l'intégration de données sans copie et d'autres outils.
- **Applications et industries**: Fournit une suite d'applications personnalisables et de solutions spécifiques au secteur d'activité basées sur les capacités intégrées de la plate-forme, exploitant la gamme complète de fonctionnalités de niveau inférieur et avec des agents IA profondément intégrés.
## 3\. Hyperforce
Salesforce développe une infrastructure de centre de données globale depuis près de 25 ans, antérieure à de nombreux hyperscalers et fournisseurs IaaS actuels. Hyperforce, la génération actuelle de l"évolution de l'infrastructure de Salesforce, est conçue pour fonctionner à travers plusieurs fournisseurs de cloud publics dans le monde.
Il est adapté aux besoins des clients en matière d'échelle B2C élastique, de résidence globale des données, de disponibilité accrue, de sécurité de niveau supérieur et de conformité réglementaire. Hyperforce standardise l'infrastructure dans tous les produits Salesforce, ce qui facilite l'intégration rapide des nouvelles acquisitions.
Hyperforce assure la livraison de Salesforce Platform, permettant un déploiement rapide de nouvelles fonctionnalités et applications, répondant aux exigences de résidence des données et de conformité réglementaire dans plus de 20 régions à travers le monde.
### 3.1 Principes architecturaux
Lors de la transition de Salesforce vers Hyperforce, des différences significatives dans les services, les interfaces et les niveaux de conformité entre les hyperscalers ont été identifiées. Pour construire une fondation robuste et portable pour Salesforce Platform, les principes architecturaux suivants ont été adoptés :
- **Infrastructure comme code**: En utilisant une architecture pilotée par le domaine, ce principe implique un codage déclaratif pour l'infrastructure, la création d'artefacts immuables et l'automatisation de l'infrastructure à la demande en utilisant des normes telles que Kubernetes et Service Mesh.
- **Zero-Trust Security**: Implémentation d'un modèle de sécurité zéro Trust avec des stratégies de défense complètes comprenant la gestion de l'identité, l'authentification, l'autorisation, l'isolation du réseau, des stratégies de sécurité avec le moindre privilège et le cryptage des données en transit et au repos.
- **Services gérés**: Mettant l'accent sur l'utilisation de services multilocataires et multicloud, ce principe améliore la portabilité à travers différentes infrastructures et environnements tels que les systèmes commerciaux, gouvernementaux et aériens.
- **Résilience intégrée**: Les services critiques sont répartis entre plusieurs zones de disponibilité pour garantir une haute disponibilité. Les données sont répliquées entre les zones Disponibilité. Les services sont également étiquetés avec le niveau de disponibilité pour gérer les objectifs de niveau de service et la planification de la résilience.
- **Entièrement observable**: L'intégration de tous les services à une plate-forme d'observabilité standard pour une surveillance efficace, qui comprend la collecte de journaux, la collecte de métriques, les alertes, le traçage distribué et le suivi des opérations de service telles que le volume de trafic, les taux d'erreur et l'utilisation des ressources.
- **Opérations automatisées**: Cela inclut la gestion automatisée du cycle de vie de l'infrastructure et les AIOps prédictifs (IA pour les opérations) pour maintenir la qualité du service, détecter et résoudre les dégradations du service, et détecter les pannes.
- **Échelle automatisée**: Axé sur l'évolutivité et le rapport coût-efficacité, ce principe offre une flexibilité opérationnelle à différentes échelles sans augmenter les risques opérationnels, en éliminant les limites de compte spécifiques liées au fournisseur cloud.
- **FinOps Aware**: Public Cloud apporte de l'agilité à l'infrastructure, mais avec le risque de coûts élevés. Nous adoptons une culture d'ingénierie axée sur l'efficacité tout au long du cycle de vie du service, sans compromettre la disponibilité, la sécurité et la Trust client.
Ces principes guident le développement et l'exploitation de la plate-forme Hyperforce de Salesforce, garantissant son adaptabilité, sa sécurité et son efficacité dans divers environnements.
### 3.2 Concepts d'infrastructure
Salesforce Platform et ses services de support fonctionnent sur Hyperforce Foundation, qui comprend plusieurs instances Hyperforce. Ces instances sont stratégiquement distribuées à travers divers pays pour refléter les préférences géographiques et de disponibilité des clients. Pour satisfaire aux exigences strictes en matière de résidence des données et d'exploitation, une ou plusieurs instances Hyperforce peuvent être regroupées et désignées en tant que Zone d'exploitation. Chaque instance est régulièrement mise à jour pour garantir la sécurité, l'évolutivité et la conformité aux normes locales et légales.
Les instances Hyperforce sont composées de plusieurs instances Domaine fonctionnel Hyperforce, qui sont des clusters de services délivrant des fonctionnalités spécifiques. Les domaines fonctionnels de base fournissent des services critiques tels que la sécurité, l'authentification, la consignation et la surveillance, qui sont tous essentiels pour les autres services Hyperforce. Les domaines fonctionnels métiers prennent en charge divers produits Salesforce tels que Sales Cloud, Service Cloud, et d'autres, ce qui facilite leur fonctionnement produit.
Les services d'un domaine fonctionnel peuvent être organisés en cellules, qui sont des unités de prestation de services évolutives et reproductibles. La Cellule Hyperforce correspond à ce que l'on appelle traditionnellement une " instance Salesforce " dans laquelle résident une ou plusieurs organisations (organisations) Salesforce. Une cellule est une unité d'échelle ainsi qu'une limite de rayon de souffle forte. Les supercellules fournissent un regroupement logique de plusieurs cellules pour délimiter un rayon d'explosion plus grand en raison des services partagés entre les cellules. Plusieurs supercellules peuvent être présentes dans un domaine fonctionnel. Les cellules et les supercellules permettent à Hyperforce d'évoluer horizontalement dans un domaine fonctionnel tout en gardant un contrôle fort sur la taille du rayon d'explosion.
Chaque instance Hyperforce est mappée avec une zone de disponibilité, un concept présent dans toutes les infrastructures cloud publiques, et est capable de fonctionner indépendamment de toutes les autres instances Hyperforce. Tous les services et toutes les données critiques de l'instance Hyperforce sont distribués et répliqués à travers au moins trois zones de disponibilité, afin d'atteindre la tolérance aux pannes et la stabilité. De plus, les sauvegardes de données sont copiées dans d'autres instances Hyperforce appropriées pour la continuité de l'activité et la conformité réglementaire.
L'infrastructure Hyperforce évolue constamment, à mesure que de nouvelles instances et cellules Hyperforce sont créées ou actualisées en place. Les clients sont à l'abri des modifications apportées aux détails physiques d'Hyperforce. Tous les points de terminaison clients visibles en externe sont accédés via Mes domaines Salesforce stables et sécurisés (par exemple, acme.my.salesforce.com) qui acheminent en toute sécurité le trafic vers l'emplacement de données et de service actuel. Il est préférable d'implémenter le trafic sortant (p. ex. courrier, appels Web) en utilisant des mécanismes sécurisés tels que Domain Keys Identified Mail (DKIM) et mTLS, afin de s'assurer que l'infrastructure sur site des clients ne code pas en dur les détails physiques de l'infrastructure Salesforce, par exemple les adresses IP qui peuvent changer au fil du temps.
### 3.3 Sécurité du réseau
Les domaines fonctionnels Hyperforce sont conçus avec des mesures de sécurité robustes. Chaque domaine est sécurisé au périmètre et isolé, avec des services dans un domaine séparé en comptes dédiés pour plus de sécurité. La communication entre les services est facilitée en toute sécurité via Service Mesh ou des protocoles similaires. La gestion du trafic est gérée par des passerelles d'entrée et de sortie qui inspectent, acheminent et appliquent les contrôles nécessaires tels que des disjoncteurs ou des limites de taux à tout le trafic entrant et sortant.
Les services d'un domaine fonctionnel Hyperforce sont regroupés en groupes de sécurité, seuls ceux du groupe edge étant exposés à l'Internet public. Les stratégies de sécurité à l'exécution appliquent les règles de communication entre les différents groupes de sécurité, en adhérant au principe du moindre privilège pour garantir que les services n'ont que l'accès nécessaire.
Chaque région géographique a un domaine fonctionnel Hyperforce Edge qui met fin à la sécurité de la couche transport et emploie des stratégies de pare-feu d'application Web programmables pour faire face préventivement aux menaces. Ainsi, seul le trafic légitime atteint les points de terminaison Hyperforce tout en préservant une expérience client sécurisée et efficace. De plus, les liens réseau internes entre les instances Hyperforce sont étroitement contrôlés, et toutes les données du journal contenant des informations d'identification personnelle sont anonymisées pour respecter les normes RGPD.
### 3.4 Plan de contrôle de grille Hyperforce
Une grille Hyperforce comprend plusieurs instances Hyperforce partageant le même plan de contrôle, qui est conçu pour isoler les charges de travail sensibles le cas échéant. Il garantit l'absence de fuite de données clients ou système, de métadonnées de plate-forme ou de données de surveillance à travers les grilles. Le Plan de contrôle est composé d'instances Hyperforce redondantes qui hébergent des services essentiels pour créer, gérer et surveiller les instances Hyperforce accessibles aux clients.
Le code de service et d'infrastructure de tous les services Hyperforce est développé en toute sécurité dans un domaine fonctionnel de plan de contrôle dédié, en utilisant des services de gestion du code source, d'intégration continue, de test et d'élaboration d'artefacts. Le code généré est analysé pour détecter les menaces et les vulnérabilités avant d'être empaqueté dans des conteneurs standardisés signés numériquement et stocké dans des registres d'images. Le déploiement de code est géré par des pipelines autorisés dans le système Hyperforce Continuous Delivery, avec des privilèges de déploiement limités aux équipes et opérateurs autorisés. Un avion de contrôle Airgapped gère les mesures de protection supplémentaires nécessaires dans de tels environnements.
Les services IAM (Identity and Access Management) appliquent automatiquement l'approbation juste à temps pour limiter la durée d'accès et les actions, tandis que les pistes d'audit surveillent toutes les activités, alimentant les systèmes de détection en temps réel pour identifier et alerter sur toute activité suspecte.
### 3.5 Gestion des coûts Hyperforce
Alors que Salesforce migre ses services vers Hyperforce sur les clouds publics depuis ses centres de données internes, il est crucial de revoir nos stratégies de création de budget, de visualisation des coûts et d'optimisation des ressources.
Notre approche de gestion des coûts ne se limite pas à réduire les coûts, mais est un processus stratégique qui différencie les produits axés sur la croissance de ceux stables. Elle prévoit des prix basés sur la consommation et des marges qui respectent la disponibilité des produits, en s'alignant sur notre valeur principale Trust. Les comptes Cloud publics sont organisés hiérarchiquement et liés à des produits et des dirigeants spécifiques. Le balisage détaillé des ressources au niveau du service, enrichi de métadonnées organisationnelles, aide à identifier les coûts des microservices individuels. Des outils tels que Tableau et Slack, ainsi que des outils de prévision avancés, sont utilisés pour fournir aux dirigeants et aux équipes des données en temps réel sur les coûts, les prévisions et les analyses budgétaires, ce qui inspire confiance dans la planification financière future.
Pour garantir une gestion optimale des coûts, Salesforce utilise une combinaison de Plans d'économies de calcul, Capacité spot et Réservations de capacité à la demande (ODCR), garantissant la capacité nécessaire. Ces réservations sont gérées par des prévisions temporelles avancées et des tableaux de bord personnalisés, ce qui permet une supervision humaine et la prise de décision. La définition d'objectifs réalisables de réduction des coûts transactionnels unitaires (coût de traitement d'un volume défini de transactions commerciales) est une stratégie efficace pour favoriser les améliorations. L'outil Hyperforce Unit Cost Explorer permet aux équipes d'analyser et de gérer les tendances des coûts unitaires, en attribuant des coûts à des services spécifiques, et en identifiant de nouvelles opportunités d'amélioration. L'indice d'optimisation Salesforce Cloud, ou score « COIN », évalue les services par rapport à une liste dynamique d'opportunités d'économies, ce qui motive les équipes de service à maintenir une efficacité optimale des ressources.
Dans notre engagement inébranlable envers le développement durable, nous poursuivons activement la réduction de notre empreinte carbone, en fixant des objectifs spécifiques pour réduire notre unité Carbon to Serve, une mesure des émissions par rapport au travail effectué.
## 4\. Enterprise-Grade Trust
La sécurité et la disponibilité sont des aspects fondamentaux cruciaux de notre plate-forme de niveau entreprise, essentiels pour maintenir la Trust client. Chez Salesforce, ces contrôles font partie intégrante de Salesforce Platform, automatiquement appliqués via des services partagés et des infrastructures logicielles. Cette approche intégrée garantit que les systèmes individuels en bénéficient sans effort supplémentaire.
Gérer et améliorer en permanence cette vaste gamme de contrôles de sécurité et de disponibilité à travers des milliers de services et des centaines d'équipes représente un défi de taille. Cependant, c'est crucial, car l'oubli d'un détail mineur peut entraîner une faille de sécurité ou une panne du système.
### 4.1 Sécurité
Hyperforce est une plate-forme d'infrastructure sécurisée et conforme qui prend en charge le développement et le déploiement de services avec des fonctionnalités de sécurité avancées. Il offre un contrôle d'accès renforcé, le cryptage des données et la conformité aux normes de sécurité. Salesforce adhère à plus de 40 normes de sécurité et de conformité telles que PCI/DSS, GDPR, HIPAA, FedRamp, et davantage.
Les principes de sécurité clés comprennent Zero Trust Architecture (ZTA) et le cryptage de bout en bout, garantissant la protection des données des clients à travers toutes les étapes de traitement. Salesforce respecte les normes de sécurité et les meilleures pratiques depuis le cycle de vie sécurisé du développement logiciel jusqu'aux opérations de production, ainsi que des pratiques de sécurité robustes au niveau de l'application pour limiter les menaces potentielles.
#### Zero Trust Architecture (ZTA)
Le paradigme de cybersécurité ZTA garantit que tous les utilisateurs, appareils et connexions de service subissent une authentification, une autorisation et une validation continue, quel que soit leur emplacement. La ZTA et l'infrastructure à clé publique (PKI) sont essentielles pour la cybersécurité moderne, en établissant des frontières Trust et en sécurisant la communication sans compter sur la sécurité du périmètre.
Cependant, les déploiements d'ICP négligent souvent l'importance de la révocation de certificats et de la gouvernance sur les autorités de certification racine. L'implémentation de la révocation de certificats par Salesforce est robuste et évolutive, prenant en charge la sécurité de l'ICP de bout en bout.
De plus, Hyperforce applique automatiquement la ZTA via la sécurité mutuelle de la couche transport entre les services, en utilisant des clés privées éphémères et un accès juste à temps pour les utilisateurs avec un contrôle d'accès basé sur le rôle.
#### Cryptage de bout en bout
Salesforce Platform garantit la protection des données en transit en utilisant le protocole TLS avec des suites de cryptage à secret avancé parfait, qui sécurisent les données lorsqu'elles transitent à travers le réseau entre les appareils utilisateur et les services Salesforce, ainsi que dans les domaines d'infrastructure Salesforce.
Pour les données au repos, Salesforce Platform utilise un système de gestion des clés pris en charge par des modules de sécurité matérielle. Dans sa plate-forme multilocataire, chaque locataire se voit attribuer une clé de cryptage unique, empêchant tout croisement de clés entre locataires.
La sécurité de la communication et du cryptage dépend fortement de l'entropie de génération de clés ou de données aléatoires. Reconnaissant la vulnérabilité des protocoles cryptographiques aux attaques dues à la génération de clés prévisible, Salesforce Platform atténue ce risque en s'approvisionnant en entropie d'origines multiples pour tous les processus de génération de clés. Nous exploitons la fonctionnalité de cryptage de la mémoire disponible dans divers processeurs, activée par un fournisseur de services cloud, pour renforcer la protection contre les attaques par démarrage à froid.
#### Cycle de vie de développement de logiciels sécurisé
Salesforce a un JDK personnalisé pour satisfaire à de nombreuses normes de conformité, telles que Federal Information Processing Standard (FIPS), ce qui simplifie le processus pour les développeurs et les opérateurs en éliminant la nécessité pour eux d'entreprendre eux-mêmes un travail de conformité. Cette personnalisation permet non seulement de prévenir les risques tels que l'injection d'entités externes XML (XXE), mais également d'améliorer l'agilité cryptographique de Salesforce et sa capacité à échanger des stratégies cryptographiques si nécessaire. Il permet de transformer un code non conforme (qu'il soit développé en interne ou provenant de référentiels ouverts) en code conforme FIPS sans nécessiter une réécriture complète, réduisant ainsi la charge de travail des équipes de développement et maintenant l'adhésion aux principes de conception sécurisé par défaut.
De plus, Salesforce a incorporé des infrastructures pour lutter contre les vulnérabilités telles que le script inter-site (XSS), la falsification de requêtes (CSRF) et l'injection SQL en intégrant des mesures de protection au cycle de vie sécurisé du développement logiciel (SSDL).
Un système centralisé de gestion des secrets, renforcé par des contrôles d'accès basés sur le rôle (RBAC), est mis en œuvre pour sécuriser à la fois les services et l'accès des utilisateurs. En outre, des outils de lecture de code sont utilisés pour empêcher l'exposition accidentelle de secrets dans des environnements de production grâce à des systèmes de gestion de code source.
#### Capacités de sécurité opérationnelle Hyperforce
L'hameçonnage reste une menace importante pour les organisations, ce qui conduit Salesforce à mettre en place l'authentification multifacteur résistante à l'hameçonnage (MFA) conformément à un certain nombre de meilleures pratiques de l'industrie, notamment les principes Zero Trust CISA (Cybersecurity and Infrastructure Security Agency). Cela inclut des clés matérielles pour les employés qui ont un accès en production et un noyau sécurisé pour un accès contrôlé aux comptes de fournisseurs de services cloud.
Pour maintenir un dispositif de sécurité robuste, Salesforce a standardisé les contrôles de sécurité et intégré des services de sécurité natifs du cloud dans Hyperforce, offrant une visibilité, une détection des menaces et une application des politiques améliorées. Un système complet d'information de sécurité et de gestion des événements est en place pour la surveillance, les alertes et les rapports en temps réel, qui est soutenu par un programme complet de gestion des vulnérabilités et des outils de gestion du dispositif de sécurité cloud pour identifier, évaluer et corriger en permanence les vulnérabilités.
De plus, un pare-feu d'application Web filtre et surveille le trafic HTTP pour se protéger contre diverses attaques, et une série d'outils de sécurité réseau, notamment des pare-feux, des systèmes de détection et de prévention des intrusions, des réseaux privés virtuels, et des agents de détection et de réponse aux points de terminaison, sont utilisés pour assurer une surveillance continue et la détection des menaces. La segmentation du réseau et la micro-segmentation sont implémentées pour minimiser la surface d'attaque et contenir les brèches potentielles.
Salesforce a également développé et implémenté un solide plan de réponse aux incidents adapté aux défis uniques d'Hyperforce, comprenant des procédures prédéfinies pour identifier, contenir et atténuer les incidents de sécurité, garantissant une réponse rapide et efficace aux menaces potentielles pour la sécurité.
### 4.2 Disponibilité
Salesforce gère les charges de travail clients critiques qui nécessitent une haute disponibilité. Notre stratégie de haute disponibilité comprend diverses facettes organisationnelles telles que notre modèle de propriété du service, la gestion des incidents et les examens opérationnels. Les éléments techniques clés de notre stratégie comprennent notre architecture de surveillance, l'automatisation des opérations pilotée par l'IA et les mécanismes de sécurité automatisés pour les changements en production.
#### Normes d'architecture de disponibilité
Pour garantir une disponibilité élevée dans des milliers de services, une approche en trois étapes gère les risques techniques à grande échelle.
Tout d'abord, des normes d'architecture de disponibilité sont établies, définissant les meilleures pratiques telles que :
- **Redondance avec basculement automatisé**. Pour gérer les pannes constantes rencontrées par un grand système basé sur le cloud, Salesforce élabore ses services avec un niveau élevé de redondance, une détection des pannes entièrement automatisée et une restauration automatisée transparente pour les pannes complètes et partielles.
- **Rayon d'explosion** limité. Des échecs _seront_ rencontrés, et l'équipe conçoit donc tous ses services avec des maximums de rayon d'explosion intentionnels pour limiter l'impact des échecs. L'exemple le plus classique et le plus visible est celui de la Cellule Hyperforce (fka Pod).
- **Compartimentez les échecs**. Empêche la propagation et l'aggravation des pannes entre les unités indépendantes du système. Les appels d'API tolérants aux pannes entre les services sont un modèle clé qui empêche une cascade d'échecs à travers le système distribué. En cours de route, l'équipe met soigneusement en balance compartimentation et redondance.
- **Évoluez automatiquement**. Pour servir une charge imprévisible sans dégradation des performances, augmentez et réduisez automatiquement rapidement, sans dépendre d'opérateurs humains lents et faillibles, déclenchés par des points de saturation de ressources telles que le processeur, la mémoire ou les profondeurs de file d'attente.
- **Reculs rapides**. Nous définissons des objectifs de restauration en minutes pour tous les services, et testons automatiquement les restaurations dans des environnements de préproduction en définissant l'opération par défaut roll-forward, back et forward again. L'équipe utilise largement les indicateurs de fonctionnalité pour accélérer et affiner les commutateurs d'urgence et les déploiements.
- **Protégez tous les services qui reçoivent des appels d'API**. Délestage, limites en locataires équitables, pare-feux d'application Web et protections sophistiquées de couche 7 sont déployés à tous les niveaux du système, depuis nos services périmétriques externes exposés directement à Internet jusqu'aux services internes les plus profonds de l'équipe qui peuvent être accidentellement attaqués par des bogues dans des services d'appels de niveau supérieur.
- **Améliorez les dépendances**. Les dépendances entre les services sont conçues pour être souples dans la mesure du possible afin de permettre leur échec ou leur réussite indépendamment. La mise en cache est l'un des schémas les plus courants ici - souvent un résultat périmé d'une dépendance en aval est suffisant pour une fonction continue.
- **Favorisez la communication asynchrone**. Une communication asynchrone et négociée entre les services découple ces services les uns des autres et met en tampon les pics de charge entre eux.
- **Faites des appels d'API tolérants** aux défauts. Pour être tolérant aux pannes partielles et aux problèmes réseau transitoires, nous utilisons plusieurs modèles : expirations et délais, coupure de circuit et tentatives avec backoff. Nous préférons les appels non bloquants dans la mesure du possible afin de limiter la consommation de ressources et le blocage. La rétro-compatibilité et la rétro-compatibilité sont automatiquement appliquées avec le linting au niveau du schéma lors de la construction et des tests d'intégration.
- **Gérer les quotas et contraintes** de service. L'équipe définit des quotas et des contraintes à travers son parc de services, par exemple les adresses IP, les IOp disque ou la capacité d'un cluster Kubernetes donné. L'équipe agrège, surveille et alerte contre l'utilisation de ces quotas et contraintes de façon centralisée afin d'éviter qu'une limite proche impacte le système à l'exécution.
Deuxièmement, un modèle d'inspection à plusieurs niveaux garantit que les services respectent ces normes. Cela comprend des tests automatisés du chaos, la numérisation et la détection des anti-modèles, et des examens d'architecture avec des architectes chevronnés afin de détecter les problèmes non résolus par l'automatisation.
Troisièmement, des solutions sont intégrées à Hyperforce pour faciliter l'adhésion à ces normes. Cela inclut la collecte automatique de télémesures, la redondance par défaut et les mécanismes de basculement, et des protections intégrées telles que le délestage et la défense DDoS, le tout activé par défaut pour des services individuels.
#### Surveillance et observation
Salesforce gère un volume considérable de données télémétriques, notamment des métriques, des journaux, des événements et des traces, que les solutions de surveillance traditionnelles ne peuvent pas toujours gérer efficacement.
Pour y remédier, Salesforce a développé un système d'observabilité complet qui s'intègre à son cycle de développement logiciel, à ses opérations et à ses fonctions de support. Ce système offre une expérience unifiée aux équipes d'ingénierie et de support client, tout en répondant aux besoins d'échelle et en réduisant les coûts de licence des logiciels tiers.
L'infrastructure de métriques de Salesforce, basée sur OpenTSDB et HBase, prend en charge la collecte, le stockage et l'interrogation en temps réel de données temporelles. Les cas d'utilisation non temps réel utilisent Trino et Iceberg, qui gèrent plus de 2 milliards de métriques par minute pour recueillir des connaissances sur l'utilisation du processeur, l'utilisation de la mémoire et les taux de requête. Pour la gestion des journaux, Salesforce utilise Splunk pour ses puissantes capacités d'indexation et de recherche. Apache Druid prend en charge l'ingestion et l'analyse en temps réel de données d'événements à grande échelle, essentielles pour comprendre les interactions des utilisateurs et les événements système. Le traçage distribué entre les microservices est géré avec OpenTelemetry et ElasticSearch, ce qui aide à identifier des points de latence et de défaillance spécifiques.
Salesforce a également implémenté une infrastructure APM (Application Performance Monitoring) qui s'intègre à ses piles technologiques pour la collecte de données et les magasins de télémétrie. Cette instrumentation automatique des applications simplifie la collecte de données et garantit une télémétrie cohérente entre les services. Le tableau de bord unifié d'APM corrèle divers types de données, ce qui améliore la capacité des ingénieurs à surveiller les performances, à diagnostiquer les problèmes et à optimiser les systèmes via une interface cohérente.
En standardisant les outils d'observabilité, Salesforce associe différents types de télémétrie entre les services en utilisant le traçage distribué. Vous créez ainsi un graphique complet des dépendances de service, qui montre l'ensemble de l'écosystème de service et trace les requêtes avec précision. Cette capacité est cruciale pour identifier les problèmes, identifier les goulets d'étranglement et prendre en charge des fonctionnalités pilotées par l'IA telles que la détection des anomalies, l'analyse prédictive et la correction automatisée.
#### Agent AIOps
Pour augmenter les temps de résolution des incidents, nous avons développé un Agent Opérations IA (AIOps) qui détecte, trie et corrige automatiquement les incidents au nom d'opérateurs humains, avec une intervention dans une minorité de cas seulement. L'agent AIOps est une boîte à outils multi-agent réactif évolutive conçue pour faciliter le développement de systèmes complexes basés sur l'agent réactif. Il est hautement modulaire et peut être amélioré avec divers outils pour étendre ses fonctionnalités. Il est conçu pour évoluer efficacement avec un nombre croissant d'agents. Les principales fonctionnalités comprennent une architecture réactive, qui permet aux agents de réagir dynamiquement aux changements dans leur environnement, l'amélioration des outils, qui facilite l'intégration d'outils pour étendre les capacités des agents, et un module de planification enfichable, qui permet de personnaliser les stratégies de planification des agents en branchant différents modules de planification.
La détection proactive rapide est réalisée pour 91 % (au moment de la rédaction de ce rapport) de nos incidents produits CRM principaux avec des modèles d'apprentissage machine avancés de notre bibliothèque Merlion, une bibliothèque de source ouverte accessible au public développée par notre équipe de recherche en IA. Merlion est un ensemble de modèles d'apprentissage machine tels que les forêts d'isolement, les statistiques, les forêts aléatoires et les réseaux de neurones à mémoire à long court terme (LSTM) qui traitent en temps quasi réel les nombreuses données télémétriques générées par nos systèmes.
79 % des incidents (au moment de la rédaction du présent rapport) sont automatiquement résolus par les actions de l'agent. Notre agent AIOps peut traiter et trier des vecteurs de données tels que les journaux, le profilage, les diagnostics, les séries temporelles et les artefacts spécifiques au service afin de recommander des mesures correctives. Le contrôleur et planificateur AIOps Agent choisit un agent doté de compétences spécifiques pour exécuter des actions en production.
Pour les incidents restants qui nécessitent une intervention humaine, l'agent AIOps trie efficacement les problèmes non résolus dans les équipes de service appropriées. Pour ce faire, il comprend intelligemment la nature et le contexte de chaque incident en utilisant le modèle interne affiné XGenOps, qui est entraîné sur des jeux de données opérationnels tels que les enregistrements de problèmes, les incidents, les JFR et les journaux, en s'assurant qu'il est dirigé vers l'équipe qui possède l'expertise requise. Cela permet d'économiser plus de 2800 heures de temps d'ingénierie par semaine, ce qui réduit la nécessité pour les ingénieurs de trier les problèmes non résolus.
#### Déploiement continu
Pour gérer les risques de panne liés à près de 250 000 changements de production effectués chaque semaine, des systèmes de déploiement entièrement automatisés sont utilisés pour appliquer des pratiques de changement sûres, éliminant ainsi les erreurs humaines. Les systèmes standard n'étaient pas assez évolutifs ou personnalisables, ce qui a incité à développer des solutions plus adaptées.
Le système de déploiement continu personnalisé garantit la sécurité à travers plusieurs couches, en suivant les stratégies de déploiement bleu/vert standard de l'industrie :
- Preuve de test obligatoire pour chaque modification.
- Test canari initial des modifications.
- Déploiement échelonné avec un rayon d'explosion contrôlé.
- Trempage et contrôles d'intégrité entre les étapes de déploiement.
- Atténuer les conflits avec les moratoires et les incidents existants.
De plus, les systèmes d'intégration continue ont été optimisés pour exécuter des millions de tests sélectionnés par l'IA, ce qui permet des versions rapides tout en minimisant les risques de régression.
## 5\. Infrastructure de métadonnées
Le principe architectural de base de Salesforce Platform est sa conception pilotée par les métadonnées. Les ingénieurs Salesforce créent des services multilocataires et des magasins de données. Chaque application de la plate-forme est essentiellement une collection de métadonnées qui adapte l'utilisation de ces services multilocataires par des clients individuels. C'est pourquoi une phrase marketing courante pour Salesforce Platform est que « tout est accédé avec des métadonnées ».
La plate-forme met l'accent sur des métadonnées structurées et fortement typées. Ces métadonnées servent de couche d'abstraction entre l'expérience client et l'infrastructure et les implémentations Salesforce sous-jacentes. Cette approche améliore la convivialité et la qualité des applications. Par exemple, au lieu d'utiliser des définitions et des requêtes de schéma SQL, les clients interagissent avec des métadonnées structurées telles que des entités, des champs et des enregistrements via des API Salesforce Object (sObject). Cette conception permet à la plate-forme d'intégrer de nouvelles technologies de stockage de données ou de modifier des technologies existantes sans réécriture d'application, ce qui favorise les meilleures pratiques de développement continu.
L'architecture Salesforce Platform inclut une approche « d'extension en couches » qui prend en charge quatre personnes clés dans l'élaboration et l'extension d'applications :
- **Salesforce Engineering :** Les équipes développent des applications natives telles que Sales Cloud et Service Cloud, qui sont déployées dans tous les services et toutes les exécutions via un processus de publication étendu. Ces applications sont disponibles pour tous les locataires via des mécanismes de licence et de provisionnement.
- **Partenaires externes**: Les éditeurs de logiciels indépendants (ISV) et d'autres partenaires peuvent étendre les métadonnées créées par Salesforce pour élaborer des solutions à valeur ajoutée, par exemple des extensions de schéma dans des modèles de données Sales Cloud ou des règles de validation supplémentaires pour des enregistrements de requête Service Cloud. Ils peuvent empaqueter ces solutions pour les distribuer à plusieurs clients.
- **Administrateurs et développeurs informatiques spécifiques à l'organisation**: Ils peuvent personnaliser leurs applications au-delà de ce qu’offrent les éditeurs de logiciels, en adaptant des solutions pour répondre à des défis métiers uniques tels que des processus propriétaires ou spécifiques à une région.
- **Utilisateurs individuels**: Les utilisateurs peuvent personnaliser leur expérience d'application, par exemple changer l'ordre des colonnes dans une vue de liste ou définir un onglet par défaut.
Chaque personne peut itérer indépendamment sur la même application en s'assurant que les couches inférieures ne dépendent pas des changements de personne dans les couches supérieures, et en maintenant des contrats de gestion des versions et de rétrocompatibilité solides.
Une fonctionnalité qui met en évidence le concept d'« extension en couches » est l'ordre d'exécution d'enregistrement d'enregistrement, qui garantit que la logique métier des quatre couches est appliquée dans une séquence prévisible. Cela permet à une logique métier plus spécifique et de niveau supérieur déterminée par l'administrateur de l'organisation ou le développeur informatique de remplacer de façon appropriée une logique de niveau inférieur lors de l'enregistrement qui peut être fournie par Salesforce ou un partenaire externe.
De plus, les infrastructures de métadonnées de la plate-forme utilisent un environnement d'exécution « Core » et un Mappeur relationnel d'objet (ORM) propriétaire avec multilocation intégré, connecté à une base de données relationnelle. Cette exécution Core active l'état de mémoire partagée, les validations d'intégrité référentielle et les validations transactionnelles, ce qui donne la priorité à la stabilité de l'application et augmente la fiabilité des déploiements d'application. L'architecture évolue constamment pour prendre en charge l'échelle croissante de complexité des applications. Par exemple, en octobre 2025, il y avait plus de 85 000 entités définies par Salesforce et plus de 300 millions d'entités personnalisées définies par nos clients.
Historiquement, l'exécution Core hébergeait la majorité des fonctionnalités de la plate-forme et de l'application. L'architecture actuelle de Salesforce Platform inclut désormais des centaines de services indépendants pilotés par les métadonnées. L'exécution Core reste le système d'enregistrement unique pour les métadonnées d'application, exploitant les avantages uniques d'une architecture monolithique pour la gestion des métadonnées. Les métadonnées pertinentes sont synchronisées avec des caches locaux dans des services indépendants, qui alimentent la gamme diversifiée de services évolutifs pour les exécutions d'application.
## 6\. Données
Les données sont un actif essentiel pour les organisations, et Hyperforce fournit une base fiable pour leur stockage chez Salesforce. Le principal défi consiste à stocker les données de manière à optimiser leur utilité pour les applications. Salesforce Platform a transformé la couche de données en tenant compte de diverses exigences de stockage et d'accès. Il permet d'équilibrer efficacement les coûts, les vitesses de lecture/écriture, la capacité de stockage et les types de données pour répondre à divers besoins.
À mesure que l’IA et les analytiques façonnent de plus en plus les applications d’entreprise, les données sont devenues un élément central. Son importance réside dans sa capacité à permettre à l’IA et aux analytiques d’apprendre, d’analyser, de prendre des décisions et d’automatiser les processus.
Les données proviennent des bases de données System of Record (SOR), qui répondent aux exigences opérationnelles des entreprises. Il passe ensuite à travers diverses transformations vers des plates-formes Big Data, essentielles pour piloter l’IA et les applications pilotées par l’analyse.
Une gestion efficace des données, des informations transactionnelles aux connaissances analytiques, est essentielle pour extraire de la valeur et prendre en charge des applications sophistiquées. Salesforce Database (SalesforceDB) se distingue en tant que base de données transactionnelle de premier plan pour la gestion des données SOR, tandis que Data 360 sert de plate-forme Big Data robuste qui améliore les capacités IA et analytiques.
### 6.1 Base de données transactionnelle
Les données et métadonnées transactionnelles sont essentielles à Salesforce Platform. SalesforceDB est une base de données relationnelle moderne, native du cloud, conçue spécialement pour les charges de travail multilocataires de Salesforce, similaire aux autres bases de données cloud des principaux fournisseurs, mais avec des fonctionnalités personnalisées pour l'architecture de Salesforce. Il étend PostgreSQL, sépare le calcul et le stockage, et exploite Kubernetes et le stockage cloud, améliorant les opérations avec des fonctionnalités spécifiques au locataire telles que le cryptage et les sandbox.
SalesforceDB gère toutes les données CRM transactionnelles, plus de 1 100 milliards de transactions par mois, ainsi que les métadonnées de Data 360 et des services associés. Ses objectifs principaux sont d'assurer Trust par la durabilité, la disponibilité, les performances, et la sécurité; l'échelle pour les grands clients; et faciliter des opérations cloud simplifiées et fiables. Il atteint ces objectifs avec une conception qui sépare les couches de calcul et de stockage, un système de stockage distribué immuable et l'accès aux données de l'arborescence de fusion structurée en journaux. Cela permet des fonctionnalités avancées telles que le cryptage des données par locataire dans le stockage, et des sandbox et des migrations efficaces.
#### Présentation architecturale
L'architecture de service SalesforceDB s'exécute dans trois zones de disponibilité, avec le calcul et le stockage répliqués dans ces zones pour garantir la disponibilité du système même si un nœud ou une zone entière est perdu. Tous les services sont exécutés dans Kubernetes pour activer la reprise après échec automatisée et les déploiements de service.
Pour offrir des niveaux élevés de durabilité et de disponibilité, le système d'enregistrement ultime pour SalesforceDB est le stockage cloud tel que S3 d'AWS. Les opérations telles que l'archivage et la réplication inter-régions sont gérées à ce niveau de stockage cloud. Les objets de stockage sont immuables, ce qui améliore la distribution et la réplication des données pour une haute disponibilité.
En raison de la latence élevée dans le stockage cloud, SalesforceDB utilise des caches de stockage pour accéder aux données. Ces caches sont des systèmes de stockage distribués qui gèrent des copies temporaires d'objets de stockage dans un cluster de nœuds, assurant la réplication et la durabilité nécessaires à la base de données. Des caches séparés sont utilisés pour le stockage du journal des transactions et le stockage des fichiers de données.
Le niveau de calcul SQL comprend un cluster de base de données principal et deux clusters de secours dans trois zones de disponibilité différentes. Le cluster principal gère toutes les modifications de la base de données, alors que les clusters de secours gèrent uniquement les opérations de requête.
#### Stockage et accès LSM
SalesforceDB utilise une structure de données arborescence de fusion structurée en logarithmes (LSM), dans laquelle les modifications sont initialement enregistrées dans un journal des transactions et accumulées en mémoire. Les modifications validées sont ensuite écrites collectivement dans des fichiers de données organisés par clé, qui sont périodiquement fusionnés et compactés pour optimiser l'efficacité du stockage.
Cette structure élimine efficacement les problèmes de mise à jour simultanée courants dans les bases de données qui mettent directement à jour le stockage. En utilisant l'approche LSM, SalesforceDB prend en charge des fonctionnalités critiques telles que le stockage immuable, ce qui en fait une solution robuste pour gérer les charges de travail Salesforce.
#### Stockage immuable
Les données stockées sont immuables. Une fois les fichiers de données écrits et visibles, ils ne changent pas. Les journaux des transactions sont disponibles uniquement en ajout, ce qui simplifie les modèles d'accès aux données et augmente la fiabilité. Cette structure prend en charge les lectures non coordonnées, simplifie les sauvegardes, augmente l'évolutivité et facilite la virtualisation du stockage, ce qui la rend adaptée aux environnements Cloud.
#### Disponibilité et durabilité
Les transactions dans SalesforceDB sont engagées dans plusieurs zones de disponibilité, ce qui garantit l'absence de perte de données, même si un nœud ou une zone échoue. En cas d'échec, les transactions en vol sont abandonnées et les transactions engagées sont récupérées avec succès. Comme les échecs ne perdent pas les données validées, le basculement vers de nouveaux nœuds est automatisé.
Le logiciel de gestion de cluster gère automatiquement les basculements en surveillant les quorums et en gérant les transferts de propriété. Ce processus n'est pas seulement utilisé en cas d'urgence, mais aussi régulièrement pendant les correctifs réguliers, ce qui augmente la fiabilité du système grâce à une utilisation constante. Généralement, les utilisateurs ne remarquent pas les redémarrages courts de la base de données, ce qui garantit une expérience utilisateur transparente.
Salesforce effectue trois mises à jour majeures de schéma par an, avec des mises à jour hebdomadaires de schéma plus petites. SalesforceDB fournit des opérations de schéma sans temps d'arrêt qui permettent d'effectuer ces mises à jour sans impact client.
#### Système d'enregistrement
Notre base de données transactionnelle sert de référentiel principal pour les données clients, qui sont mises en cache dans plusieurs zones de disponibilité et stockées dans le cloud. Chaque bloc de données est sécurisé avec une somme de contrôle immuable, vérifiée à la fois par la couche de stockage et le moteur de base de données. La base de données effectue le suivi des lignages pour détecter tout changement en désordre ou toute version manquante, et effectue des contrôles de cohérence permanents entre les index et les tableaux de base.
Pour la protection contre les rançongiciels, les bases de données sont archivées dans un stockage séparé sous un autre compte, y compris les sauvegardes complètes et incrémentielles du journal des transactions. Ces sauvegardes sont régulièrement validées par un processus de test de restauration. De plus, l'infrastructure cloud est préconfigurée, mais pas activée, prête à gérer les requêtes de restauration de données si nécessaire.
#### Échelle
Chaque organisation Salesforce est hébergée dans une cellule Hyperforce, qui inclut le service SalesforceDB. Cette configuration permet une mise à l'échelle globale rapide grâce à la création de nouvelles cellules via l'architecture Hyperforce, et le trafic peut être aisément déplacé entre les cellules pour gérer la charge. Cependant, à mesure que la charge de travail des clients et les demandes métiers augmentent, la capacité d'une instance de base de données unique peut être insuffisante.
Pour y remédier, SalesforceDB utilise une architecture d'échelle horizontale pour ses niveaux de stockage et de calcul. Le stockage dans le cloud est pratiquement illimité et les couches de cache sont automatiquement adaptées à la demande. De plus, le niveau de calcul peut s'étendre en ajoutant d'autres nœuds de calcul de base de données, qui lisent efficacement depuis un stockage immuable partagé sans coordination. Cette approche permet à SalesforceDB d'atteindre une évolutivité égale ou supérieure à celle des principales architectures de base de données de clusters commerciaux, sans nécessiter de mise en réseau ni de matériel particulier.
#### Location multiple
Salesforce est une application multilocataire dans laquelle une base de données unique héberge plusieurs locataires. Chaque enregistrement de tableau inclut un ID de locataire pour différencier sa propriété, et l'isolement du locataire est maintenu par des prédicats de requête automatiques ajoutés par la couche d'application de Salesforce.
SalesforceDB est adapté à ce modèle, prenant en charge les processus DDL, de métadonnées et d'exécution spécifiques au locataire, ce qui augmente la fiabilité, les performances et la sécurité. Il combine la faible surcharge d'un modèle locataire par ligne à l'efficacité d'un schéma locataire par base de données.
Dans SalesforceDB, les ID de locataire font partie de la clé primaire dans les tableaux multilocataires, qui regroupent les données par locataire dans la structure de données LSM, ce qui améliore l'efficacité de l'accès. Cette configuration facilite non seulement l'accès efficace aux données et le cryptage par locataire, mais simplifie également la gestion des données locataires. Les locataires peuvent être aisément copiés ou déplacés avec un minimum d'ajustements de métadonnées grâce à la structure compacte des métadonnées.
### 6.2 Data 360 et Data Lake
Les capacités en IA, en analytique et en données sont essentielles dans les entreprises modernes. Les entreprises investissent déjà dans des plates-formes Big Data matures telles que Snowflake, Databricks, BigQuery et Redshift. Cependant, beaucoup
les clients ne tirent pas de valeur métier de leurs données en raison de silos de données, d'un manque de traitement IA, de données périmées ou de l'inaction dans un processus métier existant. La centralisation des données clients en une seule source de vérité, avec une vue unique de l'engagement des clients, est à la fois cruciale pour une entreprise et difficile en raison de la fragmentation des données et de la complexité de la gestion du système. Salesforce joue un rôle moteur en facilitant une vue globale d'un client en intégrant les données, l'IA et le CRM dans un cercle vertueux, piloté par l'IA générative et les connaissances de l'apprentissage machine, et piloté par les données.
SalesforceDB est optimisée pour les charges de travail transactionnelles hautement performantes sur les données structurées, alors que les charges de travail IA et analytiques nécessitent de traiter de grands volumes de données non structurées provenant de diverses sources et d'effectuer des requêtes complexes et des traitements par lot. Pour répondre à ces besoins, Salesforce a développé Data 360, une plate-forme conçue pour briser les silos de données, unifier, stocker et traiter les données de façon sécurisée et efficace, en prenant en charge les demandes en IA et en analytique, et en permettant des opérations d'entreprise en temps réel.
Data 360, construit sur Hyperforce, sert de plate-forme de base pour l'IA et Analytics, offrant:
- Infrastructure intégrée et plate-forme sans code pour consolider les silos de données via des connexions
- Ingestion de données en temps réel et en temps quasi réel
- Fédération zéro copie
- Nettoyage, préparation et mise en forme des données pour le traitement
- Service de requête unifié sur des données structurées et non structurées
- Développement de modèles analytiques et IA/ML pour la génération de connaissances
- Actions et activations déclenchées par des données
- Prise en charge de la génération augmentée de récupération d’IA générative (RAG)
- Gouvernance globale basée sur la politique
Data 360 Architecture prend en charge un certain nombre de composants et de capacités, qui sont décrits ci-dessous.
#### Connectivité, transformation et harmonisation
Data 360 prend en charge des pipelines d'ingestion efficaces à partir de diverses sources de données structurées et non structurées, pour le traitement des données par lot, en temps quasi réel et en temps réel. Le service d'ingestion de Data 360 fonctionne selon un modèle ELT (Extract-Load-Transform), conçu pour une faible latence et adapté à l'échelle B2C. L'ingestion en temps réel inclut des API et des flux interactifs, tandis que les sources en temps quasi réel couvrent l'utilisation détaillée des produits. Une fois ingérées, les données sont transformées en profondeur pour les préparer, les harmoniser (par exemple, unifier divers types de contact) et les modéliser pour des applications d'interrogation, d'analyse et d'IA efficaces. La plate-forme inclut également un large éventail de modèles de données harmonisés prêts à l'emploi.
Data 360 s'intègre de façon transparente à des applications Salesforce telles que Sales Cloud, Service Cloud, Marketing Cloud et Commerce Cloud. De plus, il offre des centaines de connecteurs pour des sources de données externes, ce qui garantit une intégration fluide des données.
#### Lakehouse pour les Big Data
Data 360 propose une architecture Lakehouse native basée sur Iceberg/Parquet, conçue pour gérer la gestion et le traitement des données à grande échelle pour des scénarios par lot, en continu et en temps réel. Cette architecture prend en charge les données structurées et non structurées, cruciales pour les applications IA et analytiques.
Dans les lacs de données basés sur le cloud tels que Azure, AWS ou GCP, l'unité de stockage de base est un fichier, généralement organisé en dossiers et en hiérarchies. Ce lac améliore cette structure en introduisant des abstractions structurelles et sémantiques de niveau supérieur pour faciliter des opérations telles que l'interrogation et le traitement IA/ML. L'abstraction principale est un tableau avec des métadonnées qui définit sa structure et sa sémantique, incorporant des éléments de projets open-source tels que Iceberg ou Delta Lake, avec des couches sémantiques supplémentaires ajoutées par Data 360.
Couches d'abstraction dans la maison du lac :
- **Parquet File Abstraction**: À la base, le stockage est composé de fichiers lac de données (par exemple S3 dans AWS ou Blob dans Azure) au format Parquet. Les données d'un tableau source sont stockées dans plusieurs partitions sous forme de fichiers Parquet, chaque tableau étant une collection de ces fichiers.
- **Abstraction de tableau iceberg**: Les tableaux sont organisés en dossiers, avec des partitions de données stockées sous forme de fichiers Parquet dans ces dossiers. Les modifications apportées à une partition entraînent de nouveaux fichiers Parquet sous forme de clichés instantanés. Iceberg gère un fichier de métadonnées pour chaque tableau, détaillant des schémas, des spécifications de partition et des clichés instantanés.
- **Salesforce Cloud Table Abstraction**: Basée sur Iceberg, cette couche ajoute des métadonnées sémantiques telles que les noms de colonne et les relations, ainsi que des configurations telles que la taille de fichier cible et la compression. Il extrait des tableaux sur diverses plates-formes telles que Snowflake et Databricks, protégeant les applications Data 360 des spécificités de la plate-forme de stockage sous-jacente.
- **Bibliothèque d'accès au lac**: Cette bibliothèque permet d'accéder au tableau Salesforce Cloud, en gérant les données et les métadonnées, et d'extraire les mécanismes de stockage sous-jacents pour les développeurs d'applications.
- **Big Data Service Abstraction**: Cela inclut des infrastructures de traitement telles que Trino et Hyper pour l'interrogation, et Spark pour le traitement sur n'importe quelle plate-forme de tableau cloud.
Data 360 Lakehouse prend en charge l'échelle B2C, l'ingestion en temps réel, le traitement, l'application et l'évolution du schéma, les clichés instantanés et utilise des formats de stockage ouverts.
#### Stockage en temps réel
Pour prendre en charge les analytiques en temps réel et les applications agentiques, Data 360 augmente le stockage de Big Data d'une Lakehouse avec un magasin à faible latence (LLS) supplémentaire. La couche de traitement en temps réel de Data 360 analyse les signaux en temps réel et les données d'engagement en mémoire. La capacité de stockage basée sur la mémoire étant limitée, toutes les données ne peuvent pas être traitées en même temps. Data 360 ajoute cette LLS pour supprimer ces limitations, ce qui permet un traitement en temps réel évolutif.
Le magasin de faible latence est une couche de stockage NVMe (SSD) à l'échelle du pétaoctet dans la cabane du lac. C’est un cache durable – la plupart des données finissent par arriver au lac pour une persistance à long terme. Les données en session de la couche en temps réel peuvent être vidées vers le magasin à faible latence pour un accès rapide ultérieur. Par exemple, dans une conversation d'agent, les messages récents peuvent être traités en mémoire ; les anciens messages peuvent être vidés dans le LLS. Si une conversation précédente est requise, elle est accessible en quelques millisecondes depuis le LLS. Le stockage basé sur NVMe permet de stocker de grandes quantités de données et d'y accéder à des latences en millisecondes. Les données peuvent arriver au lac pour la persistance à long terme.
De plus, les données de Lakehouse requises pour le traitement en temps réel ou pour augmenter les expériences en temps réel sont récupérées et conservées dans le LLS. Par exemple, le contexte du profil client est pré-récupéré ou apporté depuis Lakehouse et mis en cache dans le LLS. De plus, tous les objets Lakehouse et les autres objets requis pour le traitement en temps réel pendant le traitement en session peuvent également être mis en cache dans le LLS. Le LLS active une couche en temps réel dans une véritable hiérarchie de stockage avec des couches de mémoire, de SSD et de stockage Lakehouse, avec des données qui migrent de façon transparente entre chaque couche.
Data 360 offre également un support robuste pour la sécurité, notamment le Cryptage au niveau du locataire (TLE) avec des clés gérées par le client, ainsi que la confidentialité et la conformité grâce à ses technologies de gouvernance. Au cœur de cette stratégie se trouve la prise en charge du contrôle d'accès basé sur l'attribut (ABAC), qui évalue dynamiquement l'accès en fonction des attributs associés aux entités, aux opérations et aux facteurs environnementaux. Ce système prend en charge les contrôles d'accès discrétionnaires et obligatoires.
Complémentaire à ABAC, un système de classification des données détaillé classe les données par nature et objet, ce qui améliore la conformité, la gestion des risques et la réponse aux incidents. Ensemble, ABAC et ce système de classification offrent une gouvernance complète des données, garantissant une gestion sécurisée et efficace des données dans Data 360.
#### Métadonnées pilotées
Data 360 s'intègre profondément à Salesforce Platform pour les métadonnées, l'empaquetage, l'extensibilité, l'expérience utilisateur, et la distribution d'applications via AppExchange. Les clients peuvent définir et gérer les métadonnées de flux et de tableaux Lakehouse, de la même façon que les autres métadonnées Salesforce. Chaque objet de données (y compris les tableaux fédérés ou externes) est représenté en tant qu'objet Salesforce, et modélisé en tant qu'entités virtuelles soutenues par le stockage de données dans Data 360. Ils peuvent être utilisés par les développeurs pour élaborer des applications sur Salesforce Platform.
#### Fédération zéro copie et extensibilité
Data 360 offre une prise en charge étendue de la fédération zéro copie, qui permet aux utilisateurs d'intégrer des entrepôts de données externes tels que Snowflake et Redshift, des maisons de lac telles que Google BigQuery, Databricks et Azure Fabric, ainsi que des bases de données SQL et divers types de fichier, y compris Excel. Data 360 prend en charge la fédération basée sur les fichiers et les requêtes, avec une accélération des requêtes live et de l'accès, comme illustré sur la figure. Les étiquettes (1) et (2) illustrent la requête de Data 360 (y compris les requêtes pushdown live) et la fédération basée sur un fichier pour accéder aux données de lacs de données externes/entrepôts/sources de données. L'étiquette (3) souligne l'accélération de l'accès fédéré à partir de lacs de données externes/sources de données. Les étiquettes (4) et (5) illustrent le partage de données basées sur des requêtes et des fichiers depuis Data 360 avec des lacs de données/entrepôts externes. La capacité s'étend également aux sources de données non structurées telles que Slack et Google Drive, qui sont accessibles par les pipelines de traitement non structurés de Data 360. De plus, Data 360 facilite l'abstraction des objets Salesforce et l'accès aux données pour les données fédérées à partir de sources externes, ce qui permet d'accéder à ces données sur la plate-forme et les applications Salesforce.
#### Customer Data Platform (CDP)
Data 360 intègre un CDP qui offre des capacités avancées de résolution de l'identité, créant des identifiants et des profils d'individu unifiés avec des historiques d'engagement complets. Cette plate-forme est capable de gérer les infrastructures entreprise à entreprise (B2B) et entreprise à consommateur (B2C) en prenant en charge les graphiques d'identité qui utilisent des règles de correspondance exactes et partielles. Ces graphiques d'identité sont enrichis avec les données d'engagement de divers canaux, ce qui aide à élaborer des graphiques de profil détaillés avec des connaissances analytiques et des segments précieux.
De plus, le CDP permet une segmentation et une activation efficaces sur différentes plates-formes telles que Marketing Cloud, Facebook et Google de Salesforce. Il traite les profils clients par lot, en temps quasi réel et en temps réel, ce qui permet une prise de décision et une personnalisation immédiates. Cette fonctionnalité améliore les interactions dans les scénarios B2C et B2B, ce qui permet aux entreprises de répondre rapidement et avec précision aux besoins et aux comportements des clients.
#### Graphiques de données
Data 360 offre un graphique de données d'entreprise au format JSON, qui est un objet dénormalisé dérivé de divers tableaux Lakehouse et de leurs interrelations. Cela inclut un graphique de données « Profil » créé par CDP qui inclut l'historique d'achat et de navigation, l'historique des requêtes, l'utilisation des produits et d'autres connaissances calculées d'une personne, et qui est extensible par les clients et les partenaires. Ces Graphiques de données sont adaptés à des applications spécifiques et améliorent la précision des invites d'IA générative en fournissant un contexte client ou utilisateur pertinent.
De plus, il est prévu d'élargir ces Graphiques de données pour inclure des graphiques Knowledge qui capturent et modélisent Knowledge dérivé, par exemple des entités extraites et des relations à partir de données non structurées. La couche en temps réel de Data 360 utilise le graphique Profil pour la personnalisation et la segmentation en temps réel.
#### Couche en temps réel
La couche en temps réel de Data 360 est conçue pour traiter des événements tels que les flux de clics Web et mobiles, les visites, les données de panier d'achat et les paiements à des latences en millisecondes, ce qui améliore la personnalisation de l'expérience client. Il surveille en permanence l'engagement des clients et met à jour le profil client depuis CDP avec des données d'engagement en temps réel, des segments et des calculs pour une personnalisation immédiate.
Par exemple, lorsqu'un consommateur achète un article sur un site Web d'achat, la couche en temps réel détecte et ingère rapidement cet événement, identifie le consommateur et enrichit son profil avec des informations actualisées sur les dépenses à vie. Cela permet de personnaliser leur expérience sur le site en quelques secondes. De plus, cette couche inclut des capacités de déclenchement et de réponse en temps réel, qui permettent des actions immédiates basées sur les interactions des clients.
#### Personnalisation
La personnalisation consiste à savoir quelle personne cibler, quand et où fournir des contenus et des recommandations pertinents, quoi dire et à quelle fréquence. La capacité Plate-forme des services de personnalisation de Data 360 est l'orchestre qui permet de prendre des décisions pour optimiser la réalisation des objectifs à travers des expériences personnalisées. Cette plate-forme offre les capacités suivantes :
- Ensemble cohérent de modèles et de méthodes d'interprétation des données de profil, d'activité et d'actif dans Data 360.
- Expérimentation intégrée à la plate-forme (par exemple, prise de décision A/B/N ou multi-bras bandit).
- Intégration des objectifs lors de la conception via la configuration, le temps d'entraînement ML et l'exécution (inférence ML).
- Prise en charge de l'interaction à l'échelle B2C, en temps réel et par lot (utilisateurs anonymes, externe interactif/temps réel haut volume, lot interne haut volume).
- Analytics piloté par Data 360.
- Modèles d'intégration de modèles IA et de services d'autres parties (internes et externes).
- Implémentations OOTB de cas d'utilisation pilotés par l'IA à haute valeur ajoutée (recommandations et décisions avec divers algorithmes ML, y compris des bandits contextuels pour la sélection de promotions/contenus, des recommandations de produits et des décisions de tarification).
#### Actions de données
Data 360 est une plate-forme active qui prend en charge l'activation de pipelines en réponse à des événements de données. Par exemple, un événement important, par exemple une baisse du solde du compte d'un client, peut déclencher un flux Salesforce pour orchestrer une action correspondante. De la même façon, les mises à jour des métriques clés, telles que la durée de vie, peuvent être automatiquement propagées aux applications appropriées.
#### Tissu de calcul de données
Data 360 propose des clusters de calcul à l'échelle élastique qui gèrent efficacement les tâches de traitement. Il offre une gestion robuste pour les environnements de calcul multilocataires et dédiés. Il fournit en outre une prise en charge gérée pour Spark et SQL. Les fonctionnalités BYOC (Bring Your Own Compute/Code) prennent en charge plusieurs langages de programmation, notamment Java, Python et Spark, ce qui permet l'intégration de transformations, de modèles (y compris des LLM) et de fonctions personnalisés, ce qui améliore l'extensibilité.
Data 360 Compute Fabric fournit une couche unifiée appelée Data Processing Controller (DPC) pour gérer et exécuter toutes les charges de travail Big Data. DPC est un service complet d'orchestration du traitement des données à charges de travail multiples qui fournit des capacités de travail en tant que service (JaaS) dans divers environnements de calcul cloud. Il élimine la complexité de l'infrastructure et unifie l'exécution des tâches pour des infrastructures telles que Spark (EMR sur EC2 et EMR sur EKS) et les charges de travail Kubernetes Resource Controller (KRC). En servant de passerelle de plan de contrôle centralisée, DPC orchestre, planifie et surveille les tâches à travers plusieurs plans de données, garantissant fiabilité, évolutivité, rentabilité et expérience cohérente pour les développeurs.
#### Requêtes unifiées
Le service de requête de Data 360 fournit des capacités de requête avancées, avec une prise en charge SQL étendue pour les données structurées et non structurées via Trino et Hyper. Il améliore les fonctionnalités avec l'extensibilité des opérateurs via des fonctions de tableau, ce qui permet diverses opérations de recherche à travers le texte, l'image, l'espace et d'autres types de données non structurés. Ces capacités sont intégrées de façon transparente à des opérations relationnelles, telles que la sélection d'enregistrements clients. Cette approche unifiée permet de générer des résultats ciblés et personnalisés, ce qui facilite des réponses LLM plus précises en utilisant RAG.
#### Traitement des données non structuré
Data 360 prend en charge le stockage et la gestion des données structurées (tableaux), semi-structurées (JSON) et non structurées de façon transparente à travers les mécanismes d'ingestion, de traitement, d'indexation et de requête des données. Data 360 prend en charge divers types de données non structurés au-delà du texte, notamment le son, la vidéo et les images, ce qui élargit la portée du traitement et de l'analyse des données. La figure ci-dessous illustre les deux côtés de l'ancrage (ingestion et récupération).
Data 360 gère les données non structurées en les stockant dans des colonnes sous forme de texte ou dans des fichiers pour des jeux de données plus volumineux. Il prend en charge la fédération de données pour les contenus non structurés, ce qui permet d'intégrer et de gérer les données de plusieurs sources.
Le pipeline d'indexation de données non structuré de Data 360 est conçu comme une architecture modulaire et extensible comprenant cinq étapes principales : Analyse, Prétraitement, Découpage, Post-traitement et Incorporation. Ces étapes sont ensuite suivies d'une indexation par mot-clé et vecteur. Des exemples de pré-traitement comprennent des opérations telles que l'élimination du bruit, la normalisation du langage et la compréhension de l'image (reconnaissance optique des caractères), tandis que les étapes de post-traitement peuvent inclure l'enrichissement des métadonnées, le regroupement sémantique ou des techniques avancées telles que la segmentation.
Data 360 fournit plusieurs modèles prêts à l'emploi et enfichables pour la segmentation et la génération d'encastrement. Les pipelines de données dans Data 360 prennent entièrement en charge les extensions de code, ce qui permet aux clients et aux équipes internes de brancher une logique personnalisée à n'importe quelle étape. Ces étapes prennent également en charge le traitement basé sur le LLM, qui permet aux clients de définir leurs propres invites si nécessaire.
Pour l'indexation, Data 360 prend en charge l'indexation par mot-clé en utilisant des services de recherche, et l'indexation vectorielle en utilisant Milvus, un index vectoriel natif de source ouverte. Pour configurer le RAG avec un traitement non structuré, Data 360 exploite l'indexation du contexte afin de permettre une itération rapide et une validation rapide en utilisant des exemples de requêtes de test, avec des contenus spécifiques à la personne configurés pour s'adapter à la personne ou à l'utilisateur consommateur.
La capacité IA Document de Data 360 prend en charge la lecture et l'importation de données non structurées ou semi-structurées à partir de documents tels que des factures, des CV, des rapports de laboratoire et des bons de commande. Cette fonctionnalité prend en charge le traitement interactif ad hoc, ainsi que le traitement par lot en masse. Cette capacité clé permet l'automatisation des processus métiers pour nos clients.
#### Couche sémantique
Data 360 inclut une couche sémantique headless avec des API conçues pour améliorer la sémantique métier et les analytiques pilotées par l'IA/ML, similaire à Tableau Next. Cette couche inclut un service de modélisation des données sémantiques qui enrichit les modèles analytiques traditionnels avec la taxonomie métier, notamment les mesures et les métriques.
Son service de requête sémantique utilise un langage déclaratif pour interagir avec ces modèles, traduisant les requêtes en SQL pour accéder aux données de sources de données natives et fédérées dans Data 360.
Cette intégration facilite les explorations analytiques, les rapports et les tableaux de bord évolutifs et interactifs, compatibles avec des outils de visualisation tiers.
#### Gouvernance des données
Data 360 fonctionne comme une plate-forme de gouvernance centralisée, garantissant que toutes les données, depuis l'ingestion brute jusqu'aux connaissances activées, sont gérées avec intégrité et contrôle. Data 360 a adopté le Contrôle d'accès basé sur l'attribut comme modèle d'autorisation principal. ABAC permet de prendre des décisions d'accès basées sur des attributs de l'utilisateur (service, rôle, emplacement), des données (informations personnelles, confidentialité, espace de données) et de l'environnement (par exemple, heure du jour), plutôt que des rôles prédéfinis. Cela permet des stratégies d'accès très précises et contextuelles qui s'adaptent à mesure que les données et les attributs utilisateur changent. L'utilisation du langage de stratégie CEDAR est au cœur de l'implémentation ABAC de Data 360. Ce langage de stratégie formel, ouvert et spécialement conçu fournit une méthode précise et vérifiable de définition de règles d'autorisation complexes, garantissant que les politiques sont sans ambiguïté et peuvent être évaluées de façon cohérente à l'échelle.
Le cycle de vie de la gouvernance comprend des capacités clés concernant l'information sur les politiques, l'application et les points de décision :
- **Marquage et classification (point d'information sur la politique) :** Les données sont identifiées et enrichies avec des attributs critiques. Data 360 fournit des mécanismes automatisés de balisage et de classification, qui tirent parti de la découverte, des grands modèles de langage et de l'apprentissage machine pour identifier des catégories de données confidentielles (par exemple, des informations d'identification personnelle telles que l'adresse e-mail, le téléphone, le nom) dans des données structurées et non structurées.
- **Service d'autorisation (point d'application de la politique) :** Ce service intercepte toutes les requêtes d'accès aux données de diverses couches de consommation (requêtes hybrides structurées/non structurées, RAG retrievers & prompts, et enrichissement CRM) et consulte le Point de décision de la politique pour déterminer si l'accès est autorisé.
- **Moteur d'évaluation des politiques (point de décision de la politique) :** Ce moteur prend le contexte de la demande d'accès du point d'application de la politique, avec les définitions de la politique (dans CEDAR) et les attributs du point d'information de la politique, pour prendre une décision d'accès qui fait autorité.
L'infrastructure ABAC avec des politiques CEDAR offre contrôle et flexibilité, garantissant que les données des clients sont non seulement actionnables, mais également sécurisées, conformes et fiables dans l'ensemble de l'entreprise.
### 6.3 Mise en cache des données
Les caches sont essentiels pour accéder rapidement aux données fréquemment utilisées. Salesforce utilise de nombreuses mémoires cache sur Salesforce Platform, notamment dans les serveurs d'application de base, SalesforceDB et Edge. Salesforce Platform et les applications ont besoin d'une solution de mise en cache évolutive, sensible aux locataires, avec une faible latence et un débit élevé. Cette solution doit permettre aux ingénieurs Salesforce de contrôler les éléments mis en cache et la durée de mise en cache, en s'assurant que leurs données ne sont pas expulsées par le bruit système ou les données d'autres clients. Vegacache, un service de mise en cache géré par Salesforce basé sur Redis, est adapté à un environnement cloud polyglotte, multilocataire et public. Il est largement utilisé par les services Salesforce et accessible aux développeurs de plate-forme via des API de langage de programmation Apex. Fonctionnant à grande échelle dans Hyperforce, à l'heure où nous écrivons ces lignes, Vegacache gère quotidiennement plus de 2000 milliards de requêtes avec des temps de réponse inférieurs à la milliseconde.
Les instances Vegacache, exécutées dans des conteneurs Kubernetes accédés via Service Mesh, sont déployées à travers plusieurs zones de disponibilité afin d'équilibrer la disponibilité des données et la latence. Il s'adapte automatiquement en fonction de la charge système, ce qui garantit la disponibilité des données et la préservation de l'ordre des créneaux horaires. Vegacache fournit une taille de cache garantie par client et offre une protection contre les voisins bruyants, avec une résilience contre les défaillances d'infrastructure grâce au stockage de données répliqué.
Pour les développeurs de Salesforce Platform, Vegacache permet aux développeurs de mettre en cache les objets Apex et les résultats des requêtes de base de données SOQL, réduisant ainsi l'utilisation du processeur et la latence en éliminant les récupérations de données inutiles depuis SalesforceDB. Il prend en charge les opérations Put(), Get() et Delete(), ce qui facilite l'accès aux objets fréquemment utilisés.
### 6.4 Traitement des données asynchrone
Salesforce prend en charge nativement des processus et des architectures de données asynchrones pour plus de flexibilité, de résilience et d'évolutivité dans les workflows.
Les ingénieurs Salesforce ont d'abord exploité les files d'attente de messages pour découpler les processus de données volumineux et en masse, et coordonner les processus entre des systèmes indépendants. Ces files d'attente de messages ont été extraites du développeur externe via des fonctionnalités de la plate-forme, telles que des requêtes d'API de transfert en masse ou Apex asynchrone. Salesforce Platform a ensuite introduit des flux d'événements organisés par journal, élaborés sur une infrastructure de messagerie robuste composée de clusters Apache Kafka gérés en interne. Cela a permis une architecture basée sur l'événement avec un modèle d'interaction publier/s'abonner, et a été produit pour les développeurs externes sous le nom d'événements de plate-forme.
Les files d'attente de messages et les flux d'événements continuent d'être des technologies hautement exploitées d'applications et de solutions élaborées sur la plate-forme, d'autant plus qu'elles exploitent davantage de fonctionnalités, de clouds et de systèmes externes hébergés sur des exécutions indépendantes. La communication via des schémas d'événements versionnés active des cycles de vie de développement logiciel indépendants pour les différentes exécutions. Le découplage des systèmes via des événements permet également de gérer les pics de charge et l'élasticité/l'échelle des exécutions individuelles afin d'augmenter la résilience globale et la disponibilité d'une application.
### 6.5 Recherche d'entreprise
Les fonctionnalités de recherche de Salesforce, essentielles pour des applications allant de la recherche globale à l’IA générative, sont confrontées à des défis uniques qui façonnent notre approche architecturale :
- **Échelle**: Prenant en charge des centaines de milliers de clients et des millions de locataires, notre solution de recherche native dans le cloud est conçue pour une grande échelle tout en restant économique.
- **Diversité des clients**: La clientèle diversifiée de Salesforce dans divers secteurs d'activité a des exigences de recherche uniques et complexes en raison de la personnalisation étendue de la plate-forme, impliquant de nombreux types d'objet et champs.
- **Opérabilité**: La solution de recherche doit être résiliente et hautement disponible, prendre en charge la résidence des données, les opérations de cycle de vie des locataires telles que les migrations régionales et la sandbox, et maintenir une faible latence d'indexation avec équité entre les locataires.
- **Pertinence à l'échelle**: Il est essentiel d'accroître la pertinence des résultats de recherche pour répondre aux diverses requêtes des utilisateurs, d'autant plus que nous adaptons les algorithmes de pertinence à divers locataires, types de données et scénarios de recherche.
- **IA et capacités sémantiques**: La recherche prend en charge l'apprentissage machine et l'IA générative, en particulier pour la génération augmentée par récupération (RAG) et la recherche agentique.
- **Intégration transparente**: Pour garantir une expérience utilisateur cohérente, la technologie de recherche de Salesforce s'intègre profondément à la plate-forme Salesforce élargie, y compris aux modèles de métadonnées et aux services d'IA/données.
La solution cloud native de Salesforce, SeaS (Search as a Service), repose sur Solr, un moteur de recherche distribué open-source. Salesforce a considérablement étendu et optimisé Solr pour répondre à nos défis uniques et l'a profondément intégré aux applications et à la plate-forme Salesforce, en incorporant des technologies sémantiques pour améliorer les applications IA et la pertinence de la recherche.
SeaS utilise une architecture de séparation calcul/stockage, qui permet une distribution évolutive des index entre les nœuds et un rééquilibrage des charges et de la disponibilité entre les zones en cas de défaillance. Il offre la segmentation et le redimensionnement automatiques des segments, des mises à niveau sans temps d'arrêt, et des optimisations telles que le chargement et l'archivage paresseux de répliques pour répondre aux index rarement utilisés.
L'architecture inclut également une implémentation d'index de bas niveau optimisée pour un grand nombre de champs, la saisie automatique, la correction orthographique et le cryptage par clé. Gérant environ 6000 nœuds Solr à l'échelle mondiale, l'infrastructure de recherche Hyperforce utilise plusieurs clusters indépendants (cellules Hyperforce) dans chaque région pour équilibrer le coût et le contrôle, plaçant automatiquement les index clients en fonction de la charge, du domaine et du type.
Le pipeline de pertinence de la recherche de Salesforce utilise des techniques d'apprentissage du classement, s'adaptant aux divers besoins de nos clients et des fonctionnalités de support telles que le classement des résultats. Il inclut également des prédictions d'entité à partir des requêtes des utilisateurs et des interactions passées. Les modèles de pertinence sont continuellement affinés en apprenant à partir des interactions des utilisateurs et évalués par des tests A/B, ce qui améliore la précision des résultats de recherche. Ce processus prend également en charge les modèles de bootstrapping pour les applications IA via le transfert Knowledge.
La pile incorpore un moteur de recherche vectoriel pour les applications de recherche sémantique et d'IA, intégré à Data 360 pour les capacités d'IA générative. Cela inclut un pipeline complet pour la transformation des données, la prise en charge de la recherche hybride, un catalogue de classements configurables, tels que Deep Fusion Ranker et Autodrop pour filtrer les résultats de recherche peu pertinents.
Comme l’IA générative déplace le principal consommateur de services de recherche des utilisateurs humains vers l’utilisation de LLM, la pile de recherche Salesforce s’adapte pour rechercher et renvoyer des résultats optimisés pour cette consommation par programmation, en traitant des requêtes plus longues et plus complexes et en renvoyant des résultats plus explicites tels que des segments. Cela prend en charge les nouvelles capacités de la Recherche Agentique, où les agents Agentforce exploitent la recherche avec une boucle de raisonnement pour accomplir des tâches complexes.
Les fonctionnalités de recherche de Salesforce couvrent divers contextes, notamment la recherche globale, les références, Recherche de réponses, la recherche dans la communauté, les listes associées, la configuration, les applications mobiles et d'IA générative. Cette fonctionnalité étendue est obtenue en intégrant étroitement la pile Rechercher au système de métadonnées et à l'écosystème de l'interface utilisateur de Salesforce, ce qui permet une prise en charge transparente des objets standard et personnalisés.
De plus, l'intégration à Data 360 améliore les capacités de recherche dans les objets de données grâce à des configurations sans code et permet de composer des fonctions de recherche dans des pipelines de données, par exemple inclure des instructions de recherche dans des requêtes SQL. La pile Rechercher exploite l'écosystème de connecteurs enrichis Data 360, tel que le connecteur Google Drive sensible aux autorisations, pour fournir des capacités de recherche d'entreprise complètes. L'intégration s'étend à la plate-forme IA, ce qui permet d'utiliser des requêtes de recherche en tant que récupérateurs dans le Générateur de répliques pour l'ancrage et dans la Recherche agentique.
## 7\. IA et Agentforce
L’IA a redessiné le paysage technologique, et Salesforce Platform, avec sa couche de données intégrée et riche, positionne Salesforce pour offrir des expériences d’IA impactantes aux clients. Salesforce a commencé sa transformation en IA il y a près de dix ans et est à la pointe du domaine depuis 2013, en se concentrant sur la recherche, l'éthique et le développement de produits afin de permettre aux entreprises de résoudre des problèmes complexes et de stimuler la croissance.
Tirant parti de la valeur fondamentale de l'Innovation, Salesforce a introduit l'IA prédictive Einstein, permettant aux entreprises d'analyser les données, d'automatiser les processus, de comprendre les clients et d'optimiser les opérations avec une suite complète d'outils pilotés par l'IA tels que le Générateur de prédiction Einstein et les robots IA. Avec l'essor de l'IA générative, Salesforce a lancé Agentforce, une plate-forme qui fusionne les modèles prédictifs et génératifs pour offrir des capacités d'IA avancées tout en donnant la priorité à la confidentialité des données.
Avec le tout dernier lancement d'Agentforce 3.0, élaboré sur Python avec une infrastructure pilotée par les événements, Salesforce introduit une flexibilité accrue grâce à des fonctionnalités telles que l'historique des conversations intégré, le traçage des sessions de bout en bout, la prise en charge vocale et la fonctionnalité de moteur de raisonnement personnalisé (Bring Your Own Planner), permettant des systèmes multi-agents plus évolutifs, personnalisables et intelligents.
### 7.1 Principes fondamentaux de l’IA
Agentforce suit les principes fondamentaux suivants :
- **Sécurité des données et éthique**: Donne la priorité à la protection des données, à la conformité et aux principes éthiques de l’IA.
- **Transparence et explicabilité**: Offre une compréhension et une validation claires des sorties générées par l’IA.
- **Flexibilité et personnalisation**: Adapte les applications IA à des besoins et des secteurs d'activité spécifiques.
- **Intégration transparente**: Intègre à Salesforce CRM et à d'autres systèmes.
- **Évolutivité**: Gère les déploiements à grande échelle et offre des expériences IA en temps réel.
- **Expériences intelligentes et cohérentes**: Fournit des expériences personnalisées, augmentées et automatisées à travers des données connectées et une compréhension contextuelle.
- **Observabilité complète :** Fournit une visibilité et une surveillance approfondies sur les interactions des agents IA afin de permettre une optimisation proactive et une mise au point des agents en utilisant Agentforce Interaction Explorer.
### Présentation de l'architecture 7.2
La pile IA se compose de plusieurs composants clés :
- **Plate-forme IA**: Cette couche de plate-forme est responsable de la gestion, de la formation et de l'ajustement des modèles d'IA utilisés dans les applications prédictives et génératives. Il offre des services prêts à l'emploi (OOTB), des services Trust et des modèles de base pour l'entraînement, le test et l'exécution d'inférence sur des modèles. De plus, il prend en charge l'intégration de vos propres modèles prédictifs et génératifs, ce qui vous permet d'intégrer des modèles personnalisés à la plate-forme.
- **Services de base IA**: Cela inclut les services Passerelle IA, Infrastructure de commentaires, RAG, Orchestration agentique, Évaluation et raisonnement des agents, qui facilitent l'intégration d'applications métiers à la pile IA.
- **Expériences utilisateur et agent pilotées par l’IA**: Salesforce fournit des applications spécialisées pilotées par l'IA via ses services cloud. Les clients peuvent également créer des expériences personnalisées en exploitant n'importe quel composant de la plate-forme, par exemple Flux, Apex, ou même Composants Web Lightning (LWC) pour créer des expériences pilotées par l'IA intégrées de façon transparente à leurs workflows et processus métiers.
- **Agentforce Studio**: Ce composant contient des outils tels que Générateur d'agents, Générateur de répliques, Centre de test et Générateur de modèle, conçus pour créer des expériences d'IA générative et prédictive. Il offre une prise en charge de bout en bout pour le développement/la formation, le test et l'ajustement de modèles IA. Next Gen Authoring améliore ces capacités, conçues pour simplifier et accélérer la création d’agents IA avec l’amélioration de l’expérience utilisateur et la compatibilité avec SFDX.
### 7.3 Composants de base
#### Couche de Trust Agentforce
L'Agentforce Trust Layer est disponible dans certains cas d'utilisation pour aider à protéger les données des clients dans les applications d'IA générative en offrant des fonctionnalités robustes:
- **Confidentialité des données**: De solides contrôles de masquage et de confidentialité protègent l'accès aux informations confidentielles par des modèles d'IA externes.
- **Sécurité**: Garantit un environnement de traitement des données sécurisé et empêche tout accès non autorisé.
- **Trust**: Maintient le contrôle des clients sur les données, sans stockage IA tiers ni utilisation.
- **Garde-fous :** Appliquer les normes comportementales des agents et atténuer le non-déterminisme inhérent aux grands modèles de langage, en vérifiant que les agents suivent systématiquement des instructions et des workflows prédéfinis.
- **Précision**: Améliore les sorties IA en utilisant les données Salesforce pertinentes pour ancrer les invites.
- **Modération de contenu**: Offre une modération avant et après le contenu, un masquage des données personnalisable pour les informations confidentielles (PII/PCI/PHI) et une classification de la toxicité pour les réponses de grand modèle de langage (LLM).
#### Passerelle IA Agentforce
La passerelle IA fournit une interface unifiée qui permet d'accéder à et de gérer divers grands modèles de langage et modèles prédictifs. Il agit comme un pont entre Salesforce et le monde des grands modèles de langage, en faisant abstraction des complexités des différents fournisseurs de grands modèles de langage et des modèles d’IA prédictive des clients, offrant une façon cohérente d’interagir avec eux. La passerelle IA Agentforce s'intègre à plusieurs fournisseurs de LLM, ce qui permet aux clients de choisir le modèle le plus adapté à leurs besoins, et intègre des mesures de sécurité des données robustes pour aider à gérer les coûts associés à l'utilisation de différents LLM.
Feedback Service est un composant qui collecte, analyse, mesure et utilise les commentaires des utilisateurs pour réentraîner et affiner les modèles IA. Il joue un rôle crucial dans l'amélioration continue des fonctionnalités pilotées par l'IA dans Salesforce Platform.
#### Génération augmentée de récupération (RAG)
Le RAG est une technique vitale qui améliore les capacités de recherche avec l’IA générative, conduisant à des réponses plus explicites et plus précises. Utilisant l'étendue de Salesforce Data 360 et la base de données vectorielle intégrée, la plate-forme Agentforce récupère rapidement les données pertinentes pour la requête d'un utilisateur. Ces données sont ensuite utilisées comme ancrage pour les grands modèles de langage afin de générer des réponses optimales.
De plus, cette méthode augmente la vitesse de réponse et la Trust des utilisateurs en incluant des données sources dans les réponses. Le RAG est largement utilisé dans la plate-forme Agentforce, en particulier pour des applications comme Agentforce pour Service et Agentforce pour les ventes, mettant en évidence comment il expose des informations pertinentes pour ces cas d'utilisation.
### 7.4 Agentforce Platform
À mesure que les modèles d’IA progressent, le développement d’agents pour automatiser les tâches qui nécessitent un raisonnement est la prochaine étape. Ces agents servent d'assistants intelligents, capables de comprendre et de répondre aux requêtes en langage naturel, permettant aux utilisateurs de les concevoir, de les tester et de les déployer pour diverses tâches. Un élément crucial de ce système est le Service de planification, qui fonctionne comme suit :
- **Interpréte la requête utilisateur**: Il analyse l'entrée de l'utilisateur pour déterminer l'intention.
- **Élabore un plan**: Il formule un plan structuré pour répondre aux besoins de l'utilisateur.
- **Lance des actions**: Il exécute le plan en initiant des actions directement ou via d'autres services.
Le service de planification orchestre le processus, s'assurant que l'agent répond efficacement aux demandes des utilisateurs en gérant et en exécutant les étapes nécessaires.
#### Agentforce
Agentforce représente une plate-forme de création d'agents, permettant aux clients et aux éditeurs de logiciels de créer des agents IA automatisés pour des applications telles que Agents de service et Agents commerciaux. Ces agents peuvent traiter et répondre aux demandes des clients de façon naturelle et humaine, en gérant un large éventail de tâches métiers et en offrant des avantages importants à la fois aux entreprises et à leurs clients.
Le workflow d'un agent comprend :
- **Activation**: L'agent est déclenché par des critères prédéfinis tels que la demande d'un client à travers divers canaux.
- **Comprendre et réagir**: Il utilise le traitement en langage naturel (NLP) pour saisir la requête, l'intention et le sentiment du client, puis consulte la base de Knowledge Salesforce ou d'autres sources de données pour élaborer une réponse appropriée.
- **Complexités de traitement**: S'il est confronté à un problème complexe ou nécessite une surveillance humaine, l'agent peut transmettre l'interaction en douceur à un agent humain.
- **Apprentissage continu**: L'agent apprend de chaque interaction, améliorant continuellement ses réponses et ses performances générales.
#### Agentforce Studio
Agentforce Studio fournit une plate-forme low-code qui permet aux clients d'intégrer l'IA dans leurs applications et workflows Salesforce, rendant la technologie IA accessible au-delà des scientifiques des données.
Les principales caractéristiques du studio comprennent:
- **Générateur de modèle**: Permet d'élaborer ou d'importer des modèles IA adaptés à des besoins métiers spécifiques.
- **Générateur de répliques**: Un outil sans code/à faible code qui facilite la création et la gestion d'invites d'IA générative, en améliorant l'expérience utilisateur avec une interface simple pour élaborer, tester et déployer des invites.
- **Agent Builder**: Permet aux clients et aux éditeurs de logiciels de développer des agents conversationnels et autonomes personnalisés.
- **Centre de test**: Prend en charge les tests de modèles, d'invites et d'agents, essentiels pour garantir des applications IA de haute qualité et optimiser les performances et le rapport coût-efficacité, tout en améliorant les réponses déterministes et la qualité de l'expérience utilisateur.
Agentforce combine l'IA prédictive et l'IA générative, en s'appuyant sur l'infrastructure de métadonnées unifiées de Salesforce Platform et Data 360 pour offrir des solutions métiers intelligentes, personnalisées et efficaces.
### 7.5 La prochaine évolution : Agentforce 3.0
Pour répondre aux demandes croissantes du marché de l’IA générative, notamment aux progrès rapides du raisonnement, au besoin de systèmes multi-agents évolutifs et à la transition vers des interfaces multimodales, Salesforce fait évoluer son architecture avec Agentforce 3.0. Cette plate-forme de nouvelle génération repose sur plusieurs avancées clés :
- **Architecture asynchrone pilotée par les événements :** Agentforce 3.0 repose sur une fondation Python avec une infrastructure avancée pilotée par les événements. Cela permet une implémentation asynchrone et hautement évolutive des agents, améliorant les performances et jetant les bases de cas d'utilisation complexes et multi-agents dans lesquels les agents peuvent communiquer via des événements.
- **Capacités Voice multimodales :** Au-delà des interactions textuelles, Agentforce 3.0 introduit la prise en charge de la voix en tant que modalité principale. L'architecture s'intègre aux fournisseurs de téléphonie et aux passerelles WebRTC pour gérer la diffusion audio en temps réel. De nouveaux services gèrent la conversion du son en texte (ASR) et du texte en son (TTS), ce qui permet des expériences vocales conversationnelles naturelles pour des cas d'utilisation tels que les centres de contact automatisés.
- **Agentforce Script and Determinism:** Un mécanisme d'interception basé sur la machine d'état qui contraint le comportement des agents dans une structure explicitement définie, garantissant des parcours d'exécution cohérents. Cela permet des graphiques déterministes, fournit une gestion robuste des états pour éviter les pertes de mémoire, et facilite les transferts conditionnels et déterminés par LLM, garantissant ainsi des actions prévisibles et cohérentes pour les processus métiers critiques.
## 8\. Services de plate-forme d'application
L'écosystème d'applications de Salesforce Platform se distingue par son intégration des capacités entre les couches App Platform Services, API, Expérience utilisateur et Expérience développeur. Les services App Platform sont des capacités courantes utilisées pour élaborer et personnaliser la plupart des applications sur Salesforce Platform, alors que les capacités métiers sont généralement plus spécifiques à la solution.
### 8.1 Principales capacités
L'écosystème d'applications repose sur cinq capacités clés qui guident le processus de développement d'applications.
- **Location**: Cela implique la séparation logique des données et des métadonnées au sein d'un service multilocataire, permettant aux utilisateurs authentifiés d'accéder à des données et des fonctionnalités spécifiques. Cela est particulièrement visible pour les clients qui reçoivent une organisation Salesforce lors de leur inscription.
- **Entités**: Représentant les tableaux de base de données, les entités sont constituées de champs similaires à des colonnes de tableau. Les métadonnées Entité et Champ comprennent des attributs pour la modélisation des données, tels que des types de données et des noms d'API, ainsi que des attributs fonctionnels, tels que si l'entité est accessible en requête ou en écriture. Cette abstraction, plutôt que la manipulation directe du magasin de données lui-même, permet à Salesforce d'introduire et de basculer de façon transparente des technologies de stockage sans demander de mises à jour aux développeurs informatiques, ce qui garantit une fonctionnalité continue de l'application.
- **Contrôles d'accès**: Ces contrôles régissent l'accès des utilisateurs aux données et aux fonctionnalités, principalement en fonction de leur identité et de stratégies spécifiques. Les stratégies sont composées de règles et de commutateurs de fonctionnalité, et régissent les entités, les champs et les fonctionnalités accessibles. Les stratégies et les autorisations sont capturées dans des « ensembles d'autorisations », et l'accès est accordé en attribuant des ensembles d'autorisations à l'identité des utilisateurs.
- **Extension de couche**: Comme nous l'avons vu précédemment, cela prend en charge le développement indépendant de métadonnées et d'applications par différents rôles, notamment des ingénieurs Salesforce, des partenaires externes, des administrateurs informatiques et des utilisateurs finaux, facilité par des commandes d'enregistrement structurées et des espaces de noms de métadonnées.
- **Emballage**: Cette fonctionnalité permet d'empaqueter et de distribuer des métadonnées entre les locataires Salesforce, ce qui simplifie le processus de mise à jour et de distribution des applications sans avoir à les reconstruire.
Au-delà de ces capacités clés, App Platform Services comprend également :
- **Exécution et requête de données**: Prend en charge des opérations telles que la création, la mise à jour, la suppression et l'interrogation de données dans plusieurs magasins de données spécialisés. Un éventail d'échelles de données et de performances est pris en charge par une architecture qui permet d'exécuter des opérations de données directement sur le magasin de données, via une abstraction interne que les ingénieurs Salesforce peuvent utiliser, ou via la convention « Salesforce Object » ou sObject accessible aux clients.
- **Flux / Workflow / Formules**: Définition et exécution d'une logique métier et de règles de validation en utilisant des outils à faible code.
- **Code: Apex** Langage pro-code pour la logique d'application, intégré nativement aux exécutions de données et aux API de plate-forme.
- **Services d'infrastructure natifs du cloud :** Heroku fournit un environnement robuste aux développeurs qui utilisent des langages de programmation et des infrastructures de l'industrie pour élaborer, déployer et gérer des applications qui s'intègrent aux données et aux événements de la plate-forme.
- **Événements et notifications**: Gère les déclencheurs et l'orchestration basée sur l'événement.
- **Mondialisation**: Fournit la prise en charge des applications multilingues et multinationales.
- **Licences et provisionnement**: Gère l'achat et la gestion de l'accès aux capacités et aux applications de la plate-forme.
- **Pile Web Lightning**: Permet de personnaliser les interfaces visuelles en utilisant des métadonnées structurées, telles que des présentations, et des technologies Web standard.
- **Sites + CDN**: Garantit des expériences Web à faible latence et à fort trafic, y compris pour les utilisateurs non authentifiés.
- **Sécurité et conformité**: Offre des outils et des contrôles pour répondre à des exigences spécifiques de sécurité et de conformité organisationnelles.
- **Prévention de la perte**: de données Inclut des fonctionnalités de sauvegarde, de restauration et d'archivage des données.
### 8.2 Cloud Application Platform
Salesforce Platform fournit une suite d'outils et de capacités via Heroku qui permettent aux développeurs d'élaborer, d'exécuter et de gérer des applications dans le cloud en utilisant les langages de programmation et les infrastructures de leur choix. Heroku Cloud Application Platform géré fournit des exécutions d'application, des magasins de données, des files d'attente de messagerie et des systèmes d'événements en tant que services évolutifs pour élaborer des extensions aux applications Salesforce.
Les applications exécutées sur Heroku ont accès à la suite complète de capacités Salesforce, aux données clients et à la logique métier, et peuvent se connecter à des systèmes et des services tiers. Avec Heroku, les développeurs peuvent concentrer leurs efforts sur la création de valeur sans être accablés par des problèmes d'infrastructure sous-jacents.
## 9\. Automatisation
L'automatisation rend une application dynamique et est cruciale pour la transformation numérique des processus métiers essentiels.
L'automatisation des processus Salesforce a été créée pour répondre aux principaux défis auxquels sont confrontés les clients, notamment la nécessité de rationaliser et d'efficacité les processus métiers à mesure que les organisations évoluent. Ces défis impliquent souvent des workflows qui nécessitent un effort manuel excessif, entraînant des inefficacités et des coûts opérationnels plus élevés. Les clients recherchent une solution capable d'automatiser ces processus, de minimiser la main-d'œuvre manuelle, et de maintenir la cohérence et la précision.
L'absence d'un outil convivial permettant aux utilisateurs non techniques de concevoir et de mettre en œuvre des processus métiers sans compétences étendues en codage était un problème important. De plus, il fallait une solution qui puisse s'intégrer de façon sécurisée, évolutive et transparente aux tâches Salesforce automatisées existantes telles que la saisie de données, les approbations, les notifications et les processus complexes à plusieurs étapes.
L'automatisation des processus Salesforce répond à ces besoins en offrant une plate-forme robuste mais intuitive pour créer des workflows automatisés. Il permet aux utilisateurs d'élaborer et de personnaliser des flux via une interface visuelle, accessible aux utilisateurs techniques et non techniques, automatisant ainsi les tâches répétitives, appliquant des règles métiers et rationalisant les processus dans l'écosystème Salesforce.
Pour une automatisation qui nécessite une orchestration complexe interagissant avec des données transactionnelles, Salesforce propose Apex comme langage pro-code pour écrire une logique métier.
### 9.1 Architecture et capacités d'automatisation des processus
**Générateur de logique visuelle**: Les clients et les éditeurs de logiciels utilisent Flow Builder, une interface par glisser-déposer, pour créer des flux d'automatisation des processus sans code. Convivial pour tous les niveaux techniques, cet outil visuel permet aux analystes et administrateurs commerciaux de concevoir aisément des automatisations complexes.
Flow Builder permet aux clients de créer des flux polyvalents qui fonctionnent dans divers contextes, pris en charge par le Moteur de flux principal :
- **Déclencheurs d'enregistrement**: Les flux sont activés lors de la mise à jour d'enregistrements ou de soumissions de formulaires, ce qui permet de modifier les données, de valider et d'initier des workflows en fonction des actions des clients.
- **Flux planifiés ou pilotés par l'événement**: Ces flux peuvent fonctionner selon une planification prédéterminée ou se déclencher après des événements spécifiques, et peuvent passer des appels externes à des services externes.
- **Flux d'écran**: Offrez une interface utilisateur pour des processus guidés, pas à pas, avec des formulaires, des écrans et d'autres éléments interactifs, utiles pour des tâches telles que la saisie de données, le dépannage ou l'intégration.
- **Flux Orchestrateur**: Gérez et intégrez des processus à plusieurs étapes, ce qui facilite le traitement des opérations complexes.
Le Moteur de flux hors ligne peut être exécuté sans connexion au serveur d'application Salesforce. Le flux hors ligne pilote l'automatisation pour les cas d'utilisation mobiles Field Service. Le moteur de flux à grande échelle pilote les flux marketing. Il offre une échelle B2C pour traiter simultanément un volume élevé de flux longs.
Tous les cas d'utilisation et tous les environnements sont améliorés par un modèle de métadonnées unifié dans Flow Builder, qui prend en charge divers éléments logiques puissants applicables à tous les flux Automatisation des processus :
- **Logique et conditions avancées**: Les utilisateurs peuvent intégrer une logique complexe, par exemple des éléments de décision, des boucles et des conditions d'attente dans leurs workflows, ce qui permet de gérer des scénarios métiers complexes.
- **Gestion et transformation des données**: Flow Builder permet l'ingestion, la transformation et la gestion de données à partir de diverses sources, notamment des services Web, des organisations Salesforce et Data 360. Il prend en charge des opérations de données complètes telles que la création, la mise à jour, la suppression et l'interrogation d'enregistrements.
### 9.2 Automatisation à travers Salesforce Platform
L'automatisation des processus Salesforce offre une intégration transparente à d'autres produits Salesforce et systèmes tiers, ce qui garantit un flux de données fluide entre les applications pour une vue unifiée des processus métiers et des interactions avec les clients. Il prend en charge diverses méthodes d'intégration telles que les API, les appels externes Web et les connecteurs MuleSoft.
Les Services externes et la connectivité MuleSoft dans Salesforce permettent des connexions à des API externes et l'utilisation de leurs données dans Automatisation des processus Salesforce. L'enregistrement du schéma d'API permet de créer des actions invocables qui s'intègrent de façon transparente dans des flux, ce qui facilite l'automatisation des processus avec des sources de données externes. Les capacités d'intégration robustes de MuleSoft garantissent un flux de données transparent entre Salesforce et d'autres applications, éliminant les silos de données et offrant une vue unifiée des processus métiers.
**Agentforce Integration**: L'automatisation des processus Salesforce exploite Agentforce pour améliorer les workflows avec la prise de décision intelligente. Il utilise les connaissances IA pour diriger automatiquement les pistes vers les commerciaux appropriés ou initier des campagnes marketing sur mesure basées sur le comportement des clients, ce qui augmente l'efficacité de l'automatisation avec plus d'intelligence.
**Synergie de plate-forme**: L'automatisation des processus Salesforce s'intègre de façon transparente à d'autres produits Salesforce tels que Sales Cloud, Service Cloud, Commerce Cloud et Marketing Cloud. Cette intégration permet aux organisations d'automatiser les processus dans divers services, ce qui améliore l'efficacité opérationnelle. Par exemple, un workflow peut générer automatiquement une requête de support dans Service Cloud lorsqu'une plainte d'un client est soumise via un formulaire Marketing Cloud.
### 9.3 Automatisation pro-code avec Apex
Apex est un puissant langage de programmation orienté objet qui permet aux développeurs d'écrire une logique métier personnalisée et d'effectuer des opérations complexes sur la plate-forme Salesforce. Il a été un pilier de notre plate-forme, et actuellement la plate-forme gère plus de 350 milliards de transactions Apex par mois (en octobre 2025).
Apex est utilisé pour développer un large éventail de fonctionnalités personnalisées et des intégrations profondes dans la plate-forme Salesforce, notamment:
- **Automatisation basée sur le déclencheur**: Implémentez une automatisation complexe exécutée avant ou après l'insertion, la mise à jour ou la suppression d'enregistrements. Cela permet de valider des données complexes, de mettre à jour les enregistrements associés et d'invoquer d'autres processus basés sur des modifications de données spécifiques.
- **Services Web :** Créez des intégrations personnalisées avec des systèmes externes et appelez depuis Apex des API REST ou SOAP.
- **Interfaces utilisateur personnalisées**: Élaborez des interfaces utilisateur et des expériences hautement personnalisées en utilisant Visualforce et Lightning Web Components (LWC), où Apex sert de contrôleur back-end pour gérer la manipulation des données et la logique métier.
- **API personnalisées :** Les développeurs peuvent exposer une logique personnalisée sous forme d'API en utilisant Apex REST et Apex SOAP, ce qui permet aux systèmes externes d'interagir avec les données et les processus Salesforce par programmation.
- **Traitement asynchrone**: Exécutez de façon asynchrone des tâches longues ou gourmandes en ressources à l'aide de méthodes futures, Apex Queueable et Apex planifié. Cela permet de décharger et de traiter en arrière-plan les opérations de longue durée, ce qui améliore l'expérience utilisateur et les performances système.
- **Apex planifié :** Les développeurs peuvent planifier l'exécution de classes Apex à des heures spécifiques en utilisant Apex Scheduler pour des tâches périodiques telles que la synchronisation nocturne des données, la génération de rapports et des activités de maintenance.
## 10\. Expériences utilisateur
Les capacités Expériences utilisateur de Salesforce Platform permettent aux utilisateurs d'interagir avec des applications via diverses options de déploiement à travers les applications Lightning basées sur le navigateur, les sites Experience, les composants mobiles natifs, orientés IA, UX collaboratif ou incorporés en utilisant Lightning Out.
### 10.1 Système de conception Lightning
Le système de conception Salesforce Lightning (SLDS) est une infrastructure de conception complète qui favorise la création d'interfaces utilisateur cohérentes et accessibles avec les principes de conception de Salesforce pour une expérience utilisateur cohérente à travers tous les produits. Elle permet aux ingénieurs, aux clients et aux partenaires Salesforce de créer des applications natives dans l'écosystème Salesforce.
Les principales caractéristiques du système de conception comprennent :
- **Conception de modèles**: Solutions éprouvées aux défis courants de conception, fournissant des consignes de présentation, de présentation des données et d'interactions utilisateur pour garantir une expérience utilisateur cohérente.
- **Hooks de style**: Variables CSS qui représentent les décisions de conception, telles que les couleurs, la typographie, l'espacement et les tailles, garantissant la cohérence entre les applications.
- **Lightning Base Component Library**: Une collection de composants d'interface utilisateur réutilisables, tels que des boutons, des éléments de formulaire et des éléments de navigation, qui respectent les principes de conception de Salesforce, ce qui facilite un développement rapide et efficace.
- **Accessibilité**: Fonctionnalités et consignes d'accessibilité intégrées pour s'assurer que tous les composants sont utilisables par les personnes handicapées et respectent les normes, notamment les directives Web Content Accessibility Guidelines (WCAG).
- **Présentations réactives**: Un système de grille flexible et des consignes de présentation qui permettent aux applications de s'adapter de façon transparente à différents appareils et tailles d'écran.
- **Outillage**: Une collection d'outils, de ressources et de technologies qui prennent en charge l'hygiène des composants, la réduction anti-modèle et la gouvernance du système de conception.
L'infrastructure SLDS continue d'évoluer pour prendre en charge des hooks de style plus riches et des capacités de personnalisation approfondies afin que les composants puissent être réutilisés tout en restant personnalisés pour répondre aux exigences uniques de marque et de thème. Notre aspiration au système de conception est de rendre Salesforce rapide, facile et attrayant à utiliser avec l'IA.
### 10.2 Lightning Web Stack
L'interface basée sur le navigateur de Salesforce, connue sous le nom de Lightning, offre un conteneur d'interface utilisateur cohérent et une infrastructure d'interface utilisateur pilotée par les métadonnées et une collection de technologies permettant aux ingénieurs, administrateurs informatiques, développeurs et partenaires Salesforce de développer rapidement une interface utilisateur avec une esthétique Salesforce cohérente, ainsi que des points d'extension pour un contrôle complet du remodelage et du changement de marque. La pile Web Lightning comprend plusieurs technologies :
- **Composants Web Lightning**: Composants Web personnalisés élaborés avec HTML et JavaScript, respectant les normes Web du W3C.
- **Sécurité Web Lightning**: Un moteur de virtualisation qui gère le code JavaScript dans le navigateur, garantissant la conformité aux normes de sécurité de Salesforce pour le code tiers.
- **Lightning Data Services**: Une infrastructure conçue pour une interaction efficace avec les données côté serveur.
- **Lightning Web Runtime**: Garantit un rendu de l'interface utilisateur performant et cohérent entre divers clients.
L'ingénierie Salesforce a intégré les leçons tirées des technologies d'interface utilisateur précédentes et contribué aux organismes de normalisation Web, influençant le développement d'implémentations de composants basées sur des normes. Par exemple, Salesforce reste membre d'une vingtaine de groupes de travail du W3C. Les Composants Web Lightning et la Pile Web Lightning respectent ces normes de l'industrie, ce qui réduit la complexité pour les développeurs.
### 10.3 Mobile
Le mobile reste une interface de plus en plus importante et essentielle pour les utilisateurs qui interagissent avec les applications Salesforce.
Salesforce fournit une application mobile native afin que toutes les applications Lightning basées sur un navigateur puissent devenir des applications mobiles sans avoir à écrire un nouveau code. Salesforce offre également une gamme d'outils, de kits de développement et de capacités pour créer des applications natives entièrement personnalisées optimisées pour les appareils. Il s'agit notamment de :
- **Mobile SDK**: Interface pro-code pour développeurs à travers les systèmes d'exploitation mobiles qui simplifie l'intégration avec l'authentification, la gestion des sessions/jetons, les API Salesforce, et bien plus encore.
- **Mobile Native Runtime**: Permet aux développeurs de créer des expériences natives pilotées par les métadonnées restituées dynamiquement à l'exécution en utilisant les technologies iOS et Android qui exploitent également les capacités sur l'appareil.
- **Marque**: Permet de personnaliser l'esthétique des applications mobiles via le Pipeline Mobile Publisher pour la conversion des applications mobiles Salesforce en applications de marque client.
- **Capacités hors ligne**: Garantit une fonctionnalité d'application transparente avec une connectivité Internet incohérente ou inexistante.
Mobile Customization Framework (MCF) améliore considérablement le développement d'applications mobiles Salesforce natives en offrant une facilité d'utilisation et des options de personnalisation étendues. Les principaux avantages comprennent :
- **Approche pilotée par les métadonnées**: MCF utilise des métadonnées, qui peuvent provenir de générateurs visuels, de référentiels communs et de ressources hébergées par Salesforce, pour créer des expériences utilisateur dynamiques et adaptables adaptées à des besoins spécifiques.
- **Expérimentation et optimisation**: L'infrastructure prend en charge l'expérimentation à l'exécution avec différentes présentations, ce qui facilite l'optimisation continue de l'engagement et l'amélioration de l'expérience utilisateur.
- **Extensibilité**: Conçu pour la flexibilité, MCF permet l'intégration de composants personnalisés dans l'infrastructure de métadonnées principale, ce qui améliore les fonctionnalités et la polyvalence.
- **Expériences utilisateur composables**: Utilisant les toutes dernières technologies iOS et Android, MCF prend en charge l'assemblage de composants réutilisables tels que des boutons, des listes et des cartes pour créer des interfaces utilisateur sophistiquées.
- **Personnalisation de l'exécution**: MCF permet la personnalisation et l'expérimentation de l'interface utilisateur en temps réel, ce qui favorise une expérience utilisateur plus personnalisée et plus attrayante.
Les scénarios hors ligne et à faible connectivité sont plus préoccupants lorsque vous utilisez des applications sur des appareils mobiles. La pile de technologies mobiles donne la priorité à l'élaboration d'applications qui peuvent être hors ligne. Les principales fonctionnalités comprennent :
- **Cache First Experience**: Met l'accent sur la mise en cache des données pour une utilisation hors ligne, garantissant des performances et une sécurité élevées. L'interaction des utilisateurs est également conçue pour les principes de restitution hors ligne.
- **Gestion du cache**: Garde le cache pertinent et mis à jour, même hors ligne.
- **Cache partagé**: Utilise un cache unique pour les écrans natifs et hybrides, ce qui facilite des expériences hors ligne transparentes.
Nimbus est la solution prête pour la production de la plate-forme qui simplifie le processus d'accès aux capacités de l'appareil pour les développeurs d'applications hybrides. Traditionnellement, combler le fossé entre JavaScript et le code natif mobile était une tâche complexe. Cependant, avec Nimbus, les développeurs peuvent désormais exploiter tout le potentiel des appareils mobiles sans explorer le codage de bas niveau. Les principales fonctionnalités comprennent :
- **Accès large**: Fournit une intégration transparente avec une variété de fonctionnalités de l'appareil telles que la caméra, le microphone, la géolocalisation et LiDAR.
- **Interface normalisée**: Offre une méthode uniforme pour accéder aux capacités de l'appareil.
- **Intégration d'application hybride**: Permet aux applications hybrides d'utiliser pleinement les fonctions de l'appareil.
- **Développement efficace**: Rationalise le processus de développement d'applications, réduisant ainsi la complexité.
À mesure que l'IA continue de transformer les possibilités des applications Salesforce, Salesforce offre également une expérience utilisateur différenciée en exploitant des modèles d'IA sur appareil spécifiques à une tâche, ainsi que des solutions basées sur le cloud :
- **Petits modèles de langage (SLM) :** Ils peuvent être exécutés efficacement et à moindre coût sur les appareils mobiles.
- **Confidentialité et sécurité :** Garantit la confidentialité des utilisateurs et maintient Trust et sécurité à des niveaux comparables aux modèles basés sur le serveur.
- **Fonctionnalité hors ligne :** Fonctionne efficacement dans les environnements à faible connectivité, en activant les cas d'utilisation hors ligne.
- **Voix :** Les modèles de pointe de synthèse vocale, de synthèse vocale naturelle et de diarisation des haut-parleurs sont désormais exécutés en natif sur les appareils, offrant des interactions vocales haute fidélité avec une confidentialité totale et une latence nulle.
### 10.4 IA et collaboration
L'interface utilisateur non-modèle pour le langage naturel et les interactions à tours multiples avec notre application va continuer à augmenter en prévalence. Les futurs développements devraient améliorer l'intégration entre les modèles, les capacités des appareils et les applications, en améliorant les interactions des utilisateurs grâce à des interfaces vocales et textuelles plus intuitives. La collecte de métriques sur l'appareil permettra également des ajustements personnalisés en fonction des préférences des utilisateurs.
La collaboration est essentielle entre tous les utilisateurs, y compris les humains et les agents, pour exploiter les forces combinées de l'automatisation et de la supervision humaine. Cette collaboration est particulièrement cruciale pour les interactions métiers complexes impliquant les employés d'une organisation et ses clients. Slack est l'outil principal dans Salesforce Platform, qui facilite cette interaction par messagerie directe et canaux multi-utilisateurs adaptés à des thèmes de discussion spécifiques. Ces discussions peuvent aller de conversations spontanées créées par l'utilisateur à des dialogues plus structurés centrés sur des données spécifiques dans le workflow d'un utilisateur, par exemple un fil de messages Slack détaillé traitant d'un problème client important.
À l'avenir, Salesforce Platform prévoit d'améliorer l'expérience collaborative actuellement offerte par Slack. Cette extension visera à exploiter pleinement les capacités étendues de la plate-forme, en enrichissant la façon dont les utilisateurs interagissent et collaborent dans l'espace de travail numérique.
## 11\. Expérience du développeur
Les capacités Expérience du développeur sur la plate-forme fournissent des outils pour élaborer, personnaliser, tester et déployer des applications, en se concentrant sur le spectre des approches à faible code via des approches pro-code, garantissant l'égalité des chances pour les développeurs de tous les niveaux de compétence.
- **Outils à faible code**: Il s'agit notamment du Générateur de schéma pour les modèles de données, de Flux pour les règles métiers et d'AppBuilder pour la personnalisation de l'interface utilisateur, tous conçus pour simplifier le processus de développement en manipulant des métadonnées structurées et en travaillant dans le langage de la solution métier, au lieu de concepts techniques et de jargon.
- **Outils Pro-Code**: Pour les développeurs qui ont besoin d'une personnalisation plus riche et complexe, la plate-forme offre des outils tels que le Générateur de code Salesforce, un IDE basé sur le cloud, ainsi qu'une interface de ligne de commande (CLI) et des API pour le codage avancé et la création de composants. Les développeurs peuvent coder dans la langue de leur choix en exploitant des solutions de déploiement, de gestion et d'optimisation d'applications avec Heroku.
- **Environnement de développement intégré**: L'écosystème Salesforce prend en charge l'intégration transparente entre les outils low-code et pro-code, ainsi que le développement cohérent dans le cloud et localement avec les outils standard du secteur.
- **Gestion du cycle de vie des applications (ALM)**: Présente une gamme d'organisations sandbox pour le développement séparées de l'environnement de production, y compris des organisations tests pour le développement initial et des organisations Sandbox Full pour les tests par rapport aux données et à l'échelle de type production.
### 11.1 IA pour développeurs
L'IA et les « Developer Assistants » révolutionnent l'expérience des développeurs en simplifiant et en accélérant la création d'applications efficaces et de grande qualité. Chez Salesforce, nos équipes de recherche IA et Expérience du développeur itèrent et explorent en permanence comment l’IA prédictive et générative avec le raisonnement agentique peut être transformée en puissants agents de développement. Ces agents de développeur sont intégrés nativement aux outils que les développeurs utilisent déjà, comme VS Code, Code Builder, ligne de commande, DevOps Center et Code Analyzer, ce qui les rend plus pertinents et impactants.
Nous avons fait des progrès importants dans l'analyse de code pour identifier les anti-patterns et les points chauds dans le code Apex, puis fournir des recommandations critiques pour améliorer leur implémentation. Les problèmes identifiés gaspillent généralement des ressources informatiques et entraînent souvent des incidents à grande échelle. Il a été lancé sous le nom ApexGuru Insights en janvier 2024.
Au cours de la première année suivant son lancement, plus de 2800 organisations Salesforce ont utilisé ApexGuru pour analyser et améliorer leur implémentation Salesforce. Plus de 22 000 recommandations ont été implémentées avec succès, ce qui a permis d'économiser 28 000 heures processeur par semaine. Cette amélioration non seulement améliore les performances, mais contribue également à la durabilité environnementale en réduisant les émissions de CO2 de 135 kg par semaine, conformément à notre valeur fondamentale Durabilité et à notre engagement à réduire les émissions carbone.
Nous intégrons également l'IA dans les outils et les capacités des développeurs pro-code afin d'améliorer Developer Productivity. Produite sous le nom « Agentforce pour développeurs » en 2024, les développeurs peuvent accéder à ces nouvelles capacités au sein des packs Extension Salesforce dans le code Visual Studio et le Générateur de code. Ces extensions activent :
- Suggestions de code en ligne pendant que le développeur écrit et génère du code pour Apex et Lightning Web Components (JavaScript, CSS, HTML).
- Explication de code et génération de documentation pour Apex et Composants Web Lightning.
- Génération de code de test unitaire Apex.
- Une expérience de chat à plusieurs tours distincte dans l'IDE qui peut fonctionner sur plusieurs réponses pour la génération de code, l'explication et la documentation.
- Optimisations des composants Web Lightning.
- Génération d'agents avec des métadonnées YAML lisibles par l'utilisateur, y compris les capacités de test et de débogage des agents.
En octobre 2025, plus de 42 000 développeurs utilisent activement cette technologie chaque mois, avec 17,6 millions de lignes de code acceptées. Cette suite complète garantit un environnement de développement flexible, intégré et efficace, répondant à un large éventail de besoins de développement dans Salesforce Platform. Les outils pour développeurs IA sont également améliorés avec une architecture qui fonctionne à travers plusieurs modèles externes et élaborés par Salesforce afin de choisir le modèle le plus efficace et le plus efficient pour un cas d'utilisation donné.
### 11.2 Prise en charge de MCP et codage assisté par l’IA
Le Model Context Protocol (MCP) est une norme ouverte émergente conçue pour permettre aux agents IA d'interagir de façon sécurisée et cohérente avec n'importe quel outil ou source de données. Salesforce intègre nativement la prise en charge MCP dans la boîte à outils pour développeur Salesforce afin d'aider les agents développeurs qui peuvent accéder aux capacités et aux outils de leur entreprise. Cela comprend :
- **Serveur MCP local :** Un serveur MCP local permet aux développeurs d'élaborer, de tester et de déboguer aisément leurs intégrations agentiques dans leur IDE local avant le déploiement en production, ce qui améliore considérablement la productivité. Le serveur MCP local offre des outils spécialisés pour les interactions de l'organisation et les workflows de développement, tels que le développement mobile, les tests d'accessibilité, la migration Aura vers LWC et les DevOps agents. Le serveur MCP local inclut également l'intégration au raisonnement agentique et aux grands modèles de langage pour mieux permettre aux développeurs de « coder » leur application de façon itérative et en langage naturel.
- **Serveur MCP personnalisé pour les API Salesforce :** Les développeurs peuvent désormais exposer en toute sécurité les API Salesforce, les objets Data 360 et les flux d'automatisation en tant qu'« outils » MCP. Cela transforme l'ensemble de Salesforce Platform en un ensemble riche, fiable et découvrable de capacités pour n'importe quel agent ou application IA externe, avec un contrôle d'accès précis et le potentiel de nouveaux modèles de monétisation basés sur la consommation.
- **Connectivité MCP externe native :** Les développeurs peuvent également gérer en toute sécurité la connectivité à des serveurs externes conformes à la norme MCP. Cela permet aux développeurs de créer des agents capables de travailler dans l'ensemble de leur entreprise.
## 12\. Suite d'applications
Nos clouds d'applications, notamment Sales Cloud, Service Cloud, Marketing Cloud, Revenue Cloud et Commerce Cloud, sont élaborés sur Salesforce Platform, offrant des capacités métiers de premier plan et composant notre Suite d'applications pour favoriser la réussite des clients. Les principales fonctionnalités comprennent :
- **Intégration transparente**: Profondément intégré, conçu pour fonctionner de façon cohérente à travers le parcours client et garantir un flux fluide de données et de processus à travers les points de contact des clients, améliorant ainsi l'expérience client.
- **Personnalisation de bout en bout**: Élaborées sur notre plate-forme, nos applications offrent des options de personnalisation étendues, du sans code au pro-code, permettant une adaptation précise aux besoins des clients.
- **Capacités IA avancées**: Offrez des workflows interactifs basés sur un canal assistés par un agent et autonomes avec nos Agentforce Agents. Incorpore l’IA prédictive et générative pour accroître l’efficacité grâce à l’automatisation, aux analyses prédictives et à des expériences utilisateur personnalisées, en fournissant des connaissances et des recommandations actionnables.
- **Traitement des données en temps réel**: Utilise Data 360 pour l'accès et l'analyse en temps réel des données, ce qui permet de prendre des décisions informées et en temps opportun sur la base des informations les plus récentes. Cela améliore la réactivité et l'agilité dans les environnements rapides.
- **Données et analytiques unifiées**: Intègre diverses sources de données dans une plate-forme centralisée pour des vues de données cohérentes et complètes, qui fournissent des analyses précises et améliorent la prise de décision.
- **Sécurité et conformité renforcées**: Comprend des outils de sécurité et de conformité robustes pour protéger les données confidentielles et satisfaire aux normes réglementaires.
- **Expérience utilisateur consommateur**: Offre des interfaces intuitives et conviviales qui rendent les applications accessibles et efficaces à travers les appareils, les canaux et les modalités.
- **Fiabilité**: Garantit un minimum de temps d'arrêt et d'évolutivité pour soutenir les opérations essentielles à la mission et à la vie, y compris les services d'urgence et les systèmes de transport critiques.
- **Évolutivité élastique**: Basé sur Hyperforce qui prend en charge l'augmentation des volumes de données et d'interaction des utilisateurs sans sacrifier les performances ou le coût à servir.
- **Amélioration continue**: Intègre régulièrement des innovations pour améliorer les capacités sans perturber les opérations existantes.
Salesforce s'engage à faire progresser ses applications en unifiant les capacités sur l'ensemble de sa plate-forme, en s'appuyant sur les technologies de base décrites dans ce livre blanc. Cette transformation est guidée par une série de priorités clés qui déterminent la conception et le développement de la suite d'applications Salesforce.
### 12.1 Échelle et performance
Nos équipes applicatives sont spécialisées dans les performances et l'évolutivité, utilisant des laboratoires de performance avancés pour créer des répliques exactes de nos environnements de production avec des données synthétiques. Cette configuration permet de simuler en profondeur les parcours utilisateur parallèles pour s'assurer que chaque nouvelle fonctionnalité est testée en profondeur et son impact évalué. Lorsque des goulets d'étranglement à l'exécution sont identifiés, nous ajustons dynamiquement les limites en taux et d'autres mesures pour protéger l'intégrité du système tout en recueillant des données pour favoriser la résolution.
Nos systèmes sont conçus pour l'échelle horizontale afin d'utiliser efficacement la flexibilité du cloud public. Les contrôles automatisés garantissent que les mises à jour ou les améliorations n'affectent pas négativement les performances. Nous employons des autotartres prédictifs qui gèrent proactivement la charge du système, non seulement en réagissant à l'augmentation de la demande, mais en anticipant et en ajustant à l'avance.
L'échelle automatique est cruciale pour réduire les coûts de service en réduisant la capacité inutilisée. Nous surveillons de près les coûts de fonctionnement du système, en identifiant et en corrigeant les inefficacités dans l'échelle automatique ou l'utilisation des ressources. Bien que la rentabilité soit importante, nous accordons la priorité à la livraison d'applications fiables, en optant pour des détartreurs automatiques qui s'adaptent rapidement et lentement pour maintenir la Trust des clients, même si cela entraîne des coûts plus élevés.
### 12.2 Intégration transparente
#### Modèle de données commun
Les modèles de données sont fondamentaux pour toutes les opérations commerciales chez Salesforce. Ils influencent les capacités commerciales, les API, la navigation, les affichages d'interface utilisateur et les rapports qui peuvent être créés. Ils font partie intégrante des fonctionnalités de la plate-forme.
Notre suite d'applications partage un modèle de données commun entre Sales Cloud, Service Cloud, Revenue Cloud, Commerce Cloud, Marketing Cloud et Industries Cloud. Cela contribue à notre suite intégrée, en fournissant un comportement et une interopérabilité cohérents, et des chemins clairs pour les mises à niveau et les extensions.
Par exemple, le partage d'entités Compte et Produit entre tous les Clouds permet aux utilisateurs de Marketing Cloud et de Sales Cloud d'échanger des données, des métadonnées, des composants d'interface utilisateur et une logique métier. Cette intégration permet de briser les cloisonnements et favorise la collaboration interfonctionnelle.
#### Plate-forme de données virtuelles
Un modèle de données commun à tous les Clouds Salesforce améliore considérablement l'intégration, mais peut ne pas répondre à tous les besoins complexes d'intégration de partenaires. Le modèle de données Data 360 Common s'enrichit en étendant les avantages du modèle de données partagé au-delà des frontières de données typiques de Salesforce, en tenant compte de scénarios d'intégration plus étendus.
#### Extensibilité en couches
L'infrastructure de métadonnées de Salesforce permet à divers groupes, tels que les équipes d'ingénieurs, les éditeurs de logiciels, les partenaires, les administrateurs et les utilisateurs, de personnaliser et d'étendre leurs applications dans des couches d'extensibilité distinctes sans interférer entre eux. Cette structure prend en charge un environnement évolutif dans lequel les modifications apportées par un groupe ne perturbent pas les autres, préservant ainsi l'intégrité du système.
Le produit Connaissances unifiées, qui intègre toutes les sources Knowledge dans un lac de données, est un excellent exemple du Framework en action. Cette configuration inclut une couche sémantique et des retrievers, ce qui améliore les capacités d’IA prédictive et générative dans Sales Cloud, Service Cloud, Revenue Cloud, Marketing Cloud et Commerce Cloud. Il intègre un modèle de données pour Knowledge non structuré et semi-structuré lié au modèle Knowledge structuré existant.
De plus, l'infrastructure utilise des métadonnées pour définir des relations personnalisées entre les types de données, ce qui facilite la génération de requêtes avancées. Cela permet aux équipes applicatives de créer des applications personnalisables qui exploitent cette base de Knowledge complète, tandis que les éditeurs de logiciels, les partenaires et les clients peuvent améliorer davantage les capacités applicatives en modifiant les relations des métadonnées ou en développant des récupérateurs personnalisés pour des cas d'utilisation métiers spécifiques.
#### Amélioration de la plate-forme de données commune
Les données des clients sont stockées en toute sécurité sur diverses plates-formes telles que SalesforceDB et Data 360, et sont normalisées et normalisées, quel que soit leur format structuré ou non. Cela garantit un traitement cohérent des données via un format unifié appelé sObject, qui prend en charge une plate-forme de données cohérente entre toutes les données des clients.
Cette normalisation active une API unique pour toutes les opérations de données, une interface unifiée pour les déclencheurs dans Apex, et la création de workflow personnalisés avec Flux. Il prend également en charge Tableau Next, ce qui permet des vues de données personnalisées et l'intégration à des outils d'IA générative tels que Générateur de répliques pour générer des réponses intelligentes basées sur les données des clients.
De plus, les applications Salesforce s'intègrent à divers magasins de données pour accroître la flexibilité des processus métiers dans les produits. Par exemple, dans Marketing Cloud, Flux est utilisé pour gérer les expériences clients multi-touch, avec des options d'utilisation de modèles prédéfinis ou d'élaboration de flux personnalisés qui intègrent le marketing à d'autres processus métiers, le tout basé sur les données clients sous-jacentes.
### 12.3 Capacités commerciales partagées
Les applications exploitent et améliorent les services partagés tels que la résolution de l'identité, l'orchestration de contenus, la personnalisation, les analytiques, la passerelle LLM et les services de raisonnement, ce qui permet d'innover et de livrer rapidement. Ces services prennent en charge le traitement des données en temps réel, les connaissances pilotées par l'IA et des expériences utilisateur enrichies, offrant une vue complète des clients.
Les avantages comprennent une efficacité accrue grâce à une automatisation intelligente et à des analyses prédictives, une évolutivité qui augmente les interactions avec les données et les utilisateurs, et une sécurité et une conformité robustes. Les capacités de personnalisation de la plate-forme permettent aux organisations de s'adapter rapidement à l'évolution des besoins, favorisant ainsi la croissance et l'excellence opérationnelle.
L'innovation au niveau de l'application est propulsée par Salesforce Platform et les applications individuelles, ce qui améliore l'écosystème Salesforce et établit les applications en tant que leaders du secteur.
### 12.4 Multicanal et optimisé pour les canaux
Les applications Salesforce sont conçues pour répondre aux besoins des utilisateurs sur diverses plates-formes, notamment Web, mobile, e-mail, SMS, WhatsApp et d'autres canaux. Ils optimisent les capacités natives de chaque canal pour améliorer l'expérience utilisateur et l'efficacité.
Les fonctionnalités comprennent des capacités hors ligne sur plusieurs mois pour les utilisateurs de Salesforce Field Service, des notifications push de navigateur, et des présentations grand écran pour les agents de service dans Lightning Service Console, et des devantures et des copilotes très performants pour les acheteurs Commerce.
La plate-forme de métadonnées permet à Salesforce, à ses partenaires et à ses clients de bénéficier immédiatement de ces capacités dès leur sortie de l'emballage.
### 12.5 Mise en oeuvre rapide de l'innovation
Les services de base, la plate-forme et les capacités métiers partagées de Salesforce permettent aux applications de s'adapter rapidement aux changements du marché et aux tendances technologiques, ce qui accélère la livraison d'innovations. Par exemple, avec l'avènement de l'IA générative, Salesforce a rapidement utilisé les services d'IA existants tels que la couche Trust NLP et la détection des intentions pour incorporer des modèles d'invite à la plate-forme de communications universelles. Cette intégration améliore les fonctionnalités de messagerie et de téléphonie à travers les produits, ce qui facilite les connexions client plus personnelles.
Suivant la tendance à l'IA autonome, Salesforce a lancé Agentforce, une solution qui capitalise sur ces investissements existants pour automatiser efficacement les cas d'utilisation métiers avec des agents, sans avoir besoin de construire de toutes pièces.
### 12.6 Chemin vers la Suite d'applications
Nous avons reconstruit Marketing Cloud, Revenue Cloud et Commerce Cloud sur Salesforce Platform, permettant à ces Clouds de partager la même infrastructure, plate-forme, métadonnées, données, IA, composants d'interface utilisateur et logique métier, tout en bénéficiant de toute la puissance de Salesforce Platform. Par exemple, nous avons repris des fonctionnalités de Revenue Cloud et incorporé des capacités de base telles que le configurateur basé sur les contraintes, les moteurs de tarification et la gestion du catalogue, ce qui en fait des services de base disponibles dans l'ensemble de la suite. Cela nous permet également d'avoir une intégration transparente dans tous nos clouds, et les capacités offertes par Commerce Cloud et Marketing Cloud font partie des capacités métiers partagées qui peuvent être exploitées par les autres applications. C'est notre vision de la suite d'applications intégrée livrée.
Le parcours de Salesforce Platform a conduit au développement d’une suite d’applications intégrée qui combine Sales Cloud, Service Cloud, Marketing Cloud, Revenue Cloud et Commerce Cloud en une solution unifiée. Disponible à partir de l'édition Salesforce Starter, cette suite offre la portée multicanal, la gestion de la relation client et des connaissances métiers dans un package cohérent. Quelle que soit l'édition choisie, les utilisateurs peuvent accéder aux capacités de base de Sales Cloud, Service Cloud, Marketing Cloud et Commerce Cloud, ce qui garantit une expérience cohérente à tous les niveaux.
## 13\. Solutions spécifiques au secteur d'activité
Les produits Salesforce Industries pour les services financiers, la santé, les sciences de la vie, les médias, l'énergie et les services publics, la fabrication, l'automobile, les biens de consommation, la vente au détail, Net Zero, le secteur public, l'éducation et les organisations à but non lucratif, étendent nos produits applicatifs et notre plate-forme pour fournir des solutions sur mesure qui répondent aux défis uniques des secteurs d'activité. Ils rationalisent les opérations et augmentent la productivité en incorporant des workflows, des mesures de conformité et des modèles de données spécifiques au secteur d'activité.
Le portefeuille Industries a été reconstitué sur Salesforce Platform pour permettre la composition verticale. Les clients peuvent désormais assembler une ou plusieurs capacités du secteur en solutions sur mesure, en exploitant des métadonnées partagées, des API et des services commerciaux. Cette approche concilie la différenciation verticale et la cohérence de la plate-forme, garantissant l'adaptabilité et l'évolutivité dans divers contextes réglementaires et métiers.
### 13.1 Approche de l'architecture en couches
Nos produits utilisent une architecture en couches. À la base se trouve Salesforce Platform et des applications horizontales telles que Sales Cloud et Service Cloud, qui servent de base à toutes les solutions du secteur. À cela, Salesforce a ajouté des services communs à valeur ajoutée qui améliorent les composants réutilisables incorporés dans la plupart des secteurs d'activité. Les capacités d'automatisation numérique, les chronologies, les plans d'action, et davantage, en sont des exemples. Au-dessus de cette couche, il y a une couche logique métier réutilisable qui encapsule les capacités horizontales telles que la gestion des commentaires, CPQ (config, price, devis) et la gestion du service.
La couche supérieure propose des personnalisations spécifiques au domaine adaptées aux exigences spécifiques du secteur d'activité, en exploitant la plate-forme sous-jacente pour plus d'évolutivité et d'efficacité. Par exemple, dans la verticale de fabrication, cette configuration optimise la planification de la production grâce à des prévisions précises. Dans le secteur des sciences de la vie, il fournit aux équipes commerciales pharmaceutiques des solutions mobiles hors ligne qui gèrent efficacement les workflows et le traitement des échantillons tout en respectant les diverses exigences réglementaires géographiques.
### 13.2 Capacités propres au secteur d'activité
**Intelligence artificielle approuvée Excellence**: Nos solutions d’IA générative de confiance offrent des capacités d’IA spécifiques au secteur d’activité. Il s'agit notamment des agents et de l'ingénierie rapide, qui facilitent l'automatisation et la numérisation à faible code ou sans code dans des secteurs tels que la santé, les sciences de la vie et les services financiers. De plus, des fonctionnalités telles que le minage de documents/textes et la synthèse répondent aux besoins des industries qui gèrent de grands volumes de données, ce qui facilite l'extraction d'informations et la collecte de connaissances.
Les agents personnalisés améliorent la communication tridirectionnelle entre les agents et les clients, ce qui accélère les résolutions. La couche Trust de Salesforce Platform facilite l'adhésion à toutes les normes de conformité et réglementaires à travers les secteurs d'activité.
**Données, connaissances et intelligence avec la conformité réglementaire et la sécurité**: Salesforce Industries offre une vue complète à 360° avec des mesures strictes de confidentialité, de partage et de sécurité des données adaptées à des réglementations spécifiques du secteur telles que GDPR, HIPAA et FedRamp. Salesforce intègre des données de diverses sources, ce qui permet la conformité et la sécurité, et améliore ces solutions avec des fonctionnalités supplémentaires telles que Shield Encryption BYOK (Bring Your Own Keys) pour le cryptage des données locataires.
**Expérience utilisateur améliorée**: Salesforce Industries met l'accent sur une expérience utilisateur transparente et adaptée aux besoins spécifiques du secteur d'activité afin d'améliorer le parcours utilisateur. Cela inclut des outils tels que le Centre de ressources actionnables, des modèles Experience Cloud et des solutions basées sur OmniStudio.
**Numérisation, intégration et intégration**: Salesforce Industries fournit la numérisation, l'intégration et l'intégration via des solutions low-code à sans code, en exploitant des outils tels que Flows et Omnistudio pour de nouveaux clients et en offrant des solutions de migration pour les systèmes CRM existants. L'intégration à des systèmes et des données externes est rationalisée via les connecteurs proposés par MuleSoft. Salesforce inclut également des processus de service spécifiques au secteur d'activité, tels que la gestion des litiges pour Retail Banking.
**Mobile et hors ligne**: Salesforce Industries fournit un support robuste spécifique au domaine pour l'application mobile Salesforce et l'application mobile Field Service. Pour les domaines hautement spécialisés qui nécessitent un support hors ligne avancé, Industries fournit des applications mobiles sur mesure élaborées à partir de kits de développement Salesforce Mobile.
**Capacités commerciales communes**: Salesforce Industries s'appuie sur une base de capacités métiers communes, permettant cohérence et productivité tout en adaptant les solutions aux besoins uniques du secteur, par exemple différents systèmes de prise de rendez-vous pour les banques et les hôpitaux. Intégré à l'écosystème élargi de Salesforce, Salesforce offre une vue Customer 360 globale, ce qui en fait un élément essentiel de la suite de produits Salesforce.
## 14\. Analytics
Depuis des années, le marché des plates-formes Analytics et Business Intelligence (BI) promeut le libre-service visuel et les connaissances automatisées pilotées par l’IA pour les utilisateurs finaux afin de les aider à prendre des décisions plus rapides et plus pilotées par les données. Cependant, nous savons que tout le monde n'a pas vu cela se concrétiser en raison de plusieurs défis :
- **Connaissances déconnectées**: Les connaissances ne sont pas intégrées dans les workflows des utilisateurs, ce qui rend difficile l'action sur les connaissances, malgré leur potentiel d'information dans la prise de décision.
- **Surcharge de données et silos**: Les données continuent de croître rapidement et restent compartimentées, ce qui entraîne des risques de désorganisation et de sécurité. Les organisations sont confrontées à un dilemme entre un environnement de données en libre-service chaotique et un environnement de données restrictif et bien régi.
- **Défiance envers les données**: L'expansion et la fragmentation des données ont érodé la Trust des utilisateurs dans les connaissances dérivées des données de l'entreprise.
- **Manque de composabilité**: Il y a une absence significative de composition et de réutilisation dans les processus de travail, ce qui oblige les utilisateurs à répéter les tâches et sans possibilité claire de monétisation.
Tableau Next est conçu pour élargir le cycle des analytiques visuelles en réunissant les utilisateurs professionnels et les professionnels des données de nouvelles façons collaboratives, le tout augmenté avec l'IA. Il fournit des métriques et des connaissances fiables et opportunes via Salesforce Platform, ce qui facilite l'accès omniprésent à des connaissances actionnables.
Tableau Next relève les défis suivants :
- Création d'une plate-forme ouverte, composable et API-first pour les expériences connectées, de la connexion aux données à l'action. Fournir des outils de développement, des composants composables pour des applications analytiques enrichies et des capacités de gestion de leur emballage et de leur distribution.
- Construire avec l'IA au cœur, et capable de fournir des connaissances contextuelles et pertinentes, avec des outils permettant aux professionnels des données de réviser et valider efficacement pour garantir Trust.
- S'appuyant sur Tableau Semantics en tant que couche sémantique universelle pour une analyse de données rapide, en libre-service et régie dans un écosystème contrôlé mais flexible.
- Offrant des capacités de données en temps réel à l'échelle du cloud via Data 360 pour un accès aux données fiable, évolutif et régi.
- Offrir un environnement et une place de marché riches permettant aux développeurs de créer et de monétiser des applications.
- Intégrer l’intelligence au cœur de la stratégie, apporter la puissance de la sémantique et de la Knowledge de votre organisation aux agents qui vous habilitent.
- Prioriser Trust, pour avoir confiance dans vos données, analytiques, et charges de travail et déploiement des agents, grâce à un contrôle direct et une visibilité sur leurs activités et leur efficacité.
- Tirer parti de la collaboration en tant que principe de conception de premier ordre, avec des intégrations profondes et riches à Slack, ainsi qu'à tout autre outil collaboratif pour votre organisation.
### 14.1 Expériences Analytics hors pair
Tableau Next s'appuie sur le leadership de Tableau dans les outils d'analyse des données en offrant une plate-forme ouverte qui améliore les capacités et intègre les expériences. Les principales fonctionnalités comprennent :
- **Visualisation de données enrichies**: Utilise la technologie VizQL de Tableau pour des analyses visuelles étendues.
- **Espaces de travail collaboratifs et régis**: Offre une interface unifiée pour les tâches d'analyse, s'intègre à Slack pour la collaboration en temps réel.
- **Données approuvées et régies**: Prend en charge l'analyse en libre-service avec des parcours de promotion structurés pour une gestion globale dans un environnement sécurisé.
- **Rédaction de métrique avancée**: Permet aux analystes de créer et de réutiliser efficacement des indicateurs de performance clés dans l'ensemble de votre organisation, ce qui facilite la cohérence et la fiabilité.
### 14.2 Agentic Analytics
Tableau Next est fondamentalement construit avec Agentforce en tant que construction architecturale de base, ce qui améliore la capacité de Tableau Next à fournir des outils de données hautement connectés, de confiance et pilotés par l'IA collaborative.
- **Outils: BI** Améliore l'efficacité de l'analyse en libre-service pour les agents de données, en se concentrant sur la préparation des données et la conservation des métadonnées visuelles et sémantiques.
- **Expériences contextuelles**: Met en évidence les connaissances des données, les expériences et l'IA transparente dans le contexte où la plupart des organisations travaillent (par exemple Slack).
- **Agentforce Architecture**: Élaboré sur la pile Agentforce, offrant à Tableau Next un contexte enrichi sur une architecture agentique avancée.
- **Catalogue sémantique**: Offre un système centralisé de gestion des métadonnées, du lignage et de la recherche, qui permet de partager des expériences entre les utilisateurs de Tableau Next.
- **Métadonnées partagées et générées**: Facilite les workflows transparents entre les analytiques en libre-service et les contenus régis dans un écosystème complet.
- **Cadre d'action**: Prend connaissance de l'action à travers des workflows pré-empaquetés, organisés par l'humain ou générés.
- **Connaissances personnalisées**. Apprend vos préférences en données, votre rôle et bien plus encore (dans la mesure où vous le permettez), pour vous fournir immédiatement des connaissances hautement contextuelles et personnalisées sur les données.
- **Connaissances proactives**. Explorez intelligemment votre écosystème de données, à la recherche d'endroits d'intérêt statistique pour vous, tout en comprenant proactivement les facteurs du changement, les mesures à prendre, et recommandez les actions à prendre comme étapes suivantes.
- **Agents de données** de confiance. Redonne le pouvoir, en tant que pilote de vos agents de données, d'élaborer et d'ajuster l'application à travers des expériences intégrées. Il fournit également des outils de test pour pré-évaluer vos modifications des données et leur impact sur la précision et l'efficacité de vos agents.
### 14.3 Expériences utilisateur professionnelles pilotées par les solutions intégrées
Tableau Next améliore l'expérience des utilisateurs professionnels sur diverses plates-formes telles que Slack et Salesforce, et grâce à de nouvelles fonctionnalités d'analyse telles que Tableau Pulse, le tout accessible via des expériences agentiques afin de simplifier l'engagement avec les analytiques. Les principaux aspects comprennent :
- **Collaboration**: Élément central des analytiques de confiance, il facilite l'interaction entre les différents composants analytiques et intègre des outils de validation dans le workflow des utilisateurs.
- **Métriques d'impulsion**: Fournit des connaissances organisées et automatisées plus efficacement que les tableaux de bord traditionnels créés par des analystes.
- **Expériences pilotées par l’IA**: Utilise l’IA pour réduire le besoin d’expertise technique en analytiques avancées, ce qui contribue à garantir la fiabilité avec des métadonnées déterministes et des données régies.
- **Recherche de connaissances multijoueur**: Permettre aux utilisateurs professionnels de travailler en collaboration avec les analystes pour acquérir Knowledge et Trust dans les connaissances que le système livre.
- **Intégration profonde**: Élaboré sur une plate-forme de métadonnées et de données partagée, offrant une composabilité à travers différents systèmes et expériences afin de permettre la composition pour la promotion, le flux de données et pour différentes personnes qui s'entraident pour réviser et réaliser le travail.
### 14.4 Sémantique de Tableau
La couche sémantique Tableau sert de pont crucial entre les données brutes et l'interprétation des utilisateurs, en simplifiant l'analyse des données, la prise de décision et le développement d'applications, et en améliorant le contexte et la récupération pilotés par l'IA. Les principales fonctionnalités comprennent :
- **Gestion intégrée des métadonnées**: Prend en charge le libre-service et les métadonnées régies, ce qui facilite l'analyse ad hoc avec des parcours structurés pour devenir la source unique de vérité de l'organisation.
- **Capacités de pointe de Tableau**: Incluant la prise en charge d'objets multi-logiques, la composition du modèle, les dimensions partagées, la hiérarchie géospatiale complexe et la modélisation temporelle.
- **Données et analytiques diverses**: Aide à lier des données non structurées et structurées, par exemple à corréler des catégories de produits basées sur l'image avec des données commerciales structurées, et à incorporer l'analyse du sentiment des examens de produits semi-structurés.
- **Intégration Salesforce Platform**: Établit une source de vérité unifiée, facilitant une sémantique métier cohérente et une intégration transparente entre les applications, et un modèle de métadonnées cohérent qui prend en charge diverses expériences utilisateur et cas d'utilisation.
- **Intelligence agentique**: La couche sémantique est l'un des domaines clés dans lesquels les agents gagnent en intelligence en comprenant non seulement les données et les métadonnées qui alimentent votre activité, mais aussi la sémantique qui la définit, notamment des descriptions et des préférences plus approfondies adaptées à votre organisation.
### 14.5 Workflows intégrés et connaissances actionnables
Tableau Next offre des solutions intégrées qui améliorent la prise de décision pilotée par les données et l'automatisation de confiance, avec des actions simples, des flux prédéfinis, la planification et des intégrations d'API. Les composants clés comprennent :
- **Actions commerciales intelligentes et normalisées**: Facilite les communications urgentes et spécifiques au contexte au sein des entreprises, qui sont essentielles mais complexes.
- **Planifications de flux prédéfinies et générées**: Active les actions ponctuelles et planifiées à travers des flux statiques et générés dynamiquement, fiables mais vérifiables.
- **Agentforce**: Prend en charge les conversations et les interactions de données pilotées par l'IA, ce qui permet aux utilisateurs d'interagir avec des connaissances et d'exécuter des actions similaires à celles d'une interface utilisateur traditionnelle, à la fois dans et hors de leurs applications métiers, et simplifiées par la conversation.
### 14.6 Composable Developer Platform
Tableau Next offre une plate-forme de développement composable avec des options sans code, à faible code et pro-code pour le développement d'applications, le tout en utilisant Tableau Semantics sur Data 360. Les principales offres comprennent :
- **Applications Industry/Intelligentes pré-empaquetées**: Fournit des applications analytiques basées sur un modèle et personnalisables adaptées aux besoins spécifiques du secteur.
- **Applications tierces et ISV**: Prend en charge la création d'applications dynamiques et interactives à des fins analytiques, spécifiques au secteur d'activité et personnalisées.
- **Market and Exchange**: Permet aux éditeurs de logiciels et aux développeurs d'empaqueter et de distribuer leurs applications dans l'écosystème de développement d'applications métiers le plus vaste et le plus fiable.
### 14.7 Une collaboration profonde
Tableau Next est conçu pour les utilisateurs professionnels et les professionnels des données, favorisant une approche collaborative de la compréhension des données. Qu'ils soient techniques ou non techniques, tous les membres de l'équipe, des utilisateurs professionnels aux experts en données, peuvent examiner les connaissances des données des autres membres. De plus, ces connaissances ne se limitent pas à un onglet de navigateur dans une plate-forme BI.
En tant que plate-forme BI, Tableau Next est :
- **Composable entre plates-formes**. Les connaissances sont restituées de la même façon, quelle que soit la plate-forme sur laquelle vous les visualisez. Cette cohérence est un principe de conception de pilier lors de l'utilisation visuelle des données.
- **Profondément intégré à Slack**. Le développement de l'intégration avec Slack a assuré l'une des expériences de données collaboratives les plus intuitives et immersives sur le marché aujourd'hui.
- **Ouvert pour tout outil**. L'application de notre principe API-first, sur notre plate-forme profondément unifiée, garantit que l'intégration peut s'étendre à d'autres outils de collaboration et tiers, tout en conservant la richesse.
## 15\. Intégration
Bien que Salesforce Platform offre une suite complète de capacités d'intégration pour répondre à un large éventail de défis numériques, de nombreux clients fonctionnent dans des architectures d'entreprise qui se sont développées au fil du temps en utilisant divers fournisseurs et technologies.
Les entreprises modernes sont confrontées à des défis en matière d'intégration de systèmes et d'automatisation des processus métiers, ce qui entraîne souvent des silos de données et des inefficacités. Salesforce Integration Platform, exploitant la puissance de MuleSoft, s'attaque à ces problèmes en facilitant le développement rapide et l'amélioration des processus automatisés. Il garantit une connectivité système transparente, améliore le flux d'informations et prend en charge la prise de décision sur différentes plates-formes, réduisant ainsi les coûts de main-d'œuvre et les dépenses d'automatisation. Cette couche est cruciale pour créer, gérer, gouverner et surveiller les intégrations entre les services Salesforce et d'autres services personnalisés ou tiers.
Les systèmes sont définis via des API, qui servent à :
- Accédez aux données de systèmes essentiels tels que le système ERP, les systèmes de facturation et les bases de données propriétaires.
- Facilitez l'interaction et l'intégration des données, en aidant à éliminer les silos de données.
- Ajoutez un contexte métier aux données et aux processus gérés par les API System et Process.
Pour une communication efficace, les API sont décrites en utilisant :
- Spécification OpenAPI (OAS) pour des échanges synchrones immédiats
- AsyncAPI pour les communications asynchrones pilotées par l'événement
- Model Context Protocol (MCP) pour des interactions structurées modèle-contexte
- Protocole A2A (agent à agent) pour les intégrations directes agent à agent.
La couche d'intégration Salesforce offre des capacités robustes pour intégrer et gérer n'importe quel système, ce qui améliore la connectivité avec les données, l'intelligence artificielle et les fonctionnalités de l'application Salesforce, que les systèmes soient natifs de Salesforce ou d'autres fournisseurs.
Les intégrations complexes nécessitent des transformations avancées et nécessitent des outils robustes, notamment la connectivité universelle, la gestion et la gouvernance des API, un environnement de développement intégré (IDE) pour élaborer des charges de travail d'intégration, une plate-forme d'exécution pour déployer, gérer et superviser ces intégrations, et une plate-forme d'observabilité pour fournir une visibilité complète sur ces intégrations.
Pour accélérer le processus d'intégration, nous offrons des accélérateurs et des modèles spécifiques au secteur d'activité qui encodent les modèles et les besoins d'intégration courants.
### 15.1 Schémas d'intégration à Salesforce
Deux principaux modèles d'intégration traitent du flux de données et de processus entre Salesforce et l'écosystème au sens large : l'intégration sortante et l'intégration entrante.
**Connexion de Salesforce à des systèmes externes (sortant) :** Ce schéma implique des processus provenant de Salesforce qui accèdent à des données ou déclenchent des actions dans des systèmes externes.
- **Gestion des points de terminaison sécurisés (identifiants nommés) :** Les identifiants nommés fournissent un emplacement centralisé et sécurisé pour stocker les détails des points de terminaison et d'authentification. Les applications et les automatisations référencent un nom logique, tandis que la plate-forme gère les complexités du cycle de vie de l'authentification.
- **Intégration déclarative (Services externes) :** Pour les systèmes externes qui offrent une spécification OpenAPI standard, un administrateur peut utiliser les Services externes pour enregistrer l'API par déclaration. La plate-forme traite ensuite la spécification, ce qui rend les opérations du service automatiquement disponibles en tant qu'actions natives dans des outils tels que Flux ou en tant qu'objets natifs dans Apex.
- **Intégration système complexe (MuleSoft)**: Pour les systèmes sans interface moderne, MuleSoft crée une couche d'API standard réutilisable. Cela élimine la complexité héritée et intègre des données et des processus sur site dans l'écosystème Salesforce.
- **Accès aux données en temps réel (objets externes) :** Représente les tableaux de systèmes externes en tant qu'objets virtuels dans le modèle de données Salesforce, ce qui rend les données externes accessibles via des requêtes standard et des composants d'interface utilisateur sans réplication.
- **Central Capability Management (catalogue d'API unifiée) :** Le catalogue d'API unifié est un référentiel centralisé et la source de preuve unique de toutes les spécifications d'API et de leurs métadonnées associées, notamment leur localisation et leurs protocoles de sécurité. Il garantit que, quel que soit l'emplacement où réside un élément de données ou une logique métier, il peut être découvert, connecté en toute sécurité et composé dans de nouvelles applications et automatisations puissantes à travers l'écosystème Salesforce.
- **Logique pro-code personnalisée (Apex REST):** Les développeurs peuvent exposer une logique métier personnalisée écrite en Apex sous forme d'API REST et d'action. L'action est ensuite disponible en tant qu'étape dans un flux ou outil pour un agent IA.
**Connexion de systèmes externes à Salesforce (entrant) :** Ce schéma permet aux systèmes et applications externes de se connecter à Salesforce Platform pour accéder aux données, déclencher une logique métier et orchestrer des processus. Cette capacité repose sur une base d'API éprouvées de niveau entreprise qui fonctionnent à grande échelle. Depuis octobre 2025 :
- L'API SOQL (Query API) gère plus de 50 milliards de requêtes par jour.
- L'API REST sert près de 5 milliards d'appels par jour à partir de systèmes externes, avec une utilisation croissante de 30 % d'une année à l'autre.
- L'API de transfert en masse traite quotidiennement des centaines de milliards d'enregistrements pour des opérations de données à grande échelle.
Cette fiabilité et cette évolutivité éprouvées sous-tendent les capacités suivantes :
- **Une expérience d'API unifiée :** L'accès à toutes les capacités de Salesforce est unifié via une structure de point de terminaison cohérente (api.salesforce.com), ce qui élimine la nécessité pour les développeurs d'apprendre différents modèles ou flux d'authentification pour chaque produit.
- **Un portefeuille d'API complet et spécialement conçu :** La plate-forme fournit une collection diversifiée d'API adaptées à des besoins spécifiques, notamment les API REST et SOAP pour les opérations transactionnelles, l'API de traitement en masse des données volumineuses, l'API Pub/Sub pour les applications pilotées par l'événement, et des API Apex spécialisées produit ou personnalisées.
- **Préparation future à l'intégration agentique :** Grâce à des normes telles que MCP, les clients peuvent exposer en toute sécurité leurs données et actions Salesforce en tant qu'« outils » pour les agents IA externes, transformant une instance Salesforce en un ensemble extensible de compétences pour une force de travail numérique.
### 15.2 Intégration agentique avec MCP
Au-delà des schémas entrants et sortants établis pour l'intégration des données et des processus, un nouveau schéma se dessine pour l'ère des agents. Salesforce Platform met en œuvre une stratégie MCP complète, la positionnant à la fois en tant que consommateur et fournisseur de services pilotés par l’IA. Cette approche bidirectionnelle permet l'interopérabilité des agents, permettant aux entreprises d'intégrer de façon transparente les données et les capacités Salesforce à l'écosystème en évolution des agents et des outils IA tout en préservant la sécurité et la gouvernance au niveau de l'entreprise.
**Salesforce en tant que client MCP :** Les agents peuvent agir en tant que client MCP en exploitant intelligemment et dynamiquement des systèmes et des API externes. Cette capacité permet aux organisations d'étendre la portée d'Agentforce au-delà des frontières de Salesforce, en orchestrant des actions à travers n'importe quel système, qu'il soit doté d'une API moderne ou qu'il nécessite une connexion via MuleSoft à des systèmes hérités ou à des robots RPA. La configuration est gérée par une expérience de configuration déclarative familière basée sur une rubrique, qui permet une intégration rapide sans développement personnalisé. Un mécanisme de découverte simplifié pour les serveurs MCP fournis par des partenaires rationalise davantage l'intégration des capacités externes. En éliminant les complexités de la connectivité externe à travers une pile à grande échelle, les entreprises peuvent intégrer rapidement Agentforce à leur paysage technologique plus large.
**Salesforce en tant que serveur MCP :** En tant que serveur MCP, la plate-forme expose sa logique et ses actifs, y compris les API REST standard, les points de terminaison personnalisés, les actions invocables et les flux, en tant qu'« outils » à découvrir pour les agents externes. Grâce à une interface déclarative, les clients et les éditeurs de logiciels peuvent créer et configurer leurs propres serveurs MCP personnalisés, en organisant les capacités dans des collections d'outils adaptés à des processus métiers uniques. Cela s'étend aux invites MCP, créant des synergies naturelles avec les capacités de Modèle d'invite de la plate-forme et permettant aux organisations de rendre leur investissement dans l'ingénierie rapide accessible à n'importe quel système IA externe.
Cette capacité est régie par un modèle de sécurité à plusieurs niveaux :
- **Contrôle de l'application :** La construction External Client App permet aux administrateurs de contrôler efficacement les applications des agents externes qui peuvent accéder à leur organisation Salesforce.
- **Autorisations étendues :** L'authentification est augmentée par une portée OAuth précise, qui permet de suivre et d'appliquer avec précision les actions qu'un agent authentifié est autorisé à exécuter.
- **Autorisation de plate-forme principale :** Ces nouveaux contrôles s'ajoutent au modèle d'autorisation robuste de Salesforce, notamment les contrôles d'accès aux enregistrements, les autorisations au niveau de l'entité et du champ, et d'autres autorisations définies dans Profils et ensembles d'autorisations.
Les éditeurs de logiciels et les partenaires peuvent également empaqueter et distribuer des configurations de serveur MCP, ce qui permet de déployer rapidement des intégrations prêtes pour l’IA dans l’écosystème Salesforce.
### 15.3 Connectivité universelle
L'approche moderne de Salesforce en matière de connectivité universelle est _interprétée connectivité_, une approche centrée sur les métadonnées pour développer des connecteurs qui peuvent être exécutés sur n'importe quelle plate-forme (MuleSoft, Flow ou Data 360) pour n'importe quel cas d'utilisation sans programmation. Les modèles de métadonnées comprennent comment se connecter à des services distants pour authentifier une requête, modéliser les données renvoyées, créer des requêtes, parcourir les résultats et recevoir des événements (déclencheurs) pour automatiser un processus.
Pour les systèmes qui n'utilisent pas d'API basées sur HTTP, Salesforce offre des centaines de connecteurs prédéfinis et un kit de développement complet pour élaborer des connecteurs personnalisés. Pour les systèmes sans accès API, Salesforce offre l'automatisation robotisée des processus (RPA) qui utilise des agents pour automatiser les tâches répétitives basées sur des règles généralement exécutées par des humains. Ces tâches peuvent inclure la saisie de données, le traitement des transactions et la réponse à de simples requêtes du service client. Pour extraire des informations à partir de documents, Salesforce offre notre traitement intelligent des documents (IDP) qui exploite l'IA pour extraire, classer et traiter automatiquement les données de divers types de documents, tels que des factures, des contrats et des formulaires. Quelles que soient les informations disponibles, Salesforce offre une méthode automatisée pour les récupérer et les manipuler.
Grâce aux récentes avancées de l’IA, Salesforce fournit des blocs de construction qui permettent d’activer rapidement les fonctionnalités des agents dans l’organisation :
- Le **connecteur Model Context Protocol (MCP)** permet aux organisations d'exposer rapidement leur API en tant qu'outils MCP, et de faciliter la découverte d'API et de ressources pour la consommation par les agents.
- Le **connecteur A2A (Agent to Agent)** permet aux organisations de standardiser la communication d'agent à agent en fournissant une prise en charge du protocole A2A aux agents. Chaque agent (un expert fonctionnel dans le domaine) peut découvrir et déléguer la requête d'un client à l'agent le plus adapté au domaine.
- Le **connecteur d'inférence** fournit des blocs de construction pour élaborer un agent à partir de zéro en fournissant l'appel LLM, les incorporations vectorielles et la recherche, la récupération RAG et la prise en charge des outils MCP.
### 15.4 Gestion des API
La Gestion des API de MuleSoft, fournie via le Gestionnaire d'API Anypoint, fournit une plate-forme complète pour concevoir, sécuriser, gouverner, surveiller et adapter les API et les microservices dans n'importe quel environnement de déploiement. Les organisations peuvent gérer leurs API et microservices avec des contrôles et des connaissances cohérents et de niveau entreprise à partir d'une fenêtre unique, quelle que soit la plate-forme, avec une gestion centralisée du déploiement à la gestion des versions. Les capacités clés comprennent :
- **Anypoint Flex Gateway** est une passerelle d'API de couche applicative qui permet de gérer et de sécuriser les API, en appliquant des stratégies de limitation de taux, de mise en cache, d'authentification, d'autorisation, de protection contre les menaces, de surveillance et de consignation au niveau HTTP/S. Il s'agit d'une passerelle légère, hautement performante, basée sur Envoy, conçue pour les environnements distribués basés sur des microservices. Elle est conçue pour s'intégrer de façon transparente aux workflows DevOps et CI/CD, tout en offrant la sécurité et la gestion d'entreprise dans n'importe quel environnement tout en prenant en charge les politiques entrantes et sortantes.
- Les **alertes d'API** permettent aux organisations de définir et de surveiller des seuils ou des conditions spécifiques pour que leurs API détectent des comportements inhabituels ou indésirables. Par exemple, des alertes lorsque le temps de réponse dépasse une limite (par exemple 60 secondes), lorsque le nombre de requêtes dans une période est trop élevé, lorsque certains codes de réponse HTTP sont renvoyés ou lorsque des infractions à la politique se produisent.
- **API Analytics** permet de déterminer comment les API sont utilisées et leurs performances. Le tableau de bord Analytics permet aux organisations de suivre et d'afficher des métriques générales, d'explorer des graphiques, de créer et de personnaliser des tableaux de bord et des rapports pour comprendre les tendances d'utilisation, les infractions aux politiques, les temps de réponse, les codes de requête/réponse, et davantage.
### 15.5 Environnement de développement de l'intégration de nouvelle génération
MuleSoft Anypoint Code Builder (ACB) est notre IDE de nouvelle génération conçu pour le développement d'API et d'intégration, avec une expérience moderne et unifiée avec VS Code en tant que back-end.
- **Environnement de développement unifié :** Consolide l'ensemble du processus de développement d'API et d'intégration en un seul outil, prenant en charge les API AsyncAPI, OAS et RAML, les jeux de règles de gouvernance, une zone de dessin de flux à faible code, des connecteurs prédéfinis et des options de test et de déploiement intégrées. De plus, ACB prend en charge le débogage, le dépannage et la maintenance continue avec des suggestions intelligentes et contextuelles.
- **Expérience de développement agentique :** Offre des expériences aux agents pendant tout le cycle de vie de développement d'applications. Au cœur de cette stratégie se trouve le serveur MCP MuleSoft, qui permet le développement de l'intégration agentique. MuleSoft MCP Server fournit des outils puissants pour générer des spécifications d'API et des intégrations à partir du langage naturel, créer des transformations de données, gérer des actifs dans MuleSoft Exchange, et administrer des applications et des stratégies d'API. Les outils MuleSoft MCP Server dynamisent la spécification d'API et le développement de l'intégration des utilisateurs dans tous les éditeurs de code IA basés sur VS Code, y compris Cursor, Windsurf, et bien d'autres.
- **Intégrations IA :** MuleSoft améliore le développement de l'intégration avec des capacités agentiques en utilisant MuleSoft Topic Center, qui convertit les appels d'API en Actions Agentforce pour l'accès au système d'entreprise. Le connecteur Agentforce intègre l'automatisation en langage naturel dans les intégrations. Le connecteur d'inférence intègre en toute sécurité des fournisseurs LLM externes, ce qui permet une logique pilotée par l'IA dans les applications MuleSoft. Les organisations peuvent utiliser ces capacités combinées pour élaborer des intégrations intelligentes et adaptatives.
### 15.6 Plate-forme d'exécution
Runtime Platform de MuleSoft fournit des options de déploiement flexibles pour l'exécution d'applications, d'API et d'intégrations MuleSoft à travers les environnements. Les organisations peuvent choisir le modèle d'exécution le plus adapté à leurs besoins opérationnels, de conformité et d'évolutivité, tout en maintenant une gestion et une gouvernance cohérentes via Anypoint Platform. Cette flexibilité permet aux applications de fonctionner à proximité des sources de données, de respecter les réglementations régionales et d'évoluer de façon transparente en fonction de la demande.
Les principales options d'hébergement comprennent :
- **Cloud :** L'intégration multilocataire Platform-as-a-Service (iPaaS) entièrement gérée de MuleSoft élimine les surcoûts de gestion de l'infrastructure. CloudHub 2.0 fournit une mise à l'échelle élastique, une disponibilité élevée et des déploiements/mises à niveau sans temps d'arrêt, avec des besoins d'observabilité intégrés et des certifications de conformité. Les développeurs peuvent se concentrer sur l'élaboration d'API et d'intégrations pendant que MuleSoft gère l'infrastructure d'exécution, ce qui garantit la sécurité, la fiabilité et la haute disponibilité au niveau de l'entreprise.
- **Hybride :** Pour les organisations qui doivent héberger elles-mêmes leurs applications pour plus de contrôle, MuleSoft offre Runtime Fabric, un service conteneur qui automatise le déploiement et l'orchestration des exécutions MuleSoft à travers Kubernetes ou des machines virtuelles. Il prend en charge l'évolutivité horizontale, les déploiements sans temps d'arrêt, les contrôles de sécurité intégrés et la gestion simplifiée des clusters.
- **Private Cloud Edition (PCE) :** L'édition Private Cloud de MuleSoft fournit une version entièrement autogérée et sur site d'Anypoint Platform (y compris Plans de contrôle et d'exécution), qui permet aux organisations de satisfaire à des exigences strictes en matière de réglementation, de résidence des données et de sécurité. Elle permet aux grandes entreprises de garder un contrôle total sur l'infrastructure tout en bénéficiant des capacités d'intégration unifiée et de gestion d'API d'Anypoint Platform.
### 15.7 Observabilité
MuleSoft offre des solutions d'observabilité complètes qui offrent une visibilité complète sur les API, les intégrations et les applications dans n'importe quel modèle de déploiement. Les capacités d'observabilité sont cohérentes quel que soit l'emplacement d'exécution des charges de travail, offrant une vue unifiée des environnements. En capturant des données de télémétrie historiques et en temps réel, MuleSoft permet aux organisations de détecter, d'analyser et de résoudre plus rapidement les problèmes de production sur l'ensemble du réseau d'applications. Les données d'observabilité peuvent être visualisées en natif sur Anypoint Platform ou exportées via OpenTelemetry dans la gestion des approvisionnements préférée d'un client, ce qui permet une intégration transparente aux écosystèmes de surveillance existants. Cela permet aux organisations de renforcer proactivement la résilience de l'infrastructure et d'améliorer la fiabilité des applications critiques.
MuleSoft offre une observabilité à travers deux offres principales :
- **Anypoint Monitoring** est la solution d'observabilité actuelle sur le marché intégrée à Anypoint Platform. Il offre des tableaux de bord prêts à l'emploi et personnalisables pour surveiller l'intégrité de l'application, la recherche avancée de journaux pour la gestion des journaux et des capacités d'alerte qui notifient les équipes lorsque des seuils définis ou des anomalies se produisent.
- **Integration Intelligence** est la plate-forme d'observabilité de nouvelle génération, première IA pour MuleSoft, repensée et élaborée en natif sur Salesforce Platform. Cette offre utilise Data 360 en tant que couche de données unifiée pour les données télémétriques, Tableau Semantics en tant que couche sémantique de confiance pour permettre des connaissances intelligentes et actionnables, Tableau Concierge pour réaliser un dépannage assisté par l'IA et Tableau Next Dashboards pour offrir des interfaces visuelles interactives qui regroupent plusieurs visualisations de données enrichies dans une vue unique et cohérente. Tableau Next offre également aux clients la possibilité d'élaborer des tableaux de bord personnalisés au-dessus du modèle de données sémantique fourni avec des fonctionnalités d'observabilité.
Cette pile pilote également le traçage centré sur l'agent qui offre aux clients une transparence totale sur le parcours d'invocation agentique non déterministe de bout en bout, leur permettant d'observer l'agent qui travaille à chaque étape intermédiaire, ce qui permet aux utilisateurs d'accéder plus rapidement à la cause première des échecs et d'identifier les éventuels blocages de performance.
## 16\. Ecosystem et AppExchange
L'écosystème Salesforce illustre la puissance de la plate-forme. Les intégrateurs système (SI) et les partenaires consultants assistent les clients en développant, configurant et optimisant des solutions Salesforce complexes. Les éditeurs de logiciels indépendants élaborent des applications et des solutions innovantes sur la plate-forme, que les clients peuvent ensuite installer dans leur organisation Salesforce. Ces applications ISV sont disponibles sur AppExchange, la boutique d'applications de Salesforce lancée en 2006, qui propose désormais plus de 10 000 applications avec plus de 14,3 millions d'installations en octobre 2025.
Pour aider les clients à parcourir la vaste place de marché et à découvrir des applications pertinentes, l'expérience de recherche AppExchange a été repensée en 2025 afin d'exploiter Data 360. Les capacités de recherche vectorielle de Salesforce Data 360 fonctionnent de concert avec la correspondance par mot-clé traditionnelle pour fournir des résultats plus pertinents sur le plan sémantique en comprenant l'intention d'un utilisateur en langage naturel. La vision ultime est de faire évoluer cette fondation en l'intégrant à la plate-forme Agentforce, permettant une interface entièrement agentique, « demander n'importe quoi » où les clients peuvent décrire de façon conversationnelle leurs défis métiers pour recevoir des recommandations de solutions hautement personnalisées.
AppExchange garantit des solutions de haute qualité grâce à un processus d'examen rigoureux impliquant des analyseurs de code, des scanners de sécurité et des guides d'implémentation de référence, le tout en étroite collaboration avec Salesforce. Cette plate-forme fournit également aux éditeurs de logiciels des outils de gestion des licences pour adapter les licences et la monétisation des applications, en prenant en charge divers modèles de tarification, notamment les options basées sur l'utilisateur et basées sur la consommation.
Les principes de la « plate-forme pilotée par les métadonnées » permettent aux éditeurs de logiciels d'étendre les applications natives et les métadonnées de Salesforce, ce qui facilite le développement de modèles de données, de logique métier et d'interfaces utilisateur. Salesforce Platform prend en charge un large éventail de solutions, depuis les applications spécifiques au secteur d'activité jusqu'aux applications de marque hautement personnalisées qui utilisent des technologies telles que Lightning Web Components pour l'interface utilisateur et Apex Code pour la logique métier.
Le concept de « package » est crucial pour la distribution de ces applications dans diverses organisations Salesforce. L'empaquetage implique la sérialisation des métadonnées dans un artefact qui peut être installé par n'importe quel client Salesforce, en utilisant des technologies sous-jacentes conçues pour la gestion des métadonnées dans divers environnements. Un aspect unique de l'emballage est qu'il permet des installations dans des environnements inconnus du développeur.
Pour renforcer le contrôle et la sécurité, les fonctionnalités de « maniabilité » dans l'emballage permettent aux éditeurs de logiciels de mettre à niveau en toute sécurité des pièces d'une application, car d'autres ne peuvent pas dépendre de ces pièces, tout en permettant aux clients de posséder et de gérer d'autres pièces. Par exemple, les éditeurs de logiciels peuvent définir certaines métadonnées, notamment des paramètres personnalisés, sur « géré », ce qui les rend invisibles et non modifiables par le client, évitant ainsi toute interruption dans son environnement. Les packages gérés incluent ces contrôles de gestion, alors que les packages non gérés traitent les métadonnées déployées comme créées par le client, qui ne peuvent pas être mises à niveau après le déploiement.
Depuis la création d'AppExchange et de Salesforce Platform, le nombre et la complexité des packages créés et installés ont considérablement augmenté. En réponse à ces demandes, la plate-forme a introduit l’architecture d’empaquetage de deuxième génération en 2020. Cette nouvelle architecture améliore la modularité des packages gérés, améliore la flexibilité de gestion des versions, permet le partage d'espace de noms et prend en charge les dépendances déclaratives, entre autres avancées dans le cycle de vie du développement logiciel. L'architecture de déploiement du package a également bénéficié de plusieurs améliorations importantes pour plus d'efficacité et d'échelle, notamment la détermination des métadonnées modifiées et le déploiement des deltas seulement.
Une mesure essentielle pour le développement de nouveaux produits et fonctionnalités est leur compatibilité avec l'emballage et leur préparation à l'utilisation d'éditeurs de logiciels. La plate-forme met l'accent sur la disponibilité rapide de ses capacités pour les partenaires, ce qui permet à l'écosystème Salesforce de tirer parti du potentiel innovant de Salesforce Platform efficacement et au-delà des offres prêtes à l'emploi de Salesforce. Il s'agit toutefois d'un domaine d'investissement continu qui permet de s'assurer que toutes les capacités décrites dans ce document qui sont disponibles pour les développeurs internes Salesforce le sont également pour nos développeurs ISV.
De plus, Heroku Marketplace et Slack Marketplace offrent une large gamme d'intégrations tierces et de compléments qui peuvent améliorer les fonctionnalités des applications Salesforce. Heroku Marketplace fournit des outils et des services pour des fonctionnalités d'application supplémentaires, et améliore la conception, le déploiement et la gestion d'applications par les développeurs. Slack Marketplace offre des intégrations qui peuvent rationaliser les workflows et améliorer la collaboration dans les environnements Salesforce.
## 17\. Salesforce dans Salesforce
Dans l'esprit de notre valeur fondamentale, Customer Success, Salesforce agit en tant que « Customer Zero » pour toutes les applications et tous les services sur Salesforce Platform, en tirant parti des produits accessibles aux clients en interne dans la mesure du possible. Cela offre des avantages importants:
- **Tests de produits rigoureux**: En utilisant la suite de produits quotidiennement, les employés de Salesforce exposent la plate-forme à des défis réels, en améliorant la qualité des produits et en identifiant les zones d'amélioration.
- **Produits raffinés**: Les commentaires immédiats de l'utilisation interne permettent d'affiner rapidement les fonctionnalités et la convivialité, ainsi que d'identifier et de résoudre rapidement les bogues, ce qui donne des produits qui répondent mieux aux besoins des clients dès leur publication.
- **Expertise approfondie du secteur**: L'utilisation interne à travers diverses fonctions fournit à Salesforce des connaissances précieuses sur des défis produits et industriels spécifiques, en particulier dans les secteurs de haute technologie.
- **Amélioration de l'empathie des clients**: L'expérience directe avec la plate-forme permet aux employés de mieux comprendre et de résoudre les problèmes des clients.
- **Connaissances marketing et commerciales**: L'utilisation quotidienne des produits informe les stratégies commerciales et marketing, ce qui aide à adapter la plate-forme aux besoins des clients.
- **Stratégie de commercialisation renforcée**: Une implémentation interne réussie permet à Salesforce de commercialiser en toute confiance la suite en tant que solution éprouvée.
De plus, toutes les mises à jour logicielles destinées à la production sont initialement déployées dans une instance Hyperforce dédiée " Salesforce on Salesforce " dans le cadre d'un processus de déploiement échelonné. Depuis août 2020, cette instance héberge avec succès GUS, l'organisation de Salesforce pour les équipes d'ingénieurs, ainsi que les opérations CRM de Salesforce, montrant la robustesse et la préparation d'Hyperforce pour n'importe quel client. Cette stratégie permet aux équipes internes de tester et d'exposer les problèmes bien avant les déploiements en production pour des clients externes.
L'organisation Salesforce Technology a pleinement adopté Agentforce comme plate-forme interne pour augmenter la productivité et la qualité à travers le SDLC. Cela nous a permis non seulement d'améliorer la qualité du code que nous expédions à nos clients en détectant et en atténuant les bogues à l'avance, mais aussi d'itérer rapidement sur les expériences des agents en fonction des commentaires internes de première main.
## 18\. Transformation à grande échelle
Depuis sa création en 1999, Salesforce a connu de multiples transformations technologiques. Cependant, la transformation impliquant Salesforce Platform a été particulièrement importante en raison de son ampleur et du rythme rapide de mise en œuvre des changements. Cette transformation nécessitait une évolution simultanée de tous les composants architecturaux majeurs pour parvenir à une plate-forme intégrée. Pour s'assurer que cette transformation était itérative et perturbait le moins possible les parties prenantes et les pionniers, l'organisation Salesforce Technology a également dû faire évoluer ses pratiques d'ingénierie et de livraison de produits.
L'organisation Salesforce Technology est une grande équipe diversifiée, comprenant plus de 2500 équipes réparties dans plus de 20 sites à travers 14 pays différents. Ce groupe opère à grande échelle, livrant plus de 200 versions de produits et mettant en œuvre 250 000 modifications système chaque semaine. Conformément à l’éthique plus large de l’entreprise, le groupe Technology est guidé par cinq valeurs fondamentales : Trust, Customer Success, Innovation, Égalité et Durabilité. Ces valeurs sont essentielles pour façonner la stratégie du groupe, guider son exécution et influencer les décisions quotidiennes.
Adhérant à nos valeurs fondamentales, l'infrastructure Salesforce Engineering 360 fournit aux équipes d'ingénieurs des tableaux de bord orientés vers l'action et des connaissances complètes sur leurs opérations, établissant des attentes claires en matière de normes et de meilleures pratiques au sein de l'organisation. Cette vue globale englobe divers domaines critiques, notamment la disponibilité, la sécurité, la conformité, la qualité, l'accessibilité, Developer Productivity, le développement de produits agiles et la rentabilité. Pour fournir ces connaissances, l'infrastructure traite des milliards d'enregistrements à partir de centaines de systèmes d'ingénierie internes, tels que des systèmes de sécurité, des journaux d'intégrité de production, des référentiels de code, des environnements de développement, CI/CD, et des systèmes de planification et de suivi des versions/travaux, le tout élaboré sur Salesforce Platform en utilisant les dernières innovations d'Agentforce, Data 360, Tableau et Slack.
Ancrée dans ces données et d'autres, l'organisation Salesforce Technology exploite l'IA et les technologies agentiques pour accélérer la productivité. Nous avons plus de 10 000 utilisateurs actifs par jour d’outils IA internes et nous avons élaboré plus de 100 agents IA qui font partie de notre programme AgentExchange interne, ce qui favorise l’amélioration de la productivité dans l’ensemble de l’organisation.
Grâce à notre valeur Trust, la propriété du service est profondément ancrée dans notre culture d'ingénierie. Chaque service et produit est conçu pour non seulement atteindre, mais dépasser leurs objectifs de niveau de service (SLO) liés aux métriques de disponibilité et de gestion des incidents telles que Time To Detect (TTD) et Time To Restore (TTR). Notre approche de la gestion du changement, de la préparation aux versions et de la gestion des problèmes respecte des normes élevées. La sécurité est intégrée à chaque phase de notre cycle de vie de développement sécurisé, en adhérant au principe de sécurité par défaut. La qualité et les performances sont prioritaires grâce à la Méthodologie de test agile, qui comprend des millions de tests automatisés, à travers les tests unitaires, fonctionnels, d'intégration et de charge/échelle dans nos pipelines CI/CD.
Sur le plan architectural, nous nous concentrons sur le développement de capacités partagées pour accroître l'effet de levier et l'efficacité, et ainsi améliorer la qualité. Par exemple, nous avons développé des services gérés dans Hyperforce pour répondre à divers besoins tels que le calcul et la gestion des données, permettant aux équipes produit de se concentrer sur l'innovation produit tandis que les équipes centrales améliorent ces services en termes de sécurité, de disponibilité et de rentabilité.
Nos opérations sont agiles et favorisent la livraison d’innovations aux clients. Chacune des plus de 3000 équipes dispose de l'autonomie nécessaire pour implémenter l'infrastructure agile, en utilisant Scrum ou Kanban. La planification du développement de produits dans l'ensemble de l'organisation est structurée avec divers calendriers, y compris un plan à long terme de 3 ans pour l'orientation stratégique, suivi de plans d'exécution annuels, puis divisé en plans de publication de produits sur 4 mois, qui informent les plans de sprint bihebdomadaires. Les produits, les fonctionnalités et les correctifs de bogues sont déployés via plusieurs véhicules de version pour répondre aux divers besoins des clients, notamment trois versions annuelles majeures, des versions bihebdomadaires et des versions quotidiennes.
La productivité est d'une importance cruciale compte tenu de notre échelle. Nous utilisons l'infrastructure SPACE pour mesurer efficacement la productivité, soutenue par un ensemble complet de métriques fournies par le système Engineering 360. Nous nous concentrons également sur l'amélioration des outils et des expériences pour nos développeurs internes afin de rationaliser le cycle de vie du développement, avec des investissements dans les expériences des agents et l'IA, le workflow, les outils d'élaboration, les configurations de développement, les versions plus sûres et les services de sécurité qui rapportent des avantages significatifs.
## 19\. Conclusion
En conclusion, la plate-forme Salesforce a subi une transformation remarquable au cours des cinq dernières années, passant de la plate-forme cloud multitenant pionnière à une plate-forme approuvée, intégrée, agentique et pilotée par les données, qui pilote une suite d'applications et de services dans la région de leur choix. Cette évolution a été motivée par la nécessité de relever les défis émergents tels que la montée en puissance des fournisseurs de cloud public, l’augmentation des exigences réglementaires et les progrès de l’IA générative et de l’apprentissage machine.
L'introduction d'Hyperforce, Data 360 et Agentforce a considérablement amélioré les capacités de la plate-forme, lui assurant de rester à la pointe de l'innovation tout en maintenant Trust et fiabilité. La migration réussie de la majorité de nos clients vers cette nouvelle plate-forme souligne l'ingéniosité et le dévouement de nos ingénieurs.
Alors que nous continuons à innover et à nous adapter aux demandes changeantes du marché, Salesforce Platform est bien placée pour prendre en charge la prochaine génération d'applications et de cas d'utilisation clients, réaffirmant ainsi notre engagement envers la réussite des clients et l'excellence technologique.
## Vue d'ensemble
L'architecture de données d'entreprise est à un point d'inflexion. Les organisations doivent simultanément prendre en charge les systèmes d’IA en temps réel, respecter des réglementations de confidentialité de plus en plus strictes et collaborer avec des partenaires externes qui ne peuvent pas partager de données brutes. Ces exigences modifient en profondeur la conception des plates-formes de données.
Les architectures traditionnelles basées sur des pipelines ETL et des entrepôts de données centralisés peinent à répondre à ces demandes. La réplication des données entre les systèmes augmente la latence, le coût et la complexité de la gouvernance. Chaque copie devient une nouvelle obligation de conformité, ce qui complique la gestion du consentement, les demandes de suppression et l'application des politiques dans les environnements distribués.
Pour relever ces défis, l'industrie s'oriente vers des modèles de collaboration sans copie et appliquant des politiques. Les salles blanches de données sont apparues comme une capacité architecturale clé, permettant à plusieurs organisations d'analyser les signaux partagés sans exposer ni transférer de données brutes. Au lieu de déplacer les données vers des environnements centralisés, le calcul est exécuté dans le domaine régi de chaque participant, et seuls les résultats protégés par la vie privée sont renvoyés.
Ce changement architectural est de plus en plus visible dans les secteurs d'activité. Par exemple, l'acquisition d'InfoSum par WPP, qui est la plus grande entreprise de marketing et de publicité, reflète l'importance croissante des salles blanches en tant qu'infrastructures pour la collaboration en matière de protection de la vie privée. Les institutions financières les utilisent pour détecter les fraudes entre les institutions, les détaillants pour coordonner les promotions avec les marques de consommateurs et les organisations de santé pour analyser les cohortes de patients entre les prestataires, sans partager de dossiers confidentiels sous-jacents.
Salesforce Data 360 opérationnalise ce modèle grâce à une architecture zéro copie bâtie sur Hyperforce. Les données restent dans leurs systèmes sources, tandis que les requêtes fédérées appliquent les politiques de confidentialité, de consentement et de résidence à l'exécution. Cette approche permet de recueillir des connaissances en temps réel, de collaborer entre les clouds et de prendre des décisions pilotées par l’IA sans élargir la surface de risque créée par la réplication des données.
Ce document examine comment les salles blanches de données fonctionnent comme un modèle architectural fondamental pour l'entreprise moderne, soutenant simultanément et à grande échelle l'innovation en IA, la conformité réglementaire et la collaboration inter-domaines sécurisée.
## Pourquoi les salles blanches comptent maintenant
Pour comprendre pourquoi les salles blanches des données sont nécessaires, les architectes d'entreprise doivent d'abord faire face à l'échec structurel des modèles d'intégration hérités. L'industrie vit une transition décisive des référentiels de données centralisés et monolithiques vers des écosystèmes décentralisés et fédérés. Ici, les données sont accédées, régies et calculées en place plutôt que physiquement déplacées. Ce poste de travail n'est pas incrémentiel. C'est une réponse directe aux pressions systémiques sur l'échelle, la confidentialité et l'agilité que les architectures traditionnelles ne peuvent plus absorber.
### Redéfinition des intégrations de données dans Modern Enterprise
Pendant des années, les entreprises se sont appuyées sur des architectures pilotées par ETL qui copiaient les données de systèmes CRM, ERP et numériques dans des entrepôts centralisés pour la génération de rapports et l'analyse. Cette approche s'est avérée efficace pour l'analyse historique, mais elle a été conçue pour un monde plus lent et orienté par lot.
À mesure que les interactions numériques s’accéléraient et que des systèmes pilotés par l’IA émergeaient, les limites de ce modèle devenaient plus évidentes. Les pipelines ETL sont intrinsèquement asynchrones, ce qui signifie que les connaissances arrivent souvent quelques heures ou quelques jours après les événements. Une telle latence est de plus en plus incompatible avec les cas d'utilisation modernes tels que la personnalisation en temps réel, la prise de décision adaptative et les systèmes d'IA qui nécessitent des données contextuelles immédiates.
La réplication introduit également une gouvernance et une complexité de sécurité croissantes. Chaque nouvelle copie de données nécessite des stratégies, une surveillance et des contrôles de conformité supplémentaires. Dans les environnements réglementés, des cadres tels que le Règlement général sur la protection des données (RGPD) exigent des organisations qu’elles gèrent les restrictions de suppression, de consentement et d’utilisation partout où les données existent, un défi opérationnel lorsque des jeux de données sont dupliqués entre plusieurs systèmes.
À l'échelle, cette duplication aggrave les coûts et les frais généraux opérationnels. Les organisations paient à répétition pour l'ingestion, le stockage, la sécurité et le traitement sur plusieurs plates-formes, alors que la valeur marginale des copies supplémentaires diminue.
Par conséquent, les architectures de données modernes évoluent vers des modèles qui réduisent les mouvements de données et appliquent la gouvernance directement à la source. L'intégration sans copie et l'accès aux données fédérée permettent aux organisations de générer des connaissances sans répliquer les jeux de données confidentiels, offrant une approche plus évolutive, sécurisée et conforme aux politiques de collaboration sur les données d'entreprise.
### Émergence du maillage de données et du tissu de données
Face à ces pressions, l’industrie s’est regroupée autour de deux paradigmes architecturaux complémentaires : Data Mesh et Data Fabric. Ensemble, ils représentent un abandon du contrôle centralisé vers des architectures de données fédérées et sensibles aux domaines.
Data Mesh décentralise la propriété des données vers des équipes alignées sur le domaine, telles que Sales, Marketing ou Supply Chain. Chaque domaine traite ses données comme un produit, avec des contrats, des normes de qualité et des objectifs de niveau de service clairement définis. Ce modèle améliore la responsabilisation et l'alignement des activités, mais à l'échelle de l'entreprise, il introduit de nouveaux défis en matière de coordination, d'interopérabilité et de gouvernance cohérente entre les domaines.
Data Fabric répond à ces défis en fournissant la couche connective qui lie les domaines décentralisés dans un système cohérent. Il fournit des métadonnées partagées, une sémantique commune, une application automatisée des politiques, une filiation et une gouvernance, ce qui permet de découvrir, d'accéder et de gouverner les données de façon cohérente sans forcer la consolidation physique dans un référentiel unique.
Ensemble, Data Mesh et Data Fabric jettent les bases de l'accès aux données fédérées. Cependant, ils ne vont pas jusqu'à résoudre un problème critique d'ordre suivant : permettre une collaboration sécurisée et régie à travers les domaines et les frontières organisationnelles, où les données doivent être analysées conjointement sans être copiées ni exposées.
### Le pivot stratégique pour nettoyer les salles
À mesure que les données d'entreprise sont de plus en plus distribuées et que les réglementations en matière de confidentialité deviennent plus strictes, les organisations sont confrontées à un défi architectural majeur. Comment collaborent-ils entre les équipes, les partenaires et les plates-formes sans partager de données brutes ? Les approches traditionnelles d'intégration de données n'étaient pas conçues pour ce niveau de distribution ou d'examen réglementaire, ce qui créait des tensions entre la collaboration et la conformité.
Ce défi a entraîné un virage vers les salles blanches de données en tant que capacité architecturale de base. Les salles blanches éloignent la collaboration du transfert de données et la dirigent vers le calcul régi. Au lieu de copier ou d'échanger des jeux de données, les analytiques et les charges de travail IA sont exécutées là où les données vivent déjà en partageant les métadonnées. Les requêtes sont évaluées en temps réel par rapport aux règles de confidentialité, de consentement et d'utilisation, et seuls les résultats approuvés et agrégés sont renvoyés.
Dans ce modèle, les salles blanches de données agissent comme la frontière Trust des architectures de données modernes. Ils permettent aux organisations de travailler avec des partenaires et des filiales sans perdre le contrôle de leurs données, de faire respecter la confidentialité et le consentement par des contrôles système plutôt que par la seule politique, et d'opérer à travers les clouds tout en respectant les limitations en résidence des données et contractuelles.
Pour les cas d'utilisation d'activation, d'analyse et d'IA, les salles blanches offrent un moyen sécurisé de générer des connaissances à partir de données externes sans exposer d'informations confidentielles. Ils permettent de basculer du partage de données à la collaboration de confiance. Pour les cas d'utilisation d'activation, les salles blanches offrent un moyen sécurisé de générer des audiences qui peuvent être activées directement vers une destination autorisée. Tout ceci est réalisé sans exposer d'informations d'identification personnelle (PII) à l'une des parties. Cela marque un tournant dans l'architecture des données d'entreprise. Les salles blanches de données ne sont plus des outils de niche. Ils deviennent l'infrastructure de base des plates-formes de données fédérées, préservant la confidentialité et prêtes pour l'IA.
## Personnalités des parties prenantes et garde-fous techniques
Une architecture de salle blanche de données réussie est un système multi-interface conçu pour résoudre les pressions concurrentes de l'utilité, de la sécurité et de la vitesse des données. Il existe trois personnes principales dont les points de friction distincts doivent être traités par la conception technique sous-jacente.
### Agent de la protection de la vie privée et de la conformité (l'atténuateur de risque)
Les agents de confidentialité et de conformité utilisent la salle blanche des données comme outil de gouvernance. Leur principale préoccupation est la dérive en matière de conformité, le risque que les environnements de collaboration externes ne parviennent pas à appliquer les mêmes normes rigoureuses que les systèmes internes.
- **Points de friction :** L'exposition réglementaire (RGPD, CCPA, DMA) et les attaques par « hameçonnage » dans lesquelles un partenaire tente de trianguler l'identité d'un utilisateur par des requêtes granulaires répétées.
### Data Scientist et Analyst (l'optimiseur d'utilitaire)
Les scientifiques des données considèrent la salle blanche des données comme un refuge pour la modélisation avancée. Leur préoccupation principale est la préservation des services publics, en veillant à ce que les mesures de confidentialité ne rendent pas les données statistiquement inutiles.
- **Points de friction :** Latence élevée et accès restreint aux attributs granulaires requis pour l'apprentissage machine (ML), la modélisation similaire et la prédiction d'attrition.
### L'utilisateur marketing et professionnel (Le réalisateur de valeur)
Cette personne se concentre exclusivement sur le temps de valeur (TTV). Ils craignent que les projets de salles blanches de données deviennent souvent des goulets d'étranglement techniques nécessitant des semaines de support en ingénierie des données.
- **Points de friction :** Des processus de configuration complexes, le nettoyage manuel des données et le problème de « page blanche » d'écriture de code pour obtenir de simples résultats de chevauchement.
### Le modèle de personne « Business First »
Alors que les architectures traditionnelles se concentrent sur l'élaboration de la couche de données avant la couche utilisateur, notre approche stratégique, alignée sur la méthodologie « Business First », inverse ce modèle. Nous donnons la priorité à une approche sans code en quelques clics qui permet aux utilisateurs professionnels de générer des connaissances et de prendre des mesures immédiates.
**Workflow « Connaissances vers action » :** L'architecture est conçue comme un espace de travail actif plutôt que comme un référentiel passif. En fournissant des modèles de cas d'utilisation (par exemple, chevauchement de segment, activation et performance de campagne), nous permettons aux utilisateurs professionnels d'auto-servir des connaissances. Cela garantit qu'une connaissance, par exemple un segment similaire optimisé, est immédiatement disponible pour l'activation dans l'écosystème marketing, sans avoir besoin d'un ingénieur de données pour déplacer manuellement des fichiers.
**La Fédération zéro copie comme actif stratégique :** Pour maximiser la TVT, l'architecture adopte une logique de copie nulle. Au lieu du processus ETL traditionnel, qui introduit des risques de latence et de sécurité, notre architecture fédère les requêtes directement à l'emplacement où résident les données (par exemple, Snowflake, BigQuery ou Amazon S3). Cela transforme l'investissement en données existant de l'organisation en actif stratégique, permettant aux utilisateurs métiers d'agir en temps réel sur les données les plus récentes tout en maintenant une gouvernance stricte et en éliminant le coût de la redondance des données.
## Cas d'utilisation de salles blanches de données clés
Les salles blanches de données ont émergé dans la publicité en réponse à la dépréciation des cookies et à la réglementation de la confidentialité, mais ont évolué au-delà de la mesure vers l'analyse des clients, la segmentation de l'audience et des cas d'utilisation d'activation dans tous les secteurs d'activité. Selon le rapport State of Retail Media de 2025, 66 % des organisations utilisent maintenant des salles blanches dans une certaine mesure, motivées par la nécessité d’une collaboration sûre pour la protection de la vie privée qui produit des résultats commerciaux mesurables.
Le schéma est cohérent entre les secteurs : les données restent sous la responsabilité de leur propriétaire, le calcul est régi et seules les connaissances protégées par la vie privée sont partagées.
### Marketing et publicité : Mesure sans cookies tiers
**Le défi :** Les marketeurs doivent mesurer l'efficacité des campagnes, éviter les impressions publicitaires dupliquées et optimiser la portée et la fréquence, mais ne peuvent plus s'appuyer sur des cookies tiers ou des identifiants d'appareil.
**La solution Salle blanche :**
- Les annonceurs contribuent aux données hachées sur l'exposition des clients ou des campagnes
- Les éditeurs contribuent aux signaux d'impression et d'engagement
- La salle blanche calcule la portée, la fréquence, l'attribution et l'ascenseur
- L'activation se fait via des plates-formes approuvées sans exportation de données brutes
**Résultat commercial :** Les salles blanches fournissent une attribution en boucle fermée liant les impressions publicitaires aux transactions réelles, une analyse de l'incrémentalité isolant la véritable augmentation des campagnes et une mesure unifiée entre les canaux, des capacités que la publicité numérique traditionnelle ne peut pas offrir.
**Industry Evidence:** Mesure est le cas d'utilisation de salle blanche le plus établi aujourd'hui, avec les principaux réseaux de médias tels que Pinterest, Disney et Paramount qui créent leurs propres salles blanches.
### Retail Media and Consumer Packaged Goods (CPG) : Monétisation des données tierces sans les partager
**Le défi :** Les marques CPG dépensent beaucoup dans les médias de détail, mais n'ont pas de visibilité sur les résultats d'achat. Les détaillants possèdent des données enrichies sur les points de vente, mais ne peuvent pas les exposer sans violer les engagements en matière de confidentialité.
**La solution Salle blanche :**
- Les détaillants et les entreprises CPG combinent les données des points de vente des magasins de détail avec les données marketing pour optimiser les activités promotionnelles
- Les marques contribuent aux identifiants CRM ou de fidélité hachés
- Lien salle blanche exposition publicitaire aux achats en magasin/en ligne
- L'activation reste dans l'écosystème média du détaillant
**Résultat commercial :**
- Les détaillants monétisent les données internes sans vendre d’informations brutes sur les clients
- Attribution en boucle fermée pour les marques montrant les campagnes qui ont entraîné des achats
- Évolution des réseaux de médias de détail sans risque de confidentialité
**Industry Evidence:** Les réseaux de médias de détail tels que Luminate et Kroger Precision Marketing de Walmart offrent des salles blanches qui aident les marques CPG à analyser le comportement des clients et à optimiser les stratégies marketing en utilisant les données des détaillants.
### Services financiers : Détection collaborative des fraudes
**Le défi :** Les réseaux de fraude fonctionnent entre les institutions, mais les banques ne peuvent pas partager ouvertement des données sur les clients ou les transactions en raison de réglementations telles que la GLBA et les nouvelles lois sur la protection de la vie privée.
**La solution Salle blanche :**
- Plusieurs banques mettent en commun des données anonymisées afin d'identifier des modèles révélateurs de fraude, par exemple des activités interbancaires inhabituelles
- Les analytiques ou modèles fédérés traversent des signaux de fraude partagés
- Aucune institution n'affiche les données au niveau client d'une autre
**Résultat commercial :**
- Détection plus précoce des modèles de fraude interinstitutionnelle
- Moins de faux positifs grâce à des ensembles de signaux enrichis
- Conformité réglementaire sans centraliser les données confidentielles
**Industry Evidence:** Les solutions de services financiers d'Experian et de TransUnion offrent des technologies de salle blanche permettant aux banques et aux assureurs de collaborer sur la détection des fraudes et l'évaluation des risques tout en maintenant des contrôles stricts de confidentialité des données.
### Soins de santé et sciences de la vie : Recherche sans exposition aux données des patients
**Le défi :** Les sociétés pharmaceutiques ont besoin de résultats concrets pour le développement de médicaments, mais les données résident dans les systèmes DME des hôpitaux protégés par HIPAA et d'autres réglementations similaires.
**La solution Salle blanche :**
- Les médecins et les chercheurs pharmaceutiques partagent des données dans une salle blanche pour apprendre comment les patients réagissent aux traitements.
- Les données des patients restent dans les environnements de prestataires.
- Les chercheurs effectuent des analyses statistiques approuvées dans une salle blanche.
- La confidentialité différentielle empêche la réidentification.
**Résultat commercial :**
- Données réelles statistiquement valides à l'échelle
- Simplification du recrutement de patients pour des essais cliniques en mappant les données anonymisées des patients avec les critères d’essai, en trouvant des candidats éligibles sans violer les lois sur la confidentialité des soins de santé
- Réduction de la dépendance à l'égard de populations limitées d'essais cliniques
**Industry Evidence:** Les salles blanches axées sur les soins, telles que Datavant, offrent des environnements conformes HIPAA permettant aux chercheurs et aux organisations de santé d'analyser en toute sécurité les données des patients pour les essais cliniques et le développement de médicaments.
### Modèles inter-industries : L'impératif de collaboration
Au-delà de ces principaux cas d'utilisation, les salles blanches permettent :
- **Optimisation de la chaîne d'approvisionnement :** Les fabricants et les fournisseurs collaborent pour partager les détails d'inventaire, les calendriers de production et les prévisions de demande, ce qui permet une meilleure coordination tout en protégeant les informations exclusives.
- **M&A Due Diligence:** Lorsqu'une entreprise en acquiert une autre, la diligence raisonnable nécessite d'examiner les projections financières et les bases de données des clients sans partager directement des informations confidentielles; les salles blanches révèlent des connaissances telles que l'alignement du segment de clients et les risques de conformité.
- **Médias et divertissement :** Les éditeurs prouvent la valeur de l’audience pour les annonceurs tout en protégeant l’identité des abonnés, en activant des CPM premium soutenus par une mesure de confiance au lieu d’un ciblage probabiliste
Dans les secteurs AdTech, Retail, Financial Services, Health et Media, les Data Clean Rooms sont devenues des infrastructures Trust fondamentales. Ils permettent une collaboration de grande valeur qui était auparavant bloquée par des contraintes de confidentialité, réglementaires ou concurrentielles. Les salles blanches sont des **composants architecturaux essentiels** qui permettent une collaboration sécurisée et régie, en recueillant des connaissances et en monétisant sans renoncer au contrôle des données ni à la conformité.
## Salles blanches de données : Le fondement de la collaboration sur les données de confiance
Une salle blanche de données est un environnement sécurisé et régi qui permet à plusieurs parties de générer des connaissances communes sans exposer ni échanger de données brutes. Au lieu de répliquer des jeux de données, les analytiques approuvées, l'IA et les charges de travail d'activation sont exécutées en place, et seules les sorties conformes à la stratégie sont renvoyées. Lorsque l'activation nécessite des enregistrements au niveau individuel, les données sont livrées directement à la destination prévue sans être exposées aux parties collaboratrices.
Sur le plan architectural, les salles blanches transforment la collaboration du partage de données au calcul contrôlé. Chaque participant conserve la garde de ses données, tandis que l'exécution automatique régit le comportement des requêtes, les contraintes de sortie, le consentement et les stratégies d'utilisation.
La collaboration est également activée par des mécanismes d'alignement des identifiants de protection de la vie privée, qui permettent de corréler des jeux de données de différentes parties sans exposer les identifiants sous-jacents, une capacité expliquée plus en détail plus loin dans ce document.
Par conséquent, les salles blanches de données servent d'infrastructure de base pour les entreprises multicloud, pilotées par l'IA et réglementées par la confidentialité, qui opèrent sur des stratégies de données fédérées sans copie.
Les premières salles blanches de données suivaient un modèle centralisé de « bunker ». Tous les participants devaient copier les données dans un environnement tiers neutre pour les analyser. Bien que simple dans son concept, cette approche a introduit des frictions importantes. Le mouvement des données a augmenté la latence et le coût, compliqué les accords juridiques et de conformité, et forcé les organisations à abandonner le contrôle direct des données confidentielles. Dans les industries réglementées, ces compromis rendaient souvent la collaboration peu pratique.
Les salles blanches de données modernes ont évolué vers un modèle distribué et fédéré. Les données restent dans l'environnement du propriétaire et les analytiques sont exécutées en place via des requêtes fédérées. La salle blanche elle-même fonctionne comme une couche de gouvernance qui intercepte chaque requête, applique les contrôles de confidentialité et de stratégie au moment de l'exécution, et renvoie uniquement les sorties approuvées et agrégées.
| Dimension | Salle blanche traditionnelle (modèle "Bunker") | Salle blanche moderne (modèle distribué/fédéré) |
|---|---|---|
| Emplacement des données | Les données sont copiées dans un environnement tiers centralisé | Les données restent dans l'environnement du propriétaire |
| Mouvement des données | Nécessite un transfert physique et une duplication des jeux de données | Aucun mouvement de données brutes, les requêtes sont exécutées en place |
| Control and Custody | La garde partiellement abandonnée à une plate-forme tierce | Propriété et possession des données brutes conservées par chaque partie |
| Modèle d'architecture | Agrégation centralisée | Calcul distribué et fédéré |
| Gouvernance Enforcement | Stratégies appliquées après le déplacement des données | Stratégies appliquées lors de l'exécution de la requête |
| Modèle de confidentialité | Repose fortement sur des contrôles contractuels et procéduraux | Applicable techniquement via des contrôles d'exécution et des seuils d'agrégation |
| Latence | Latence plus élevée due à l'ingestion et à la synchronisation | Latence réduite, requêtes fédérées en temps quasi réel |
| Structure de coût | Augmentation des coûts de stockage, de transfert et de duplication | Réduction de la duplication, ascompute se produit à l'endroit où résident les données |
| Complexité de conformité | Accords juridiques complexes dus au mouvement transfrontalier de données | Conformité simplifiée puisque les données ne quittent pas la frontière source |
| Évolutivité | La mise à l'échelle nécessite plus de stockage et de réplication des données | Évolue à travers le calcul distribué sans dupliquer les données |
| Industrie réglementée adaptée | Souvent peu pratique en raison de problèmes de garde et de résidence | Mieux aligné sur la souveraineté, le consentement et les contraintes réglementaires |
### Bases de la plate-forme pour les salles blanches de données évolutives
Au niveau de la couche infrastructure, Salesforce Data 360 fonctionne sur Hyperforce, l’exécution native de Salesforce qui extrait les ressources hyperscaler (AWS, Azure, GCP) derrière un plan de contrôle unifié. Cette architecture permet aux données de rester dans la région pour satisfaire aux exigences de souveraineté et de résidence, tout en permettant des opérations régies en salle blanche au niveau mondial.
Cette fondation permet la collaboration inter-clouds en salle blanche, notamment l'interopérabilité native avec AWS Clean Rooms. En utilisant Data 360 comme couche d'orchestration et de gouvernance, les entreprises peuvent collaborer avec des partenaires opérant directement sur AWS sans forcer la migration des données vers le stockage géré par Salesforce. Les requêtes sont renvoyées à la source, les règles de confidentialité sont appliquées de façon cohérente et seuls les résultats conformes et agrégés sont échangés entre les plates-formes.
Conformité et Trust sont appliqués à la frontière de l'infrastructure et de l'exécution, plutôt que modernisés au niveau de la couche applicative, ce qui fournit une base durable pour une collaboration multicloud et multipartie à grande échelle.
### Pipeline Data 360 de l'ingestion à l'activation
Data 360 implémente un pipeline de données traçable de bout en bout, qui garantit que les opérations en salle blanche s'appuient sur des données harmonisées, régies et sensibles à l'identité plutôt que sur des extractions brutes.
Les principales étapes comprennent :
- **Connect**: Ingestion et virtualisation de données via des connecteurs prêts à l'emploi, des API, des kits de développement, des connecteurs MuleSoft ou zero-copy
- **Persistance**: Stockage de données brutes sous des formats natifs (Parquet / Iceberg)
- **Harmoniser**: Mappage avec des objets modèle de données (DMO) canoniques pour des jointures cohérentes
- **Unifier**: La résolution de l'identité crée des enregistrements Golden
- **Dériver des connaissances**: Les connaissances calculées calculent des métriques agrégées dans la frontière régie
- **Act**: Les sorties régies sont transmises à des organisations Salesforce, des plates-formes marketing, des réseaux publicitaires, des plates-formes de données externes **ou d'autres salles blanches**, fermant la boucle de la connaissance à l'action
Ce pipeline garantit que les salles blanches fonctionnent sur des données de niveau entreprise, pas sur des extractions ad hoc.
### Intégration native et « Clicks-Not-Code »
Contrairement aux plates-formes de salles blanches de données autonomes qui nécessitent un provisionnement séparé et un développement SQL, les salles blanches Salesforce sont incorporées nativement à Data 360. Cela permet de réutiliser les objets modèle de données, les règles d'identité, les modèles de consentement et les stratégies de gouvernance, éliminant ainsi les couches de sécurité dupliquées.
Le modèle de salle blanche piloté par le modèle de Salesforce est un accélérateur clé qui utilise :
- **Modèles prêts** à l'emploi pour prendre en charge des modèles de collaboration courants tels que le chevauchement d'audience, la suppression, la portée et la mesure d'ascenseur.
- **Des modèles personnalisés** qui permettent aux architectes et aux utilisateurs avancés de définir une logique analytique réutilisable adaptée aux besoins spécifiques au secteur d'activité ou aux partenaires, sans exposer les données brutes ni la complexité des politiques.
Cette approche standardise la collaboration tout en offrant de la flexibilité, en permettant aux salles blanches d'évoluer en tant que capacité d'entreprise reproductible, pas en tant que projet d'analyse unique.
### La « voie d’or » – Fermer la boucle Insight-to-Action
Data 360 répond à un mode d'échec courant des salles blanches traditionnelles : le trou d'activation. Son infrastructure Golden Path garantit que les connaissances générées dans une salle blanche peuvent être immédiatement mises en œuvre, sans exporter de données brutes.
- **Configuration et découverte**: Les partenaires partagent des métadonnées de schéma et exploitent des modèles pour évaluer la faisabilité avant la finalisation des contrats.
- **Analyse**: Les modèles prédéfinis et personnalisés pilotent l'analyse du chevauchement, la suppression, la modélisation similaire et la mesure de portance, le tout exécuté à l'intérieur de la frontière régie.
- **Activation**: Les segments approuvés sont envoyés directement dans Marketing Cloud, des plates-formes publicitaires ou des systèmes partenaires, avec uniquement des résultats agrégés et conformes partagés.
Les modèles deviennent des chemins d'exécution réfléchis, ce qui garantit que la collaboration progresse de façon prévisible de l'analyse à l'activation.
## Playbook pour les salles blanches Salesforce Data 360
Le déploiement d'une salle blanche Salesforce Data 360 n'est pas seulement un exercice de configuration, c'est un workflow architectural discipliné couvrant la préparation des données, la conception de la gouvernance, la connectivité sécurisée et la surveillance opérationnelle.
### Étape 1 : Définition du cas d'utilisation de collaboration (commencer par l'intention)
Avant de toucher aux données ou à la configuration, les architectes doivent définir clairement :
- À quelle question essayons-nous de répondre ?
- Quel est le résultat attendu? (p. ex., analyse des chevauchements, mesure de l'ascenseur, suppression, détection des fraudes)
- Quel niveau d'agrégation est requis?
- Quelles contraintes réglementaires ou contractuelles s'appliquent ?
- Quel chemin d'activation consommera les résultats ?
Comprendre l'objectif du collaborateur détermine tout ce qui suit : clés de jointure, règles d'identité, seuils de gouvernance et modélisation des coûts. Les salles blanches sont des environnements spécialement conçus pour l'occasion. es salles blanches doivent être conçues autour d'un objectif analytique défini, pas d'une exposition générique aux données.
### Étape 2 : Préparation des données pour la collaboration en salle blanche
Avant de commencer à collaborer, les données d'entreprise doivent être préparées de façon structurelle et sémantique. Les salles blanches amplifient les forces et les faiblesses des données sous-jacentes. Les ordures, les déchets, c'est d'autant plus vrai ici.
**Ingestion :** Connectez des systèmes sources tels que Salesforce CRM, Marketing Cloud, AWS S3 et Google Cloud Storage à Data 360. Dans la mesure du possible, utilisez des connecteurs sans copie (par exemple Snowflake) pour éviter les déplacements inutiles ou la duplication des données.
**Mapping sémantique :** Mappez les flux de données avec le modèle de données Customer 360. Standardisez les champs clés tels que les numéros de téléphone (format E.164), les codes de pays/état (normes ISO) et les adresses e-mail. Un désalignement (par exemple, une partie qui utilise « CA » et une autre « California ») peut entraîner l'échec silencieux des jointures et réduire les taux de correspondance.
**Résolution de l'identité :** Configurez des règles déterministes (correspondance exacte) et probabilistes (correspondance partielle) pour créer un Individu unifié (enregistrement doré). Cette entité unifiée est la surface de correspondance des salles blanches.
La qualité de la résolution de l'identité impacte directement la valeur de la collaboration. Une plus grande précision de correspondance augmente les taux de chevauchement, la confiance analytique et réduit les faux négatifs.
### Étape 3 : Provisionnement de la salle blanche
Une fois les données harmonisées, la salle blanche elle-même doit être provisionnée pour définir les limites de la collaboration.
**Validation de licence :** Vérifiez que toutes les organisations participantes disposent des autorisations Data 360 et salles blanches requises.
**Étendue de l'espace de données :** Les objets de salle blanche doivent être limités à un espace de données spécifique. Seuls les objets mappés avec cet espace de données sont visibles par la salle blanche. Cela permet d'isoler logiquement la collaboration sans nécessiter la création d'un espace de données uniquement pour les salles blanches.
**Définir des règles de gouvernance :** Établissez des stratégies par déclaration avant l'exécution des requêtes :
- **Seuils d'agrégation :** par exemple, au moins 100 enregistrements par sortie
- **Clés de jointure :** par exemple Email_Hash_SHA256
- **Opérations autorisées :** uniquement les fonctions d'agrégation telles que COUNT, SUM, AVG
- **Restrictions explicites :** bloquer les exportations au niveau de la ligne (SELECT \*)
Les règles de gouvernance sont appliquées au moment de l'exécution, ce qui fait de la confidentialité et de la conformité des propriétés au niveau du système plutôt qu'un guide de procédure.
### Étape 4 : Établissement d'une connectivité multipartie sécurisée
Les salles blanches dépassent souvent les limites organisationnelles et de plate-forme. La connectivité doit être explicite et étroitement contrôlée.
**Lien de compte :**
- **Salesforce vers Salesforce :** Utilisez Data Cloud One ou des mécanismes de partage inter-organisations approuvés.
- **Scénarios multicloud :** Validez l'alignement et la résidence de la région avant l'activation des requêtes.
**Authentification et autorisation :** Configurez l'accès basé sur OAuth pour les utilisateurs d'intégration dédiés avec le principe du moindre privilège : limitez strictement l'accès aux espaces de données nécessaires et évitez les autorisations administratives.
Les échecs de sécurité résultent souvent d'utilisateurs de l'intégration trop autorisés plutôt que de faiblesses dans la cryptographie ou les contrôles de plate-forme.
### Étape 5 : Exécution, surveillance et contrôle des charges de travail en salle blanche
Une fois en ligne, l'accent est mis sur la supervision opérationnelle, la qualité des requêtes et la gestion des coûts.
**Exécution de requête :** Les analystes ou workflows effectuent des analyses et des agrégations de chevauchement via des Connaissances calculées ou des interfaces SQL approuvées. Toutes les requêtes appliquent automatiquement les seuils d'agrégation et les contrôles de confidentialité.
**Audit et traçabilité :** Les salles blanches Salesforce Data 360 fournissent des pistes d'audit sous la forme d'un objet modèle de données (DMO) d'audit. Cela capture des métadonnées sur l'activité de la requête, notamment qui a exécuté la requête, quand elle a été exécutée et quelles stratégies ont été appliquées. L'objet modèle de données Audit permet la génération de rapports de conformité, la validation de la gouvernance et la traçabilité judiciaire, ce qui garantit que la collaboration est à la fois sécurisée et vérifiable.
**Surveillance de la consommation :** Data Cloud utilise un modèle de crédit basé sur la consommation. Les principaux facteurs comprennent :
- Lignes traitées (par exemple, 1 million de lignes = unité de crédit de référence)
- Complexité des requêtes
- Opérations de résolution de l'identité (multiplicateur supérieur)
- Ingestion par lot (multiplicateur inférieur)
**Portefeuille numérique et alertes :** Utilisez Digital Wallet pour suivre la consommation en temps réel et configurer des alertes à des seuils de 50%, 75% et 90%. Corrélez les pics à des charges de travail spécifiques pour éviter des coûts inattendus.
Notez que la copie zéro n'élimine pas les coûts de calcul. Bien que la duplication physique soit supprimée, l'exécution est effectuée au niveau du système source. Les architectes doivent gérer les modèles de requête, la sélectivité des jointures et la fréquence d'exécution pour contrôler les coûts et les performances.
## Gouvernance, sécurité et conformité
### Architecture de salles blanches pour Trust à l'échelle
Dans les entreprises modernes, Trust n'est pas bloqué sur une salle blanche de données. C'est un résultat architectural. Salesforce Data 360 applique la gouvernance, la sécurité et la conformité de façon continue et automatique, en déplaçant les salles blanches des environnements pilotés par les politiques vers des systèmes gouvernés par la plate-forme.
Les contrôles du temps d'exécution (identités verrouillées, pistes d'audit et confidentialité différentielle) s'appliquent de façon cohérente, que la collaboration ait lieu dans Salesforce, entre partenaires ou entre clouds.
### Trust et gouvernance en temps d'exécution
Le changement le plus important pour les architectes est que Trust est imposé lors de l'exécution, pas assumé à l'avance. Salesforce Data 360 y parvient grâce à plusieurs contrôles de plate-forme principaux :
- **Identité verrouillée :** L'accès des partenaires est lié cryptographiquement aux identités vérifiées de l'organisation Salesforce, ce qui empêche l'usurpation ou la participation non autorisée.
- **Parcours d'audit :** Chaque requête, jointure, chevauchement de segment et activation est consigné pour une auditabilité totale et la conformité réglementaire.
- **Confidentialité différente :** L'inspection au niveau de la ligne est structurellement impossible. Les sorties sont agrégées et statistiquement limitées. Les collaborateurs affichent uniquement des résultats qui protègent la vie privée, tels que des métriques de portée ou des pourcentages d'augmentation, jamais des transactions individuelles ou des identités.
Ces contrôles remplacent le Contract Trust par des garanties mathématiques et une application au niveau de la plate-forme, réduisant ainsi les risques opérationnels et juridiques.
### Gouvernance de l’IA via la couche Einstein Trust
Les agents IA interagissant de plus en plus avec les données des salles blanches, Salesforce introduit la Einstein Trust Layer. Il agit comme un sas architectural entre les données confidentielles de l'entreprise et les grands modèles de langage externes. Les connaissances des salles blanches peuvent ainsi alimenter en toute sécurité les décisions pilotées par l’IA sans exposer les données sous-jacentes.
**Principales capacités :**
- **Zéro rétention des données :** Les données envoyées aux LLM sont éphémères. Les fournisseurs de modèle ne peuvent pas stocker des invites ou des réponses pour la formation.
- **Détection des langues toxiques et masquage des informations d'identification personnelle :** Les entrées et les sorties sont automatiquement analysées, et les informations d'identification personnelle sont masquées conformément aux stratégies de masquage des données configurées dans Data 360.
### Isolation logique via des espaces de données et des ensembles d'autorisations
Les **espaces de données** fournissent un isolement logique au sein d'une organisation et doivent respecter les frontières réglementaires, géographiques et de partenariat, notamment :
- Espace de données UE
- Espace de données Amérique du Nord
Seuls les jeux de données attribués à un espace de données sont visibles dans ses salles blanches, ce qui évite toute exposition transfrontière accidentelle.
Les ensembles d'autorisations permettent de mieux contrôler qui peut créer ou gérer des salles blanches, exécuter des requêtes ou activer des segments. Les autorisations sensibles aux données appliquent les restrictions au niveau du champ dans les objets modèle de données. Par exemple, les marketeurs peuvent afficher les noms de segment et la taille de l'audience, mais pas les indicateurs de revenu ou de santé.
La sécurité est appliquée au niveau de la couche sémantique, ce qui permet un libre-service sécurisé pour les utilisateurs professionnels sans supervision informatique constante.
### Conformité et consentement par conception
Les signaux de consentement se propagent automatiquement via Data 360 dans l'exécution en salle blanche. Les utilisateurs qui révoquent leur consentement sont exclus de l'analyse et de l'activation par défaut, ce qui garantit que la conformité est appliquée par le système, pas manuellement.
Salesforce Data 360 traite la gouvernance, la sécurité et la conformité comme des éléments architecturaux primitifs de première classe, pas comme des compléments facultatifs. En combinant l'auditabilité au moment de l'exécution, les identités verrouillées, la confidentialité différentielle, les espaces de données, la résolution de l'identité sensible au consentement et la couche Trust Einstein, les entreprises peuvent adapter la collaboration en salle blanche entre les partenaires, les systèmes multicloud et les charges de travail pilotées par l'IA, le tout sans compromettre Trust, confidentialité ou conformité réglementaire.
## Conclusion et voie à suivre
### Une voie pratique pour les architectes
Pour capturer toute la valeur des salles blanches de données, les architectes doivent les traiter comme une infrastructure architecturale de base, pas comme des outils d'analyse isolés. Les priorités suivantes définissent une voie pragmatique et évolutive :
**Faire de la collaboration une préoccupation architecturale de premier ordre :** La collaboration en matière de données externes doit être conçue avec la même rigueur que l'intégration interne. Les salles blanches doivent être incorporées dans des architectures de référence d'entreprise, aux côtés de plates-formes de données, de couches d'intégration et de systèmes IA, et non déployées en tant qu'extensions ad hoc. À mesure que l'interopérabilité se développe (par exemple, l'intégration de salles blanches Data 360 à des salles blanches AWS et la future compatibilité entre les salles blanches), les architectes doivent concevoir des modèles de collaboration qui anticipent les écosystèmes multiplate-formes plutôt que les silos à fournisseur unique.
**Conception de la confidentialité par défaut à la source**
**Conception de la fluidité des données : **Plutôt que d'appliquer par défaut la réplication ETL lourde et centrale, les architectes devraient d'abord envisager la fédération et l'accès sans copie. Le déplacement du calcul vers les données (le cas échéant) réduit les doublons inutiles, réduit les coûts et préserve l'intégrité de la source de vérité. « Connect vs. copy » doit être une décision architecturale consciente, pas une habitude héritée.
**Réduire l'écart entre les connaissances et l'action :** Les salles blanches qui s'arrêtent à l'analyse ne fournissent pas de valeur métier. Les architectures doivent connecter nativement les sorties de salle blanche à des systèmes d'activation et à des workflows IA. Les boucles de rétroaction, la mesure des performances et l'exécution en aval doivent être conçues dès le départ.
**Préparez-vous à l'entreprise Agentic :** À mesure que les agents IA utilisent de plus en plus les données de l’entreprise, les salles blanches serviront d’environnements d’exécution contrôlés dans lesquels les agents peuvent opérer sans exposer de données brutes. Les architectes qui alignent la stratégie des salles blanches avec les frameworks de gouvernance et Trust IA seront les mieux placés pour cette prochaine phase.
### Conclusion
Les salles blanches de données modernes représentent un changement fondamental dans l'architecture des données d'entreprise. Ils résolvent la tension de longue date entre l'utilité des données et la confidentialité en permettant la collaboration sans exposition aux données.
Des architectures telles que Salesforce Data 360 démontrent que ce compromis n'est pas une considération « ni ». En dissociant le stockage de données de l'activation par le biais de modèles sans copie, et en incorporant des technologies d'amélioration de la confidentialité directement dans l'exécution, les entreprises peuvent collaborer sur des analytiques à valeur élevée sans renoncer au contrôle de leurs données. La confidentialité passe de l'obligation contractuelle à la garantie architecturale.
Plus important encore, les salles blanches transforment les données d'un actif statique et cloisonné en une ressource régie et actionnable. Lorsqu'elles sont connectées en natif à des couches d'activation et d'IA, les connaissances ne sont plus bloquées dans les tableaux de bord. Ils s'infiltrent directement dans les décisions, les campagnes et les systèmes autonomes, fermant la boucle entre les données, les actions et les résultats à l'échelle de l'entreprise.
## À propos des auteurs
**Yugandhar Bora** est architecte en génie logiciel chez Salesforce, spécialisé dans l'architecture de données sur la plate-forme Data and Intelligence Applications. Il dirige les initiatives du comité d'examen de l'architecture d'entreprise (EARB) axées sur la gouvernance des données et les modèles de données unifiés, tout en contribuant aux solutions de provisionnement de plate-forme automatisé.
**Birendra Kumar Singh** est membre principal du personnel technique, spécialisé dans l'architecture de plate-forme et de données dans Data 360 chez Salesforce. Il est un membre principal de la plate-forme d'activation et dirige l'initiative Salle blanche axée sur la fourniture d'une infrastructure de salle blanche de données aux clients de Data 360.
**Priyanka Kshirsagar** est chef de produit senior chez Salesforce, dirigeante des salles blanches Data 360, une capacité qu'elle a développée de toutes pièces pour permettre aux entreprises clientes de collaborer sur des données internes dans un environnement de protection de la vie privée. Elle pilote la vision des cas d’utilisation pilotés par l’IA agentique et la ML, notamment la modélisation similaire et l’enrichissement de l’identité dans les salles blanches, et a piloté le produit via la Disponibilité générale et un lancement de Dreamforce de niveau 1.
## Résumé
Le paradigme du logiciel est en train de basculer de la manipulation directe à la délégation orientée vers des objectifs. Au premier plan de cette transformation, les agents IA, des entités autonomes et intelligentes capables de comprendre, de raisonner et d’agir au nom des utilisateurs. Ce livre blanc propose une exploration technique des principaux types d’agents IA : Conversationnel, Proactif, Ambiant, Autonome et Collaboratif. Il définit chaque type, présente des cas d'utilisation spécifiques de Gestion des relations clients (CRM) et fournit un avant-projet architectural pour l'élaboration de ces agents sur Salesforce _Agentforce_ Platform, complété par des exemples techniques exploitant l'interopérabilité Flow, Apex, Data 360, Agent2Agent (A2A) communication et Model Context Protocol (MCP).
## Chapitre 1 : Une taxonomie des agents IA
Un agent IA est un système qui perçoit son environnement et prend des mesures pour atteindre des objectifs spécifiques. Bien que le concept ne soit pas nouveau, l'avènement de puissants grands modèles de langage (LLM) a renforcé leurs capacités. Nous pouvons classer les agents en fonction de leur mode de fonctionnement principal et de leur interaction.
### 1.1 Agents conversationnels
**Définition :** Les agents conversationnels sont le type d'agent le plus familier. Ils fonctionnent de façon réactive, en réponse à la demande, principalement par le biais d'interfaces en langage naturel (texte ou voix). Leur fonction principale est de comprendre l'intention de l'utilisateur et de fournir une réponse pertinente, que ce soit pour répondre à une question, récupérer des informations ou exécuter une simple commande.
**Importance :** Les agents conversationnels sont les portes d'entrée numériques d'une organisation. Ils excellent dans la gestion des tâches répétitives et bien définies, libérant ainsi des ressources humaines. Leur efficacité est mesurée par leur capacité à résoudre rapidement et avec précision les intentions des utilisateurs et à prendre des mesures au nom des utilisateurs.
### 1.2 Agents proactifs
**Définition :** Contrairement aux agents conversationnels qui attendent une invite, les agents proactifs agissent en tant qu'observateurs vigilants. Ils sont déclenchés par des événements spécifiques, des modifications de données ou des conditions prédéfinies dans un système. Lorsqu'ils sont déclenchés, ils exécutent une tâche ou initient un workflow sans nécessiter une interaction directe de l'utilisateur.
**Importance :** Les agents proactifs transforment un système de référentiel passif de données en participant actif aux processus métiers. Ils identifient les opportunités et les risques à mesure qu'ils apparaissent, permettant aux entreprises d'agir en temps réel sur les signaux critiques.
### 1.3 Agents d'ambiance
**Définition :** Les agents ambiants sont un type spécifique d'agent proactif qui fonctionne en permanence en arrière-plan du workflow d'un utilisateur sans nécessiter de commandes explicites. Les utilisateurs bénéficient souvent de leurs actions sans être conscients de leur fonctionnement, car elles sont conçues pour augmenter les capacités humaines tout en gardant un profil bas.
**Importance :** L'objectif d'un agent ambiant est de réduire la charge cognitive des utilisateurs en automatisant le « travail sur le travail » banal. Ils augmentent l'efficacité des processus en s'intégrant de façon transparente aux outils que les employés utilisent au quotidien, en capturant et en structurant automatiquement les informations.
### 1.4 Agents autonomes
**Définition :** Les agents autonomes représentent un saut important dans la complexité. Ils ont un objectif général et sont capables de planifier et d'exécuter indépendamment une séquence d'étapes pour atteindre cet objectif. Ils peuvent raisonner, prendre des décisions et même apprendre de leurs actions pour améliorer les performances au fil du temps.
**Importance :** C'est le plus proche d'un véritable employé numérique. Les agents autonomes peuvent se voir déléguer un objectif complexe à plusieurs étapes, par exemple « Générer 50 nouvelles pistes qualifiées dans le secteur manufacturier ce trimestre », et être autorisés à formuler et à exécuter un plan pour l'atteindre.
### 1.5 Agents collaboratifs (essaims d'agents)
**Définition :** Les agents collaboratifs, souvent appelés « essaims d'agents », sont un ensemble d'agents spécialisés qui travaillent ensemble pour résoudre un problème trop complexe pour être traité par un seul agent. Un agent « orchestrateur » ou « principal » décompose souvent une tâche importante, délègue les tâches secondaires aux agents spécialisés appropriés, puis synthétise leurs résultats. Un protocole de communication robuste Agent2Agent (A2A) permet d'y parvenir.
**Importance :** Cette approche reflète une équipe humaine. En décomposant un problème complexe, chaque agent spécialisé peut mettre à profit ses compétences uniques : l'un est spécialisé dans l'analyse des données, un autre dans la communication avec les clients et un troisième dans l'intégration système, pour aboutir à une solution plus robuste et complète.
## Chapitre 2 : Modèles d'architecture Agentforce
Après avoir exploré la taxonomie des agents IA, une question cruciale demeure : comment combiner ces éléments pour résoudre efficacement et de façon fiable des problèmes métiers réels ? Ce chapitre répond à cette question en fournissant un référentiel des modèles de conception d'agents courants. Chaque modèle est une solution éprouvée à un défi récurrent, offrant un avant-projet pour tous les types d'agents, des simples agents à usage unique aux essaims d'agents complexes et collaboratifs.
### 2.1 Modèles d'agent conversationnel
Les agents conversationnels sont souvent la porte d'entrée des capacités IA d'une organisation. Ils se définissent par leur capacité à engager un dialogue dynamique et à plusieurs tours de parole, agissant comme interface principale à travers laquelle les utilisateurs effectuent des tâches et récupèrent des informations en langage naturel. Cette section présente deux recettes essentielles pour élaborer des agents conversationnels, chacune adaptée à un canal spécifique : une pour les échanges rapides et interactifs de clients de messagerie, et une autre pour la nature structurée et asynchrone de la messagerie.
L'intelligence d'un agent conversationnel est dérivée de sa capacité à accéder aux données appropriées et à les raisonner au moment opportun. Ce schéma repose sur une fondation de données sophistiquée qui se connecte aux enregistrements clients, aux articles Knowledge et aux analytiques métiers. Les recettes complètes et réutilisables de ces intégrations sont disponibles au [chapitre 4 : Modèles d'intégration](#chapitre-4--modèles-dintégration-pour-les-agents).
#### 2.1.a Agent conversationnel : Modèle client de messagerie interactive
**Problème**
Les clients interagissent sur de nombreux canaux numériques et attendent des **réponses instantanées, contextuelles et intelligentes.** Les chatbots traditionnels sont **scriptés** ou **invisibles,** ce qui entraîne une faible personnalisation, des escalades précoces vers les humains et des coûts de service élevés.
**Context**
- Votre organisation a un engagement numérique multicanal (WhatsApp, SMS, Slack et Salesforce Experience Cloud).
- Les clients de votre organisation interagissent en [plusieurs langues](https://help.salesforce.com/s/articleView?id=ai.service_agent_considerations.htm&type=5) avec votre organisation.
- Votre organisation doit augmenter les workflows de service et de vente avec des agents qui :
- Extraire à partir de données clients fiables et en temps réel
- Respecter les garde-fous et les exigences de conformité
- Escaladez vers des agents humains uniquement lorsque nécessaire
**Composants clés**
- **Abstraction de canal :** Service Cloud Enhanced Chat (auparavant Messagerie dans l'application et Web) permet à l'agent de communiquer à travers plusieurs canaux via une expérience unique.
- **Agent de service Agentforce :** Le comportement et l'objet de l'agent sont définis par les composants ci-dessous.
- **Rubriques et instructions :** Définit la personne et le motif conversationnel de l'agent pour l'interaction directe de l'utilisateur. Cela comprend sa mission principale (par exemple, « Vous êtes un expert dans la résolution des problèmes de support client »), des instructions pour maintenir un ton empathique et professionnel, et des garde-fous clairs sur la portée des demandes qu'il est autorisé à traiter.
- **Actions :** Actions orientées service qui sont des outils que l'agent utilise pour diagnostiquer et résoudre en temps réel les problèmes des clients. Ces outils sont conçus pour exécuter des tâches telles que vérifier le statut d'une commande, rechercher des solutions dans une base Knowledge ou créer une requête de support directement depuis l'interface conversationnelle.
- **Garde-fous :** Les garde-fous agissent comme un ensemble de règles configurables et de contrôles d'exécution qui limitent le comportement de l'agent. Agit en tant que couche de sécurité qui peut intercepter les invites, valider les actions proposées par l'agent et filtrer sa réponse finale pour empêcher les contenus préjudiciables, appliquer des règles métiers et s'assurer que l'agent opère dans le périmètre qui lui a été attribué.
- **Modèles d'invite :** Modèles réutilisables remplis dynamiquement avec des données CRM live via des champs de fusion ou des données sémantiques de Data 360 RAG Retrievers. Ces modèles permettent aux agents de générer des contenus contextuels et sur la marque pendant que la couche Trust Einstein masque en toute sécurité les informations confidentielles avant l'envoi des instructions au grand livre.
- **Data 360**
- Les composants Data 360, notamment les objets lac de données, les objets modèle de données, le magasin vectoriel et les récupérateurs RAG, offrent à l'agent une vue unifiée de toutes les données d'entreprise pertinentes, depuis les enregistrements clients structurés jusqu'aux articles Knowledge non structurés, garantissant ainsi que les réponses sont précises et ancrées dans le contexte.
- **Service Cloud**
- **Données CRM :** Connecte l'agent à l'historique complet des requêtes, en fournissant un contexte crucial sur les détails du compte, les enregistrements de contact et les autorisations
- **File d'attente Live Agent :** Prise en charge de l'escalade et de l'acheminement vers un agent de service humain avec le contexte complet de la conversation injecté
**Interactions**
1. Le client de votre organisation initie la conversation via un canal.
2. Le message est acheminé vers **Agentforce,** qui détermine la portée (rubriques) et applique des garde-fous.
3. L ' IA compose les réponses en utilisant des **modèles d &apos**; invite, tandis que Flow ou Apex peuvent déclencher une logique back-end.
4. Le contexte est récupéré à partir des **objets Data 360, du magasin vectoriel et du CRM** via le récupérateur RAG.
5. L’IA renvoie une réponse contextuelle.
6. Si l'IA ne parvient pas à résoudre, la conversation s'intensifie vers **Service Cloud Live Agent.**
**Compromis**
| Aspect | Gain | Coût |
|---|---|---|
| Vitesse de réponse | Réponses instantanées toujours activées | Latence de plus de 2 secondes pour les requêtes complexes |
| Précision | Ancré dans des données réelles via RAG | Nécessite un magasin de vecteurs organisé et à jour |
| Évolutivité | Conversations simultanées quasi infinies | Les coûts doivent être optimisés par la mise en cache, la qualification et le filtrage |
| Flexibilité | Gère les requêtes ouvertes | Nécessite une ingénierie d'invite sophistiquée |
| Toucher humain | Les agents de service humain gèrent uniquement les requêtes complexes | Frustration des clients si les seuils d'escalade sont incorrects |
| Diversité des conversations | Un grand nombre d'intentions qui nécessite différentes Knowledge, compétences et outils | Nécessite un ajustement continu des rubriques et des instructions pour optimiser la précision et la latence |
**Composants clés**
- **Canal de messagerie :** Gère la capture des messages entrants, l'analyse de leur contenu et de leurs pièces jointes, et le maintien de la continuité du thread pour activer les conversations asynchrones.
- **Agent SDR Agentforce :** Le comportement et l'objet de l'agent sont définis par les composants ci-dessous.
- **Rubriques et instructions :** Définit la mission de l'agent d'engager et de qualifier les pistes entrantes par la conversation. Cela comprend des instructions pour comprendre les besoins des prospects, recueillir des données importantes sur les qualifications (par exemple, le budget, l'autorité et le calendrier) et guider la conversation vers une étape suivante claire, par exemple planifier une réunion avec un chargé de compte.
- **Actions :** Actions commerciales spécialisées qui permettent à l'agent de gérer le cycle de vie des pistes. Ces outils sont conçus pour exécuter des tâches SDR de base, par exemple enrichir les données des pistes, envoyer des e-mails de suivi basés sur un modèle ou intégrer des systèmes de calendrier pour réserver des appels de découverte.
- **Garde-fous :** Les garde-fous agissent comme un ensemble de règles configurables et de contrôles d'exécution qui limitent le comportement de l'agent. Agit en tant que couche de sécurité qui peut intercepter les invites, valider les actions proposées par l'agent et filtrer sa réponse finale pour empêcher les contenus préjudiciables, appliquer des règles métiers et s'assurer que l'agent opère dans le périmètre qui lui a été attribué.
- **Modèles d'invite :** Modèles réutilisables remplis dynamiquement avec des données CRM live via des champs de fusion ou des données sémantiques de Data 360 RAG Retrievers. Ces modèles permettent aux agents de générer des contenus contextuels et sur la marque pendant que la couche Trust Einstein masque en toute sécurité les informations confidentielles avant l'envoi des instructions au grand livre.
- **Data 360**
- Les composants Data 360, notamment les objets lac de données, les objets modèle de données, le magasin vectoriel et les récupérateurs RAG, offrent à l'agent une vue unifiée de toutes les données d'entreprise pertinentes, depuis les enregistrements clients structurés jusqu'aux articles Knowledge non structurés, garantissant ainsi que les réponses sont précises et ancrées dans le contexte.
- **Sales Cloud**
- **Données CRM :** Connecte l'agent à l'historique complet des requêtes, en fournissant un contexte crucial sur les détails du compte, les enregistrements de contact et les autorisations
- **Planifiez une réunion entre le client et le DTS :** Le transfert SDR Live Agent peut être configuré pour configurer une réunion live en utilisant Tâches et planification de réunions (Actions suivantes).
- **Consignation des activités :** Capturez les événements, les tâches et les activités de messagerie, et associez-les à des pistes, des comptes et des opportunités à la suite des interactions des agents DTS.
**Interactions**
1. Le client envoie et reçoit un e-mail via le canal, qui achemine vers Agentforce.
2. Agentforce applique des rubriques, des actions et des garde-fous pour analyser l'intention.
3. Agentforce rédige des réponses contextuelles en utilisant des modèles d'invite enrichis du contexte CRM et Data 360.
4. Une conversation par e-mail à plusieurs tours continue jusqu'à la résolution ou les consignes de la politique.
5. Pour les pistes qualifiées, Agentforce planifie une réunion et met à jour le CRM.
6. Si l'intention dépasse la portée de l'IA, Agentforce escalade vers Sales Cloud SDR pour une réponse du représentant de service humain.
**Compromis**
| Aspect | Gain | Coût |
|---|---|---|
| Vitesse de réponse | <5 min première réponse (vs. 8 à 24 heures) | Portée initiale moins personnalisée par rapport au téléphone |
| Capacité SDR | Augmentation de 2 à 5 fois de la couverture des pistes | Perte des premiers points de contact d'établissement des relations |
| Cohérence des qualifications | Acquérir de façon asynchrone une couverture budgétaire, d'autorité, de besoin et chronologique (BANT) | Peut manquer des signaux nuancés |
| Précision des contenus | RAG garantit des informations actualisées | Nécessite un produit de vente organisé et une bibliothèque enablement. Multi-tours peut être difficile |
| Conversion des réunions | Conversion nettement plus élevée | Certaines réunions avec des pistes de moindre qualité en cas d'écarts BANT |
| Rentabilité | Plus économique que le DTS humain | Coûts de développement et de maintenance |
**Composants clés**
- **Source de l'événement**
- Événements déclenchés par une action de données après l'ingestion de données externes dans Data 360
- Serveurs MCP Heroku tiers ou Salesforce capables d'envoyer des événements à Salesforce via l'API Salesforce Pub/Sub
- Application externe capable d'envoyer des notifications d'événement via l'API Salesforce Pub/Sub
- **Intergiciel facultatif :** MuleSoft ou Data 360 pour les transformations
- **Agentforce Agent:** Le comportement et l'objet de l'agent sont définis par les composants ci-dessous.
- **Rubriques et instructions :** Spécifie la mission principale de l'agent et ses déclencheurs, y compris la définition de son objectif principal (par exemple, « Surveiller toutes les requêtes prioritaires et empêcher les infractions à l'accord de niveau de service »). Contient les événements ou les conditions de données spécifiques que l'agent doit écouter pour initier ses tâches
- **Actions :** Actions déclenchées par un événement et planifiées conçues pour répondre à des événements externes. Bien que ces actions fonctionnent de façon autonome pour les tâches courantes, elles comprennent souvent la possibilité d'orchestrer des workflows qui impliquent une intervention humaine, une escalade vers les utilisateurs pour révision, approbation ou la gestion de scénarios qui nécessitent un jugement humain.
- **Garde-fous :** Les garde-fous agissent comme un ensemble de règles configurables et de contrôles d'exécution qui limitent le comportement de l'agent. Agit en tant que couche de sécurité qui peut intercepter les invites, valider les actions proposées par l'agent et filtrer sa réponse finale pour empêcher les contenus préjudiciables, appliquer des règles métiers et s'assurer que l'agent opère dans le périmètre qui lui a été attribué.
- **Modèles d'invite :** Modèles réutilisables remplis dynamiquement avec des données CRM live via des champs de fusion ou des données sémantiques de Data 360 RAG Retrievers. Ces modèles permettent aux agents de générer des contenus contextuels et sur la marque pendant que la couche Trust Einstein masque en toute sécurité les informations confidentielles avant l'envoi des instructions au grand livre.
- **Data 360**
- Composants Data 360, y compris des **objets lac de données et** des objets modèle de données, qui stockent les données d'événements [générées par des systèmes externes et envoyées à Salesforce](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-create-eventbusconnector-data-stream.html), transformant et générant des connaissances en continu ou en temps réel
- **Les connaissances calculées, en continu et en temps réel** fournissent aux agents des données immédiates et pertinentes sur les clients. Cela permet de résoudre les problèmes de façon préventive, en atténuant l'escalade. Les **Graphiques de données** exposent proactivement les relations et les connaissances à partir de sources de données diverses, ce qui permet de détecter rapidement les modèles ou les anomalies qui se rapportent à l ' engagement, à l ' activité et au profil des clients.
- Les récupérateurs **Data 360 vector store et RAG** offrent à l ' agent une vue unifiée de toutes les données d ' entreprise pertinentes et des articles Knowledge non structurés, ce qui garantit l ' exactitude et le contexte des réponses.
- **Objectifs d'événement**
- Notifier proactivement les employés ou contacter les clients
- Extensible pour les agents (consultez Modèles d'[agent ambiant](#23-modèles-dagent-ambiant) et d'[agent autonome](#25-modèles-dagent-autonome))
**Interactions**
1. Un changement notable se produit dans le système externe.
2. Le système externe émet un événement et le publie dans Bus d'événement Salesforce via l'API (crée un événement de plate-forme) ou l'API Pub/Sub, ou les données d'événement sont diffusées dans Data 360.
3. Les abonnés à l'événement sont déclenchés. Un flux est déclenché.
4. Le flux appelle [Action de l'agent](https://help.salesforce.com/s/articleView?id=platform.automate_flow_ref_elements_actions_generate_ai_agent_response.htm&type=5) avec les données de l'événement. L'agent détermine le plan d'action approprié et l'exécute.
5. Le résultat est une notification ou un workflow déclenché. Les notifications sont transmises à un utilisateur dans un outil de collaboration (tel que Slack). Des tâches ou des événements sont également générés. De plus, les actions peuvent appeler des systèmes externes. Par conséquent, les événements ne sont pas perdus, mais sont exécutés, signalés et actionnés proactivement, en supprimant les coûts humains ou les automatisations complexes pour les découvrir.
**Compromis**
| Aspect | Gain | Coût |
|---|---|---|
| Intégration en temps réel | Les événements déclenchent des actions en quelques secondes. | Complexité de l'entrée d'API (variabilité du contrat de niveau de service partenaire) |
| Réponse intelligente | Décisions pilotées par l’IA avec le CRM et le contexte externe | L'enrichissement ajoute la latence et des données périmées (telles que des événements hors d'usage). |
| Couplage lâche | Systèmes externes indépendants de la logique Salesforce | Le traitement asynchrone entraîne une éventuelle cohérence. |
| Évolutivité | Gère les événements en rafale | Limites en API, coûts de stockage des événements |
| Bidirectional | Salesforce peut répondre à des systèmes externes. | Dépendances d'API externes, scénarios d'échec |
| Sécurité | Événements vérifiés signés, accès à moindre (ou nul) privilège par des systèmes externes | Protection contre la relecture, rotation des clés et frais généraux opérationnels |
**Composants clés**
- **Couche source Événement**
- Données CRM, Événements de plate-forme, Capture des données de modification (CDC) et Surveillance des événements en temps réel (RTEM) des données d'activité de plate-forme de faible niveau
- **Data 360**
- Composants Data 360, y compris des **objets lac de données et** des objets modèle de données, qui stockent les données d'événements [générées par des événements](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-create-eventbusconnector-data-stream.html) CRM ou de plate-forme, transformant et générant des connaissances en continu ou en temps réel
- Les **connaissances calculées, en continu et en temps réel** fournissent aux agents des données immédiates et pertinentes sur les clients, l'activité des employés ou les modifications des métadonnées dans le système. Cela permet de résoudre les problèmes de façon préventive, en atténuant l'escalade. Cette connaissance de la situation en temps réel permet aux agents d'offrir des interventions en temps opportun pour le débit opérationnel de gouvernance et de conformité.
- **Graphiques de données** faisant apparaître proactivement les relations et les connaissances à partir de différentes sources de données, permettant de détecter à un stade précoce les modèles ou les anomalies pertinents pour l ' engagement, l ' activité et le profil des clients.
- Les récupérateurs **Data 360 vector store et RAG** offrent à l ' agent une vue unifiée de toutes les données d ' entreprise pertinentes et des articles Knowledge non structurés, ce qui garantit l ' exactitude et le contexte des réponses.
- **Agentforce Agent:** Le comportement et l'objet de l'agent sont définis par les composants ci-dessous.
- **Rubriques et instructions :** Spécifie la mission de l'agent qui consiste à appliquer des règles métiers et à automatiser les processus en fonction des modifications des données dans Salesforce. Il définit l'objectif de l'agent (par exemple, « Assurez-vous que toutes les opportunités sont mises à jour avec un contact principal avant d'atteindre l'étape de négociation ») et les créations d'enregistrements spécifiques, les mises à jour de champ, etc., qui déclenchent l'agent.
- **Actions :** Actions déclenchées par un événement et planifiées conçues pour répondre à des événements Salesforce internes. Bien que ces actions fonctionnent de façon autonome pour les tâches courantes, elles comprennent souvent la possibilité d'orchestrer des workflows qui impliquent une intervention humaine, une escalade vers les utilisateurs pour révision, approbation ou la gestion de scénarios qui nécessitent un jugement humain.
- **Garde-fous :** Les garde-fous agissent comme un ensemble de règles configurables et de contrôles d'exécution qui limitent le comportement de l'agent. Agit en tant que couche de sécurité qui peut intercepter les invites, valider les actions proposées par l'agent et filtrer sa réponse finale pour empêcher les contenus préjudiciables, appliquer des règles métiers et s'assurer que l'agent opère dans le périmètre qui lui a été attribué.
- **Modèles d'invite :** Modèles réutilisables remplis dynamiquement avec des données CRM live via des champs de fusion ou des données sémantiques de Data 360 RAG Retrievers. Ces modèles permettent aux agents de générer des contenus contextuels et sur la marque pendant que la couche Trust Einstein masque en toute sécurité les informations confidentielles avant l'envoi des instructions au grand livre.
- **Objectifs d'événement**
- Notifiez proactivement les employés ou contactez les clients.
- Extensible pour appeler d’autres agents (voir [IA ambiante](#23-modèles-dagent-ambiant) et schémas [IA autonomes](#25-modèles-dagent-autonome))
**Interactions**
1. Un changement notable se produit dans le système interne, par exemple une mise à jour d'un enregistrement CRM, une modification des métadonnées ou une action de données déclenchée depuis Data 360.
2. Le système interne émet un événement et le publie dans Bus d'événement Salesforce via l'API (crée un événement de plate-forme) ou l'API Pub/Sub, ou les données d'événement sont diffusées dans Data 360.
3. Les abonnés à l'événement sont déclenchés et activent un Flux ou Apex .
4. Le flux activé ou Apex appelle [Action de l'agent](https://help.salesforce.com/s/articleView?id=platform.automate_flow_ref_elements_actions_generate_ai_agent_response.htm&type=5).
5. Le résultat est une notification ou un workflow déclenché. Les notifications sont transmises à un utilisateur dans un outil de collaboration (tel que Slack). Des tâches ou des événements sont également générés. De plus, les actions peuvent appeler des systèmes externes.
6. Par conséquent, les événements ne sont pas perdus, mais sont exécutés, signalés et actionnés proactivement, en supprimant les coûts humains ou les automatisations complexes pour les découvrir.
**Compromis**
| Aspect | Gain | Coût |
|---|---|---|
| Intégration en temps réel | Les événements déclenchent des actions en quelques secondes. | Des couches supplémentaires peuvent entraîner une latence pour un simple traitement des événements. |
| Réponse intelligente | Décisions pilotées par l’IA avec le CRM et le contexte externe | L'enrichissement ajoute la latence et des données périmées (par exemple, des événements périmés). |
| Couplage lâche | Fan out (plus d'abonnés) et extensible | Le traitement asynchrone entraîne une cohérence entre les abonnés. |
| Évolutivité | Gérer les événements en rafale | Limites en API |
| Sécurité | Couche Trust fournie par la plate-forme | Frais généraux opérationnels non négociables |
| Aspect | Gain | Coût |
|---|---|---|
| Taille de la fenêtre | Fenêtre réduite : latence réduite, accompagnement plus rapide | A également moins de contexte, moins de précision |
| Mode de traitement | Le temps réel présente une opportunité d'assistant immédiate. | Consommateur de ressources |
| Résolution du flux | Un son et une vidéo de haute qualité peuvent avoir une meilleure précision, mais augmenter la latence. | Plus de stockage et de calcul |
| Période de conservation | De grandes quantités de données peuvent être utilisées pour la formation et la conformité. | Plus de coûts de stockage, peut entraîner du bruit |
| Multimodal | Contexte enrichi, compréhension globale | Complexité de la synchronisation |
| Ambience | Peut fournir un support cohérent à l'utilisateur humain | Protection de la vie privée/application des politiques |
| Aspect | Gain | Coût |
|---|---|---|
| Portée | Large ensemble de couvertures d'activité, l'agent peut partager le contexte dans différentes fenêtres modales (e-mail, calendriers, pages d'application) | Coût de calcul |
| Automatisation intelligente | Peut être un module et s'étendre à l'IA totalement autonome et peut éliminer les humains hors de la boucle où la politique est claire | Plus d'évaluation des agents. Risque de faux positifs ou d'erreurs, peut passer inaperçu dans un délai raisonnable |
| Complexité de l'interception | Peut bénéficier des analytiques en temps réel. Par exemple, peut détecter une fraude ou une menace et arrêter les transactions | Besoin d'une synchronisation des workflows d'agents et d'humains |
| Profondeur du contexte | Un contexte plus profond conduit à des décisions intelligentes | Nécessité d'être contextuel |
| Autonomie des agents | Les agents headless travaillent en arrière-plan sans l'invite de l'utilisateur, ce qui réduit les frictions | Moins de transparence dans la prise de décision des agents, plus de pistes d'audit |
| Multi-agents | Les agents headless peuvent travailler ensemble pour former des agents spécialisés | Orchestration headless et complexité supplémentaire |
| Aspect | Gain | Coût |
|---|---|---|
| Surfaces de collaboration natives | Les agents peuvent participer et contribuer immédiatement au flux de travail humain | L'adoption par les utilisateurs nécessite une formation et une activation supplémentaires |
| Partage de contexte bidirectionnel | Les agents peuvent exposer et partager le contexte avec toutes les parties, ce qui rend les informations accessibles à tous. | Les informations confidentielles asymétriques intentionnelles nécessitent des garanties supplémentaires. |
| Collaboration | Les agents permettent la collaboration en temps réel, en fournissant des commentaires immédiats et en accélérant le temps de résolution. | Des résolutions plus rapides signifient un travail plus actif dans la file d'attente pour les humains pouvant entraîner une fatigue |
| Spécialisation | Les agents spécifiques au domaine offrent une assistance de grande valeur. | Augmentation des besoins en contexte limité et de la spécificité du domaine. Complexité pour s'adapter aux changements |
| Observabilité | Fournir un raisonnement, des pistes d'audit, les Évaluations des agents bâtissent Trust | Augmentation des coûts de télémétrie |
| Aspect | Gain | Coût |
|---|---|---|
| Vitesse | Les agents exécutent les tâches en heures, en jours, plutôt qu'en semaines, voire en mois | Nécessite l'activation du fonctionnement autonome de l'agent |
| Autonomie | Les agents réalisent une exécution complète sans intervention humaine | L'intervention est limitée et coûteuse lors de l'exécution |
| Évolutivité | Les agents évoluent aisément | Des limites tarifaires doivent être établies pour empêcher le verrouillage des ressources. |
| Cohérence | Les agents respectent les politiques via des garde-fous | Le traitement des nouveaux scénarios nécessite une inspection pour garantir le résultat correct. |
| Coût | Les agents évitent l'humain dans la boucle | Le processus est coûteux à élaborer |
| Ressources humaines | Les agents libèrent des ressources critiques et expertes | Les experts n'ont pas de visibilité expérientielle par la pratique, ce qui réduit la capacité à identifier les améliorations des processus |
| Contrôle qualité | Peut surveiller et réviser | Les coûts de correction sont élevés si les erreurs des agents ne sont pas détectées immédiatement |
| Précision | Les agents peuvent utiliser le contexte et les politiques pour prendre la bonne décision. | Le contexte et les données doivent être organisés et conservés afin d'éliminer toute ambiguïté ou vétusté. |
-
Configurez un agent conversationnel.
Configuration de Chat avancé → Créer agent de service → Rubrique Définir des commandes de support → Action Créer Obtenir une commande ↓ Ajouter un flux Omni-Channel d'escalade sortante ← Créer une rubrique Escalader ← Ajouter des actions à des rubriques ← Action Créer Obtenir le statut ↓ Publier l'agent - Configurez Chat avancé comme point d'entrée de chat de Jane pour qu'elle ouvre la fenêtre Agentforce sur la page Web.
- Activez Agentforce et créez un agent de service dans Agentforce Builder pour gérer les conversations et déclencher des actions personnalisées.
-
Définissez une rubrique Commandes de support avec une description et des instructions pour que l'agent reconnaisse naturellement « Où est ma dernière commande ? ».
-
Créer des actions personnalisées pour les agents :
- Action Obtenir la dernière commande de contact pour récupérer la commande la plus récente de Jane
- Action Obtenir le statut d'expédition par ID de commande pour récupérer les informations de suivi via MuleSoft
- Vous pouvez également orchestrer les deux actions dans Flux (récupérer la dernière commande et appeler MuleSoft) en utilisant des actions de service externes.
- Ajoutez les deux actions à l'agent de service dans le générateur, liez-les à la rubrique Commandes et suivi, puis publiez.
-
Créer des actions personnalisées pour les agents :
-
Définissez une rubrique Escalade avec une description à escalader pour un agent de service.
- Créez et activez un flux Omni-Channel sortant.
- Ajoutez-le à l'onglet Connexions du générateur pour l'escalade avec un message d'escalade.
-
Configurez Omni-Channel.
Configuration d'Omni-Channel → Définir des règles d'escalade dans des instructions → Définir les priorités et la capacité → Tester et valider - Activez l'escalade transparente vers les agents de services sociaux lorsque l'agent IA ne peut pas résoudre la requête. Configurez l'acheminement Omni-Channel pour attribuer des chats aux agents de service et transférer la transcription complète pour le contexte.
- Intégrez une logique d'escalade dans les instructions Agentforce et une action d'escalade pour indiquer à l'agent quand transférer des requêtes complexes. Gérez les priorités et capacités d'acheminement via Omni Supervisor.
- Testez l'expérience complète : Jane ouvre le chat et l'agent l'accueille, identifie sa commande, récupère les données d'expédition et escalade de façon transparente lorsqu'une intervention humaine est requise (consultez également Activation des journaux d'événements avancés).
-
Configurez l'intégration de données.
Mapper les données de contexte → Création d'identifiants d'API MuleSoft → Enregistrer le service externe MuleSoft - Ancrez l'agent avec le contexte Salesforce de Jane en mappant ses enregistrements de contact et de commande via un chat authentifié ou des formulaires préalables au chat.
- Connectez Salesforce en toute sécurité à l'API d'expédition MuleSoft en utilisant des identifiants externes et des identifiants nommés pour l'authentification.
- Si MuleSoft expose une spécification OpenAPI, enregistrez-la en tant que service externe afin que Flow et l'agent puissent l'appeler par déclaration.
-
Configurez l'intégration de données non structurées.
- Créez une bibliothèque de données dans Configuration. Nommez-le « Politique de commande et d'expédition ».
- Ajoutez les fichiers PDF des documents de politique qui contiennent les exceptions de la politique d'expédition.
- En arrière-plan, les documents sont automatiquement segmentés, indexés et prêts à l'emploi.
-
Configurez un événement Panier d'achat abandonné pour le déclencher lorsque John, un client VIP, laisse le panier abandonné.
Créer un champ Contact personnalisé → Définir un nouvel événement de plate-forme - Créez un événement de plate-forme
Cart_Abandoned__e avec les champs ID de contact, Valeur du panier d'achat, Date/heure de dernière mise à jour du panier d'achat et Détails du panier d'achat. - Configurez l'événement d'abandon : En utilisant Commerce Cloud, créez un événement de plate-forme pour les notifications d'événement Checkout. L'abandon est détecté lorsque l'état de la session de panier Checkout est dans un état intermédiaire et que la session expire après un seuil. Alternativement, si votre e-commerce est un système externe, publiez l'événement dans Salesforce en utilisant l'une des méthodes suivantes : Flux, Apex, API Salesforce, ou API Pub/Sub.
- Dans l'objet Contact, créez un champ,
Customer_Tier__c , avec les valeurs de liste de sélectionStandard ,Premium etVIP .
- Créez un événement de plate-forme
-
Configurez l'ingestion de données non structurées dans Data 360 : Ajoutez à Data 360 via Amazon S3 un document de politique de remise provenant d'un référentiel de documents.
Créer des identifiants AWS S3 → Créer un flux de données S3 → Configurer et déployer un flux → Créer index de recherche ↓ Fonction de récupération de test ← Configurer et déployer l'index - Créez des identifiants externes pour accéder à S3 : Créez une nouvelle série de clés et de secrets d'accès pour un utilisateur IAM ou IAM Amazon Resource Name (ARN) pour un fournisseur d'identité.
- Créez un flux de données S3 : Sous l'onglet Flux de données, créez le flux de données Flux de documents de politique, sélectionnez la source S3, choisissez le type de fichier PDF, définissez la fréquence d'actualisation, mappez les champs de métadonnées (nom et taille du fichier), puis déployez.
- Une fois le flux de données terminé, créez un index de recherche : Utilisez l'extraction de passage pour la segmentation, le modèle d'incorporation E5-large-v2 et le type de recherche hybride, puis déployez l'index.
- Testez la fonction de récupération créée.
-
Configurez l'agent de récupération du panier d'achat VIP.
Créer un agent à partir d'un modèle → Rubrique Ajouter Récupérer le panier d'achat VIP → Ajouter des instructions de rubrique → Action Créer une alerte Slack ↓ Ajouter des actions à la rubrique ← Action Créer une inscription au parcours ← Action Créer une offre de remise ← Créer une tâche de récupération de panier d'achat - Créez un agent à partir du modèle Agentforce Employee Agent.
- Ajoutez une nouvelle rubrique, Récupérer le panier d'achat VIP, avec la description que cet agent gère les abandons de panier d'achat importants pour les clients VIP.
- Ajoutez des instructions de rubrique pour valider le statut VIP, qualifier le panier d'achat, notifier le responsable de compte dans Slack, recommander une offre de remise et inscrire le client au parcours d'e-mail de récupération du panier d'achat.
- Créez des actions et une tâche.
- Action Alerter le responsable de compte : Envoie une notification Slack proactive
- Tâche Récupérer le panier d'achat abandonné, attribuée au responsable avec les détails du panier d'achat
- Action Obtenir une offre de remise : Analyse la politique et l'historique des achats précédents. Créez un modèle d'invite avec un ancrage, référencez la fonction de récupération dans le modèle d'invite et utilisez les données.
- Inscrivez-vous à l'action Journey de récupération : S'inscrit au parcours de récupération Marketing Cloud via l'API et prend en compte toutes les données des abonnés et l'e-mail d'offre à prix réduit généré par l'agent.
- Ajoutez les actions à la rubrique.
- Créez un parcours de récupération de panier d'achat VIP en utilisant des modèles dans Marketing Cloud ou créez un parcours.
-
Connectez un événement de plate-forme pour appeler l'agent.
Créer un flux déclenché par un événement → S'abonner à l'événement de plate-forme → Action invocable Ajouter un agent → Transmettre les données d'événements à un agent - Créez un flux déclenché par un événement de plate-forme, VIP Cart Abandonment Recovery.
- Sélectionnez l'événement Panier d'achat abandonné auquel le flux doit s'abonner.
- Configurez une action invocable d'agent personnalisé dans Flow Builder, puis sélectionnez l'agent VIP Cart Recovery. Envoyez la demande d'initier une récupération de panier d'achat abandonné VIP pour le client et envoyez la charge de travail de l'événement de plate-forme.
| Le client abandonne son panier | → | Commerce Cloud publie un événement | → | Flux de déclencheurs d'événement de plate-forme | → | Flux invoque Agent employé |
| ↓ | ||||||
| Analyse l'offre de remise | ← | Crée une tâche pour le responsable | ← | Gestionnaire d'alertes dans Slack | ← | L'agent exécute la rubrique Récupération |
| ↓ | ||||||
| Inscrit le client au parcours | → | Le client échange l'offre | → | L'agent analyse le résultat pour recueillir des commentaires |
-
Configurez un agent Sales Call Realtime Response.
Créer un agent à partir d'un modèle → Rubrique Ajouter un appel d'assistance → Ajouter des instructions de rubrique → Action Créer une analyse de transcription ↓ Ajouter des actions à la rubrique ← Action Créer des connaissances Slack ← Action Créer une spécification de produit - Créez un agent à partir du modèle Agentforce Employee Agent.
- Ajoutez une nouvelle rubrique, Appel d'assistance, avec la description indiquant que cet agent écoute les transcriptions en direct, comprend l'intention et aide à consulter les données des produits.
- Ajoutez des instructions de rubrique pour analyser les transcriptions, récupérer les spécifications des produits et envoyer des messages Slack.
- Créez des actions.
- Action Analyser la transcription des appels : Analyse en temps réel les données des transcriptions d'appels reçues et extrait les principales questions ou actions
- Action Obtenir les spécifications du produit : Interroge les articles Knowledge des produits
- Envoyer des connaissances Slack à l'utilisateur "interne"
- Ajoutez les actions à la rubrique.
-
Configurez une bibliothèque de données Product Knowledge.
Créer une bibliothèque de données → Ajouter des articles Knowledge → Segments et index système → Bibliothèque au sol en action - Créez une bibliothèque de données dans Configuration. Nommez-le "Product Knowledge".
- Ajoutez les articles Knowledge qui contiennent les informations sur le produit.
- En arrière-plan, les documents sont automatiquement segmentés, indexés et prêts à l'emploi.
- Utilisez l'ancrage dans l'action Obtenir les spécifications du produit.
-
Publiez la transcription en temps réel dans Salesforce via l'API Pub/Sub.
Le serveur reçoit la transcription audio → Le serveur publie un événement de plate-forme - Créez un événement de plate-forme,
Transcript_Segment__e , avec les champsID d'appel ,Séquence ,Haut-parleurs ,Heure de début du segment,Heure de fin du segment,Durée etDonnées de transcription . - Dans votre serveur de signalisation (consultez la section prérequise), lorsque vous recevez le texte transcrit de l'audio, publiez immédiatement les données via l'événement
Transcript_Segment__e . Vous pouvez publier l'événement dans Salesforce en utilisant l'une des méthodes suivantes : Flux, Apex, API Salesforce, ou API Pub/Sub.
- Créez un événement de plate-forme,
-
Flux wire pour vous abonner à l'événement
Transcript_Segment__e publié.Créer un flux déclenché par un événement → Événement S'abonner à la transcription → Action invocable Ajouter un agent → Envoyer la charge utile à l'agent ↓ Un agent envoie Slack DM - Créez un flux déclenché par un événement de plate-forme, Discovery Call Insights.
- Sélectionnez l'événement
Transcript_Segment__e auquel le flux doit s'abonner. - Configurez une action invocable d'agent personnalisé dans Flow Builder, puis sélectionnez l'agent Sales Call Realtime Response. Envoyez la charge de travail de l'événement à la rubrique Appel d'assistance. Une fois la question dérivée de la rubrique, la question est envoyée à l'action Obtenir les spécifications du produit pour obtenir une réponse.
- La réponse finale est compilée et envoyée immédiatement à l'utilisateur via un DM Slack.
| L'utilisateur démarre l'appel Zoom | → | Le serveur transcrit et publie | → | Le flux invoque l'agent Response | → | L'agent interroge Knowledge base |
| ↓ | ||||||
| Analytics affine les performances des agents | ← | L'agent compile un résumé des appels | ← | L'agent continue d'écouter | ← | Un agent envoie Slack DM |
-
Configurez l'architecture multi-agents.
Un agent de recherche recueille des renseignements → Piste de score de l'agent de qualification → L'agent SDR commence la sensibilisation - Agent de recherche : Interroge Data 360 et des sources externes via MuleSoft
- Agent de qualification : Priorise, évalue et enrichit les pistes
- Agent SDR : Récupère les attributions de pistes, effectue la sensibilisation, assure le suivi et planifie des réunions. Suivez l'activité et la progression des agents DTS avec Agentforce Analytics pour agent DTS.
-
Découvrez et ingérez de nouvelles données d'entreprise.
Créer un espace de données → Ingestion de données Salesforce CRM → Ingestion de données ZoomInfo → Ingestion des données de la base de données des fournisseurs - Configurez un nouvel espace de données appelé Ventes et marketing. Ce nouvel espace de données contiendra toutes les données nécessaires aux agents autonomes.
- Utilisez des connecteurs Salesforce pour transmettre les données Piste, Compte, Contact et Opportunité CRM dans l'espace de données.
- Configurez un connecteur Data 360 pour ZoomInfo. Fluxez les données vers l'espace de données Data 360 Sales and Marketing.
- Configurez le connecteur Anypoint Salesforce Data 360 pour vous connecter à la base de données des fournisseurs et ingérer les données dans Data 360.
-
Configurez un événement de plate-forme pour initier l'agent Recherche et qualification headless.
Créer un événement de plate-forme - Créez un événement de plate-forme
AgentGoal__e avec l'objectif de champ qui capture l'objectif général de l'utilisateur humain.
- Créez un événement de plate-forme
-
Configurez un agent Orchestrateur d'objectif, un agent d'IA conversationnelle qui reçoit l'objectif de l'utilisateur et l'orchestre avec d'autres agents.
Créer un agent à partir d'un modèle → Rubrique Ajouter un objectif d'analyse → Ajouter des instructions de rubrique → Action Créer un événement d'objectif ↓ Ajouter une action à la rubrique - Créez un agent à partir du modèle Agentforce Employee Agent.
- Ajoutez une nouvelle rubrique, Objectif d'analyse, avec la description indiquant que cet agent comprend l'intention de l'objectif et peut appeler des agents supplémentaires si nécessaire.
- Ajoutez des instructions de rubrique pour analyser l'objectif et déclencher des événements pour d'autres agents.
- Créez un événement Objectif,
ObjectifAgent__e .
-
Configurez un agent Recherche et qualification des pistes, qui est déclenché par un agent orchestrateur.
Créer une rubrique Recherche → Action Créer une déduplication → Action Créer un enrichissement de piste → Action Créer un score de piste ↓ Ajouter des actions à la rubrique ← Action Créer une qualification de piste - Créez une rubrique Recherche de prospects avec la description "Recherche de nouvelles pistes dans une région ou un état".
- Créez des actions.
- Action Apex Dédupliquer la piste : Vérifier et valider les nouvelles pistes par rapport aux clients existants
- Action Apex Enrichir les pistes, qui utilise un modèle d'invite : Examine les connaissances marketing non structurées et les données de la base de données des fournisseurs pour enrichir les données des pistes
- Action Score Piste : Score proactif d'une piste avec des données de piste mises à jour
- Action Qualifier la piste pour l'agent : En fonction du score, attribuez des paramètres qui qualifient la piste pour un agent DTS
-
Configurez un agent SDR Agentforce pour effectuer la sensibilisation, l'entretien des pistes et la planification de réunions.
Créer un agent SDR à partir d'un modèle → Configurer l'agent Knowledge base → Configurer les paramètres de messagerie des agents → Définir des règles d'attribution de pistes ↓ Définir des critères de piste qualifiants - Créez un agent DTS depuis la page Configuration en utilisant le modèle Agent principal préconfiguré. Configurez les paramètres de messagerie et les règles d'attribution de piste, en sélectionnant l'objet Piste ou l'objet Contact, puis en définissant les critères qualifiants (score de piste de seuil et nouvelle piste) pour les règles d'attribution.
- Configurez Agentforce Lead Nurturing en configurant l'agent, en attribuant des autorisations, et en configurant les règles de cadence et d'attribution.
- Configurez Knowledge nécessaire pour permettre à l'agent de DTS de répondre aux questions.
-
Configurez un nouveau flux pour vous abonner à l'événement publié
AgentGoal__e .Créer un flux déclenché par un événement → Événement S'abonner à l'objectif de l'agent → Action invocable Ajouter un agent - Créez un flux déclenché par un événement de plate-forme intitulé Acheminer les objectifs vers les agents.
- Sélectionnez l'événement Objectif de l'agent auquel le flux doit s'abonner.
- Configurez une action invocable d'agent personnalisé dans Flow Builder, puis sélectionnez l'agent Recherche et qualification des pistes.
| L'utilisateur attribue un objectif général | → | L'agent Orchestrateur crée un événement | → | Le flux achemine l'objectif vers l'agent | → | Un agent de recherche qualifie une piste |
| ↓ | ||||||
| Surveillance des agents avec Analytics | ← | L'agent SDR planifie une réunion | ← | L'agent SDR commence la sensibilisation |
- Configurez Chat avancé comme point d'entrée de chat du client pour lui permettre d'ouvrir la fenêtre Agentforce sur la page Web.
-
Configurez un Agentforce Billing, un agent spécialisé headless qui peut prendre une commande ou une facture et effectuer une enquête de facturation.
Créer un agent à partir d'un modèle → Définition d'une rubrique d'enquête de facturation → Action Créer un flux personnalisé → Ajouter une action à la rubrique - Activez Agentforce et créez un Agent Employé à partir du modèle Agentforce Agent Employé.
- Définissez une rubrique, Demande de facturation, avec la description « Enquêter sur les écarts de facture, les problèmes de paiement et les erreurs de facturation ».
- Ajoutez une action de flux personnalisée, Vérifier les écarts de facture, avec une entrée
Numéro de facture ,ID de client etPlage de dates , et une sortieMontant des écarts ,Cause première etTransactions affectées .
- Ajoutez une action de flux personnalisée, Vérifier les écarts de facture, avec une entrée
-
Configurez un Agent logistique Agentforce, un agent spécialisé headless capable de vérifier les expéditions, de suivre les expéditions et de vérifier l'inventaire.
Créer un agent à partir d'un modèle → Définition de la rubrique Vérification de l'expédition → Action Créer un flux personnalisé → Ajouter une action à la rubrique - Activez Agentforce et créez un Agent Employé à partir du modèle Agentforce Agent Employé.
- Définissez une rubrique : Vérification de l'expédition, avec une description pour vérifier l'expédition pour facture.
- Ajoutez une action de flux personnalisée, Vérifier les détails d'expédition, avec une entrée
Numéro de facture ,ID de client etPlage de dates , et une sortiePièce expédiée ,Date etStatut d'inventaire .
- Ajoutez une action de flux personnalisée, Vérifier les détails d'expédition, avec une entrée
-
Configurez un Agent de provisionnement Agentforce, un agent spécialisé headless capable de vérifier le provisionnement et le statut de service.
Créer un agent à partir d'un modèle → Définir la rubrique Contrôle de service → Action Créer un flux personnalisé → Ajouter une action à la rubrique - Activez Agentforce et créez un Agent Employé à partir du modèle Agentforce Agent Employé.
- Définissez une rubrique, Contrôle du service, avec une description pour vérifier la connectivité du service et le statut du compte.
- Ajoutez une action de flux personnalisée, Vérifier le service, avec une entrée
ID de client etID d'actif , et une sortieStatut du service etMotif de l'exception de service.
- Ajoutez une action de flux personnalisée, Vérifier le service, avec une entrée
-
Exposer les agents de facturation, de logistique et de provisionnement en tant que serveurs A2A, puis les enregistrer dans le Registre des agents.
Exposer les agents via MuleSoft → Enregistrer les agents dans le registre - En l ' absence d ' un support direct de l ' A2A sur les agents Agentforce, des connecteurs MuleSoft peuvent être utilisés pour exposer les API des agents en tant que serveurs A2A.
- Enregistrez ces serveurs A2A dans Registre des agents.
- Utilisez Anypoint Agent Fabric pour l'orchestration des agents.
- MuleSoft Agent Broker peut vous aider à orchestrer n'importe quel agent à travers les plates-formes en fonction des capacités des agents mentionnées dans les cartes de l'agent.
-
Configurez un Agent d'aide Agentforce, un agent d'IA conversationnelle qui interagit avec les clients, évalue la complexité et coordonne avec plusieurs agents spécialisés pour résoudre le problème.
Créer Agent de service → Définir la rubrique Investigation → Action Créer une notification → Définir la rubrique Orchestration ↓ Définir la rubrique Escalade ← Action Créer Créer une requête ← Action Créer un agent d'appel ← Créer un flux d'orchestration d'agent ↓ Créer un flux Omni-Channel → Connecter le flux pour l'escalade - Activez Agentforce et créez un agent de service dans Agentforce Builder pour gérer les conversations et déclencher des actions personnalisées.
- Définissez une rubrique, Enquête de service, avec une description et des instructions afin de permettre à l'agent de reconnaître naturellement une rubrique complexe contenant généralement plusieurs problèmes simultanés.
- Créez des actions personnalisées.
- Action Notification de statut pour reconnaître le problème et fournir des mises à jour sur la progression
- Créez des actions personnalisées.
- Définissez une rubrique Orchestration qui peut appeler d'autres agents via des actions.
- Créez une action Agent d'appel qui appelle une action Flux. L'action Flux contient plusieurs actions d'agent et peut initier chacun des agents headless : l'agent de facturation, l'agent logistique et l'agent de provisionnement.
- Créez une action Créer une requête qui crée une requête, ajoute des détails et définit le statut.
- Définissez une rubrique Escalade avec une description à escalader pour un agent de service.
- Créez et activez un flux Omni-Channel sortant.
- Ajoutez-le à l'onglet Connexions de l'agent pour l'escalade avec un message d'escalade.
| Agent d'aide Agentforce | → | MuleSoft Agent Broker | → | Agent de facturation en tant que serveur A2A | → | Agent logistique en tant que serveur A2A |
| ↓ | ||||||
| Réponse de l'agent d'aide | ← | Réponse du courtier agrège | ← | Agent d'acquisition en tant que serveur A2A |
| Le client démarre le chat | → | Le client déclare plusieurs problèmes | → | L'agent examine les détails de la commande | → | Orchestrateur appelle des agents spécialisés |
| ↓ | ||||||
| Orchestrateur synthétise un plan de résolution | ← | L'agent de provisionnement détecte un problème | ← | L'agent logistique confirme l'erreur | ← | L'agent de facturation constate une divergence |
| ↓ | ||||||
| Agent escalade en agent de service | → | Un agent de service offre une résolution | → | L'agent système exécute les tâches | → | L'agent met à jour et ferme la requête |
**Recette 1 :** **Activation des outils externes avec MCP**
**Problème**
Les organisations fonctionnent à la fois avec des systèmes ERP hérités et SaaS modernes, mais leur intégration à un agent est difficile, car il n'existe pas de protocole commun : chaque outil a ses propres API, authentification et modèle de données. Les développeurs finissent par élaborer et gérer des connecteurs point à point personnalisés pour chaque outil, produisant des intégrations fragiles, non évolutives et coûteuses.
**Modèle**
L'agent invoque un outil externe (exposé via MCP) via une action structurée, lui permettant d'utiliser des outils spécialisés au-delà de la plate-forme Salesforce.
**Context**
- L'agent agit en tant que proxy pour une série d'outils qui existent hors de Salesforce Platform.
- Ces outils externes peuvent avoir divers API, mécanismes d'authentification et formats de données.
- Un protocole de communication normalisé est requis pour permettre une interaction transparente entre l'agent et ces outils externes.
- La réutilisation est une préoccupation majeure, car les mêmes outils externes peuvent être utilisés par plusieurs agents à des fins différentes.
**Interactions**
1. **Déclencheur :** Une requête utilisateur ou un événement interne à Agentforce nécessite l'utilisation d'un outil externe.
2. **Intention d'agir :** L'agent Agentforce identifie l'intention et détermine qu'un outil externe basé sur MCP est requis.
3. **Planificateur (interne) :** Le planificateur de l'agent Agentforce sélectionne l'outil ou l'action MCP approprié en fonction de ses instructions configurées et des outils disponibles.
4. **Exécution :** L'agent Agentforce envoie une requête conforme MCP au serveur MCP externe (par exemple, via un appel Apex à un point de terminaison MuleSoft, qui achemine ensuite vers le serveur MCP externe).
5. **Traitement externe :** Le serveur MCP externe traite la requête, interagit avec l'application externe sous-jacente et prépare une réponse conforme MCP.
6. **Résultat**: Le serveur MCP externe renvoie la réponse à l'Agentforce Agent.
7. **Suivi :** L'Agent Agentforce traite la réponse, met à jour son état interne et poursuit sa tâche ou fournit des commentaires à l'utilisateur.
**Compromis**
| Aspect | Gain | Coût |
|---|---|---|
| Flexibilité | Accès à diverses capacités externes | Développement initial pour la couche serveur/intégration MCP |
| Modularité | Les capacités des agents sont découplées des outils externes | Nécessite une conception d'API et une gestion des versions soignées |
| Évolutivité | Utilise l'évolutivité du système externe | Les performances du système externe deviennent une dépendance |
| Standardization | Protocole normalisé (MCP) | Adoption et/ou wrapper |
| Sécurité | Sécurité centralisée pour l'accès externe | Gestion des identifiants et des stratégies d'accès pour les systèmes externes |
| Maintenabilité | Les mises à jour des outils externes ne nécessitent pas de modification de l'agent. MCP peut signaler des changements | Coût des changements fréquents |
| Aspect | Gain | Coût |
|---|---|---|
| Vitesse | Un appel d'outil | Plus de frais généraux de gouvernance |
| Idempotence et sécurité | Essais en toute sécurité | Mise en œuvre pour soutenir la dédupe et l'idempotency |
| Évolutivité | Peut évoluer facilement | Frais généraux de connexion |
| Cohérence | Clair et explicite | Atomique |
| Sécurité | Des garde-fous et des politiques peuvent être mis en œuvre. | Frais généraux d'exploitation pour cascader les changements de politique |
| Observabilité | La corrélation et l'audit sont disponibles pour l'exploitation. | Augmentation des coûts de télémétrie |
| Aspect | Gain | Coût |
|---|---|---|
| Vitesse | Un appel pour plusieurs opérations distribuées | Développement et frais généraux opérationnels |
| Idempotence et sécurité | Sécurité des tentatives / prise en charge SAGA | Complexité |
| Évolutivité | Peut évoluer facilement, peut être asynchrone | Cohérence éventuelle pour Async |
| Sécurité | Stratégies dans la couche API | Frais généraux d'exploitation pour cascader les changements de politique |
| Observabilité | Corrélation et audit disponibles pour le traçage | Augmentation des coûts de télémétrie |
| Aspect | Gain | Coût |
|---|---|---|
| Mouvement de données | Aucun; zéro copie | Calculer le coût |
| Latence | Des jours ou des semaines en temps quasi réel | SLA |
| Évolutivité | Volume de données illimité | Calculer le coût |
| Aspect | Gain | Coût |
|---|---|---|
| Latence | Disponible en quelques secondes | Coût de calcul et d'implémentation |
| Couplage | Les producteurs sont indépendants des consommateurs. | Plus difficile à déboguer et à tracer |
| Évolutivité | Peut évoluer | Limites |
| Commande | Élaboration du contexte incrémentiel | Arrivée hors commande |
| Valeur | Connaissances en temps quasi réel | Frais généraux de gouvernance et de conformité |
| Aspect | Gain | Coût |
|---|---|---|
| Précision | Higher Trust (réponses ancrées avec citation) | Conservation et hygiène des documents |
| Récupération | Gère le langage naturel et les mots-clés | Plus de stockage, effort de réglage |
| Sécurité | Peut imposer l'accès privilégié | Exécution, complexité du cache |
| Chunking | Meilleure pertinence | Prétraitement et réglage supplémentaires |
| Versioning | Filtre Knowledge obsolète | Coûts de maintenance et de gouvernance |
| Aspect | Gain | Coût |
|---|---|---|
| Précision | Higher Trust (réponses ancrées avec des relations vérifiables) | Harmonisation des données et effort de modélisation des graphiques |
| Récupération | Gère les requêtes relationnelles complexes | La traversée de graphiques peut coûter cher en calcul pour des graphiques très volumineux |
| Sécurité | Peut appliquer l'accès privilégié basé sur les relations | Frais généraux d'exécution, contrôle d'accès complexe |
| Profondeur du contexte | Compréhension riche et globale des entités et de leurs connexions | Prétraitement et réglage supplémentaires pour l'optimisation des graphiques |
| Maintenabilité | Modèle de données centralisé pour les relations | Alignement continu des objets modèle de données avec l'évolution des besoins métiers |
**Découvrez :** Le Registre des agents fournit un catalogue centralisé de tous les agents et outils IA de l'organisation. Il permet de découvrir et de réutiliser des actifs construits en interne, incorporés au SaaS et externes. En fournissant une source de preuve unique pour tous les actifs agents, le Registre des agents élimine la redondance et permet aux développeurs d'exploiter les capacités existantes à grande échelle.
**Orchestre :** MuleSoft Agent Broker est une solution d'acheminement intelligente qui mappe dynamiquement les tâches avec l'agent ou l'outil le plus adapté. Propulsé par le grand livre de votre choix, il se coordonne entre les agents et les outils pour s'assurer que les requêtes complexes à plusieurs étapes et les processus métiers sont exécutés avec une grande fiabilité et des résultats traçables.
**Gouverner :** [MuleSoft Agent Governance](https://www.mulesoft.com/platform/ai/ai-agent-governance) utilise Flex Gateway et sa prise en charge du [Model Context Protocol (MCP)](https://www.mulesoft.com/platform/ai/model-context-protocol) et du [protocole Agent2Agent (A2A)](https://www.mulesoft.com/platform/ai/a2a-support). Avec Flex Gateway, les entreprises peuvent appliquer des politiques de sécurité et de conformité à chaque interaction agent-agent et agent-outil.
**Observer :** Agent Visualizer offre une observabilité en temps réel grâce à une carte dynamique et interactive des interactions des agents. Il suit les décisions, surveille l'intégrité du système, permettant ainsi une optimisation continue et une surveillance fiable de l'ensemble de l'écosystème des agents.
Agent Fabric défend une approche YAML (spécification-first) dans laquelle les utilisateurs définissent des réseaux d'agents via un descripteur de métadonnées (le « fichier YAML »). Ce fichier YAML est agnostique pour MuleSoft et il dissocie la définition du réseau de l'agent de son exécution.
## Spécification du réseau d'agents (descripteur de métadonnées)
Chaque réseau d'agents (YAML) définit une zone fonctionnelle spécifique avec ses actifs agents, y compris leurs règles et politiques opérationnelles. Le YAML est utilisé pour activer les quatre piliers de tissu Agent :
1. Découvrez : Remplissez le Registre des agents avec les actifs agents existants tels que :
1. Agents déployés sur diverses plates-formes (MuleSoft ou autres)
2. Serveurs MCP
3. Fournisseurs de LLM
2. Orchestration : Création de courtiers agents pour l'orchestration
3. Gouverner : Appliquer des politiques sur les actifs pour la sécurité et la gouvernance
4. Observez : Définissez et réutilisez des connexions aux actifs définis. De plus, les capacités d'observabilité et de surveillance sont disponibles pour les réseaux d'agents.
### Création
Le parcours utilisateur commence dans le Générateur de code Anypoint. Utilisez la nouvelle commande disponible via la palette de commandes appelée « MuleSoft : Create an Agent Network Project » pour créer un projet. Cette commande crée un nouveau projet (le ‘Réseau d'agents’) contenant deux fichiers.
- **agent-network.yaml :** Ce fichier définit la configuration du système multi-agents, qui active l'orchestration des agents IA avec des outils externes (via MCP) et des agents (via le protocole A2A). Ce format fournit une méthode déclarative pour définir les capacités, les dépendances et les intégrations des agents.
- **exchange.json:** Tous les projets de réseau d'agents ont également un fichier exchange.json. Ce fichier contient les métadonnées des actifs disponibles dans Anypoint Exchange après la publication des actifs de votre réseau d'agents.
Le développement de votre réseau d'agents suit un cycle de vie de développement logiciel (SDLC) standard comprenant quatre étapes principales :
1. **Configuration de l'environnement :** Configuration de l'environnement d'exécution et des passerelles
2. **Création et conception de projets**: Spécification du projet Créer un réseau d'agents
3. **Élaboration et publication :** Élaborer et publier des actifs dans le Registre des agents
4. **Déploiement :** Déployer ou promouvoir le réseau d'agents dans un environnement donné
Après avoir élaboré le projet et généré l'application et les actifs MuleSoft requis, rendez-les disponibles dans Exchange. Dans le Générateur de code Anypoint, déclenchez le processus d'élaboration et de publication en utilisant **_« MuleSoft : Publish Agent Broker Project to Exchange »_** disponible via la palette de commandes.
L'étape de publication transforme chaque actif agent du fichier YAML en spécification A2A, MCP ou LLM, puis la publie dans Exchange.
De plus, le système **publie** le YAML dans Exchange en utilisant un nouveau type d'actif réseau-agent. Vous pouvez **afficher** cet actif dans l'interface utilisateur du Registre des agents et le **rechercher** via l'API Exchange.
### Exemple
Consultez un [fichier Réseau d'agents](https://docs.mulesoft.com/anypoint-code-builder/af-project-files) qui définit un réseau d'agents pour une entreprise. Ce réseau d'agents active le réseau pour l'exécution de commandes dans Salesforce, Stripe, un autre agent d'exécution de commande et le serveur MCP d'inventaire avec une expérience unique et régie par la politique.
- **Découvrir**
Publiez des agents et des outils existants (tels que Salesforce, Stripe, Exécution de commande et Inventaire) en tant qu'actifs Exchange pour les réutiliser. Également la définition d'exécution de commande (YAML) qui est basée sur des versions et partageable, ce qui permet une adaptation rapide pour les rôles, les régions ou les filiales sans reconstruire les flux.
- **Orchestrer**
Un courtier agent utilise un grand livre pour décomposer le processus d'exécution de commande en une séquence de tâches, par exemple vérifier les détails du client, allouer l'inventaire et calculer les frais d'expédition. Il exécute ensuite ce workflow en appelant les agents MCP et A2A, s'assurant que les approbations humaines dans la boucle sont demandées dès que nécessaire.
- **Gouverner**
Anypoint Flex Gateway applique automatiquement l'authentification, l'accès aux moindres privilèges et les garde-fous. Les stratégies du Gestionnaire d'API garantissent des contrôles cohérents entre tous les appels et tous les échanges de données.
- **Observer**
La surveillance et les traces offrent une visibilité complète sur la progression, les échecs et la latence. La visualisation montre les agents qui ont interagi et où des blocages se sont produits.
- **Confiance et conformité**
Les identifiants centralisés, les pistes d'audit et l'héritage des polices prennent en charge la sécurité, la confidentialité et les exigences réglementaires (traitement des informations d'identification personnelle, approbations et séparation des tâches).
Le diagramme montre les différents nœuds du Réseau d'agents (métadonnées) défini dans le YAML.
## Registre des agents (découvrir)
- **Objet**: Exchange est le catalogue des agents, des outils et d'autres actifs. Son objectif principal est de résoudre l'étalement des agents en fournissant un catalogue unique et régi pour la découverte, la curation et la gestion du cycle de vie des agents hétérogènes. Il permet aux développeurs de trouver et de réutiliser des agents, aux propriétaires de plate-forme de maintenir la visibilité et aux orchestrateurs de découvrir des capacités.
- **Heterogeneous by Design**: Anypoint Exchange prend désormais en charge trois nouveaux actifs : les agents, les MCP et les LLM. Exchange est conçu pour être un catalogue universel, pour enregistrer et gérer tout type d'agent. Il prend en charge les agents conformes A2A, les serveurs MCP et les fournisseurs LLM de n'importe quelle source, y compris les agents tiers, Agentforce et MuleSoft personnalisés.
- **Métadonnées principales**: Chaque actif enregistré a un ensemble de métadonnées immuables de référence, y compris un Nom et une Version uniques, Propriété et Éditeur. Les états du cycle de vie (développement, étape, production, déprécié) sont également suivis.
- **Découverte**:
- **Design-Time**: Les développeurs peuvent découvrir les agents enregistrés via l'interface utilisateur Exchange existante ou via la recherche en langage naturel avec Vibes dans le Générateur de code Anypoint.
- **Marquage et classification**: Les actifs peuvent être classés par type (agent, MCP, LLM, courtier) et domaine (par exemple, RH, météo) en utilisant un système de balisage clé-valeur de base, qui active des stratégies de liaison dynamique, de recherche et de sélection.
- **Catalogue**: Le référentiel prend en charge les modèles de catalogue privés et internes pour le partage d'agents au sein d'une organisation.
- **Visualisation**: Fournit un outil visuel qui prend en charge les vues de réseau, montrant les connexions pour des actifs uniques ou la carte complète des nœuds et des liens à travers l'organisation, avec des capacités de filtrage.
Les courtiers d'un réseau d'agents peuvent référencer des agents enregistrés, des serveurs MCP et des fournisseurs LLM stockés dans Anypoint Exchange. Cependant, s'ils ne sont pas déjà enregistrés, ils peuvent être déclarés dans les métadonnées du Réseau d'agents (YAML) et ils sont automatiquement enregistrés. Dans l'exemple, plusieurs agents, serveurs MCP et fournisseurs LLM sont déclarés et enregistrés dans Anypoint Exchange.
```
agents:
orders-agent:
label: Order Fulfilment Agent
metadata:
protocol: a2a
platform: OpenAI
salesforce-agent:
label: Salesforce Agent
metadata:
protocol: a2a
platform: OpenAI
stripe-agent:
label: Stripe Payment Agent
metadata:
protocol: a2a
platform: OpenAI
mcpServers:
inventory:
label: Inventory MCP
metadata:
transport:
kind: streamableHttp
path: /mcp
llmProviders:
open-ai:
label: OpenAI
description: OpenAI LLM Provider
metadata:
platform: OpenAI
```
## Agent Broker (Orchestre)
Un agent courtier est un agent d'acheminement intelligent qui coordonne la délégation de tâches entre les agents spécialisés d'une entreprise. Il est défini par les agents et les serveurs MCP qu'il utilise pour réaliser des tâches.
Un courtier est un agent spécialisé qui apparaît dans Anypoint Exchange après la publication d'un actif réseau d'agents et sa réutilisation par d'autres courtiers.
Les courtiers sont définis dans la section _courtiers_ de la LJM. Les brokers définis sont « compilés » de façon transparente dans une application, sans nécessiter de Knowledge préalable sur Mule. Cette application générée est déployée vers CloudHub 2.0 (CH2) et exploite la robuste infrastructure CH2.
Cela signifie que les courtiers agents bénéficient des caractéristiques de performance établies de CloudHub 2.0, notamment ses capacités de consignation et de métriques. Les aspects opérationnels, tels que le « coût d'exploitation » et la « surveillance/alerte/outillage », sont identiques à toute autre charge de travail.
Pour les scénarios nécessitant une intervention humaine (Human-in-the-Loop), l'état de chaque interaction est conservé en utilisant MuleSoft Object Store, une solution distribuée conçue pour une gestion efficace des états dans des environnements hautement simultanés.
Une définition de courtier comprend deux sections : carte et spécification.
### Carte
La section de la carte suit la [spécification A2A (](https://a2a-protocol.org/v0.2.5/specification/)Agent à agent). Il décrit entre autres le contrat, les compétences et les capacités de l'agent de courtier. L'URL de la carte est automatiquement remplie avec la valeur ${ingressgw.url}/broker-name. Lors du déploiement, l'espace réservé ${ingressgw.url} est automatiquement remplacé par l'URL de la passerelle Flex Anypoint qui précède les requêtes d'entrée de l'agent.
### Spécification
La section spécification configure le « code source » du courtier. Ici, le développeur peut spécifier le grand livre à utiliser, les instructions, les outils disponibles, le traitement des erreurs et, surtout, les divers agents et outils MCP disponibles pour ce courtier.
**LLM Providers**
Cette section fait partie de la spécification de chaque courtier. Il s'agit d'une référence à l'un des grands modèles de langage définis dans la section Services. Nous pouvons choisir entre partager un grand livre entre tous les courtiers ou, si nécessaire, demander à différents courtiers d'utiliser le grand livre qui convient le mieux à leurs tâches.
Les courtiers peuvent pointer vers des fournisseurs de LLM. Nous pouvons choisir des modèles de ces prestataires en fonction de nos besoins.
```
llmProviders:
open-ai:
label: OpenAI
description: OpenAI LLM Provider
metadata:
platform: OpenAI
```
**Instructions**
Cette section est facultative et vous pouvez l'utiliser pour spécifier des instructions particulières à cet agent de courtier. Ces instructions se concentrent souvent sur des préoccupations spécifiques à l'entreprise. Imaginons par exemple un agent du service client qui coordonne la gestion des incidents signalés par les clients:
```
instructions:
- |
You are an Incident Management Orchestrator Agent. Your primary responsibility is to coordinate the resolution of incidents reported by customers.
The process for incident management is:
1. Fetch Salesforce Case Details: Retrieve the latest critical case details for the given customer.
2. Fetch Entitlement Details: Obtain the customer's entitlement information.
3. Fetch On-Call Engineer: Identify the current on-call engineer for the incident.
4. Create Slack War Room and invite on-call engineer: Set up a Slack war room channel and invite the on-call engineer.
5. Summarize Actions: Provide a clear, human-readable summary of the steps performed, including information about the created slack channel and the on-call engineer assigned
```
Notez qu'il n'est pas nécessaire de fournir des instructions explicites, par exemple **« diviser l'invite en tâches » ou « sélectionner le meilleur outil »**, car le courtier gère cela seul. Ces instructions sont nécessaires uniquement pour décrire des processus métiers spécifiques.
**Configuration des outils**
Les outils fournissent aux agents des capacités externes. Lorsqu'un courtier doit accéder à un système externe (qui n'est pas un autre agent, par exemple une API existante ou un service SaaS), il contacte un serveur MCP (Model Context Protocol) :
```
tools:
- mcp:
server: collaboration-mcp # MCP server reference
allowed: # Allowlist specific tools
- create_channel
- invite_user
```
Le serveur MCP est référencé par le nom de l'actif d'échange. Les détails de connectivité sont spécifiés dans la section Services.
Par défaut, le courtier a accès à tous les outils disponibles dans le serveur MCP. Selon notre observation, les grands modèles de langage modernes ne peuvent gérer que 20 à 25 outils par contexte avant de commencer à générer des imprécisions (ou de perdre le contexte). Pour cette raison, il est généralement recommandé de limiter les outils disponibles au strict minimum nécessaire. Vous pouvez appliquer ce filtrage aux listes autorisées.
**Liens Agent**
Cette section est la partie la plus importante de toute la définition. La section Liens permet la communication et l'orchestration inter-agents. Cela signifie que ce courtier s'appuie sur les agents liés ici pour exécuter les actions appropriées afin d'atteindre l'objectif de l'utilisateur.
```
links:
- agent:
ref:
name: orders-agent
- agent:
ref:
name: salesforce-agent
- agent:
ref:
name: stripe-agent
```
En fait, cet article définit un réseau d'agents pour la collaboration.
## Flex Gateway (gouverner)
La gouvernance des agents est un pilier essentiel pour le tissu d'agents, fondamental pour établir un réseau d'agents de confiance et garantir la sécurité et la conformité.
Pour la gouvernance, deux passerelles Flex (1 entrée et 1 sortie) sont requises dans votre espace privé.
La gouvernance établit les structures, les contrôles et les preuves nécessaires pour adapter en toute sécurité le cycle de vie complet du développement agentique (ADLC). Plus précisément, la gouvernance implémente des processus clés tels que la certification des agents, le catalogage, les décisions relatives au cycle de vie et l'application de politiques d'exécution.
- **Catalogue :**
- Échange : Prend en charge l'enregistrement des objectifs des agents, des propriétaires, des environnements, ainsi que des limites en données et en classification. Il enregistre également les capacités, les outils, les ressources, les invites et les dépendances externes avec des versions.
- **Versionnement et cycle de vie :**
- Documentez et gérez la gestion des versions sémantiques des agents, des outils et des actifs pendant le cycle de vie complet du développement des agents.
- La gestion des versions aide à gérer les chronologies de dépréciation des agents et prend en charge la double exécution (si possible) afin de faciliter les migrations.
- **Application des politiques**:
- L'architecture IA agentique élargit la surface d'attaque (interface de conversation, invites et nouveaux protocoles tels que MCP). Tout compromis sur des composants peut entraîner des effets en cascade sur plusieurs systèmes fournissant des composants tels que protocole, invite, API ou outil.
- La sécurisation des déploiements d’IA agentique d’entreprise nécessite une approche spécialisée, car ces environnements autonomes et imprévisibles élargissent intrinsèquement la surface d’attaque par des interactions d’agent à agent. Bien que les outils de sécurité existants pour les systèmes statiques soient essentiels, ils ne suffisent plus à eux seuls. Les entreprises doivent planifier et implémenter proactivement quatre solutions de sécurité spécifiques, chacune traitant directement un risque métier critique associé à l’IA agentique.
- Flex Gateway : Tout le trafic A2A et MCP est acheminé via Flex Gateway, même si le système cible n'est pas sécurisé, pour s'assurer que les stratégies sont appliquées à chaque point de terminaison. Cet acheminement est crucial pour sécuriser les communications des agents et l'intégration aux serveurs d'autorisation.
- Paquets de police : Les utilisateurs peuvent définir et appliquer des paquets de stratégies prédéfinies à des workflows avant l'exécution, en appliquant un ensemble cohérent de stratégies de sécurité et opérationnelles.
- Types de police : La plate-forme prend en charge diverses politiques entrantes et sortantes, notamment :
- Stratégies A2A : Carte de l'agent, Détecteur d'informations personnelles, Décorateur d'invites, Validation du schéma.
- Stratégies MCP : Contrôle d'accès basé sur l'attribut, Validation du schéma, Prise en charge du MCP.
- Politiques LLM/AI : Décorateur d'invites IA, Garde d'invites IA (filtrant les contenus nocifs), Modèle d'invite IA (appliquant des modèles prédéfinis), Limitation du taux de jetons de base IA.
- Politiques de télémétrie : A2A et MCP Telemetry pour étendre les solutions Open Telemetry à la collecte et à l'exportation de données consignées.
- **Consignation**: Grâce au traçage automatique, des journaux à travers le Réseau d'agents sont disponibles pour suivre chaque interaction des agents, expliquer les comportements et établir Trust.
L'exemple montre une stratégie de consignation des messages, qui est configurée en utilisant les métadonnées du réseau de l'agent. Orderfullfillment broker désigne un agent existant appelé agent Salesforce et la stratégie de messagerie est configurée en utilisant les métadonnées. Notez que Agent Fabric configure automatiquement toutes les stratégies mentionnées sous la section « Spécifications » dans Flex Gateway. Aucune étape supplémentaire n'est requise.
```
salesforce-agent-connection:
kind: agent
ref:
name: salesforce-agent
spec:
url: ${salesforce-agent.cardUrl}
policies:
- ref:
name: message-logging
namespace: 68ef9520-24e9-4cf2-b2f5-620025690913
configuration:
loggingConfiguration:
- itemName: "Payload"
itemData:
message: "#[payload]"
firstSection: true
secondSection: true
level: "INFO"
- itemName: "Headers"
itemData:
message: "#[attributes.headers]"
firstSection: true
secondSection: true
level: "INFO"
```
## Visualiseur de l'agent (observer)
Compte tenu de la nature non déterministe et de la complexité des agents du LLM et des déploiements multi-agents, l'observabilité et la surveillance sont essentielles.
- **Journaux et traces de base**: Le raisonnement et le traçage de l'exécution de l'outil sont fournis par des journaux. Les journaux et les traces des exécutions de workflow peuvent être visualisés après l'exécution dans Runtime Manager.
- **Métriques**: Dans la phase initiale, la plate-forme publie a2a_total_calls et mcp_total_calls en tant que compteurs avec des étiquettes (telles que chemin, statut, méthode, outil) pour déterminer le nombre total d'appels réussis et échoués. Ces métriques sont publiées à partir d'un code de stratégie en utilisant l'interface de statistiques natives d'Envoyé (Flex Gateway), de préférence via des stratégies existantes telles que mcp_support_policy et a2a_agent_card_policy.
- **Observabilité accrue (future)**: Les plans prévoient d'utiliser Open Telemetry pour le traçage distribué dans les futures versions. L'observabilité plus avancée comprend :
- **Traçage des demandes détaillé**: Obtention d'une visibilité complète sur les requêtes, englobant les invites, les processus de planification, les actions invoquées et les interactions avec les sous-agents.
- **Surveillance sanitaire des agents**: Surveillance du temps de fonctionnement des agents, de la latence des réponses, du débit, des taux d'erreur et de l'utilisation des ressources sous-jacentes (CPU, mémoire, réseau, GPU).
- **Surveillance de la coordination multi-agents**: Capturer les taux de réussite et d'échec des interactions agent à agent, détecter les modèles d'invocation circulaire (boucles) et suivre des métriques par agent telles que la réalisation des tâches et le nombre d'invocations.
- **Suivi des coûts**: Suivi de l'utilisation de jetons et des coûts associés pour chaque appel LLM, idéalement par agent, avec des tableaux de bord et des alertes.
- **Traçage cognitif**: Capture et affichage d'une trace détaillée de la session d'un agent, y compris les processus de pensée internes et tous les appels d'outils, servant de piste d'audit immuable.
- **Lecture de session de l'agent**: Une interface utilisateur qui permet de « rejouer » visuellement la trace cognitive d'un agent étape par étape pour un débogage profond.
- **Visualisation DAG**: Fournissant une visualisation DAG (Directed Acyclic Graph) de l'exécution du workflow de l'agent pour des interactions multi-agents complexes.
Agent Visualizer est utilisé pour identifier les parties de votre réseau d'agents et voir comment elles fonctionnent ensemble.
- Distinguez les types de nœud (agents et serveurs MCP).
- Visualisez les bords pour afficher les interactions déclarées et à l'exécution.
- Utiliser des couches pour concentrer les vues sur des environnements spécifiques
- Ouvrir des cartes de détail pour inspecter les métadonnées et les métriques des nœuds, et accéder aux journaux et aux traces
- Examinez les indicateurs de gouvernance tels que la protection Flex Gateway et les politiques appliquées.
Vous trouverez [ici](https://docs.mulesoft.com/agent-visualizer/agent-visualizer-components) des détails sur les composants de Agent Visualizer.
## Tissu d'agent : Ensemble, quatre piliers
Avec ces quatre piliers réunis, MuleSoft Agent Fabric étend la sécurité et le contrôle à tous les agents avec une gouvernance intégrée. Il permet aux agents d'agir n'importe où en exploitant de nouveaux protocoles tels que A2A (Agent à Agent) et MCP (Model Context Protocol) pour élaborer et étendre les processus métiers. Nous connectons tous les éléments - applications, données et systèmes - pour habiliter et gouverner les agents dans l'ensemble de leur activité. L'outillage intelligent prend en charge la création et l'extension de processus métiers ou d'API en utilisant l'IA nativement ou en apportant des outils IA tiers.
L'utilisation des quatre piliers ensemble n'est pas obligatoire, mais recommandée. Vous pouvez choisir des piliers indépendamment si nécessaire. Vous pouvez par exemple exploiter Agent Fabric pour le registre et la gouvernance, sans utiliser la couche d'orchestration. De la même façon, vous pouvez utiliser le courtier pour orchestrer des agents gouvernés via une autre plate-forme.
Le diagramme montre comment les quatre composants interagissent entre eux :
1. Publiez les actifs agents dans Anypoint Exchange pour les découvrir et les réutiliser après avoir défini le réseau d'agents (courtiers, agents, serveurs MCP) dans le réseau d'agents YAML dans Anypoint Code Builder.
2. Déployez les actifs agents vers CloudHub 2.0 (géré dans Runtime Manager).
3. Appliquez des stratégies sur le trafic entrant dans le réseau avec une passerelle Flex entrante, qui se situe devant les points de terminaison broker et API.
4. Appliquez des politiques, gérez les connexions et émettez des données télémétriques avec une passerelle Flex de sortie. Cette passerelle se trouve sur les chemins sortants des courtiers et des agents vers les services externes.
5. Recueillez des journaux, des métriques et des traces depuis Flex Gateway et les exécutions dans Anypoint Monitoring.
## Modèles de conception d'orchestration d'agent
Il est tentant de rendre chaque agent spécialisé immédiatement accessible dans une architecture plate et non restreinte, avec un orchestrateur unique capable de s’attaquer à n’importe quelle tâche en ayant accès à chaque actif IA disponible. Cependant, cette approche se révèle rapidement préjudiciable à l'efficacité et à la fiabilité globales du système. De la même façon que le principe appliqué à un excès d'outils individuels, de nombreuses options d'agent introduisent un bruit et une complexité importants pour l'**agent de courtage** central (ou orchestrateur). Cette complexité accrue entraîne directement une baisse sensible de la précision de la prise de décision du courtier (sélection de l'agent approprié pour le travail) et du déterminisme de la réponse du système (résultats prévisibles et cohérents pour des requêtes similaires). L'agent de courtier souffre effectivement d'une paralysie des options, entraînant un acheminement plus lent et moins fiable.
Au lieu d'une structure plate, nous plaidons fermement pour une **approche hiérarchique multiniveaux** dans la structuration du Réseau d'agents. Ce principe organisationnel offre de nombreux avantages critiques. Tout d’abord, elle favorise par nature **la traçabilité et** la gestion. Une structure hiérarchique reflète les meilleures pratiques organisationnelles établies, ce qui facilite l'audit du flux d'une demande, le débogage des problèmes en identifiant la couche d'échec, et la gestion du déploiement et du retrait d'agents ou de sous-réseaux spécifiques.
Deuxièmement, et surtout dans le contexte des grands modèles de langage (LLM) qui pilotent ces agents, une hiérarchie aide considérablement à **contrôler la taille** des contextes. En segmentant le paysage de l'agent, l'agent de courtier à une couche donnée prend en compte uniquement l'ensemble limité d'agents ou de sous-courtiers directement sous lui. Cette structure empêche l'orchestrateur principal de charger la description, les capacités et le contexte historique de _chaque agent_ dans sa mémoire de travail, ce qui **évite** le risque de **dépasser** rapidement les limites en fenêtres contextuelles du grand livre, et **d'entraîner** des coûts et une latence prohibitifs.
Le réseau d'agents peut être implémenté de plusieurs façons. Deux d'entre eux sont :
1. Loi de Conway : méthode intuitive pour la mapper avec la structure hiérarchique du monde réel.
2. Conception pilotée par le domaine - Plus axée sur les domaines métiers
# Option 1 : Mappage avec la structure hiérarchique du monde réel
Dans une organisation hiérarchique, la communication circule verticalement - des responsables aux subordonnés - et les décisions sont souvent centralisées. Selon la loi de Conway :
- Les systèmes ou les architectures logicielles élaborés par ces organisations ont également tendance à être stratifiés et hiérarchiques.
- Chaque équipe a tendance à concevoir des sous-systèmes qui reflètent ses propres limites et pouvoirs.
- Les interfaces entre les systèmes reflètent les canaux de communication entre les ministères.
Le Réseau d'agents peut également être mappé intuitivement avec la **structure hiérarchique réelle d'une grande entreprise** suivant la loi Conway.
- **Le modèle conceptuel :** De la même façon qu'une société a des divisions, des services et des niveaux de gestion distincts (par exemple, C-suite, VP, Directors, Managers), un réseau d'agents opérant dans un domaine spécifique peut être modélisé en tant qu'organigramme parallèle.
- **Les nœuds et les feuilles :** Dans cette hiérarchie :
- **Les feuilles** de l'arborescence sont les **agents spécialisés** ou **MCP**. Ce sont les unités fonctionnelles qui effectuent le travail réel (par exemple, un « Agent de requête de base de données », un « Agent d'authentification client », un « Agent d'analyse des sentiments »). Ils représentent les contributeurs individuels ou les unités de travail de l'organisation.
- **Tous les autres nœuds** de la hiérarchie, y compris les couches racine et intermédiaire, sont des **agents de courtier** (ou des sous-orchestres). Ces agents n'exécutent pas la tâche finale, mais sont responsables de l'acheminement, de la délégation, de l'agrégation et de la résolution des conflits dans leur domaine ou couche spécifique. Un courtier de haut niveau délègue une tâche à un « Courtier du domaine des ventes », qui à son tour délègue la tâche à un « Courtier de la gestion des opportunités », qui exécute la tâche via un « Agent de mise à jour du statut de l'opportunité » (la feuille).
Cette structure garantit que la complexité est gérée localement, que le contexte est contenu et que le système évolue de façon prévisible et fiable. Vous pouvez introduire de nouveaux agents spécialisés dans des branches spécifiques et appropriées de l'arborescence organisationnelle.
Prenons l'analogie d'un organigramme pour la main-d'œuvre numérique. Chaque fichier YAML représente chacune des organisations internes (Réussite des employés, Sécurité, Finances, etc.). Dans chaque organisation (réseau d'agents), vous pouvez avoir une structure hiérarchique à travers laquelle les acteurs collaborent, les tâches sont divisées en tâches et attribuées. Dans le diagramme précédent, la communication circule de haut en bas. Les feuilles ne sont pas limitées à la consommation uniquement par un ensemble d'agents courtiers.
## Option 2 : Conception pilotée par le domaine et implémentation de l'IA agentique
Modéliser des réseaux d'agents sur la base de l'organigramme humain comporte le risque de nécessiter des ré-archivages fréquents, notamment dans les entreprises qui subissent de fréquentes réorganisations. Une autre approche consiste à organiser les agents par domaine fonctionnel. Ce regroupement peut nécessiter de franchir les frontières organisationnelles humaines traditionnelles. Par exemple, l'intégration de nouveaux employés implique des opérations informatiques pour le provisionnement de matériel et d'utilisateurs, alors qu'une motion commerciale nécessite à la fois des opérations et du marketing.
## À propos des auteurs
Nikhil Aggarwal est architecte principal chez Salesforce, où il dirige l'architecture pour MuleSoft et Salesforce Automation Cloud. Nikhil apporte plus de 18 ans d'expérience dans la livraison de produits à grande échelle et est passionné par l'architecture évolutive, les expériences intuitives de développement et la création d'équipes très performantes. Avant Salesforce, il a dirigé plusieurs initiatives dans Microsoft Power Platform, Dataverse et Office 365, du concept au lancement. Son travail continue de façonner la façon dont les entreprises modernes connectent les systèmes, automatisent les workflows et libèrent la valeur métier à l’ère de l’IA.
Mariano Gonzalez a rejoint MuleSoft à ses débuts en 2011, spécialisé dans les systèmes distribués critiques, l'intégration, le PaaS et le cloud computing. Aujourd'hui, Mariano se concentre sur la progression des plates-formes IA, avec une attention particulière à la gouvernance, l'orchestration, la découverte et l'observabilité. Avec plus de 20 ans dans l'industrie informatique, Mariano a été architecte logiciel et chef d'équipe, concevant et livrant des solutions de gestion des ressources humaines, de gestion des ressources humaines et d'intégration dans les secteurs de l'agriculture, de l'énergie, du gouvernement, de l'informatique, des télécommunications et de la gestion des contenus.
Pedro Colunga est architecte ingénieur logiciel chez Salesforce, spécialisé en architecture d'API et de métadonnées. En mettant l'accent sur le cycle de vie complet de la plate-forme, Pedro joue un rôle clé dans l'interaction des organisations avec l'intelligence système, la sémantique et les solutions pilotées par les métadonnées. Pedro a 20 ans de carrière, qui comprend de l'expérience entrepreneuriale, couvrant des sociétés telles que Fuego, BEA Systems, Oracle et TekGenesis, une société rachetée par la suite par MuleSoft, où il a toujours piloté l'architecture de plate-forme, fournissant une expertise approfondie dans des domaines tels que la gestion des performances, la RAD et les intégrations.
Gulal Kumar est architecte en génie logiciel chez Salesforce, spécialisé dans l'architecture de données et d'intégration. Avec plus de 20 ans d'expérience dans l'intégration et les API, les programmes de modernisation, la sécurité et les initiatives AIML, il apporte une riche expertise. Gulal s’est engagé à faire progresser les initiatives de transformation métier, à renforcer la sécurité et la résilience, à promouvoir l’excellence en architecture et à piloter des initiatives AIML dans divers domaines.
## Présentation du guide
Le traitement asynchrone augmente l'[évolutivité](/docs/architect/fr-fr/well-architected/guide/reliable#évolutivité) en autorisant des limites plus élevées par contexte. Les requêtes asynchrones sont exécutées dans leurs propres threads en arrière-plan. Les utilisateurs peuvent ainsi continuer à travailler côté client pendant que les tâches asynchrones sont exécutées en arrière-plan.
Salesforce Lightning Platform offre une variété de technologies asynchrones qui peuvent être utilisées pour résoudre un cas d'utilisation donné. Chaque technologie présente des avantages et des limites que vous devrez prendre en compte lors de la sélection d'une approche pour chaque cas d'utilisation.
Lors du choix d'une technologie pour l'implémentation, trois considérations importantes à prendre en compte sont les suivantes :
1. Le traitement asynchrone n'est pas la meilleure approche pour chaque problème. Il peut être tentant de considérer tout processus qui ne nécessite pas directement l'interaction de l'utilisateur comme un bon candidat pour le traitement asynchrone, mais il y a quelques inconvénients. Tout d'abord, les processus asynchrones n'ont pas de contrat de niveau de service, ce qui signifie qu'il n'y a aucune garantie qu'un processus asynchrone se termine dans un délai défini. Deuxièmement, rien ne garantit une latence de réponse cohérente. Si un processus asynchrone se termine dans un délai donné, un processus suivant peut prendre un délai différent. Par conséquent, même si un utilisateur n'attend pas directement une réponse, le traitement asynchrone peut ne pas être adapté à votre scénario si vous avez des processus ultérieurs qui dépendent d'une réponse ou si vous craignez que des temps de réponse excessifs ne désynchronisent vos données avec celles d'un système externe.
2. Il existe différentes méthodes de traitement des requêtes asynchrones sur Salesforce Platform. Par conséquent, assurez-vous de choisir la meilleure approche. Les technologies qui prennent en charge le traitement asynchrone sur Salesforce Platform fonctionnent différemment « en arrière-plan », et certaines ont été conçues pour des cas d'utilisation très spécifiques.
3. Si une technologie est asynchrone côté client, cela ne signifie pas nécessairement que tous les traitements de bout en bout sont effectués en parallèle. Selon vos choix, les messages du client peuvent parfois être numérotés côté serveur.
Si vous utilisez les mauvaises technologies ou les mauvaises combinaisons de technologies pour une tâche, des conséquences inattendues qui annulent les avantages du traitement asynchrone peuvent se produire. Ce guide fournit des explications et des recommandations, ainsi que les inconvénients potentiels et les anti-modèles pour divers cas d'utilisation asynchrone, avec la justification de ces recommandations. Il fournit également des connaissances sur le fonctionnement et la réglementation des diverses techniques d'implémentation asynchrone sur Salesforce Platform.
Si vous décidez de la technologie à utiliser, un [guide de décision](/docs/architect/fr-fr/decision-guides/guide/async-processing) sur le traitement asynchrone ciblé permet de mapper rapidement les cas d'utilisation typiques avec la technologie la plus adaptée.
## Produits dans la portée
 |
Salesforce Lightning Platform est une plate-forme complète pilotée par l'IA qui unifie les employés, les agents IA autonomes, les données de l'entreprise et les applications dans un système unique et de confiance afin d'améliorer la productivité et l'expérience client. Il permet la création d'une "entreprise agentique" en connectant les applications Customer 360, Data Cloud, et Slack pour une automatisation de bout en bout. |
#### Utilisation équitable
Le mécanisme d'utilisation équitable de la plate-forme implémente un système basé sur le niveau. Le système garantit que chaque organisation sur Salesforce Platform reçoit une part équitable du temps de traitement pour un type de message donné, y compris les types de message Future, Queueable et Batch. Si une organisation domine un type de message donné pendant que d'autres organisations attendent pour travailler sur le même type de message, l'algorithme d'utilisation équitable réduit le nombre de threads disponibles pour ce type de message particulier.
Un avantage de l'utilisation de méthodes Apex asynchrones est que certaines limites du gouverneur, telles que les limites en requêtes SOQL et les limites en taille de tas, sont plus élevées. Cependant, ne vous appuyez pas trop sur ces méthodes. En raison des ressources limitées allouées à l'infrastructure asynchrone, une utilisation intensive de Future, Queueable et Batch Apex peut entraîner des retards de traitement qui découlent de limitations basées sur une utilisation équitable et un contrôle de flux.
#### Considérations particulières relatives aux appels externes sortants via Apex asynchrone
Les appels externes sortants qui utilisent Apex asynchrone sont pris en compte dans la limite Apex asynchrone. La limite quotidienne est actuellement de 250 000 ou 200 fois le nombre de licences utilisateur applicables, selon la valeur la plus élevée. Cette limite peut être problématique pour les cas d'utilisation à haut volume. Si vous dépassez la limite, vos tâches Apex asynchrones et leurs appels sortants associés échoueront.
De plus, comme la plate-forme a un nombre fini de threads asynchrones disponibles, l'évolutivité des intégrations sortantes via Apex asynchrone est limitée. Toutes les intégrations sortantes à haut volume qui dépassent le nombre de threads disponibles peuvent entraîner des temps de traitement importants et des retards.
Pour des cas d'utilisation à haut volume, tenez compte des approches alternatives ci-dessous. Les appels d'API avec ces approches sont pris en compte dans la limite quotidienne en requêtes d'API, qui est significativement plus élevée que la limite Apex asynchrone quotidienne. Ainsi, ces approches sont plus évolutives. Notez toutefois que le nombre de requêtes simultanées que tout processeur peut traiter reste limité.
- **Middleware Scheduled Pull.** Évitez les délais associés aux tâches d'intégration sortantes à haut volume en utilisant un middleware pour extraire les données sur une base planifiée au lieu de les envoyer automatiquement via Apex asynchrone. Les middlewares, tels que MuleSoft Anypoint Platform, peuvent utiliser l'API SOAP native ou l'API REST de façon synchrone afin d'introduire peu, voire aucun délai. Middleware peut également utiliser l'API de transfert en masse native pour des volumes de données importants.
- **Middleware Pull via Notification d'événement de plate-forme.** Au lieu de mettre en file d'attente Apex asynchrone Future, Queueable ou Batch pour effectuer des intégrations sortantes, vous pouvez utiliser des événements de plate-forme. L'événement de plate-forme peut livrer les informations sortantes lui-même ou charger un outil middleware d'extraire les informations requises via une API native et de les livrer à leur destination finale. Aucune de ces approches n'est soumise aux délais auxquels est soumis Apex asynchrone. Cependant, les [limites en événements](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_limits_default.htm) de plate-forme restent applicables.
#### Compromis Apex asynchrones
| Produit / Approche | Cas d'utilisation | Compétences requises | Asynchrone par rapport au client | Asynchrone par rapport au serveur | Type de limitation de la plate-forme appliquée |
|---|---|---|---|---|---|
| Apex Future Methods | Nous recommandons d'utiliser Apex Queueable au lieu de méthodes Apex futures. Les files d'attente ont les mêmes cas d'utilisation que les méthodes futures, mais offrent des avantages supplémentaires. | Pro-code | Oui | Oui | Asynchrone |
| Apex Queueable | Nous préférons cette approche aux méthodes futures. Utilisé pour les processus qui impliquent de longues opérations de base de données ou des appels externes de service Web. Apex Queueable offre des avantages supplémentaires par rapport aux méthodes futures, notamment les ID de tâche, la prise en charge des types non primitifs et l'enchaînement des tâches. | Pro-code | Oui | Oui | Asynchrone |
| Apex planifié | Exécutez Apex à une heure planifiée définie par une expression cron. Bien que l'action de planifier Apex via l'expression cron soit un processus asynchrone, le code sous-jacent est exécuté de façon synchrone au démarrage de la tâche. | Pro-code | Oui | Oui | Synchrone |
| Appels externes de continuation Apex | Appels externes de méthodes Apex exécutées dans un contexte de transaction synchrone. | Pro-code | Oui | Oui | Synchrone |
Les événements publiés dans le bus via [publier après validation](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm) sont livrés dans l'ordre et peuvent être traités en masse par le déclencheur ou le flux dans un contexte synchrone séparé. Le contexte est synchrone et applique toutes les limites du gouverneur synchrone. Choisissez soigneusement la taille de lot de déclencheur/flux d'événement de plate-forme pour ne pas atteindre les limites.
| Produit / Approche | Cas d'utilisation | Compétences requises | Asynchrone par rapport au client | Asynchrone par rapport au serveur | Type de limitation de la plate-forme appliquée |
|---|---|---|---|---|---|
| Déclencheurs d'événements de plate-forme | Couplez librement Salesforce à des systèmes externes et communiquez entre des composants de plate-forme asynchrones. | Code bas + code pro | Oui | Oui | Synchrone |
| Produit / Approche | Cas d'utilisation | Compétences requises | Asynchrone par rapport au client | Asynchrone par rapport au serveur | Type de limitation de la plate-forme appliquée |
|---|---|---|---|---|---|
| Parcours planifié (après validation des flux) | Exécutez à des heures planifiées dynamiquement après le déclenchement d'événements. | Code faible | Oui | Oui | Asynchrone |
| Trajet asynchrone (flux déclenchés par un enregistrement) | Exécutez une opération que vous souhaitez exécuter sur son propre temps et pour éviter les erreurs DML mixtes. | Code faible | Oui | Oui | Asynchrone |
| Produit / Approche | Cas d'utilisation | Compétences requises | Asynchrone par rapport au client | Asynchrone par rapport au serveur | Type de limitation de la plate-forme appliquée |
|---|---|---|---|---|---|
| Messages sortants | Partager des données avec des systèmes tiers en temps quasi réel via le protocole SOAP | Code faible | S.O. | Oui | S.O. |
| Produit / Approche | Cas d'utilisation | Compétences requises | Asynchrone par rapport au client | Asynchrone par rapport au serveur | Type de limitation de la plate-forme appliquée |
|---|---|---|---|---|---|
| E-mail vers requête | Créez automatiquement des requêtes et remplissez les champs de requête en fonction des valeurs des e-mails entrants. | Code faible | Oui | Oui* | Synchrone |
| * E-mail vers requête est traité à la fois comme synchrone et asynchrone, mais avec des limitations Apex synchrones | |||||
| Produit / Approche | Cas d'utilisation | Compétences requises | Asynchrone par rapport au client | Asynchrone par rapport au serveur | Type de limitation de la plate-forme appliquée |
|---|---|---|---|---|---|
| Batch Apex | Processus complexes et longs qui impliquent des milliers d'enregistrements | Pro-code | Oui | Oui | Asynchrone |
| Flux déclenchés par une planification | Exécuter des actions sur un lot d'enregistrements en arrière-plan à une heure spécifiée et à une fréquence répétée via un flux. | Code faible | Oui | Oui | Synchrone |
| API de transfert en masse | Insérez, mettez à jour, mettez à jour/insérez, interrogez ou supprimez de nombreux enregistrements de façon asynchrone. | Pro-code | Oui | Oui | Asynchrone |