Skip links

Salesforce Summer 26 – Les nouveautés

Les nouveautés Salesforce Summer ’26 sont déployées en production à partir des 15 mai, 5 juin et 12-13 juin 2026 selon les instances.

Dans cet article, nous vous proposons un tour d’horizon des nouveautés Salesforce Summer ’26 les plus intéressantes, sélectionnées à partir des release notes officielles et de retours terrain. Cette release marque la vision de l’Agentic Enterprise, où humains et agents IA collaborent au sein des mêmes processus métier.

Les nouveautés sont regroupées par grands thèmes : Agentforce, Administration, Flow Builder, Screen Flows, Triggered Flows, Développement, Experience Cloud et Data360.

Agentforce

Multi-Agent Orchestration

C’est l’une des fonctionnalités phares de Summer ’26.

Aujourd’hui, dans un centre d’appel, quand un client est transféré d’un service à l’autre, il doit souvent répéter son problème à chaque interlocuteur. Avec la Multi-Agent Orchestration, ce problème disparaît.

Concrètement, Salesforce permet désormais à plusieurs agents Agentforce spécialisés de se passer le relais sur une même conversation et de collaborer, comme une équipe qui se transmet un dossier complet.

Du côté de l’utilisateur final : un seul interlocuteur, une seule conversation, zéro répétition. Le contexte, l’intention et l’historique sont conservés tout au long du parcours.

Jusqu’ici, construire ce type de parcours nécessitait un Flow complexe ou du code Apex : l’orchestration restait manuelle. Ici, l’orchestration est native, déclarative, et les agents se coordonnent d’eux-mêmes selon les règles définies.

⚠️ Cette fonctionnalité est en version Beta. Il est fortement recommandé de tester les scénarios en sandbox avant toute mise en production.

Debug et correction des erreurs de flow avec Agentforce

Summer ’26 introduit une assistance IA pour diagnostiquer les erreurs de flows, aussi bien les erreurs de conception que les erreurs d’exécution sur des flows actifs. Via le panneau Ask Agentforce, il est possible d’obtenir une explication en langage naturel de la cause d’une erreur, ainsi qu’une proposition de correction automatique avec l’option Fix Issue.

⚠️ Fonctionnalité en Beta. Les corrections générées doivent être considérées comme un brouillon à valider, et non comme une implémentation finale.

Administration

Chatter désactivé par défaut dans les nouvelles orgs

Un signal fort de la stratégie Salesforce : à partir de Summer ’26, Chatter est désactivé par défaut sur toutes les nouvelles organisations.

Il reste activable manuellement, et n’est pas désactivé sur les organisations existantes. Mais la direction est claire : Salesforce amorce le retrait progressif de Chatter.

Ce n’est pas une surprise. Depuis le rachat de Slack en 2021, Salesforce a progressivement repositionné sa stratégie de collaboration autour de lui. Slack concentre aujourd’hui les investissements : intégration native avec Agentforce, canaux dédiés aux processus métier, automatisations, et désormais des capacités IA embarquées directement dans les conversations.

Chatter, de son côté, n’a plus évolué de manière significative depuis plusieurs années. Sa désactivation par défaut dans les nouvelles orgs n’est que la confirmation officielle d’un retrait qui s’opère en silence depuis longtemps.

Nouvel onglet Field Access dans l'Object Manager

Un nouvel onglet Field Access fait son apparition en bas de chaque objet dans l’Object Manager. Il présente, pour chaque champ de l’objet, une vue des accès accordés par profils et permission sets.

C’est un gain de temps significatif pour les audits de sécurité, les revues de conformité, ou simplement lors de l’onboarding de nouveaux administrateurs qui doivent comprendre la configuration existante.

Emails avec domaines non vérifiés

Depuis février 2026, Salesforce a renforcé ses exigences en matière d’authentification des emails sortants. Pour pouvoir envoyer des emails depuis Salesforce avec un domaine personnalisé, ce domaine doit désormais être vérifié et configuré avec les enregistrements DNS appropriés : SPF, DKIM et idéalement DMARC.

Cette exigence pose un problème concret pour certains profils d’utilisateurs : un consultant externe avec une adresse @gmail.com, un utilisateur Experience Cloud, ou encore un compte système utilisant un domaine que vous ne maîtrisez pas — impossible de vérifier ces domaines, donc impossible d’envoyer des emails dans les règles.

Salesforce introduit une adresse de substitution automatique pour ces cas. L’email est envoyé via une adresse technique du format :

email@[OrgId].sfcustomeremail.com

Le nom d’affichage de l’expéditeur reste inchangé côté destinataire. Seule l’adresse technique en coulisse change — ce qui suffit à satisfaire les contrôles d’authentification sans que l’expérience utilisateur soit dégradée.

Cette configuration s’active dans Setup > Deliverability, via l’option « Use a substitute email address for unverified domains ».

