L’orchestration multi-agents de Summer ‘26 n’est pas une évolution incrémentale. C’est un changement de régime : plusieurs agents Salesforce peuvent désormais se déléguer des tâches, prendre des décisions enchaînées, et agir sur des données clients sans intervention humaine à chaque étape. Pour une ETI française avec 50 000 contacts dans Sales Cloud et un Data Cloud actif, cette architecture soulève immédiatement une question que la plupart des DSI n’ont pas encore posée : qui est responsable de la décision automatisée, et comment le prouvez-vous à la CNIL ?
Agentforce conformité n’est pas un sujet de DPO. C’est un sujet d’architecture.
Ce que Summer ‘26 change concrètement dans l’orchestration
Avant Summer ‘26, un agent Agentforce opérait dans un périmètre défini par ses Topics et ses Actions. L’Atlas Reasoning Engine raisonnait, mais dans un espace relativement contrôlé. La nouveauté de cette release, c’est la capacité d’orchestration entre agents : un agent “coordinateur” peut invoquer des agents spécialisés, leur transmettre du contexte, et consolider leurs sorties pour produire une action finale.
En pratique, cela ressemble à ceci : un agent commercial reçoit une demande client, délègue l’analyse de risque crédit à un agent financier, interroge un agent logistique sur les délais, et génère une proposition commerciale personnalisée, le tout sans qu’un commercial ait validé chaque étape intermédiaire.
L’efficacité opérationnelle est réelle. Mais chaque délégation entre agents est une décision automatisée au sens de l’article 22 du RGPD si elle produit un effet juridique ou affecte significativement la personne concernée. Dans une ETI industrielle ou retail, “affecter significativement” peut inclure une offre de prix différenciée, un refus de crédit, ou une priorisation de service.
Summer ‘26 introduit également des améliorations sur les Data Graphs dans Data Cloud, avec des jointures pré-calculées plus granulaires. Couplé à l’Identity Resolution et aux Calculated Insights, un agent peut désormais accéder à une vue unifiée d’un individu avec une latence réduite à 2-3 minutes en activation temps réel. C’est précisément ce niveau de précision qui rend la question de la base légale de traitement non négociable.
Pourquoi les ETI françaises sont particulièrement exposées
Les grandes entreprises ont des équipes juridiques dédiées et des DPO internes qui ont déjà cartographié leurs traitements automatisés. Les PME, elles, n’ont souvent pas de déploiement Salesforce suffisamment sophistiqué pour que la question se pose.
Les ETI françaises sont dans l’angle mort. Elles ont la sophistication technique pour déployer Agentforce avec Data Cloud (et de plus en plus d’ESN françaises proposent ces architectures), mais elles n’ont pas nécessairement la maturité de gouvernance pour documenter ce que font leurs agents en production.
Le problème structurel est le suivant : dans Salesforce, les Instructions d’un agent définissent son comportement, mais elles ne constituent pas une documentation de traitement au sens du registre RGPD. Un agent qui croise des données de Data Cloud (profil unifié via Identity Resolution) avec des données transactionnelles de Commerce Cloud pour générer une offre personnalisée effectue un traitement de données à caractère personnel. Ce traitement doit avoir une base légale, une finalité documentée, et une durée de conservation définie.
Aucune de ces informations n’est capturée automatiquement dans la configuration Agentforce.
À l’échelle d’une ETI avec 3 à 5 agents en production et une dizaine d’Actions par agent, le nombre de traitements implicites non documentés peut dépasser rapidement la centaine. C’est un risque CNIL concret, pas théorique.
L’architecture de gouvernance qui fonctionne
La bonne approche n’est pas de ralentir le déploiement Agentforce en attendant une clarification juridique. C’est d’intégrer la traçabilité dans l’architecture dès la conception.
Trois principes structurants :
Traçabilité des décisions par agent. Chaque Action d’un agent qui produit un effet sur un enregistrement client doit écrire un log structuré. Platform Events est le mécanisme natif Salesforce pour cela. Un Platform Event déclenché à chaque décision significative (avec l’identifiant de l’agent, l’Action exécutée, les données sources utilisées, et l’horodatage) crée un audit trail exploitable. Ce n’est pas de l’over-engineering : c’est la condition minimale pour répondre à une demande d’accès RGPD ou à un contrôle CNIL.
Isolation des données sensibles dans les Data Streams. Data Cloud permet de configurer des Data Streams avec des politiques de rétention et de classification. Dans une architecture multi-agents, les agents ne devraient pas accéder directement aux DMOs bruts. L’architecture correcte passe par des Data Graphs qui matérialisent uniquement les attributs nécessaires à chaque agent : le principe de minimisation des données appliqué au niveau de la couche de données, pas au niveau applicatif.
Consentement comme attribut de profil, pas comme processus externe. L’erreur classique est de gérer le consentement dans un système tiers et de vérifier côté Salesforce via une API au moment de l’action. Avec des agents multi-orchestrés qui peuvent enchaîner des décisions en quelques secondes, cette architecture crée des fenêtres de race condition où le consentement est vérifié une fois mais l’action est exécutée plusieurs fois. La bonne architecture stocke le statut de consentement comme Calculated Insight dans Data Cloud, mis à jour en temps réel via un Data Stream dédié, et accessible comme attribut du profil unifié. Chaque agent lit ce statut avant d’agir, sans appel externe, sans latence.
Pour les DSI qui construisent cette architecture, le lien entre Data Cloud et Agentforce n’est pas optionnel : c’est la fondation. L’article sur l’architecture Data Cloud comme fondation Agentforce détaille pourquoi cette dépendance est structurelle, pas configurable.
Ce que les ESN françaises ne disent pas à leurs clients ETI
Le marché français des ESN Salesforce a massivement investi dans les certifications Agentforce depuis 2025. La plupart des offres de déploiement incluent la configuration des agents, la définition des Topics et Actions, et l’intégration avec les clouds existants.
Ce que ces offres n’incluent généralement pas : l’analyse d’impact relative à la protection des données (AIPD) pour les traitements automatisés, la documentation des flux de données entre agents pour le registre de traitement, et la conception des mécanismes de droit à l’explication pour les décisions automatisées.
Ce n’est pas de la mauvaise foi. C’est une délimitation de périmètre. Mais pour une ETI qui déploie Agentforce sans architecte solution expérimenté sur les enjeux RGPD, le gap entre “l’agent fonctionne” et “l’agent est conforme” peut représenter plusieurs mois de remédiation.
L’Agentforce Testing Center, introduit dans les releases récentes, permet de valider le comportement des agents dans des scénarios de test. C’est utile pour la qualité fonctionnelle. Ce n’est pas un outil de conformité RGPD : il ne teste pas les bases légales, ne vérifie pas les durées de conservation, et ne génère pas de documentation de traitement.
La confusion entre “testé” et “conforme” est un anti-pattern récurrent dans les déploiements ETI.
Le cadrage prospectif : Summer ‘26 est le point de non-retour
Les décisions d’architecture prises aujourd’hui sur l’orchestration multi-agents seront difficiles à défaire dans 18 mois. Un agent déployé en production sans traçabilité des décisions accumule un historique de traitements non documentés. Rétrospectivement documenter ces traitements est possible mais coûteux, et ne couvre pas la période antérieure.
Summer ‘26 marque le moment où Agentforce passe d’un outil d’assistance à un système de décision autonome à part entière. Pour les ETI françaises, c’est le moment de décider si leur architecture Agentforce est construite pour la conformité ou si elle sera remédiée sous contrainte.
La remédiation sous contrainte, dans le contexte d’un contrôle CNIL ou d’une plainte d’un individu exerçant ses droits, coûte structurellement plus cher que la conception initiale. Les organisations qui ont traversé des audits RGPD sur des systèmes de scoring automatisé le savent : le coût n’est pas l’amende potentielle, c’est l’effort de reconstitution de la documentation et la suspension des traitements pendant l’audit.
Pour les DSI d’ETI qui évaluent leur roadmap Agentforce post-Summer ‘26, la question n’est pas “est-ce qu’on déploie ?” mais “avec quelle architecture de gouvernance on déploie ?”. Les deux ne sont pas incompatibles, mais la seconde doit précéder la première.
Les architectes qui accompagnent ces déploiements doivent maîtriser à la fois la couche technique Salesforce et les implications réglementaires françaises. C’est précisément le périmètre couvert dans une mission d’architecture Agentforce orientée conformité.
Points Clés
- L’orchestration multi-agents de Summer ‘26 crée des chaînes de décisions automatisées qui tombent sous l’article 22 du RGPD dès qu’elles affectent significativement un individu. La configuration Agentforce seule ne documente pas ces traitements.
- Dans Data Cloud, l’architecture correcte pour la conformité passe par des Data Graphs qui exposent uniquement les attributs nécessaires à chaque agent, avec le consentement stocké comme Calculated Insight mis à jour en temps réel.
- Platform Events est le mécanisme natif pour créer un audit trail des décisions agents : chaque Action significative doit écrire un événement structuré avec l’identifiant agent, les données sources, et l’horodatage.
- Les ETI françaises sont dans l’angle mort : elles ont la sophistication technique pour déployer Agentforce, mais rarement la maturité de gouvernance pour documenter les traitements automatisés implicites.
- L’Agentforce Testing Center valide le comportement fonctionnel, pas la conformité RGPD. Confondre les deux est l’anti-pattern le plus fréquent dans les déploiements ETI post-Summer ‘26.
