Disruption de l'API SAP

Gestion de l'architecture de l'API SAP

Dans la mesure où la gestion de l'architecture API ne correspond pas exactement au schéma ERP prévu par SAP, les clients existants de SAP sont confrontés à des restrictions et des limitations considérables. Il est particulièrement alarmant de constater que, par le passé, de nombreux utilisateurs et partenaires ont dû recourir à des interfaces non documentées, mais longtemps tolérées par SAP, faute d'alternatives. Leur utilisation devient maintenant soudainement contraire au contrat et détruit des modèles commerciaux qui fonctionnent.

Open Data Infrastructure Scorecard (ODI) a examiné de manière critique la volonté des fournisseurs de logiciels en nuage de permettre à leurs clients d'accéder librement à leurs propres données d'entreprise. Dans ce type d'évaluation, SAP obtient traditionnellement de très mauvais résultats, car le groupe érige de plus en plus de barrières propriétaires, bloque l'accès direct aux bases de données et bloque de manière ciblée les interfaces performantes pour l'extraction de données par des fournisseurs tiers.

ODI-Scorecard confirme impitoyablement cette image, car SAP interdit le chemin direct de S/4 vers des entrepôts de données externes comme Microsoft Fabric et bloque l'interface efficace ODP (Operational Data Provisioning) pour l'extraction de données en masse par les concurrents. Cette politique architecturale restrictive oblige de facto les clients à utiliser les outils d'intégration coûteux propres à SAP, ce qui est diamétralement opposé à l'idée de base d'une infrastructure de données ouverte et cimente un vendor lock-in dur comme fer.

Doctrine API pour SAP BTP, SAP BDC et SAP Integration Suite

Pour les clients existants de SAP, cette doctrine API restrictive signifie qu'ils doivent faire preuve d'une extrême prudence lorsqu'ils utilisent la Business Technology Platform (SAP BTP), le Business Data Cloud (SAP BDC ou, selon l'association d'utilisateurs DSAG, Business Data Complexity) et la SAP Integration Suite. Le blocage de l'extraction directe de données de masse vers des Data Lakes externes oblige les utilisateurs à utiliser les solutions SAP BDC ou Datasphere, ce qui donne l'impression que SAP a érigé une barrière douanière fermée pour le flux de données numériques.

Certes, SAP positionne la BDC comme un écosystème de données ouvert avec une technologie de copie zéro via des partenaires comme Databricks, mais les petits caractères des conditions générales révèlent des pièges massifs, car l'utilisation d'API SAP pour l'extraction de données dans des logiciels non SAP est explicitement interdite, sauf si cela a été expressément documenté comme une fonction de l'API (voir aussi SAP Digital Access). Lors de la planification de l'architecture sur le BTP, les clients doivent veiller scrupuleusement à orchestrer exclusivement des interfaces validées, ce qui augmente drastiquement les efforts de développement pour les processus individuels de bout en bout et freine massivement l'agilité entrepreneuriale dont l'entreprise a tant besoin (voir aussi le concept de clean core SAP).

Si l'on considère d'un œil critique les licences et les conditions de licence pour SAP API et SAP BDC, on découvre un modèle commercial hautement toxique au détriment des clients existants. Le modèle d'accès numérique établi par SAP fait déjà payer depuis des années la création indirecte de documents par des systèmes tiers, ce qui risque maintenant de dégénérer complètement avec la nouvelle politique API à l'ère de l'IA, lorsque des agents IA autonomes lisent et écrivent des données en masse.

Utilisation équitable pour la complexité des données commerciales (SAP BDC)

L'association d'utilisateurs DSAG craint une commercialisation insidieuse et exige des modèles transparents d'utilisation équitable pour l'accès aux API, faute de quoi les coûts de la transformation numérique augmenteront de manière incommensurable. Dans le cas de SAP Business Data Cloud (BDC), les conditions d'utilisation cachent en outre des restrictions contractuelles flagrantes, comme par exemple des limitations sévères à seulement 2000 appels à l'API OData par gigaoctet de mémoire de calcul par mois, ce qui peut entraîner des frais supplémentaires incalculables à chaque dépassement.

De plus, SAP classe les services BDC Connect importants dans le soi-disant groupe 2 des services de capacité, ce qui fait que le groupe se réserve le droit de supprimer ces services sans les remplacer avec un préavis de six mois, ce qui annule toute sécurité d'investissement à long terme pour l'utilisateur dans le domaine de l'infrastructure de données.

Face à ces pouces en l'air, les clients existants de SAP doivent de toute urgence évaluer des alternatives indépendantes pour la gestion des API et l'intégration des données. Au lieu de s'en remettre aveuglément à SAP BDC et à SAP Integration Suite, les fournisseurs indépendants de plateformes d'intégration en tant que services (iPaaS) comme Boomi offrent des échappatoires décisives pour gérer les API de manière flexible, rentable et sans la contrainte des développements Abap propriétaires.

Boomi et JiVS : des alternatives à SAP BTP et BDC

