Préparez votre org Salesforce pour la Release Spring ’26 : guide complet pour marketeurs et admins

La Release Spring ’26 n’est pas “juste” une vague de nouveautés. C’est aussi une période où Salesforce applique des changements (Release Updates) susceptibles de modifier des comportements existants. Si vous attendez le week-end de mise en production pour réagir, vous prenez le risque de découvrir des régressions en plein usage, ou pire, en plein cycle de campagne.

L’objectif de ce guide est de vous donner une méthode simple et robuste pour préparer votre org, sécuriser vos intégrations, anticiper les mises à jour imposées, et organiser une communication claire côté métiers (marketing, sales ops, support).

Calendrier de la Salesforce release Spring ’26

La préparation commence par le timing, parce que vos tests doivent coller aux fenêtres Salesforce.

Salesforce met en avant une étape clé : le Sandbox Preview, qui démarre le 9 janvier 2026. C’est votre meilleur terrain de test, car vous pouvez valider les impacts sur vos automatisations et vos personnalisations, sans toucher la production.

Ensuite, les déploiements production Spring ’26 se font sur plusieurs week-ends. Salesforce Admin annonce trois fenêtres : 16 janvier, 13 février et 20 février 2026 (selon votre instance). Pour connaître votre date, la référence fiable reste le Maintenance Calendar sur Salesforce Trust/Status.

Ce qui change avec la mise à jour Salesforce Spring ’26 

Le point le plus important (et trop souvent sous-estimé) : certaines évolutions prennent la forme de mises à jour de version obligatoires et peuvent être appliquées automatiquement lors du déploiement. Sans préparation en amont, certains processus existants peuvent ne plus fonctionner correctement, car la release introduit des changements de comportement appliqués automatiquement.

Concrètement, votre préparation doit couvrir trois zones à risque :

1. les intégrations (API, middleware, ETL, connecteurs),
2. les automatisations (Flow, validation rules, Apex, etc.),
3. les applications AppExchange

Étape 1 : construire un plan de test qui reflète la réalité 

L’objectif n’est pas de vérifier que “Salesforce fonctionne”. L’objectif est de s’assurer que vos parcours métier essentiels continuent de fonctionner après la release.

Côté admin, commencez par lister 6 à 10 scénarios critiques (ceux qui, s’ils cassent, bloquent l’activité). Par exemple :

• Lead → conversion : création, qualification, conversion en compte/contact/opportunité.
• Opportunité : création, mise à jour des étapes, automatisations associées (tâches, alertes, calculs).
• Routage et affectation : flows d’assignation, règles de partage, files, SLA.
• Marketing & collecte de leads : formulaires, web-to-lead, synchronisation avec vos outils marketing (MCAE/Pardot, Marketing Cloud ou connecteurs).
• Traitements planifiés : imports/exports, jobs programmés, synchronisations nocturnes, traitements de données.

Ensuite, utilisez l’écran “Release Updates” dans Setup pendant la période de preview : c’est là que vous voyez les mises à jour à activer/tester, celles qui arriveront bientôt, et celles qui deviennent obligatoires. Vous testez ces mises à jour sur vos scénarios critiques, et vous notez précisément ce qui change.

Étape 2 : prioriser les Release Updates Spring ’26 qui ont un potentiel de “casse”

Mettre fin aux redirections “legacy host names” : impact direct sur les API

C’est un changement typiquement invisible… jusqu’au jour où une intégration tombe.

Salesforce a une Release Update qui vise à mettre à jour les références aux anciens host names (legacy). Le principe est simple : vous ne devez plus dépendre de redirections historiques ; l’idée est d’utiliser des URLs stables (souvent votre My Domain). Salesforce indique que vous pouvez activer/désactiver la redirection jusqu’à l’enforcement Spring ’26, après quoi vous ne pourrez plus revenir en arrière.

Si une intégration appelle encore une URL “d’instance”, vous devez la basculer vers votre My Domain URL et retester, y compris côté Apex/Visualforce si vous faites des callouts.

Checklist de vérification recommandée :

• recenser tous les endpoints Salesforce utilisés (middlewares, scripts, connecteurs, apps internes),
• vérifier qu’aucun n’utilise encore des URLs d’instance au lieu de My Domain,
• activer le test run en sandbox et exécuter vos scénarios critiques.

Connected Apps : restriction de création (à anticiper côté sécurité/intégrations)

Autre point à ne pas rater : Salesforce indique qu’avec Spring ’26, la création de nouvelles Connected Apps peut être bloquée, sauf si c’est activé par Salesforce Support. Si votre organisation a l’habitude de créer des Connected Apps “au fil de l’eau” (nouvel outil, POC, nouveau partenaire), il faut anticiper ce changement dans votre gouvernance et vos process.

Pour un admin, ça implique généralement :

• cadrer la demande en amont (catalogue, procédure, validations),
• éviter les créations “en urgence” à proximité de la fenêtre de release,
• documenter les alternatives si vous dépendez de la création fréquente de Connected Apps.

Fin de support : Data Detect Managed Package

Salesforce mentionne la fin de support du Data Detect Managed Package à partir de Spring ’26. Si vous l’avez (ou si un projet sécurité l’a déployé), c’est un sujet à mettre sur votre radar : dépendance, plan de remplacement et surtout coordination avec l’équipe sécurité/risque.

Étape 3 : organiser la préparation côté marketing (sans dépendre uniquement de l’admin)

La release, ce n’est pas un “sujet IT”. Le marketing a tout intérêt à structurer sa préparation, surtout si Salesforce alimente des campagnes, du lead management, du scoring, ou des workflows de qualification.

Ce que le marketing doit valider pendant le sandbox preview :

• que les objets et champs utilisés dans les campagnes (sources, UTMs, consent, segments) se comportent comme avant,
• que les automatisations de routage ne changent pas (affectation, SLA, relances),
• que les connecteurs externes (tracking, formulaires, enrichissement, BI) continuent d’ingérer/émettre correctement,
• que les permissions et accès n’ont pas d’effets de bord sur les équipes (cas courant lors de changements sécurité).

Et surtout : le marketing doit fournir à l’admin une liste courte de parcours à tester (les vrais), pour éviter les tests “au hasard”.

Étape 4 : préparer la mise en production comme un mini-projet (et pas comme un switch technique)

Testez en sandbox, déployez quand les utilisateurs sont hors ligne, prévoyez un plan de rollback, et restez après activation.

Dans les faits, un plan de release “propre” ressemble à ça :

• une date interne de gel des changements (éviter de déployer des évolutions juste avant la release),
• un créneau de validation post-release (smoke tests le lundi matin, par exemple),
• une page interne “Release Spring ’26 : ce qui change / ce qu’on a vérifié / qui contacter”,
• une communication brève aux utilisateurs (ce qu’ils peuvent remarquer, quoi faire si anomalie).

Pour vous aider à structurer cette préparation, Salesforce centralise aussi des ressources “Be Release Ready” dédiées à Spring ’26, avec des renvois vers release notes, sandbox preview, et communauté Release Readiness.

La meilleure stratégie Spring ’26, c’est d’être prêt avant le week-end de votre instance

Tout ce qui est critique doit être validé en sandbox preview (à partir du 9 janvier 2026), et tout ce qui touche aux intégrations doit être revu avec une attention particulière, notamment sur les sujets d’URLs/domaine et de gouvernance des Connected Apps.