Comment alimenter une sandbox Salesforce avec des données réalistes

Réponse courte : bien alimenter une sandbox Salesforce, ce sont trois travaux, pas un. Extrayez une tranche de production consciente des relations plutôt qu'un nombre d'enregistrements, chargez-la des parents vers les enfants avec des identifiants externes stables pour que le même jeu puisse être rechargé, et anonymisez de façon déterministe pour que les données se comportent encore comme de vraies données. Versionnez ensuite la définition du jeu à côté de vos métadonnées, car ce qui tue un jeu de données n'est pas le premier chargement, c'est le changement de schéma trois sprints plus tard.

Qu'est-ce que le seeding de sandbox ?

Le seeding consiste à copier un sous-ensemble d'enregistrements de production vers un environnement inférieur, afin que l'org dispose de données réalistes pour développer et tester, les valeurs sensibles étant masquées avant leur arrivée. C'est un problème de données, pas de métadonnées : un refresh de sandbox apporte la configuration et vous laisse, le plus souvent, une org vide ou inexploitable.

Quelles sandboxes ont vraiment besoin d'être alimentées ?

Celles qui ne copient pas les données pour vous. D'après la documentation Salesforce sur les licences et limites de stockage : Developer (200 Mo) et Developer Pro (1 Go) ne copient que les métadonnées et se rafraîchissent chaque jour, ce sont celles que vous alimentez. Partial Copy (5 Go, tous les 5 jours) apporte un échantillon choisi par un modèle et vous comblez les trous. Full (taille production, tous les 29 jours) apporte tout, et c'est pour cela que le masquage y compte davantage. Les scratch orgs démarrent toujours vides : le seeding y est obligatoire.

Comment choisir une tranche consciente des relations ?

L'échec classique consiste à sélectionner par volume : 500 Accounts, 500 Contacts, en espérant qu'ils soient reliés. Ils ne le sont pas, et les testeurs recréent toute la semaine les enregistrements promis.

Sélectionnez plutôt par graphe, en partant d'un petit ensemble d'enregistrements racines :

1. Choisissez les racines avec intention. Vingt à cinquante Accounts couvrant ensemble vos record types, devises, pays, territoires et cas limites. Un très gros client, un tout nouveau, un avec une adresse cassée.
2. Descendez vers les enfants. Contacts, Opportunities, lignes, Cases, objets personnalisés et les objets de jonction entre eux.
3. Remontez par les lookups. Si une Opportunity pointe vers un Pricebook, une Campaign ou un Contract personnalisé, ces parents suivent, sinon l'insertion échoue.
4. Traitez les données de référence à part. Produits, entrées de pricebook et enregistrements de configuration sont la copie complète d'une petite table, pas une tranche de graphe.

Quelques centaines d'enregistrements bien reliés valent mieux que cent mille enregistrements isolés, sauf pour les tests de charge.

Dans quel ordre charger les enregistrements ?

Ordre de dépendance strict, les parents avant les enfants, et chaque objet clé sur quelque chose de stable.

• Ne transportez jamais les identifiants Salesforce d'une org à l'autre. Ils ne survivent pas. Ajoutez un champ texte identifiant externe sur chaque objet alimenté, remplissez-le depuis l'enregistrement source et faites un upsert dessus. Le chargement devient idempotent : relance-le et il met à jour au lieu de dupliquer.
• Traitez les références circulaires en deux passés. Les auto-lookups comme Account.ParentId, et les paires qui se pointent mutuellement, ne peuvent pas être satisfaites en une insertion. Chargez les enregistrements avec le lookup vide, puis lancez une seconde passe qui ne renseigne que ce lookup.
• Remappez la propriété. Owner et tout lookup vers User ne se résoudront pas : les noms d'utilisateur en sandbox reçoivent un suffixe et vos utilisateurs de production peuvent y manquer. Remappez-les avant le chargement.
• Les jonctions en dernier. Ne chargez un objet de jonction qu'une fois ses deux maîtres créés.
• Contournez l'automatisation, ne la désactivez pas. Triggers, flows, règles de validation et de doublons se déclenchent pendant le chargement. Un interrupteur de contournement consulté par votre automatisation vaut mieux que déployer des désactivations.