Boomi permet d'acheminer les données vers n'importe quel cloud data lake, indépendamment du réseau, sans devoir se soumettre à la stricte hégémonie des données de Walldorf. Pour la gestion des anciennes données historiques et la préservation de la souveraineté des données à l'écart de l'infrastructure coûteuse de SAP, des plateformes comme JiVS de Data Migration International se positionnent en outre comme une alternative précieuse pour gérer l'héritage de l'ère ERP conformément à la législation et pour soulager durablement le noyau S/4.

Néanmoins, le problème fondamental demeure : les outils externes dépendent eux aussi des API sévèrement réglementées par SAP, ce qui oblige les fournisseurs alternatifs à chercher de plus en plus des moyens créatifs, mais juridiquement sécurisés, pour compenser l'interface ODP bloquée par SAP.

Clean Core, une feuille de vigne nécessaire

Si la gestion des API SAP dans un environnement S/4 Cloud doit néanmoins être organisée strictement selon la doctrine Clean Core de SAP, cela nécessite une transformation organisationnelle et technique radicale au sein du Customer Center of Expertise (CCoE) du client existant. Le CCoE passe du statut de simple administrateur opérationnel de base à celui d'instance de gouvernance stratégique, qui doit surveiller implacablement chaque appel d'API et chaque extension de BTP.

Dans le cadre du modèle Clean-Core strict, seules les API listées en blanc (niveau A), mises à disposition via le SAP Business Accelerator Hub et obligatoirement orchestrées via SAP Integration Suite, peuvent être utilisées pour des extensions côte à côte sur la BTP. Toute modification directe ou tout accès en lecture non autorisé aux tables internes de la base de données (niveaux Clean Core C et D) sont strictement interdits.

Ces restrictions Clean Core nécessitent impérativement l'utilisation d'outils de surveillance professionnels tels que SAP Cloud ALM, afin de garantir le respect de ces directives rigoureuses, ainsi que le développement de compétences entièrement nouvelles dans des modèles de programmation modernes tels que CAP (Cloud Application Programming Model) et RAP (RESTful Application Programming Model), afin de reproduire sur la BTP des logiques critiques pour l'entreprise, de manière pérenne et conforme aux API.

Conclusion de l'API SAP

La recommandation urgente de l'association des utilisateurs germanophones DSAG à ses membres et à tous les clients existants de SAP est donc d'éviter à tout prix d'aborder la nouvelle politique de SAP sans préparation et sans esprit critique. Le groupe d'intérêt exige de SAP des définitions claires et immédiates, une documentation complète et contractuelle de toutes les API concernées ainsi que des délais de transition réalistes, afin que les modèles d'intégration existants et très complexes ne s'effondrent pas du jour au lendemain.

Il est vivement conseillé aux clients SAP existants de sécuriser immédiatement les preuves de concept et les projets pilotes d'IA sur le plan juridique et de veiller scrupuleusement, lors des renouvellements de contrats à venir, à ne pas accepter de restrictions techniques ultérieures ou d'augmentations de coûts cachées par la porte dérobée de l'utilisation de l'API.

En fin de compte, DSAG appelle la communauté SAP à défendre activement sa propre souveraineté numérique et à exiger de SAP une transparence inconditionnelle sur l'utilisation, les consommations et les conséquences commerciales de la stratégie API, afin de ne pas perdre toute capacité d'action opérationnelle au profit du groupe de logiciels dans cette phase de transformation risquée.

La DSAG exige donc des définitions claires, une documentation complète des API concernées et une sécurité de planification fiable pour les clients et les partenaires, ainsi qu'une représentation dans les contrats qui permette, côté client, une évaluation solide des cas d'utilisation. Les réglementations correspondantes doivent être compréhensibles et bien comprises. En outre, elles ne doivent pas entraîner de hausse des coûts pour les clients et les partenaires. „Dans le contexte d'une exploitation sûre et stable, il est également important pour nous, en tant qu'utilisateurs, d'avoir une transparence totale sur l'utilisation, la consommation et les conséquences“, déclare Stefan Nogly, directeur technologique de DSAG.

Poignée de contrôle : SAP API Policy

Du point de vue de la DSAG, la conception actuelle de l'API Policy soulève des questions. L'étendue des restrictions semble aller au-delà de la mesure technique nécessaire. Afin de garantir à long terme la capacité d'innovation et la sécurité de planification chez les clients et les partenaires, ces points ouverts doivent être clarifiés le plus rapidement possible en collaboration entre SAP et DSAG.

En y regardant de plus près, la stratégie API actuelle de SAP ressemble à une prise de contrôle stratégique de la souveraineté absolue des données, qui menace massivement la capacité d'innovation des clients existants. Avec le renforcement de la SAP API Policy en avril 2026, le groupe de logiciels de Walldorf réglemente rigoureusement les conditions dans lesquelles les clients et les partenaires peuvent transférer des données dans des systèmes tiers. À l'avenir, seules les interfaces explicitement mentionnées dans le „SAP Business Accelerator Hub“ ou dans la documentation officielle du produit seront autorisées. Dans un récent communiqué de presse, le groupe germanophone des utilisateurs SAP (DSAG) critique vivement cette initiative et déplore l'absence d'obligation contractuelle de ces documentations, ce qui met en péril la sécurité de planification juridique et technologique des utilisateurs.