Salesforce et RGPD : auditer votre configuration

Une revue RGPD de Salesforce doit porter sur les services et connexions effectivement utilisés. Le contrat du CRM, un outil marketing, une application tierce et une fonction Agentforce peuvent avoir des périmètres documentaires et techniques différents.

Deux raccourcis doivent être évités : assimiler tout hébergement Hyperforce à une garantie de traitement exclusivement européen, ou présenter Salesforce Shield comme un chiffrement rendant automatiquement les données inaccessibles au service.

Constituer le dossier contractuel par service

Le centre des accords Salesforce donne accès au contrat principal, au DPA et à des documents propres aux produits et prestations. Rapprochez-les des bons de commande et des entités qui utilisent réellement les services.

Le DPA consulté en septembre 2026 encadre notamment les instructions, les sous-traitants et l’assistance. Sa section 6.3 organise l’accès aux rapports et, sous conditions, un audit sur site. Ce droit ne doit pas être présenté comme une garantie réservée par principe à un seul niveau commercial d’abonnement.

Conservez les preuves de l’engagement contractuel applicables à votre compte. La FAQ officielle du DPA décrit un parcours de signature et renvoie aux documents d’infrastructure et de sécurité propres aux services. N’affirmez pas qu’une formule donnée permet toujours de négocier toutes les clauses : vérifiez le contrat effectivement proposé.

Cartographier les flux, au-delà du nom du cloud

Dressez une fiche par ensemble fonctionnel utilisé : gestion commerciale, assistance client, marketing, unification des données et fonctions d’IA. Les noms commerciaux ne suffisent pas à déterminer les finalités ou les responsables.

Salesforce a présenté une offre spécifique Hyperforce EU Operating Zone avec des engagements de résidence et de support européen. Cette annonce ne permet pas d’attribuer ces garanties à toute instance Hyperforce. Vérifiez l’offre souscrite, les services couverts et ses limites actuelles.

Pour chaque accès ou transmission identifié hors EEE, documentez le mécanisme applicable. Le guide des transferts de données hors UE distingue les vérifications selon le destinataire et les garanties utilisées.

Comprendre ce que protège Salesforce Shield

La documentation de Shield Platform Encryption décrit des clés gérées ou fournies par le client, utilisées pour chiffrer les données puis les déchiffrer lorsque les utilisateurs autorisés en ont besoin. Elle distingue plusieurs mécanismes et périmètres de chiffrement.

Il est donc inexact de conclure que l’option BYOK empêche nécessairement Salesforce de traiter les données en clair dans toutes les situations. Le contrôle des clés constitue une garantie à examiner avec l’architecture, les permissions et les accès ; il ne remplace pas ces éléments.

Listez les objets, champs, pièces jointes et index effectivement couverts. Vérifiez ce que voit un utilisateur autorisé et ce qu’une application connectée peut exporter. Ne confondez pas masquage d’affichage, chiffrement au repos et restriction d’accès.

Maîtriser les applications et les permissions

Une application installée peut rester dans l’environnement Salesforce ou transmettre des données à son éditeur. Son rôle juridique dépend de ses opérations : ne qualifiez pas automatiquement tout éditeur de sous-traitant indépendant sans examiner les flux.

Pour chaque connexion, consignez l’administrateur responsable, les autorisations accordées, l’utilité actuelle et la procédure de révocation. Retirez les accès inutiles et limitez les données disponibles aux fonctions réellement nécessaires. La conformité d’un CRM exige également des règles sur les notes commerciales et les documents, souvent moins structurés que les champs principaux.

Faire circuler les oppositions avec les données

L’existence d’un contact dans Sales Cloud ne justifie pas automatiquement un envoi marketing. Définissez les finalités et les canaux, puis vérifiez comment chaque outil reçoit les choix correspondants.

Préparez notamment un cas de désabonnement, un changement d’adresse et un contact présent dans plusieurs bases. La liste d’opposition du CRM doit empêcher qu’une synchronisation réactive une personne. Les preuves d’un accord et les raisons autorisant un traitement doivent rester disponibles sans conserver indéfiniment toutes les données commerciales.

Fixez aussi les règles de conservation pour les activités, pièces jointes, copies de développement et exports. Un journal utile à la sécurité ne doit pas devenir une archive commerciale accessible à tous.

Agentforce : vérifier les limites de la couche de confiance

