Releases Salesforce : préparer les changements utiles à votre équipe

Mis à jour le 15 octobre 2026.

Une nouvelle version Salesforce arrive. Le responsable CRM reçoit une sélection de nouveautés, les utilisateurs découvrent parfois une interface différente et l’équipe technique doit vérifier que les automatisations continuent de fonctionner. La difficulté est de transformer ces informations en décisions : que faut-il traiter maintenant, que peut-on essayer et que peut-on laisser de côté ?

Une préparation utile répond à ces trois questions sans lancer un chantier pour chaque annonce. Elle protège les activités qui comptent et permet d’adopter les améliorations qui répondent à un besoin réel. Voici une méthode pour organiser cette préparation, avec des contrôles métier, un tableau de suivi et une répartition claire des responsabilités.

Retrouver le calendrier de votre organisation

Salesforce publie trois grandes releases par an, nommées Spring, Summer et Winter. Le calendrier officiel de préparation Winter ’27 rappelle cette cadence et renvoie aux fenêtres de maintenance des instances. Le nom d’une release ne suffit donc pas à connaître la date de passage de votre environnement.

Consultez le calendrier de maintenance Salesforce Trust pour l’instance concernée. Notez séparément l’environnement de production et les environnements de test. En octobre 2026, la documentation courante porte sur Winter ’27 : l’année figurant dans le nom commercial n’est pas toujours celle de la date de déploiement.

Dans votre planning interne, ajoutez les échéances métier : clôture commerciale, événement, campagne ou traitement important. Cela permet de réserver les personnes capables de vérifier les parcours concernés. La préparation ne se résume pas à inscrire la date de mise à jour dans le calendrier de l’administrateur.

Les produits et services complémentaires peuvent avoir leur propre cadence. Vérifiez les informations de chaque produit utilisé, ainsi que celles des applications installées. N’étendez pas automatiquement le calendrier de la plateforme à tout votre système d’information.

Lire les notes de version avec un objectif précis

Les notes de version officielles Salesforce constituent le point de départ. Commencez par les produits réellement utilisés et les sujets dont dépend votre activité : accès, automatisations, interfaces, documents, applications métier ou portails. Une synthèse commerciale peut aider à repérer une idée ; elle ne remplace pas la notice de la fonctionnalité.

Pour chaque sujet retenu, relevez son périmètre, son mode d’activation et ses conditions d’utilisation. Le tableau officiel How and When Do Features Become Available? distingue notamment les fonctions disponibles directement pour les utilisateurs de celles qui demandent une intervention de l’administrateur ou de Salesforce.

L’expression « Generally Available » décrit un statut de disponibilité. Elle ne signifie pas à elle seule que la fonction est incluse dans votre contrat, ouverte à toutes les éditions ou déjà activée dans votre organisation. Vérifiez les licences, les permissions et les prérequis indiqués dans la documentation du produit. Si une décision d’achat en dépend, faites confirmer les conditions par Salesforce.

Une mention Beta ou Pilot mérite aussi une lecture précise. Les conditions d’accès, les limites et les modalités de support peuvent différer. Pour un usage critique, documentez ce qui permettrait d’adopter la fonction et ce qui imposerait de conserver le fonctionnement actuel.

Séparer les changements à préparer des nouveautés à essayer

Le même document de veille peut contenir une évolution visible par tous, une mise à jour à traiter avant une échéance et une nouvelle option intéressante. Ces sujets ne demandent pas la même décision.

La rubrique Release Updates, dans la configuration Salesforce, apporte des informations propres aux mises à jour à examiner. La documentation de cette rubrique précise les étapes, les échéances et les possibilités de test. Lorsqu’un essai est proposé, son activation modifie le comportement de l’environnement : ce n’est pas une simple consultation. Préparez-le dans un environnement adapté et lisez les conditions de la mise à jour concernée.

Une annonce de retrait doit être reliée au composant réellement utilisé. Relevez la notice exacte, la date, les fonctions touchées et la solution de remplacement. Un changement de marque ne démontre pas une migration technique obligatoire. De même, une annonce concernant une version d’API ne permet pas de conclure que tous les développements anciens doivent être réécrits.

Préparer un environnement de test représentatif

Une organisation de démonstration permet de découvrir une nouveauté. Elle ne montre pas nécessairement son comportement avec vos automatisations, vos permissions et vos interfaces. Pour examiner l’existant, il faut un environnement de test suffisamment représentatif du périmètre étudié.

