Le cloud : innovation technique, pression en faveur de la transformation commerciale et souveraineté numérique

Au cœur de ce tournant historique marqué par le cloud computing se trouve le changement de paradigme qui voit l'achat classique de logiciels céder la place à l'accès, sous forme d'abonnement, à des fonctionnalités informatiques via des infrastructures cloud. Pour la clientèle mondiale existante de SAP, leader mondial du marché des progiciels de gestion intégrée (ERP), cette évolution ne se résume toutefois pas à un simple changement de génération technique, mais implique une réorganisation commerciale, juridique et organisationnelle.

Sous la pression des attentes des marchés financiers internationaux, qui exigent des revenus de souscription récurrents et prévisibles, la direction du groupe SAP a de fait abandonné sa stratégie axée exclusivement sur la vente de logiciels. En fixant la fin du support technique pour la SAP Business Suite 7 bien établie ainsi que pour le système central SAP ERP 6.0 à la fin de l’année 2027 – accompagnée d’une prolongation payante et facultative payante jusqu’à fin 2030 –, une pression immense en faveur de la transformation s’exerce tant sur les PME que sur les grands groupes.

Cette situation difficile exige des responsables des services informatiques, des équipes de direction ainsi que des centres d'expertise client (CCoE) qu'ils procèdent à une analyse lucide et critique : Les promesses alléchantes de la rhétorique marketing du cloud laissent entrevoir des processus métier plus agiles, un accès aisé à l’intelligence artificielle ainsi qu’une réduction drastique des coûts d’exploitation. La réalité opérationnelle dans les pays germanophones et à l’échelle mondiale révèle en revanche un scepticisme profond et une désillusion vis-à-vis des architectures. Une part considérable des clients SAP existants s’oppose à la transition imposée et vers les architectures de cloud public et cherche des moyens de garantir sa propre souveraineté numérique, le contrôle sans entrave de ses « joyaux de la couronne » stratégiques et la préservation de la valeur des logiques de processus qui se sont développées au fil du temps, comme les modifications ABAP.

Dans ce contexte, le cloud computing cesse d'être un simple choix technique en matière d'infrastructure pour devenir une question existentielle liée à la liberté d'action stratégique. La distinction théorique du cloud computing s'articule traditionnellement autour des trois modèles de services bien connus : Infrastructure as a Service (IaaS), Platform as a Service (PaaS) et Software as a Service (SaaS).

IaaS, PaaS et SaaS

Alors que l'IaaS se contente de fournir de la puissance de calcul purement virtuelle, des supports de stockage et des capacités réseau, le PaaS offre aux clients SAP existants des environnements d'exécution structurés, des bases de données et des services applicatifs. Le modèle SaaS, quant à lui, incarne l'exonération totale de la gestion interne de l'infrastructure informatique, en mettant à la disposition des utilisateurs ERP, via Internet, une application logicielle prête à l'emploi, incluant toutes les tâches de maintenance et d'exploitation, sous forme de solution clé en main.

Dans la réalité concrète des entreprises industrielles complexes, il est toutefois apparu que les approches SaaS rigides et monolithiques répondent rarement aux exigences très variées des chaînes de valeur modernes. Il faut au contraire des architectures cloud hybrides et flexibles, capables d’orchestrer de manière transparente les centres de données locaux, les instances de cloud privé dédiées et les capacités évolutives des hyperscalers.

Dans ce contexte, Red Hat, spécialiste de l'open source, joue un rôle clé pour l'ensemble de l'écosystème SAP. Alors que Linux est depuis de nombreuses années le système d'exploitation de référence incontesté pour SAP Hana, la base de données en mémoire, le système d'exploitation Red Hat Enterprise Linux (RHEL) s’est imposé comme l’épine dorsale privilégiée et la base standard pour les environnements informatiques internes de SAP ainsi que pour l’ensemble du portefeuille de clients des SAP Enterprise Cloud Services. Le partenariat entre SAP et Red Hat garantit que les charges de travail SAP exigeantes peuvent être exécutées sur une infrastructure renforcée, certifiée et à sécurité intégrée, que ce soit dans un centre de données local propre à l’entreprise ou sur les infrastructures d’hyperscalers mondiaux.

