Un paradoxe revient dans presque toutes les entreprises : le CRM contient l'intégralité du fichier client — identités, coordonnées, historique commercial, parfois des données sensibles — et c'est l'application la moins revue par l'équipe sécurité. La raison est simple : elle est perçue comme un outil métier, gérée par une équipe métier, achetée sur un budget métier.
Voici les huit points qu'un RSSI examine, et ce qu'il y trouve le plus souvent.
1. Qui peut exporter, et qui le sait
C'est le premier point, et de loin le plus important. Un utilisateur avec des droits de lecture larges et la permission d'exporter des rapports peut sortir le fichier client entier en trois clics, sans rien contourner. Aucune alerte ne se déclenche par défaut.
Ce qu'on cherche : qui détient réellement cette permission — la réponse surprend presque toujours — et si les exports volumineux sont tracés et surveillés.
2. Les profils historiques et l'accumulation de droits
Un modèle de droits vieux de cinq ans a traversé des réorganisations, des départs et des projets pressés. Le motif classique : un profil créé pour une personne, dupliqué pour une deuxième, puis élargi « temporairement » pour un projet, et jamais réduit.
La question utile n'est pas « qui a accès à quoi » mais « quelqu'un a-t-il revu ces droits depuis leur création, et selon quelle périodicité ». Si la réponse est non, l'ancienneté de la plateforme donne directement l'ampleur du problème.
3. Les intégrations et leurs comptes de service
Une plateforme CRM est rarement seule : ERP, marketing, outil de signature, service client, entrepôt de données. Chaque intégration passe par un compte technique, et ces comptes sont presque systématiquement surdotés — souvent administrateurs, parce que c'est ce qui faisait fonctionner l'intégration le jour de sa mise en place.
Ce compte-là n'a pas de deuxième facteur, ne part jamais de l'entreprise, et son mot de passe ou son jeton n'a probablement jamais été renouvelé. C'est le chemin d'attaque le plus court vers la donnée client.
4. Les environnements de recette et leurs données
La question tient en une phrase : que contiennent vos environnements de test ? Si la réponse est « une copie de la production », vous avez multiplié votre surface d'exposition par le nombre d'environnements, avec des droits plus permissifs, davantage de comptes et souvent des prestataires externes.
L'anonymisation des données de recette est fastidieuse, régulièrement repoussée, et c'est l'un des écarts les plus fréquemment relevés en audit.
5. Le code déployé et ce qu'il contourne
Sur Salesforce, le code exécuté par la plateforme ignore par défaut les règles de partage et les droits sur les champs. Ce comportement est documenté et parfois nécessaire — mais il signifie qu'un développement écrit sans précaution donne accès à des données que le modèle de droits interdit par ailleurs.
Ce qu'on regarde : la présence de mots-clés de respect du partage dans le code, l'existence d'une revue systématique avant déploiement, et le traitement réservé aux composants exposés à des utilisateurs externes.
6. Les portails et communautés exposés
Un portail client ou partenaire, c'est une plateforme interne exposée sur Internet à des utilisateurs qu'on ne maîtrise pas. Les modèles de partage y sont plus complexes qu'ils n'en ont l'air, et la faute classique consiste à donner à un utilisateur externe un accès qui, par cascade de partage, remonte bien au-delà de son propre périmètre.
Tout portail exposé mérite un test dédié, mené avec un compte externe réel plutôt que sur plan.
7. La journalisation, et le fait qu'elle soit lue
Savoir qui a consulté quoi suppose une journalisation activée, conservée assez longtemps, et surtout remontée dans l'outil de supervision de l'équipe sécurité. Sur beaucoup de plateformes, ces fonctions relèvent d'options payantes qui n'ont pas été prises, ou l'ont été sans que personne n'exploite les données produites.
Une journalisation que personne ne lit ne sert qu'après l'incident — et encore, seulement si la rétention couvre la période concernée.
8. La sauvegarde, qui n'est pas celle que vous croyez
C'est le point qui surprend le plus les directions. L'éditeur garantit la disponibilité de la plateforme, pas la récupération de vos données après une erreur de votre côté : une suppression massive, un import raté, une automatisation qui écrase un champ sur cent mille enregistrements. La restauration relève de votre responsabilité, et suppose une solution de sauvegarde tierce.
La question qui tranche : quand avez-vous testé une restauration pour la dernière fois ? Une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est une intention.
Par où commencer
Si vous ne deviez traiter que trois points : les droits d'export, les comptes de service des intégrations, et les données présentes dans les environnements de recette. Ce sont les trois qui combinent la probabilité la plus élevée et l'impact le plus large, et ils se traitent sans projet lourd.
Ce chantier demande un profil hybride — quelqu'un qui comprend le modèle de droits de la plateforme et le vocabulaire de la sécurité. C'est un profil rare, et c'est précisément pour cela qu'il se facture bien. Voyez les missions ouvertes, les profils disponibles, ou nos articles sur les déplacements de fond de la sécurité et le CRM composable.