Ce que ça couvre
  • Les utilisateurs avec une adresse email publique (Gmail, Outlook…)
  • Les consultants et utilisateurs externes
  • Les emails système générés automatiquement
  • Les emails envoyés via des comptes email partagés avec un domaine non vérifié
⚠️ Ce n’est pas une solution de contournement de la vérification de domaine — c’est un filet de sécurité pour les cas où la vérification est structurellement impossible. Si vous gérez un domaine d’entreprise, la bonne pratique reste de le vérifier et de configurer SPF/DKIM correctement.

Flow builder

Opérateurs de date dans les composants de Décision

Summer ’26 ajoute un ensemble d’opérateurs spécifiques aux champs de date dans les éléments Decision.

Parmi les nouveautés : Is Today, Is Tomorrow, Is On, mais aussi la gestion des anniversaires — pratique pour des communications de renouvellement ou des rappels annuels.

⚠️ Ces opérateurs s’appliquent uniquement aux champs de type Date, et non aux champs DateTime.

Templates d'email référencés par nom dans les flows

Jusqu’à présent, un flow utilisant un template d’email en sandbox et déployé en production se retrouvait cassé car les identifiants des templates diffèrent entre environnements.

Avec Summer ’26, la version 3.0.1 ou supérieure de l’action Send Email stocke les références de templates par nom plutôt que par ID, évitant ainsi ces ruptures au déploiement.

Pour en bénéficier, dépliez la section Show advanced options dans les propriétés de l’action Send Email et sélectionnez la version 3.0.1+.

Collapse des fault paths

Dans la continuité de la Spring ’26 qui permettait de replier les composants Decision et Loop, Summer ’26 étend cette capacité aux Fault Paths.

Les flows complexes gagnent encore en lisibilité sur le canvas.

Taille de batch personnalisable pour les Scheduled Flows

Il est désormais possible de configurer la taille des lots de traitement pour les Scheduled Flows. La valeur par défaut reste 200 enregistrements.

Réduire ce nombre permet de limiter les risques de dépassement des governor limits Apex — au prix d’un temps de traitement global plus long. À calibrer selon le volume et la complexité de chaque flow.

Screen flows

Mise à jour des Screen Flows en langage naturel

La possibilité de modifier des flows en langage naturel via Agentforce, jusqu’ici réservée aux flows déclenchés et planifiés, s’étend désormais aux Screen Flows. Il suffit de décrire en français ou en anglais les modifications souhaitées dans le panneau Agentforce, et le flow est mis à jour en conséquence.

⚠️ Fonctionnalité en Beta. Les modifications générées doivent impérativement être relues avant activation.

Pour activer cette fonctionnalité : Setup > Process Automation Settings > activer Agentforce flow automation (Beta).

Nouveau composant Radio Button Group

Un nouveau composant Radio Button Group fait son apparition dans les Screen Flows, en alternative aux boutons radio classiques.

Il affiche les choix horizontalement sur desktop et verticalement sur mobile, réduisant la hauteur des formulaires et améliorant l’expérience utilisateur.

Vue et liens vers des enregistrements liés dans les datatables

Une amélioration attendue de longue date sur le composant Datatable : les colonnes issues de champs de type Lookup affichent désormais le nom lisible de l’enregistrement lié, et non son identifiant brut.

Il est également possible de configurer ce nom comme un lien hypertexte ouvrant l’enregistrement dans un nouvel onglet.

Fini donc la création de champs formule dédiés aux affichages dans les datatables !

Ajout d'images Static Resources directement depuis Flow Builder (GA)

Jusqu’ici, pour intégrer une image issue des Static Resources dans un composant Display Text, il fallait quitter Flow Builder, naviguer dans Setup pour retrouver le nom exact de la ressource, puis revenir la saisir manuellement dans le composant.

Cette fonctionnalité, désormais en disponibilité générale, permet de rechercher des images existantes, d’en uploader de nouvelles et de renseigner le texte alternatif directement depuis le composant, sans jamais quitter Flow Builder.

Développement

Interopérabilité MCP : connecter des clients IA tiers à Salesforce

Summer ’26 introduit la prise en charge native du protocole MCP (Model Context Protocol) dans Agentforce. Concrètement, tout client IA compatible MCP — comme Claude, ChatGPT ou Cursor — peut désormais se connecter directement aux données et métadonnées Salesforce, de manière sécurisée et sans développement d’intégration sur mesure.

Côté architecture, Salesforce expose ses propres serveurs MCP hébergés (Hosted MCP Servers), accessibles depuis Setup via la recherche MCP Servers. Chaque serveur expose un ensemble d’outils ciblés :

  • Accès aux métadonnées de l’org
  • Requêtes sur les données CRM
  • Contexte Agentforce

Ce que ça change concrètement : un développeur travaillant dans Cursor ou Claude peut interroger le schéma de l’org, récupérer des enregistrements ou générer des métadonnées Salesforce précises — directement depuis son environnement de travail, sans jamais ouvrir l’interface Salesforce.