Kubernetes d'entreprise

Ce n'est toutefois qu'avec le déploiement de la plateforme Kubernetes d'entreprise Red Hat OpenShift que le client SAP existant parvient véritablement à s'affranchir des contraintes architecturales liées aux technologies propriétaires. OpenShift fait office de couche d’abstraction et d’intégration universelle qui, en tant que structure fédératrice indépendante des éditeurs, recouvre les infrastructures sur site traditionnelles, les environnements d’hébergement privés ainsi que les plateformes publiques de Microsoft Azure, Amazon Web Services et Google Cloud. Grâce à cette abstraction indépendante du cloud, OpenShift protège l’utilisateur contre un verrouillage progressif lié au fournisseur de cloud concerné. Les développeurs ERP et les architectes informatiques gagnent ainsi en liberté stratégique : ils peuvent concevoir des applications une seule fois et les exploiter de manière flexible où qu’elles se trouvent : « Develop once, deploy anywhere ! »

La combinaison d'OpenShift et de la Red Hat Ansible Automation Platform permet en outre l'automatisation complète, de bout en bout, d'environnements système complexes, de processus de déploiement, de politiques de sécurité et de tâches quotidiennes d'exploitation informatique. La SAP Edge Integration Cell (EIC), qui succède aux systèmes classiques d’orchestration des processus en tant que solution moderne et conteneurisée, constitue un excellent exemple de la convergence informatique entre l’open source et l’architecture SAP.

„ Nous assurons la sécurité dans le cloud grâce à des agents IA en
” la mise en place d'un environnement d'exécution avec notre partenaire technologique Nvidia. »

Thomas Pfiester,
Responsable de l'engagement client et de l'adoption à l'échelle mondiale,
SAP, (Conférencier principal lors du congrès annuel de la DSAG)

Edge Integration Cell nécessite un environnement d'exécution Kubernetes à haute disponibilité et a été officiellement validé pour Red Hat OpenShift, ce qui permet aux entreprises d'exploiter des points de terminaison API et des intégrations de données critiques pour leur activité sur site, dans leur propre usine ou dans un cloud privé, tout en garantissant la connexion à la Business Technology Platform (SAP BTP). Dans le cadre des infrastructures Microsoft également, l’Azure Center for SAP Solutions s’appuie sur le SAP Deployment Automation Framework (SDAF), développé conjointement, et utilise des composants Red Hat pour le déploiement automatisé de l’infrastructure. L’open source et les plateformes de conteneurs hybrides s’avèrent ainsi être le rempart indispensable à la préservation de la souveraineté numérique du secteur industriel européen dans le cloud.

Un aperçu du portefeuille d'offres de SAP révèle un éventail varié d'options d'exploitation et de licences qui diffèrent considérablement les unes des autres en termes de fonctionnalités, de liberté de configuration et d'engagements commerciaux. À l’extrémité traditionnelle de ce spectre se trouve le modèle « on-prem » classique. Dans ce cas, l’entreprise utilisatrice achète ou loue les licences logicielles et exploite le système S/4 dans son propre centre de données ou dans le cadre d’un hébergement dédié chez un prestataire de services. L’avantage inestimable de cette variante réside dans le contrôle illimité du système, la liberté totale de configuration au niveau du backend ainsi que la gestion des mises à jour et des correctifs sans contrainte de délai. L’entreprise conserve la souveraineté absolue sur ses données et n’est pas contrainte de suivre les cycles de mise à niveau rigides imposés par l’éditeur.

