Orchestration multi-agents sur Salesforce : ce qui rend les transferts entre agents fiables en production

Réponse courte : l'orchestration multi-agents sur Salesforce signifie qu'un agent orchestrateur porte la conversation et confie chaque tâche à un agent spécialisé qui couvre un domaine étroit. Ce qui la rend fiable en production n'est pas un prompt plus gros sur l'orchestrateur, mais un contrat de transfert strict entre agents : ce qui est transmis, ce qui revient, et qui a le droit d'agir. Salesforce a rendu l'orchestration multi-agents d'Agentforce généralement disponible le 15 juin 2026, et le protocole Agent2Agent (A2A) étend le même schéma à des agents qui ne tournent pas sur Salesforce.

Qu'est-ce que l'orchestration multi-agents sur Salesforce ?

C'est une architecture de routage. Un agent principal est le seul point de contact de l'utilisateur et conserve le contexte de session. Derrière lui se trouvent des agents spécialisés, chacun limité à un domaine précis et doté de ses propres actions : Apex, Flow, modèles de prompt, API externes.

Le routage n'est pas un arbre de décision. Le moteur Atlas Reasoning Engine lit la description, les instructions et les actions disponibles de chaque agent enregistré, puis choisit le meilleur candidat à l'exécution. D'où une conséquence sous-estimée : une description d'agent est une logique de routage, pas de la documentation. Des descriptions vagues produisent un routage vague.

Pourquoi un seul gros prompt cesse-t-il de fonctionner ?

Presque toutes les équipes commencent par la version à un seul agent. Elle fait bonne impression en démo et se dégrade en production, pour des raisons structurelles et non corrigeables :

• Dilution des instructions. Des règles utiles à un workflow débordent sur un autre, et le modèle en fait la moyenne.
• Prolifération des outils. Au-delà d'une douzaine d'actions, la précision de sélection chute et le mauvais outil se déclenche.
• Aucun périmètre d'impact. Un agent qui peut rembourser peut rembourser dans chaque conversation qu'il tiendra.
• Changements non testables. Un paragraphe ajouté sur les retours peut modifier en silence le comportement sur la garantie, et il n'y a rien à tester unitairement.

Un spécialiste avec une seule mission et cinq actions n'a aucun de ces problèmes. La complexité ne disparaît pas : elle se déplace vers les jointures entre agents, à sa juste place, car une jointure se spécifie.

À quoi ressemble un orchestrateur avec des spécialistes en production ?

1. Un orchestrateur qui identifie l'intention, garde le contexte et escalade. Il ne porte aucune action métier propre.
2. Un spécialiste par domaine délimité, par exemple contrôle des droits, planification terrain ou ajustements de facturation, chacun avec ses actions et ses cas de test.
3. Un contexte structuré transmis entre eux, plutôt que du texte libre.
4. Une validation humaine sur tout ce qui est irréversible ou financier.
5. Une trace à chaque transfert, pour qu'un mauvais résultat soit imputable à un agent et non à "l'IA".

L'échelle explique pourquoi cela compte. Dans notre programme ASSA ABLOY (FocusCura et Phoniro), la surface opérationnelle couvre 11 000 appareils connectés qui produisent jusqu'à 2,5 millions d'événements par semaine sur trois marchés, et les cas hebdomadaires sont passés de 3 000 à 350 sans renfort du support. Personne ne fait tenir une charge opérationnelle de cette forme dans un seul prompt.

Qu'est-ce qui rend un transfert entre agents fiable ?

C'est la partie que la documentation éditeur saute, et c'est là que les systèmes cassent en production. Traitez chaque transfert comme une interface, pas comme une conversation.

• Typé en entrée, typé en sortie. Si vous ne savez pas écrire le transfert comme une signature de fonction, l'orchestrateur en inventera une, et une autre demain.
• Transmettez des identifiants, pas de la prose. Un CaseId et un AssetId survivent au transfert. Un résumé reformulé, non.
• Donnez au spécialiste le droit de refuser. "Je ne peux pas continuer, le droit a expiré" est une réponse routable. L'improvisation silencieuse ne l'est pas.
• Rendez les actions idempotentes. Les orchestrateurs réessaient. Un réessai ne doit jamais émettre un second remboursement.
• Versionnez les descriptions. Le routage en dépend : modifier une description est un changement de production et passe en revue.

La jointure est le produit. Les agents sont la partie facile ; le contrat entre eux, c'est l'ingénierie.

Où se placent réellement A2A et MCP ?

A2A gère la délégation entre plateformes. Un agent publie une agent card décrivant ce qu'il sait faire ; un agent client la découvre, délègue une tâche et reçoit messages et artefacts en retour. C'est ainsi qu'un orchestrateur Agentforce atteint un spécialiste hébergé ailleurs.

MCP est l'autre axe. Il donne à un agent l'accès aux outils et aux données. Nous construisons des serveurs MCP pour qu'un agent agisse dans les systèmes déjà en place, au lieu de faire repasser chaque action par un écran CRM.

Règle simple : A2A va d'agent à agent, MCP va d'agent à système. Se tromper d'axe est l'erreur d'architecture la plus fréquente que nous voyons.

Comment déployer sans casser les jointures ?

1. Commencez avec trois agents sur un workflow dont les données sont déjà propres. Des agents posés sur des données sales multiplient le désordre.
2. Instrumentez avant de passer à l'échelle. Si vous ne tracez pas un transfert aujourd'hui, vous ne déboguerez pas dix agents au trimestre prochain.
3. Donnez à chaque spécialiste un propriétaire humain nommé.
4. Testez le routage de façon adverse, avec des demandes ambiguës et multi-intentions, pas avec le chemin idéal.
5. Gardez un coupe-circuit par spécialiste, pour qu'un agent défaillant n'emporte pas tout le workflow.

FAQ

L'orchestration multi-agents est-elle disponible en production sur Salesforce aujourd'hui ?

Oui. Salesforce a rendu l'orchestration multi-agents d'Agentforce généralement disponible le 15 juin 2026, avec la prise en charge d'A2A pour les agents hors plateforme.

Avec combien d'agents spécialisés commencer ?

Trois, sur un seul workflow. Validez d'abord les transferts et la traçabilité, puis ajoutez les domaines un par un.

Un modèle plus puissant supprime-t-il le besoin d'orchestration ?

Non. Un modèle plus fort améliore le raisonnement à l'intérieur d'un agent. Il n'apporte ni droits cloisonnés, ni tests par domaine, ni panne imputable. Cela vient de l'architecture.

Qu'est-ce qui casse le plus souvent en production ?

Les transferts. Le contexte perdu entre agents, un mauvais routage causé par une description floue, et des réessais qui répètent une action jamais rendue idempotente.

Faut-il reconstruire les agents hébergés sur d'autres plateformes ?

Non. A2A permet à un orchestrateur Agentforce de déléguer à des agents tiers, donc un spécialiste hors Salesforce peut rejoindre le même workflow.

Tekunda construit des systèmes multi-agents sur Salesforce et en dehors, y compris de l'orchestration agent à agent en production. Si vous passez d'un agent à une équipe d'agents, concevoir les jointures est le premier travail qui compte.