Le coût de l'IA pour un client SAP existant

Fin de commercialisation des licences « on-prem » et des frais liés au moteur

Lorsque Christian Klein, PDG de SAP, proclame haut et fort que le modèle d’abonnement classique est absurde à l’ère de l’intelligence artificielle, cela devrait immédiatement faire sonner l’alarme chez tous les clients existants de SAP. Le raisonnement de M. Klein repose sur l’hypothèse selon laquelle une facturation basée sur le nombre d’utilisateurs humains (user-based) deviendrait obsolète à l’ère de l„“ Autonomous Enterprise », car des agents d’IA hautement sophistiqués automatiseraient en grande partie le travail manuel effectué par les humains dans le système ERP et réduiraient considérablement les besoins en personnel des entreprises. Si, à l’avenir, une poignée d’opérateurs d’IA suffit à piloter le système au lieu d’une centaine d’employés, le modèle de licence traditionnel basé sur les Full Use Equivalents (FUE) s’effondre pour l’éditeur de logiciels de Walldorf. Afin d’éviter cette cannibalisation imminente de ses propres revenus, SAP promeut un changement de paradigme commercial radical vers un modèle de « paiement à l’utilisation de l’IA » et des modèles de facturation axés sur les résultats.

Paiement à l'utilisation de l'IA et coût total de possession (TCO)

Ce qui, à première vue, semble être une tarification équitable et fondée sur les avantages se révèle pourtant, après un examen analytique approfondi, être un instrument habilement conçu pour monétiser au maximum les flux de données et les processus, dans lequel le coût total de possession (TCO) des clients est destiné à atteindre des sommets astronomiques.

Dans ce nouveau réseau commercial, deux philosophies fondamentales en matière de facturation s'opposent : le modèle d'abonnement traditionnel et le modèle de facturation à l'utilisation.

Dans le cadre d'un abonnement classique, le client SAP existant paie un forfait mensuel ou annuel fixe, calculable à l'avance, pour des packs de services définis. L'avantage pour l'utilisateur du cloud réside dans une sécurité de planification absolue ; l'inconvénient majeur réside dans le risque de „ shelfware “, c'est-à-dire de payer pour des capacités inutilisées.

En revanche, le modèle « Consumption » – tel qu’il est mis en œuvre sur la SAP Business Technology Platform (BTP) via le Cloud Platform Enterprise Agreement (CPEA) ou le plus récent BTP Enterprise Agreement (BTPEA) – une agilité maximale et une évolutivité adaptée aux besoins, dans le cadre de laquelle le client SAP existant dispose d’un compte de crédit de type prépayé.

Pourtant, pour un client SAP établi et autonome, le modèle de consommation n’est en aucun cas meilleur en soi que l’abonnement. Alors que l’abonnement garantit des budgets informatiques prévisibles, le modèle basé sur la consommation exerce une pression permanente sur les services métier en matière de retour sur investissement. Comme pratiquement aucune entreprise ne peut estimer avec précision à l’avance le nombre de transactions dont un algorithme d’IA aura réellement besoin pour répondre à une question, la budgétisation dans le cadre d’une stratégie purement basée sur la consommation devient rapidement un saut dans l’inconnu financier, impossible à calculer, au cours de l’exploitation courante.

Compte tenu des investissements considérables réalisés dans l'IA par SAP, OpenAI, Oracle, Anthropic, etc., et des frais et prix des jetons actuellement très bas, la question se pose légitimement : j'ai dépassé ma limite sur Claude d'Anthropic et j'ai dû racheter des jetons à un prix élevé. J’ai posé la question à Claude et l’IA m’a répondu que, selon un calcul des coûts complets, cela restait tout de même avantageux pour moi, car mon abonnement Claude à 200 dollars correspondait à peu près à une valeur de 75 000 dollars américains. La différence est pour l’instant subventionnée et tous les fournisseurs d’IA enregistrent des pertes !

Abonnement ou paiement à l'utilisation

Les pièges financiers de ce modèle de consommation sont multiples et menacent la stabilité financière de l'infrastructure informatique des utilisateurs SAP non préparés. Il convient tout d’abord de mentionner le principe insidieux d’expiration des crédits cloud achetés à l’avance. Les clients existants doivent s’engager, dans le cadre de contrats tels que le BTPEA, à respecter des volumes d’achat annuels minimaux.

