Le partenariat VCARB-Salesforce autour d’Agentforce 360 a fait beaucoup de bruit dans la sphère enterprise. Mais pendant que les architectes anglo-saxons débattent des cas d’usage fan engagement, les DSI français ont une question plus urgente : comment déployer Agentforce RGPD-compatible sans créer un risque juridique ou de souveraineté numérique que le COMEX ne voudra jamais signer ?
Ce n’est pas une question rhétorique. C’est le blocage réel dans la majorité des ETI françaises qui évaluent Agentforce aujourd’hui.
Ce que VCARB révèle sur l’architecture Agentforce 360
Le déploiement VCARB n’est pas juste un cas d’usage sportif. C’est une démonstration publique de ce qu’Agentforce 360 signifie architecturalement : une couche d’orchestration IA qui traverse Sales Cloud, Service Cloud et Data Cloud simultanément, avec l’Atlas Reasoning Engine comme cerveau central.
Dans ce modèle, l’agent ne répond pas à des scripts. Il raisonne sur des données unifiées issues de Data Cloud, déclenche des Actions dans plusieurs clouds, et maintient un contexte conversationnel persistant. Pour VCARB, cela signifie un agent qui connaît l’historique d’achat d’un fan, son comportement sur l’application mobile, et son niveau d’engagement sur les réseaux sociaux, le tout en temps réel.
Pour une ETI française, ce même pattern soulève immédiatement trois questions que VCARB n’a pas à se poser : où résident les données traitées par l’Atlas Reasoning Engine ? Quels sous-traitants Salesforce interviennent dans la chaîne de traitement ? Et comment documenter la base légale de chaque inférence IA pour satisfaire une demande CNIL ?
Où le RGPD frotte contre l’architecture Agentforce
L’Atlas Reasoning Engine est un LLM. Quand il raisonne sur un profil client unifié dans Data Cloud, il traite des données personnelles au sens du RGPD. Ce traitement doit avoir une base légale, une finalité documentée, et une durée de conservation définie. La plupart des déploiements Agentforce que l’on voit en production aujourd’hui n’ont pas ces trois éléments formalisés.
Le problème s’aggrave avec Identity Resolution. Quand Data Cloud fusionne des profils issus de plusieurs systèmes legacy via ses rulesets de correspondance, il crée un Unified Individual qui n’existait pas dans les systèmes sources. Ce nouvel objet est-il couvert par le consentement initial collecté dans chaque système ? Juridiquement, la réponse est souvent non.
Dans les organisations avec plusieurs centaines de milliers de profils clients, l’Identity Resolution peut générer des millions d’Unified Individuals en quelques heures. Sans gouvernance préalable des rulesets, c’est un risque RGPD massif créé automatiquement par la plateforme.
Autre point de friction : les Prompt Builder templates. Un template de type Flex qui injecte des données client dans un prompt envoyé à un LLM constitue un traitement automatisé de données personnelles. Si ce traitement produit une décision ou une recommandation qui affecte l’utilisateur, l’article 22 du RGPD peut s’appliquer, avec obligation d’information et droit d’opposition.
L’architecture qui fonctionne pour les ETI françaises
La bonne approche n’est pas de renoncer à Agentforce. C’est de construire une couche de gouvernance des données avant de déployer les agents.
Étape 1 : cartographier les flux avant d’activer les Data Streams. Chaque Data Stream entrant dans Data Cloud doit être documenté avec sa base légale, sa finalité, et les catégories de données personnelles concernées. Ce travail est fastidieux mais non négociable. En pratique, les ETI qui sautent cette étape se retrouvent à devoir désactiver des Data Streams en production après un audit CNIL, ce qui casse la cohérence des profils unifiés.
Étape 2 : segmenter les Unified Individuals par niveau de consentement. Data Cloud permet de créer des Segments basés sur des attributs de consentement. L’architecture correcte consiste à créer un Data Model Object dédié au consentement, alimenté par le système de gestion des préférences existant, et à l’utiliser comme filtre systématique dans toutes les définitions de Segments. Les agents Agentforce ne doivent jamais raisonner sur des profils dont le consentement n’est pas vérifié.
Étape 3 : contraindre les Topics et Instructions des agents. Dans Agentforce, les Topics définissent le périmètre d’action d’un agent. Les Instructions définissent son comportement. C’est ici que la conformité RGPD se traduit en configuration concrète : une Instruction peut interdire à l’agent de mentionner des inférences basées sur des données comportementales si l’utilisateur n’a pas consenti au profilage. Une Action peut être conditionnée à la vérification du consentement avant exécution.
Étape 4 : tracer chaque raisonnement de l’Atlas Reasoning Engine. Salesforce expose des logs de raisonnement via l’Agentforce Testing Center, mais en production, ces logs doivent être archivés et exploitables pour répondre à une demande d’accès RGPD. L’architecture doit prévoir un pipeline d’export de ces logs vers un système de stockage conforme, avec une durée de conservation alignée sur la politique de l’organisation.
Pour aller plus loin sur la configuration des agents dans ce contexte, l’article sur les bonnes pratiques Prompt Builder détaille comment structurer les templates pour minimiser l’exposition des données personnelles dans les prompts.
Souveraineté numérique : la question que les ESN évitent
La souveraineté numérique est distincte du RGPD, mais les deux se superposent dans les décisions d’architecture. Le RGPD encadre le traitement des données personnelles. La souveraineté numérique concerne la capacité à contrôler où et comment les données stratégiques sont traitées, indépendamment de la légalité.
Pour les ETI françaises dans des secteurs sensibles (défense, santé, infrastructure critique), la question n’est pas seulement “est-ce légal ?” mais “est-ce acceptable que nos données clients soient traitées par des LLM hébergés hors de l’Union Européenne ?”
Salesforce a fait des progrès sur ce point. Les régions de données EU sont disponibles, et Hyperforce permet de choisir la localisation des données. Mais l’Atlas Reasoning Engine appelle des modèles de fondation dont la localisation exacte du traitement n’est pas toujours transparente dans la documentation contractuelle standard.
L’architecture qui répond à cette contrainte passe par deux leviers. Premier levier : utiliser les modèles Einstein intégrés à Salesforce plutôt que des modèles externes, car leur traitement reste dans l’infrastructure Salesforce avec les garanties contractuelles associées. Deuxième levier : pour les données les plus sensibles, concevoir des Actions Agentforce qui appellent des APIs internes via External Services plutôt que de passer les données directement dans les prompts. L’agent raisonne sur des résultats d’API, pas sur les données brutes.
Cette approche a un coût en complexité d’architecture, mais elle est la seule qui permette de répondre honnêtement à un DSI qui demande “où passent nos données clients quand l’agent répond ?”
Ce que les ETI font mal en pratique
Le pattern d’échec le plus fréquent : déployer Agentforce comme un projet IT sans impliquer le DPO dès la phase de conception. Le DPO arrive en fin de projet, identifie des traitements non conformes, et le déploiement est bloqué ou dégradé.
La deuxième erreur : traiter la conformité RGPD comme une checklist à cocher plutôt que comme une contrainte architecturale. Une checklist produit de la documentation. Une contrainte architecturale produit des garde-fous techniques qui fonctionnent même quand personne ne vérifie.
Troisième erreur : sous-estimer la complexité de l’Identity Resolution dans un contexte multi-systèmes. Dans les organisations avec 7 systèmes legacy ou plus, les rulesets de correspondance par défaut créent des fusions de profils incorrectes. Un client B2B peut se retrouver fusionné avec son entreprise. Un prospect peut être fusionné avec un client existant. Ces erreurs ne sont pas juste des problèmes de qualité de données : elles constituent des traitements non conformes si les profils fusionnés ont des bases légales différentes.
La mise en place d’un Centre d’Excellence Salesforce est souvent le cadre organisationnel qui permet d’éviter ces erreurs, en créant une gouvernance transverse entre les équipes IT, juridique et métier avant le déploiement.
Points Clés
- L’Atlas Reasoning Engine traite des données personnelles au sens du RGPD dès qu’il raisonne sur des profils Data Cloud : chaque déploiement Agentforce nécessite une analyse d’impact (AIPD) préalable.
- Identity Resolution crée des Unified Individuals qui peuvent ne pas être couverts par les consentements collectés dans les systèmes sources : les rulesets doivent être validés juridiquement avant activation.
- La conformité RGPD dans Agentforce se configure dans les Topics, Instructions et Actions des agents, pas seulement dans les paramètres de Data Cloud.
- La souveraineté numérique exige de choisir entre modèles Einstein intégrés et modèles externes selon la sensibilité des données, avec une documentation contractuelle explicite sur la localisation du traitement.
- Les ETI qui réussissent leurs déploiements Agentforce RGPD-compatibles impliquent le DPO dès la phase de conception de l’architecture Data Cloud, pas en validation finale.
