La disponibilité générale d’Agentforce 360 Platform change le calcul pour les DSI françaises. Ce n’est plus une question de “si” déployer des agents IA en production, mais de “comment” le faire sans exposer l’organisation à un risque CNIL documenté.
Le problème est structurel. Agentforce RGPD n’est pas un sujet que l’on règle avec une clause contractuelle et un DPA signé avec Salesforce. C’est une question d’architecture de données, de traçabilité des décisions automatisées, et de contrôle effectif sur ce que l’Atlas Reasoning Engine fait avec les données personnelles au moment du raisonnement. Les DSI qui traitent ça comme un problème juridique à déléguer au DPO vont se retrouver avec un audit CNIL sur les bras.
Ce que change Agentforce 3 sur le plan de la gouvernance
Avec Agentforce 3, Salesforce a introduit plusieurs changements architecturaux qui modifient directement l’équation de gouvernance. Le nouvel Agentforce Builder repose sur un moteur graph-based pour les nouveaux agents, tandis que les agents existants continuent de fonctionner sur l’ancienne architecture. Cette coexistence de deux moteurs dans un même org crée une complexité de gouvernance que les DSI doivent anticiper : les politiques de logging et de contrôle d’accès ne s’appliquent pas de façon identique aux deux générations.
Le Command Center unifié introduit avec Agentforce 3 est la première réponse native de Salesforce au besoin d’audit à l’échelle. Il centralise le suivi des agents en production et offre une visibilité sur les Topics activés et les Actions exécutées. C’est utile, mais insuffisant pour une conformité RGPD complète : le Command Center ne capture pas les données personnelles effectivement injectées dans les prompts, ni la base légale associée à chaque traitement.
L’ajout du support MCP (Model Context Protocol) et l’élargissement d’AgentExchange introduisent un nouveau vecteur de risque. Dès qu’un agent Agentforce se connecte à un service tiers via MCP, le périmètre du traitement de données personnelles s’étend potentiellement hors du stack Salesforce. Chaque connecteur tiers doit être audité pour sa conformité RGPD avant activation en production.
Sur l’Atlas Reasoning Engine, Salesforce a réduit la latence et ajouté une recherche web avec citations intégrées. Cette dernière fonctionnalité mérite une attention particulière : si l’agent peut enrichir son raisonnement avec des données web en temps réel, la question de la minimisation des données et de la finalité du traitement se pose différemment selon le cas d’usage. Un agent de support client qui interroge le web pour répondre à une question technique est dans un périmètre acceptable. Un agent qui croise des données personnelles CRM avec des résultats web pour qualifier un profil client entre dans une zone grise que la CNIL examinerait de près.
Un point qui reste inchangé et que les DSI doivent intégrer : Agentforce ne supporte pas encore de modèles souverains européens comme Mistral ou Aleph Alpha. Les inférences LLM passent par des modèles comme Claude Sonnet via Amazon Bedrock. L’hébergement Hyperforce en EU couvre l’infrastructure Salesforce, mais la chaîne complète d’inférence doit être auditée pour confirmer que les données personnelles ne transitent pas hors de l’UE.
Les trois vecteurs de risque que les DSI sous-estiment
Traçabilité du raisonnement. L’Atlas Reasoning Engine opère en plusieurs étapes de raisonnement avant de produire une réponse ou de déclencher une action. Ces étapes intermédiaires ne sont pas loguées par défaut dans un format exploitable pour un audit RGPD. En pratique, si la CNIL demande à reconstituer pourquoi un agent a pris une décision spécifique pour un client identifié, la réponse “le modèle a raisonné ainsi” n’est pas suffisante. Il faut une architecture de logging qui capture le contexte injecté, les Topics activés, les Actions exécutées, et les données personnelles effectivement utilisées dans le prompt.
Minimisation des données dans les prompts. Prompt Builder permet de construire des templates qui injectent des données CRM dans le contexte de l’agent. Sans gouvernance explicite, il est trivial de construire un template qui injecte l’intégralité du profil Data Cloud d’un client alors que l’agent n’a besoin que de deux ou trois champs. La minimisation des données, principe fondamental du RGPD, doit être appliquée au niveau de la conception des Data Graphs et des templates Prompt Builder, pas en aval.
Transferts hors UE. Salesforce opère des datacenters en France et en Allemagne. Mais l’inférence LLM pour Agentforce peut impliquer des appels vers des modèles hébergés hors de l’UE selon la configuration. Les DSI doivent auditer précisément quelles couches du stack Agentforce 3 restent dans le périmètre EU et lesquelles ne le sont pas. Ce n’est pas une information que Salesforce met en avant dans ses fiches produit.
L’architecture de gouvernance qui fonctionne en pratique
Les organisations qui déploient Agentforce en conformité RGPD sans bloquer le time-to-value convergent vers un pattern en trois couches.
La première couche est la gouvernance des données en entrée. Elle se joue dans Data Cloud, au niveau des Data Streams et des Data Model Objects. Chaque DMO qui peut alimenter un agent doit être étiqueté avec sa base légale de traitement, sa durée de conservation, et ses restrictions d’usage. Les Data Graphs utilisés par Agentforce doivent être construits avec des vues restreintes, pas avec l’intégralité du profil unifié. Identity Resolution peut produire un Unified Individual très riche, mais l’agent n’a pas besoin de tout ce contexte pour la majorité des cas d’usage.
La deuxième couche est la gouvernance des Topics et Actions dans Agentforce Builder. Chaque Topic doit avoir un périmètre documenté qui correspond à une finalité de traitement déclarée dans le registre RGPD. Une action qui accède à l’historique médical d’un client dans un contexte assurance ne peut pas être activée dans un Topic de support commercial générique. Ce cloisonnement par finalité est la traduction architecturale du principe de limitation des finalités du RGPD. Avec le moteur graph-based d’Agentforce 3, ce cloisonnement doit être revu pour les nouveaux agents : la logique de routage entre Topics fonctionne différemment et les politiques de contrôle d’accès doivent être reconfigurées explicitement.
La troisième couche est l’audit trail. En pratique, cela signifie utiliser Platform Events pour capturer chaque interaction agent avec les métadonnées nécessaires à la traçabilité : identifiant de la personne concernée, Topics activés, Actions exécutées, données personnelles injectées dans le contexte (par référence, pas en clair), timestamp, et résultat. Le Command Center d’Agentforce 3 complète ce dispositif pour le monitoring opérationnel, mais ne le remplace pas pour la traçabilité RGPD. Ces événements doivent être archivés dans un système qui permet une recherche par personne concernée pour répondre aux demandes d’accès RGPD dans les délais légaux d’un mois.
Pour aller plus loin sur la relation entre Data Cloud et la conformité des profils unifiés, l’article sur l’architecture Data Cloud et Identity Resolution détaille les rulesets de correspondance et leurs implications sur la qualité des données personnelles consolidées.
Ce que les ESN françaises font mal sur ce sujet
Un pattern récurrent dans les projets Agentforce portés par des ESN françaises : la gouvernance RGPD est traitée comme une phase de projet distincte, planifiée après la mise en production du MVP. C’est une erreur de séquençage qui coûte cher.
Les décisions d’architecture prises dans les premières semaines d’un projet Agentforce, notamment la structure des Data Graphs, le périmètre des Topics, et le modèle de logging, déterminent 80% de la surface de risque RGPD finale. Revenir sur ces décisions après la mise en production implique des refactorisations coûteuses et des périodes de non-conformité documentées.
L’autre erreur fréquente est de confondre les certifications Salesforce (ISO 27001, SOC 2) avec la conformité RGPD de l’implémentation. Salesforce peut être certifié sur la sécurité de son infrastructure et l’implémentation client peut quand même violer le RGPD sur la minimisation des données ou la traçabilité des décisions automatisées. Ce sont deux niveaux distincts de responsabilité.
Les DSI d’ETI qui n’ont pas de ressource interne spécialisée sur l’intersection Agentforce et RGPD ont intérêt à consulter un architecte solution indépendant avant de valider l’architecture cible, pas après. La page /services/agentforce-architecture détaille les patterns de gouvernance applicables à ce type de déploiement.
La position de la CNIL sur l’IA générative en 2026
La CNIL a publié ses recommandations sur les systèmes d’IA générative en 2024 et maintient depuis une activité de contrôle soutenue sur les déploiements en production. Trois points de doctrine restent particulièrement pertinents pour Agentforce 3.
D’abord, la CNIL considère que l’utilisation de données personnelles pour contextualiser un LLM, même sans fine-tuning, constitue un traitement au sens du RGPD. L’injection de données client dans un prompt Agentforce est donc un traitement qui doit avoir une base légale, une finalité documentée, et respecter la minimisation. L’ajout de la recherche web en temps réel dans Agentforce 3 ne change pas cette doctrine : si la recherche croise des données personnelles, le traitement doit être déclaré.
Ensuite, pour les traitements qui produisent des effets significatifs sur les personnes, une Analyse d’Impact relative à la Protection des Données (AIPD) est obligatoire avant la mise en production. Dans le contexte Agentforce 3, cela concerne typiquement les agents qui gèrent des réclamations, des demandes de résiliation, ou des décisions de crédit. L’AIPD doit être conduite avec une compréhension technique suffisante du fonctionnement de l’Atlas Reasoning Engine pour être crédible, y compris sur les nouvelles capacités de raisonnement introduites avec Agentforce 3.
Enfin, la CNIL attend que les organisations puissent démontrer le contrôle effectif sur les traitements automatisés, pas seulement l’existence de politiques. Un registre de traitement à jour et une architecture de logging opérationnelle sont les deux preuves minimales attendues lors d’un contrôle.
Points Clés
- Agentforce 3 introduit un moteur graph-based pour les nouveaux agents et un Command Center d’audit, mais ni l’un ni l’autre ne couvre la traçabilité RGPD complète : la couche Platform Events reste indispensable.
- L’Atlas Reasoning Engine ne logue pas ses étapes de raisonnement par défaut dans un format exploitable pour un audit CNIL : cette architecture de traçabilité doit être construite explicitement via Platform Events.
- La minimisation des données doit être appliquée au niveau des Data Graphs et des templates Prompt Builder, pas en aval : un Unified Individual Data Cloud peut contenir des centaines d’attributs dont l’agent n’a besoin que d’une fraction.
- Le support MCP et AgentExchange dans Agentforce 3 étendent le périmètre de traitement des données personnelles hors du stack Salesforce : chaque connecteur tiers doit être audité avant activation en production.
- Les ESN qui traitent la gouvernance RGPD comme une phase post-MVP génèrent des refactorisations coûteuses : les décisions d’architecture des premières semaines déterminent 80% de la surface de risque finale.
