SAP restreint les API tierces : le choc pour les projets IA

Temps de lecture : 6 min

Contexte : pourquoi SAP ferme le robinet ?

Les API, c’est le tuyau invisible qui connecte vos applications métiers au monde extérieur. Sans elles, pas de synchronisation avec vos outils CRM, pas d’export vers un entrepôt de données, et surtout pas de brique IA pour enrichir vos LLM avec vos données clients ou vos stocks. SAP, en gros, décide de fermer les vannes sur les API non listées dans son Business Accelerator Hub. Dans un communiqué officiel, l’éditeur annonce que seules les API publiées ou approuvées dans sa doc produit sont valables. Et il ajoute un truc qui fait froid dans le dos : « Les applications des clients et des tiers ne doivent en aucun cas accéder, invoquer ou interagir avec des API non publiées. »

En bon dirigeant, on se dit : « C’est leur droit, ils veulent contrôler l’écosystème. » Mais quand on creuse, cette décision menace directement vos plans IA. Je vais être honnête, dans la vraie vie (pas sur LinkedIn), j’ai vu des boîtes déjà lancer des POC basés sur des API non officielles : des flux de données clients vers un LLM pour générer des propositions commerciales, des chatbots RH, ou du reporting automatisé. Tout ça, SAP le coupe.

Le point de vue du terrain : DSAG contre-attaque

L’association des utilisateurs germanophones de SAP (DSAG) ne mâche pas ses mots. Son président, Jens Hungershausen, déclare que cette politique risque de « compromettre la sécurité des plans stratégiques et les capacités d’innovation. » Dit autrement, si vous aviez prévu d’intégrer vos données SAP dans un assistant IA maison, vous êtes bloqués, sauf si SAP a gentiment publié l’API correspondante.

Michael Bloch, membre du conseil du DSAG, ajoute : « Le DSAG réclame depuis longtemps des documents contractuels fiables. SAP a adopté une position contraire. » Et là, il tape sur le vrai nerf de la guerre : l’opacité des conditions. Ce qu’on ne vous dit jamais, c’est que le Business Accelerator Hub lui-même n’est pas un composant contractuel clair. Selon le DSAG, sa définition reste vague, et aucun contrat ne garantit que les API listées seront stables dans le temps. Imaginez que vous basiez toute votre stratégie IA sur une API qui disparaît du hub le mois prochain sans préavis. Pas de sécurité, pas de planification.

Quel impact concret sur vos projets IA ?

Prenons un exemple fictif mais réaliste. Vous êtes une PME de 45 salariés (j’en ai dirigé une par le passé, je connais bien ce contexte). Vous lancer un projet de chatbot client alimenté par vos données de ventes et stocks hébergés sur SAP Business One. Actuellement, vous utilisez une API non officielle pour extraire les données vers votre base vectorielle. Avec la nouvelle politique de SAP, cette opération est interdite. Résultat : le chatbot ne peut plus répondre en temps réel, votre projet tombe à l’eau, et vous avez déjà investi 15 000 euros dans l’infrastructure et la formation.

Et ce n’est pas tout. Stefan Nogly, directeur technique du DSAG, précise que l’interdiction concerne aussi l' »interaction avec des systèmes d’IA semi-autonomes ou génératifs qui planifient, sélectionnent ou exécutent des appels d’API », ainsi que tout scraping ou extraction massive de données. C’est un coup de pied dans la fourmilière : vos POC, vos pilotes, tout est gelé.

Dans la vraie vie, notez bien : si vous utilisiez déjà une API officielle et que vous avez un contrat en bonne et due forme, a priori, vous êtes safe. Mais comme le souligne Nogly, les intégrations existantes des clients et partenaires « ne sont pas concernées », du moins si elles sont autorisées. Pour les autres, c’est l’arrêt immédiat. Et là, le stress monte.

Les problèmes de transparence et de tarifs

Regardons les chiffres. Le DSAG dénonce un manque de transparence : quelles API exactement sont concernées ? Comment savoir si les API utilisées par vos partenaires sont fléchées ? On ne vous dit pas grand-chose. En plus, SAP laisse planer un modèle de tarification à l’usage. Sur le principe, ce n’est pas choquant : beaucoup d’éditeurs facturent à l’API call. Mais dans la pratique, sans visibilité sur les coûts, impossible de budgéter.

