Agentforce RGPD : guide pour les DSI françaises

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 360 Platform GA sur le plan de la gouvernance

Avant la GA, la plupart des déploiements Agentforce en France restaient cantonnés à des cas d’usage internes : assistance aux commerciaux, résumés d’opportunités, génération de contenu non-personnalisé. Le périmètre était limité, le risque RGPD gérable par des garde-fous manuels.

Agentforce 360 Platform change l’équation en rendant les agents accessibles sur l’ensemble du cycle client, y compris les interactions directes avec les personnes concernées. Un agent qui répond à un client sur un portail self-service, qui traite une réclamation, ou qui qualifie une demande de résiliation, c’est un traitement automatisé de données personnelles au sens de l’article 22 du RGPD. Dès lors que ce traitement produit des effets significatifs sur la personne, l’obligation d’information, le droit d’opposition, et potentiellement l’interdiction de décision entièrement automatisée s’appliquent.

La nouveauté avec Agentforce 360, c’est aussi l’intégration native avec Data Cloud via les Data Graphs. L’Atlas Reasoning Engine peut désormais accéder à des profils unifiés enrichis par Identity Resolution, ce qui signifie que le contexte fourni à l’agent peut inclure des données consolidées depuis des sources multiples. C’est architecturalement puissant. C’est aussi exactement ce que la CNIL examine en priorité lors d’un contrôle sur l’IA générative.

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 360 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 360 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.

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. 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 a depuis renforcé son activité de contrôle sur les déploiements en production. Trois points de doctrine sont particulièrement pertinents pour Agentforce 360.

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.

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 360, 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.

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 360 Platform GA étend les agents aux interactions directes avec les personnes concernées, ce qui déclenche les obligations de l’article 22 du RGPD sur les décisions automatisées.
• 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 cloisonnement des Topics par finalité de traitement est la traduction architecturale directe du principe de limitation des finalités du RGPD : chaque Topic doit correspondre à une finalité déclarée dans le registre.
• 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.