Pourquoi les agents IA tiers auront plus de mal à piloter SAP

En avril 2026, SAP a mis à jour sa politique d’usage des API. Pour les entreprises qui veulent connecter des agents IA à leur ERP, la question ne se résume plus à savoir si le connecteur fonctionne. Elle devient aussi contractuelle, architecturale et liée à la gouvernance des données.

La SAP API Policy explique qu’elle définit la disponibilité des API, leurs limites et les contrôles destinés à préserver le bon fonctionnement et la sécurité des solutions, à garantir un accès équitable et à éviter les usages abusifs. Jusque-là, rien de surprenant pour une plateforme critique. Le point sensible se trouve dans la clause IA.

Des analyses externes et la presse spécialisée indiquent que la section 2.2.2 de l’API Policy v4/2026 cible les systèmes d’IA semi-autonomes ou génératifs capables de planifier, sélectionner ou exécuter des séquences d’appels d’API. Sauf passage par une architecture, un service de données ou un chemin spécifique approuvé par SAP, ce type d’interaction ou d’intégration est interdit.

Le vrai sujet : conseiller dans SAP ou agir à la place de l’utilisateur ?

La nouvelle politique ne signifie pas que SAP interdit l’IA dans l’entreprise. La ligne de séparation est plus précise : SAP encadre fortement les cas où un agent IA traite les API SAP comme une couche d’exécution libre, capable de décider de l’étape suivante, d’enchaîner plusieurs appels et parfois d’écrire dans les systèmes métier.

Un outil qui résume des données déjà exportées, produit une prévision ou suggère une action avant qu’un humain ne valide dans SAP se situe généralement dans une zone moins risquée. En revanche, un agent qui vérifie automatiquement un stock, modifie une commande, crée une demande d’achat, approuve un flux ou met à jour des données de référence s’approche beaucoup plus du scénario visé : une IA qui orchestre plusieurs actions et change l’état du système.

Autrement dit, la question opérationnelle devient : l’IA donne-t-elle une recommandation, ou pilote-t-elle directement le cœur transactionnel de SAP ?

Quatre frontières pratiques à retenir

1. Les agents IA tiers doivent passer par des voies reconnues par SAP

The Register résume la nouvelle clause en indiquant que SAP interdit l’usage de ses API pour intégrer des systèmes IA externes en dehors de ses architectures approuvées, ce qui nourrit des inquiétudes sur l’accès des outils IA tiers aux données SAP des clients. Fivetran souligne également que la politique vise explicitement les systèmes semi-autonomes ou génératifs qui planifient, sélectionnent ou exécutent des séquences d’appels API.

La conséquence est simple : une connexion techniquement possible n’est plus nécessairement une connexion acceptable au regard de la politique SAP. Pour un agent tiers, l’enjeu est désormais de savoir si le cas d’usage passe par une SAP-endorsed architecture, un data service ou un service-specific pathway.

2. Les API publiées et documentées deviennent le socle minimal

SAPInsider indique que la mise à jour resserre l’accès système autour des API publiées et documentées. Les API non documentées restent utilisées dans certains environnements, mais se retrouvent hors des frontières de support, ce qui augmente le risque d’exploitation à long terme.

La politique SAP définit les Published APIs comme les API publiées sur le SAP Business Accelerator Hub, aussi appelé API Hub, ou identifiées dans la documentation propre au produit.

Pour les entreprises qui ont accumulé des connecteurs historiques, des intégrations sur mesure ou des interfaces peu documentées, cela impose un inventaire. Même si une intégration fonctionne encore aujourd’hui, son statut de support, sa conformité et sa capacité à survivre aux mises à jour SAP deviennent plus incertains.

3. L’extraction massive de données est elle aussi dans le périmètre

La clause ne concerne pas seulement les agents qui enchaînent des appels d’API. Fivetran et The Register relèvent aussi des restrictions autour du scraping, du harvesting, ainsi que de l’extraction ou de la réplication systématique et/ou à grande échelle de données, sauf via des architectures et chemins contrôlés ou approuvés par SAP.

