SAP 2026 : ce que la nouvelle politique API change pour les agents IA tiers

Pour une DSI, un intégrateur ou un éditeur logiciel, cela change la manière de concevoir un démonstrateur IA, un flux ETL, une automatisation RPA, une plateforme iPaaS ou un agent capable d’orchestrer plusieurs actions dans SAP.

Ce que SAP encadre plus strictement

La nouvelle politique formalise davantage la frontière entre ce qui est considéré comme une API SAP utilisable et supportée, et ce qui relève d’un usage plus fragile. Selon CIO, SAP indique que seules les interfaces listées dans le SAP Business Accelerator Hub ou dans la documentation produit correspondante sont considérées comme des API publiées.

The Register rapporte de son côté que la politique impose d’utiliser les API uniquement dans les limites d’architectures validées par SAP, de services de données ou de chemins propres à certains services — la formulation anglaise citée est SAP-endorsed architectures, data services, or service-specific pathways.

Concrètement, une entreprise ne peut plus partir du principe que toute interface SAP techniquement appelable est adaptée à un usage pérenne. Le document de politique API mentionne notamment des contrôles sur les limites fonctionnelles et techniques, les quotas, les calendriers de dépréciation, les quotas d’entrée et de sortie de données, les limites et préconditions applicables aux extractions ou réplications en masse, ainsi que d’autres exigences de sécurité ou techniques.

SAPinsider souligne que les API non documentées restent largement utilisées dans certains paysages SAP, mais qu’elles se retrouvent désormais en dehors des frontières de support, ce qui accroît le risque opérationnel et d’intégration à long terme.

Autrement dit, la question dépasse largement l’IA. Elle touche à la gouvernance de l’ERP : quelles API sont publiées, quels usages sont supportés, quelles extractions nécessitent des conditions particulières, et quelles automatisations doivent passer par un chemin officiellement reconnu par SAP.

Pourquoi les agents IA sont particulièrement visés

La clause la plus commentée concerne les systèmes d’IA. Plusieurs sources rapportent que SAP interdit l’usage de ses API pour interagir ou s’intégrer avec des systèmes IA semi-autonomes ou génératifs qui planifient, sélectionnent ou exécutent des séquences d’appels API, sauf lorsque cela se fait par des architectures, services de données ou chemins expressément validés par SAP.

C’est précisément ce qui distingue un agent IA d’une intégration classique. Une intégration traditionnelle suit en général un scénario défini à l’avance : lire une commande, mettre à jour un statut, déclencher une facture. Un agent IA, lui, peut décider dynamiquement de la prochaine action selon un objectif : consulter un fournisseur, vérifier un stock, analyser un historique d’achats, proposer une commande, puis soumettre une approbation ou mettre à jour un enregistrement.

Dès qu’un système choisit et enchaîne lui-même plusieurs appels API SAP, il peut entrer dans le champ décrit par la politique. La conformité dépendra alors des API utilisées, de l’architecture retenue, des services de données mobilisés et du caractère reconnu ou non du chemin d’intégration par SAP.

La même logique vaut pour les flux de lecture intensive. Les restrictions citées couvrent aussi le scraping, la collecte automatisée de données, ainsi que l’extraction ou la réplication systématique et/ou à grande échelle. Les agents qui écrivent dans SAP ne sont donc pas les seuls concernés : les architectures qui aspirent beaucoup de données SAP vers un lakehouse, une plateforme IA ou une couche d’orchestration externe doivent également être revues à l’aune des quotas, préconditions et chemins autorisés.

L’innovation ne s’arrête pas, mais elle devient moins improvisée

Pour les équipes innovation, les intégrateurs et les éditeurs indépendants, le principal changement est l’apparition d’un filtre de gouvernance plus exigeant avant même le PoC. Tester rapidement un agent de rapprochement comptable, d’aide aux achats, d’analyse de stocks ou d’automatisation du service client reste envisageable, mais il faut d’abord vérifier plusieurs points : l’API est-elle publiée dans le SAP Business Accelerator Hub ou la documentation produit ? L’architecture est-elle validée par SAP ? Les volumes risquent-ils de déclencher des limites de quota ou des restrictions d’extraction ? L’agent planifie-t-il seul une séquence d’appels API ?

Le PoC ressemble donc moins à une expérimentation légère et davantage à un mini-projet d’intégration : cartographie des API, conception des droits, estimation des volumes, revue des flux de données, journalisation, auditabilité et validation contractuelle.

ERP Today estime que cette politique transforme un sujet autrefois très technique — l’usage d’interfaces SAP — en question d’architecture ERP plus large. Certaines intégrations existantes peuvent dépendre d’interfaces non formellement documentées, alors que les nouveaux usages IA ont besoin d’un accès contrôlé aux données d’entreprise et aux workflows transactionnels.

