À l’approche d’un go-live Salesforce, le risque n’est pas seulement un défaut technique. C’est aussi la succession de demandes raisonnables prises séparément : une règle à ajuster, un profil à ouvrir, un champ à ajouter, un rapport à corriger. À quelques jours de la bascule, leur accumulation modifie les tests, les droits, les données ou les automatisations plus vite que l’équipe ne peut les vérifier.
Un release freeze utile ne dit pas « plus rien ne bouge ». Il rend visible une décision : quels changements restent admissibles, qui les arbitre et comment l’équipe prouve que le périmètre de départ tient toujours. C’est une discipline de décision, pas un gel administratif.
Pourquoi le freeze arrive souvent trop tard
Le freeze est fréquemment annoncé quand la pression est déjà forte. Le métier découvre un cas d’usage absent, l’équipe projet veut éviter une frustration légitime et personne ne souhaite être celui qui refuse une amélioration. Sans règle partagée, chaque demande devient une exception. Or une exception qui touche une automatisation, un mapping, un jeu de droits ou un chargement de données peut faire rejouer davantage que la seule fonctionnalité demandée.
Le bon moment pour fixer la règle est avant la dernière semaine de tests. L’équipe peut alors expliquer ce qui est protégé : un périmètre testé, une liste de rôles validée, des données préparées et un plan de retour arrière compréhensible. Le débat ne porte plus sur la bonne volonté, mais sur l’impact vérifiable de la demande.
Ce que le release freeze protège réellement
Un freeze ne protège pas une date sur un planning. Il protège quatre éléments qui rendent un go-live lisible :
- Le périmètre testé. Toute évolution qui modifie le comportement d’un utilisateur remet en question les scénarios déjà validés.
- Les accès. Les permissions, profils et règles de partage méritent une attention particulière : une modification locale peut empêcher une opération métier essentielle.
- Les données et intégrations. Un mapping, une valeur de référence ou une synchronisation changés tardivement peuvent produire une anomalie difficile à diagnostiquer après la bascule.
- La capacité de décision. Quand les critères d’exception sont connus, un sponsor sait ce qu’il accepte comme risque au lieu de choisir dans l’urgence.
Le freeze ne remplace donc ni les tests ni la préparation opérationnelle. Il leur donne une limite claire.
Les changements à sortir du lot final
Avant le freeze, constituez une liste courte des changements qui vont au backlog sauf exception formalisée :
- une nouvelle fonctionnalité demandée par confort ;
- une évolution de processus qui n’est pas nécessaire au démarrage ;
- une modification d’automatisation sans scénario de régression documenté ;
- un ajustement de données qui ne répond pas à une erreur bloquante ;
- une amélioration de reporting qui peut être fournie après stabilisation.
Cette liste évite de classer tous les sujets dans « urgent ». Elle ne dit pas que ces demandes sont mauvaises ; elle les remet dans une séquence où elles pourront être estimées, testées et assumées.
Définir les exceptions sans ouvrir une porte trop large
Une exception est possible lorsque le risque de ne rien changer est supérieur au risque de changer. Pour éviter une appréciation subjective, utilisez quatre questions.
| Question | Décision attendue |
|---|---|
| Quel processus métier est empêché au démarrage ? | Distinguer le blocage réel de l’amélioration souhaitable. |
| Quel périmètre technique ou de données est touché ? | Identifier les tests à rejouer et les dépendances. |
| Qui accepte le risque résiduel ? | Nommer un décideur, pas seulement un exécutant. |
| Comment vérifie-t-on l’exception avant le go-live ? | Définir une preuve : scénario, contrôle d’accès, rapprochement ou test d’intégration. |
Si l’une de ces réponses manque, la décision la plus prudente est de reporter. Cette méthode ne ralentit pas le métier : elle évite de découvrir après coup que la demande a déplacé un risque vers les équipes opérationnelles.
Attribution des rôles pendant le freeze
- Le demandeur métier décrit le problème observable et son impact.
- Le référent fonctionnel vérifie si le besoin appartient au démarrage ou au backlog.
- Le référent technique explicite les dépendances et les tests nécessaires, sans décider seul de la priorité métier.
- Le décideur désigné accepte ou refuse l’exception et la trace.
- Le responsable de mise en production s’assure que les exceptions et contrôles associés sont visibles.
Un tableau de décisions suffit : demande, impact, dépendances, décision, responsable, preuve de vérification. Il est plus utile qu’une longue liste de tâches dont personne ne sait laquelle a réellement changé le périmètre.
Relier freeze, go/no-go et hypercare
Le freeze prépare la décision de go/no-go : il évite que le comité découvre un périmètre instable au dernier moment. Il prépare aussi l’hypercare, car les exceptions acceptées deviennent des zones à surveiller après la bascule. Enfin, il rend le rollback plus réaliste : si l’équipe sait quelles décisions ont modifié le lot final, elle comprend mieux ce qui doit être contrôlé avant un éventuel retour arrière.
Checklist de décision avant le go-live
- Date et périmètre couverts.
- Changements interdits par défaut.
- Décideurs d’exception et remplaçant.
- Tests minimaux à rejouer.
- Canal unique de traçabilité.
- Éléments à surveiller en hypercare.
- Moment prévu pour reprendre le backlog reporté.
Quand demander un second avis
Un go-live proche, des changements encore ouverts et des responsabilités floues sont trois signaux qui justifient de prendre du recul. Un regard externe ne remplace pas l’équipe projet ; il aide à remettre à plat les dépendances, les critères de décision et les contrôles réellement nécessaires.
Pour préparer cette revue, consultez notre page second avis Salesforce et nos repères sur Salesforce. Selon le contexte, le travail peut aussi s’articuler avec un go/no-go, un plan de rollback et une période d’hypercare.
