Les API sont devenues un maillon essentiel des stratégies IA pour enrichir les LLM avec des données métiers. Mais SAP voit d’un mauvais œil la croissance des API non-SAP et entend limiter leurs accès aux données hébergées dans ses systèmes. Dans un communiqué, l’éditeur a indiqué que seules les API répertoriées dans Business Accelerator Hub (le gestionnaire d’API) ou approuvées dans la documentation produit sont valables. En revanche, « les applications des clients et des tiers ne doivent en aucun cas accéder, invoquer ou interagir de quelques manières que ce soit avec des API qui ne sont pas des API publiées », annonce SAP.
Une décision inacceptable
La firme de Waldorff justifie cette orientation par la volonté de « préserver la santé des solutions » et de garantir une stabilité technique. Des raisons qui ne convainc pas le groupe d’utilisateurs germanophones de SAP (DSAG). L’association pense plutôt que cette politique risque de compromettre la sécurité des plans stratégiques, ainsi que leurs capacités d’innovation. « Concernant les scénarios SAP-vers-non-SAP, cela signifie qu’ils ne seront pris en charge de manière fiable que lorsque SAP aura explicitement publié et documenté les interfaces sous-jacentes », a expliqué Jens Hungershausen, président du DSAG, dans un communiqué.
De plus, le DSAG estime que Business Accelerator Hub et la documentation produit, dont la définition reste vague, n’ont pas encore été nettement établis en tant que composantes contractuelles. « Du point de vue du client, cela nécessite la mise en place de conditions-cadres claires et fiables afin de permettre une évaluation précoce de l’impact des changements », a ajouté le dirigeant. « Le DSAG réclame depuis longtemps des documents contractuels absolument fiables. Cependant, SAP a adopté une position contraire, par exemple avec le Business Data Cloud et maintenant avec sa politique relative aux API », a déclaré Michael Bloch, membre du conseil d’administration du DSAG chargé des licences, des contrats et du support. Les clients se posent actuellement des questions quant à l’interprétation de la documentation et, du point de vue du DSAG, une clarification s’impose concernant leur classification contractuelle. « C’est inacceptable », affirme M. Bloch.
Couper l’accès au système IA ?
L’association souligne que les modèles de tarification ou les règles d’utilisation potentiels concernant les API doivent être communiqués de manière transparente — et suffisamment tôt — afin de garantir la fiabilité de la planification pour les clients et les partenaires. SAP, par exemple, a déjà développé un modèle de tarification avec son modèle Digital Access pour la création de certains types de documents en utilisation indirecte. « D’après les informations fournies par SAP, un modèle d’utilisation équitable sera mis en place. Cependant, les détails précis ne sont pas encore clairs et devraient être spécifiquement documentés dans la politique relative aux API », a réclamé M. Bloch.
Un autre point critique est que SAP lie l’utilisation des API à des exigences techniques et organisationnelles. De plus, l’utilisation des API est restreinte dans certains cas, notamment « l’interaction ou l’intégration avec des systèmes d’IA (semi-)autonomes ou génératifs qui planifient, sélectionnent ou exécutent des séquences d’appels d’API, et le scraping, la collecte, ou l’extraction ou la réplication systématique et/ou à grande échelle de données ». Selon Stefan Nogly, directeur technique du DSAG, « d’après les informations dont nous disposons, les intégrations existantes des clients et les solutions des partenaires autorisés ne sont pas concernées » Il estime toutefois que cette protection importante pour les intégrations existantes devrait être explicitement mentionnée dans la politique API de SAP. Il souligne que de nombreuses entreprises utilisatrices travaillent déjà sur des études de faisabilité (PoC) et des projets pilotes en se basant sur l'interprétation actuelle de l'utilisation des API. « Du point de vue des clients, nous constatons un besoin important de clarification et d'adaptation, notamment pour éviter de perturber les processus de bout en bout existants, essentiels à l'activité, ou de les rendre vulnérables sur le plan juridique », a-t-il souligné.
Manque de transparence et délais de transition insuffisants
Le DSAG critique particulièrement le manque de transparence de SAP. Ses membres soulignent que la récente politique relative aux API ne précise pas formellement quelles API spécifiques sont concernées, ni ne définit clairement l’étendue de l’impact. « La question est de savoir quelles interfaces sont utilisées dans les solutions des partenaires », a demandé M. Hungershausen, président du DSAG. Selon l’interprétation de l’association, ceux qui utilisent des API officielles n’ont pas besoin de prendre de mesures, bien que l’absence de garanties contractuelles n’offre pas une sécurité absolue.
Cependant, pour certaines entreprises partenaires, l’effort requis pourrait être considérable, et les modèles économiques pourraient s’effondrer. « Il est donc essentiel que SAP accorde aux clients plus de temps pour la transition », a estimé M. Hungershausen. Les clients et les partenaires ont également besoin d’un soutien technique et organisationnel concret pour passer à des interfaces prises en charge par SAP. Du point de vue du DSAG, il est crucial que les clients ne soient pas contraints de se tourner vers d’autres fournisseurs de solutions en raison d’un manque d’alternatives viables lorsque les scénarios existants sont limités.