L’incertitude elle-même peut ralentir les projets. The Register rapporte que DSAG, le groupe d’utilisateurs SAP germanophone, critique l’incertitude créée par la politique. Le même article note que certains critiques estiment que la liste des interfaces approuvées par SAP n’est pas toujours suffisamment bien gérée ni tenue à jour.

Le vrai sujet : qui contrôle les chemins d’accès aux données ?

Le débat ne se limite pas à la propriété des données. Dans beaucoup d’entreprises, la question opérationnelle est plus concrète : peut-on utiliser la plateforme IA, l’entrepôt de données, le lakehouse ou l’outil d’automatisation de son choix pour accéder directement, en continu et à grande échelle, aux données et processus SAP ?

The Register présente l’enjeu comme un risque d’exclusion de certains outils IA tiers vis-à-vis des données SAP des clients. ERP Today l’inscrit plus largement dans les choix d’architecture ERP, de réplication de données et d’accès IA aux processus métier.

Une entreprise qui synchronise ses données SAP vers un lakehouse externe, une plateforme d’IA, une couche d’orchestration d’agents ou un système d’automatisation tiers doit donc examiner précisément les quotas d’entrée et de sortie, les conditions d’extraction ou de réplication en masse, le périmètre des API publiées et l’éventuelle obligation de passer par un chemin reconnu par SAP.

Ces contrôles peuvent renforcer la sécurité, la performance, l’audit et la gouvernance. Leur contrepartie est une moindre liberté architecturale pour les scénarios IA multi-plateformes, surtout lorsqu’ils nécessitent de lire ou d’écrire de gros volumes de données transactionnelles SAP.

Verrouillage fournisseur : un risque réel, pas une fatalité

Le risque de verrouillage vient d’un mécanisme simple : si un agent IA tiers ne peut pas interagir librement avec les API SAP, le client peut être amené à s’appuyer davantage sur les architectures validées par SAP, ses services de données ou les modes d’intégration explicitement autorisés. The Register parle d’une clause IA qui suscite des inquiétudes de lock-in, car elle pourrait empêcher certains outils IA tiers d’accéder aux données SAP des clients.

La réaction de DSAG montre que les clients ne s’inquiètent pas seulement d’un détail juridique. E3 Magazine rapporte que le groupe d’utilisateurs juge inacceptable que SAP restreigne fortement l’usage des API à des fins non documentées, les extractions massives systématiques et les interactions avec des systèmes d’IA générative autonomes fournis par des tiers.

Ce verrouillage n’est toutefois pas automatique. Tout dépendra de la manière dont SAP définit et maintient ses chemins reconnus, de la qualité et de l’actualité des listes d’API publiées, de l’existence de procédures d’exception ou d’approbation auditables, et de la possibilité laissée aux fournisseurs tiers d’innover dans un cadre clair. Le fait que des critiques pointent déjà la gestion et la mise à jour des listes approuvées est un signal à prendre en compte dans les décisions d’achat et d’architecture.

Cinq réflexes à adopter dès maintenant

1. Cartographier toutes les intégrations SAP. Pour chaque flux, distinguer API publiée, API documentée dans un produit, interface non documentée, extraction en masse, lecture/écriture temps réel, RPA, iPaaS, workflow externe ou appel par agent IA.

2. Isoler les cas d’usage IA agentiques. Tout processus où un modèle ou un agent planifie, sélectionne ou exécute plusieurs appels API SAP doit faire l’objet d’une revue de risque avant passage en production — et idéalement avant même le PoC.

3. Réexaminer les extractions de données. Les usages de scraping, harvesting, extraction systématique, réplication massive ou alimentation de plateformes analytiques et IA doivent être vérifiés par rapport aux quotas, préconditions et chemins autorisés.

4. Demander une confirmation écrite. Pour les scénarios sensibles — agent IA autonome, mise à jour transactionnelle automatisée, orchestration entre plusieurs systèmes, export massif de données — une validation orale ne suffit pas. Les critiques de DSAG sur l’incertitude montrent l’importance de disposer de limites documentées.

5. Préserver la réversibilité architecturale. Même si l’entreprise choisit un chemin reconnu par SAP, il est prudent de garder séparables l’orchestration IA, la gouvernance des données, les droits, les journaux d’audit et les règles métier. L’objectif est d’éviter que toute la logique d’innovation soit prisonnière d’un seul couloir technique.

À retenir

La politique API 2026 de SAP ne signifie pas que l’IA ne peut plus fonctionner avec SAP. Elle signifie plutôt que les agents IA tiers ne peuvent plus supposer qu’ils pourront librement orchestrer les API SAP, surtout lorsqu’ils enchaînent des appels, extraient des données à grande échelle ou interviennent dans des processus ERP critiques.

Pour les entreprises, le chantier immédiat est clair : inventorier les intégrations existantes, identifier les usages IA à risque, vérifier les API publiées et les chemins validés, puis concevoir les nouvelles architectures de manière à conserver autant que possible le choix des outils et des fournisseurs.