Profils, rôles et partages : quand un paramétrage Salesforce expose des données RGPD

La sécurité d'accès aux données dans Salesforce ne se règle pas par un interrupteur unique. C'est un empilement de couches qui interagissent, et c'est précisément cette complexité qui en fait une source d'erreurs coûteuses :

• OWD (Organization-Wide Defaults) : le niveau d'accès par défaut à chaque objet — Private, Public Read Only, Public Read/Write. C'est le socle.
• Hiérarchie de rôles : qui voit les données de qui en remontant la chaîne managériale.
• Profils et permission sets : ce qu'un utilisateur peut faire (créer, modifier, supprimer) et voir au niveau des champs.
• Règles de partage (sharing rules) : les exceptions qui élargissent l'accès à certains groupes.

Le piège : chacune de ces couches peut, seule, ouvrir une brèche. Une OWD réglée trop large « pour aller vite » pendant le développement, un profil cloné depuis un modèle trop permissif, une règle de partage temporaire jamais retirée — et des données qui devaient rester cloisonnées deviennent accessibles à toute l'organisation.

Le scénario le plus fréquent illustre bien le danger. Pendant la phase de configuration, vous réglez l'OWD d'un objet sensible — par exemple les dossiers RH, les contrats clients ou les données de santé d'un objet personnalisé — en Public Read/Write pour faciliter vos tests. C'est pratique : tout le monde voit tout, vous n'avez pas à jongler avec les rôles.

Puis le projet avance, le go-live approche, et ce réglage provisoire passe à travers les mailles de la recette. En production, n'importe quel utilisateur licencié de l'organisation peut consulter — et parfois modifier — des enregistrements qui auraient dû être réservés à une poignée de personnes.

Tant qu'aucun utilisateur ne s'en aperçoit, l'incident reste latent. Mais le jour où un collaborateur consulte des données auxquelles il n'aurait jamais dû accéder, ou pire, où ces données fuitent, la question remonte directement à la conception du modèle de sécurité — c'est-à-dire à vous.

Ce type d'exposition est d'autant plus piégeux qu'il ne génère aucune alerte technique : aucun governor limit n'est franchi, aucun crash ne survient. Le système fonctionne parfaitement — il expose simplement les données à trop de monde.

Beaucoup de consultants pensent que le RGPD ne concerne que leur client, en tant que responsable de traitement. C'est une vision incomplète. Dès lors que vous paramétrez les accès à des données personnelles pour le compte d'un client, vous pouvez être qualifié de sous-traitant au sens de l'article 28 du RGPD.

Cette qualification emporte des obligations concrètes :

• Mettre en œuvre les mesures techniques et organisationnelles appropriées pour garantir la sécurité du traitement (article 32). Un paramétrage de partage défaillant est, par nature, un manquement à cette obligation.
• Respecter le principe de minimisation : un utilisateur ne doit accéder qu'aux données nécessaires à sa fonction. Une OWD Public Read/Write sur des données sensibles viole frontalement ce principe.
• Agir uniquement sur instruction documentée du responsable de traitement, et l'alerter si une instruction vous paraît contraire au règlement.

En cas de violation, la CNIL et les personnes concernées peuvent se retourner contre le responsable de traitement, qui pourra ensuite engager votre responsabilité de sous-traitant. La protection juridique professionnelle incluse dans une bonne RC Pro prend alors tout son sens.

Tout accès trop large n'est pas automatiquement une violation notifiable, mais la frontière est ténue. Le RGPD définit la violation de données comme une atteinte à la confidentialité, l'intégrité ou la disponibilité des données — y compris un accès non autorisé, même interne et même sans fuite vers l'extérieur.

Concrètement, si un audit révèle que des collaborateurs non habilités ont eu accès pendant des mois à des données personnelles sensibles à cause d'un partage mal configuré, le responsable de traitement peut être tenu de :

• Documenter l'incident dans son registre des violations.
• Notifier la CNIL sous 72 heures si la violation présente un risque pour les droits et libertés des personnes.
• Informer les personnes concernées en cas de risque élevé.

Ces démarches ont un coût — accompagnement juridique, expertise, communication — et le client cherchera à imputer ce coût à la cause racine : votre paramétrage. C'est ici que le volet cyber apporte une réponse adaptée, en couvrant la gestion de crise sur les données et l'accompagnement à la notification, là où la RC Pro répond de la faute de prestation elle-même.

Au-delà des OWD et des règles de partage, une couche plus discrète concentre un risque RGPD majeur : la Field-Level Security (FLS), qui régit la visibilité champ par champ. Un objet peut être correctement cloisonné au niveau enregistrement, tout en laissant visible un champ qui ne devrait pas l'être pour certains profils — un numéro de sécurité sociale, un RIB, une donnée de santé, une appréciation RH.

La FLS est insidieuse parce qu'elle est invisible dans l'usage quotidien : un commercial ne se rend pas compte qu'il voit un champ qu'il ne devrait pas voir. Elle l'est aussi parce qu'elle se diffuse par les permission sets empilés : un utilisateur cumule les droits de son profil et de tous ses permission sets, si bien qu'un accès accordé pour une raison ponctuelle peut rouvrir un champ verrouillé par ailleurs.

Sur des données qualifiées de sensibles au sens de l'article 9 du RGPD (santé, opinions, origine, orientation), l'exigence de minimisation est renforcée. Le consultant qui paramètre ces accès doit appliquer le principe du moindre privilège champ par champ, et conserver la trace de la matrice d'habilitation validée par le client. Cette matrice est à la fois un outil de conformité et une pièce de défense en cas de contrôle CNIL.

Trois leviers permettent de réduire votre exposition sur les missions de sécurité Salesforce :

Auditer avant de livrer

Avant chaque go-live, passez en revue toutes les OWD, comparez les profils aux besoins réels, listez les règles de partage actives et supprimez les exceptions temporaires. Salesforce fournit des rapports d'accès et le Health Check : utilisez-les systématiquement et conservez-en une copie horodatée.

Tracer vos recommandations

Si le client refuse une restriction que vous préconisez — pour des raisons de confort utilisateur, par exemple — formalisez cette décision par écrit. Cette trace bascule la responsabilité du choix vers le responsable de traitement et constitue une pièce de défense déterminante.

Couvrir le risque résiduel

Même avec un audit irréprochable, le risque zéro n'existe pas sur des architectures de sécurité complexes héritées de plusieurs prestataires. Une couverture combinant RC Pro et cyber, adaptée au conseil et à l'intégration CRM, protège à la fois contre la réclamation pour faute et contre les conséquences d'une violation de données. Pour les freelances qui interviennent sur des données personnelles à grande échelle, c'est le socle minimal d'une activité sereine. Retrouvez les garanties détaillées sur notre page consultant Salesforce.