Le lancement Agentforce Commerce du 24 juin 2026 distingue trois agents disponibles, Shopper Agent, Buyer Agent et Merchant Agent. Il annonce aussi une intégration ChatGPT pour les parcours d’achat externes. Cette intégration ne prouve pas que les conversations du Buyer Agent sur WhatsApp ou SMS transitent par OpenAI.
Pour une ETI française, le cadrage Agentforce RGPD commence par les flux réellement activés, pas par les marques citées dans l’annonce. L’architecture, le DPO, la sécurité et les achats doivent valider ensemble les finalités, sous-traitants, transferts, durées de conservation et droits d’accès. Cet article fournit un cadre de contrôle, pas un avis juridique.
Ce que le lancement Agentforce Commerce change concrètement
Le lancement ajoute des surfaces commerce aux usages CRM existants. Le Shopper Agent intervient sur les storefronts B2C, le Buyer Agent sur des parcours B2B incluant WhatsApp et SMS, et le Merchant Agent sur les opérations liées au catalogue. Le traitement réel dépend ensuite des canaux, sources, Actions et intégrations activés dans l’organisation.
Du point de vue des données, ces agents peuvent ajouter des sessions non authentifiées, des flux comportementaux et des prestataires de messagerie au périmètre existant. Cartographiez chaque surface séparément au lieu de supposer qu’elles suivent toutes le même trajet.
L’Agentic Commerce Search (ex-Cimulate) ajoute un moteur de recherche fondé sur l’intention. Une requête, une préférence ou une intention dérivée peut constituer une donnée personnelle si elle se rapporte à une personne identifiable. Vérifiez les entrées, les sorties conservées et les rapprochements réellement effectués avant de qualifier le traitement.
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.
Séparez les données de session éphémères des données persistées dans Data 360. Pour chaque Data Stream, documentez la finalité, la base légale et la durée de conservation. N’intégrez une session à Identity Resolution que si le rapprochement est nécessaire à cette finalité et couvert par une base légale. Le consentement peut être requis selon le traitement, mais ce n’est pas la seule base prévue par le RGPD.
Le test utile est reproductible : une session qui ne doit pas être persistée ne doit ni alimenter le profil unifié, ni rester interrogeable après l’échéance définie. Une simple capture de configuration ne suffit pas.
Surface 2 : le Buyer Agent sur WhatsApp et SMS
WhatsApp et SMS sont régulés différemment d’un storefront web. La CNIL distingue notamment la prospection de particuliers et la prospection B2B : le consentement préalable n’est pas systématiquement requis entre professionnels, mais l’information, la pertinence par rapport à l’activité et l’opposition restent à traiter. Pour chaque parcours Buyer Agent, documentez le caractère entrant ou sortant, le type de destinataire, la finalité, la base légale et le mécanisme d’opposition.
La source Salesforce confirme le Buyer Agent sur WhatsApp et SMS. Elle ne décrit ni le trajet technique complet, ni tous les sous-traitants, ni les régions de traitement. Ne déduisez donc pas un transfert vers OpenAI à partir de l’intégration ChatGPT annoncée séparément.
Cartographiez chaque variante déployée : point d’entrée, fournisseur du canal, API ou connecteur, Salesforce, modèle utilisé, journalisation et stockage. Cette cartographie détermine les contrats et informations à tenir à jour au titre des articles 28 et 30 du RGPD. Si ChatGPT ou un autre service externe intervient effectivement dans le flux, ajoutez-le sur preuve contractuelle et technique, pas par supposition.
Si les données passent déjà par MuleSoft entre l’ERP et Salesforce Commerce, cette couche peut appliquer une pseudonymisation ou une réduction de charge utile avant les Topics et Actions. Vérifiez aussi que le flux ne conserve pas une copie brute ailleurs. MuleSoft n’est pas un prérequis universel à ce contrôle.
Surface 3 : le Merchant Agent et les données catalogue
Le Merchant Agent travaille autour du catalogue et des opérations marchandes. Le risque RGPD reste faible si seules des données produit non personnelles sont exposées. Il augmente lorsque les Actions ou sources ajoutent des contrats nominatifs, des remises personnalisées ou des historiques liés à des contacts professionnels.
Classez les champs accessibles au Merchant Agent par finalité et sensibilité, quel que soit leur support technique. Si des Data Model Objects ou Calculated Insights contiennent des comportements d’achat rattachables à une personne, limitez leur exposition par permissions, Actions et tests d’accès négatifs.
Comment configurer Prompt Builder pour la conformité
Prompt Builder détermine quelles données contextuelles entrent dans certains prompts. Les templates de type Flex peuvent injecter ces données dynamiquement. Sans minimisation et test, un champ personnel peut donc atteindre le modèle alors qu’il n’est pas nécessaire à la tâche.
Trois règles concrètes pour les ETI françaises :
Premièrement, n’injectez un identifiant direct dans un prompt Flex que s’il est nécessaire à la finalité testée. Préférez un identifiant pseudonymisé lorsque l’action peut résoudre la donnée côté Salesforce sans l’exposer au modèle.
Deuxièmement, configurez le masquage du Trust Layer selon la sensibilité des champs et testez le résultat. La documentation Salesforce du Trust Layer mentionne notamment des engagements de non-rétention avec des fournisseurs de modèles. Ces engagements et le masquage sont deux contrôles parmi d’autres : permissions, minimisation du prompt, choix du modèle, journalisation et cadre contractuel restent à vérifier.
Troisièmement, rattachez chaque template Prompt Builder au traitement qu’il sert et documentez les données injectées. L’article 22 du RGPD exige une analyse spécifique lorsqu’une décision est fondée exclusivement sur un traitement automatisé et produit des effets juridiques ou similaires significatifs. Le simple usage d’un agent ne déclenche pas automatiquement cet article.
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. Elle doit identifier les composants et sous-traitants effectivement présents dans chaque parcours, y compris les fournisseurs de messagerie, moteurs de recherche et modèles externes lorsqu’ils sont activés.
Ensuite, une décision documentée sur l’analyse d’impact relative à la protection des données (AIPD). L’article 35 du RGPD la rend obligatoire lorsqu’un traitement est susceptible d’engendrer un risque élevé. L’échelle, le profilage, la surveillance et les effets sur les personnes font partie de l’analyse, sans rendre toute activation Agentforce automatiquement soumise à AIPD.
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.
Sans ce plan, le délai de réponse d’un mois devient difficile à tenir dès qu’une demande oblige plusieurs équipes et systèmes à rechercher ou supprimer les mêmes données.
Pour les organisations qui envisagent un déploiement structuré, le guide d’architecture Agentforce pour les DSI détaille les contraintes de conformité à intégrer au cadrage.
Points Clés
- La persistance d’une session et son rapprochement dans Identity Resolution exigent une finalité, une base légale et une durée documentées. Le consentement n’est pas la seule base possible.
- Salesforce confirme Buyer Agent sur WhatsApp et SMS, sans établir un transit par OpenAI. La liste des sous-traitants doit refléter le flux réellement déployé.
- Les requêtes et intentions dérivées par Agentic Commerce Search peuvent relever du RGPD si elles se rapportent à une personne identifiable ; vérifiez le traitement réel avant de conclure.
- Le Trust Layer réduit certains risques, mais ne remplace ni la minimisation, ni les permissions, ni la validation contractuelle du modèle et des canaux.
- Une AIPD est obligatoire si l’analyse conclut à un risque élevé au sens de l’article 35. Cette conclusion dépend du traitement conçu, pas du seul nom Agentforce Commerce.
