La Security Mesh de Salesforce Summer ‘26 n’est pas une mise à jour de sécurité parmi d’autres. C’est un changement de paradigme dans la façon dont les contrôles d’accès aux données sont architecturés au sein de la plateforme. Pour les ETI françaises, qui jonglent entre conformité RGPD, dépendance aux ESN et DSI sous-staffées, les implications sont concrètes et immédiates.
Le problème n’est pas technique en premier lieu. C’est un problème de gouvernance qui devient technique.
Ce que la Security Mesh change réellement dans l’architecture Salesforce
Avant Summer ‘26, la sécurité dans Salesforce reposait sur un modèle périmétrique : profils, ensembles d’autorisations, règles de partage. Chaque couche était configurée indépendamment, souvent par des équipes différentes, avec une visibilité transversale quasi nulle. Le résultat dans les orgs matures : des matrices d’autorisations impossibles à auditer, des règles de partage en cascade dont personne ne comprend plus l’origine, et des données sensibles accessibles à des utilisateurs qui n’auraient jamais dû y avoir accès.
La Security Mesh introduit une couche d’orchestration de politique centralisée. Concrètement, les politiques de sécurité deviennent des objets de premier ordre dans la plateforme, avec leur propre cycle de vie, leur versioning et leur traçabilité. Au lieu de reconstruire mentalement qui peut voir quoi en croisant profils, permission sets et sharing rules, un architecte solution peut désormais définir des politiques déclaratives qui s’appliquent de façon cohérente à travers les objets, les clouds et les agents Agentforce.
Ce n’est pas anodin. Dans les orgs avec plus de 200 profils actifs et 15 business units, la dette de sécurité accumulée représente un risque réel. La Security Mesh ne l’efface pas automatiquement, mais elle fournit enfin un mécanisme pour la résorber de façon contrôlée.
Pourquoi les ETI françaises sont particulièrement exposées
Les grandes entreprises françaises ont généralement des équipes sécurité dédiées, des RSSI avec des budgets, des processus d’audit formalisés. Les ETI, elles, fonctionnent souvent avec un DSI qui porte simultanément la casquette de responsable de la conformité, de l’architecture et des relations avec les ESN. La gouvernance Salesforce est déléguée de fait à l’intégrateur, ce qui crée une dépendance structurelle documentée dans de nombreuses organisations de cette taille.
Le RGPD a imposé des obligations de traçabilité et de minimisation des données que la plupart des ETI ont adressées au niveau juridique, sans les traduire en contrôles techniques dans leur org Salesforce. Résultat : des registres de traitement qui décrivent une réalité théorique, et une org où les données personnelles de clients, prospects et partenaires sont accessibles bien au-delà du cercle des utilisateurs légitimes.
La Security Mesh change l’équation parce qu’elle permet d’aligner les politiques de sécurité sur les catégories de données RGPD directement dans la plateforme. Un champ contenant des données de santé, des informations financières ou des données comportementales peut se voir attribuer une politique de sécurité qui s’applique indépendamment du profil de l’utilisateur. C’est une approche data-centric plutôt que role-centric, et c’est exactement ce que le RGPD demande conceptuellement.
Pour aller plus loin sur les risques de conformité liés aux données dans Salesforce, l’article sur les risques RGPD de Momentum pour les DSI illustre comment des décisions d’architecture peuvent créer des expositions réglementaires non anticipées.
L’architecture de déploiement qui fonctionne pour une ETI
Déployer la Security Mesh sans préparation dans une org existante est une erreur que beaucoup vont commettre. La tentation est de migrer toutes les règles de partage existantes vers des politiques Security Mesh en une seule passe. C’est la mauvaise approche.
L’architecture qui fonctionne dans ce contexte suit trois phases distinctes.
Phase 1 : cartographie des données sensibles. Avant de toucher à la configuration, il faut identifier les objets et champs qui contiennent des données à risque réglementaire. Dans une org Salesforce typique d’ETI, cela représente entre 40 et 80 champs répartis sur 10 à 20 objets. Data Cloud peut accélérer cette cartographie si l’org l’utilise, via les Data Model Objects et les métadonnées de classification. Sans Data Cloud, c’est un travail manuel qui prend entre 3 et 5 jours pour une org de taille moyenne.
Phase 2 : définition des politiques par catégorie de données. La Security Mesh permet de définir des politiques à grain fin. L’erreur classique est de créer une politique par profil utilisateur, ce qui reproduit exactement le problème qu’on cherche à résoudre. La bonne approche est de créer des politiques par catégorie de données : données d’identification directe, données financières, données comportementales, données contractuelles. Chaque politique définit les conditions d’accès, les restrictions de modification et les règles d’audit. Le nombre de politiques reste ainsi gérable : entre 8 et 15 pour une ETI avec une org bien structurée.
Phase 3 : déploiement progressif avec validation. La Security Mesh s’active par objet, pas globalement. Cela permet un déploiement progressif avec validation à chaque étape. Le pattern recommandé est de commencer par les objets les plus sensibles avec le moins d’utilisateurs légitimes, valider le comportement en sandbox pendant deux semaines minimum, puis étendre progressivement. Un déploiement complet sur une org ETI prend entre 6 et 10 semaines en suivant ce rythme.
Les écueils que la plupart des équipes vont rencontrer
Le premier écueil est la confusion entre Security Mesh et les contrôles existants. Les profils et permission sets ne disparaissent pas avec Summer ‘26. La Security Mesh s’ajoute comme une couche supplémentaire, ce qui signifie qu’un utilisateur doit satisfaire à la fois les contrôles traditionnels et les politiques Security Mesh pour accéder à une donnée. Les équipes qui ne comprennent pas cette logique additive vont créer des blocages inattendus en production.
Le deuxième écueil concerne Agentforce. Les agents configurés avant Summer ‘26 fonctionnent avec les autorisations de l’utilisateur qui les invoque. Avec la Security Mesh, les politiques s’appliquent également aux actions exécutées par les agents. Un agent de service client qui accédait jusqu’ici aux données de contrat d’un client peut se retrouver bloqué si une politique Security Mesh restreint l’accès à ces données aux seuls utilisateurs du département juridique. L’audit des Topics et Actions Agentforce existants est non négociable avant le déploiement.
Le troisième écueil est organisationnel. La Security Mesh nécessite une décision sur qui possède les politiques de sécurité. Dans une ETI, cette question n’a souvent pas de réponse claire. Le DSI ? L’équipe Salesforce ? Le DPO ? En pratique, la gouvernance des politiques Security Mesh doit être portée conjointement par le DSI et le DPO, avec l’équipe technique en position d’exécution. Les organisations qui laissent cette décision à l’intégrateur créent une dépendance supplémentaire qu’elles regretteront lors du prochain renouvellement de contrat.
Pour les ETI qui gèrent déjà une dette technique significative dans leur org, l’article sur le framework d’évaluation de la dette technique Salesforce fournit une méthode pour prioriser les chantiers avant d’ajouter une nouvelle couche de complexité.
Ce que les DSI doivent décider maintenant
Summer ‘26 est disponible. La Security Mesh est activable dès aujourd’hui. La question n’est pas si les ETI françaises doivent l’adopter, mais dans quel ordre et avec quelle gouvernance.
Trois décisions structurantes doivent être prises avant tout déploiement.
La première : qui réalise la cartographie des données sensibles ? Si c’est l’ESN en place, le DSI doit s’assurer que la méthodologie est documentée et que les livrables restent propriété de l’entreprise. Une cartographie réalisée dans les outils de l’intégrateur sans transfert de connaissance est une cartographie inutilisable lors du prochain changement de prestataire.
La deuxième : comment les politiques Security Mesh s’articulent-elles avec le registre RGPD existant ? L’opportunité est réelle de synchroniser les deux référentiels. Une politique Security Mesh qui ne correspond à aucune entrée dans le registre de traitement est soit superflue, soit le signe que le registre est incomplet. Cette synchronisation est un travail de fond qui prend du temps mais qui transforme la conformité RGPD d’une obligation documentaire en un contrôle technique effectif.
La troisième : quel est le plan de test pour les agents Agentforce existants ? Si l’org utilise Agentforce, l’Agentforce Testing Center doit être mobilisé pour valider le comportement de chaque agent après activation des politiques Security Mesh. Ce n’est pas optionnel. Un agent qui échoue silencieusement à récupérer des données à cause d’une politique mal configurée produit des réponses incorrectes sans erreur visible pour l’utilisateur final.
Les architectes solution qui accompagnent des ETI dans cette transition ont intérêt à consulter les ressources sur l’architecture Agentforce pour comprendre comment la Security Mesh s’intègre dans une architecture agent complète.
Points Clés
- La Security Mesh de Summer ‘26 introduit des politiques de sécurité déclaratives centralisées, distinctes des profils et permission sets existants. Les deux couches coexistent et s’appliquent de façon additive.
- Pour les ETI françaises, l’alignement entre politiques Security Mesh et registre de traitement RGPD est l’opportunité de transformer une conformité documentaire en contrôle technique effectif.
- Le déploiement progressif par objet est la seule approche viable : commencer par les données les plus sensibles avec le moins d’utilisateurs légitimes, valider en sandbox pendant deux semaines minimum avant chaque extension.
- Les agents Agentforce existants doivent être audités et testés via l’Agentforce Testing Center avant activation des politiques Security Mesh. Les blocages silencieux sont le risque principal.
- La gouvernance des politiques Security Mesh doit être portée conjointement par le DSI et le DPO, pas déléguée à l’ESN. C’est une décision organisationnelle, pas technique.
