SAP et l’IA : l’éditeur et ses clients n’ont pas encore trouvé la formule idéale

IA : des responsables des projets SAP encore réticents

Pour en revenir à l’IA, la majorité des personnes interrogées ne sont pas suffisamment au courant de l’accompagnement offert par SAP (56 %), ne sont pas satisfaites des méthodes de licences (53 %) et n’ont pas une visibilité claire permettant la maîtrise des coûts (56 %).

Le livre blanc proposé par l’éditeur à l’USF pour commenter les annonces de Sapphire est peu compréhensible pour une population qui n’est pas familière avec l’IA.

Pour faire très simple, d’un côté, SAP multiplie les solutions sur étagère. De l’autre, elle pousse ses clients vers sa plateforme BTP (Business Technology Platform) pour intégrer à l’aide de leurs intégrateurs de grands modèles de langage (LLM) dans leurs processus.

Oui, SAP a déjà un catalogue riche en la matière, mais l’éditeur n’aborde pas suffisamment les sujets importants : la gestion du changement, le bon cas d’usage pour commencer et surtout, au-delà des démonstrations, n’a pas de chemins clairs vers ses solutions.

Bernard Cottineau, président de la commission Organisation & Gouvernance de l’USF, note une certaine réticence des métiers IT œuvrant sur l’ERP.

« Les départements SAP se posent des questions sur l’avenir de leur métier. C’était déjà le cas avec l’adoption du cloud, l’enjeu est renforcé avec les solutions IA », remarque-t-il.

D’autres comme Servier, Promocean, ID Logistics, Bouygues Telecom et De Sangosse commencent à tirer parti de l’IA intégrée à SAP.

De Sangosse tire les leçons de Joule Companion

Le cas du groupe De Sangosse, fabricant et concepteur de produits « biophythosanitaires » utilisés dans le monde agricole, est notable. Accompagné par l’intégrateur STMS, il avait annoncé lors de la convention USF 2025 l’intégration de l’assistant Joule Companion à son environnement S/4HANA Cloud Private Edition sur Azure. Le premier en France. Un an plus tard, « ça a fait pschitt », constate Jean-François Judit, DSI chez De Sangosse, lors d’un atelier de la Convention USF, le 14 octobre.

Pas « pschitt » parce que Joule hallucine, que l’intégration ou que le produit est défaillant, mais « pschiit » parce que les usagers connaissaient trop bien leur ERP pour avoir besoin de poser des questions à une IA. L’assistant en lecture seule n’a finalement pas été déployé.

« Cela nous a permis de travailler sur la structure organisationnelle et technique pour mettre en place Joule », relativise le dirigeant.

Le DSI et l’intégrateur ont tenté d’interroger les métiers à la recherche de cas d’usage. En vain. Les comptables étaient réticents à partager des idées de cas d’usage par peur, tout simplement, de se voir remplacé par un agent IA.

Le dirigeant IT, qui craint de son côté que les agents IA shadow pullulent avec le temps, s’est donc évertué à impulser un premier cas d’usage. Il est consacré à la gestion du risque client afin d’éviter les impayés. Lors des entretiens avec les métiers, Jean-François Judit et les consultants de STMS ont retenu que ces tâches étaient chronophages et pénibles pour la direction administrative financière. Un facteur de risque supplémentaire.

Trois réunions de 30 minutes plus tard, en s’appuyant sur Joule Studio, l’interface de Joule Copilot et un modèle de raisonnement, STMS a développé un agent doté de « skills » qui lit les données dans SAP, la documentation interne vectorisée de l’entreprise et les compare avec les données de solvabilité obtenues à travers le serveur MCP de Pappers (un connecteur pour les agents IA) puis fournit des conseils sur la classification de risques et les prochaines mesures à prendre, notamment l’analyse des cas spécifiques ou critiques et les relances clients. Il peut également écrire dans quelques champs de la base de données HANA afin de changer la classe de risques.

« Cela a provoqué un déclic chez nous. Alors que les comptables n’étaient pas pour au départ, cela leur donne de nouvelles idées », assure Jean-François Judit. « Cela a déclenché un projet au sein de la DAF pour améliorer les processus internes de gestion des créances clients. Nous nous attendons également à ce qu’il y ait de nouvelles demandes d’agents IA ».

