La dernière politique d'API de SAP augmente les enjeux de votre stratégie d'IA

Cette semaine encore, SAP a publié un nouvelle politique d'API qui suscite déjà une forte réticence de la part des clients, des partenaires et de l'ensemble de la communauté SAP. Et il est difficile de passer à côté d'un élément de cette politique : elle distingue explicitement l'IA. SAP interdit désormais l'utilisation d'API pour »interaction ou 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», ainsi que »le grattage, la récolte ou l'extraction ou la réplication de données systématiques et/ou à grande échelle,« sauf via des architectures et des voies contrôlées par SAP.

En d'autres termes, si vous souhaitez utiliser des agents IA pour accéder aux données SAP directement via des API, SAP souhaite que cela se fasse selon les conditions de SAP.

La réaction a été suffisamment rapide pour que SAP ait déjà mis à jour le document et publié une FAQ pour répondre à certaines préoccupations. Christian Klein, PDG lors de l'appel de résultats de la semaine dernière, a rassuré ses clients et partenaires sur le fait que SAP souhaitait une plateforme ouverte et que personne ne devrait s'inquiéter. Mais le libellé de la politique elle-même n'a pas été sensiblement assoupli.

À une époque où toutes les entreprises s'efforcent de trouver comment utiliser l'IA de manière rentable et performante, c'est la clause sur l'IA qui devrait inciter chaque responsable des données à réfléchir.

[CTA_MODULE]

Ce que cela signifie pour les clients de Fivetran

Tout d'abord, la bonne nouvelle pour nos clients : les connecteurs SAP de Fivetran ne sont pas concernés. Vous pouvez continuer à déplacer vos données SAP là où vous en avez besoin, sans interruption. Il convient également de préciser ce que cette politique change réellement aujourd'hui. Il s'agit d'une politique et non d'un contrat, donc pour l'instant, son application est limitée.

SAP agit principalement sur une interface spécifique (ODP RFC), qu'il commencera à bloquer en juillet, à quelques exceptions près jusqu'à la fin de l'année. L'impact immédiat pour la plupart des clients SAP peut donc être minime. Mais les effets à long terme sur l'infrastructure de données, et en particulier sur la stratégie d'IA, méritent d'être examinés, d'autant plus que SAP peut continuer à évoluer et restreindre l'accès à vos données sur leur plateforme.

Le plus important, c'est la direction que prend SAP, et c'est la partie à surveiller.

Pourquoi la direction est importante

La restriction de l'IA est l'élément le plus urgent de la politique, mais elle s'inscrit dans un cadre plus vaste. La position générale est que l'intégration des données SAP avec des systèmes non SAP doit se faire par des voies contrôlées par SAP.

C'est une position qui fonctionne bien pour SAP, mais elle pose une question importante à chaque équipe chargée des données : souhaitez-vous que votre architecture d'intégration et Stratégie en matière d'IA cela dépend de cela, défini par la feuille de route commerciale de votre fournisseur d'ERP ou par la vôtre ?

Les compromis ont tendance à ne devenir clairs qu'une fois que vous vous êtes engagé :

• Cumul des coûts: Les clients finissent souvent par payer pour plusieurs produits de données SAP, et lorsqu'un moteur de calcul externe rejoint l'architecture, les coûts augmentent rapidement.
• Flexibilité limitée du cloud: Même lorsque votre environnement s'exécute sur AWS ou Azure, vous êtes limité aux services certifiés par votre fournisseur, et non au catalogue natif complet que vous avez déjà vérifié et pour lequel vous payez.
• Verrouillage architectural: votre logique métier, votre modèle de sécurité et vos couches sémantiques restent liés au fournisseur. Déplacer l'analytique principale ailleurs plus tard implique de reconstruire ce travail à partir de zéro.
• L'IA selon les termes de quelqu'un d'autre: Si vos agents d'IA ne peuvent accéder à vos données que par des voies définies par les fournisseurs, le rythme et l'orientation de votre stratégie d'IA sont liés au rythme et à l'orientation de la leur.

C'est pourquoi une infrastructure de données ouverte est importante

Notre position chez Fivetran est simple : vos données vous appartiennent, pas à votre fournisseur. Et les outils d'IA que vous choisirez de développer en plus de cela devraient également vous appartenir. C'est la prémisse qui sous-tend Infrastructure de données ouverte (ODI): une architecture dans laquelle le stockage, le calcul et l'intégration sont découplés et où les formats ouverts permettent de garder vos options ouvertes.

En pratique, ODI signifie :

• Vous êtes propriétaire de vos données. Il atterrit dans un lac ou un entrepôt que vous contrôlez entièrement. Aucune revendication de propriété intellectuelle de fournisseur sur vos produits de données.
• Stockage et calcul découplés. Stockez une seule fois, de manière centralisée. Utilisez le moteur de calcul le mieux adapté à la charge de travail.
• Formats ouverts, portabilité réelle. Les formats de table ouverte Iceberg et Delta Lake vous permettent d'utiliser les meilleurs outils de BI, de ML et d'IA disponibles aujourd'hui, sans attendre qu'un fournisseur les certifie.
• Pas de bloqueurs artificiels. Les données circulent là où votre entreprise en a besoin, y compris vers les systèmes d'IA de votre choix.

Les entreprises qui évolueront le plus rapidement en matière d'IA au cours de l'année prochaine seront celles dont les données sont portables, bien gérées et exemptes de restrictions de la part des fournisseurs quant à leur destination ou à leur utilisation.

Réflexions finales

Pour les clients de Fivetran qui utilisent SAP aujourd'hui : rien ne change. Vos pipelines et modèles fonctionnent, vos données atterrissent là où vous le souhaitez, et nous continuerons à défendre vos intérêts au fur et à mesure de l'évolution de cette politique.

L'architecture que vous avez aujourd'hui a été construite pour le travail que vous faisiez il y a 5 ans. Le travail que vous effectuerez dans un an — des agents raisonnant entre différents systèmes, des modèles formés à partir de données dont vous ne saviez pas avoir besoin, des décisions prises plus rapidement que n'importe quel humain ne peut les supporter — vous en demandera davantage. Peut-être que votre architecture est prête pour cela. Peut-être que ce n'est pas le cas. C'est la question à laquelle il vaut la peine de répondre avant que quelqu'un d'autre n'y réponde pour vous.

[CTA_MODULE]