Un ERP conçu pour mener à la faillite

Un système SAP ERP est bien plus qu'un simple outil d'IA performant

Le risque le plus fondamental lié à l'IA agentique dans un environnement ERP critique pour l'entreprise réside dans le caractère potentiellement incontrôlable des algorithmes agissant de manière autonome. Alors que les logiciels traditionnels fonctionnent de manière strictement déterministe, les agents d'IA agissent de manière probabiliste. Un agent Joule autonome, qui gère de manière indépendante les chaînes d’approvisionnement, passe des commandes ou effectue des écritures comptables sans instance de contrôle visuelle, nécessite une qualité irréprochable des données de référence et une stabilité absolue du système. Une IA autonome pourrait se procurer les données manquantes et ne reculerait devant aucune limite pour y parvenir, car elle n’a qu’un seul objectif : l’optimisation du résultat en fonction de la consigne donnée.

Comme ces conditions ne sont tout simplement pas réunies dans les environnements de données qui se sont développés au fil du temps chez la plupart des clients existants, des décisions erronées prises en arrière-plan par l’IA risquent d’entraîner des pertes économiques astronomiques. Si un agent d’IA, sur la base de données erronées ou d’une « hallucination » dans le modèle linguistique associé, en arrive à la conclusion qu’un processus métier est inefficace et, dans le pire des cas, manipule de son propre chef la base de données ERP, voire la supprime, c’est l’existence même de l’ensemble de l’entreprise qui est en jeu.

L'humain dans la boucle ou au-dessus de celle-ci

Sans une instance de contrôle humaine rigoureuse – le „ Human in the Loop “ ou „ Human above the Loop “, absolument indispensable – –, l’utilisation sans discernement de tels systèmes dans le domaine hautement sensible des progiciels de gestion intégrée (ERP) est tout simplement irresponsable, car les machines ne sont pas en mesure de saisir les variables complexes et le contexte économique global. Les machines dotées d’IA manquent de compréhension, mais elles compensent parfaitement cette lacune par l“” optimisation » de la tâche qui leur est confiée.

Si l'on examine la mise en œuvre technique de la plateforme SAP Business AI, du Knowledge Graph et de l'assistant Joule, le client existant sceptique vis-à-vis de l'IA se retrouve face à un système fermé et hautement propriétaire. Les utilisateurs SAP se voient proposer une « boîte noire » : l’accès au Knowledge Graph central, censé fournir le contexte sémantique aux agents, reste exclusivement réservé à SAP. Les clients ne peuvent ni modifier le Knowledge Graph, ni comprendre en détail comment fonctionne le routage des modèles linguistiques qui s’appuient sur celui-ci dans le Generative AI Hub (SAP BTP).

SAP BTP et la politique relative aux API SAP

Même le LLM, qui se trouve par défaut derrière Joule, reste un mystère pour le client. En imposant, via les spécifications « Clean Core », que le développement de ses propres agents se fasse exclusivement dans Joule Studio sur la Business Technology Platform (SAP BTP), SAP bloque fondamentalement le développement APAL traditionnel et flexible. Cette mesure s’accompagne de la nouvelle politique restrictive en matière d’API que SAP a adoptée au printemps 2026 : SAP érige ici une barrière douanière numérique et restreint considérablement l’utilisation des API pour les extractions systématiques de données et leur utilisation avec des systèmes d’IA générative externes fournis par des tiers.

Les clients existants sont ainsi contraints de manière artificielle d'utiliser les plateformes propriétaires coûteuses telles que Datasphere ou le Business Data Cloud (SAP BDC), tandis que les solutions d'IA alternatives et plus flexibles proposées par des partenaires sont systématiquement exclues. De plus, quiconque tente d’intégrer en profondeur des agents tiers non structurés dans son environnement S/4 risque de déstabiliser complètement l’architecture « Clean Core », mise en place au prix de nombreux efforts, en raison d’une nouvelle dette technique et de flux de données non coordonnés.

Sécurité pour l'IA et l'IA agentique

Du point de vue de la sécurité informatique, l'intégration de l'intelligence artificielle dans l'environnement S/4 représente une toute nouvelle dimension de menace à laquelle les cadres traditionnels ne sont pas préparés. La cyber-résilience est vitale dans un paysage de menaces en constante évolution, mais la sécurité SAP est encore souvent considérée, dans de nombreuses entreprises, comme une « boîte noire » inaccessible et un angle mort.

