Ce qui a changé dans Summer '26 pour les équipes DevOps Salesforce

En bref : Summer '26 apporte la version d'API 67.0, et pour les équipes DevOps trois points pèsent plus lourd que tout le reste réuni. Les opérations de base de données Apex s'exécutent désormais en user mode par défaut, les classes sans mot-clé de partage passent par défaut à with sharing, et WITH SECURITY_ENFORCED ne compile plus. Ces trois éléments dépendent de la version d'API à laquelle une classe est enregistrée, ce qui fait du réglage de version d'API de votre pipeline une décision de comportement et non une tâche d'entretien.

De quelle release parle-t-on, et quand est-elle arrivée ?

Summer '26 correspond à la version d'API 67.0. L'aperçu en sandbox a ouvert le 8 mai 2026 et les déploiements en production ont eu lieu les 15 mai, 5 juin et 12 au 13 juin 2026 : si vous lisez ceci, vous y êtes déjà. La liste complète se trouve dans les notes de version. Voici le sous-ensemble qui touche le déploiement, les métadonnées et le comportement des API.

Qu'est-ce qui casse réellement un pipeline dans Summer '26 ?

Trois choses, dans l'ordre de rapidité avec laquelle elles mordent.

1. WITH SECURITY_ENFORCED est retiré et ne compile plus. Celle-ci est bruyante et immédiate : tout déploiement contenant encore la clause fait échouer le build. Remplacez-la par WITH USER_MODE, comme l'indique le guide développeur de la release.
2. Les opérations de base de données Apex passent en user mode par défaut. À partir de l'API 67.0, DML et SOQL s'exécutent avec les permissions d'objet, la sécurité au niveau des champs et les règles de partage de l'utilisateur courant, sauf indication contraire.
3. Les classes sans mot-clé de partage passent par défaut à with sharing. L'ancien défaut était l'inverse. Un code qui s'appuyait discrètement sur l'accès en mode système renvoie désormais discrètement moins de données.

Les triggers continuent de s'exécuter en mode système dans toutes les versions. Utile à retenir, dangereux à utiliser comme béquille.

Pourquoi le changement de partage est-il un problème de déploiement et non de code ?

C'est le point que la plupart des récapitulatifs manquent. Les nouveaux défauts s'appliquent aux classes enregistrées en version d'API 67.0 ou ultérieure. Le comportement de votre org ne change donc pas le jour où la release arrive, mais le jour où votre pipeline monte une version d'API.

Ce qui transforme trois lignes de votre dépôt en changements fonctionnels :

• sourceApiVersion dans sfdx-project.json
• l'élément de version dans votre package.xml
• la version d'API par classe dans chaque .cls-meta.xml

Trois conséquences en découlent, et aucune n'est théorique.

• Vos tests ne l'attraperont pas. Les tests Apex s'exécutent dans un contexte que vous contrôlez généralement : une classe peut passer toutes les assertions et renvoyer quand même moins de lignes à un vrai utilisateur.
• Une montée de version d'API en masse est une livraison, pas une corvée. Traitez "tout passer en 67.0" comme un changement qui exige une UAT avec de vrais profils, pas comme un ticket de rangement.
• Les montées partielles créent un comportement scindé. Deux classes de la même chaîne d'appels sur des versions d'API différentes se comporteront différemment. Si vous montez, montez un domaine entier à la fois.

L'ordre sûr consiste à déclarer explicitement le partage sur chaque classe d'abord, puis à monter la version d'API. L'explicite bat le défaut, dans les deux sens.

Quelles fins de vie mettre au backlog dès maintenant ?

• Les versions d'API plateforme 31.0 à 40.0. Dépréciées, avec retrait complet en Summer '28, moment où ces appels échoueront. Tout doit être en 41.0 ou ultérieur.
• Le login() de l'API SOAP sur les versions 31.0 à 64.0, retiré en Summer '27.
• Les identifiants de session de packages managés pour authentifier de l'Apex anonyme, appliqué à partir de Summer '27.

Rien de tout cela n'est urgent ce sprint. Ce sont exactement les sujets qu'on découvre dans dix-huit mois, à 2h du matin, via une intégration qui tombe. Faites l'inventaire des versions d'API tant qu'il coûte peu.

Qu'y a-t-il de vraiment neuf pour la CI/CD ?

• La logique Data 360 dans le pipeline. Les DevOps data kits déplacent extensions de code et transformations de données de la sandbox vers la production, extensions associées incluses, pour qu'un pipeline promeuve la logique Data 360 comme il promeut déjà Apex et LWC.
• L'évaluation d'agents en métadonnée. Les Custom Scorers se déploient via la Metadata API avec aiAgentScorerDefinitions, ce qui place les portes qualité des agents sous gestion de versions.
• Un indicateur de scratch org sur lequel vous trébucherez. Les tests d'intégration exigent désormais ApexIntegrationTests dans le tableau features de la définition de scratch org. Ajoutez-le avant que votre prochaine exécution échoue sans raison apparente.
• DevOps Center devient natif. Salesforce Ben rapportait en juin 2026 que la nouvelle génération de DevOps Center abandonne le package managé au profit d'une capacité native, avec un serveur DX MCP pour piloter le pipeline depuis un IDE agentique. À suivre. Pas encore de quoi changer de plateforme.

Que faire cette semaine ?

1. Cherchez WITH SECURITY_ENFORCED dans le dépôt et remplacez-le. C'est une rupture de build, pas un avertissement.
2. Listez chaque classe sans mot-clé de partage explicite et tranchez sciemment pour chacune.
3. Gelez les montées de version d'API en masse jusqu'à la fin de l'étape deux.
4. Inventoriez les intégrations qui appellent encore l'API 31.0 à 40.0.
5. Ajoutez ApexIntegrationTests à votre définition de scratch org.

FAQ

Summer '26 modifie-t-il le comportement de l'Apex existant ?

Pas de lui-même. Les nouveaux défauts de user mode et de partage s'appliquent aux classes enregistrées en version d'API 67.0 ou ultérieure : les classes existantes conservent leur comportement jusqu'à ce que vous montiez leur version.

Qu'est-ce qui remplace WITH SECURITY_ENFORCED ?

Utilisez WITH USER_MODE. L'ancienne clause est retirée et ne compile plus : tout déploiement qui la contient encore échouera.

Quand les anciennes versions d'API cessent-elles vraiment de fonctionner ?

Les versions 31.0 à 40.0 sont dépréciées avec retrait complet en Summer '28, et le login() SOAP sur les versions 31.0 à 64.0 est retiré en Summer '27. Passez les intégrations en 41.0 ou ultérieur.

Ces changements touchent-ils les triggers Apex ?

Non. Les triggers continuent de s'exécuter en mode système dans toutes les versions d'API.

Si votre pipeline ne sait pas vous dire quelles classes n'ont pas de mot-clé de partage explicite, c'est le manque à combler avant la prochaine release. Serpent effectue une revue de code par IA sur chaque changement, sur tous les plans, et signale exactement ce type de dérive de gouvernance avant qu'il n'atteigne la production.