L'argent fait tourner le monde

La transformation numérique des processus clés de gestion d'entreprise est inlassablement célébrée par le groupe de logiciels SAP de Walldorf comme un paradis ERP sans limites, agile et basé sur le cloud, mais une analyse critique des réalités contractuelles révèle que cette promesse est un carcan stratégique très complexe qui pousse les clients existants de SAP dans un vendor lock-in sans précédent.

Au cœur de ce déplacement tectonique se trouve le changement de paradigme du modèle classique sur site, basé sur la propriété, vers un modèle de souscription au cloud, accompagné d'une liste de prix et de conditions (PKL) opaque, de nouvelles restrictions API et d'une monétisation rigoureuse des flux de données.

Pour le client SAP existant, le passage à S/4 Hana ne signifie plus depuis longtemps une mise à niveau technique de la version, mais une réorientation fondamentale de son architecture informatique commerciale, avec le risque permanent d'une explosion des coûts, d'un octroi excessif de licences et d'une perte totale de souveraineté numérique. Celui qui ne déconstruit pas dans les moindres détails les mécanismes de l'abonnement au cloud SAP, de la Business Technology Platform (SAP BTP), du Business Data Cloud (SAP BDC) et des nouvelles métriques de licence sera inévitablement victime d'une machine à monétiser orchestrée de main de maître.

La transition historique vers le monde du cloud de SAP, principalement sous l'impulsion des contrats globaux Rise et Grow, marque le passage complexe d'une dépense d'investissement (Capex) à une dépense d'exploitation courante (Opex) pour l'utilisateur ERP. Alors que les licences sur site étaient acquises en tant que propriété perpétuelle et garantissaient un droit d'utilisation légitime et continu du système, même en cas de résiliation des contrats de maintenance, l'abonnement au cloud réduit le client au rang de locataire sans défense.

SAP transforme les licences existantes sur site en souscriptions dans le cloud par le biais de la "Contract Conversion", ce qui entraîne la destruction irrémédiable des anciennes licences d'achat précieuses. L'instrument central de cette transformation est la métrique du Full Use Equivalent (FUE), un ensemble de règles très complexes qui comprime l'attribution détaillée des utilisateurs basée sur l'utilisation du monde ECC dans des types d'utilisation Cloud standardisés.

Un FUE sert d'unité de facturation, qui est répartie avec différents facteurs de pondération entre les types d'utilisateurs tels que Developer Access, Advanced Use, Core Use ou Self-Service Use. Le défi critique pour le client SAP existant réside ici dans la base de calcul : dans le nouveau monde S/4 Cloud, SAP n'accorde plus de licence en premier lieu en fonction de l'utilisation effective du logiciel, mais rigoureusement en fonction des autorisations attribuées dans le système.

Mesure basée sur l'autorisation

Comme les autorisations ont souvent été attribuées de manière extrêmement généreuse dans les paysages SAP R/3, R/3 Enterprise et ERP/ECC 6.0 (SAP Business Suite) qui se sont développés, cette mesure basée sur les autorisations conduit à un surplus massif de licences en cas de migration non préparée.

Des experts indépendants en matière de licences avertissent que la nouvelle métrique du cloud peut faire grimper les coûts de licence de 50 à 150 %, car même les utilisateurs occasionnels doivent soudain payer des licences professionnelles ou avancées onéreuses dès qu'ils se voient attribuer des rôles étendus par le système.

SAP tente d'aider les clients à classifier les données avec le service Star (S/4 Trusted Authorization Review), mais cet outil analyse de manière obtuse les objets d'autorisation et attribue automatiquement le type de licence le plus cher aux cas peu clairs, ce qui est considéré comme un piège financier dangereux pour les utilisateurs qui ne se doutent de rien.

La base contractuelle de ces constructions nuageuses est la liste des prix et conditions SAP, qui s'est transformée en un véritable labyrinthe juridique à l'ère du cloud. La PKL ne se compose plus seulement d'une simple liste de prix Excel et d'un document maître, mais se fragmente en un entrelacs inextricable de Cloud Supplements, de Service Description Guides, de Cloud AGBs et de Service Level Agreements (SLAs), qui deviennent tous des éléments indissociables de ce que l'on appelle le Order Form.

Suppléments Cloud toxiques

