Un CRM Salesforce agrège prospects, clients, contacts et historiques d'interaction : c'est l'un des traitements de données personnelles les plus exposés d'une ETI. Or la conformité RGPD ne se règle pas par une case cochée en fin de projet, mais par des choix d'architecture, de paramétrage et de gouvernance. Cette checklist en 22 points aide les DSI et les DPO à cadrer un projet Salesforce conforme, sans se substituer à un avis juridique.
Pourquoi Salesforce est un point sensible pour le RGPD
Salesforce est un traitement de données personnelles au sens du RGPD, et le plus souvent un sous-traitant au sens de l'article 28. L'entreprise reste responsable de traitement : c'est elle qui définit finalités, durées de conservation et mesures de sécurité. Les intégrations (marketing automation, téléphonie, ERP, outils d'enrichissement) élargissent la surface de risque, car chacune peut faire circuler des données hors du périmètre initialement documenté.
La CNIL n'exige pas une architecture unique, mais une capacité à démontrer la conformité (principe d'accountability). Une checklist structurée sert précisément à produire cette preuve : registre, contrats, journalisation, politiques de rétention.
Cadrage et gouvernance (points 1 à 6)
Documenter avant de paramétrer
- 1. Inscrire le traitement au registre (article 30) : finalités, catégories de données, destinataires, durées.
- 2. Identifier la base légale de chaque flux : intérêt légitime pour la prospection B2B, consentement pour certaines campagnes, exécution du contrat pour la relation client.
- 3. Cartographier les données personnelles réellement stockées dans les objets Salesforce (Lead, Contact, Account, champs personnalisés, pièces jointes, notes libres).
- 4. Évaluer la nécessité d'une AIPD (analyse d'impact) si le projet inclut du profilage, du scoring ou des données à risque.
- 5. Désigner les rôles : qui est responsable de traitement, qui administre l'instance, qui valide les évolutions de modèle de données.
- 6. Appliquer la minimisation : ne collecter que les champs utiles à une finalité déclarée, et challenger les champs « au cas où ».
Les champs texte libres (notes, commentaires) sont souvent le point faible. Ils peuvent contenir des données sensibles (santé, opinions) sans qu'aucune finalité ne le prévoie. Cadrez leur usage et sensibilisez les utilisateurs.
Sous-traitance et transferts (points 7 à 11)
Encadrer le prestataire et la localisation
- 7. Signer le DPA Salesforce (Data Processing Addendum) et vérifier qu'il couvre bien votre périmètre.
- 8. Recenser les sous-traitants ultérieurs déclarés par Salesforce et les intégrateurs tiers connectés à l'instance.
- 9. Documenter la localisation d'hébergement et vérifier les options d'implantation des données (dont options UE selon les offres).
- 10. Encadrer les transferts hors UE le cas échéant : clauses contractuelles types, analyse d'impact du transfert.
- 11. Contractualiser avec l'intégrateur : si l'agence accède aux données de production, un contrat de sous-traitance est requis, avec engagement de confidentialité et de restitution/suppression.
Ce dernier point est souvent négligé lors du choix d'un prestataire. L'accès aux données réelles pendant la recette ou le run engage la responsabilité de l'entreprise. Il mérite d'être discuté au même titre que le périmètre fonctionnel.
Aller plus loin
Paramétrage et sécurité de l'instance (points 12 à 18)
Traduire la conformité en configuration
- 12. Restreindre les accès par profils, ensembles d'autorisations et rôles : appliquer le moindre privilège plutôt que des profils larges par défaut.
- 13. Sécuriser l'authentification : SSO, authentification multifacteur, politiques de mot de passe et restrictions d'adresses IP.
- 14. Activer la journalisation des accès et des exports pour tracer qui consulte ou extrait des données.
- 15. Chiffrer les données sensibles selon les besoins, en évaluant les fonctionnalités de chiffrement disponibles dans votre édition.
- 16. Contrôler les exports massifs (rapports, Data Loader, API) qui peuvent faire sortir des volumes importants sans traçabilité.
- 17. Séparer les environnements : éviter d'utiliser des données personnelles réelles dans les sandbox de développement, ou les anonymiser.
- 18. Maîtriser les intégrations : chaque connecteur (marketing, téléphonie, enrichissement) doit être inscrit au registre et couvert par un contrat.
Droits des personnes et cycle de vie (points 19 à 22)
Rendre les droits opérationnels
- 19. Outiller les droits d'accès, rectification et effacement : savoir retrouver toutes les occurrences d'une personne dans les objets et les doublons.
- 20. Gérer les durées de conservation : définir des règles d'archivage et de purge automatiques par catégorie de données, plutôt qu'une conservation illimitée.
- 21. Tracer et honorer les oppositions à la prospection et les préférences de contact, en cohérence avec les outils marketing connectés.
- 22. Préparer la gestion des violations : procédure d'alerte, capacité à qualifier l'incident et à notifier la CNIL dans les 72 heures si nécessaire.
Ces quatre derniers points font la différence entre une conformité déclarative et une conformité démontrable. Une demande d'effacement mal traitée, faute d'outillage, est l'un des motifs les plus fréquents de réclamation auprès de la CNIL.
Comment utiliser cette checklist dans un projet
La conformité RGPD gagne à être intégrée dès le cadrage, pas ajoutée en fin de déploiement. Concrètement, les points 1 à 6 relèvent du DPO et du métier, les points 12 à 18 de la DSI et de l'intégrateur, et les points 7 à 11 de la direction juridique. Le DPO n'a pas à paramétrer l'instance, mais il doit pouvoir vérifier que la configuration traduit fidèlement les engagements documentés.
Sur le plan pratique, chaque point peut devenir une exigence du cahier des charges et un critère d'évaluation des prestataires. Un intégrateur qui parle spontanément de gestion des droits, de purge et de contrat de sous-traitance montre une maturité utile pour un projet d'ETI. Les sources officielles (cnil.fr, service-public.fr, texte du RGPD) restent les références à jour : les fonctionnalités de sécurité de Salesforce évoluant, il est recommandé de vérifier la documentation en vigueur au moment du projet.
Attention enfin à ne pas confondre outil et responsabilité : Salesforce fournit des fonctionnalités, mais la conformité reste portée par l'entreprise. Aucun paramétrage ne remplace une gouvernance des données claire et un registre tenu à jour.