Salesforce® Summer ’25 : les actions à engager pour sécuriser votre environnement Salesforce

La mise à jour Salesforce® Summer 25 arrive bientôt (déploiement prévu entre mai et juin 2025) et apporte son lot d’évolutions techniques, d’améliorations UX et de nouvelles pratiques à intégrer. Entre modernisation des sites Experience Cloud, migration vers Lightning Knowledge, retrait des anciennes API ou encore renforcement des règles de sécurité CSP, cette nouvelle release requiert une attention particulière.

Dans cet article, on vous propose un tour d’horizon clair des nouveautés à ne pas manquer, ainsi que les étapes concrètes à suivre pour anticiper les changements et sécuriser votre org avant la bascule.

Des dates de déploiement échelonnées : comment savoir quand votre org sera mis à jour ?

La mise à niveau Summer ’25 de Salesforce ne se fait pas partout en même temps. La date exacte de déploiement dépend de votre instance Salesforce. 

En 2025, les principales vagues de mise à jour auront lieu autour des weekends des 10 et 17 mai, puis des 7 et 14 juin 2025. 

Pour savoir précisément quand votre organisation passera à Summer ’25, vous pouvez consulter le site Salesforce Trust : recherchez votre instance (par son nom ou le domaine de votre org) puis ouvrez l’onglet “Maintenance”. Vous y trouverez la date planifiée pour la mise à jour Summer 25 de votre environnement, ce qui vous permettra d’anticiper et d’organiser les actions préalables en conséquence.

Experience Cloud : une expérience d’enregistrement modernisée pour les sites Aura

La mise à jour Summer ’25 apporte une apparence modernisée des formulaires et pages d’enregistrement sur les sites Aura d’Experience Cloud (le portail Salesforce Experience Cloud, anciennement appelé Lightning Community). 

Concrètement, l’aspect des composants standard tels que Create Record Form, Record Banner et Record Detail va être rafraîchi. Cette évolution améliore l’expérience utilisateur, mais peut impacter vos personnalisations front-end existantes. 

Il est recommandé de tester tous les composants personnalisés liés aux enregistrements avant que Salesforce n’applique automatiquement ce changement.

En sandbox :

• Allez dans Setup → Digital Experiences → All Sites et identifiez les sites dont le Framework est “Aura” (remarque : si vous ne voyez que “Salesforce CMS” et “Settings” sous Digital Experiences, cela signifie que Experience Cloud n’est pas activé dans votre org).
• Parcourez les pages de ces sites Aura pour noter l’apparence actuelle des formulaires d’enregistrement, bannières et détails d’enregistrement (n’hésitez pas à faire des captures d’écran pour garder une référence visuelle).
• Dans Setup → Digital Experiences → Settings, activez l’option “Use Lightning Web Components on your record pages in Aura sites”.
• Rechargez et vérifiez les pages concernées afin de vous assurer que les composants s’affichent correctement avec le nouveau style. Attention aux éventuelles surcharges CSS personnalisées : elles pourraient nécessiter des ajustements pour rester compatibles avec la nouvelle interface.
• Apportez en sandbox les modifications nécessaires (CSS, composants, mise en page) pour que le rendu des pages soit conforme à l’existant avec le nouveau framework LWC.

En production :

• Une fois les changements validés en sandbox, activez à votre tour l’option “Use Lightning Web Components on your record pages in Aura sites” en production (de préférence en dehors des heures de forte activité).
• Appliquez dans l’org de production les mêmes ajustements effectués en sandbox afin de garantir un affichage cohérent des composants après la mise à jour Summer ’25.

Migration vers Lightning Knowledge : pourquoi et comment anticiper ce changement

La release Summer ’25 marque la fin du modèle de base de connaissances Classic Knowledge au profit du nouveau Lightning Knowledge. 

En effet, le modèle d’articles Classic ne sera plus disponible après Summer ’25. Il est donc indispensable d’utiliser l’outil Lightning Knowledge Migration Tool pour convertir vos articles au format Lightning Knowledge et bénéficier des nouvelles fonctionnalités. (À noter qu’il restera possible d’accéder à Lightning Knowledge depuis l’interface Salesforce Classic, mais avec certaines limitations.)