Imaginons un éditeur de solution qui a bâti un CRM sur les API non officielles de SAP. Son modèle économique repose sur des appels gratuits. Du jour au lendemain, SAP exige qu’il migre vers une API payante, avec des tarifs publiés seulement en sous-main. La trésorerie peut être sérieusement impactée. Et ce qui est pire, c’est que SAP n’a toujours pas clarifié les conditions de licence pour l’utilisation indirecte (type Digital Access). Vous croyez que vous allez signer un contrat clair ? Pour l’instant, c’est flou.

Le défi des durées de transition

Le DSAG le dit sans détour : les clients ont besoin de temps. Quand on est une TPE/PME, on ne bascule pas en une semaine. Il faut redévelopper des connecteurs, tester, former, puis certifier la conformité. SAP brandit une politique sans délai fixe : l’accès est coupé immédiatement pour les API non autorisées. Hungershausen demande : « Il est essentiel que SAP accorde plus de temps pour la transition. »

J’ajoute que les partenaires qui ont construit des modules ou extensions basés sur ces API risquent de voir leur business s’effondrer. Ce n’est pas de la science-fiction : j’ai connu un prestataire qui perdait 60 % de son chiffre en un trimestre à cause d’un changement de politique API. Une vraie douille.

Que faire ce week-end pour votre boîte ?

Au lieu de paniquer, je vous propose un plan d’action pragmatique, comme je le fais avec les dirigeants que j’accompagne.

1. Auditez vos accès API : listez toutes les API qui dialoguent avec votre instance SAP, même celles utilisées par vos appels IA ou vos processus automatisés.
2. Vérifiez leur statut officiel : consultez le Business Accelerator Hub et votre documentation produit. Si une API n’y apparaît pas, considérez-la comme interdite dès maintenant.
3. Contactez votre partenaire ou votre revendeur SAP : demandez une confirmation écrite que vos usages IA sont compatibles avec la politique API actuelle. Insistez pour obtenir les conditions tarifaires futures.
4. Faites un point avec votre DSI ou prestataire technique : identifiez les POC en cours sur des API non officielles. Peuvent-ils migrer vers des alternatives publiées ? Sinon, l’option la plus réaliste est souvent de reporter le projet.
5. Pensez à la diversification : si votre stratégie IA repose exclusivement sur SAP, vous êtes vulnérable. Envisagez des solutions intergiciels (middleware) qui acceptent des API standardisées, ou des plateformes d’intégration tierces (iPaaS) pouvant servir de buffer.

Ce week-end, prenez 30 minutes pour auditer. Dans la vraie vie, c’est ce qui fait gagner des semaines de migraine.

Ce qu’on peut retenir sans bullshit

Cette décision n’est pas un coup de tonnerre isolé. SAP continue son recentrage sur son écosystème propriétaire, comme elles le font avec Business Data Cloud. Le message est clair : si vous voulez utiliser leurs données, vous passerez par leurs API officielles, facturées et contrôlées. Pas de pitié pour les start-ups qui brodaient à côté.

Ce que j’ai appris à la dure, en tant qu’ex-dirigeant de PME, c’est que les dépendances logicielles sont des lignes de fragilité. Quand vous concevez un produit, intégrez une clause de sortie dans votre architecture : isolez vos appels API derrière une couche d’abstraction. Ça vous évitera de voir votre business plan exploser si l’éditeur change les règles du jeu.

En conclusion, gardez un œil sur les annonces de SAP. Consultez leur politique API mise à jour sur le Business Accelerator Hub. Et surtout, si vous avez le moindre doute, ne lancez pas un gros projet IA sans avoir un retour contractuel solide de votre partenaire SAP. Le temps, l’argent et l’énergie que vous économiserez valent bien une réunion de cadrage.

Romain Grand

Neuf ans à piloter une PME de 45 personnes, à tester des outils, à faire des erreurs — et à en tirer les leçons que personne ne publie. Aujourd’hui, je vous épargne les détours inutiles.