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

Réponse courte : l'org drift est le coût accumulé de chaque changement arrivé dans une org sans passer par votre processus. Il ne vient pas d'un mauvais admin ni d'une revue sautée, il est la somme de centaines de petites exceptions légitimes. Et le rafraîchissement trimestriel sur lequel comptent la plupart des équipes ne peut pas le corriger, car un refresh se fait au mieux une fois par mois alors que la dérive se crée chaque jour.

Qu'est-ce que l'org drift ?

L'org drift est l'écart entre ce qu'un environnement contient et ce que votre source de vérité dit qu'il devrait contenir. Entre sandbox et production, entre deux sandboxes, ou entre la production et le dépôt censé la décrire.

Le symptôme que tout le monde connaît : un changement qui a passé tous les tests en sandbox échoue au moment de partir en production. La cause n'est presque jamais le changement. C'est que la sandbox a cessé d'être un test honnête.

D'où vient réellement la dérive ?

Presque toute la dérive vient de changements raisonnables sur le moment :

• De la configuration faite directement en production. Une valeur de liste ajoutée un vendredi parce qu'une affaire l'exigeait. Bonne décision, invisible pour votre dépôt.
• Des correctifs jamais remergées. Le correctif est parti. La branche où il aurait dû atterrir ne l'a pas reçu.
• Des packages installés dans un seul environnement. Quelqu'un installe une app en sandbox pour l'évaluer, ou en production pour débloquer une équipe.
• Des droits accordés par exception. Profils et permission sets dérivent le plus vite dans la plupart des orgs et sont les moins souvent versionnés.
• Des réglages propres à chaque environnement. Endpoints, named credentials, délivrabilité email, tâches planifiées. C'est une dérive légitime, et il faut quand même la déclarer : si vous ne distinguez pas la dérive légitime de la dérive accidentelle, vous finirez par ignorer les deux.
• Le calendrier de release de Salesforce. Les instances sont mises à jour à des moments différents, donc deux environnements peuvent réellement tourner sur des versions différentes pendant une période.

Rien de tout cela n'est de la négligence. C'est un système qui laisse le changement entrer par plus d'une porte.

Pourquoi le refresh trimestriel ne règle-t-il rien ?

Le rituel du refresh suppose que la dérive se remet à zéro périodiquement. Regardez la cadence autorisée par Salesforce : les sandboxes Developer et Developer Pro se rafraîchissent 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 réaliste, la Full sandbox, a donc un plancher d'environ un mois. En pratique personne ne rafraîchit au rythme maximal, car un refresh efface le travail en cours, exige masquage et rechargement des données, et coûte ensuite plusieurs jours de remise en place. Trimestriel est le chiffre honnête.

Pendant ce temps, la dérive se crée chaque jour. On ne corrige pas un problème quotidien par un rituel trimestriel. Le refresh n'est pas inutile, il remet simplement à zéro un compteur qui repart aussitôt, et entre deux refresh votre confiance dans l'environnement de test se dégrade en continu sans que personne la mesure.

Que coûte vraiment la dérive ?

• Des déploiements en échec. Le coût visible, et le plus petit.
• Une fausse confiance. Bien pire. Des tests qui passent sur une sandbox dérivée ne vous apprennent rien, et vous ne le découvrez qu'en production.
• Des estimations plus longues. Les équipes ajoutent une marge pour les surprises de déploiement. Cette marge, c'est la dérive, chiffrée.
• Des rollbacks incomplets. Si la production contient de la configuration que votre dépôt n'a jamais eue, revenir au dépôt n'est pas revenir à un état connu.
• Une exposition en audit. "Qu'y a-t-il en production et qui l'a mis" doit avoir une seule réponse.

À quoi ressemble une détection continue de la dérive ?

1. Déclarez une source de vérité. En général Git. Tout le reste s'y compare. Sans cette étape, la détection 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'écart, ne l'affichez pas seulement. Trois catégories : différences d'environnement attendues, exceptions acceptées avec propriétaire et date de fin, et vraie dérive non planifiée.
4. Adressez-la immédiatement à un humain. Un rapport de dérive sans responsable est un tableau de bord, pas un contrôle.
5. Bouclez vers le dépôt. Les changements de production légitimes doivent être capturés en source, pas seulement signalés. Sinon chaque cycle rapportera éternellement le même élément.

La plupart des outils de la catégorie savent comparer deux environnements. Ce qui compte, c'est de savoir si la comparaison tourne sur un calendrier sans que personne ait à y penser, si la sortie est classée plutôt que brute, et si elle est branchée au pipeline qui déploie.

C'est le parti pris de Serpent : la détection de dérive côtoie les déploiements delta, le rollback en un clic et une revue de code par IA qui signale les écarts de gouvernance à chaque changement, le tout via des API standard, sans rien installer dans votre org. Détection et déploiement au même endroit, c'est une correction en une action plutôt qu'un ticket pour une autre équipe.

Que faire cette semaine ?

Prenez votre sandbox la plus critique et comparez-la une fois à la production. Triez le résultat en "attendu", "on le savait" et "qui a fait ça". Si la troisième pile est la plus grosse, arrêtez de planifier des refresh et planifiez des comparaisons.

FAQ

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

Des changements qui atteignent une org hors du processus de déploiement : configuration directe en production, correctifs non remergées, packages installés dans un seul environnement, modifications de droits, et réglages propres à un environnement jamais documentés comme tels.

Rafraîchir une sandbox corrige-t-il la dérive ?

Momentanément seulement. Une Full sandbox se rafraîchit au mieux tous les 29 jours et la plupart des équipes tiennent un rythme trimestriel, alors que la dérive s'accumule chaque jour.

À quelle fréquence vérifier la dérive ?

Quotidiennement pour la production et pour tout environnement servant à valider les releases. Plus lentement, vous perdez le contexte nécessaire pour expliquer ce qui a changé.

Toute dérive est-elle mauvaise ?

Non. Endpoints, credentials et tâches planifiées doivent différer. Le problème n'est pas l'existence de différences, c'est que les différences non déclarées sont indiscernables des erreurs.