Le 15 juin 2026, Salesforce déploie Agentforce Summer '26 : l'orchestration multi-agents passe officiellement de la bêta à la disponibilité générale (GA), Gemini 3.5 Flash devient le modèle par défaut de la plateforme, et le protocole Agent2Agent (A2A) ouvre l'écosystème aux agents non-Salesforce.
Pour les organisations qui utilisent Salesforce comme CRM central, c'est un basculement significatif : Agentforce n'est plus un outil de création d'agents individuels, mais une plateforme d'orchestration où plusieurs agents spécialisés coopèrent sur un même workflow client. Atlas Reasoning Engine 3.0 coordonne leurs interactions ; Agentforce Gateway impose les règles de gouvernance.
L'annonce a été faite le 9 juin 2026, six jours avant le déploiement effectif. Elle arrive en même temps que l'intégration de Gemini 3.5 Flash dans les environnements Gemini Enterprise (activé par défaut depuis le 8 juin) et que la publication du guide développeur Summer '26 par Salesforce. Ce dossier décrypte chaque composant et ce que les équipes DSI et Salesforce admins doivent préparer avant le 15 juin.
L'orchestration multi-agents : de la bêta à la production
L'orchestration multi-agents Agentforce en GA signifie qu'un agent orchestrateur peut désormais déléguer automatiquement des tâches à des agents spécialisés en production, avec un contexte partagé entre tous les agents d'une même conversation. Ce qui était en bêta restreinte depuis fin 2025 devient accessible à tous les clients Agentforce le 15 juin.
Le fonctionnement est le suivant : un agent orchestrateur reçoit une demande client, inspecte les descriptions et actions disponibles des agents spécialisés enregistrés, puis route le travail vers le plus adapté. Si plusieurs étapes sont nécessaires, l'orchestrateur enchaîne les délégations en séquence ou en parallèle. Le client, lui, interagit avec un point de contact unique — il ne sait pas et ne doit pas savoir qu'un agent stock, un agent logistique et un agent facturation ont collaboré pour lui répondre.
Exemples de workflows multi-agents devenus possibles
- Service client complexe : un agent orchestrateur reçoit une réclamation, délègue la vérification de commande à un agent stock, la consultation du contrat à un agent juridique, et la proposition de remboursement à un agent finances — en une seule interaction.
- Qualification commerciale avancée : l'orchestrateur interroge un agent scoring, un agent CRM pour l'historique, et un agent calendrier pour proposer un créneau de démo, sans que le commercial ait à naviguer entre plusieurs outils.
- Onboarding client automatisé : plusieurs agents spécialisés (contractuel, provisioning, formation) s'enchaînent dans un workflow structuré déclenché dès la signature.
Une nuance importante : les workflows cross-org (qui impliquent plusieurs instances Salesforce distinctes) restent en preview à la date du 15 juin. Si votre organisation a une architecture multi-org, vérifiez la feuille de route Salesforce avant de concevoir des orchestrations qui en dépendraient.
Gemini 3.5 Flash : pourquoi pas un modèle Pro ?
Salesforce choisit Gemini 3.5 Flash plutôt qu'un modèle Pro ou un modèle haut de gamme pour une raison économique précise : une plateforme d'agents fait des milliers d'appels de modèle par jour. À cette échelle, la latence et le coût par appel priment sur la puissance brute de raisonnement. Flash, qui délivre une performance 4× supérieure en vitesse à des modèles comparables, change l'équation opérationnelle.
Ce qui rend ce choix techniquement défendable : Gemini 3.5 Flash surpasse les modèles Pro-tier sur les benchmarks de coding et de tâches agentiques — une hiérarchie inhabituelle qui s'explique par la spécialisation de Flash pour les pipelines à fort volume de tokens et d'appels d'outils. Dans un pipeline Agentforce, l'agent ne raisonne pas de façon générale : il inspecte des objets CRM, appelle des tools, met à jour des records. Flash est optimisé exactement pour ce type de tâches structurées à haute fréquence.
Le rôle de l'Atlas Reasoning Engine
L'Atlas Reasoning Engine 3.0 complète Flash en ancrant ses réponses dans les données Salesforce : Data Cloud, objets CRM, connaissances métier. L'engine gère le grounding (prévention des hallucinations sur des données d'entreprise) et le routage (quel agent pour quelle sous-tâche). C'est cette combinaison — un modèle rapide et économique + un layer de grounding contextuel — qui rend l'approche viable en production.
Salesforce conserve la possibilité de brancher d'autres modèles via BYO-LLM (Bring Your Own LLM) pour les cas d'usage à forte exigence de raisonnement ou à contrainte de souveraineté. Si vous avez des agents critiques qui requièrent un raisonnement profond — analyse juridique, aide à la décision financière — gardez BYO-LLM sur votre radar. Nous avions analysé le rapport qualité/coût de Gemini 3.5 Flash dans notre article dédié : Gemini 3.5 Flash : diviser le coût de vos features IA par 3.
Atlas 3.0 et le protocole A2A
Atlas 3.0 est la couche de coordination de l'Agentforce multi-agents. Il détermine quel sous-agent est sollicité pour quelle tâche, dans quel ordre, avec quel contexte transmis. Il gère également la mémoire de session : si l'agent logistique a besoin de l'historique de commandes que l'agent CRM vient de récupérer, Atlas s'assure de la transmission sans que vous ayez à câbler manuellement chaque passage de données.
Le protocole Agent2Agent (A2A)
A2A est un protocole ouvert qui normalise la communication entre agents de vendors différents. Avec A2A, un agent orchestrateur Agentforce peut déléguer une tâche à un agent construit sur Azure AI, Google Cloud, ou n'importe quelle plateforme qui implémente le protocole. La requête, les résultats et le contexte passent via un standard commun, sans couplage en dur.
Ce que cela change en pratique : si votre organisation a un agent procurement sur Azure et un agent logistique construit en interne, l'orchestrateur Salesforce peut les coordonner dans un workflow unifié sans migration technique. Pour les DSI qui gèrent plusieurs départements construisant des agents sur des stacks différentes, c'est la fin des silos d'agents.
Nuance importante : A2A est un protocole ouvert, mais l'adoption côté partenaires non-Salesforce est encore en cours à la date de publication. Avant de designer une architecture multi-vendor basée sur A2A, vérifiez la maturité de l'implémentation chez chaque éditeur tiers impliqué.
MCP et Agentforce Gateway
Agentforce Summer '26 intègre le Model Context Protocol (MCP) comme standard d'outillage et ajoute Agentforce Gateway comme couche de gouvernance : politiques d'accès par agent, limites d'usage, et règles d'autorisation granulaires.
Concrètement, MCP dans Agentforce signifie que vos agents peuvent se connecter aux mêmes serveurs MCP que vos autres outils IA — Jira, Slack, ERP, bases documentaires internes. Un serveur MCP bien conçu peut être réutilisé par plusieurs agents sans recâblage. Pour une organisation qui a déjà investi dans des serveurs MCP, c'est une économie réelle de développement. Nous avions analysé la gouvernance MCP dans le contexte de l'acquisition Snowflake-Natoma : Snowflake rachète Natoma : le MCP s'impose comme couche de gouvernance.
Agentforce Gateway : la gouvernance qui manquait
La Gateway répond à une question que les DSI posaient depuis les premières démos Agentforce : comment contrôler finement quels agents accèdent à quels outils, avec quelles limites ? La réponse est maintenant opérationnelle :
- Politiques manuelles : définir connexion par connexion quels agents MCP peuvent appeler quel outil.
- Politiques automatiques : appliquer des règles en fonction de critères — source de connexion, nom de l'agent, type d'environnement (sandbox vs production).
- Limites de taux : plafonner le nombre d'appels par agent sur une période donnée, ce qui évite les dérives de coût sur les agents à fort volume.
Pour les organisations à contrainte de conformité — finance, santé, secteur public — Agentforce Gateway est la brique non-négociable avant tout déploiement multi-agents en production. Sans elle, chaque agent autonome représente un vecteur d'accès potentiel à vos systèmes sensibles. Pour des besoins d'automatisation métier sur mesure connectant plusieurs systèmes internes, ce type de gouvernance est systématiquement intégré dans nos architectures.
Vos trois priorités avant le 15 juin
Si vous utilisez Agentforce en production ou en pilote, voici les trois actions à mener avant le 15 juin pour éviter les mauvaises surprises au déploiement.
- Inventaire et cartographie des agents existants. Identifiez quels agents Agentforce vous avez en production ou en bêta. Pour chacun, documentez ses actions disponibles, ses intégrations et ses dépendances modèles. Cet inventaire est le prérequis de toute décision d'orchestration : vous ne pouvez pas concevoir une architecture multi-agents sans savoir précisément ce que fait chaque brique.
- Validation de Gemini 3.5 Flash sur vos cas d'usage réels. Si certains agents utilisent un BYO-LLM ou un modèle personnalisé, comparez la qualité de Flash vs votre modèle actuel sur un échantillon représentatif de requêtes réelles avant le déploiement automatique. Flash performe très bien sur les tâches agentiques standardisées, mais certains cas métier très spécialisés — rédaction contractuelle longue, analyse de données sectorielles atypiques — peuvent nécessiter un modèle plus puissant.
- Plan de gouvernance MCP avec Agentforce Gateway. Si vous utilisez des serveurs MCP et prévoyez d'ouvrir l'accès à plusieurs agents, définissez les politiques d'autorisation avant le 15 juin plutôt qu'après. Ouvrir l'accès multi-agents à des outils sensibles sans gouvernance préalable est le cas d'usage qui génère le plus d'incidents en production.
Pour les organisations qui n'utilisent pas encore Agentforce, Summer '26 représente un point d'entrée plus solide que les versions précédentes — l'orchestration multi-agents en GA réduit significativement la complexité technique d'un premier déploiement ambitieux. Si vous êtes en phase de cadrage, contactez-nous pour évaluer la pertinence d'une architecture Agentforce sur votre contexte.
FAQ
Sources
FAQ — Agentforce Summer '26 : orchestration multi-agents en GA, Gemini 3.5 Flash natif et Atlas 3.0 — le dossier avant le 15 juin
L'orchestration multi-agents Agentforce nécessite-t-elle une licence spécifique ?
Salesforce n'a pas publié de grille tarifaire dédiée à l'orchestration multi-agents dans l'annonce Summer '26. La fonctionnalité est présentée comme incluse dans Agentforce. Contactez votre Account Executive Salesforce pour vérifier les conditions de votre contrat actuel, en particulier si vous êtes sur un plan Agentforce Starter ou sur une licence héritée.
Gemini 3.5 Flash sera-t-il le seul modèle disponible dans Agentforce Summer '26 ?
Non. Gemini 3.5 Flash devient le modèle par défaut, mais le mécanisme BYO-LLM (Bring Your Own LLM) reste disponible pour brancher un autre modèle — que ce soit GPT-5, Claude Opus 4 ou un modèle auto-hébergé. Pour les cas d'usage à forte exigence de raisonnement ou à contrainte de souveraineté, BYO-LLM reste l'option pertinente.
Comment le protocole A2A fonctionne-t-il avec des agents construits hors Salesforce ?
A2A est un protocole ouvert qui normalise les échanges entre agents de différentes plateformes. Pour qu'un agent non-Salesforce soit orchestrable par Agentforce, il doit implémenter le standard A2A côté serveur. À la date de juin 2026, l'adoption est en cours chez les partenaires — vérifiez la maturité de l'implémentation avant de designer une architecture multi-vendor en production.
Agentforce Gateway est-il disponible dès le 15 juin pour tous les clients ?
Selon l'annonce Salesforce du 9 juin 2026, Agentforce Gateway ship en GA le 15 juin avec le reste du package Summer '26. Les détails de disponibilité par édition (Enterprise vs Unlimited vs autres) n'ont pas été précisés dans l'annonce publique — vérifiez les release notes détaillées sur le Salesforce Help Portal.
MCP dans Agentforce : faut-il reconfigurer les serveurs MCP existants ?
Non, si vos serveurs MCP respectent le standard MCP officiel (modelcontextprotocol.io), ils devraient être compatibles avec Agentforce sans reconfiguration majeure. La configuration à faire est du côté Agentforce Gateway : définir les politiques d'autorisation qui contrôlent quels agents Agentforce peuvent appeler quels outils MCP.