Les Cloud Supplements règlent en détail les restrictions d'utilisation, les métriques et les détails de provisionnement pour chaque service cloud. L'élément toxique est que SAP modifie et adapte ces documents et métriques tous les trimestres, ce qui rend impossible une budgétisation fiable et à long terme pour le directeur financier. Pour le client SAP existant, cela signifie qu'il est obligé d'archiver les suppléments du jour de manière juridiquement sûre à chaque conclusion de contrat ou à chaque renouvellement - ce que l'on appelle le renouvellement -, car SAP se réserve le droit de procéder à des ajustements de prix unilatéraux lors des prolongations de durée ou de tarifer soudainement séparément des fonctions autrefois incluses.

Les risques commerciaux sont encore plus évidents en ce qui concerne la Business Technology Platform, que SAP présente comme l'épine dorsale technique et la couche d'innovation essentielle de la stratégie Clean Core. C'est sur la BTP que doivent se faire à l'avenir toutes les extensions et intégrations personnalisées (Side-by-Side Extensibility), afin de maintenir le noyau numérique de S/4 Hana propre et apte à être mis à jour.

BTPEA et Cloud Bill Shock

L'octroi de licences pour les services BTP s'effectue en premier lieu par le biais de modèles de consommation basés sur la consommation, à savoir le Cloud Platform Enterprise Agreement (CPEA) ou le plus récent BTP Enterprise Agreement (BTPEA), dans le cadre desquels le client achète au préalable des "Cloud Credits". Le piège commercial de ces modèles réside dans la menace d'expiration des crédits achetés : Les crédits cloud non utilisés expirent sans exception à la fin de chaque année contractuelle, ce qui crée une pression extrême pour consommer effectivement les services afin de ne pas financer ce que l'on appelle des "shelfware".

En même temps, le redoutable Cloud Bill Shock guette en cas d'utilisation intensive. Dès que le contingent de Cloud Credits pré-acheté est épuisé, SAP facture sans pitié et sans rabais toute nouvelle utilisation excessive au prix catalogue. SAP propose également un modèle Pay-As-You-Go, qui n'exige certes pas de quantité minimale d'achat, mais pour lequel les frais de service ne peuvent pas faire l'objet d'une remise et qui représente donc, en cas d'utilisation évolutive, la plus chère de toutes les formes d'exploitation.

La gestion et le suivi de ces consommations BTP via le portail SAP-for-Me ou le BTP Cockpit sont critiqués par des associations d'utilisateurs comme la DSAG comme étant hautement insuffisants et peu transparents, car les évaluations granulaires des coûts au niveau des différents processus commerciaux font souvent défaut. L'image est tout aussi restrictive pour SAP Integration Suite, le successeur basé sur le cloud du middleware classique SAP PI/PO de la pile NetWeaver. L'octroi de licences pour cet outil d'intégration essentiel, indispensable pour relier les systèmes SAP et non-SAP, se base souvent sur des métriques telles que les tenants et les paquets de 10 000 messages chacun.

Le défi de gestion pour le client SAP existant réside dans la prévisibilité du volume de messages. Dans les paysages ERP modernes, pilotés par des événements (event-driven), et dans les scénarios IoT, le nombre de messages système à traiter explose souvent de manière incontrôlée. Étant donné que la suite d'intégration est provisionnée de manière centralisée via la BTP, il n'est guère possible d'imputer les prestations en interne à des domaines spécifiques, tandis que des pics de charge soudains consomment rapidement le crédit du cloud et entraînent des coûts supplémentaires incalculables.

Mais le sommet de la stratégie de monétisation de SAP se révèle dans le nouveau Business Data Cloud (SAP BDC) et la SAP Datasphere. Le BDC est vanté par le marketing SAP comme une base de données ouverte et harmonisée (Data Fabric) qui doit briser les silos de données SAP historiques et les fédérer avec des services hyperscaler comme Databricks ou Snowflake. Mais si l'on lit les petits caractères des contrats et des guides de description de service, la BDC se révèle être un système de poucettes restrictives que la DSAG raille avec justesse sous le nom de „Business Data Complexity“. SAP limite l'utilisation des données de manière extrêmement stricte. À chaque fois que les limites minimales sont dépassées, SAP se réserve le droit de sanctionner par des frais supplémentaires et sensibles. Ces barrières techniques et commerciales sévères contrecarrent complètement la promesse d'une culture de données ouverte et obligent les entreprises à limiter leurs analyses de données exactement en fonction des objectifs de volume coûteux.

Politique de l'API SAP

Cette tactique de cloisonnement a été renforcée par la nouvelle politique API très controversée publiée par SAP en avril 2026. Sous prétexte de préoccupations de sécurité et de stabilité du système, SAP réglemente désormais avec précision les conditions dans lesquelles les clients existants peuvent transférer leurs propres données dans des systèmes tiers.

