Ce qui a changé dans la dernière version de Salesforce pour les équipes DevOps

En bref : La version actuellement en production, Summer '26 (API version 67.0), a remodelé les déploiements Salesforce : DevOps Center est désormais natif sans managed package, une nouvelle bêta Metadata Deployment résout automatiquement les dépendances de composants, et Apex s'exécute désormais en user mode par défaut. Winter '27 atteint la production entre le 4 septembre et le 9 octobre 2026 et retire le flux OAuth username-password, alors auditez l'authentification de vos intégrations avant cette date.

Si votre pipeline tourne encore sur des habitudes vieilles de deux versions, le sol a bougé sous vos pieds ces derniers mois. Voici ce qui a réellement changé, ce qui arrive, et ce qu'un release manager devrait faire cette semaine.

Quelle est la dernière version de Salesforce pour les équipes DevOps ?

Summer '26 est la version actuellement en production, déployée sur les instances entre le 15 mai et le 13 juin 2026 en API version 67.0. Winter '27 suit : ses notes de version paraissent le 19 août 2026, la préversion sandbox ouvre le 28 août, et les mises à niveau en production se déroulent en trois vagues les 4 septembre, 2 octobre et 9 octobre. Autrement dit, la version contre laquelle vous déployez aujourd'hui n'est pas celle du mois prochain.

Comment Summer '26 a-t-il changé les déploiements et DevOps Center ?

Le point marquant pour les équipes, c'est que DevOps Center est désormais natif. Plus de managed package à installer et à versionner, ce qui supprime toute une catégorie de friction de mise à niveau pour l'outil qui suit vos changements et les promeut à travers des étapes liées aux sandboxes.

Deux autres changements comptent pour quiconque déploie du metadata :

• Metadata Deployment (bêta) déplace les composants entre orgs depuis l'interface, avec un DX Inspector qui identifie et inclut automatiquement les dépendances liées qui cassaient historiquement les déploiements.
• Une orientation agentic. Salesforce a introduit un serveur DX MCP pour piloter DevOps Center depuis des IDE agentic et des outils en ligne de commande, pas seulement l'interface point-and-click.

Ce sont de vraies améliorations, mais natif et bêta ne signifient pas éprouvé à grande échelle. Les équipes qui gèrent des dizaines de branches parallèles, une config propre à chaque environnement et des versions chargées en profils ont toujours besoin de gouvernance, de résolution de conflits et de pistes d'audit qu'un outil first-party en bêta ne couvre pas encore pleinement. C'est précisément pour cela qu'existent des plateformes dédiées comme Copado, Gearset et Serpent, et si vous comparez l'outillage natif à un pipeline conçu pour cela, notre comparaison avec Copado montre où chacun se situe.

Quels changements Apex et API affectent les pipelines de release ?

L'API version 67.0 a livré des valeurs par défaut qui peuvent changer le comportement à l'exécution : leur place est dans vos tests de régression, pas dans une note de bas de page :

• User mode par défaut. Dans les classes enregistrées en API 67.0 ou version ultérieure, les méthodes SOQL, SOSL, DML et Database s'exécutent en user mode plutôt qu'en system mode, appliquant automatiquement les permissions d'objet et la sécurité au niveau des champs.
• Défaut de partage inversé. Également pour les classes enregistrées en 67.0 ou version ultérieure, une classe Apex sans mot-clé sharing explicite passe désormais par défaut à with sharing plutôt qu'à without sharing. Les classes existantes conservent leur comportement jusqu'à ce que votre pipeline relève leur version d'API.
• Syntaxe de sécurité supprimée. WITH SECURITY_ENFORCED ne compile plus en API 67.0. Tout déploiement qui la contient encore échoue au build, alors remplacez-la par WITH USER_MODE avant de relever la version.

Côté outillage, la Salesforce CLI masque désormais par défaut les access tokens et mots de passe des sorties de commande, et un serveur Metadata API MCP est entré en bêta. Plus loin, l'appel SOAP login() pour l'authentification username-password doit être retiré en Summer '27, une échéance à inscrire dès maintenant sur la feuille de route plutôt qu'à découvrir dans un déploiement raté.

Que doivent faire les équipes DevOps avant l'arrivée de Winter '27 ?

Le changement le plus perturbateur de Winter '27 n'est pas une fonctionnalité, c'est un retrait. Le flux OAuth 2.0 username-password disparaît, et les connected apps qui s'authentifient encore avec un nom d'utilisateur, un mot de passe et un security token cesseront de recevoir des access tokens à votre date de mise à niveau. La panne est silencieuse, donc les intégrations se dégradent sans erreur évidente.

Une version que vous n'avez pas testée est une version que vous déployez à l'aveugle. La préversion sandbox est l'endroit le moins cher pour découvrir ce qui casse.

Une checklist serrée avant la mise à niveau :

1. Rafraîchissez ou créez votre sandbox de préversion avant la limite de 17 h PT le 27 août 2026, sinon vous manquez complètement l'instance de préversion.
2. Inventoriez chaque intégration utilisant l'OAuth username-password et migrez-la vers JWT ou le flux web server.
3. Rappelez-vous que le metadata créé sur l'API version Winter '27 ne peut pas être déployé vers un org de production tant que cet org n'est pas mis à niveau, alors gardez les tests de version hors de votre chemin de déploiement normal pendant la fenêtre de préversion.

Rien de tout cela n'est du travail optionnel. Prendre les devants fait la différence entre un week-end de mise à niveau tranquille et un incident. Pour la vue d'ensemble de l'orientation de la plateforme, lisez nos analyses sur ce qui a changé en Summer '26 et les tendances DevOps que chaque release manager doit suivre en 2026. Si une version comme celle-ci est le moment où vous dépassez les change sets et l'outillage natif, une migration guidée vers un vrai pipeline est l'étape suivante.

FAQ

Quelle est la dernière version de Salesforce en ce moment ?

Summer '26 est la version en production aujourd'hui, en API version 67.0. Winter '27 met à niveau la production par vagues les 4 septembre, 2 octobre et 9 octobre 2026.

DevOps Center est-il encore un managed package ?

Non. Depuis Summer '26, DevOps Center est natif à la plateforme, sans managed package à installer ni à mettre à niveau.

Quel est le plus gros changement cassant pour les équipes DevOps ?

Winter '27 retire le flux OAuth 2.0 username-password. Les intégrations utilisant un nom d'utilisateur, un mot de passe et un security token cessent de recevoir des tokens après la mise à niveau, et échouent silencieusement.

Pourquoi le comportement de mon Apex a-t-il changé après Summer '26 ?

L'API version 67.0 fait passer par défaut SOQL, DML et les classes sans mot-clé sharing en user mode et with sharing, donc les permissions d'objet et de champ sont désormais appliquées là où elles ne l'étaient peut-être pas avant.

Quand a lieu la préversion sandbox de Winter '27 ?

La préversion sandbox ouvre le 28 août 2026. Pour atterrir sur une instance de préversion, rafraîchissez ou créez la sandbox avant 17 h PT le 27 août.