Les annonces TDX 2026 ont mis l’orchestration multi-agents Agentforce au centre de la roadmap Salesforce. Pour les DSI américaines, c’est une question d’architecture. Pour les DSI françaises, c’est d’abord une question de conformité RGPD, et ensuite seulement une question d’architecture.
La distinction n’est pas anodine. Déployer Agentforce RGPD-compatible dans un contexte multi-agents n’est pas un problème de configuration, c’est un problème de gouvernance de flux de données. Et la plupart des organisations qui se lancent aujourd’hui font l’erreur de traiter le RGPD comme une case à cocher post-déploiement.
Pourquoi l’orchestration multi-agents crée un risque RGPD spécifique
Dans un déploiement mono-agent classique, le périmètre de traitement des données personnelles est relativement délimité. Un agent Service Cloud répond à des tickets, accède à un profil client, génère une réponse. La chaîne de traitement est courte et auditable.
L’orchestration multi-agents change fondamentalement cette équation. Avec les patterns annoncés à TDX 2026, un agent orchestrateur peut déléguer dynamiquement à des sous-agents spécialisés : un agent de qualification commerciale, un agent de vérification de conformité contractuelle, un agent de personnalisation marketing. Chaque délégation est un transfert de contexte. Chaque transfert de contexte peut inclure des données personnelles.
Le problème architectural est précis : l’Atlas Reasoning Engine, qui pilote le raisonnement de l’agent orchestrateur, construit un contexte cumulatif à travers les étapes de raisonnement. Ce contexte peut agréger des données issues de Data Cloud via des Data Graphs, des Calculated Insights, des résultats d’Identity Resolution. Quand ce contexte est passé à un sous-agent, vous avez techniquement un transfert de données personnelles entre deux systèmes de traitement distincts, même s’ils tournent tous les deux dans votre org Salesforce.
La CNIL a une position claire sur ce point : la complexité technique d’un système ne réduit pas les obligations de traçabilité. Si vous ne pouvez pas produire un registre des traitements qui documente chaque flux de données personnelles dans votre chaîne multi-agents, vous êtes en défaut.
Ce que TDX 2026 a changé dans l’équation
TDX 2026 a introduit des capacités d’orchestration qui rendent le problème plus aigu, mais aussi plus adressable. Deux éléments méritent attention.
D’abord, les Topics et Actions des agents peuvent maintenant être structurés avec une granularité plus fine sur le périmètre de données accessible. Un sous-agent peut être configuré pour n’accéder qu’à un sous-ensemble de DMOs (Data Model Objects) dans Data Cloud, sans visibilité sur le profil complet de l’Unified Individual. C’est un levier de minimisation des données au sens RGPD, mais il faut l’activer explicitement dans la configuration des Topics, pas dans les paramètres généraux de l’org.
Ensuite, les guardrails Flow permettent maintenant d’intercepter les transitions entre agents pour appliquer des contrôles conditionnels. En pratique, cela signifie qu’on peut insérer une vérification de consentement ou de base légale de traitement avant qu’un agent orchestrateur passe le contexte à un sous-agent spécialisé. Ce n’est pas une fonctionnalité RGPD native, c’est un pattern d’architecture que les équipes doivent construire délibérément.
Pour les DSI d’ETI françaises qui travaillent avec des ESN sur leurs déploiements Agentforce, la question à poser immédiatement est : votre partenaire a-t-il une pratique de conception des guardrails Flow orientée conformité, ou traite-t-il le RGPD comme un sujet juridique séparé de l’architecture technique ?
L’architecture de contrôle qui fonctionne en pratique
Dans les organisations qui ont réussi à déployer de l’orchestration multi-agents en environnement réglementé, le pattern architectural convergent s’articule autour de trois niveaux de contrôle.
Niveau 1 : Isolation des contextes par base légale. Chaque agent ou groupe d’agents est associé à une base légale de traitement spécifique (consentement, intérêt légitime, exécution contractuelle). Les Data Streams qui alimentent ces agents sont segmentés en conséquence dans Data Cloud. Un agent commercial qui opère sur base d’intérêt légitime n’accède pas aux mêmes Data Graphs qu’un agent de personnalisation marketing qui requiert un consentement explicite. Cette séparation est implémentée au niveau des Segments et des permissions d’accès aux DMOs, pas au niveau applicatif.
Niveau 2 : Traçabilité des transferts de contexte. Chaque fois que l’agent orchestrateur délègue à un sous-agent, un Platform Event est émis avec les métadonnées du transfert : identifiant de l’agent source, identifiant de l’agent cible, catégories de données personnelles incluses dans le contexte, timestamp. Ces événements alimentent un objet de journalisation dédié dans Salesforce, consultable par le DPO sans accès aux données elles-mêmes. C’est la différence entre une architecture auditable et une architecture opaque.
Niveau 3 : Guardrails de consentement en temps réel. Avant toute activation d’un sous-agent qui traite des données de catégorie sensible ou qui opère sur base de consentement, un Flow vérifie l’état du consentement dans Data Cloud. Si le consentement est absent ou révoqué, le Flow interrompt la délégation et route l’interaction vers un canal humain. Ce pattern ajoute une latence de 200 à 400 millisecondes sur les transitions inter-agents, ce qui est acceptable pour la quasi-totalité des cas d’usage enterprise.
L’article sur l’architecture Data Cloud et Agentforce détaille comment structurer les Data Graphs pour que cette vérification de consentement soit performante à l’échelle.
Les erreurs que font les DSI françaises en ce moment
La première erreur est de déléguer la conformité RGPD au DPO sans lui donner les outils pour auditer l’architecture technique. Un DPO qui ne peut pas interroger les journaux de transfert de contexte inter-agents ne peut pas remplir son rôle. L’architecture doit produire des artefacts lisibles par des non-développeurs.
La deuxième erreur est de traiter les Instructions des agents Agentforce comme un substitut aux contrôles techniques. Les Instructions définissent le comportement de l’Atlas Reasoning Engine, mais elles ne constituent pas une garantie technique. Un agent peut être instruit de “ne jamais mentionner les données de santé”, mais si les Data Graphs auxquels il accède contiennent des données de santé, l’instruction est insuffisante au regard du RGPD. La minimisation des données doit être implémentée au niveau de l’accès aux données, pas au niveau du prompt.
La troisième erreur, et la plus coûteuse, est de déployer en production sans avoir cartographié les flux de données personnelles dans le registre des traitements. En France, la CNIL peut demander ce registre à tout moment. Une organisation qui déploie de l’orchestration multi-agents sans mise à jour du registre est en infraction, indépendamment de la qualité technique de son déploiement.
Pour les DSI qui gèrent simultanément la pression d’adoption IA et les obligations réglementaires, la gouvernance Salesforce comme framework structurant reste le point d’ancrage le plus solide avant de scaler l’orchestration.
Le cadre décisionnel pour les DSI françaises
Avant de valider un déploiement multi-agents Agentforce en production, quatre questions doivent avoir une réponse documentée.
Premièrement : chaque sous-agent a-t-il un périmètre de données explicitement délimité dans sa configuration Topics, avec une correspondance documentée vers une base légale de traitement RGPD ?
Deuxièmement : les transferts de contexte inter-agents génèrent-ils des événements traçables, consultables par le DPO sans accès aux données personnelles elles-mêmes ?
Troisièmement : les guardrails Flow qui interceptent les transitions inter-agents ont-ils été testés avec des scénarios de consentement révoqué et de données hors périmètre ?
Quatrièmement : le registre des traitements a-t-il été mis à jour pour refléter les nouveaux flux de données créés par l’orchestration multi-agents ?
Si l’une de ces questions n’a pas de réponse documentée, le déploiement n’est pas prêt pour la production, quelle que soit la qualité de l’implémentation technique.
Les architectes qui travaillent sur ces déploiements peuvent s’appuyer sur le cadre détaillé disponible sur la page architecture Agentforce pour structurer cette validation avant mise en production.
Points Clés
- L’orchestration multi-agents Agentforce crée des flux de transfert de contexte entre sous-agents qui constituent des traitements de données personnelles distincts au sens RGPD, même au sein d’une seule org Salesforce.
- La minimisation des données doit être implémentée au niveau des Topics et des accès aux DMOs Data Cloud, pas au niveau des Instructions de l’agent, qui ne constituent pas une garantie technique opposable.
- Un pattern d’architecture viable repose sur trois niveaux : isolation des contextes par base légale, traçabilité des transferts via Platform Events, et guardrails Flow de vérification de consentement en temps réel (latence typique : 200-400 ms par transition inter-agents).
- Les guardrails Flow introduits à TDX 2026 permettent d’intercepter les délégations inter-agents pour des contrôles de conformité, mais ce pattern doit être conçu délibérément, il n’est pas activé par défaut.
- Avant tout déploiement multi-agents en production, le registre des traitements CNIL doit être mis à jour pour documenter chaque nouveau flux de données personnelles créé par l’orchestration.
