
Stratégie sandbox Salesforce : les 4 types expliqués (et combien il vous en faut vraiment)
Salesforce livre quatre types de sandbox. La plupart des équipes en font mauvais usage. Voici la stratégie qui livre un pipeline propre sans payer pour des sandboxes jamais ouvertes.
Salesforce livre quatre types de sandbox, et la plupart des équipes prennent le mauvais mix, soit elles paient pour de la capacité inutilisée, soit elles essaient de tout faire tenir dans une Developer qui ne peut pas contenir de vraies données. Voici la stratégie qui livre un pipeline propre sans surpayer.
Les quatre types
- Developer, metadata seulement, 200 MB de données. Refresh quotidien. Gratuit dans la plupart des éditions.
- Developer Pro, comme Developer avec 1 GB. Refresh quotidien.
- Partial Copy, metadata + jusqu'à 5 GB d'échantillon. Refresh tous les 5 jours.
- Full, metadata + toutes les données. Refresh tous les 29 jours. Payant, tarifé sur le volume.
Le modèle d'environnement qui marche
| Environnement | Type sandbox | Usage |
|---|---|---|
| Sandboxes Dev (une par dév) | Developer | Travail individuel |
| Intégration / QA | Developer Pro | Tests de merge équipe |
| UAT | Partial Copy | Tests métier avec données réalistes |
| Staging / Préprod | Full | Tests à échelle, tests de charge |
La cadence de refresh
- Dev : refresh au début de chaque sprint.
- QA : refresh après chaque release déployée.
- UAT : refresh au début de chaque gros projet.
- Full : refresh mensuel, toujours avant une release majeure. Voir guide release freeze.
La question des données
Tout ce qui est au-dessus de Partial Copy contient des données client. Anonymisez avant d'ouvrir aux dévs. Voir guide anonymisation sandbox.
Optimisation des coûts
- Supprimer les sandboxes dev inutilisées, chacune prend du stockage et ralentit les refresh.
- Templates Partial Copy : définir une fois, réutiliser.
- Full : une suffit généralement. Deux uniquement si projets majeurs parallèles.
Erreurs classiques
- Tester en prod. Jamais acceptable en 2026.
- UAT sur Developer avec fausses données, le métier ne teste pas de scénarios réalistes.
- Ne jamais refresh la Full, vous testez la régression contre des données rances.
- Pas de versioning du setup sandbox, nouveaux envs prennent des jours à bootstrapper.
Notes régionales
- UE : la résidence des copies sandbox compte, les Full doivent respecter les mêmes règles que la prod. Voir guide RGPD.
- Secteurs régulés : certains auditeurs exigent un planning documenté de refresh et anonymisation.
Questions fréquentes
Coût d'une Full sandbox ?
Tarifée en % de votre valeur de licences ; typiquement plusieurs milliers de $ par an.
Partager une sandbox entre équipes ?
Oui pour QA/UAT. Jamais pour le travail dev.
Fréquence de refresh Full ?
Mensuel, plus avant chaque release majeure.
Partial Copy nécessaire ?
Pas toujours. Sautable si UAT tourne sur une Full à la place.
Évaluation de stratégie sandbox
Notre audit Salesforce inclut une revue de topologie sandbox avec optimisation des coûts. Réservez un appel de 30 minutes.
Si ça ressemble à votre CRM, regardons-le ensemble.
Trente minutes, sans slides, sans pitch commercial. Vous repartez avec un diagnostic dans tous les cas.