La directive API interdit explicitement l'utilisation des API SAP à des fins non explicitement documentées et interdit les extractions systématiques de données de masse vers des entrepôts de données externes ou des data warehouses.
Lakes, dans la mesure où SAP n'a pas explicitement autorisé ce cas d'utilisation spécifique dans la documentation du produit.

Pour les clients SAP existants, c'est un coup fatal porté à leur propre souveraineté numérique. Ceux qui souhaitent à l'avenir extraire efficacement leurs données historiques S/4 pour les analyser avec des outils d'IA tiers ou sur des plateformes comme Microsoft Fabric seront de facto contraints de recourir aux solutions maison et coûteuses comme SAP Datasphere et SAP BDC en raison du blocage des interfaces performantes (comme ODP).

L'interdiction faite aux agents d'IA autonomes et génératifs de fournisseurs tiers est particulièrement explosive : les systèmes d'IA ne pourront plus accéder librement et de manière autonome aux données SAP via des API. SAP érige ici de fait une barrière douanière numérique où tout accès externe touchant à la souveraineté des données de Walldorf sera à l'avenir réglementé et presque certainement monétisé afin d'assurer un avantage concurrentiel artificiel à ses propres assistants IA, souvent en retard sur le plan technique, comme Joule.

Les restrictions de l'API se fondent parfaitement avec l'un des thèmes de licence les plus dangereux de l'histoire de SAP : l'utilisation indirecte et le modèle de prix Digital Access. À l'ère de l'industrie 4.0, de la Robotics Process Automation (RPA) et des chaînes d'approvisionnement en réseau, d'innombrables systèmes tiers accèdent au système ERP de manière automatisée. Avec Digital Access, SAP a créé un modèle de licence axé sur les résultats (outcome-based) qui ne compte plus l'utilisateur humain, mais le simple nombre de documents créés initialement dans des sources non SAP et importés dans le noyau SAP. Les prix catalogue pour ce volume de documents sont astronomiquement élevés, c'est pourquoi SAP doit attirer les clients dans le nouveau modèle avec des programmes de rabais (Digital Access Adoption Program, DAAP) allant jusqu'à 90%.

Mais ces rabais sont une illusion contractuelle : une fois qu'une entreprise a opté pour l'accès numérique, il n'est plus possible de revenir à l'ancien monde basé sur l'utilisateur, potentiellement plus économique. La charge de la preuve pour le comptage correct des documents, par exemple la distinction entre une nouvelle création soumise à une licence et une lecture sans licence (Indirect Static Read), est souvent entièrement reportée sur le client par des outils de mesure insuffisants comme l'outil SAP Passport. Tout agent d'intelligence artificielle externe ou capteur IoT qui créera à l'avenir des commandes de manière autonome dans S/4 Hana fera grimper les compteurs de Digital Access et entraînera des demandes de remboursement sans une gouvernance stricte.

Stratégie de sortie du cloud

Mais le danger ultime du modèle d'abonnement au cloud de SAP se révèle à la fin : il n'y a tout simplement pas de stratégie de sortie du cloud native et garantie par contrat de la part de SAP. Les contrats tout-en-cloud sous Rise with SAP fonctionnent comme une fonction mathématique de trappe - une voie stratégique à sens unique. Comme le client a dû renoncer irrémédiablement à ses licences sur site à durée indéterminée lors de la conversion du contrat, il se retrouve les mains vides à la fin de la durée du contrat cloud. Si une entreprise utilisatrice ne peut ou ne veut plus payer les frais d'abonnement onéreux, le droit d'accès au logiciel s'éteint instantanément.

Cette asymétrie place SAP dans une position de monopole absolu à chaque renouvellement de contrat (renewal), ce qui permet au groupe d'imposer sans pitié des augmentations de prix unilatérales et des métriques moins favorables, sans que le client ait une possibilité réaliste de changer.

De même, les efforts juridiques de l'Union européenne par le biais de l'EU Data Act, qui vise à briser les effets de verrouillage du cloud et à imposer la portabilité des données, sont en grande partie vains dans la pratique ERP, car la loi réglemente certes la sortie technique des données, mais ne résout pas le problème de l'absence de licences d'application pour le traitement ultérieur des données.

Transparence et optimisation

Face à ce terrain commercial miné, le magazine E3 a déjà formulé à plusieurs reprises, en accord avec des experts indépendants en matière de licences et DSAG, des recommandations drastiques mais essentielles pour chaque client SAP existant : La priorité absolue est la transparence absolue et l'optimisation de son propre paysage de licences avant de signer un contrat Rise-with-SAP ou Cloud. Le chemin vers le cloud ne doit en aucun cas être emprunté avec des charges historiques et des shelfware (logiciels sur étagère) inutilisés.

