Nos 6 meilleurs conseils de sécurité Salesforce pour 2026

En 2019, nous avons publié une liste de cinq conseils de base en matière de sécurité Salesforce pour aider les organisations à limiter les brèches causées par l’erreur humaine ou la malveillance. Bien des choses ont changé depuis : Salesforce a relevé le niveau de sécurité minimal pour tous ses clients, la surface d’attaque s’est étendue bien au-delà des connexions humaines, et un changement majeur que notre liste originale ne pouvait pas prévoir est apparu… des agents IA qui agissent au sein de votre org.

Voici une version mise à jour de nos conseils de sécurité Salesforce, fondée sur les mêmes bases pratiques que notre article original, mais revue en fonction de la réalité actuelle de la plateforme (et des risques).

Table des matières :

• Bien configurer l’authentification multifacteur, pas seulement l’activer
• Configurer la sécurité basée sur le réseau
• Surveiller l’historique des connexions et l’activité des agents
• Encadrer les Connected Apps et les accès OAuth
• Utiliser des comptes dédiés aux intégrations et aux agents
• Encadrer vos agents IA (Agentforce)

1. Bien configurer l’authentification multifacteur, pas seulement l’activer

En 2019, la recommandation consistait simplement à activer l’authentification à deux facteurs. Ce n’est plus le cas : Salesforce exige l’authentification multifacteur (AMF) pour toutes les connexions directes à l’interface depuis 2022. Si votre org est en production, l’AMF est donc déjà activée. La vraie question pour 2026 n’est pas « devrions-nous l’activer? », mais « notre mise en œuvre est-elle réellement solide? »

Cela signifie délaisser la vérification par texto, toujours vulnérable à l’interception et à l’échange de carte SIM, au profit de l’application Salesforce Authenticator ou des clés d’accès (passkeys). Cela signifie aussi étendre les exigences de session à haut niveau d’assurance au-delà de la connexion, afin de couvrir les rapports sensibles et les exportations Data Cloud, et revoir les exceptions ou contournements de l’AMF accordés il y a des années et jamais réévalués depuis.

Conseil de pro : vérifiez vos politiques Identity Verification et Session Security Level au moins une fois par année; elles sont souvent configurées une seule fois lors de l’implantation, puis jamais revues.

2. Configurer la sécurité basée sur le réseau

Cette recommandation de 2019 tient toujours la route, mais mérite d’être élargie. Les Trusted IP Ranges restent un moyen simple et efficace de réduire votre surface d’attaque; les utilisateurs qui se connectent hors des plages d’adresses connues du bureau ou du RPV devraient toujours devoir confirmer leur identité.

Pour 2026, combinez les Trusted IP Ranges à l’échelle de l’org avec des Login IP Ranges définies au niveau des profils, pour un contrôle plus serré sur vos groupes d’utilisateurs les plus sensibles. Assurez-vous aussi qu’Enhanced Domains et My Domain sont entièrement déployés dans votre org; un nombre croissant de nouvelles fonctionnalités de sécurité Salesforce, dont plusieurs capacités d’Agentforce et de Shield, en dépendent.

3. Surveiller l’historique des connexions et l’activité des agents

Le suivi de l’historique des connexions demeure une bonne pratique. Le rapport standard « New Login Location Report » de Salesforce reste un moyen rapide de repérer un utilisateur qui se connecte d’un endroit inhabituel, un signal qui a historiquement aidé les organisations à détecter des tentatives d’exfiltration de données avant le départ d’un employé, par exemple.

Ce qui a changé, c’est que les connexions humaines ne sont plus la seule activité à surveiller. Si votre org utilise Agentforce, des identités non humaines y lisent et modifient désormais des enregistrements de façon autonome. Étendez votre surveillance aux journaux d’actions et de raisonnement des agents au moyen de Shield ou d’Event Monitoring, et pas seulement aux connexions humaines. Un agent qui opère discrètement hors de son périmètre prévu est beaucoup plus difficile à repérer qu’un employé sur le départ qui lance une exportation massive, et c’est précisément pourquoi il exige sa propre discipline de surveillance.

4. Encadrer les Connected Apps et les accès OAuth