Le détail perfide : les crédits cloud non utilisés expirent sans compensation à la fin de chaque année contractuelle, ce qui crée une pression commerciale énorme poussant à consommer frénétiquement les services pour ne pas gaspiller d'argent. D'autre part, à l'autre extrémité du spectre de consommation, se profile la redoutable „ facture cloud choc “.

Facture exorbitante liée au cloud

Dès que le contingent de crédits cloud prépayé est épuisé, SAP frappe sans pitié et facture tout dépassement au prix catalogue extrêmement élevé, sans aucune remise. Le modèle « Pay-As-You-Go » (PAYG), qui semble flexible, s’avère en réalité être une arnaque commerciale, car les frais de service qui y sont associés ne donnent droit à aucune remise dès le départ et constituent donc, en cas d’utilisation évolutive au quotidien, de loin le mode d’exploitation le plus coûteux.

Le jeton LLM et SAP BTP GenAI Hub

Un troisième facteur de coût, souvent totalement sous-estimé, est la consommation massive de jetons par les grands modèles linguistiques au sein du Generative AI-Hub de la BTP. Contrairement aux logiciels déterministes, les grands modèles linguistiques fonctionnent de manière probabiliste. Lorsque l'on lance des invites complexes et itératives ou que l'on fait appel à des agents IA qui, dans le cadre d'architectures RAG (Retrieval-Augmented Generation), explorent d'énormes fenêtres contextuelles, les coûts liés aux API explosent en un rien de temps.

En raison du phénomène dit „ Lost in the Middle “, dans lequel les modèles linguistiques négligent et ignorent purement et simplement les informations contenues dans la partie centrale des longs textes, il est souvent nécessaire de lancer plusieurs requêtes de recherche affinées, ce qui fait grimper le compteur de tokens à l’insu de l’utilisateur, en arrière-plan. Chaque requête adressée à un copilote tel que Joule ou à un agent BTP coûte de l’argent. Si, au final, un expert humain doit tout de même contrôler et valider laborieusement chaque réservation effectuée par l’IA, conformément au principe „ Human in the Loop “, la pertinence économique de cette approche statistique de type « boîte noire » est remise en question plus que jamais sous la pression permanente de l’explosion des frais liés aux jetons.

Politique relative à l'API SAP et accès numérique

SAP a érigé une barrière douanière numérique par le biais de sa nouvelle politique restrictive en matière d’API. Sous prétexte de préoccupations sécuritaires, le groupe SAP, basé à Walldorf, restreint rigoureusement l’accès direct aux données des agents d’IA externes fournis par des tiers sur les systèmes SAP critiques pour l’activité. Quiconque souhaite extraire des données ERP précieuses afin de les analyser à l'aide des outils d'IA des hyperscalers se heurte à un blocage et est contraint de recourir à l'écosystème propriétaire et coûteux de BTP et du SAP Business Data Cloud (BDC).

Ce cloisonnement porte gravement atteinte au principe éprouvé de l„“ accès numérique ». Désormais, ce n’est plus l’utilisateur humain qui fait l’objet d’une licence, mais le nombre brut de pièces comptables créées dans des sources non SAP et importées dans le cœur de système SAP, ce qui peut entraîner des paiements supplémentaires catastrophiques en cas de planification incomplète. Les prix catalogue pour ce volume de documents étant fixés à des niveaux absurdement élevés, SAP tente d’attirer les clients vers ce nouveau modèle à l’aide de programmes de remises à durée limitée, tels que le Digital Access Adoption Program (DAAP), afin de les lier ensuite de manière permanente, par contrat, au comptage des documents.

Au final, les licences de base de données Hana, coûteuses mais obligatoires sur la plateforme BTP, rendent d'emblée non rentables les développements d'applications « low-code » simples et innovantes destinés aux PME.

SAP Autonomous Enterprise

Lorsque le client SAP existant se demande ce que coûte concrètement cette « Autonomous Enterprise » tant vantée, il se heurte à un enchevêtrement opaque de tarifs peu transparents et de dépendances techniques. Il n’existe pas de forfait simple pour l’intelligence autonome. La structure des coûts se compose plutôt d’une multitude d’éléments : outre les coûts de base liés à la transformation vers le cloud (Rise with SAP), il faut acquérir des licences supplémentaires pour l’infrastructure de la plateforme BTP. Les scénarios d’IA intégrée prêts à l’emploi et les notifications Joule sont certes formellement inclus en faibles quantités dans certains abonnements cloud, mais dès que ces limites sont dépassées, SAP exige l’achat coûteux de ce qu’on appelle des « AI-Units ».

