Votre IA, vos données, sa permission: comment le verrouillage des API de SAP livre le marché des achats à ses rivaux

Une seule clause enfouie dans une politique d’API pourrait faire plus pour accélérer la migration hors de SAP que n’importe quel pitch concurrent.

SAP vient de finir de reconstruire sa plateforme achats. Puis l’entreprise a publié une politique qui donne à chaque client une raison de construire son futur IA ailleurs. La nouvelle API Policy v4/2026 restreint l’accès des systèmes IA autonomes et génératifs aux données SAP, sauf si cet accès passe par des architectures endossées par SAP. Le timing est le problème. SAP a fait ce mouvement au moment précis où la technologie enterprise court vers des architectures multi-agents ouvertes, et juste au moment où SAP elle-même relançait une reconstruction de fond en comble d’Ariba avec ses propres agents Joule. Le marché l’a lu comme une blessure auto-infligée.

Le débat a pris de l’ampleur après qu’une série de posts ait cadré la politique comme un but contre son camp. Les chiffres qui ancrent l’argument sont frappants. Selon un sondage de DSAG, le groupe d’utilisateurs SAP germanophone, 77 pour cent des entreprises SAP actives en IA utilisent déjà des outils non-SAP, tandis que seulement 3 pour cent utilisent Joule en production. La politique ne restreint pas seulement l’adoption future. Elle restreint ce que la plupart des clients SAP font déjà. Le post a attiré des architectes SAP, des rivaux ERP, des dirigeants achats et des leaders d’intégration. L’accord que c’était une erreur stratégique était bruyant. La défense de la logique de SAP était plus discrète mais plus substantielle que le pile-on ne le suggérait.

L’erreur non provoquée

Le cadrage le plus tranchant est venu d’un analyste de technologie achats qui a comparé le mouvement au tennis. La plupart des matchs sont perdus non par le joueur qui frappe le moins de coups gagnants, mais par celui qui commet le plus d’erreurs non provoquées. “SAP had a perfectly reasonable ball sitting in the middle of the court, a genuine platform advantage, an entirely rebuilt Ariba, a Joule agent strategy that was actually starting to look almost interesting, and they hit it straight into the net.”

Son diagnostic de la conséquence était précis. “The real risk isn’t that big enterprises will rip out SAP tomorrow. They won’t. SAP’s ERP code block is safe for a decade or more. The risk is that procurement and finance teams will start building their AI-native workflows around SAP rather than through it, and once that architecture hardens, it doesn’t unharden.”

Cette distinction compte. La menace n’est pas un rip-and-replace dramatique. C’est la construction silencieuse d’une couche d’intelligence externe qui laisse SAP comme ce qu’il a appelé “a dumb node receiving clean data from an external intelligence layer that SAP doesn’t control and can’t throttle.”

Le marché a déjà voté

Le point de donnée le plus cité est devenu le centre rhétorique du débat. Veera Baskar K, SCM consultant, l’a dit franchement. “The 77 percent versus 3 percent gap tells you everything. Enterprises have already voted with their integrations, and SAP’s policy is effectively trying to reverse a decision the market already made.”

Son avertissement opérationnel était plus tranchant pour les équipes supply chain spécifiquement. “If your demand sensing, inventory optimisation, or carrier visibility tools are pulling SAP data through non-approved APIs, you’re now looking at a compliance exposure on top of your existing tech debt.”

Alex Saric, dirigeant enterprise SaaS chevronné, a localisé le mouvement dans l’histoire de SAP. “Yes, SAP at the same game as when they announced indirect license fees to try to block customers from using competing SaaS solutions. We see more and more customers, with their CIOs driving, moving their supplier masters outside the ERP such as to Ivalua, with data being pushed back into SAP but managed outside it. The magic, whether agentic workflows or data management, will increasingly happen outside of SAP.”

Cette observation capte l’ironie structurelle. La politique conçue pour garder la valeur à l’intérieur des murs de SAP pourrait être la chose qui pousse la valeur définitivement à l’extérieur.

La défense de SAP

Toutes les voix n’ont pas rejoint le pile-on. Le contre-argument le plus substantiel est venu de Nils Charvin, account executive chez SAP, qui a soutenu que le débat était cadré trop étroitement. “Agentic AI on ERP isn’t another integration. It’s autonomous write access to systems of record. An agent posting journal entries, releasing payments or mutating master data is a different beast from a Copilot summarizing a thread.”

Son point sur la Section 2.2.2 mérite du poids. “The policy targets exactly that, autonomous systems planning and executing sequences of API calls. Not AI access in general. At that level, governance isn’t optional. Signed agent identity. Scoped tokens. SoD enforced at the API layer. Immutable audit trails. No enterprise CFO signs off on anything less.”