La page officielle Trust and Agentforce distingue les engagements de non-conservation par les fournisseurs de modèles tiers des autres données conservées dans l’environnement Salesforce. Elle indique notamment la journalisation de requêtes, réponses et signaux dans Data 360.

Cette documentation précise également que le masquage des données par la couche de confiance est désactivé pour les agents. Il serait donc incorrect de promettre un masquage automatique universel avant toute transmission à un modèle.

Avant utilisation, limitez les sources accessibles à l’agent, définissez les actions autorisées et examinez les durées des journaux. Une garantie contractuelle du fournisseur de modèle ne remplace ni la minimisation des données envoyées ni le contrôle des destinataires des réponses. Documentez les fonctions réelles sans extrapoler une promesse générale à toutes les configurations.

Qualifier les rôles avant de négocier

La première question n’est pas technique : qui décide des finalités et des moyens ? L’article 4, points 7 et 8, du RGPD distingue le responsable du traitement du sous-traitant. Dans la plupart des usages courants de Sales Cloud ou de Service Cloud, votre organisation est responsable du traitement et Salesforce agit comme sous-traitant pour les données de ses clients. Cette qualification ne vaut pas pour tous les flux : Salesforce peut aussi traiter des données pour ses propres finalités (facturation, sécurité de ses services, relation commerciale avec vous), sur lesquelles il agit en responsable distinct.

Cette grille est un outil d’analyse, pas une règle automatique : la qualification résulte des faits (qui décide quoi), pas de l’étiquette du contrat. Le guide sur le rôle du sous-traitant détaille ces critères.

Vérifier le contrat clause par clause (Art. 28)

Un DPA signé ne vaut pas conformité tant que son contenu n’a pas été rapproché de l’Art. 28(3) du RGPD. Voici la grille que j’applique à un contrat de sous-traitance, quel que soit l’éditeur :

Deux points méritent une attention particulière. D’abord, le mécanisme de notification des sous-traitants ultérieurs : abonnez-vous aux notifications de l’éditeur plutôt que de découvrir un changement lors d’un audit. Ensuite, le délai de notification d’une violation : le DPA doit permettre au responsable de respecter le délai de 72 heures de l’Art. 33(1), le sous-traitant devant notifier « dans les meilleurs délais » selon l’Art. 33(2). Un manquement à l’Art. 28 expose à une amende pouvant atteindre 10 000 000 € ou 2 % du chiffre d’affaires annuel mondial (Art. 83(4)(a)).

Exemple résolu : revue d’un CRM dans une PME (cas hypothétique)

Cet exemple est fictif ; il illustre la méthode, non un cas réel.

Une société de services de 80 salariés utilise Sales Cloud pour la prospection, Service Cloud pour le support et deux applications de signature et d’enrichissement de contacts installées par l’équipe commerciale. Le DPO prépare une revue annuelle.

1. Inventaire. Il liste 4 ensembles fonctionnels et 6 connexions. Trois connexions n’ont plus de propriétaire : l’ancien responsable commercial les avait installées.
2. Qualification. L’application d’enrichissement envoie les adresses e-mail à l’éditeur, qui les rapproche de sa propre base. L’éditeur poursuit donc ses propres finalités : ce n’est pas une simple sous-traitance. La société suspend l’application, le temps d’analyser la base légale de cette communication.
3. Contrat. Le DPA principal est rapproché de la grille de l’Art. 28(3). Le DPO ajoute au dossier la liste des sous-traitants ultérieurs en vigueur et s’abonne aux notifications de changement.
4. Transferts. Le support de l’éditeur peut accéder aux données depuis un pays tiers. Le DPO identifie le mécanisme invoqué (décision d’adéquation, clauses contractuelles types) et en conserve la preuve.
5. Conservation. Les pièces jointes des opportunités perdues depuis plus de trois ans sont purgées ; une règle trimestrielle est planifiée.
6. Registre. Les fiches du registre sont mises à jour par finalité (prospection, support, facturation), pas par produit.

Le résultat attendu n’est pas un score, mais un dossier daté qui montre que chaque flux a un responsable, une base juridique et une règle de durée.

Transferts hors EEE : documenter le mécanisme

Une instance hébergée dans l’EEE n’exclut ni l’accès à distance depuis un pays tiers (support, administration), ni le recours à des sous-traitants ultérieurs situés hors EEE. Dans ces cas, le chapitre V du RGPD s’applique. Trois mécanismes reviennent le plus souvent : une décision d’adéquation (Art. 45), des garanties appropriées telles que les clauses contractuelles types (Art. 46) ou des règles d’entreprise contraignantes.