Les clients existants de SAP doivent reprendre le contrôle de leurs structures d'utilisateurs et d'autorisations. Étant donné que la future métrique dans S/4 est basée sur les autorisations attribuées et non plus sur l'utilisation pure, une refonte des rôles SAP doit impérativement être effectuée avant l'application du propre Star-Service de SAP.

Il est vivement recommandé de recourir à des outils indépendants de gestion des actifs logiciels (SAM) de fournisseurs spécialisés tels que USU, Snow, Flexera ou Dynamic License Control, qui simulent l'utilisation réelle et indiquent quels objets d'autorisation coûteux peuvent être éliminés dans les rôles afin d'éviter un classement fatal dans les licences professionnelles onéreuses. Si l'on fait le ménage en amont, on peut réduire massivement le besoin final en FUE pour le cloud.

La rédaction de l'E3 met en garde contre la conversion prématurée de ses propres licences d'achat on-prem à durée illimitée au modèle de souscription en nuage (Contract Conversion). Dans la mesure où cela est encore possible et judicieux d'un point de vue contractuel, il convient d'insister sur une conversion de produit qui garantit le maintien du stock de licences et des anciens droits d'utilisation spéciaux.

Pour les entreprises qui aspirent à l'exploitation en nuage, mais qui souhaitent conserver leur souveraineté numérique, il est recommandé d'opter pour le modèle Bring-Your-Own-License (BYOL) sur l'infrastructure d'un hypercalculateur neutre (IaaS) ou chez Green Lake de Hewlett Packard Enterprise. Dans ce cas, le client SAP reste juridiquement propriétaire des licences logicielles et peut, en cas d'insatisfaction, changer de fournisseur d'hébergement ou transférer à nouveau les licences dans son propre centre informatique (Private Cloud On-premises).

Les pièges du BTP et de l'utilisation indirecte doivent être négociés avec minutie. Lors de l'utilisation du BTP Enterprise Agreement (BTPEA), les entreprises ne devraient jamais commencer avec des paquets de crédits cloud trop importants, car les volumes non utilisés expirent inévitablement à la fin de l'année. Il est préférable de commencer par de petits volumes ou de recourir à des modèles de souscription sûrs pour des services clairement définis et nécessaires à long terme (comme la suite d'intégration).

En ce qui concerne l'accès numérique, les entreprises doivent analyser avec précision l'architecture de leur système et toutes les interfaces avec les systèmes non-SAP avant un audit. Chaque transfert de données ne déclenche pas automatiquement un comptage de documents ; des fonctions telles que l'Indirect Static Read doivent rester définies de manière étanche dans le contrat comme étant gratuites.

Précision médico-légale

Lors de la lecture des contrats SAP, il faut faire preuve d'une précision quasi médico-légale. Un contrat SAP Cloud n'est pas terminé sur le formulaire de commande. Les clients existants de SAP doivent télécharger, lire et archiver physiquement les Cloud Supplements et les Service Description Guides valables au jour le jour à partir du SAP Trust Center, car ce sont précisément ces documents qui définissent les métriques dures, les restrictions (comme la limitation à 2000 appels OData API dans le BDC) et les Support Level Agreements. Comme SAP modifie régulièrement ces liens et ces documents, il est vain de vouloir apporter des preuves ultérieures en cas de litige sur les licences sans un solide archivage personnel.

Le décideur informatique critique doit comprendre que le modèle actuel de cloud SAP et de licence ERP ne sert en aucun cas en premier lieu à libérer le client, mais qu'il s'agit d'un réseau commercial magistralement construit pour maximiser et pérenniser les revenus de SAP.

Celui qui se fie aux présentations Rise-with-SAP sans stratégie informatique fondée, sans conseil juridique externe et sans outils de licence indépendants, tombera inévitablement dans un piège de coûts qui fera grimper le coût total de possession de manière ruineuse pendant des années et qui mettra durablement sa propre entreprise sous perfusion du géant des logiciels.

Aujourd'hui, la souveraineté numérique du client SAP existant ne peut plus être assurée par une confiance aveugle dans la feuille de route de SAP, mais exige une responsabilité personnelle radicale, une compréhension technique et contractuelle approfondie ainsi que la volonté de traiter le leader mondial de l'ERP d'égal à égal et avec la plus grande fermeté lors de chaque négociation de licence.