Stratégie sandbox Salesforce : les 4 types expliqués (et combien il vous en faut vraiment)
Digital Stratify Team
August 4, 2026
5 min read

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

EnvironnementType sandboxUsage
Sandboxes Dev (une par dév)DeveloperTravail individuel
Intégration / QADeveloper ProTests de merge équipe
UATPartial CopyTests métier avec données réalistes
Staging / PréprodFullTests à é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

  1. Tester en prod. Jamais acceptable en 2026.
  2. UAT sur Developer avec fausses données, le métier ne teste pas de scénarios réalistes.
  3. Ne jamais refresh la Full, vous testez la régression contre des données rances.
  4. 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.