Release freeze Salesforce : protéger le go-live sans bloquer le métier

Les release freezes paraissent bureaucratiques, jusqu'au vendredi avant go-live, quand un « petit changement » du marketing casse le Flow de capture des leads. Un freeze bien conçu n'est pas fait pour ralentir le métier ; il est fait pour rendre prévisibles les deux dernières semaines. Voici la politique pragmatique que nous appliquons sur chaque lancement Salesforce, avec le process d'exception qui laisse passer l'urgent sans démolir le launch.

Ce qu'un release freeze veut vraiment dire

• Pas de nouvelles features en prod.
• Pas de modif de métadonnées sans validation du change-board.
• Seuls les bug fixes critiques et patches de sécurité passent.
• Refresh de sandbox suspendus.
• Chargements de données groupés, planifiés, revus.

Pourquoi les freezes échouent

La plupart échouent parce qu'annoncés trop tard, sans process d'exception, ou tenus par une seule personne pressurée. Résultat : tout le monde les traite en suggestion et le launch reçoit un hotfix à minuit.

Le playbook qui marche vraiment

1. Annoncer 4 semaines à l'avance. Publier dates, périmètre, process d'exception. Envoyer aux sales ops, marketing, IT et tout admin avec accès de déploiement.
2. Nommer un change-board de trois. Un delivery, un métier, un IT sécu. Deux voix sur trois pour approuver.
3. Publier le formulaire d'exception. Dix champs max : quoi, urgence, blast radius, plan de rollback, testé où.
4. Appliquer par l'outillage. Gearset, Copado ou Salesforce DevOps Center pour verrouiller les déploiements. L'application manuelle fuit toujours.
5. Communiquer tous les jours. 3 lignes quotidiennes à l'exécutif : ce qui est livré, ce qui a été refusé, ce qui arrive.

Ce qui doit passer quand même

• Patches de sécurité avec CVE ou advisory Salesforce.
• Bug fixes qui bloquent le métier (login cassé, devis impossible).
• Modifs légales ou conformité avec échéance (nouveau champ de consentement RGPD).
• Corrections de données qui empirent si retardées.

Durée du freeze par type de lancement

Type de lancement	Pré-freeze	Post-freeze
Nouvelle org Salesforce / greenfield	14 jours	7 jours
Nouveau cloud majeur (Service, Marketing, Data Cloud)	10 jours	5 jours
Refonte de processus majeur (CPQ, forecasting)	7 jours	3 jours
Nouvelle intégration (ERP, marketing automation)	5 jours	3 jours
Release majeure Salesforce (Spring/Summer/Winter)	3 jours	2 jours

Ce que le freeze permet en post-launch

Le secret bien gardé d'un bon freeze : il transforme le week-end de launch en observation, pas en pompiers. Rien n'ayant bougé pendant 2 semaines, tout incident est traçable à la release elle-même, pas à « le marketing a poussé un Flow hier ». La cause racine devient chirurgicale, pas archéologique.

Notes régionales

• Europe : tenir compte des jours fériés (France en août, Allemagne en décembre). Voir France, Allemagne, Belgique, Luxembourg, Suisse.
• États-Unis & Canada : fin de trimestre et Black Friday créent leurs propres freezes de fait. Synchronisez avec les sales ops avant de verrouiller. Voir États-Unis, Canada.

Questions fréquentes

Durée d'un release freeze Salesforce ?

7 à 14 jours avant, 3 à 7 jours après. Plus long : la demande refoulée explose à la sortie du freeze.

Quels outils pour l'appliquer ?

Gearset, Copado, Salto ou Salesforce DevOps Center supportent tous le verrouillage de déploiement.

Freeze de toute l'org ou seulement des clouds lancés ?

Toute l'org est plus sûr. Freeze par cloud marche si vous savez isoler les changements.

Qui décide des exceptions ?

Un change-board de trois (delivery + métier + IT sécu), majorité. Jamais un décideur seul sous pression.

Obtenez un modèle de politique de freeze

Notre playbook de lancement Salesforce inclut une politique de freeze défendable, un formulaire d'exception et une charte de change-board. Réservez un appel de 30 minutes pour l'adapter à votre prochain lancement.