En sandbox :

• Privilégiez un sandbox Full Copy pour tester la migration (les autres types de sandbox sont utilisables mais présentent un risque accru d’altération des données, notamment avec une Partial Copy).
  
  
• Vérifiez dans les Knowledge Settings que l’option “Enable Lightning Knowledge” est bien activée.
  
  
• Exécutez l’outil Lightning Knowledge Migration Tool dans votre sandbox et analysez les résultats. Comme Lightning Knowledge repose sur une structure de données différente, certaines personnalisations (mises en page, automatisations, intégrations…) peuvent être impactées et devront être ajustées.
• Après la migration en sandbox, pensez à vérifier et adapter :
  • Les champs et actions affichés sur les page layouts des articles de connaissance.
  • L’assignation des mises en page aux différents types d’enregistrement (record types) et profils utilisateurs.
  • L’ajout des listes associées importantes (historique des approbations, fichiers, cas liés, ordres de travail, etc.) sur les nouvelles pages d’articles si ces éléments étaient utilisés.
  • Les permissions : dans Lightning Knowledge, les droits s’appliquent directement sur l’objet Knowledge (et non plus par type d’article comme auparavant). Assurez-vous que chaque profil/utilisateur dispose toujours des accès nécessaires pour lire, modifier ou publier les articles requis. Au besoin, mettez en place des règles de validation pour restreindre l’édition de certaines catégories d’articles sensibles.
  • L’association des types d’article (record types) aux profils et aux permission sets, afin de contrôler quels types d’articles chaque utilisateur peut créer.
  • Si vous exposez la base de connaissances dans une communauté Experience Cloud, vérifiez que les utilisateurs externes conservent bien les accès et fonctionnalités appropriés après la migration.
  • En cas de multiples Article Types en Classic Knowledge, contrôlez après migration des aspects comme le mapping des canaux de diffusion des articles, les listes de sélection dépendantes (dependent picklists), la sécurité des champs, les formules, les règles de validation, les automatisations (Flows, processus d’approbation) ainsi que tout composant personnalisé (pages Visualforce, etc.).

En production :

• Confirmez que l’outil Lightning Knowledge Migration Tool est bien activé dans votre org de production (sinon, demandez son activation auprès du support Salesforce en amont).
• Répliquez en production les ajustements de configuration effectués en sandbox suite à la migration test (mises en page, droits, composants, etc.).
• Lancez le Lightning Knowledge Migration Tool en production, puis réalisez un cycle de tests complet pour vérifier que toutes les fonctionnalités de la base de connaissances fonctionnent correctement. Assurez-vous que les utilisateurs peuvent continuer à créer, modifier, rechercher et publier des articles comme attendu après la mise à jour.

Fin des API Salesforce obsolètes : suppression des versions 21.0 à 30.0

Salesforce profite de Summer ’25 pour retirer du service ses anciennes versions d’API (de la 21.0 à la 30.0). Concrètement, si certains de vos outils ou intégrations appellent les API Salesforce (SOAP, REST ou Bulk) en version 21.0 à 30.0, ces appels cesseront de fonctionner une fois la mise à jour déployée. 

Pas d’inquiétude pour vos développements internes : cette mesure n’impacte pas les versions d’API utilisées en interne par vos classes Apex, triggers, pages Visualforce, Flow ou Process Builder. 

De même, les webservices Apex personnalisés et les composants de packages managés ne sont pas concernés. En revanche, il est possible que du code ou des configurations dans votre org Salesforce référencent encore d’anciens endpoints d’API externes — par exemple, une page Visualforce appelant une URL d’API obsolète. Il va donc falloir identifier et corriger ces cas avant la mise à jour.

En sandbox :