L'inconvénient majeur réside toutefois dans la responsabilité totale qui incombe à l'entreprise en matière de matériel, de sauvegarde des bases de données, de fiabilité et de mise à disposition d'un personnel informatique hautement spécialisé. De plus, SAP exclut de plus en plus les clients existants disposant uniquement d’installations sur site des extensions innovantes telles que les scénarios d’IA natifs ou les fonctionnalités BTP spécifiques, afin d’accroître artificiellement la pression en faveur de la migration.

Développez-vous avec SAP

SAP présente « Rise with SAP », une offre complète, comme la principale voie de transformation pour sa base de clients existante. La solution S/4 Hana Cloud Private Edition est au cœur de ce programme. D'un point de vue technique, le « Private Cloud » est un système dédié à locataire unique, exploité sur l'infrastructure de SAP ou d'hyperscalers sélectionnés, et fourni sous forme de service géré.

Contrairement au cloud public, l'édition privée offre une gamme de fonctionnalités de gestion d'entreprise pratiquement identique ainsi qu'une couverture sectorielle aussi large que celle de la version sur site. Avec l’édition privée, le client existant peut continuer à utiliser l’interface graphique SAP à laquelle il est habitué, procéder à une personnalisation approfondie et poursuivre les développements Z existants, tandis que l’exploitation de base de l’infrastructure, l’application des correctifs de sécurité et les services techniques définis sont confiés à SAP. Toutefois, même au sein de l’édition privée, SAP accentue continuellement la pression sur les clients pour qu’ils respectent le principe du « Clean Core » et transfèrent progressivement les extensions spécifiques au client vers la Business Technology Platform ou vers des structures découplées.

À l'opposé, on trouve l'offre commerciale « Grow with SAP », qui s'adresse spécifiquement aux nouveaux clients, aux entreprises de taille moyenne dont les processus sont fortement standardisés ou aux filiales autonomes. Grow repose sur S/4 Hana Cloud Public Edition, un véritable produit SaaS multi-tenant.

Dans le cloud public, plusieurs clients partagent l’infrastructure physique et les fonctionnalités logicielles de base, tandis que les données restent strictement séparées sur le plan logique. Ce modèle promet des délais de mise en œuvre courts, des innovations fonctionnelles continues et l’installation entièrement automatisée des mises à jour du système directement par SAP. Ce confort apparent s'accompagne toutefois de restrictions considérables : tout accès direct au code backend ABAP ou à la couche de base de données classique est catégoriquement exclu. Les adaptations ne sont possibles que via des extensions prédéfinies intégrées à l'application ou via des extensions externes « side-by-side » sur la plateforme BTP. Le client SAP Cloud doit être prêt à subordonner radicalement ses processus opérationnels aux « meilleures pratiques » prédéfinies par SAP.

La migration d'un environnement traditionnel sur site vers l'univers cloud de Rise ou Grow s'accompagne d'une refonte nécessaire du cadre contractuel et comptable. Dans l’environnement historique R/3 ou ECC, les entreprises acquéraient des licences perpétuelles (Perpetual Licenses), qui étaient inscrites à l’actif du bilan en tant qu’immobilisations corporelles (CapEx). À cela s’ajoutait une redevance de maintenance annuelle, généralement de 22 %, couvrant l’assistance technique et le droit aux mises à jour logicielles.

Lors de la souscription à un contrat d'abonnement au cloud, cette structure se transforme entièrement en dépenses d'exploitation courantes (OpEx). La propriété du logiciel reste acquise à l'éditeur ; le client n'acquiert qu'un droit d'utilisation temporaire sous forme de location. Si l'entreprise cesse de payer les mensualités ou les annuités, l'accès au système ERP dans le cloud est entièrement suspendu.

Métrique de licence cloud

