Mises à jour de version Salesforce : que faire avant Spring '27

Winter '27 est désormais disponible sur les orgs de production, et avec lui un nouveau lot de mises à jour de version Salesforce. Certaines ont été activées automatiquement lors de la montée en version, d'autres ont des dates fixes au 30 novembre et au 1er décembre, et une liste plus longue arrivera avec Spring '27 et Summer '27. Les mises à jour de version ne sont pas optionnelles : chacune est appliquée à sa date, que votre équipe l'ait testée ou non. Ce guide classe la liste actuelle par échéance, explique qui est concerné et propose un plan en cinq étapes que votre administrateur peut dérouler cette semaine.

Mises à jour de version Salesforce : de quoi parle-t-on et pourquoi les dates comptent

Les mises à jour de version sont des modifications apportées par Salesforce à la sécurité, aux performances et au comportement de la plateforme, qui pourraient casser quelque chose si elles arrivaient sans prévenir. Elles apparaissent dans la Configuration (Setup) sous Mises à jour de version avant d'être appliquées, afin que les administrateurs puissent lire ce qui change, tester et activer en avance. Le module Trailhead sur les habitudes de gestion de produit des administrateurs décrit comment la page les regroupe : Action requise, Bientôt due, Échue et Archivée. Ouvrir une mise à jour affiche ses détails, et le bouton Premiers pas vous guide pas à pas dans les étapes de test.

La liste officielle des mises à jour de version dans les notes de version Winter '27 est la référence à garder en favori. Elle évolue au fil de l'année : des dates sont déplacées, certaines mises à jour sont annulées ou remplacées. Comparez-la toujours avec la page Mises à jour de version de votre propre org, qui n'affiche que les mises à jour concernant les fonctionnalités que vous utilisez.

Déjà appliquées avec Winter '27 : ce qu'il faut vérifier maintenant

Ces mises à jour ont été appliquées lors de la montée en version Winter '27. Si personne ne les a testées, vérifiez dès maintenant que rien n'a changé pour vos utilisateurs.

Activation du filtrage des profils. Selon la note de version (en anglais), le filtrage des profils est désormais activé par défaut : un utilisateur ne voit que le nom de son propre profil, sauf s'il dispose de l'autorisation Afficher tous les profils (View All Profiles). La page d'aide sur le filtrage des profils (en anglais) liste les autres autorisations qui permettent toujours de voir tous les profils, notamment Personnaliser l'application, Gérer les utilisateurs, Gérer les profils et les ensembles d'autorisations, et Gérer les utilisateurs externes. Deux conséquences passent facilement inaperçues :

• Tout rapport, vue de liste, écran ou composant personnalisé qui affiche le nom de profil d'un autre utilisateur à un utilisateur standard ne l'affichera plus.
• Les utilisateurs sans l'autorisation Afficher tous les profils ne peuvent plus créer ni modifier de flux de connexion (login flows).

Les administrateurs disposent en général de l'une de ces autorisations : tester avec votre propre compte ne prouve donc rien. Connectez-vous en tant qu'utilisateur commercial ou service client standard et contrôlez les pages, rapports et automatisations qui mentionnent les profils.

Attribution de l'autorisation Use Any API Auth pour login() SOAP. Les intégrations qui se connectent encore avec login() SOAP ont désormais besoin de cette autorisation. Nous avons détaillé ce changement, et les échéances OAuth qui suivent, dans notre guide sur les échéances d'authentification des intégrations Salesforce.

Améliorations de l'accessibilité. Trois mises à jour modifient le style des cartes, menus, panneaux, en-têtes de page, fenêtres modales et autres composants lorsque les pages sont affichées avec un zoom navigateur de 200 % ou plus. Demandez aux utilisateurs qui travaillent avec un zoom élevé de signaler tout élément tronqué.

Avant la fin de 2026 : 30 novembre et 1er décembre

Deux dates fixes arrivent avant les fêtes.

30 novembre 2026 : restriction du flux d'appareil OAuth 2.0 aux applications clientes externes locales. Le flux d'appareil (device flow) sert aux outils qui se connectent depuis des appareils à saisie limitée. À partir du 30 novembre, Salesforce le réserve aux applications clientes externes locales avec une URL de rappel localhost. Les applications connectées qui utilisent ce flux doivent être migrées vers des applications clientes externes pour continuer à fonctionner.

1er décembre 2026 : gestion de votre exception de vérification des e-mails. Par le passé, certaines orgs ont demandé au support Salesforce de désactiver la vérification des adresses e-mail pour leurs domaines. Le 1er décembre, Salesforce supprime ces listes d'autorisation gérées par le support. L'ancienne mise à jour « Adopt Authorized Email Domains » a été annulée et remplacée par celle-ci. Pour conserver votre exception, configurez-la vous-même, comme l'explique la page d'aide sur le contournement de la vérification des adresses e-mail pour les domaines vérifiés (en anglais) :

1. Dans la Configuration, ouvrez Domaines d'e-mail autorisés (Authorized Email Domains) et vérifiez votre domaine (l'autorisation Administration des e-mails est nécessaire).
2. Cliquez sur Modifier à côté du domaine vérifié.
3. Réglez l'option Require Address Verification to Send Email sur For Updated Addresses Only ou Never. La valeur par défaut est Always.
4. Enregistrez, puis testez un envoi depuis un utilisateur et depuis une adresse à l'échelle de l'organisation sur ce domaine.