Cela compte pour les projets de data lake, de data warehouse ou de plateforme IA externe. Déplacer des volumes importants de données SAP ne se juge plus seulement à l’aune du coût, du débit ou de la latence. Il faut aussi vérifier les droits contractuels, les limites d’API, les obligations d’audit et les chemins autorisés par SAP.

4. L’écosystème IA de SAP devient une route plus naturelle

SAP met en avant la possibilité de construire des agents IA sur SAP BTP, sa plateforme technologique, avec intégration à Joule, son copilote IA central, et à l’infrastructure IA sous-jacente. Le SAP Cloud SDK for AI peut aussi se connecter à des frameworks d’agents courants via LangChain et d’autres adaptateurs.

SAP présente également SAP Knowledge Graph comme une capacité destinée à aider Joule et d’autres IA, y compris des agents IA, à produire des réponses plus exactes et pertinentes grâce au contexte métier présent dans les applications SAP.

Cela ne rend pas tous les produits tiers impossibles. Mais lorsque la politique réduit les marges d’interprétation, les voies officielles ou explicitement reconnues deviennent plus faciles à défendre auprès des équipes architecture, juridique, sécurité et risque.

Quels projets IA sont les plus touchés ?

Cas d’usage	Niveau d’exposition	Pourquoi
BI, reporting ou analyse hors ligne à partir de données extraites de manière autorisée	Faible à moyen	Si l’IA n’orchestre pas directement les API SAP, elle touche moins la clause sur l’IA agentique ; l’extraction massive reste toutefois à vérifier.
Chatbot qui conseille, avec exécution finale par un utilisateur dans SAP	Plutôt faible	La politique vise surtout les systèmes qui planifient, sélectionnent ou exécutent des séquences d’appels API ; un flux purement consultatif est différent d’un agent opérationnel.
Agent qui consulte les stocks, modifie des commandes, crée des achats, approuve ou met à jour des données de référence	Élevé	Ces flux impliquent souvent plusieurs appels API, une écriture dans SAP et un changement d’état métier, soit le cœur du risque décrit par la politique.
Réplication importante de données SAP vers une plateforme IA externe	Élevé	La politique mentionne aussi le scraping, le harvesting et l’extraction ou réplication systématique et/ou à grande échelle.
Connecteur ancien ou intégration sur mesure reposant sur des API non documentées	Moyen à élevé	SAPInsider indique que les API non documentées sortent des frontières de support ; SAP définit les API publiées via l’API Hub ou la documentation produit.

Innovation : les PoC devront être cadrés plus tôt

Du point de vue d’une plateforme ERP critique, SAP peut défendre l’idée qu’un agent externe ne doit pas multiplier librement les appels sur des API centrales, surtout lorsqu’il écrit dans le système, modifie des processus ou affecte les performances. La politique indique d’ailleurs que ses contrôles visent le bon fonctionnement, la sécurité, l’accès équitable et la prévention des abus.

Pour les équipes produit, data ou innovation, le coût de démarrage augmente cependant. Un proof of concept qui consistait hier à obtenir un accès API, monter un connecteur et tester un scénario devra désormais être qualifié plus tôt : l’IA décide-t-elle seule de la prochaine action ? Traverse-t-elle plusieurs API ? Écrit-elle dans SAP ? Relève-t-elle d’une architecture approuvée par SAP ?

Le résultat n’est pas forcément l’arrêt de l’innovation. C’est plutôt un déplacement de l’innovation vers une gouvernance plus précoce. Un agent maison, une solution partenaire ou une plateforme IA tierce peut être techniquement capable de se connecter à SAP ; cela ne suffit plus à garantir qu’elle pourra fonctionner durablement dans un cadre supporté et conforme.

Données : accéder n’est pas la même chose qu’agir en temps réel

Il ne faut pas faire dire à la SAP API Policy plus qu’elle ne dit. Le texte porte sur la disponibilité des API, leurs limites et les contrôles associés ; ce n’est pas, en soi, une charte complète sur la propriété des données.