L'indicateur « Full Use Equivalent » (FUE) constitue l'outil de gestion central de cette transformation des licences. Au lieu d’acheter, comme auparavant, un nombre précis de types de licences utilisateur spécifiques (telles que « Professional », « Functional » ou « Productivity User »), l’entreprise souscrit à un contingent variable de points FUE. La conversion des différents types d’utilisation du S/4 Cloud s’effectue à l’aide de facteurs d’équivalence fixes : un FUE correspond exactement à un « S/4 for Advanced Use » (comparable à l’ancien « Professional User »), à cinq « S/4 for Core Use » (comparables au « Functional User ») ou à trente « S/4 for Self-Service Use ».

Pour l'accès développeur (Developer Access), SAP exige, dans la clé FUE, un ratio de deux FUE par développeur. Alors que SAP présente le modèle FUE comme une solution flexible permettant un rééquilibrage des capacités en fonction des besoins au sein des tranches d'utilisateurs réservées, sans avoir à renégocier laborieusement les contrats, des experts indépendants en licences mettent en garde contre des hausses de prix cachées et drastiques.

Le principal facteur de coûts du modèle FUE réside dans la transition commerciale d'un système de mesure basé sur l'utilisation (Did-Do) vers un système basé sur les autorisations (Could-Do). Alors que dans l’ancien environnement ECC, on mesurait les transactions qu’un collaborateur avait effectivement effectuées dans la pratique, SAP, dans les éditions S/4 Cloud, attribue rigoureusement les licences en fonction des autorisations et des rôles définis dans le système.

Si, en raison de „ rôles monstres “ non harmonisés et accumulés au fil du temps ou d’attributions forfaitaires de profils système, un collaborateur dispose, d’un point de vue purement théorique, de l’autorisation d’accéder à des fonctions avancées de logistique ou de finance, il est automatiquement classé par l’outil de vérification du fournisseur (le service STAR ou S/4 Trusted Authorization Review) dans la catégorie de licence la plus coûteuse (Advanced Use), même s’il n’utilise jamais ces fonctions dans son travail quotidien. Sans un nettoyage en profondeur des structures d’autorisations avant la migration vers un contrat cloud, les clients existants risquent de voir leurs coûts augmenter de 20 à 50 % par rapport à leurs frais de maintenance « sur site » actuels.

Outre les abonnements FUE, les modèles de facturation basés sur la consommation (Consumption Models) sur la Business Technology Platform et au sein du Business Data Cloud (SAP BDC) accentuent le risque commercial. Que ce soit via les BTP Capacity Units, les Cloud Credits ou les AI Units liées à la consommation, le client paie en fonction de l'utilisation effective de la puissance de calcul, des volumes de données ou des jetons d'IA.

Factures « choc » liées au cloud

Le défi contractuel réside ici dans une logique d’expiration : les contingents de crédit prépayés (comme dans le cadre d’un contrat CPEA ou BTPEA) expirent sans compensation à la fin de l’année contractuelle correspondante s’ils n’ont pas été utilisés faute de cas d’utilisation productifs. En revanche, si des pics de charge imprévus ou des requêtes de données incontrôlées surviennent pendant l’exploitation, SAP facture immédiatement la surconsommation aux prix catalogue nettement plus élevés, ce qui entraîne régulièrement les redoutables « cloud bill shocks ».

Cette monétisation stricte s'accompagne du modèle de licence « Digital Access », basé sur les justificatifs, ainsi que de la version 4 de la SAP API Policy, adoptée en avril 2026. Avec cette API Policy, Walldorf a érigé une barrière douanière numérique qui réglemente l'extraction directe et sans licence de données en masse ainsi que l'accès d'agents d'IA tiers au système ERP.

Quiconque exporte des données stratégiques vers des systèmes tiers sans payer de « péage BTP » coûteux se verra facturer des frais d'utilisation indirecte ou des licences basées sur le nombre de documents. Des associations européennes d'utilisateurs telles que la DSAG et l'association CISPE, spécialisée dans le cloud, condamnent fermement cette pratique, qu'elles considèrent comme une tentative, susceptible d'enfreindre le droit de la concurrence, d'imposer un marché fermé et d'enchaîner sans relâche les utilisateurs à l'écosystème propriétaire BTP.

