Gestion des sandboxes Salesforce : types, stratégie de rafraîchissement et workflow de déploiement

La gestion des sandboxes Salesforce est souvent une réflexion après coup — jusqu'au jour où vous avez un déploiement cassé, des données de test corrompues, ou un audit de conformité demandant pourquoi des données de production se trouvent dans un sandbox développeur. Voici comment faire les choses correctement.

Types de sandbox : lequel pour quoi

Type	Métadonnées	Données	Rafraîchissement	Cas d'usage
Developer	Copie complète	Aucune	1 jour	Développement individuel
Developer Pro	Copie complète	Aucune	1 jour	Développement en équipe, stockage plus grand
Partial	Copie complète	Sous-ensemble (jusqu'à 10k enregistrements)	5 jours	Tests QA avec données représentatives
Full	Copie complète	Copie complète	29 jours	UAT, staging, tests de performance

Note sur les coûts : Les sandboxes Developer sont généralement inclus dans les licences Enterprise/Unlimited (vous en avez plusieurs). Les sandboxes Partial et Full sont limités — souvent 1 de chaque. Planifiez soigneusement.

La stratégie de sandbox recommandée

Pour une équipe de 3+ développeurs, ce modèle de branchement fonctionne bien :

[Sandbox Dev 1] ──┐
[Sandbox Dev 2] ──┤ déployer → [Sandbox Intégration] → [UAT/Staging] → [Production]
[Sandbox Dev 3] ──┘

Sandboxes Developer (1 par développeur ou fonctionnalité) : rafraîchissement journalier disponible
Intégration (Developer Pro ou Partial) : fusionne tout le travail développeur, premiers tests d'intégration
UAT/Staging (Full) : tests par les utilisateurs métier avec données à l'échelle réelle
Production : ne reçoit que des releases validées et approuvées

Créer un sandbox

Via l'interface Setup

Configuration → Environnements → Bacs à sable → Nouveau bac à sable
Choisir le type, le nom (ex. DEV-alice, INTEGRATION, UAT)
Pour Partial/Full : sélectionner la source de données

Via la CLI Salesforce

# Créer un sandbox via CLI
sf org create sandbox \
    --name DEV-feature-lwc \
    --license-type Developer \
    --target-org production \
    --alias dev-lwc
 
# Authentifier un sandbox existant
sf org login web --alias dev-lwc --instance-url https://test.salesforce.com
 
# Vérifier la connexion
sf org display --target-org dev-lwc

Planification des rafraîchissements

Quand rafraîchir

Un rafraîchissement efface le sandbox et le recrée depuis la production. Cela signifie :

Toutes les personnalisations spécifiques au sandbox sont perdues
Les noms d'utilisateur changent (suffixe ajouté : utilisateur@entreprise.com.integrationsandbox)
Les apps connectées et les credentials nommés peuvent nécessiter une reconfiguration

Déclencheurs de rafraîchissement :

Grandes releases de production (rafraîchir l'UAT avant le cycle UAT)
Incidents de sécurité
Cadence planifiée (sandbox d'intégration : mensuel ; developer : selon besoin)

Runbook post-rafraîchissement

Créez un runbook documenté pour la configuration post-rafraîchissement :

## Checklist post-rafraîchissement : Sandbox INTEGRATION
 
1. [ ] Mettre à jour les Named Credentials pour pointer vers les API sandbox (pas production)
2. [ ] Ré-authentifier toutes les Connected Apps
3. [ ] Vérifier que tous les utilisateurs peuvent se connecter (les noms d'utilisateur ont un suffixe)
4. [ ] Désactiver ou mettre à jour les règles d'email sortant
       (éviter que les emails de test partent à de vrais utilisateurs)
5. [ ] Exécuter le script de smoke test : sf apex run --file scripts/smoke-test.apex
6. [ ] Mettre à jour la config du pipeline avec le nouvel ID de session
7. [ ] Notifier l'équipe via Slack : #déploiements

Anonymisation des données pour la conformité (RGPD)

Les sandboxes Partial et Full peuvent contenir des données de production. C'est un risque RGPD/confidentialité si ces données incluent des DCP (données à caractère personnel).

Option 1 : Sandbox Data Mask (natif Salesforce)

Disponible en option payante. Masque automatiquement les champs DCP lors de la copie sandbox.

Option 2 : Script Apex d'anonymisation post-rafraîchissement

Exécuter immédiatement après le rafraîchissement, avant d'accorder l'accès aux développeurs :

// AnonymiserContactsBatch.cls — Batch Apex : une transaction est limitée à 10 000 lignes DML,
// trop peu pour 50 000 Contacts en Apex anonyme. Chaque lot est une transaction distincte.
public class AnonymiserContactsBatch implements Database.Batchable<SObject> {
 
    public Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator([SELECT Id FROM Contact]);
    }
 
    public void execute(Database.BatchableContext bc, List<Contact> scope) {
        for (Contact c : scope) {
            // Pas de compteur partagé entre les lots : le suffixe vient de l'Id
            String suffix = String.valueOf(c.Id).right(6);
            c.FirstName     = 'Test';
            c.LastName      = 'Utilisateur ' + suffix;
            c.Email         = 'testuser.' + suffix + '@sandbox.test';
            c.Phone         = '0600000000';
            c.MailingStreet = '123 Rue de Test';
        }
        update scope;
    }
 
    public void finish(Database.BatchableContext bc) {
        System.debug('Anonymisation des Contacts terminée');
    }
}
 
// Lancement en Apex anonyme, juste après le rafraîchissement :
// Database.executeBatch(new AnonymiserContactsBatch(), 2000);

Anonymisez toujours avant l'accès développeur. Un sandbox avec de vrais emails clients finira inévitablement par envoyer un email de test à un vrai client.

Workflow de déploiement : dev → production

Avec la CLI Salesforce

Étape 1 : Dans le sandbox dev — récupérer vos changements

# Récupérer les changements depuis le sandbox vers le projet local
sf project retrieve start --target-org dev-lwc
 
# Ou récupérer des types de métadonnées spécifiques
sf project retrieve start \
    --metadata "ApexClass:AccountTriggerHandler" \
    --metadata "LightningComponentBundle:accountSummaryCard" \
    --target-org dev-lwc

Étape 2 : Valider contre l'org cible (sans déploiement)

sf project deploy validate \
    --source-dir force-app/main/default \
    --target-org integration \
    --test-level RunLocalTests

Étape 3 : Déployer si la validation réussit

sf project deploy start \
    --source-dir force-app/main/default \
    --target-org integration \
    --test-level RunLocalTests

Automatisé avec GitHub Actions

# .github/workflows/deploy-integration.yml
name: Déployer vers Intégration
 
on:
  push:
    branches: [integration]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Installer Salesforce CLI
        run: npm install -g @salesforce/cli
 
      - name: Authentifier sur le sandbox Intégration
        run: |
          echo "${{ secrets.INTEGRATION_SFDX_AUTH_URL }}" > auth.json
          sf org login sfdx-url --sfdx-url-file auth.json --alias integration
 
      - name: Valider le déploiement
        run: |
          sf project deploy validate \
            --source-dir force-app \
            --target-org integration \
            --test-level RunLocalTests
 
      - name: Déployer
        run: |
          sf project deploy start \
            --source-dir force-app \
            --target-org integration \
            --test-level RunLocalTests

Gestion des utilisateurs sandbox

Après un rafraîchissement, les noms d'utilisateur sandbox reçoivent un suffixe.

Désactiver les utilisateurs non autorisés dans le sandbox

// Désactiver les utilisateurs dans le sandbox qui ne devraient pas avoir accès
// (ex. anciens employés répliqués depuis la production)
List<User> aDesactiver = [
    SELECT Id FROM User
    WHERE IsActive = true
    AND Profile.Name NOT IN ('Administrateur système', 'Profil Développeur')
];
for (User u : aDesactiver) u.IsActive = false;
update aDesactiver;

Checklist de gestion des sandboxes

Configuration :

Chaque développeur actif a son propre sandbox Developer
Sandboxes Intégration, UAT et production documentés
Noms de sandboxes suivant une convention : [TYPE]-[OBJECTIF]

Conformité :

DCP anonymisées dans tous les sandboxes avec données réelles (Full, Partial)
Délivrabilité email réglée sur « Email système uniquement » hors production
Accès sandbox restreint aux membres actuels de l'équipe

Déploiement :

Déploiement validé avant deploy (ne jamais passer la validation)
Niveau de test : RunLocalTests minimum pour l'intégration, RunAllTestsInOrg pour la production
Plan de rollback documenté avant chaque déploiement production

Rafraîchissement :

Runbook post-rafraîchissement maintenu et à jour
Sandbox d'intégration rafraîchi au moins mensuellement
UAT rafraîchi avant chaque cycle UAT

Conclusion

Une bonne gestion des sandboxes est la différence entre un processus de déploiement chaotique et un processus reproductible et fiable. Les habitudes clés : anonymiser les DCP immédiatement après chaque rafraîchissement, imposer un chemin de promotion linéaire (dev → intégration → UAT → production), valider avant de déployer, et maintenir un runbook post-rafraîchissement pour que la configuration ne soit jamais improvisée.

Ressources utiles :