Le MCP pour SAP : connecter les modèles d'IA à l'entreprise, en sécurité
Le problème d'intégration que crée l'IA
Avant l'IA agentique, l'intégration d'entreprise était surtout application-à-application : le système A appelle le système B via une interface connue et stable. Les clients IA changent la nature du problème — Claude, ChatGPT, Gemini, SAP Joule et ce qui viendra ensuite veulent tous appeler les mêmes capacités SAP, sans partager par défaut de technologie d'intégration commune.
Construit naïvement, cela devient N clients IA fois M capacités SAP en intégrations sur mesure — une dette d'intégration qui passe mal à l'échelle et s'audite encore plus mal. Le Model Context Protocol existe pour ramener ce N×M à N+M : des capacités SAP exposées une fois, via une interface gouvernée unique, que tout client IA compatible peut découvrir et appeler.
Ce qui change réellement au niveau architecture
Un serveur MCP se place entre les clients IA et SAP, exposant un ensemble défini d'outils — lire une commande client, vérifier un stock, déclencher un workflow — chacun avec un schéma, un périmètre de permission et une piste d'audit. Le client IA découvre ce qui est disponible à l'exécution plutôt que via une intégration codée en dur, ce qui signifie qu'ajouter un nouveau client IA ne nécessite de toucher aucun code côté SAP.
Point essentiel, le MCP ne contourne pas les autorisations SAP — il doit se poser au-dessus. Chaque appel d'outil porte l'identité du contexte appelant, et le serveur MCP applique les mêmes contrôles d'autorisation qu'un utilisateur humain rencontrerait. C'est ce détail qui sépare un déploiement MCP de niveau production d'une démo : l'agent ne peut faire que ce que l'utilisateur SAP sous-jacent est réellement autorisé à faire.
Où nous le déployons
Nous construisons les serveurs MCP comme des charges SAP BTP de premier rang — Cloud Foundry quand la simplicité managée est prioritaire, Kyma quand une équipe a besoin d'un contrôle Kubernetes-natif, tous deux reliés à SAP Integration Suite et Event Mesh pour des patrons d'agents asynchrones et événementiels. Cela maintient la couche MCP dans votre gouvernance BTP existante plutôt que comme un processus annexe non géré.
C'est aussi là que Clean Core et MCP se croisent directement : les outils qu'expose un serveur MCP ne sont fiables et stables qu'à la hauteur des interfaces qui se trouvent derrière eux. Une API RAP ou basée CDS bien cadrée fait un bon outil MCP. Du code spécifique enchevêtré ne le permet pas.