La comparaison directe des trois principaux modèles d'exploitation révèle des différences structurelles profondes qui vont bien au-delà des simples questions d'hébergement. En matière de gouvernance des systèmes et de flexibilité opérationnelle, le modèle classique « sur site » reste la référence pour les entreprises industrielles hautement complexes : L'utilisateur conserve une maîtrise totale sur le calendrier des mises à niveau du système, des packs de fonctionnalités et des correctifs de base de données. Il n'existe aucune fenêtre de maintenance obligatoire prédéfinie et les développements spécifiques au client dans l'espace de noms ABAP peuvent être exploités sans aucune restriction. Toutefois, l’entreprise doit organiser elle-même ou via des contrats de prestation de services distincts l’ensemble des tâches liées au dimensionnement du matériel, à la gestion du système d’exploitation, à l’administration de la base de données ainsi qu’au respect des normes complexes de conformité et de sécurité informatique.

La solution S/4 Cloud Private Edition (dans le cadre de Rise with SAP) vise à allier l'exhaustivité fonctionnelle du système sur site à la commodité d'un environnement cloud géré. D’un point de vue technique, il s’agit d’une instance isolée à locataire unique, dans laquelle l’hébergement est confié à SAP, mais où le client existant conserve des droits de participation étendus concernant le choix de l’hyperscaler spécifique (Azure, AWS, Google Cloud ou des fournisseurs européens) ainsi que de l’emplacement géographique précis du centre de données.

Cloud privé vs. sur site

L'éventail des fonctionnalités de la Cloud Private Edition couvre l'ensemble des 31 solutions sectorielles et des 39 versions linguistiques de l'environnement sur site. Certes, le client SAP existant bénéficie d’une stratégie de mise à niveau nettement plus flexible que dans le cloud public et peut reporter les mises à jour du système au sein de la fenêtre de maintenance standard, mais il reste soumis aux contraintes infrastructurelles imposées par SAP. Le dimensionnement de la mémoire de la base de données HANA et des serveurs d’applications est directement lié au volume de FUE souscrit. Si un système nécessite davantage de mémoire vive en raison d’analyses en mémoire complexes sans augmentation du nombre d’utilisateurs, il faut alors acquérir des licences supplémentaires pour des modules d’extension d’infrastructure coûteux.

En revanche, la version S/4 Cloud Public Edition (dans le cadre du programme « Grow with SAP ») représente le concept cloud le plus radical. En tant que véritable modèle SaaS multi-tenant, il offre les coûts d'exploitation spécifiques les plus bas pour l'infrastructure informatique, car les mises à jour logicielles, les correctifs de sécurité et l'évolutivité de l'infrastructure sont gérés de manière entièrement automatique par SAP en arrière-plan. Le cœur fonctionnel évolue automatiquement au gré des mises à jour semestrielles de SAP.

Modifications d'Abap

Cependant, le cloud public exige une soumission absolue au principe du « Clean Core ». Les développements Z classiques, les modifications d’objets SAP standard ou les accès en écriture directe aux tables de base de données sont techniquement impossibles. Les entreprises disposant de processus de fabrication spécialisés, de traitements spécifiques développés au fil du temps ou d’intégrations complexes avec des systèmes tiers se heurtent rapidement à des obstacles insurmontables dans l’édition publique. Cela explique pourquoi, selon les rapports d’investissement de la DSAG, une écrasante majorité des clients existants bien établis dans la région DACH continue de rejeter le cloud public pour leur cœur de métier ERP et opte plutôt pour des scénarios sur site ou de cloud privé contrôlé.