• Rendez-vous dans Setup → Event Log File Browser et sélectionnez l’événement “API Total Usage” sur une période étendue (plusieurs semaines idéalement).
• Téléchargez les fichiers CSV des journaux (Event Logs) et parcourez-les à la recherche de toute utilisation d’une version d’API inférieure à 31.0.
• Pour chaque appel repéré en version obsolète, identifiez l’origine grâce aux champs Connected App ID ou Connected App Name présents dans le log.
• Si l’ID de l’application connectée commence par “888”, il s’agit d’une application Salesforce interne. Dans ce cas, contactez le support Salesforce pour obtenir des détails sur cette application (afin de la mettre à jour ou la remplacer si nécessaire).
• Examinez également les autres colonnes du journal (log), par exemple ENTITY_NAME (objet Salesforce concerné par l’appel), API_RESOURCE (type de ressource utilisée) et USER_ID (utilisateur à l’origine de l’appel), afin de bien comprendre l’origine de chaque appel obsolète.
• Mettez à jour le code ou les intégrations identifiées pour qu’ils utilisent une version d’API plus récente (idéalement la dernière version disponible), puis testez vos modifications pour vous assurer que tout fonctionne avec la nouvelle version.
• Enfin, exécutez une nouvelle analyse des logs sur la sandbox pour vérifier qu’aucun appel n’utilise encore une version inférieure à 31.0.

En production :

• De la même façon, analysez les logs d’utilisation d’API en production pour détecter toute application ou script qui emploierait encore une version d’API désormais obsolète.
• Pour chaque cas identifié, faites évoluer l’appel ou l’intégration vers une version d’API supportée (en mettant à jour l’URL d’appel, les bibliothèques utilisées, etc.), puis effectuez les tests nécessaires afin de garantir qu’aucune régression fonctionnelle n’apparaît.
• Pour minimiser les risques, planifiez ces mises à jour d’API de manière progressive : par lots de fonctionnalités ou par application, avec des phases de validation intermédiaires, plutôt qu’une bascule totale en une fois.

Nouvelles directives CSP Salesforce : mettez à jour vos Trusted URLs

Salesforce renforce la sécurité avec de nouvelles règles de CSP (Content Security Policy) dans Summer ’25. Ce changement remplace l’ancienne mise à jour “Adopt Updated CSP Directive” annoncée précédemment, en introduisant un mécanisme de détection plus strict et un nouvel événement de surveillance des violations. 

En pratique, une fois cette mise à jour activée, Salesforce pourra bloquer l’affichage de tout contenu externe non autorisé dans votre org (par exemple, le chargement d’images depuis un site externe, l’affichage d’un contenu via iframe ou l’utilisation de polices personnalisées hébergées hors Salesforce). 

Il est donc crucial de passer en revue vos paramètres de sécurité CSP afin d’éviter toute interruption visuelle ou fonctionnelle due à ces blocages.

En sandbox :

• Dans Setup → Security → Trusted Sites (URLs de confiance), consultez la section Browser Policy Violations qui liste les URL externes récemment bloquées par la politique CSP de votre organisation.
• Filtrez cette liste par type de violation afin d’identifier toutes les ressources concernées : img-src (images), frame-src (contenus iframe) et font-src (polices externes).
• Analysez l’ensemble des URL listées (idéalement en compilant les rapports de violation de plusieurs environnements sandbox) afin d’obtenir un inventaire complet des ressources externes utilisées par votre organisation Salesforce.
• Pour chaque domaine ou URL nécessaire au bon fonctionnement de vos utilisateurs, ajoutez-le aux Trusted Sites en lui accordant les autorisations CSP adéquates. Par exemple, si vos pages affichent un logo depuis un site tiers, autorisez ce domaine en tant que source d’images (img-src).
• Activez ensuite la mise à jour CSP en mode test sur la sandbox et vérifiez que toutes vos pages fonctionnent normalement : les images externes s’affichent, les iframes se chargent, les polices personnalisées sont bien appliquées, etc. Si quelque chose est bloqué, ajustez la liste des Trusted URLs en conséquence puis retestez jusqu’à ce qu’aucune ressource légitime ne soit filtrée.