Salesforce explique le principe de la sandbox preview dans Trailhead. Toutes les sandboxes ne passent pas sur la nouvelle release au même moment. Le calendrier de rafraîchissement et l’instance déterminent l’accès à cette préversion. Avant de rafraîchir une sandbox, vérifiez donc le guide de la release : l’opération peut modifier son positionnement dans la période de preview.

Préparez les comptes de test, les données nécessaires et les connexions autorisées. Une sandbox ne doit pas envoyer par erreur des messages à vos clients ou appeler un système de production comme s’il s’agissait d’un véritable traitement. Identifiez les dépendances externes et la manière de les tester sans perturber l’activité.

Si la sandbox ne reflète plus la configuration actuelle, inscrivez les écarts qui limitent les conclusions. Il vaut mieux savoir qu’une interface n’a pas été testée que déclarer toute l’organisation compatible après avoir uniquement ouvert quelques écrans.

Tester les parcours qui font fonctionner l’entreprise

La priorité est de vérifier ce que les équipes doivent pouvoir continuer à faire. Choisissez des parcours qui traversent plusieurs étapes : recevoir une demande, la qualifier, produire un document, obtenir une validation ou transmettre une information à un autre outil. Pour chacun, définissez un résultat observable.

Voici un exemple fictif pour une équipe commerciale. Un utilisateur prépare un devis, le soumet à validation puis génère le document destiné au client. Le contrôle ne s’arrête pas à l’affichage du bouton. Il vérifie les montants, le destinataire de la validation, l’état du dossier et le document produit. Un second scénario couvre le refus ou la correction du devis.

Complétez ces essais avec les droits utiles. Un administrateur peut réussir une action qui échoue pour le commercial ou pour un utilisateur du portail. Notre guide sur les profils et permission sets Salesforce explique cette distinction entre autorisations, licences et accès aux données.

Les tests techniques complètent cette recette. Ils ne remplacent pas la confirmation que le résultat convient à l’utilisateur. Conservez la date, l’environnement, le scénario et le résultat : ces éléments serviront si un comportement différent apparaît ensuite.

Tenir un tableau de décisions plutôt qu’une collection d’annonces

Un tableau partagé peut suffire pour piloter la préparation. Pour chaque ligne, conservez le lien officiel, le composant concerné, l’impact possible, l’action décidée, le responsable et l’échéance. Ajoutez le résultat du test et, si nécessaire, la personne qui doit arbitrer.

Utilisez des états explicites : à analyser, à tester, correction nécessaire, prêt pour la production ou sans action pour notre périmètre. La dernière catégorie est utile si sa raison est connue. Elle permet de distinguer un sujet examiné d’un sujet oublié.

Une nouveauté optionnelle doit rejoindre le backlog avec son intérêt métier, son coût d’adoption et ses dépendances. Une fonction disponible peut demander du paramétrage, une adaptation des processus ou un accompagnement des utilisateurs. Ces travaux méritent une estimation avant de décider de les engager.

Il n’existe pas de charge universelle de préparation valable pour toutes les organisations. Le temps nécessaire dépend des produits, des interfaces, des développements et du niveau de documentation. Définissez le périmètre des vérifications et les responsables avant d’associer un budget au travail.

Organiser le passage et les jours suivants

Avant le passage de l’instance, les personnes concernées doivent connaître les vérifications prévues et le point de contact en cas d’anomalie. Préparez une information courte pour les utilisateurs lorsque leur manière de travailler va changer : ce qui sera différent, à partir de quand et où obtenir de l’aide.

Après la mise à jour, rejouez les contrôles critiques et observez les traitements importants. Un écran qui s’ouvre ne démontre pas qu’un échange nocturne ou qu’un document généré fonctionne correctement. Si un problème apparaît, relevez le scénario, les utilisateurs concernés et le moment où il a été constaté. Notre guide pour qualifier un problème Salesforce aide à organiser ces premières informations.

Distinguez le passage de version réalisé par Salesforce et les changements de configuration que votre équipe décide de livrer. Vous ne devez pas promettre un retour libre de la plateforme à sa version précédente. Pour vos propres modifications, prévoyez les moyens de correction ou de retour adaptés, notamment lorsqu’elles touchent les données.

Une fois les contrôles terminés, classez les preuves et actualisez la liste des sujets ouverts. Le support et la maintenance Salesforce peuvent intégrer cette routine de veille, de qualification et de suivi. Le périmètre convenu doit préciser ce qui est inclus et ce qui nécessite une décision complémentaire.