Algorithmes ERP contre LLM et agents IA

Déterministe ou probabiliste

Les clients SAP existants sont confrontés à un nouveau type de menace : un système ERP fonctionne traditionnellement comme une machine déterministe garantissant la précision, tandis que les modèles d’IA générative reposent sur des logiques stochastiques probabilistes qui conduisent inévitablement à des hallucinations structurelles. Outre cette disruption sur le fond, se pose le défi de la sécurité des systèmes cloud.

Les pirates et les modèles d'IA automatisés ont appris à pénétrer rapidement le code des systèmes et à cibler les interfaces automatisées, ce qui permet des attaques à une vitesse exponentielle. La question de la sécurité du cloud et de la maîtrise des agents autonomes (IA agentique) passe ainsi d’un simple enjeu technique informatique à un enjeu existentiel en matière de gestion des risques et de continuité des activités.

Gestion des risques : agents IA

Le risque concret que des agents d'IA au sein de SAP Autonomous Enterprise déclenchent des actions erronées, effectuent des écritures comptables incorrectes ou corrompent les données de base trouve son origine dans plusieurs causes systémiques : Lorsque des modèles linguistiques stochastiques sont confrontés à des données de base historiquement corrompues ou à du code personnalisé obsolète, les systèmes ont tendance à mettre en œuvre des déductions erronées avec une grande conviction.

Comme l'ont clairement démontré des incidents survenus au sein de groupes informatiques tels qu'Amazon et Microsoft, des agents autonomes disposant de droits d'exécution étendus peuvent entraîner des modifications involontaires de la configuration du système ou paralyser des processus critiques.

Kurt Gödel et Alan Turing

Les limites de la théorie de l'information, telles que définies par Kurt Gödel et Alan Turing, démontrent mathématiquement qu'une „ machine à vérité “ mathématiquement infaillible est en principe impossible dans le cadre de modèles stochastiques. De plus, la direction de SAP elle-même a mis en garde contre une « architecture Frankenstein » incontrôlable, dans laquelle des agents d’IA non coordonnés provenant de différents fabricants entreraient en conflit au sein d’un même système ERP, en l’absence de règles communes.

La gouvernance en tant que code et les harnais d'IA

Afin d'empêcher efficacement toute corruption du cœur du système ERP par des agents non contrôlés, les entreprises utilisatrices doivent mettre en place une gouvernance « as-code » et des barrières de sécurité à plusieurs niveaux (IA-Harnesses).

Sur le plan technique, le contrôle porte sur l'identité et les droits d'accès : un agent IA ne doit jamais agir en tant qu'entité privilégiée dotée de droits illimités, mais doit être géré en tant qu'identité numérique non humaine (Non-Human Identity) selon le principe de la propagation du principal. Cela signifie que l’agent s’exécute exactement dans le contexte de sécurité et d’autorisation de l’utilisateur authentifié et ne peut ni effectuer d’actions ni consulter de données auxquelles l’utilisateur humain n’a pas accès.

De plus, grâce à l’intégration de l’environnement d’exécution open source Nvidia OpenShell dans Joule Studio Runtime, SAP garantit une couche d’exécution isolée (Sandbox Boundary) qui définit les outils auxquels un agent est autorisé à accéder et la destination des données d’inférence. Pour les transactions critiques pour l’entreprise – telles que les validations de paiement ou les modifications des données de base –, le principe « Human in the Loop » ou « Human above the Loop » reste indispensable : l’agent prépare des propositions, mais l’exécution finale doit être confirmée par une intervention humaine.

L'utilisation du Model Context Protocol (MCP) constitue par ailleurs un complément essentiel : cette norme d'interface indépendante des fabricants permet de mettre en place, de manière déterministe et vérifiable, l'accès des agents d'IA aux outils via des serveurs MCP découplés.

Les cerises du jardin du voisin

En ce qui concerne la préoccupation pressante de savoir si les agents d’IA SAP peuvent s’échapper de leur environnement client ou système prévu et s’introduire dans des systèmes S/4 tiers ou d’autres « Autonomous Enterprises », l’analyse actuelle dresse un tableau nuancé : une évasion physique de l’environnement d’exécution au-delà des limites du système est rendue difficile au niveau de la plateforme grâce à une isolation des mandants à plusieurs niveaux (Tenant Isolation), à une gestion cryptée des secrets (Secret Management) dans l’AI Launchpad et à des sandbox en conteneurs isolés.

