Spring '26 : Agentforce RGPD pour les ETI

Spring ‘26 n’est pas une release ordinaire pour les ETI françaises. Les nouvelles capacités Agentforce introduisent des agents qui raisonnent sur des données clients en temps réel, prennent des décisions autonomes et déclenchent des actions sans validation humaine systématique. C’est précisément là que la question Agentforce RGPD cesse d’être théorique.

Pour une ETI avec 50 000 à 500 000 contacts dans Salesforce, un agent qui qualifie des prospects, répond à des demandes SAV ou génère des devis personnalisés traite des données à caractère personnel à chaque itération. La CNIL ne distingue pas entre un humain et un algorithme : le responsable de traitement reste le même, et les obligations aussi.

Ce que Spring ‘26 change concrètement dans le modèle de traitement

Les releases précédentes positionnaient Agentforce comme un assistant. Spring ‘26 franchit un seuil différent : les agents peuvent désormais initier des actions proactives, accéder à des Data Graphs enrichis et s’appuyer sur l’Atlas Reasoning Engine pour enchaîner plusieurs étapes de raisonnement sans intervention humaine intermédiaire.

Architecturalement, cela crée trois nouveaux vecteurs de risque RGPD.

Le premier concerne la traçabilité des décisions automatisées. Quand l’Atlas Reasoning Engine enchaîne cinq étapes pour décider qu’un contact doit recevoir une offre commerciale personnalisée, l’article 22 du RGPD s’applique si cette décision produit des effets juridiques ou affecte significativement la personne. La question n’est pas de savoir si Salesforce est conforme, c’est de savoir si votre configuration l’est.

Le deuxième vecteur touche à la minimisation des données. Les Data Graphs Spring ‘26 permettent des jointures pré-calculées entre DMOs (Data Model Objects) qui agrègent comportements, transactions et données démographiques dans une vue unifiée. C’est architecturalement puissant. C’est aussi une surface d’exposition maximale si les agents accèdent à l’intégralité du graphe sans filtrage contextuel.

Le troisième est plus subtil : la durée de rétention des traces d’inférence. Chaque interaction avec l’Atlas Reasoning Engine génère des logs. Ces logs contiennent des données personnelles indirectes. Dans la plupart des configurations par défaut, leur durée de conservation n’est pas alignée sur les politiques de rétention définies dans le registre des traitements de l’ETI.

L’architecture de gouvernance que Spring ‘26 rend nécessaire

La réponse architecturale correcte n’est pas de désactiver les agents. C’est de construire une couche de gouvernance qui s’intercale entre les capacités de la plateforme et leur exécution.

En pratique, cela se traduit par quatre décisions d’architecture que les DSI doivent prendre avant de déployer les nouvelles fonctionnalités Spring ‘26.

Périmètre des Topics Agentforce. Chaque agent Agentforce est défini par ses Topics, qui délimitent ce sur quoi il peut raisonner. La gouvernance RGPD commence ici : un Topic qui donne accès à l’historique complet des interactions d’un contact est fondamentalement différent d’un Topic limité aux 90 derniers jours. Ce n’est pas une contrainte technique, c’est une décision de conception qui doit être documentée dans le registre des traitements.

Filtrage au niveau des Data Streams. Avant que les données atteignent les DMOs consommés par les agents, les Data Streams peuvent être configurés avec des règles de filtrage et de pseudonymisation. Pour les ETI qui traitent des données sensibles (santé, situation financière, comportements d’achat révélateurs), ce filtrage n’est pas optionnel. Il doit être conçu en amont, pas ajouté après déploiement.

Journalisation des décisions automatisées. Spring ‘26 n’impose pas nativement un format de log conforme à l’article 22. Les ETI doivent implémenter une couche de journalisation explicite, typiquement via Platform Events, qui capture pour chaque décision automatisée significative : les données d’entrée utilisées, la chaîne de raisonnement, la décision produite et l’horodatage. C’est ce qui permet de répondre à une demande d’explication d’un contact ou à une injonction de la CNIL.

Politique de rétention des logs d’inférence. Les logs générés par l’Atlas Reasoning Engine doivent être soumis à la même politique de rétention que les données personnelles qu’ils référencent. Dans les organisations où la durée de conservation des données clients est de 3 ans, les logs d’inférence ne peuvent pas être conservés indéfiniment sous prétexte qu’ils servent au débogage ou à l’amélioration du modèle.

Pour aller plus loin sur la structuration des données avant déploiement d’agents, l’article sur l’unification des données avant de déployer Agentforce détaille les prérequis Data Cloud qui conditionnent la conformité.

Ce que la plupart des ETI font mal au moment du déploiement