Grâce à l'IA, les cybercriminels agissent aujourd'hui de manière hautement automatisée et efficace. Les attaquants „ maîtrisent désormais l’ABAP “ et sont capables d’analyser et d’exploiter en masse des failles de sécurité en quelques secondes. Cela concerne en particulier les systèmes centraux critiques pour l’activité qui, faute de fenêtres de maintenance, ne sont souvent pas mis à jour pendant des années et présentent donc le risque le plus élevé.

À cela s'ajoute le fait que les outils de sécurité classiques ne sont pas en mesure de détecter les menaces spécifiques à SAP, telles que les injections de code malveillant ou les téléchargements de fichiers manipulés via des interfaces standard. Selon des rapports d'experts, la plateforme BTP, qui est au cœur de la stratégie d'IA de SAP, présente en outre un manque flagrant de gouvernance effective, de structures de sécurité solides et de bonnes pratiques.

SAP Basis (CCoE) face à la sécurité

La séparation organisationnelle entre les équipes SAP Basis et le service de sécurité informatique de niveau supérieur entraîne la formation de silos dangereux qui compliquent considérablement la défense efficace contre les attaques. Lorsque s’y ajoutent des environnements hybrides combinant des systèmes sur site, des clouds privés et des hyperscalers, toute transparence sur les flux de données, les droits d’accès et les états de sécurité est perdue. La seule défense efficace qui reste donc aux clients existants est la mise en place d’une architecture « zero trust » stricte, dans laquelle, conformément aux principes d’authenticité et de confidentialité, on ne fait aveuglément confiance à aucun utilisateur, aucun appareil ni aucun agent d’IA – même si l’accès s’effectue depuis le réseau interne de l’entreprise. Là où l’IA tentera d’obtenir le résultat optimal, un conflit entre les systèmes informatiques s’engagera.

Pour un système S/4, ces risques de sécurité s’aggravent considérablement à l’ère des agents, car les agents IA autonomes agissent au-delà des limites de confiance (voir OpenAI), prennent des décisions de grande envergure (optimisation finale) et traitent des données d’entreprise sensibles (sécurité). La connexion des données SAP à des modèles linguistiques à grande échelle (LLM) externes comporte un risque considérable de fuites de données, car des informations à caractère personnel ou des droits de propriété intellectuelle protégés des clients peuvent se retrouver involontairement dans les données d'entraînement des hyperscalers.

Les nouvelles exigences réglementaires, telles que la loi européenne sur l'IA (EU AI Act), imposent donc une évaluation des risques exhaustive et continue, ainsi que des mécanismes de supervision humaine obligatoires pour ces charges de travail critiques liées à l'IA, ce qui alourdit considérablement la charge administrative des entreprises.

Le cloud d'abord, l'IA d'abord… mais la sécurité avant tout

Comment Christian Klein, PDG de SAP, se positionne-t-il face à ce contexte de sécurité secoué par la crise ? En interne, M. Klein a déclaré l’état d’urgence stratégique (Code Rouge) et fait de l’adoption de l’IA une priorité absolue. Dans le même temps, il rassure le marché boursier nerveux et les clients inquiets en répétant sans relâche que l’IA ne remplacera pas les logiciels standard existants, mais qu’elle en a au contraire un besoin urgent pour garantir la qualité des données et la logique des processus.

En matière de sécurité, la direction de SAP renvoie à son engagement interne en faveur d'une „ IA responsable “ et fait référence au SAP Trust Center. Elle garantit que les données clients sont protégées au sein de SAP AI Core grâce à des filtres techniques, au masquage des données et au filtrage de contenu, et qu’elles ne sont pas utilisées pour l’entraînement des modèles de langage (LLM) de fournisseurs tiers.

Mais Christian Klein utilise ces arguments apparemment légitimes de sécurité et de stabilité pour, dans le même temps, favoriser le cloisonnement de l’écosystème SAP. Sous le prétexte de la protection des données, SAP bloque les interfaces performantes destinées aux fournisseurs tiers afin de consolider la dépendance commerciale vis-à-vis du fournisseur. Le caractère creux de la promesse de sécurité faite par l’entreprise de Walldorf dans un monde géopolitiquement instable est apparu très clairement lorsque le gouvernement américain a bloqué l’accès aux modèles Anthropic Claude – le cerveau cognitif de Joule – aux utilisateurs européens, ce qui a provoqué du jour au lendemain un court-circuit embarrassant et incontrôlable de la très vantée SAP Autonomous Enterprise.