L'intelligence artificielle générative d'entreprise a franchi une étape décisive, passant des chatbots conversationnels basiques à des agents autonomes capables de planifier, raisonner et exécuter des processus métiers complexes en plusieurs étapes. Avec Salesforce Agentforce, des agents autonomes agissent pour le compte des employés et des clients. Cependant, la fiabilité de ces agents dépend directement de la fraîcheur et de l'exhaustivité des données d'entreprise qui alimentent leurs décisions. Si un agent s'appuie sur des caches CRM obsolètes ou des historiques clients incomplets, son raisonnement génère des hallucinations, des déclenchements erronés d'automatisations et des failles critiques de conformité.
Auparavant, fournir un contexte d'entreprise unifié nécessitait la mise en place de pipelines ETL (extraction, transformation, chargement) volumineux, répliquant des pétaoctets de données depuis des entrepôts externes vers Salesforce. Ce modèle historique engendre des délais de synchronisation pénalisants, une explosion des coûts de stockage cloud, une fragmentation de la sécurité et des profils clients désynchronisés.
Les architectes de données Salesforce résolvent cette équation en associant Agentforce, le moteur de raisonnement Atlas Reasoning Engine et Salesforce Data Cloud (désormais Data 360) au sein d'une architecture Zero-Copy (zéro copie). Cette approche ancre les agents dans les données d'entreprise en direct hébergées dans Snowflake, Google BigQuery, Databricks et Amazon Redshift, sans déplacer ni dupliquer le moindre enregistrement physique.
1. Le dilemme des agents autonomes : pourquoi l'ETL traditionnel échoue face à Atlas
Contrairement aux assistants virtuels rigides répondant à des invites prédéfinies, Agentforce est orchestré par le moteur Atlas Reasoning Engine, qui exécute une boucle continue ReAct (Reason + Act : Raisonner et Agir). Face à une demande utilisateur, Atlas suit la démarche suivante :
- Évalue l'intention de l'utilisateur ou l'événement entrant au regard des objectifs métiers.
- Élabore un plan d'action dynamique au sein de domaines de compétences appelés Topics (Thèmes).
- Interroge dynamiquement des entrepôts de données structurées et des bases documentaires non structurées.
- Exécute des actions déterministes via Salesforce Flow, du code Apex ou des API MuleSoft.
- Analyse les résultats intermédiaires et ajuste son plan en boucle jusqu'à l'accomplissement de la tâche.
Cette boucle opérationnelle exige un socle de données en temps réel que les flux ETL traditionnels ne peuvent soutenir :
- Fraîcheur des données et latence : Un agent gérant le support client ou la lutte antifraude ne peut tolérer des fenêtres de synchronisation par lots espacées de 4 à 24 heures. Une annulation de commande validée dans Snowflake doit être immédiatement visible par l'agent.
- Redondance des coûts de stockage et de calcul : Répliquer des téraoctets d'entrepôts de données dans le stockage CRM génère des surcoûts de licences et une double facturation d'infrastructure.
- Fragmentation de la gouvernance : Multiplier les copies de données sensibles augmente l'exposition aux réglementations RGPD et HIPAA, tout en risquant de contourner les politiques de sécurité au niveau des lignes et des colonnes définies à la source.
Les architectes de données résolvent ce défi en transformant Salesforce Data Cloud en un maillage sémantique de requêtes fédérées en temps réel.
2. Les fondations de l'architecture Zero-Copy
L'intégration Zero-Copy permet à Data Cloud d'interroger directement les données là où elles résident, en fédérant les métadonnées sans déplacer les données brutes. Salesforce propose trois modèles principaux de fédération :
[ Lakehouses / Entrepôts de Données Externes ]
Snowflake | Databricks | BigQuery | Amazon Redshift
| |
(Fédération de fichiers / Iceberg) (Pushdown SQL / JDBC)
| |
v v
+-------------------------------------------------------+
| Salesforce Data Cloud (Data 360) |
| - Objets du Lac de Données (DLOs) |
| - Objets du Modèle de Données (DMOs / Standard CIM) |
| - Résolution d'Identité en Temps Réel (Unified) |
| - Graphes de Données pré-matérialisés (JSON) |
| - Index de Recherche Hybride (Vecteurs + BM25) |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| Einstein Trust Layer |
| - Masquage dynamique des PII et démasquage |
| - Garantie de rétention zéro des données |
| - Détection des hallucinations et de la toxicité |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| Atlas Reasoning Engine |
| - Analyse d'intention et sélection de Topic |
| - Ancrage contextuel et boucle ReAct |
| - Déclenchement d'actions (Apex / Flow / MuleSoft) |
+-------------------------------------------------------+
Fédération de fichiers via Apache Iceberg
Permet à Data Cloud d'accéder directement aux formats de tables ouvertes (comme Apache Iceberg ou Delta Lake) situés sur du stockage objet (Amazon S3 ou Google Cloud Storage). Le moteur de requête Hyper de Data Cloud lit les métadonnées et les fichiers Parquet à la source sans consommer les unités de calcul de l'entrepôt externe. C'est la méthode idéale pour les flux volumineux de télémétrie, de navigation web et d'IoT.
Fédération de requêtes (Pushdown Querying)
Utilisée lorsque l'agent a besoin de calculs analytiques complexes déjà modélisés dans l'entrepôt distant (score de propension à l'attrition, analyse de solvabilité). Data Cloud délègue la requête SQL directement à Snowflake ou BigQuery. Le calcul est exécuté à distance et seul le résultat final consolidé est retourné à Salesforce.
Partage bidirectionnel des données (Data Sharing)
La technologie Zero-Copy fonctionne dans les deux sens. Grâce à des protocoles comme Snowflake Secure Data Sharing ou Databricks Delta Sharing, Data Cloud expose les interactions CRM et les profils unifiés directement aux data lakehouses de l'entreprise, sans scripts d'exportation récurrents.
3. Harmonisation sémantique et résolution d'identité
Les données fédérées brutes doivent être harmonisées pour que les modèles de langage et le moteur de raisonnement puissent les interpréter de manière fiable. Les architectes conçoivent cette structure en deux étapes dans Data Cloud :
1. Mappage des DLOs vers les DMOs
Les tables externes connectées sont d'abord enregistrées en tant qu'Objets du lac de données (DLO). Les architectes mappent ensuite ces champs vers des Objets du modèle de données (DMO) alignés sur le standard Cloud Information Model (CIM) :
- Les lignes de commande ERP sont mappées aux DMOs
SalesOrderetSalesOrderProduct. - Les données d'utilisation de l'application mobile alimentent
DeviceApplicationetEngagementTopic. - Les coordonnées de contact sont reliées à
IndividualetContactPointAddress.
2. Résolution d'identité en temps réel
Dans un écosystème multicanal, un même client interagit sous différentes identités : cookies anonymes sur le site web, compte d'application mobile et numéro de téléphone au service client.
Le moteur de résolution d'identité de Data Cloud applique des règles déterministes et probabilistes (adresses e-mail, numéros de téléphone hachés, identifiants uniques) sur l'ensemble des DMOs. Il génère ainsi un profil unique : l'Individu unifié (Unified Individual). Lorsqu'Agentforce engage une interaction, le moteur Atlas dispose de la vue complète du parcours client.
4. Élimination de la latence : Les Graphes de Données (Data Graphs)
Dans le déploiement d'agents autonomes, la latence des requêtes représente un obstacle majeur. Si le moteur de raisonnement Atlas devait exécuter cinq jointures relationnelles SQL complexes sur des tables distantes à chaque prise de décision, le temps de réponse atteindrait 5 à 15 secondes, entraînant des expirations de session et une mauvaise expérience utilisateur.
Les architectes surmontent cet écueil grâce aux Data Graphs dans Data Cloud.
Qu'est-ce qu'un Data Graph ?
Un Data Graph est un modèle hiérarchique préconfiguré qui parcourt les relations entre plusieurs DMOs et les matérialise sous la forme d'un objet JSON optimisé pour une lecture instantanée.
Structure type :
- Entité racine :
Unified Individual - Nœuds enfants :
SalesOrder(commandes des 90 derniers jours),Case(tickets de support en cours), indicateurs deCalculated Insightet télémétrie Snowflake en Zero-Copy.
Pourquoi les Data Graphs accélèrent Agentforce
- Suppression des jointures en temps réel : Les relations entre entités sont pré-assemblées en arrière-plan.
- Récupération instantanée par clé unique : Atlas interroge une clé primaire unique (
UnifiedIndividualId) et récupère l'ensemble du contexte client 360 en quelques millisecondes. - Intégration native à Prompt Builder : Les Data Graphs peuvent être insérés directement comme champs de fusion structurés dans les modèles de prompts de Salesforce, sans nécessiter de code Apex pour la sérialisation.
5. Ancrage des connaissances non structurées : Recherche hybride et vecteurs
Une part considérable de l'expertise d'entreprise se trouve dans des documents non structurés : manuels d'utilisation en PDF, contrats de garantie, articles de base de connaissances et historiques de conversations.
Pour relier Agentforce à ce patrimoine documentaire, les architectes déploient les index de recherche de Data Cloud :
- Intégration documentaire : Les référentiels comme SharePoint, Amazon S3 ou Salesforce Knowledge sont intégrés comme DLOs non structurés.
- Découpage sémantique et embeddings vectoriels : Data Cloud segmente les documents en fragments (chunks) et génère des représentations vectorielles stockées dans sa base de données vectorielle intégrée.
- Recherche hybride (Hybrid Search) : Face à une interrogation complexe, Atlas combine une recherche textuelle BM25 (pour les références techniques exactes) et une recherche vectorielle sémantique dense (pour le sens contextuel), fournissant les passages les plus pertinents directement dans la fenêtre de contexte du prompt.
6. Le cycle d'exécution d'Atlas et la protection de l'Einstein Trust Layer
Grâce à la fédération Zero-Copy, au modèle CIM, aux Data Graphs et à la recherche hybride, Agentforce exécute son cycle opérationnel en toute sécurité :
[Demande utilisateur / Déclencheur système]
│
▼
[Atlas Reasoning Engine] ──────► Analyse l'intention et sélectionne le Topic
│
▼
[Data Cloud Grounding] ──────► Extrait le Data Graph (JSON client 360)
──────► Lance la recherche hybride (Documents techniques)
──────► Requête Zero-Copy (Solde ERP en temps réel)
│
▼
[Einstein Trust Layer] ──────► Masque les PII / Vérifie les permissions d'accès
│
▼
[Raisonnement du LLM] ──────► Boucle ReAct : Détermine l'action à exécuter
│
▼
[Exécution de l'action] ──────► Déclenche Salesforce Flow / Apex / MuleSoft
│
▼
[Validation du résultat] ──────► Vérifie l'atteinte de l'objectif et clôture
Les garanties de l'Einstein Trust Layer
Avant que le contexte enrichi ne soit envoyé au grand modèle de langage (qu'il provienne de Salesforce, OpenAI, Anthropic ou Azure), la couche de confiance applique des contrôles stricts :
- Masquage dynamique des PII : Les données d'identification personnelle (numéro de sécurité sociale, carte bancaire) sont substituées par des jetons anonymes avant l'envoi au modèle.
- Garantie de non-rétention des données : Les accords contractuels garantissent que les données d'entreprise ne sont jamais conservées chez le fournisseur de modèle ni utilisées pour l'entraînement de modèles publics.
- Contrôle d'ancrage et détection de toxicité : La réponse générée est comparée aux données d'origine pour éliminer tout risque d'hallucination ou de propos toxiques.
- Démasquage sécurisé et traçabilité : Les informations sont réintégrées pour l'utilisateur final et l'ensemble des échanges est enregistré dans les DMOs d'audit de Data Cloud.
7. Comparatif architectural : ETL traditionnel vs Ancrage Zero-Copy
| Critère | Approche Traditionnelle par ETL | Ancrage Zero-Copy dans Data Cloud |
|---|---|---|
| Mouvement des données | Extraction par lots, transformation et réplication physique dans le CRM | Accès in situ via fédération Iceberg ou délégation de requête pushdown |
| Fraîcheur des données | Retard inhérent aux lots de synchronisation (heures ou jours) | Temps réel ; consultation de l'état exact de l'entrepôt à l'instant T |
| Coûts d'infrastructure | Élevés ; duplication du stockage et facturation croisée de capacité | Minimes ; données conservées sur le stockage économique du lakehouse |
| Latence d'assemblage | Lente ; nécessite de multiples requêtes SOQL complexes à l'exécution | Millisecondes ; les Data Graphs fournissent une structure JSON prête à l'emploi |
| Sécurité et gouvernance | Fragmentée ; gestion manuelle complexe de la réplication des droits | Centralisée ; respect des droits de la source avec l'Einstein Trust Layer |
| Périmètre de raisonnement | Limité aux données déjà présentes dans le CRM | Global ; englobe ERP, lakehouses, télémétrie et bases documentaires |
8. Bonnes pratiques et guide de décision pour l'architecte d'entreprise
Pour garantir performance, maîtrise budgétaire et fiabilité à grande échelle, les architectes doivent appliquer les principes suivants :
1. Arbitrer entre fédération de fichiers et délégation de requêtes
- Privilégiez la fédération de fichiers avec Apache Iceberg pour les volumes massifs en ajout seul (logs web, télémétrie, historiques d'achats), afin d'éviter toute consommation de calcul sur l'entrepôt externe.
- Utilisez la délégation de requêtes (Pushdown) pour les indicateurs analytiques complexes nécessitant la puissance de calcul de Snowflake ou BigQuery.
2. Prévenir l'explosion des coûts de calcul externes
Dans un contexte d'échanges interactifs avec les agents, les requêtes pushdown peuvent solliciter fortement l'entrepôt distant :
- Proscrivez les balayages complets de tables non indexées dans les boucles de conversation.
- Intégrez les attributs fréquemment consultés dans des Data Graphs avec des fenêtres de mise en cache adaptées.
- Utilisez Calculated Insights dans Data Cloud pour réaliser des agrégations planifiées en amont.
3. Dimensionner précisément les Data Graphs
Ne créez pas de Data Graphs monolithiques contenant des centaines de champs superflus. Une structure JSON surchargée sature la fenêtre de contexte du modèle, augmente les coûts d'inférence et risque de perturber le raisonnement d'Atlas. Concevez des Data Graphs ciblés et alignés sur les thèmes (Topics) de l'agent.
4. Structurer la gouvernance multi-agents
Plutôt que de concevoir un agent unique généraliste, configurez des sous-agents spécialisés par domaine métier, dotés d'autorisations d'accès précises dans Data Cloud. Pour les opérations sensibles modifiant le système d'enregistrement (remboursements, avenants contractuels), prévoyez systématiquement une étape de validation humaine (Human-in-the-Loop) dans Salesforce Flow ou Apex.
Conclusion
L'ancrage d'Agentforce dans Salesforce Data Cloud via une architecture Zero-Copy marque une étape fondamentale dans la stratégie de données et d'intelligence artificielle des entreprises. En reliant directement les data lakehouses modernes aux moteurs de raisonnement autonome, les architectes suppriment la dette technique liée à la réplication des données tout en offrant aux agents un contexte opérationnel exhaustif et en temps réel. Grâce à la fédération Apache Iceberg, à la normalisation CIM, aux Data Graphs optimisés et aux garde-fous de l'Einstein Trust Layer, les entreprises peuvent déployer en toute sérénité une force de travail numérique autonome et créatrice de valeur.