La communication stratégique de la direction du groupe SAP a connu une évolution remarquable : lors de la conférence internationale des clients „ Sapphire 2026 “ à Orlando, l’architecture « North Star » de la SAP Business Suite 7 classique, vantée pendant des années, a été progressivement abandonnée. Elle a été remplacée par la vision spectaculaire de la « SAP Autonomous Enterprise ». Dans cette nouvelle perspective centrée sur l’IA, S/4 HANA ne s’avère en aucun cas être le point d’aboutissement de l’évolution des ERP, mais simplement le socle de données transactionnelles indispensable et une étape intermédiaire tout à fait nécessaire. Le cœur de l’ERP classique est relégué au rang de simple « système d’enregistrement », fonctionnant en arrière-plan comme un serveur de comptabilisation fiable, tandis que le traitement proprement dit des processus et l’interaction avec l’utilisateur sont transférés vers des couches d’intelligence superposées.

L'interface utilisateur Joule Work, associée à la suite SAP Autonomous, constitue le visage opérationnel de cette nouvelle ère. Au lieu d'avoir à ouvrir des centaines de vignettes Fiori ou à saisir des codes de transaction complexes, les collaborateurs décrivent leurs intentions métier en langage naturel. En arrière-plan, plus de 50 assistants Joule spécifiques à chaque domaine et plus de 200 agents IA spécialisés orchestrent des processus autonomes de bout en bout dans les domaines de la finance, des achats, de la chaîne d’approvisionnement et des ressources humaines. Un assistant autonome tel que l„“ Autonomous Close Assistant „ se charge ainsi de l’analyse autonome des écarts, du rapprochement des comptes et de la préparation de la clôture mensuelle, tandis que l’humain, dans le cadre d’une approche “ Human in the Loop », n’intervient plus que dans des situations exceptionnelles insolubles.

Le SAP Knowledge Graph fait office de « cerveau sémantique » indispensable pour permettre à ces agents IA de comprendre le modèle de données historiques complexe de SAP (basé sur SQL Server), composé de plus de sept millions de champs de données et de dizaines de milliers de tables. Le Knowledge Graph traduit automatiquement les tables de bases de données relationnelles en ontologies lisibles par machine et en un modèle de réseau composé de nœuds et d’arêtes. Il fournit aux modèles linguistiques et aux agents IA le contexte métier précis – par exemple, la signification des réseaux de relations entre les commandes clients, les données de base des articles, les factures et les appels de livraison – afin de supprimer efficacement les hallucinations stochastiques dans le grand livre, élément critique pour l’activité.

Graphique des connaissances SAP

L'affirmation selon laquelle les agents d'IA et le SAP Knowledge Graph pourraient à l'avenir rendre un système ERP classique totalement superflu ne résiste toutefois pas à un examen analytique : un système ERP reste irremplaçable, car les fonctions de gestion d'entreprise essentielles, telles que la comptabilité financière, la conformité fiscale, la comptabilité analytique et l'établissement de bilans conformes à la législation, exigent une exactitude absolue et déterministe.

Les modèles linguistiques reposent sur des calculs probabilistes ; les principes fondamentaux de la théorie de l'information démontrent qu'une IA stochastique ne peut jamais garantir une absence totale d'erreurs. Si un agent d’IA probabiliste agissait sans la logique fondée sur des règles d’un noyau ERP déterministe, les écarts les plus infimes conduiraient déjà à des écritures comptables juridiquement irrecevables ou à des validations de production erronées. S/4 Hana et l’ERP cloud restent ainsi le fondement mathématique indispensable sur lequel repose l’autonomie cognitive des agents d’IA en tant que couche de contrôle.

La perspective à long terme du cloud computing dans l'environnement SAP est de plus en plus dominée par des questions de résilience géopolitique, de sécurité juridique et de prévention d'une dépendance irréversible vis-à-vis des éditeurs. Alors que SAP exerce une pression considérable sur ses clients existants pour les pousser vers des structures cloud propriétaires, les contrats officiels ne prévoient toujours pas de stratégie de sortie du cloud qui soit techniquement et commercialement réalisable.

Sortie du cloud et de l'IA

