Salesforce a lancé officiellement Agentforce Commerce le 24 juin 2026 : trois agents distincts (Shopper Agent, Buyer Agent, Merchant Agent), l’intégration de Cimulate rebaptisée Agentic Commerce Search, et des canaux OpenAI/ChatGPT en production. Pour les ETI françaises, la question n’est pas “est-ce que ça marche ?” mais “est-ce qu’on peut le déployer sans exposer nos données client à un risque RGPD non maîtrisé ?” La réponse est oui, à condition de ne pas traiter la conformité comme une couche qu’on ajoute après.
Agentforce RGPD n’est pas un sujet de DPO. C’est un sujet d’architecture.
Ce que le lancement Agentforce Commerce change concrètement
Avant ce lancement, les agents Salesforce opéraient principalement sur des données CRM structurées : contacts, opportunités, cases. Agentforce Commerce introduit un périmètre radicalement différent. Le Shopper Agent interagit en temps réel avec des acheteurs anonymes ou authentifiés sur des storefronts B2C. Le Buyer Agent orchestre des transactions B2B via WhatsApp et SMS. Le Merchant Agent accède aux catalogues produits et aux règles de pricing.
Ce qui change du point de vue des données : on passe de données relationnelles relativement statiques à des flux comportementaux en temps réel, des sessions non authentifiées, et des canaux de messagerie qui traversent des infrastructures tierces. Chacun de ces trois vecteurs crée une surface RGPD distincte.
L’Agentic Commerce Search (ex-Cimulate) ajoute une couche supplémentaire : les requêtes de recherche des utilisateurs sont désormais traitées par un moteur d’inférence qui peut inférer des intentions d’achat, des préférences, voire des données sensibles par corrélation. Dans le cadre du RGPD, une inférence sur des données personnelles est elle-même une donnée personnelle.
Les trois surfaces RGPD à cartographier avant le déploiement
Surface 1 : le Shopper Agent et les sessions anonymes
Le Shopper Agent peut interagir avec un visiteur non connecté. Dès qu’une conversation contient des éléments permettant l’identification indirecte (panier, localisation, historique de navigation), on entre dans le périmètre des données personnelles au sens de l’article 4 du RGPD.
L’architecture qui fonctionne ici repose sur une séparation stricte entre les données de session éphémères et les données persistées dans Data Cloud. Les Data Streams qui alimentent le Shopper Agent doivent être configurés avec des règles de rétention explicites : pas de persistance des données de session anonyme au-delà de la durée nécessaire à la transaction. Identity Resolution ne doit pas être activé sur des profils non consentis, même si la correspondance technique est possible.
En pratique, les ETI qui déploient sans cette séparation se retrouvent avec des Unified Individuals construits à partir de sessions non consenties. C’est un risque CNIL direct, pas théorique.
Surface 2 : le Buyer Agent sur WhatsApp et SMS
WhatsApp et SMS sont des canaux régulés différemment d’un storefront web. Le consentement pour recevoir des communications commerciales via SMS est soumis à des règles spécifiques en France (article L34-5 du Code des postes et communications électroniques, en plus du RGPD). Le Buyer Agent qui initie ou répond à des conversations B2B sur ces canaux doit opérer dans un cadre de consentement documenté.
Le point d’architecture critique : les métadonnées de conversation (horodatage, numéro, contenu) transitent par l’infrastructure OpenAI avant d’atteindre Salesforce. Le Data Processing Agreement (DPA) avec OpenAI doit être en place et documenté dans votre registre des traitements. Ce n’est pas optionnel. La CNIL a déjà sanctionné des transferts vers des sous-traitants sans DPA conforme.
Pour les ETI qui utilisent MuleSoft comme couche d’intégration entre leurs systèmes ERP et Salesforce Commerce, c’est également le bon endroit pour implémenter des filtres de pseudonymisation avant que les données n’atteignent les Topics et Actions de l’agent.
Surface 3 : le Merchant Agent et les données catalogue
Le Merchant Agent semble le moins risqué des trois. Il gère des catalogues, des règles de pricing, des stocks. Mais dans un contexte B2B, les données catalogue peuvent contenir des informations sur des acheteurs professionnels identifiables (contrats nominatifs, remises personnalisées, historiques de commandes liés à des contacts). Ces données tombent dans le périmètre RGPD dès qu’elles concernent des personnes physiques, même dans un contexte professionnel.
L’architecture recommandée : les Data Model Objects (DMOs) qui alimentent le Merchant Agent doivent être segmentés par niveau de sensibilité. Les Calculated Insights qui agrègent des comportements d’achat B2B ne doivent pas être exposés directement à l’agent sans contrôle d’accès basé sur les rôles.
Comment configurer Prompt Builder pour la conformité
Prompt Builder est le point de contrôle le plus sous-utilisé pour la conformité RGPD dans les déploiements Agentforce. Les templates de type Flex permettent d’injecter dynamiquement des données contextuelles dans les prompts. Sans gouvernance, c’est une porte d’entrée pour l’exfiltration involontaire de données personnelles vers le LLM.
Trois règles concrètes pour les ETI françaises :
Premièrement, ne jamais injecter d’identifiants directs (email, téléphone, numéro client) dans les prompts Flex. Utilisez des identifiants pseudonymisés et résolvez côté Salesforce, pas côté LLM.
Deuxièmement, activer les Einstein Trust Layer data masking rules sur tous les champs qui peuvent contenir des données personnelles. Le Trust Layer est la seule garantie technique que les données ne sont pas loggées par le modèle externe. Sans cette configuration, votre DPA avec Salesforce ne couvre pas les données qui transitent en clair.
Troisièmement, documenter chaque template Prompt Builder dans votre registre des traitements comme un traitement automatisé. L’article 22 du RGPD sur les décisions automatisées s’applique dès que l’agent prend une décision qui affecte significativement un utilisateur (refus de commande, modification de prix, blocage de compte).
Pour aller plus loin sur la configuration de Prompt Builder dans un contexte de conformité, l’article sur les bonnes pratiques Prompt Builder couvre les patterns de template qui minimisent l’exposition des données.
Ce que les DSI français doivent exiger de leurs ESN
Un déploiement Agentforce Commerce conforme RGPD n’est pas livrable en mode projet classique avec une recette fonctionnelle. Les DSI d’ETI qui mandatent des ESN pour ce type de déploiement doivent exiger quatre livrables non négociables.
D’abord, une cartographie des flux de données personnelles spécifique aux trois agents, distincte de la cartographie générale Salesforce. Les flux Shopper Agent, Buyer Agent et Merchant Agent ont des chemins différents et des sous-traitants différents (OpenAI pour les canaux conversationnels, Cimulate/Agentic Commerce Search pour la recherche).
Ensuite, une analyse d’impact relative à la protection des données (AIPD) pour chaque agent qui traite des données à grande échelle ou des données comportementales. Ce n’est pas une recommandation, c’est une obligation légale pour les traitements à risque élevé.
Troisièmement, la configuration documentée de l’Einstein Trust Layer avec les règles de masquage activées et testées. Pas une capture d’écran de la configuration, mais un test de non-régression qui vérifie que les données masquées ne réapparaissent pas dans les logs.
Enfin, un plan de réponse aux droits des personnes (droit d’accès, droit à l’effacement) qui couvre les données traitées par les agents. Si un client demande la suppression de ses données, l’ETI doit être capable de supprimer non seulement les données CRM mais aussi les données de session et les profils unifiés construits par Identity Resolution.
À l’échelle d’une ETI avec plusieurs milliers de clients actifs sur des canaux commerce, l’absence de ce plan se traduit concrètement par une incapacité à répondre aux demandes RGPD dans le délai légal d’un mois.
Pour les organisations qui envisagent un déploiement structuré, les patterns d’architecture Agentforce avec contraintes de conformité sont détaillés sur la page /services/agentforce-architecture.
Points Clés
- Le Shopper Agent crée des profils comportementaux à partir de sessions potentiellement anonymes : Identity Resolution ne doit pas s’activer sans consentement explicite, sous peine de construire des Unified Individuals non conformes.
- Les canaux WhatsApp/SMS du Buyer Agent impliquent un transfert de données vers OpenAI : un DPA conforme avec ce sous-traitant est obligatoire et doit figurer dans le registre des traitements.
- L’Agentic Commerce Search (ex-Cimulate) traite des requêtes de recherche qui peuvent constituer des données personnelles par inférence : ce traitement doit être documenté et basé sur une finalité légitime.
- Einstein Trust Layer avec data masking activé est la seule garantie technique contre l’exfiltration de données personnelles vers le LLM : sans cette configuration, le DPA Salesforce ne suffit pas.
- Une AIPD est obligatoire pour les déploiements Agentforce Commerce qui traitent des données comportementales à grande échelle : les ETI qui l’omettent s’exposent à une sanction CNIL, pas seulement à un risque théorique.