L’erreur la plus fréquente est de traiter la conformité RGPD comme une validation post-déploiement. Dans les organisations qui déploient Spring ‘26 sans revue architecturale préalable, le schéma est toujours le même : les équipes métier activent les agents, les résultats sont impressionnants, et c’est six mois plus tard que le DPO découvre que des données de catégorie sensible transitent dans des contextes non documentés.

La deuxième erreur concerne l’Identity Resolution. Les rulesets de correspondance dans Data Cloud peuvent unifier des profils issus de sources multiples, y compris des sources externes via MuleSoft. Quand un agent raisonne sur un Unified Individual construit à partir de cinq systèmes sources, la base légale du traitement doit couvrir l’ensemble des données unifiées, pas seulement celles du CRM Salesforce. En pratique, les ETI qui ont des intégrations legacy héritées ne peuvent pas garantir cette couverture sans audit préalable.

La troisième erreur est architecturale : confondre les contrôles d’accès Salesforce (profils, permission sets) avec une gouvernance RGPD. Les permission sets contrôlent qui peut voir quoi dans l’interface. Ils ne contrôlent pas ce que l’Atlas Reasoning Engine peut inférer à partir des données auxquelles il a accès. Un agent peut être configuré pour ne pas afficher un champ tout en l’utilisant dans son raisonnement. C’est une distinction critique que les équipes de déploiement sans expertise RGPD ratent systématiquement.

Pour les ETI qui déploient Agentforce sans catalogue de données structuré, les risques de conformité sont amplifiés. L’article sur la rentabilisation d’Agentforce sans catalogue structuré aborde ce problème sous l’angle de la gouvernance opérationnelle.

La position de la CNIL sur les agents IA en 2026

La CNIL a publié en 2024 ses recommandations sur les systèmes d’IA et le RGPD. La position est claire : l’utilisation d’un système d’IA comme Agentforce pour des traitements automatisés de données personnelles ne transfère pas la responsabilité vers l’éditeur. Le responsable de traitement reste l’ETI, et les obligations de transparence, de minimisation et de limitation des finalités s’appliquent intégralement.

Ce que Spring ‘26 ajoute à cette équation, c’est la capacité proactive des agents. Un agent qui initie un contact commercial sans déclencheur humain explicite doit s’appuyer sur une base légale documentée pour ce traitement. L’intérêt légitime peut fonctionner dans certains cas, mais il nécessite une analyse d’impact (AIPD) si le traitement est susceptible d’engendrer un risque élevé pour les droits des personnes. Les agents proactifs Spring ‘26 entrent dans cette catégorie pour la plupart des cas d’usage B2C.

Les DSI qui déploient sans AIPD préalable s’exposent à des sanctions qui peuvent atteindre 4% du chiffre d’affaires mondial. Pour une ETI de 50M EUR de CA, c’est 2M EUR de risque potentiel sur une décision d’architecture.

Le cadre de déploiement responsable pour les ETI

L’architecture qui fonctionne pour les ETI françaises en 2026 suit une séquence précise. D’abord, cartographier les traitements existants dans Salesforce et identifier ceux qui seront augmentés par des agents. Ensuite, qualifier chaque traitement automatisé selon les critères de l’article 22 et déterminer si une AIPD est requise. Puis configurer les Topics, les Data Streams et les politiques de rétention avant activation. Enfin, implémenter la journalisation via Platform Events et valider avec le DPO.

Ce n’est pas un processus de six mois. Les ETI qui ont leur registre des traitements à jour et une architecture Data Cloud propre peuvent compléter ce cadre en quatre à six semaines. C’est le prérequis pour exploiter Spring ‘26 sans créer de passif réglementaire.

Pour les ETI qui veulent structurer cette démarche avec un accompagnement architectural, la page Architecture Agentforce détaille les patterns de déploiement conformes pour le marché français.

Points Clés

• Spring ‘26 introduit des agents proactifs qui déclenchent des traitements automatisés sans validation humaine, activant directement l’article 22 du RGPD pour les cas d’usage B2C des ETI françaises.
• Les Data Graphs et l’Identity Resolution de Data Cloud créent une surface d’exposition maximale si les agents accèdent à des profils unifiés sans filtrage contextuel au niveau des Data Streams.
• Les logs de l’Atlas Reasoning Engine contiennent des données personnelles indirectes et doivent être soumis aux mêmes politiques de rétention que les données clients, ce que les configurations par défaut ne garantissent pas.
• La gouvernance RGPD Agentforce se construit au niveau des Topics (périmètre de raisonnement), des Data Streams (filtrage à l’ingestion) et des Platform Events (journalisation des décisions), pas au niveau des permission sets Salesforce.
• Les ETI sans AIPD préalable pour les agents proactifs s’exposent à un risque réglementaire pouvant atteindre 4% du chiffre d’affaires mondial, soit 2M EUR pour une ETI à 50M EUR de CA.