Pour les États-Unis, la décision d’exécution (UE) 2023/1795 du 10 juillet 2023 reconnaît un niveau de protection adéquat aux organisations certifiées au Data Privacy Framework. Vérifiez la certification de chaque destinataire sur la liste officielle et conservez une capture datée ; si le destinataire n’est pas certifié, c’est un autre mécanisme qui doit être documenté. Notre page sur le Data Privacy Framework suit l’état du dispositif, et les clauses contractuelles types détaillent le recours aux garanties contractuelles.

Exercer les droits des personnes dans le CRM

Une demande d’accès (Art. 15) ou d’effacement (Art. 17) doit être traitée dans le délai d’un mois de l’Art. 12(3), prolongeable de deux mois selon la complexité et le nombre de demandes. Dans un CRM, la difficulté vient de la dispersion : contact, pistes, requêtes de support, notes libres, pièces jointes, historiques d’e-mails, sauvegardes.

Préparez à l’avance une procédure testée : où chercher (objets standard et personnalisés, champs de texte libre, applications connectées), qui valide, comment exporter, comment supprimer ou anonymiser, comment informer les destinataires (Art. 19). Testez-la une fois par an sur un contact fictif : c’est le seul moyen de découvrir une copie oubliée avant une demande réelle.

Erreurs fréquentes

• Confondre contrat et conformité. Le DPA fixe un cadre ; il ne remplace ni les paramètres d’accès, ni la durée de conservation, ni l’information des personnes.
• Laisser les applications connectées sans propriétaire. Chaque connexion doit avoir un responsable et une date de revue.
• Traiter Hyperforce ou Shield comme une preuve de conformité. Ce sont des éléments d’architecture ; la conformité dépend de ce que vous en faites.
• Activer une fonction d’IA sans analyse préalable. Une fonction qui journalise les requêtes et réponses crée un nouveau traitement : finalité, base légale, durée et information doivent être revues. Si l’agent prend des décisions produisant des effets significatifs, l’Art. 22 doit être examiné, et une AIPD peut être requise au titre de l’Art. 35.
• Mettre à jour le registre par produit. Le registre (Art. 30) se tient par traitement.

Ce qu’il faut retenir

• Rassemblez les documents correspondant à chaque service et connexion utilisés.
• Distinguez résidence de l’instance et garanties d’une offre européenne particulière.
• Shield protège les données selon son périmètre ; il ne remplace pas les permissions.
• Les engagements de non-conservation des modèles tiers n’effacent pas tous les journaux Agentforce.
• Qualifiez les rôles (Art. 4) et rapprochez le DPA de l’Art. 28(3) clause par clause.
• Documentez le mécanisme de transfert (Art. 45 ou 46) pour tout accès hors EEE.
• Testez chaque année une demande d’accès ou d’effacement sur un contact fictif.

FAQ

Une certification Salesforce couvre-t-elle toutes les applications installées ?

Il faut vérifier le périmètre du rapport ou certificat. Une application tierce et ses traitements peuvent nécessiter des garanties distinctes.

Une clé fournie par le client signifie-t-elle que personne ne peut déchiffrer les données ?

Pas automatiquement. Le service doit pouvoir les traiter pour certains usages autorisés ; examinez le mécanisme de clés, le chiffrement réellement appliqué et les permissions.

Faut-il conserver une fiche de traitement par produit commercial ?

Le registre se structure par activité et finalité de traitement. Plusieurs produits peuvent servir une même activité, et un même produit peut contribuer à plusieurs traitements.

Salesforce est-il toujours sous-traitant ?

Non. Pour les données de vos clients et prospects saisies dans le CRM, il agit généralement comme sous-traitant. Pour ses propres finalités (sécurité de ses services, facturation, relation commerciale), il peut agir comme responsable du traitement. La qualification dépend des faits et des documents applicables à votre compte.

Faut-il une AIPD pour utiliser Agentforce ?

Pas automatiquement. L’Art. 35 impose une AIPD lorsque le traitement est susceptible d’engendrer un risque élevé ; le résultat dépend des données accessibles à l’agent, des décisions qu’il prend et des personnes concernées. Faites au minimum une analyse documentée du besoin d’AIPD.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.