Centre de découverte SAP

La conversion de ces monnaies virtuelles en euros réels dépend de contrats négociés au cas par cas, ce qui étouffe toute transparence dans l'œuf. Un exemple de calcul concret issu du SAP Discovery Center illustre la structure tarifaire : la création automatisée d’un rapport ESG à l’aide d’une IA générative, sur la base de la SAP Sustainability Control Tower, représente, pour un rapport de 100 pages, un coût de douze unités d’IA, ce qui, avec un prix unitaire fictif de 7 euros, représente un coût mensuel de 84 euros, soit 1 008 euros par an, rien que pour cette fonctionnalité.

De plus, d’autres coûts cachés se cachent dans les recoins de cette nouvelle architecture. Le BDC, que les détracteurs de l’association d’utilisateurs DSAG qualifient à juste titre de „ Business Data Complexity “ , oblige les entreprises à répliquer leurs données historiques dans une architecture « lakehouse » coûteuse afin de pouvoir accéder aux services d’IA modernes, ce qui revient de facto à une taxe ruineuse sur la duplication des données.

Piège : conversion des contrats SAP

La migration classique vers S/4 comporte elle aussi des risques financiers considérables : outre la hausse spectaculaire des frais de maintenance pour les anciens systèmes ECC, SAP exige, dans le cadre d’une maintenance étendue jusqu’en 2030, une majoration substantielle de 2 % sur les frais de maintenance existants, ce qui correspond en réalité à une augmentation cachée des prix d’environ 9 %. Quiconque signe ces contrats sans s’y être préparé et convertit ses licences via une „ conversion de contrat “ perd tous ses anciens droits sur ses licences Onsur site, passe à un contrat de location pur et permanent et se retrouve confronté à des majorations de prix allant de 20 à 50 %.

Gouvernance avec un centre d'expertise client (CCoE)

Pour se prémunir contre une explosion incontrôlée des coûts dans ce champ de mines commercial extrêmement complexe, les clients SAP existants doivent mettre en place une gouvernance technique et organisationnelle rigoureuse. En tant qu’instance de contrôle fondamentale, le Customer Center of Expertise (CCoE) ou la gestion des actifs informatiques doit être transformé en un centre stratégique FinOps chargé de surveiller la consommation des crédits cloud, d’unités d’IA et de jetons non seulement lors de la conclusion du contrat, mais aussi en tant que tâche de pilotage continue tout au long de la durée du contrat.

Lors de leurs négociations avec SAP, les clients existants de SAP ne devraient jamais commencer par des forfaits de crédits cloud (BTPEA) trop importants afin d’éviter efficacement la perte définitive des crédits à la fin de l’année, mais plutôt commencer par de petits volumes. De plus, un nettoyage approfondi des données de base et des données de mouvement (cleansing), ainsi que la mise hors service des anciens systèmes dans le respect de la législation, sont indispensables pour réduire au minimum le trafic de données et les besoins en mémoire centrale, qui représentent des coûts inutiles. De même, les autorisations dans le système doivent être restructurées de manière cohérente selon le principe du „ droit minimal “, car les outils d’évaluation des systèmes SAP tels que STAR classifient parfois à tort certains utilisateurs en fonction des autorisations de rôle qui leur sont attribuées plutôt qu’en fonction de leur utilisation réelle, ce qui entraîne un surlicenciamento massif et évitable. Enfin, avant tout audit, une analyse minutieuse de toutes les interfaces avec les systèmes non-SAP est impérative afin de bloquer les paiements imprévus liés à l’accès numérique et de stipuler contractuellement les transferts de données gratuits, tels que la « lecture statique indirecte » (Indirect Static Read).

Les développeurs d'IA devraient veiller, au niveau de la base SAP, à limiter systématiquement la consommation de jetons des modèles linguistiques grâce à des techniques de « grounding » telles que l'optimisation de la taille des blocs RAG, la mise en cache des prompts et un prétraitement conforme à la protection des données sur SAP AI Core, de réduire systématiquement la consommation de tokens des modèles linguistiques, afin que l’intelligence artificielle ne finisse pas par ruiner la viabilité économique de l’entreprise.