Le principe de base de notre article original n’a pas changé : ne laissez pas les utilisateurs accorder à leur insu l’accès à votre org à des applications tierces. Un employé bien intentionné qui connecte un outil de messagerie pour recevoir des notifications d’Opportunities peut tout aussi facilement créer une faille de conformité involontaire.

Ce qui a changé, ce sont les outils. La « liste blanche d’applications » (App Whitelisting) se gère désormais au moyen des politiques OAuth des Connected Apps, et Salesforce a introduit les External Client Apps comme successeur plus granulaire et plus sécuritaire des Connected Apps traditionnelles pour de nombreux cas d’usage. Le principal ajout pour 2026 est l’examen rigoureux de tout ce qui demande un accès API impliquant de l’IA. Les serveurs MCP, les copilotes IA et les plateformes d’agents tierces peuvent avoir des implications bien plus vastes en matière d’accès aux données qu’une intégration ponctuelle typique, et méritent un examen plus strict avant d’être approuvés.

5. Utiliser des comptes dédiés aux intégrations et aux agents

Ce conseil a bien vieilli; il faut seulement en élargir la portée. La logique selon laquelle la connexion personnelle d’un employé ne devrait pas faire fonctionner votre intégration d’automatisation marketing s’applique tout autant aux agents IA. Chaque intégration, et désormais chaque agent IA, devrait fonctionner sous sa propre identité, limitée et vérifiable : un utilisateur dédié doté d’un profil et d’un Permission Set personnalisés, qui n’hérite jamais d’un large périmètre administrateur ni d’un compte de service partagé utilisé pour cinq autres choses.

C’est plus important aujourd’hui qu’en 2019, parce qu’une org typique compte plus d’identités non humaines que jamais, et chacune représente un rayon d’impact potentiel si elle dispose de trop de permissions.

6. Encadrer vos agents IA (Agentforce)

Voici le conseil que notre liste originale de 2019 ne pouvait pas prévoir. Mais impossible de vous présenter une liste de conseils Salesforce qui fait complètement abstraction des agents.

Agentforce hérite par conception des profils, des Permission Sets et des règles de partage existants de votre org, ce qui est une force, puisqu’il n’y a aucun système de permissions distinct à synchroniser. Mais cela signifie aussi que des permissions trop larges pour un utilisateur humain deviennent rapidement des problèmes à l’échelle de l’IA, car les agents peuvent agir en continu et à une vitesse qu’aucun utilisateur humain n’atteint.

L’Einstein Trust Layer de Salesforce couvre ici un terrain important : il sécurise les données en transit, applique la conservation zéro des données avec les LLM tiers et signale les contenus inappropriés. Il faut toutefois comprendre où s’arrête son rôle. Le Trust Layer vérifie si une requête (prompt) est sécuritaire, mais pas si un agent devrait réellement modifier un enregistrement. Cette limite relève de la configuration de votre Action Layer, de vos Permission Sets et de vos règles de partage.

Étapes concrètes pour 2026 :

• Appliquez des Permission Sets selon le principe du moindre privilège, adaptés à la tâche précise de chaque agent; un agent de soutien qui résume des notes de Cases n’a aucune raison de toucher aux Opportunities ou aux données financières.
• Exigez une approbation humaine pour les actions à risque élevé : tout ce qui crée, modifie ou supprime des enregistrements, ou envoie des communications externes.
• Utilisez Shield pour surveiller les parcours de raisonnement des agents et signaler les anomalies, comme vous le feriez pour un utilisateur humain privilégié.
• Traitez les permissions des agents comme des contrôles évolutifs; réévaluez-les régulièrement lorsque les agents sont réentraînés ou connectés à de nouvelles sources de données, comme vous réviseriez les accès après un changement de poste.

Conclusion

Les fondamentaux de 2019 tiennent toujours : une authentification solide, des contrôles réseau, la surveillance des activités et des comptes d’intégration aux accès strictement limités demeurent la base d’une org Salesforce sécurisée. Ce qui a changé, c’est la portée de la notion d’« accès ». Votre org compte désormais des identités non humaines qui y agissent, et elles exigent la même rigueur que vos utilisateurs humains les plus privilégiés, appliquée de façon constante et révisée souvent.