L’orchestration multi-agents de Summer ‘26 n’est pas une évolution cosmétique. C’est un changement de paradigme qui déplace la responsabilité de traitement des données personnelles vers des couches d’infrastructure que la plupart des DSI français n’ont pas encore cartographiées dans leur registre RGPD.
Le problème n’est pas Agentforce en soi. C’est que les équipes de gouvernance IT traitent encore chaque agent comme un outil isolé, alors que Summer ‘26 introduit des chaînes de raisonnement où plusieurs agents se transmettent du contexte, des décisions intermédiaires, et potentiellement des données à caractère personnel, sans que ces flux soient visibles dans les journaux d’audit traditionnels.
Agentforce RGPD n’est pas un sujet de conformité à cocher après déploiement. C’est une contrainte architecturale à intégrer dès la conception des Topics et des Actions.
Ce que Summer ‘26 change concrètement pour les architectes
Avant Summer ‘26, un agent Agentforce opérait dans un périmètre relativement borné : un Topic, un ensemble d’Actions, un canal d’entrée. L’Atlas Reasoning Engine raisonnait en boucle fermée. La traçabilité était imparfaite, mais le périmètre de traitement restait identifiable.
Summer ‘26 introduit la coordination native entre agents spécialisés. Un agent commercial peut déléguer à un agent de qualification, qui lui-même interroge un agent d’enrichissement connecté à Data Cloud. Chaque handoff transporte du contexte. Ce contexte peut contenir des données personnelles : identité du prospect, historique d’interaction, scores calculés à partir de Calculated Insights.
Dans ce modèle, la question “qui traite quoi” devient architecturalement complexe. L’Atlas Reasoning Engine orchestre des décisions distribuées. Les données circulent entre agents via des mécanismes internes qui ne génèrent pas automatiquement de traces exploitables pour un DPO.
Pour les organisations avec plus de 3 000 points de contact retail ou B2B, ce n’est pas théorique. Un pipeline multi-agents qui qualifie des leads en temps réel peut traiter des dizaines de milliers de profils par heure, chacun potentiellement soumis aux droits d’accès, de rectification et d’effacement du RGPD.
La cartographie des flux de données personnelles dans une architecture multi-agents
La première obligation pratique est de cartographier les flux de données personnelles à travers la chaîne d’agents, pas seulement à l’entrée et à la sortie du système.
L’architecture qui fonctionne ici repose sur trois niveaux de traçabilité :
Niveau Topic : chaque Topic doit avoir une classification de sensibilité des données explicite dans sa documentation. Un Topic “Qualification Prospect” qui accède à des Data Graphs contenant des données comportementales est un traitement à risque élevé au sens de l’article 35 du RGPD. Cela déclenche une obligation d’Analyse d’Impact relative à la Protection des Données (AIPD).
Niveau Action : chaque Action qui appelle un Data Stream, un DMO, ou un système externe via External Services doit être documentée comme un sous-traitement. Si l’Action appelle une API tierce pour enrichir un profil, ce tiers est un sous-traitant au sens du RGPD, et un contrat de sous-traitance conforme à l’article 28 est obligatoire.
Niveau handoff inter-agents : c’est le point aveugle de la plupart des déploiements actuels. Quand l’Atlas Reasoning Engine passe du contexte d’un agent à un autre, ce contexte doit être loggé avec suffisamment de granularité pour reconstituer le traitement subi par un enregistrement individuel. Platform Events peut servir de mécanisme de journalisation si l’architecture est conçue pour l’émettre à chaque transition.
Sans cette cartographie à trois niveaux, répondre à une demande d’exercice de droits (accès, effacement) dans le délai réglementaire d’un mois devient opérationnellement impossible dès que le volume dépasse quelques centaines de demandes par mois.
Le problème spécifique des Instructions dans un contexte RGPD français
Les Instructions Agentforce sont le mécanisme par lequel on définit le comportement d’un agent : ton, limites, règles métier. Dans un contexte RGPD, les Instructions sont aussi le seul endroit où l’on peut encoder des contraintes de traitement directement dans la logique de l’agent.
En pratique, les ESN françaises qui déploient Agentforce pour leurs clients ETI négligent systématiquement cet aspect. Les Instructions sont rédigées pour optimiser la performance métier, pas pour refléter les bases légales de traitement.
L’approche correcte est de traiter les Instructions comme une couche de politique de données. Concrètement :
- Si la base légale du traitement est le consentement, l’Instruction doit inclure une vérification explicite que le consentement est actif avant tout accès aux données personnelles via Data Cloud.
- Si le traitement repose sur l’intérêt légitime, l’Instruction doit encoder les limites de la mise en balance : pas de profilage comportemental au-delà d’un certain niveau de granularité, pas de décision automatisée sur des catégories sensibles.
- Les droits d’opposition doivent se traduire par des flags dans les DMOs que les Actions vérifient systématiquement avant d’agir.
Ce n’est pas de la sur-ingénierie. C’est la seule façon de rendre le système auditable par la CNIL sans avoir à reconstruire la logique de traitement après coup.
Pour aller plus loin sur la conception des Instructions et des Prompt Builder templates dans ce contexte, l’article sur les bonnes pratiques Prompt Builder couvre les patterns de templating qui s’appliquent directement ici.
Gouvernance IT : ce que Summer ‘26 impose comme changement organisationnel
La question technique est résoluble. La question organisationnelle est plus difficile.
Dans la plupart des ETI françaises, la gouvernance Salesforce est portée par la DSI avec un niveau d’implication variable du DPO. Summer ‘26 force une convergence de ces deux fonctions sur les sujets d’architecture Agentforce.
Le pattern qui émerge dans les organisations qui gèrent cette transition correctement est un comité de validation des agents, distinct du comité de gouvernance Salesforce classique. Ce comité réunit l’architecte solution, le DPO, et un représentant métier. Il valide chaque nouveau Topic avant mise en production sur trois critères : base légale documentée, cartographie des flux de données personnelles complète, mécanisme de journalisation opérationnel.
Ce n’est pas un processus lourd si l’architecture est bien conçue en amont. Un Topic bien documenté passe ce comité en moins d’une heure. Un Topic mal conçu révèle des problèmes qui auraient coûté beaucoup plus cher à corriger après déploiement.
La CNIL a publié des lignes directrices sur les systèmes d’IA qui s’appliquent directement aux agents Agentforce dès lors qu’ils prennent des décisions ayant un effet sur des personnes physiques. Les organisations qui déploient Summer ‘26 sans avoir lu ces lignes directrices s’exposent à des risques réels, pas hypothétiques.
Transferts de données et souveraineté : le point de friction Summer ‘26
Summer ‘26 étend les capacités de Slack-first workflows et d’intégration Tableau MCP. Pour les DSI français, chaque nouvelle surface d’intégration est une question de transfert de données potentiel.
Slack est opéré par Salesforce depuis l’acquisition, mais les données Slack peuvent résider dans des régions différentes selon la configuration du tenant. Si un agent Agentforce utilise Slack comme canal de sortie pour communiquer des informations personnelles à un commercial, et que le tenant Slack est configuré sur une région non-UE, c’est un transfert hors UE qui nécessite des garanties appropriées au sens du chapitre V du RGPD.
Ce n’est pas un problème insoluble. Salesforce propose des options de résidence des données en UE. Mais c’est un paramètre de configuration qui doit être vérifié explicitement, pas supposé correct par défaut.
Le même raisonnement s’applique aux Data Streams qui alimentent les agents. Si un Data Stream ingère des données depuis un système legacy hébergé hors UE, la chaîne de traitement multi-agents hérite de cette contrainte de transfert. L’architecture de Data Cloud doit documenter la résidence de chaque source de données avant que les agents puissent l’utiliser en production.
Points Clés
- L’orchestration multi-agents de Summer ‘26 crée des flux de données personnelles inter-agents que les registres RGPD traditionnels ne capturent pas automatiquement. La cartographie doit descendre au niveau des handoffs entre agents, pas seulement aux entrées/sorties du système.
- Les Instructions Agentforce sont la couche où les contraintes RGPD doivent être encodées : vérification de consentement, limites de profilage, respect des droits d’opposition. Les laisser purement métier est une erreur architecturale.
- Chaque Action qui appelle un système externe via External Services est un sous-traitement au sens de l’article 28 du RGPD. La documentation contractuelle doit suivre l’architecture technique.
- Platform Events est le mécanisme le plus pragmatique pour journaliser les transitions inter-agents avec suffisamment de granularité pour répondre aux demandes d’exercice de droits dans les délais réglementaires.
- Summer ‘26 force une convergence organisationnelle entre DSI et DPO sur la gouvernance Agentforce. Les organisations qui anticipent cette convergence avec un comité de validation des agents réduisent leur risque réglementaire sans ralentir les déploiements.
