Trois fois par an, Salesforce déploie une nouvelle version de sa plateforme : Winter, Spring et Summer. Ces montées de version sont automatiques et non optionnelles. Pour une ETI qui a construit des automatisations, des intégrations et des développements spécifiques, chaque release peut introduire des changements de comportement, des dépréciations ou des régressions. L'enjeu n'est pas d'éviter ces montées — c'est impossible — mais de les industrialiser pour transformer un risque récurrent en routine maîtrisée.
Comprendre le rythme des releases Salesforce
Salesforce fonctionne sur un modèle de trois versions majeures par an, nommées selon les saisons : Winter (déploiement à l'automne), Spring (déploiement en hiver) et Summer (déploiement au printemps). Chaque version apporte de nouvelles fonctionnalités, des améliorations de performance, mais aussi des changements qui peuvent affecter l'existant.
Le déploiement suit un calendrier public en trois vagues. Les org de préproduction (sandbox) sont mises à jour en premier, ce qui laisse une fenêtre de plusieurs semaines pour tester avant que la production ne soit à son tour migrée. Salesforce publie systématiquement les Release Notes détaillées et un calendrier de maintenance consultable dans le Trust Status (status.salesforce.com).
Point essentiel : ces montées de version sont poussées automatiquement. Vous ne choisissez pas de les refuser. Vous ne choisissez que le degré de préparation avec lequel vous les abordez.
Pourquoi une release peut faire mal
Une org Salesforce vierge subit peu d'impact lors d'une montée de version. Le risque grandit avec le niveau de personnalisation. Plus votre plateforme comporte de développements Apex, de flows, d'intégrations via API et de composants Lightning, plus la surface d'exposition aux changements augmente.
Les types de changements à surveiller
- Les dépréciations : une API, une méthode ou une fonctionnalité annoncée en fin de vie. Salesforce communique en général plusieurs versions à l'avance.
- Les changements de comportement : une action qui produit un résultat différent après la mise à jour, sans erreur explicite.
- Les évolutions de versions d'API : vos intégrations peuvent appeler une version d'API donnée ; il faut vérifier sa prise en charge dans le temps.
- Les fonctionnalités activées par défaut : certaines nouveautés sont actives dès la release, d'autres nécessitent une activation manuelle.
Le piège le plus fréquent n'est pas la panne visible, mais la régression silencieuse : un flow qui cesse de déclencher une action, un champ calculé qui change de valeur, une intégration qui renvoie des données légèrement différentes. Sans tests de non-régression, ces écarts ne sont détectés qu'en production, souvent par les utilisateurs métier.
Industrialiser : un processus en cinq temps
Industrialiser une montée de version signifie disposer d'un enchaînement d'étapes répétable, documenté et outillé, que l'on rejoue à l'identique trois fois par an. L'objectif est de réduire le travail exceptionnel à chaque release.
1. Veille et lecture ciblée des Release Notes
Dès la publication des Release Notes de la prochaine version, une lecture ciblée s'impose. Il ne s'agit pas de tout lire, mais de filtrer selon les fonctionnalités et clouds que vous utilisez réellement (Sales Cloud, Service Cloud, Experience Cloud, etc.) et selon vos technologies d'intégration. Constituez une liste des changements pertinents pour votre org.
2. Prise en main sur sandbox Preview
Salesforce propose des sandbox « Preview » mises à jour avant la production. C'est votre environnement de vérité pour tester la version à venir. Assurez-vous de disposer d'au moins une sandbox alignée sur l'instance Preview et non sur l'instance non-Preview.
3. Tests de non-régression automatisés
C'est le cœur de l'industrialisation. Un socle de tests automatisés (tests Apex, jeux de tests fonctionnels sur les parcours critiques) rejoué à chaque release permet de détecter rapidement les écarts. La couverture doit prioriser les processus à fort impact métier : cycle de vente, création de cas, synchronisation avec l'ERP ou l'outil de facturation.
4. Validation métier des nouveautés
Certaines nouveautés méritent d'être activées, d'autres non. Une revue avec les référents métier permet de décider : quelles fonctionnalités adopter, lesquelles désactiver, lesquelles reporter. Cette étape évite que des changements de comportement par défaut ne perturbent les utilisateurs.
5. Communication et documentation
Une release qui modifie l'interface ou introduit une fonctionnalité doit être communiquée aux utilisateurs. Une note synthétique, un point en réunion d'équipe ou une mise à jour de la base de connaissances internes réduisent les tickets de support et soutiennent l'adoption.
Aller plus loin
Qui fait quoi : la question de la responsabilité
Dans une ETI, la gestion des releases se répartit souvent entre plusieurs acteurs : l'administrateur Salesforce interne, la DSI, et éventuellement un intégrateur ou une agence en charge de la TMA (tierce maintenance applicative). Le flou sur cette répartition est une source fréquente de problèmes.
Il est utile de formaliser, par écrit, qui assure la veille, qui exécute les tests, qui décide de l'activation des nouveautés et qui communique. Cette clarification prend tout son sens lors du cadrage d'un contrat de maintenance : la gestion des trois montées de version annuelles doit y figurer explicitement, avec un engagement de tests avant chaque passage en production.
Internaliser ou déléguer ?
Il n'existe pas de réponse unique. Une org peu personnalisée avec un administrateur formé peut gérer ses releases en interne. Une org complexe, avec de nombreuses intégrations et développements spécifiques, gagne souvent à s'appuyer sur un prestataire qui dispose d'un socle de tests automatisés et d'une expérience répétée de ces montées de version. Le critère de choix n'est pas la taille du prestataire, mais sa capacité démontrée à cadrer un processus de release répétable.
Attention aux contrats de maintenance qui ne mentionnent pas explicitement la gestion des releases. Si rien n'est écrit, chaque montée de version peut donner lieu à une facturation au forfait ou à un simple « rien n'a été testé ». Exigez que le processus soit décrit et que la non-régression fasse partie du périmètre.
Ce que l'industrialisation change concrètement
Un processus mature ne supprime pas le risque, mais le rend prévisible. Vous passez d'une posture réactive — découvrir les problèmes en production — à une posture anticipée : identifier les changements pertinents, les tester en amont, décider en connaissance de cause. Le temps consacré à chaque release diminue au fil des cycles, car le socle de tests et la documentation se capitalisent.
Pour une ETI, l'enjeu dépasse la technique : c'est la stabilité de l'outil sur lequel reposent les équipes commerciales et le service client. Une régression non détectée sur un parcours de vente ou de facturation a un coût opérationnel bien supérieur au coût des tests.
Points de repère pour cadrer votre démarche
- Suivez le calendrier officiel des releases et le Trust Status pour connaître les dates de déploiement de votre instance.
- Vérifiez que vous disposez d'une sandbox alignée sur l'instance Preview.
- Constituez et faites vivre un socle de tests de non-régression sur vos parcours critiques.
- Formalisez la répartition des rôles entre interne, DSI et prestataire.
- Décidez explicitement, à chaque release, des nouveautés à activer ou non.
Ces repères ne demandent pas un investissement démesuré au démarrage, mais une discipline régulière. L'industrialisation est avant tout une affaire de méthode répétée trois fois par an.