Sécuriser ses données dans Salesforce : bonnes pratiques et recommandations

Comprendre les risques liés aux données CRM

Un CRM contient souvent bien plus qu'un fichier de prospects. On y trouve des coordonnées, des préférences de contact, des prévisions de chiffre d'affaires, des notes commerciales, des documents, des échanges de support et des informations relatives à des comptes stratégiques. Une mauvaise permission ou un partage trop large peut exposer un portefeuille entier en quelques clics.

Les incidents ne viennent pas toujours d'une attaque sophistiquée. Un collaborateur qui télécharge un rapport sur un appareil personnel, un ancien salarié dont le compte reste actif, un mot de passe réutilisé ou une intégration mal configurée constituent des situations beaucoup plus courantes. La sécurité Salesforce commence donc par la réduction des accès inutiles.

Considérez votre CRM comme un immeuble : la réception doit accueillir tout le monde, mais chaque porte intérieure doit rester fermée à ceux qui n'ont pas de raison légitime d'y entrer.

Appliquer le principe du moindre privilège

Le principe du moindre privilège signifie qu'un utilisateur reçoit uniquement les droits indispensables à son travail. Dans Salesforce, cela passe par les profils, les jeux d'autorisations, les rôles, les règles de partage et les paramètres d'accès aux objets, champs et enregistrements.

Un commercial peut par exemple créer et mettre à jour ses opportunités, sans avoir accès à l'ensemble des contrats négociés par d'autres équipes. Un manager peut consulter les résultats de son périmètre. Un prestataire ponctuel peut disposer d'un accès limité, avec une date d'expiration et des autorisations très ciblées.

Configurer la visibilité des objets, champs et enregistrements

La protection des données Salesforce se joue à plusieurs niveaux. Les autorisations d'objet déterminent qui peut accéder aux comptes, contacts, leads, opportunités ou cas. La sécurité au niveau des champs limite l'affichage ou la modification d'informations plus délicates, comme une donnée financière, une remise exceptionnelle ou une information contractuelle.

La visibilité des enregistrements doit aussi être paramétrée avec soin. Lorsque les réglages par défaut de l'organisation sont trop ouverts, un utilisateur peut consulter des informations qui ne lui sont pas destinées. Un modèle privé, complété par des règles de partage ciblées, est souvent plus prudent qu'un accès global ouvert à tous.

Une règle utile : si vous ne pouvez pas expliquer clairement pourquoi un rôle a besoin d'un accès, cet accès mérite d'être revu.

Renforcer l'authentification et la gestion des sessions

Une politique de droits bien pensée perd sa valeur si un identifiant est compromis. L'authentification multifacteur ajoute une vérification supplémentaire lors de la connexion. Elle réduit le risque qu'un mot de passe volé suffise à ouvrir une session Salesforce.

La gestion des sessions mérite la même attention. L'organisation peut définir des plages IP de confiance, contrôler les heures de connexion, limiter la durée des sessions et demander une nouvelle authentification pour certaines opérations sensibles. Ces mesures sont particulièrement utiles lorsque les équipes se connectent depuis des réseaux variés ou utilisent des appareils mobiles.

1. Activer l'authentification multifacteur pour les utilisateurs concernés par l'organisation.
2. Éviter les comptes partagés, qui empêchent toute traçabilité fiable des actions réalisées.
3. Définir une politique de session adaptée au niveau de sensibilité des données.
4. Retirer rapidement les accès lors d'un départ, d'un changement de poste ou de la fin d'une mission externe.

Contrôler les exports, les fichiers et les intégrations

La fuite de données ne se produit pas forcément dans Salesforce lui-même. Elle peut intervenir après un export CSV, le partage d'un rapport ou le téléchargement d'un document. Les droits d'export doivent être réservés aux personnes qui en ont réellement besoin, et les rapports contenant des données personnelles ou commerciales sensibles doivent être examinés comme n'importe quel autre accès.

Les fichiers joints et bibliothèques documentaires demandent aussi une gouvernance claire. Vérifiez qui peut téléverser, partager, télécharger ou supprimer un document. Un devis, un contrat signé ou une pièce d'identité déposée dans un dossier client ne doit pas devenir visible par défaut à une population trop large.

Les applications connectées et les intégrations sont un autre point de contrôle. Une connexion entre Salesforce et un outil de marketing, de comptabilité, de signature électronique ou de BI peut transférer de nombreuses informations. Avant de l'autoriser, identifiez les objets lus ou modifiés, le compte utilisé, le niveau d'accès accordé et la procédure de révocation. [ A lire en complément ici ]

• Inventorier les applications connectées et les comptes techniques.
• Limiter les autorisations OAuth au strict nécessaire.
• Supprimer les intégrations abandonnées ou non documentées.
• Vérifier que les environnements de test ne contiennent pas de données de production non protégées.