Il existe néanmoins des risques réels d'attaque et de propagation (mouvement latéral), qui découlent principalement de failles conceptuelles telles que l'injection de prompt, l'empoisonnement de la mémoire ou des destinations BTP mal configurées. Si un agent autonome est connecté, via des interfaces inter-systèmes, à des systèmes CRM externes ou à des systèmes partenaires et qu’il y rencontre des données manipulées, il peut être amené à effectuer des appels API non autorisés vers d’autres mandants S/4.

Passerelle API d'IA et analyse comportementale

Pour empêcher de telles intrusions entre clients, il faut une passerelle API IA centralisée qui regroupe tout le trafic des agents au niveau d’une interface unique et surveillée, applique des politiques d’accès très granulaires au niveau des paramètres et bloque immédiatement les comportements inhabituels grâce à des analyses comportementales automatisées (Behavioral Analytics).

Sur le plan commercial, SAP utilise toutefois ces préoccupations en matière de sécurité comme levier : Avec la version 4 de la SAP API Policy (paragraphe 2.2.2), adoptée en avril 2026, le groupe réglemente strictement l'extraction directe et sans licence de données par des agents tiers et oblige les clients à acheminer les charges de travail de leurs agents via la Business Technology Platform (SAP BTP) et le Business Data Cloud (SAP BDC). Si cela permet certes de limiter les flux de données incontrôlés, cela fait toutefois grimper sans pitié les coûts via des « Capacity Units » facturées en fonction de la consommation.

Sécurité SAP Cloud ERP

L'analyse de la sécurité de SAP Cloud ERP montre que le passage au cloud – que ce soit via « Rise with SAP » (cloud privé) ou « Grow with SAP » (cloud public) – impose un modèle d'exploitation entièrement nouveau fondé sur le partage des responsabilités (modèle de responsabilité partagée). La promesse selon laquelle le cloud constituerait en soi une forteresse imprenable a été relativisée par des incidents tels que la grave vulnérabilité « zero-day » dans SAP NetWeaver Visual Composer (CVE-2025-31324), qui a démontré que même les infrastructures proches du cloud doivent être renforcées et surveillées en permanence.

SAP propose une gamme complète de mesures de protection pour garantir la sécurité de ses clients existants dans le cloud. Ce portefeuille s'appuie sur des centres de données certifiés ISO 27001, un chiffrement de bout en bout des données au repos et en transit (TLS/KMS), une authentification basée sur OAuth2, ainsi qu'une détection automatisée des menaces via des services tels que SAP Enterprise Threat Detection. Au niveau de l’infrastructure, SAP coopère étroitement avec les grands hyperscalers tels que Microsoft Azure, Amazon Web Services et Google Cloud Platform, ce qui permet d’intégrer directement des outils de sécurité avancés tels que Microsoft Sentinel Threat Monitoring ou AWS Secrets Manager.

Pour autant, les entreprises utilisatrices du cloud ne doivent pas se bercer d’une fausse sécurité. Pour faire face aux risques liés à la dépendance vis-à-vis des hyperscalers américains et aux réglementations imprévisibles en matière de contrôle des exportations – comme le blocage à court terme par les États-Unis des modèles linguistiques d’Anthropic –, les alternatives garantissant la souveraineté des données, telles que l’AWS European Sovereign Cloud, le StackIT-Cloud du groupe Schwarz ou le cloud privé certifié Rise de T-Systems, gagnent massivement en importance. De plus, même la meilleure sécurité cloud fournie par le fournisseur ne dégage pas l’entreprise utilisatrice de ses propres obligations légales. En vertu des exigences strictes de la loi européenne sur l’IA (EU AI Act), la responsabilité juridique et opérationnelle finale pour toutes les décisions et actions exécutées par des agents IA autonomes au sein du cœur de système ERP productif incombe entièrement et de manière intransférable à l’utilisateur lui-même.