En production :

• Reproduisez dans votre org de production les entrées Trusted Sites ajoutées ou modifiées en sandbox, afin que la liste des URL de confiance soit à jour avant l’activation de la nouvelle CSP.
• Avant d’activer la nouvelle politique CSP, nettoyez l’historique des violations (cela supprimera les anciennes entrées de blocage enregistrées). Ainsi, si une ressource venait encore à être bloquée par oubli, elle réapparaîtra dans la liste des violations comme une nouvelle entrée à investiguer.
• Lancez un test d’activation de la mise à jour CSP en production et contrôlez que les images, frames et polices externes continuent de s’afficher correctement pour vos utilisateurs (comme cela a été validé en sandbox).
• Après le déploiement, surveillez régulièrement le rapport de Browser Policy Violations pour détecter rapidement toute nouvelle URL externe qui serait bloquée, et ajoutez-la aux Trusted Sites si nécessaire afin de maintenir une expérience utilisateur fluide.

Bonus : autres nouveautés pratiques de Salesforce Summer ’25

La mise à jour Summer ’25 apporte également de nombreuses autres améliorations pratiques. En bref :

• Renommage d’un groupe de partage standard : le groupe « Roles and Subordinates » s’appelle désormais « Roles and Internal Subordinates ». (Ce changement a déjà été appliqué automatiquement avec Spring ’25 pour la plupart des orgs ; s’il n’a pas abouti dans votre org, Salesforce le réexécutera lors de Summer ’25.)
• Recherche de vues de liste : vous pouvez enfin rechercher une vue de liste par son nom grâce à une barre de recherche intégrée dans la liste des vues (pratique pour retrouver rapidement une vue spécifique parmi beaucoup d’autres).

• Processus d’approbation via Flow : Salesforce prévoit de retirer progressivement l’ancien système de Processus d’approbation. Il est recommandé d’utiliser désormais les Flux d’approbation (Flow), plus flexibles et capables de gérer des scénarios plus complexes.

• Amélioration de l’envoi d’e-mails : l’action standard « Envoyer un e-mail » permet maintenant de rédiger et de mettre en forme le contenu de votre email directement dans l’interface, sans nécessiter la création d’un modèle de texte séparé. Un gain de temps et de simplicité pour les utilisateurs !

• Actualisation ciblée des tableaux de bord : les utilisateurs peuvent choisir d’actualiser seulement certains composants d’un tableau de bord (plutôt que de recharger le dashboard en entier). Cela offre plus de contrôle et de rapidité dans l’analyse des données en temps réel.
• Agentforce (l’agent virtuel natif de Salesforce) gagne en fonctionnalités : vous pouvez désormais le solliciter pour réaliser des tâches d’administration (création d’objets, configuration d’applications connectées, etc.) par simple commande. Il devient aussi possible d’intégrer des Lightning Web Components (LWC) dans l’interface d’Agentforce afin de personnaliser les interactions avec l’agent virtuel à l’aide de formulaires ou écrans sur mesure. Enfin, les agents humains profitent de la nouveauté Agent Connections, qui leur permet d’utiliser un formatage de contenu enrichi dans leurs réponses, offrant des interactions client plus personnalisées et cohérentes sur plusieurs canaux.

• Prompt Builder s’enrichit : cet outil d’IA de Salesforce supporte maintenant les objets externes. Vous pouvez ainsi intégrer des données issues d’objets externes directement dans vos prompts (requêtes IA) sans avoir besoin de les importer ni de les stocker au préalable dans votre org.

En suivant ces conseils et en anticipant les changements, vous aborderez sereinement la mise à jour Salesforce Summer ’25. Il ne vous reste plus qu’à planifier ces actions en amont et à profiter pleinement des nouveautés 2025 que Salesforce a préparées pour vous !

En tant que partenaire Salesforce Crest, nous mettons à votre service une expertise reconnue, des équipes certifiées et une approche sur mesure, adaptée à vos enjeux métier. Contactez-nous !