Sandbox Salesforce : lesquelles choisir et comment les rafraîchir

Une stratégie de sandbox mal pensée est l'une des causes les plus fréquentes de développements qui « marchent en test mais pas en prod ». Salesforce propose quatre types de sandbox aux caractéristiques très différentes ; choisir le bon type pour le bon usage évite des heures de débogage inutiles.

Les quatre types de sandbox

• Developer : copie de la configuration uniquement (metadata), sans données, limitée à 200 Mo de stockage. Idéale pour le développement individuel isolé, rafraîchissable une fois par jour.
• Developer Pro : identique au Developer mais avec 1 Go de stockage, adaptée aux équipes de développement ayant besoin de jeux de données de test un peu plus volumineux.
• Partial Copy : copie la configuration et un échantillon de données défini par un gabarit d'échantillonnage (sandbox template), jusqu'à un certain volume. Rafraîchissable tous les 5 jours. Bon compromis pour les tests d'intégration et la recette fonctionnelle.
• Full : copie complète de la configuration et de toutes les données de production, y compris l'historique des champs et les journaux. Rafraîchissable tous les 29 jours, réservée aux tests de performance, de charge et à la recette finale avant une mise en production majeure.

Quel type pour quel usage

Besoin	Sandbox recommandée
Développement Apex / Flow individuel	Developer
Intégration continue / pipeline DevOps	Developer ou Developer Pro
Recette fonctionnelle utilisateur (UAT)	Partial Copy
Tests de performance, formation, recette finale	Full

Créer un gabarit d'échantillonnage pour Partial Copy

Une Partial Copy ne copie pas les données au hasard : elle suit un sandbox template (Configuration > Modèles Sandbox) que vous définissez en sélectionnant les objets à inclure et, pour chacun, un critère SOQL de filtrage (ex. « Opportunités créées dans les 12 derniers mois »). Bien conçu, ce gabarit garantit un jeu de données réaliste et cohérent (avec ses relations parent-enfant préservées) sans importer des années d'historique inutile.

Le rafraîchissement : ce qu'il faut savoir

Rafraîchir une sandbox (Configuration > Sandbox > Actualiser) écrase entièrement son contenu par une nouvelle copie de production. Points de vigilance :

1. Délai minimum entre rafraîchissements : 1 jour (Developer), 5 jours (Partial Copy), 29 jours (Full) — planifiez vos cycles de développement en conséquence.
2. Tout le contenu non versionné est perdu : configuration modifiée directement en sandbox sans être poussée vers un repository Git, données de test créées manuellement, fichiers importés. Committez systématiquement vos métadonnées avant un rafraîchissement.
3. Les identifiants de connexion changent : le nom d'utilisateur est automatiquement suffixé (ex. user@entreprise.com.sandboxname) et les mots de passe doivent être réinitialisés après rafraîchissement.
4. Les intégrations externes pointant vers l'ancienne sandbox (webhooks, Named Credentials, Connected Apps) doivent être revérifiées : un rafraîchissement peut désactiver certains flux d'authentification OAuth.

Planifiez vos rafraîchissements de sandbox en dehors des sprints actifs de développement ou juste avant leur démarrage. Un rafraîchissement en plein sprint efface le travail non versionné et casse la continuité de la recette en cours.

Bonnes pratiques de gouvernance

• Attribuez un nom explicite et une convention à chaque sandbox (ex. DEV-Feature-XYZ, UAT-Q2) pour éviter la confusion entre environnements.
• Limitez le nombre de sandbox actives simultanément : chaque édition Salesforce a un quota, et une sandbox oubliée avec des données sensibles est un risque de sécurité (elle hérite des mêmes règles de masquage de données que vous n'avez peut-être pas activées).
• Activez le masquage de données (Data Mask) sur les sandbox contenant des données de production sensibles, surtout les Full et Partial Copy accessibles à des équipes de test élargies.
• Documentez le cycle de vie prévu de chaque sandbox (création, usage, date de suppression) dans votre outil de gestion de projet.

Une stratégie de sandbox claire, alignée sur votre cycle de release, est un prérequis silencieux mais essentiel à toute démarche DevOps sérieuse sur Salesforce.