Comment anonymiser sans rendre les données inutiles ?

Un masquage qui produit du bruit vaut le non-masquage : personne ne fait confiance à un test tombé sur des données absurdes. Adaptez la technique au champ :

• Pseudonymes déterministes pour tout ce qui sert aux jointures, au rapprochement ou au dédoublonnage. La même entrée doit toujours donner la même sortie, pour qu'un client reste un client sur tous les objets.
• Mélange à l'intérieur de la colonne quand la distribution compte plus que la valeur, par exemple les tranches de chiffre d'affaires ou les dates de clôture sur lesquelles vous reportez.
• Suppression pure et simple pour les champs qu'aucun test ne touche. Les notes libres, les descriptions et les pièces jointes sont là où les données personnelles se cachent réellement.
• Neutralisez tout ce qui peut sortir. E-mails, numéros de téléphone et identifiants externes utilisés par les intégrations doivent être réécrits vers des valeurs qui ne peuvent atteindre personne, et le paramètre de délivrabilité e-mail de la sandbox vérifié avant le premier chargement.

Salesforce propose Anonymize for Salesforce, et Gearset, Odaseva, Flosum et Serpent proposent des outils de seeding avec masquage intégré. Quel que soit l'outil, le jeu de règles doit être validé une fois, par écrit, par le responsable de la protection des données.

Que se passe-t-il quand le schéma change ?

C'est la partie que presque personne ne traite, et c'est pourquoi la plupart des jeux meurent en un trimestre. Une définition de seeding est une photo figée de votre schéma : listes de champs, valeurs de picklist, champs obligatoires, règles de validation. Livrez un nouveau champ obligatoire et tous les chargements suivants échouent.

Traitez le jeu de données comme du code source :

• Versionnez la définition dans le dépôt, à côté des métadonnées dont elle dépend, pour qu'un changement de schéma et son changement de seeding arrivent dans la même pull request.
• Dérivez les colonnes d'un appel describe plutôt que de figer une liste manuelle, afin que les nouveaux champs ne disparaissent pas en silence.
• Exécutez le chargement en CI contre une scratch org sur toute pull request touchant objets, champs ou règles de validation. Un chargement en échec est un échec de build légitime : il signale que vous venez de casser la création de données.
• Régénérez après chaque refresh. Les valeurs de picklist sont renommées et des record types disparaissent ; un jeu correct en mars est une file d'erreurs de validation en juin.

Dans Serpent, une opération de données est une action de pipeline à part entière plutôt qu'une corvée manuelle, ce qui permet au chargement de vivre dans le même pipeline que le déploiement qu'il soutient. Serpent masque aussi les PII pendant la migration : activez l'option dans Migrate Data et le seed arrive masqué.

Alignez enfin la cadence sur vos releases : chaque itération pour les sandboxes de développement, chaque campagne de tests pour la recette, toujours après un refresh. Comme le chargement est idempotent et versionné, c'est une exécution de pipeline et non un projet. D'autres guides DevOps Salesforce.

FAQ

Quel volume de données une sandbox alimentée doit-elle contenir ?

De quoi couvrir chaque record type, parcours et cas limite, en général quelques centaines d'enregistrements reliés. Le volume ne compte que pour les tests de charge.

Puis-je simplement utiliser Data Loader ?

Oui, pour un petit jeu. Vous prenez alors en charge vous-même l'ordre de chargement, le remappage des identifiants et le masquage, et vous les refaites à la main à chaque refresh.

Un refresh de sandbox conserve-t-il les données chargées ?

Non. Un refresh remplace la sandbox : tout ce que vous aviez chargé disparaît. Prévoyez le rechargement comme étape standard après refresh.