Sa conclusion a recadré le test. “Vendor control is the failure mode. Enterprise-grade interop is the win condition.”

Un développeur chez SAP a posé la logique commerciale plus franchement. “Why should SAP allow competitors to build AI Agents using SAP data instead of developing and selling the agents themselves?”

Saurabh Ajay Kumbhare, SAP integration architect, a défendu la rationale de sécurité. “Feeding general use AI with your customers data is like putting your payslip or HMRC data on Facebook. Even Salesforce doesn’t allow it so let’s stop blaming SAP.”

Le sous-texte du revenu de licence

Plusieurs voix ont identifié le motif commercial que le langage de la politique n’énonce pas. Sudarshan Survepalli, fondateur SaaS, l’a nommé directement. “The problem is more to do with license costs. With one agent capable of doing work of hundreds of users, the loss of user based revenue will pinch. In the short term this may slow the bleeding but needs a rethink in terms of how software or APIs are priced.”

James Flood, client director, a tracé l’analogie avec l’histoire de l’accès indirect de SAP. “This is nothing new, it’s indirect usage. Whether it’s people or AI agents, it’s workload which would otherwise be attributed to subscription and consumption in SAP. Not so different to you sharing your Netflix password.”

Duncan Jones, investisseur logiciel, était moins indulgent. “I called out SAP as ‘Ransomware’ when they introduced their Indirect Access policy. This is even worse. SaaS providers need to find a fair way to monetize agents’ use of their software now they can’t simply count human logins. Protectionist bans and tariffs aren’t the solution.”

Ce cadrage compte. L’économie des agents casse le licensing par siège. La politique de SAP se lit pour beaucoup comme un palliatif pour protéger le revenu pendant que l’entreprise cherche comment pricer les agents, pas une vraie mesure de sécurité.

Le risque des systèmes fantômes

La critique la plus ancrée opérationnellement est venue de ceux qui ont vu la friction de gouvernance se retourner. Paulo Segala, supply chain planning leader, a averti sur l’effet de second ordre. “When official integration is too slow, shadow systems appear. And once that happens, the governance problem gets worse, not better.” Son suivi plus tranchant a nommé le vrai danger. “It is shadow decision logic. Once teams build their own paths around friction, they also create their own signals, thresholds, and escalation rules. That is when governance starts losing the execution layer it was meant to protect.”

Rob Colletti, spécialiste packaging et operations, a fait le même point depuis le terrain. “If systems gate access, teams work around them. That’s how shadow spreadsheets and bad data start, then AI just inherits the mess.”

Cette dynamique est le risque le plus profond de la politique. Une restriction censée imposer le contrôle pourrait produire exactement les workarounds non gouvernés qu’elle était conçue pour prévenir.

Les rivaux observent

La réponse concurrentielle a été immédiate. Ward Karson, COO chez Raindrop, a confirmé l’opportunité. “We also love SAP’s unforced error architecture decision. We fully support the BYOLLM architecture. If a customer wants to bring their own Claude, ChatGPT, Gemini or Grok Enterprise LLM and plug it into Raindrop, we happily offer that. We see the tennis score as Advantage: Industry.”

Amol Joshi, Head of Worldwide Sales chez Ivalua, était plus cinglant. “Maybe they think they are Apple.” Felipe R., leader d’intégration, a pointé Oracle JD Edwards comme bien placé pour capitaliser. Le talking track concurrent s’est écrit tout seul.

À retenir pour les dirigeants supply chain

Trois leçons traversent la discussion. D’abord, la politique ne déclenchera pas de migration immédiate, mais elle durcira les workflows AI-native autour de SAP plutôt qu’à travers. Une fois que cette architecture externe se fige, elle ne s’inverse pas.

Ensuite, la gouvernance est une préoccupation légitime, et l’accès autonome en écriture aux systèmes de référence exige vraiment des contrôles. La question est de savoir si SAP industrialise une interopérabilité sûre et auditable assez vite, ou si le délai d’approbation pousse les équipes vers des systèmes fantômes qui détruisent la gouvernance que la politique prétendait protéger.

Enfin, l’enjeu sous-jacent est le pricing, pas la sécurité. L’économie des agents casse le licensing par siège chez chaque vendeur SaaS. SAP a bougé en premier et maladroitement. Le vendeur qui résout la monétisation des agents sans protectionnisme gagne la décennie.

Si vos workflows IA dépendent des données SAP aujourd’hui, avez-vous cartographié lesquels se trouvent maintenant du mauvais côté de la Section 2.2.2?

Poursuivez la discussion sur Chain.NET, la communauté mondiale du supply chain, sur www.chain.net. Posez vos questions, participez aux événements et accédez à des ressources exclusives.