Quiconque a converti ses licences d'achat sur site existantes en abonnements cloud dans le cadre d'une conversion de contrat détruit irrémédiablement ses immobilisations historiques. Une sortie du cloud SAP laisse le client avec des données brutes nues, sans valeur sans les algorithmes propriétaires du cloud et les environnements d'exécution.

L'absence de stratégie de sortie en matière d'IA est encore plus préoccupante : Comme SAP ne dispose pas de compétence clé propre dans le domaine des modèles cognitifs de base et s'appuie principalement sur des pionniers américains tels qu'Anthropic (avec le modèle Claude), les utilisateurs européens se retrouvent extrêmement vulnérables face aux décisions géopolitiques prises par des gouvernements étrangers.

Dans ce contexte délicat, le cadre juridique de l’Union européenne – notamment la loi européenne sur les données (EU Data Act), publiée au Journal officiel le 22 décembre 2023 – offre une lueur d’espoir importante pour le rétablissement de la souveraineté numérique. L’« EU Data Act » vise à faciliter le changement de fournisseur de services cloud et à interdire légalement les barrières artificielles au changement, les frais de transfert de données excessifs ainsi que les clauses contractuelles abusives.

Même si les contrats types concrets de l'UE et les dispositions techniques d'application pour les environnements ERP complexes sont encore en cours d'élaboration, la législation européenne oblige de plus en plus les fournisseurs tels que SAP à mettre à disposition des interfaces ouvertes et des mécanismes standardisés de portabilité des données. Cette évolution réglementaire s’accompagne d’initiatives lancées par des fournisseurs d’infrastructures européens tels que StackIT (l’hyperscaler européen du groupe Schwarz), qui proposent des charges de travail Rise en conformité avec le droit européen et sans s’exposer au risque lié au Cloud Act américain.

Pour élaborer concrètement une stratégie de sortie du cloud et de découplage pérenne, les entreprises utilisatrices doivent miser sur des normes architecturales modernes et indépendantes des éditeurs : Au lieu de programmer de manière rigide des algorithmes spécifiques à chaque client dans la plateforme BTP propriétaire ou de se limiter exclusivement au SAP Knowledge Graph, la mise en place d’une „ Enterprise Semantic Backbone “ indépendante des éditeurs s’impose désormais.

Grâce à des formats standard ouverts du W3C tels que le Resource Description Framework (RDF) et le langage de requête SPARQL, les entreprises peuvent modéliser de manière autonome leurs ontologies métier et leurs relations entre données sur des plateformes open source souveraines (telles que SUSE Rancher, SUSE AI ou Red Hat OpenShift).

Le Model Context Protocol (MCP), indépendant des fabricants, joue également un rôle absolument essentiel dans le fonctionnement découplé des agents d'IA. En tant que norme ouverte – comparable à un port USB-C universel pour les systèmes d’IA –, le MCP établit une séparation claire entre les modèles linguistiques et le cœur transactionnel de l’ERP. Grâce à des serveurs MCP découplés (tels que ceux fournis par des fournisseurs comme Boomi, Suse ou par des communautés open source), les agents IA peuvent accéder aux données S/4 de manière sécurisée, contrôlée et entièrement vérifiable, sans que le client SAP existant ne tombe dans le piège incalculable des licences de la politique d’API SAP.

Pour le Centre d'expertise client (CCoE) et la direction informatique d'un client SAP existant, la conclusion de cette analyse est la suivante : „ Tirez parti des avantages techniques du cloud et de l'intelligence artificielle là où ils apportent une réelle valeur ajoutée sur le plan économique. Tout en conservant toutefois un contrôle strict sur votre architecture système. En rationalisant systématiquement votre cœur de métier avec SAP Clean Core, en optimisant vos licences en termes de droits d’accès avant chaque signature de contrat, en misant sur des fondements de cloud hybride open source tels que Red Hat et en découplant vos structures de données via des normes ouvertes comme MCP et RDF, vous vous assurez un avenir ERP pérenne, agile et souverain sur le plan numérique, sur un pied d’égalité avec l’éditeur. “