Mettre en place une surveillance utile, pas seulement théorique

La sécurité ne s'arrête pas à la configuration initiale. Les journaux de connexion, l'historique des modifications et les fonctions de surveillance disponibles selon l'édition Salesforce permettent d'identifier des comportements inhabituels : connexion depuis un emplacement inattendu, extraction massive, changement de permissions ou consultation de données sensibles.

Un bon suivi repose sur des alertes compréhensibles et sur une personne clairement désignée pour les traiter. Une alerte jamais lue n'apporte aucune protection. Il est préférable de surveiller quelques signaux pertinents que de générer un volume d'événements impossible à analyser.

La revue des droits doit être régulière : nouveaux arrivants, mobilités internes, réorganisations et prestataires modifient continuellement le périmètre d'accès. Prévoir ce contrôle dans un processus métier évite de le repousser jusqu'à l'incident.

Protéger les données personnelles et respecter leur cycle de vie

Salesforce peut contenir des données à caractère personnel : nom, email, téléphone, fonction, historique d'échanges ou préférences de communication. Leur collecte doit être justifiée, leur usage encadré et leur conservation limitée à ce qui est nécessaire. La protection technique ne remplace pas une politique de gestion des données.

Concrètement, définissez quelles informations sont indispensables dans chaque objet, qui peut les corriger et à quel moment elles doivent être supprimées, anonymisées ou archivées. Les doublons et les champs libres mal maîtrisés compliquent ce travail. Ils favorisent aussi le stockage de notes inappropriées ou de données dont personne ne connaît l'origine.

Pour les demandes d'accès, de rectification ou de suppression, une procédure documentée facilite la recherche des données concernées. L'enjeu n'est pas seulement juridique : une base propre est plus fiable pour les équipes commerciales, le support et les actions de communication.

Former les utilisateurs aux gestes qui évitent les incidents

La plupart des collaborateurs ne cherchent pas à contourner les règles. Ils vont souvent au plus vite : envoyer un export par email, copier une donnée dans un fichier local, accepter une demande de connexion inhabituelle ou installer une application sans mesurer son périmètre. Une sensibilisation courte, concrète et répétée est plus efficace qu'un document oublié dans un dossier partagé.

Montrez les situations réelles rencontrées dans l'entreprise : un faux écran de connexion, une demande urgente supposément envoyée par un dirigeant, un lien vers un rapport partagé ou un fichier client récupéré sur un poste non géré. Les utilisateurs doivent savoir à qui signaler un doute et comprendre qu'un signalement rapide est utile, même s'il s'avère finalement sans gravité.

Préparer la réponse à un incident

Un incident peut survenir malgré des contrôles solides. La différence se joue alors dans la rapidité de réaction. L'équipe doit savoir qui contacter, comment désactiver un compte, comment révoquer une session ou une application connectée, et quelles informations conserver pour comprendre ce qui s'est passé.

Un plan de réponse doit inclure les responsables métier, l'administration Salesforce, la sécurité informatique et, selon le contexte, les équipes juridiques ou de protection des données. Testez ce plan sur un scénario simple : compte compromis, export envoyé au mauvais destinataire ou intégration suspecte. Les zones floues apparaîtront immédiatement.

Après l'incident, recherchez la cause réelle plutôt que de vous limiter à corriger le symptôme. Si un utilisateur a reçu trop de droits, le problème se situe peut-être dans le processus d'attribution. Si une intégration a accédé à trop de données, il faut aussi revoir son périmètre et sa documentation.

Encadrer l'IA et les assistants connectés au CRM

Les fonctions d'IA peuvent faciliter la recherche d'informations, la rédaction de comptes rendus ou la préparation d'actions commerciales. Elles renforcent aussi la nécessité de savoir quelles données sont accessibles, quelles sources sont interrogées et quelles autorisations s'appliquent à l'utilisateur qui formule une demande.

Avant d'ouvrir un assistant à grande échelle, commencez par des cas d'usage précis et contrôlés. Vérifiez les données mises à disposition, les profils concernés, les réponses générées et les scénarios où l'outil ne doit pas être utilisé. L'IA ne doit pas contourner les règles de confidentialité déjà définies dans Salesforce ; elle doit s'y conformer.

Cette vigilance vaut aussi pour les contenus produits automatiquement. Une réponse peut reprendre une information confidentielle si le contexte d'accès est mal conçu. La bonne question n'est donc pas seulement « que peut faire l'assistant ? », mais aussi « qu'a-t-il le droit de consulter pour répondre ? ».

Pour prolonger cette réflexion sur les assistants connectés au CRM et les précautions à prendre autour des données utilisées par Einstein Copilot, vous pouvez lire cet article d'InformatiqueNews.