Org drift : pourquoi vos sandboxes Salesforce ne ressemblent plus a la production

Reponse courte : l'org drift est le cout accumule de chaque changement arrive dans une org sans passer par votre processus. Il ne vient pas d'un mauvais admin ni d'une revue sautee, il est la somme de centaines de petites exceptions legitimes. Et le rafraichissement trimestriel sur lequel comptent la plupart des equipes ne peut pas le corriger, car un refresh se fait au mieux une fois par mois alors que la derive se cree chaque jour.

Qu'est-ce que l'org drift ?

L'org drift est l'ecart entre ce qu'un environnement contient et ce que votre source de verite dit qu'il devrait contenir. Entre sandbox et production, entre deux sandboxes, ou entre la production et le depot cense la decrire.

Le symptome que tout le monde connait : un changement qui a passe tous les tests en sandbox echoue au moment de partir en production. La cause n'est presque jamais le changement. C'est que la sandbox a cesse d'etre un test honnete.

D'ou vient reellement la derive ?

Presque toute la derive vient de changements raisonnables sur le moment :

• De la configuration faite directement en production. Une valeur de liste ajoutee un vendredi parce qu'une affaire l'exigeait. Bonne decision, invisible pour votre depot.
• Des correctifs jamais remergees. Le correctif est parti. La branche ou il aurait du atterrir ne l'a pas recu.
• Des packages installes dans un seul environnement. Quelqu'un installe une app en sandbox pour l'evaluer, ou en production pour debloquer une equipe.
• Des droits accordes par exception. Profils et permission sets derivent le plus vite dans la plupart des orgs et sont les moins souvent versionnes.
• Des reglages propres a chaque environnement. Endpoints, named credentials, delivrabilite email, taches planifiees. C'est une derive legitime, et il faut quand meme la declarer : si vous ne distinguez pas la derive legitime de la derive accidentelle, vous finirez par ignorer les deux.
• Le calendrier de release de Salesforce. Les instances sont mises a jour a des moments differents, donc deux environnements peuvent reellement tourner sur des versions differentes pendant une periode.

Rien de tout cela n'est de la negligence. C'est un systeme qui laisse le changement entrer par plus d'une porte.

Pourquoi le refresh trimestriel ne regle-t-il rien ?

Le rituel du refresh suppose que la derive se remet a zero periodiquement. Regardez la cadence autorisee par Salesforce : les sandboxes Developer et Developer Pro se rafraichissent environ une fois par jour, les Partial Copy tous les cinq jours et les Full tous les 29 jours (voir la documentation Salesforce sur les types de sandbox).

L'environnement le plus important pour un test realiste, la Full sandbox, a donc un plancher d'environ un mois. En pratique personne ne rafraichit au rythme maximal, car un refresh efface le travail en cours, exige masquage et rechargement des donnees, et coute ensuite plusieurs jours de remise en place. Trimestriel est le chiffre honnete.

Pendant ce temps, la derive se cree chaque jour. On ne corrige pas un probleme quotidien par un rituel trimestriel. Le refresh n'est pas inutile, il remet simplement a zero un compteur qui repart aussitot, et entre deux refresh votre confiance dans l'environnement de test se degrade en continu sans que personne la mesure.

Que coute vraiment la derive ?

• Des deploiements en echec. Le cout visible, et le plus petit.
• Une fausse confiance. Bien pire. Des tests qui passent sur une sandbox derivee ne vous apprennent rien, et vous ne le decouvrez qu'en production.
• Des estimations plus longues. Les equipes ajoutent une marge pour les surprises de deploiement. Cette marge, c'est la derive, chiffree.
• Des rollbacks incomplets. Si la production contient de la configuration que votre depot n'a jamais eue, revenir au depot n'est pas revenir a un etat connu.
• Une exposition en audit. "Qu'y a-t-il en production et qui l'a mis" doit avoir une seule reponse.

A quoi ressemble une detection continue de la derive ?

1. Declarez une source de verite. En general Git. Tout le reste s'y compare. Sans cette etape, la detection produit deux listes et aucun verdict.
2. Photographiez chaque environnement selon un calendrier. Quotidien vaut mieux qu'hebdomadaire. La valeur est d'attraper un changement pendant que son auteur se souvient encore du pourquoi.
3. Classez l'ecart, ne l'affichez pas seulement. Trois categories : differences d'environnement attendues, exceptions acceptees avec proprietaire et date de fin, et vraie derive non planifiee.
4. Adressez-la immediatement a un humain. Un rapport de derive sans responsable est un tableau de bord, pas un controle.
5. Bouclez vers le depot. Les changements de production legitimes doivent etre captures en source, pas seulement signales. Sinon chaque cycle rapportera eternellement le meme element.

La plupart des outils de la categorie savent comparer deux environnements. Ce qui compte, c'est de savoir si la comparaison tourne sur un calendrier sans que personne ait a y penser, si la sortie est classee plutot que brute, et si elle est branchee au pipeline qui deploie.

C'est le parti pris de Serpent : la detection de derive cotoie les deploiements delta, le rollback en un clic et une revue de code par IA qui signale les ecarts de gouvernance a chaque changement, le tout via des API standard, sans rien installer dans votre org. Detection et deploiement au meme endroit, c'est une correction en une action plutot qu'un ticket pour une autre equipe.

Que faire cette semaine ?

Prenez votre sandbox la plus critique et comparez-la une fois a la production. Triez le resultat en "attendu", "on le savait" et "qui a fait ca". Si la troisieme pile est la plus grosse, arretez de planifier des refresh et planifiez des comparaisons.

FAQ

Qu'est-ce qui provoque la derive d'une org Salesforce ?

Des changements qui atteignent une org hors du processus de deploiement : configuration directe en production, correctifs non remergees, packages installes dans un seul environnement, modifications de droits, et reglages propres a un environnement jamais documentes comme tels.

Rafraichir une sandbox corrige-t-il la derive ?

Momentanement seulement. Une Full sandbox se rafraichit au mieux tous les 29 jours et la plupart des equipes tiennent un rythme trimestriel, alors que la derive s'accumule chaque jour.

A quelle frequence verifier la derive ?

Quotidiennement pour la production et pour tout environnement servant a valider les releases. Plus lentement, vous perdez le contexte necessaire pour expliquer ce qui a change.

Toute derive est-elle mauvaise ?

Non. Endpoints, credentials et taches planifiees doivent differer. Le probleme n'est pas l'existence de differences, c'est que les differences non declarees sont indiscernables des erreurs.