Cette fonctionnalité est disponible dans Lightning Experience en éditions Professional, Enterprise, Unlimited et Developer avec l’option API activée.

Apex : fin du mode système par défaut, place au mode utilisateur

Summer ’26 marque un tournant dans la posture de sécurité par défaut d’Apex. Jusqu’ici, les opérations de base de données — SOQL, SOSL et DML — s’exécutaient en mode système, avec un accès total aux données indépendamment des permissions de l’utilisateur connecté. Ce comportement change.

Mode utilisateur par défaut

Les opérations de base de données s’exécutent désormais en mode utilisateur par défaut. Concrètement, si l’utilisateur connecté n’a pas accès à un champ ou un objet, la requête respecte cette restriction — sans qu’il soit nécessaire de le spécifier explicitement dans le code.

C’est un changement de paradigme important : le comportement sécurisé devient la norme, et non plus l’exception à implémenter manuellement.

Retrait de WITH SECURITY_ENFORCED au profit de WITH USER_MODE

La clause WITH SECURITY_ENFORCED est officiellement retirée au profit de WITH USER_MODE, plus cohérente avec le nouveau comportement par défaut et plus explicite dans son intention.

-- Avant
SELECT Id, Name FROM Account WITH SECURITY_ENFORCED

-- Après
SELECT Id, Name FROM Account WITH USER_MODE

Règles de partage appliquées automatiquement

Les classes Apex appliquent désormais automatiquement les règles de partage de l’org. Fini le recours systématique à la clause with sharing pour garantir que le code respecte les règles de visibilité — c’est désormais le comportement natif.

⚠️ Ces évolutions peuvent casser du code Apex existant si celui-ci reposait implicitement sur le mode système pour accéder à des données normalement restreintes. Un audit des classes Apex critiques est fortement recommandé avant la mise à jour en production.

ApexGuru (GA)

Jusqu’ici en beta, Apex Guru passe en disponibilité générale avec Summer ’26. L’outil analyse le code Apex et détecte automatiquement les anti-modèles les plus courants — au premier rang desquels les requêtes SOQL dans des boucles, responsables de la majorité des dépassements de governor limits en production.

Les suggestions de correction sont proposées directement dans l’environnement de développement, sans avoir à quitter l’IDE ni consulter une documentation externe.

Experience Cloud

Règles d'attribution automatique des Cases

Jusqu’ici, les cases créés depuis un portail Experience Cloud ne déclenchaient pas automatiquement les règles d’attribution standard. Il fallait passer par un Flow ou du code Apex pour router ces cases vers les bonnes équipes.

Avec Summer ’26, les Case Assignment Rules s’appliquent désormais nativement aux cases créés via Experience Cloud, avec le même comportement que les cases issus d’Email-to-Case ou de l’interface standard.

La configuration se fait dans Setup > Case Assignment Rules en cochant l’option « Apply case assignment rules to cases created via the Community Portal ». Cette option n’est visible que si Experience Sites est activé sur l’org.

Data360

Capture automatique des enregistrements en erreur

Lors de l’ingestion de données, les enregistrements en échec sont désormais capturés automatiquement dans un objet dédié : les Problem Records.

Fini le débogage à l’aveugle sur des pipelines d’ingestion. Il est maintenant possible d’identifier précisément quels enregistrements ont échoué, pour quelle raison, et d’agir en conséquence — sans interrompre le flux global.

Scripts Python dans les transformations

La fonctionnalité Code Extension permet désormais de déployer des scripts Python personnalisés qui s’exécutent dans des conteneurs isolés directement sur la plateforme. Les cas d’usage couverts incluent les transformations de données complexes en batch — manipulation de chaînes, calculs personnalisés, nettoyage de données — ainsi que la logique de chunking personnalisée lors de la création d’index de recherche.

Le workflow de développement s’appuie sur le Data Custom Code Python SDK et le plugin Salesforce CLI Code Extension pour écrire et déboguer les scripts en local, avant déploiement en sandbox. L’exécution et le monitoring se font ensuite via un DLO de logs dédié.

⚠️ Le déploiement du code revient aux développeurs, mais l’exécution et le monitoring sont réservés aux utilisateurs disposant du permission set Data Cloud Architect.

Points d'attention

Salesforce Summer ’26 est une release qui demande de l’attention. Les changements de comportement par défaut en Apex peuvent impacter votre org sans action proactive de votre part.

Sur le fond, la direction est claire : Agentforce n’est plus une couche optionnelle que l’on greffe sur Salesforce. Il devient progressivement l’infrastructure sur laquelle repose l’ensemble de la plateforme — des flows aux données, en passant par le service client et les intégrations tierces.

Vous avez des questions sur l’impact de Summer ’26 sur votre organisation, ou vous souhaitez être accompagné dans la mise en place d’Agentforce ? Contactez notre équipe — nous serons ravis d’échanger sur votre projet.