Pas un seul agent, mais un réseau de spécialistes
L'erreur la plus courante est d'imaginer Joule comme un assistant unique polyvalent. La réalité est différente : SAP a construit une architecture multi-agents, où chaque Joule Agent se spécialise dans une fonction métier précise — finance, chaîne d'approvisionnement, gestion des services, RH — au lieu de tout confier à un seul agent généraliste.
La logique est la même que dans une vraie entreprise, où l'on ne demande pas à la même personne de clôturer le bilan et de gérer un retour fournisseur : des compétences différentes sont nécessaires. L'avantage de cette approche est que chaque agent peut se spécialiser en profondeur dans son domaine, au lieu d'être médiocre partout.
Joule comme orchestrateur
Au-dessus du réseau d'agents spécialisés, Joule agit comme orchestrateur central. SAP décrit ce rôle comme celui d'un « chef d'orchestre » : il décompose une tâche complexe en sous-tâches, sélectionne l'agent le plus adapté pour chacune, et coordonne le flux de travail global.
Les humains restent dans le rôle de « compositeur » : ils définissent l'objectif et les contraintes, l'orchestration de l'exécution étant assurée par Joule. C'est un modèle qui sépare nettement deux responsabilités — ce qui doit être fait (humain) et comment coordonner qui le fait (Joule) — réduisant la supervision manuelle sans éliminer le contrôle.
Vous voulez savoir quels Joule Agents sont nécessaires à votre entreprise ?
30 minutes pour discuter de votre cas spécifique.
Les deux protocoles qui font tenir l'ensemble : A2A et MCP
Deux standards ouverts rendent cette architecture possible. Le premier est Agent2Agent (A2A), le protocole que SAP a adopté comme standard préféré pour la collaboration multi-agents et l'interopérabilité entre fournisseurs : il permet à un agent de déléguer une tâche, de demander à un autre agent quelles capacités il possède, et d'échanger des informations de manière structurée, quel que soit le framework avec lequel il a été construit.
Le second est le Model Context Protocol (MCP), le standard d'Anthropic qui régit comment un agent découvre, comprend et interagit avec des outils externes. SAP l'utilise en interne pour donner aux Joule Agents un accès sémantiquement enrichi aux capacités métier de SAP — pas seulement des données brutes, mais un contexte déjà structuré sur ce que ces données signifient pour le processus métier.
Où s'intègrent les agents
Les Joule Agents s'intègrent nativement avec SAP S/4HANA, SAP SuccessFactors, SAP Business Data Cloud, SAP Concur, SAP Customer Experience et SAP Business Network. C'est le cœur de l'écosystème SAP, là où vivent les processus les plus lourds.
Mais l'architecture ne s'arrête pas aux frontières de SAP : des plateformes externes comme Google Cloud, Microsoft Azure, AWS et IBM Cloud peuvent consommer les Joule Agents via un Agent Gateway dédié, ou se faire orchestrer directement par Joule. C'est une architecture pensée pour une entreprise qui a plusieurs systèmes, pas seulement du SAP pur.
Pourquoi cette architecture compte pour évaluer l'adoption
Comprendre cette structure change la façon d'évaluer un projet d'agents sur Joule. Vous n'achetez pas « un chatbot plus intelligent » : vous adoptez une architecture d'agents spécialisés, orchestrés, qui parlent un protocole commun (A2A) et accèdent à vos systèmes via un autre protocole commun (MCP).
Cela signifie que le vrai travail d'implémentation n'est pas « activer Joule », mais décider quels agents vous faut-il, sur quels processus, avec quelles limites d'autonomie. C'est la question que nous traitons avec nos clients dans chaque projet d'agents sur SAP Joule.