Vous venez de rafraîchir votre sandbox depuis la production. Cinq minutes plus tard, vos développeurs et vos consultants externes ont accès à 100 % des données client réelles : noms, emails, téléphones, contrats, parfois données financières ou de santé. Et personne dans votre organisation n’y a vraiment réfléchi.
C’est l’un des angles morts les plus fréquents en conformité RGPD Salesforce. Heureusement, c’est aussi l’un des plus faciles à corriger — encore faut-il choisir la bonne approche.
Pourquoi les sandboxes posent un problème RGPD
Une sandbox Salesforce est, par défaut, une copie partielle ou complète de votre production. C’est l’environnement où vos équipes développent, testent, forment, démontrent. Le problème : si la production contient des données personnelles, la sandbox aussi.
Le RGPD ne fait pas de distinction entre prod et sandbox. Si une donnée personnelle est traitée dans une sandbox sans base juridique, c’est un manquement. Et les bases juridiques de la production (exécution du contrat, intérêt légitime commercial) ne couvrent généralement pas l’usage en environnement de test.
Concrètement, la CNIL a déjà sanctionné des entreprises pour ce motif précis. Et au-delà du risque réglementaire, il y a un risque sécurité : un développeur qui télécharge la sandbox sur son laptop personnel = base de données client en exposition.
Les 3 approches possibles
Option 1 — Salesforce Data Mask
La solution officielle de Salesforce. C’est un produit additionnel, payant, qui s’achète avec licence dédiée.
Ce que ça fait :
- Masque automatiquement les champs sensibles après chaque refresh sandbox.
- Trois modes de masking : Anonymous (remplace par valeur aléatoire), Pseudonymous (remplace par alias cohérent réutilisable), Random (remplace par caractères aléatoires).
- Fonctionne sur les objets standard et custom.
- Chiffrement à la volée pendant le refresh, jamais de fenêtre où la donnée est exposée.
- Configuration centralisée et auditée.
Pour qui : entreprises mid-market et grands comptes avec budget conformité, plusieurs sandboxes, refresh fréquents.
Coût : licence Data Mask, négociable selon la taille de l’org. Comptez quelques dizaines de milliers d’euros par an.
Option 2 — Scripts Apex sur mesure
L’alternative pragmatique pour les entreprises qui n’ont pas le budget Data Mask. Notre approche chez Cloud Girafe :
- Développement de classes Apex spécifiques qui anonymisent les champs sensibles identifiés (noms, emails, téléphones, adresses, IBAN, données financières).
- Exécution déclenchée manuellement après chaque refresh sandbox, ou automatisée via un Trigger sur SandboxPostCopy si ergonomie permet.
- Pseudonymisation cohérente : Pierre Dupont devient toujours « UTILISATEUR-12345 » dans toutes les sandboxes.
- Logs et reporting de ce qui a été anonymisé.
Pour qui : associations, PME, ETI sans budget Data Mask, ou entreprises qui veulent garder le contrôle total sur les règles de masking.
Coût : développement initial 5 à 15 k€ selon la complexité du modèle de données. Maintenance légère ensuite.
Option 3 — Sandboxes vides + dataset de test
L’approche radicale : ne jamais rafraîchir les sandboxes depuis la production. À la place, construire un dataset de test fictif et l’importer dans les sandboxes.
- Sandboxes Developer ou Developer Pro toujours « propres » (sans données prod).
- Dataset de test géré séparément (CSV, scripts d’import, ou outil tiers comme Snowfakery).
- Aucune donnée personnelle réelle ne quitte la production.
Pour qui : organisations très sensibles (banque, santé, défense, secteur public régalien) où aucune fuite n’est acceptable.
Coût : effort de mise en place initial (construire le dataset de test), maintenance régulière.
Comment choisir
- Vous avez le budget et un grand nombre de sandboxes → Data Mask, c’est le standard.
- Vous voulez une solution rapide et sur mesure → scripts Apex.
- Vous êtes en environnement régulé fort → ajouter l’option 3 (sandboxes vides) sur les environnements les plus sensibles, et option 1 ou 2 sur les autres.
Les champs à toujours masker
- Standard : FirstName, LastName, Email, Phone, MobilePhone, MailingAddress, BillingAddress, Birthdate.
- Sensibles spécifiques : numéros de sécurité sociale, IBAN, numéros de cartes (qui ne devraient pas être en clair de toute façon), dates de naissance, identifiants nationaux de santé.
- Documents et fichiers : pièces jointes contenant des données personnelles. Souvent oubliées.
- Champs custom : faire la cartographie. Tous les champs « __c » qui contiennent des données personnelles doivent être listés et traités.
Les pièges classiques
- Oublier les Notes et Attachments. Les pièces jointes ne sont pas masquées par défaut. Si une note contient « Mr Dupont, 06 12 34 56 78 », elle reste visible.
- Oublier les emails archivés (Email Activities). Les emails synchronisés contiennent typiquement des données personnelles dans corps, signature, expéditeur.
- Oublier les rapports figés. Un rapport sauvegardé peut contenir des données figées au moment de la sauvegarde.
- Oublier les données dans les big objects ou external objects connectés à des systèmes tiers.
- Faire le masking 3 jours après le refresh. Pendant ces 3 jours, la sandbox contient les données réelles. Le masking doit être déclenché immédiatement.
Conclusion : pas de RGPD Salesforce sérieux sans masking sandbox
Que vous choisissiez Data Mask, scripts Apex ou sandboxes vides, l’important est qu’aucun rafraîchissement sandbox ne laisse de données personnelles réelles accessibles à des utilisateurs sans base juridique. C’est l’un des contrôles RGPD les plus simples à mettre en place et l’un des plus contrôlés par la CNIL.
Voir notre checklist RGPD Salesforce en 14 points pour le contexte global, et notre livre blanc Sécurité Salesforce pour la méthodologie complète.
Chez Cloud Girafe, nous proposons les trois approches selon votre contexte. Si vous voulez en discuter, contactez-nous sur cloudgirafe.fr.