Mais dans un scénario d’IA agentique, le contrôle ne se limite pas au téléchargement d’un rapport. Il porte aussi sur la capacité à lire, écrire, ordonner et exécuter des appels API en temps réel, avec des effets directs sur les processus SAP.

L’analyse de Kai Waehner présente ainsi cette mise à jour comme un moment de réexamen pour l’intégration des données : l’entreprise ne doit pas seulement se demander si elle peut accéder à ses données SAP, mais si l’agent IA de son choix peut agir directement sur ces données et ces processus.

Nuance importante : cette même analyse cite une clarification du CEO de SAP, Christian Klein, selon laquelle l’objectif serait de protéger le savoir-faire métier de SAP et d’éviter une dégradation des performances, non d’empêcher les clients d’accéder à leurs propres données. Pour les entreprises, cette nuance doit toutefois être traduite noir sur blanc dans les contrats, les politiques d’API, les listes d’architectures reconnues et les autorisations propres à chaque cas d’usage.

Verrouillage fournisseur : le risque se déplace vers l’orchestration

Le vendor lock-in ne se manifeste pas toujours par une impossibilité d’exporter des données. À l’ère des agents IA, il peut apparaître plus discrètement au niveau de l’orchestration : si la voie la moins contestable pour automatiser SAP consiste à placer les agents dans SAP BTP, Joule, SAP AI Core ou des services liés à Knowledge Graph, l’architecture IA de l’entreprise tend mécaniquement à s’ancrer davantage dans l’écosystème SAP.

The Register indique explicitement que la clause IA suscite des inquiétudes de lock-in, car des outils IA tiers pourraient avoir plus de difficulté à accéder directement aux données et processus SAP des clients. Fivetran estime aussi que cette politique augmente les enjeux et les arbitrages de la stratégie IA des entreprises, en particulier lorsqu’elles veulent donner à des agents IA l’accès aux données ERP.

Cinq réflexes pour les entreprises

1. Découper chaque cas d’usage IA. Distinguer lecture seule, recommandation, validation humaine, écriture dans SAP et exécution autonome en plusieurs étapes. Le risque monte surtout avec les deux derniers scénarios.
2. Demander la voie reconnue, pas seulement le connecteur. Pour chaque scénario, faire confirmer par SAP ou l’intégrateur s’il existe une SAP-endorsed architecture, un data service, un service-specific pathway ou une architecture liée à SAP BTP et Joule.
3. Auditer les API utilisées. Vérifier si les intégrations reposent sur des API publiées et documentées. Si des API non documentées sont en production, prévoir un plan de refonte et de réduction du risque support.
4. Formaliser les droits dans les contrats et la gouvernance. Inclure l’usage par des IA tierces, l’extraction et la réplication de données, les API limits, les audits, la responsabilité en cas d’incident et la frontière de responsabilité lorsqu’une IA écrit dans SAP.
5. Suivre les FAQ et mises à jour SAP. SAP indique que sa FAQ répond aux questions courantes sur l’API Policy et peut être mise à jour au fil du temps. Une interprétation orale ponctuelle ne suffit pas pour sécuriser un programme IA.

En résumé

Le message central de la nouvelle politique est clair : un agent IA tiers ne peut plus présumer qu’il pourra orchestrer librement les API SAP. Pour les outils de reporting, d’analyse hors ligne ou de recommandation avec validation humaine, l’impact peut rester limité. Pour les projets qui veulent automatiser des processus SAP, écrire dans l’ERP ou répliquer massivement des données vers une plateforme externe, c’est un point de contrôle majeur, à la fois technique, contractuel et organisationnel.

Les entreprises déjà engagées dans SAP BTP, Joule ou SAP AI Core disposeront probablement d’un cadre plus lisible pour leurs projets IA. Celles qui veulent construire une couche d’agents ouverte, au-dessus de plusieurs ERP, CRM, outils supply chain et plateformes data, devront clarifier plus tôt les droits d’usage des API SAP, les architectures approuvées et les limites d’extraction. Mieux vaut le faire avant le développement qu’après avoir bâti un PoC sur une intégration impossible à industrialiser.