Pourquoi ne jamais modifier la production directement
Une org de production est un environnement vivant. Des commerciaux y saisissent, des automatisations s'y déclenchent, des intégrations y écrivent, et vos données réelles y sont.
Modifier directement cet environnement revient à changer une pièce d'un moteur qui tourne. Cela fonctionne souvent, et le jour où cela ne fonctionne pas, l'incident est immédiat et visible par tout le monde. Une sandbox Salesforce existe précisément pour éviter cette situation : c'est une copie de votre org, isolée, dans laquelle une erreur ne coûte rien.
Trois risques justifient à eux seuls cette discipline. Une règle de validation activée par erreur bloque toute la saisie en quelques secondes. Une automatisation mal conçue modifie des milliers d'enregistrements avant que quiconque s'en aperçoive. Un changement de droits expose des données ou, à l'inverse, empêche une équipe entière de travailler.
Aucun de ces incidents ne se rattrape en un clic.
Ce qu'est réellement une sandbox
C'est une copie de votre org, avec sa configuration, dans laquelle vous pouvez tout casser sans conséquence. Votre abonnement en inclut, ce n'est pas un service à acheter.
Plusieurs types coexistent, et ils se distinguent principalement par les données qu'ils contiennent. Les environnements de développement copient la configuration sans vos données réelles : ils suffisent à la grande majorité des chantiers d'administration. D'autres types intègrent une partie ou la totalité des données, ce qui est utile pour éprouver un traitement sur du volume réel, avec des délais de rafraîchissement plus longs.
Deux précautions valent d'être connues. Une sandbox contenant des données réelles contient aussi des données personnelles : les mêmes règles de confidentialité s'y appliquent, et les adresses email doivent être neutralisées pour éviter tout envoi accidentel à vos clients. Et une sandbox rafraîchie écrase ce qu'elle contenait : ce qui n'a pas été déployé est perdu.
Ce que la sandbox permet vraiment
Au delà de la sécurité, elle change la nature du travail.
Elle permet de chiffrer honnêtement. C'est pour cette raison que je demande un accès avant d'établir un devis : j'explore la configuration réelle, je mesure l'écart avec le besoin, et j'annonce un prix fondé sur ce que j'ai vu plutôt que sur une description.
Elle permet de montrer avant de livrer. Un utilisateur qui voit fonctionner ce qu'il a demandé réagit très différemment de quelqu'un à qui l'on décrit une solution. Les malentendus se règlent là, quand ils coûtent encore une heure.
Elle permet enfin d'essayer plusieurs approches. La première idée n'est pas toujours la bonne, et pouvoir jeter un travail d'une demi-journée sans conséquence est un luxe qui améliore le résultat final.
La recette, et ce qui la rend utile
La recette est la validation par vous de ce qui a été construit. Sans elle, la fin de mission devient une négociation : vous estimez que le résultat ne correspond pas, l'intervenant estime avoir livré ce qui était demandé, et personne n'a de référence commune.
Une recette utile tient en quatre éléments, écrits avant de commencer les développements.
- Des cas concrets, issus de votre activité réelle, avec les valeurs attendues. Pas « le calcul doit être juste », mais « pour cette commande, avec cette remise, le montant doit être celui-ci ».
- Un testeur désigné, qui utilisera réellement la fonctionnalité. Un chef de projet qui valide à la place des utilisateurs valide une intention, pas un usage.
- Un délai. Une recette sans échéance s'étire, et le projet reste ouvert pendant des semaines.
- Une décision explicite à la fin : validé, validé avec réserves, ou refusé avec les motifs.
Le point le plus important est de faire tester par ceux qui utiliseront. Ils essaieront ce à quoi personne n'avait pensé, et c'est exactement ce que vous cherchez à ce moment-là.
La mise en production, l'étape qui se prépare
Une fois la recette validée, le déploiement transfère ce qui a été construit vers la production. Cette étape se décide séparément, et elle mérite quatre préparatifs.
Le moment. Jamais un vendredi soir, jamais en pleine période de clôture. Choisissez un créneau où quelqu'un est disponible pour réagir dans les heures qui suivent.
La liste de ce qui part. Champs, automatisations, droits, code, mises en page. Ce qui n'est pas listé sera oublié, et un composant déployé sans le champ dont il dépend échoue immédiatement.
Le retour arrière. Que fait-on si le comportement en production diffère de la sandbox ? Désactiver l'automatisation, restaurer une ancienne version, ou revenir à l'état antérieur. Cette réponse doit exister avant, pas pendant.
L'information des utilisateurs. Une automatisation la mieux conçue du monde sera contournée si personne n'explique pourquoi l'écran a changé. Un message court, la veille, suffit le plus souvent.
Après la mise en production
Le travail ne s'arrête pas au déploiement. Les premiers jours sont ceux où apparaissent les cas que la recette n'avait pas couverts.
Vérifiez le lendemain que les traitements planifiés se sont exécutés, que les alertes d'erreur arrivent à quelqu'un de présent, et que les utilisateurs ont réellement adopté le nouveau parcours plutôt que de le contourner.
C'est aussi le moment de figer la documentation : ce qui a été livré, pourquoi, et ce qui reste en suspens avec son estimation. Sans cela, la connaissance repart avec l'intervenant.
Le cas de l'urgence, et ses limites
La question arrive toujours : et quand c'est urgent ?
Soyons pragmatiques. Corriger une faute d'orthographe dans un libellé, ajouter une valeur à une liste déroulante, modifier un texte d'aide : le risque est nul, et exiger un passage complet par un environnement de test serait de la rigidité inutile.
Le raisonnement change dès que l'un de ces trois éléments est concerné : une automatisation, un droit d'accès, ou du code. Dans ces trois cas, l'urgence est précisément le pire moment pour se passer d'un test, parce qu'elle pousse à agir vite sur un système que l'on comprend mal, et que l'incident qui en résulte coûtera plus cher que l'heure économisée.
Ma règle pratique : si la modification peut se défaire en un clic et n'affecte qu'un affichage, elle peut se faire directement. Sinon, même en urgence, elle passe par une sandbox Salesforce, quitte à raccourcir la recette à un seul cas de test validé par une personne.
Une remise au propre menée dans une org qui a longtemps été modifiée en direct commence d'ailleurs presque toujours par la même constatation : personne ne sait plus ce qui a été changé, ni quand, ni par qui.
La question à poser à tout intervenant
« Travaillez-vous en sandbox avant la production ? » Si la réponse hésite, passez votre chemin.
Ce n'est pas une question de sérieux affiché, c'est une question de risque assumé. Un intervenant qui modifie directement votre production vous fait porter un risque qu'il ne paiera pas lui-même, et cette pratique finit toujours par coûter cher, en général au pire moment.
Ouvrir un accès à une sandbox Salesforce ne vous engage à rien : l'environnement est inclus dans votre abonnement, l'accès est nominatif, et il se révoque en un clic. C'est le point de départ que je demande systématiquement, avant même de parler de prix.
Questions fréquentes
Une sandbox Salesforce est-elle facturée en plus ?
Non, votre abonnement inclut des environnements de test. Le type inclus dépend de votre édition : les environnements de développement, qui copient la configuration sans les données, sont les plus courants et suffisent à la grande majorité des chantiers d'administration.
Peut-on modifier directement la production quand c'est urgent ?
Techniquement oui, et c'est précisément ce qui finit par coûter cher. Pour un correctif d'une ligne sur un champ, le risque reste faible. Dès qu'une automatisation, un droit ou du code est concerné, l'urgence est le pire moment pour se passer d'un test.