Choisir Never réserve les modifications d'adresse e-mail aux utilisateurs disposant de Gérer les utilisateurs ou Modifier toutes les données : n'autorisez donc que des domaines entièrement contrôlés par votre entreprise.

Spring '27 et Summer '27 : planifier les migrations importantes

Le groupe suivant demande un vrai temps de projet, pas une activation de dix minutes.

• 20 février 2027 : retrait des flux OAuth user-agent et hybrid user-agent. Les intégrations doivent passer au flux web server ou hybrid web server avec PKCE. Le flux OAuth username-password des applications connectées est retiré le même jour.
• Spring '27 : retrait de Salesforce to Salesforce. Salesforce recommande Partner Cloud, Data Cloud One, MuleSoft Anypoint ou MuleSoft for Flow comme solutions de remplacement. Si vous partagez des pistes ou des opportunités avec des partenaires de cette façon, lancez la conception dès maintenant. Notre équipe migration CRM peut vous aider à cartographier ce qui doit migrer et où.
• Spring '27 : mise à jour des URL instanciées dans le trafic d'API. Le trafic d'API qui utilise une URL instanciée incorrecte ne sera plus pris en charge. Chaque intégration doit appeler l'URL de connexion Mon domaine (My Domain) de votre org. Cette mise à jour a déjà été reportée plusieurs fois : ne comptez pas sur un nouveau délai.
• Spring '27 : masquage des champs d'informations personnelles pour les utilisateurs invités. Une nouvelle option, Independent Guest Field Masking, et un ensemble de champs Guest_PersonalInfo_EPIM permettent de masquer des champs personnels aux utilisateurs invités sans changer ce que voient les utilisateurs du portail. Les orgs avec des sites publics ou un accès invité Experience Cloud doivent l'examiner.
• Spring '27 : autorisation View Setup Audit Trail. L'accès au journal d'audit de configuration (Setup Audit Trail) obtient sa propre autorisation. Les accès existants sont conservés, mais les nouveaux administrateurs et auditeurs devront la recevoir.
• Summer '27 : les applications connectées doivent être migrées vers des applications clientes externes, et login() de l'API SOAP dans les versions 31.0 à 64.0 est retiré.

Qui est concerné

• Administrateurs : pilotent la revue dans la Configuration, les tests de connexion en tant qu'utilisateurs standard et les réglages des domaines e-mail.
• Équipes intégration et DSI : gèrent le flux d'appareil, les retraits de flux OAuth, les URL instanciées et le passage aux applications clientes externes.
• Responsables commerciaux et partenaires : dépendent de Salesforce to Salesforce ou du partage de données avec les partenaires et doivent valider la solution de remplacement.
• Équipes marketing et opérations : envoient des e-mails depuis Salesforce et seront les premières à le remarquer si la vérification de domaine n'est pas en place le 1er décembre.
• Responsables sécurité et conformité : décident qui garde Afficher tous les profils et quels champs les utilisateurs invités peuvent voir.

Que faire maintenant : un plan en cinq étapes

1. Ouvrez Mises à jour de version dans la Configuration dès aujourd'hui. Exportez ou notez chaque mise à jour en Action requise, Bientôt due et Échue, avec sa date et l'équipe responsable.
2. Vérifiez les effets de Winter '27. Connectez-vous en tant qu'utilisateur standard, ouvrez les rapports, pages et flows qui utilisent les noms de profil, et décidez qui a réellement besoin d'Afficher tous les profils. Préférez un ensemble d'autorisations à une modification des profils.
3. Sécurisez les dates de décembre. Vérifiez avec la DSI si un outil utilise le flux d'appareil OAuth, et configurez vos domaines d'e-mail autorisés avant le 1er décembre.
4. Testez les mises à jour de Spring '27 dans une sandbox. Quand une mise à jour propose une exécution de test, activez-la d'abord dans une sandbox et consignez le résultat.
5. Lancez les deux projets. Planifiez la migration vers les applications clientes externes et, si vous l'utilisez, le remplacement de Salesforce to Salesforce, avec un responsable et une date cible avant chaque échéance.

Avant et après, en bref :

• Avant : des mises à jour de version découvertes la semaine de leur application, des réglages modifiés directement en production, et une intégration qui s'arrête un lundi matin.
• Après : une liste unique avec responsables et dates, des tests en sandbox, et des changements activés selon votre calendrier plutôt que celui de Salesforce.

Ces vérifications s'intègrent aussi naturellement dans une revue de sécurité plus large. Notre guide pas à pas pour vérifier si votre org Salesforce a été attaquée couvre les accès et les applications connectées, et notre article sur la fin de Salesforce for Outlook ajoute une date de plus à votre calendrier.

Conclusion

Les mises à jour de version Salesforce récompensent les équipes qui les lisent tôt. Winter '27 a déjà imposé le filtrage des profils, le 30 novembre et le 1er décembre modifient le flux d'appareil et la vérification des e-mails, et Spring '27 retire Salesforce to Salesforce ainsi que plusieurs flux OAuth. Une revue rapide dans la Configuration, des tests de connexion en tant qu'utilisateurs standard et deux projets bien cadrés suffisent pour garder une longueur d'avance. Si vous souhaitez une revue structurée de votre org avant Spring '27, nos consultants Salesforce Sales Cloud peuvent auditer vos mises à jour de version, vos intégrations et vos autorisations avec votre équipe.