Le DSI note déjà une réduction des impayés, l’amélioration du délai moyen du paiement clients, des gains de productivité et des décisions accélérées. En revanche, l’agent n’est pas encore en production. « J’attends Joule Studio 2.0 avec impatience que j’adopterais après une négociation sur la facture des tokens », renseigne-t-il. « Cela fait pratiquement un an qu’il a été annoncé, ils [les membres des équipes de SAP] sont en retard par rapport au calendrier ». L’entreprise déploie un autre agent interagissant avec l’ERP, cette fois-ci en s’appuyant sur Microsoft Copilot.

« Avant d’être prêt pour Joule 2.0, il faut l’être pour adopter la BTP », souligne Sébastien Faure, directeur général de STMS Solutions. La BTP est la PaaS de SAP nécessaire pour déployer les connexions aux LLM. Les membres de l’USF qui ont adopté S/4HANA cloud le savent bien. Selon l’enquête de satisfaction de l’USF, c’est le produit complémentaire à l’ERP le plus cité devant SAP Analytics Cloud, SAP Concur et Successfactors.

Il recommande d’adopter Joule for Consultants. « Cela vous permet de vous familiariser avec l’IA de SAP et de répondre à vos problématiques IT. Cela fait six mois que nous l’utilisons chez STMS et les clients à qui nous l’avons recommandé voient déjà des gains », note-t-il.

Quelques entreprises rencontrées par LeMagIT commencent par adopter cet outil. C’est un assistant pour les responsables des déploiements SAP, normalement les ESN. Dans ce cas-là, il doit surtout les aider à mettre le pied à l’étrier de nouveaux venus dans les équipes, dans le cadre de projet de fusion et acquisition. Ces entreprises doivent encore en valider l’efficacité.

Architecture, tarification : SAP doit aussi peaufiner son offre

Comme avec le cloud souverain, SAP cherche lui aussi les meilleures formules financières et techniques.

« Nous essayons encore de trouver la tarification la plus adaptée pour qu’elle soit à la fois compréhensible et accessible », déclare Olivier Nollent. « Il y a aussi beaucoup de communication à faire : nous devons informer l’USF. Nous avons également des outils de simulation pour que les clients puissent se projeter de façon sereine. Des outils pour comparer les bénéfices d’un agent sur un processus versus le coût. Mais ce sont des choses encore en évolution ».

Pour les clients qui le souhaitent, SAP anticipe le passage à un modèle économique axé sur les résultats. « Ce n’est pas forcément pour tout le monde, mais nous réfléchissons au bon modèle économique et ce mode axé sur les résultats demeure un point important à évoquer », assure Véronique Hangard, Chief Business Officer chez SAP.

D’un point de vue plus technique, Olivier Nollent reconnaît qu’en début d’année, « la promesse ne correspondait pas à la réalité ». Ce ne sera bientôt plus le cas. « Joule Works, Joule Studio 2.0 et près 400 agents IA seront disponibles d’ici la fin de l’année », souligne-t-il. Le PDG de SAP a aussi exprimé sa volonté d’accélérer l’accompagnement des clients qui peuvent déjà déployer ces agents IA.

Dans un même temps, SAP est en train de renforcer son architecture de données pour qu’elle puisse supporter les agents IA. Oui, les données enregistrées dans l’ERP sont (généralement) exactes, les graphes de connaissances et les produits de données de SAP qui en dérivent aussi. En revanche, l’éditeur doit s’assurer de la bonne intégration des données externes (« non SAP »). Là, il faut donc trouver un moyen de standardiser le knowledge graph pour éviter les hallucinations et les erreurs. Les knowledge graph SAP ne sont pas personnalisables. Or, il faudra les faire cohabiter avec des graphes spécifiques à chaque client, ce qui est plus difficilement maîtrisable.

SAP a également décidé de contrôler plus finement les données accessibles depuis ses serveurs MCP. L’éditeur n’évoque pas des raisons de propriété intellectuelle ou de contrôle de son écosystème. Tout simplement, des appels incontrôlés mettraient « les serveurs à genoux », dixit Florian Hamon, expert en données et en analytique chez SAP EMEA. « C’est la raison pour laquelle nous appliquons des limites en matière de nombre d’appels API par jour ou par mois. Nous avons aussi à inspecter les sources de danger afin d’éviter les piratages », ajoute-t-il. « Nous avons une responsabilité juridique, d’où l’interdiction de l’API ODP (Operational Data Provisioning) RFC qui pouvait être utilisé à mauvais escient ».