DSAG critique la nouvelle politique API de SAP

SAP a précisé ses directives concernant l'utilisation des interfaces afin, selon ses propres indications, de mieux protéger l'utilisation en forte croissance des API par des systèmes non-SAP ainsi que les nouveaux scénarios basés sur le cloud et l'IA. Les risques potentiels pour la performance, la stabilité et la sécurité doivent ainsi être abordés à temps. Alors que SAP justifie la nouvelle API Policy par des intérêts légitimes de sécurité et la garantie de la stabilité technique, le groupe d'utilisateurs germanophones de SAP (DSAG) estime qu'il y a un besoin considérable de clarification, de concrétisation et d'adaptation.

Absence de garantie contractuelle

Concrètement, SAP stipule avec la nouvelle politique que seules les interfaces qui sont indiquées dans le «SAP Business Accelerator Hub» ou dans la documentation produit correspondante sont considérées comme des API publiées. «Pour les scénarios SAP vers non SAP, cela signifie qu'ils ne seront pris en charge de manière résiliente que là où SAP a explicitement publié et documenté les interfaces sous-jacentes», explique Jens Hungershausen, président du comité directeur de DSAG.

Selon l'avis de la DSAG, le «SAP Business Accelerator Hub» ainsi que la documentation produit non définie ne sont jusqu'à présent pas clairement conçus comme des éléments contractuels. Du point de vue du client, il en résulte une exigence impérative de conditions générales claires et fiables. «La DSAG exige depuis longtemps des documents contractuels absolument solides. SAP adopte cependant une position contraire, par exemple pour SAP Business Data Cloud et maintenant aussi pour l'API Policy. Les clients se posent encore des questions lors de l'interprétation des documents - du point de vue de la DSAG, il y a ici un besoin de clarification concernant la classification contractuelle, ce qui n'est pas acceptable en l'état», déclare Michael Bloch, responsable DSAG des licences, des contrats et du support.

Impact sur les scénarios d'intégration et d'innovation existants

En outre, SAP lie l'utilisation de l'API à des conditions techniques et organisationnelles claires. Les utilisations à des fins non documentées, pour des extractions de données systématiques ou à grande échelle ainsi que pour l'utilisation en interaction avec des systèmes d'IA (semi-)autonomes ou génératifs sont limitées, sauf si elles ont lieu expressément dans des architectures ou des services prévus par SAP.

«Selon les informations dont dispose DSAG, les intégrations existantes des clients et les solutions autorisées des partenaires ne sont pas concernées. C'est essentiel du point de vue des clients et des partenaires», estime Stefan Nogly, directeur technologique de DSAG, qui ajoute : «Une protection pour les intégrations déjà existantes et tolérées par SAP est importante et devrait être inscrite dans la politique API». Dans la pratique, des interfaces qui n'étaient pas officiellement documentées ou approuvées ont été utilisées par le passé - l'expérience montre que des interfaces non documentées sont souvent utilisées, en particulier pour les solutions complémentaires des partenaires.

Une éventuelle commercialisation suscite le scepticisme

La DSAG fait remarquer que les nouveaux modèles de prix potentiels ou les règles d'utilisation autour des API devraient être communiqués de manière transparente et précoce afin de garantir la sécurité de planification pour les clients et les partenaires. «Selon les informations de SAP, il devrait y avoir un modèle d'utilisation équitable. La forme concrète n'est actuellement pas encore claire et devrait être documentée de manière transparente dans l'API Policy», demande Bloch.

Les projets d'IA et la capacité d'innovation en jeu

De nombreuses entreprises utilisatrices travaillent déjà sur des preuves de concept et des projets pilotes sur la base de l'interprétation actuelle de l'utilisation des API. Certes, selon la DSAG, la politique doit d'abord être pertinente pour les nouveaux clients et contrats et ne pas entraîner à court terme de restrictions techniques des intégrations existantes. En revanche, la manière dont SAP prévoit de procéder en cas de prolongation ou d'extension de contrat n'a pas encore été définitivement clarifiée.

«Du point de vue du client, nous voyons un besoin considérable de clarification et d'adaptation - en particulier pour ne pas interrompre les processus end-to-end critiques existants ou les rendre juridiquement vulnérables», explique Nogly. «Les effets à long terme sur la capacité d'innovation ainsi que les nouvelles structures possibles de coûts et de dépendance sont décisifs. Dans une phase d'architectures de plus en plus hétérogènes et d'expérimentations intensives en matière d'IA, les API sont un facteur d'innovation central».»

Les modifications du statut de l'API, des droits d'utilisation ou des scénarios pris en charge ne doivent pas être unilatérales ni rétroactives. C'est la seule façon d'éviter les risques juridiques, les interruptions d'exploitation et les restrictions ultérieures des scénarios d'intégration et d'innovation existants.

Plus de transparence et des délais de transition réalistes exigés

La DSAG juge particulièrement critique le manque de transparence : il n'est pas clairement documenté quelles API sont concrètement concernées, et leur étendue n'est pas non plus clairement définie. Pour certaines entreprises partenaires, la charge de travail pourrait être importante et les modèles commerciaux menacés de disparition. «Il est donc essentiel que SAP accorde plus de temps aux clients pour la transition», demande Hungershausen.

De plus, les clients et les partenaires ont besoin d'une aide technique et organisationnelle concrète pour passer aux interfaces supportées par SAP. Du point de vue de la DSAG, il est essentiel que les clients ne soient pas obligés de se tourner vers d'autres fournisseurs de solutions en cas de restrictions des scénarios existants, faute d'alternatives viables. 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 illustration dans les contrats. «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, les consommations et les conséquences», explique Nogly.

Du point de vue de la DSAG, la conception actuelle de l'API Policy soulève des questions fondamentales. 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.

Plus d'informations : www.dsag-ev.ch