Il existe une version de SAP S/4HANA que la plupart des organisations n’exploitent pas encore.
Ce n’est pas une version future, ni un produit inscrit à la roadmap. Elle existe aujourd’hui. Elle tourne en production dans un nombre croissant d’entreprises en Europe et en Amérique du Nord. Et elle fonctionne avec un niveau d’intelligence des processus qui fait passer les ERP que connaissent la plupart des organisations pour de simples classeurs sophistiqués.
La différence ne tient pas au numéro de version. Ni à l’hyperscaler qui l’héberge. Elle tient à un seul point : l’organisation a-t-elle construit — délibérément et correctement — la couche d’intelligence qui transforme SAP d’un système d’enregistrement en un système d’action ?
Ce que signifie réellement l’ambition IA de SAP
SAP multiplie depuis des années les annonces autour de l’IA. Analyses prédictives dans SAP Analytics Cloud. Machine learning dans Ariba et Fieldglass. Intelligence embarquée dans IBP. Pendant une bonne partie de la dernière décennie, ces annonces décrivaient des capacités réelles mais étroites : des cas d’usage spécifiques, des modules spécifiques, une intégration limitée à l’échelle de la suite.
Joule change l’architecture de cette ambition.
SAP Joule n’est pas un module de plus doté d’une fonction IA. C’est un copilote IA transversal, embarqué au niveau de la plateforme, à travers S/4HANA, SuccessFactors, Ariba et BTP. Il peut faire remonter des analyses, rédiger des réponses, déclencher des workflows et exécuter des actions sur l’ensemble du paysage SAP, en langage naturel. Il repose sur la fondation Business AI que SAP construit depuis 2023 — combinant les données d’entraînement métier propres à SAP et l’infrastructure de grands modèles de langage issue de son partenariat avec Microsoft Azure OpenAI.
L’accélération de la roadmap est bien réelle. Lors de SAP Sapphire 2024, SAP s’est engagé à embarquer Joule dans 80 % de ses workflows les plus utilisés d’ici fin 2025. Pour les organisations qui planifient aujourd’hui leur programme S/4HANA, ce n’est pas une considération d’avenir : c’est une contrainte de conception immédiate.
L’écart entre la plateforme et l’implémentation
Voilà le problème. La capacité existe. La plateforme la délivre. Mais l’implémentation, dans la plupart des organisations, n’est pas en mesure de la supporter.
La capacité de Joule à produire une intelligence exacte et actionnable dépend entièrement de la qualité des données et du paramétrage des processus qui se trouvent en dessous. Si les données de base articles sont incomplètes, si le paramétrage financier charrie les hypothèses héritées d’un système historique jamais réellement audité, si les flux de processus ont été configurés d’après la documentation plutôt que d’après la réalité opérationnelle — Joule produira des réponses fausses, mais formulées avec assurance.
C’est là le mode de défaillance silencieux de l’IA en entreprise : non pas l’hallucination spectaculaire, mais l’inexactitude plausible. Un copilote qui suggère des actions à partir de données ne reflétant pas la réalité opérationnelle. Un modèle prédictif qui extrapole à partir d’historiques imprégnés de tous les contournements, exceptions et corrections manuelles qui caractérisaient le système hérité.
La couche d’intelligence n’est jamais plus intelligente que la couche de données qui la porte.
Ce que BTP rend possible — et ce qu’il exige
SAP Business Technology Platform est le tissu conjonctif de l’écosystème SAP moderne. C’est là que tournent les pipelines d’intégration, que vivent les extensions sur mesure, que les modèles de machine learning sont entraînés et déployés sur les données ERP, et que la couche d’API management relie SAP au reste du paysage technologique de l’entreprise.
Pour les organisations dotées d’une implémentation BTP bien architecturée, les possibilités sont considérables. Un demand sensing en temps réel qui alimente directement la planification dans S/4HANA. Un scoring du risque fournisseur construit sur des signaux de données externes et l’historique achats interne, restitué au moment de la validation de la commande. Une prévision de trésorerie combinant commandes confirmées, comportements de paiement historiques et signaux de change externes dans un modèle actualisé en continu.
Rien de tout cela n’exige d’attendre que SAP l’intègre au produit standard. BTP fournit la plateforme pour le construire dès maintenant, sur vos données, ajusté à votre secteur et à vos schémas opérationnels propres.
Mais l’architecture BTP suppose des décisions. Sur les modèles d’intégration et la gouvernance des API. Sur la localisation des données et la conformité au RGPD et au règlement européen sur l’IA. Sur le lieu d’entraînement des modèles, leur versionnement, la surveillance de la dérive de leurs sorties. Ces décisions ne peuvent pas être différées jusqu’après la mise en production : elles structurent l’implémentation dès le premier sprint.
Les organisations qui traitent BTP comme un sujet secondaire — à aborder une fois le cœur S/4HANA stabilisé — constatent systématiquement que greffer après coup une architecture d’IA et d’intégration sur un système en production coûte bien plus cher et perturbe bien davantage que de la concevoir correctement dès le départ.
Le règlement européen sur l’IA : une contrainte de conception, pas un exercice de conformité
Les entreprises européennes ont une contrainte réglementaire que leurs homologues nord-américaines n’ont pas : l’AI Act, entré en vigueur en août 2024, dont les obligations s’appliquent progressivement selon les catégories de systèmes d’IA.
Pour les déploiements d’IA d’entreprise au sein des paysages SAP, les implications les plus directes concernent les systèmes à haut risque au sens de l’annexe III du règlement — qui couvre notamment l’IA utilisée dans les décisions d’emploi et de gestion des effectifs (donc pertinente pour les déploiements SuccessFactors dotés de fonctions RH assistées par IA) et l’IA utilisée dans l’accès aux services essentiels, publics comme privés.
Au-delà des obligations propres à chaque catégorie, le règlement fixe des exigences de base qui affectent la façon dont les systèmes d’IA sont conçus, documentés, surveillés et gouvernés, toutes catégories de risque confondues. Exigences de transparence. Dispositions de supervision humaine. Standards de gouvernance des données qui doivent être démontrables, et non présumés.
Pour les implémentations IA sur SAP, cela signifie que l’architecture de gouvernance — la manière dont les décisions prises ou assistées par l’IA sont journalisées, auditées et soumises à revue humaine — doit être intégrée à la conception, et non ajoutée après le déploiement.
Les organisations qui traitent l’AI Act comme un exercice de conformité à confier à leur direction juridique une fois l’implémentation technique terminée s’exposent à des reprises coûteuses. Celles qui l’intègrent dès la conception découvrent que l’architecture de gouvernance exigée par la conformité est très largement la même que celle qui rend, de toute façon, l’IA d’entreprise fiable et auditable.
Ce qu’exige réellement une implémentation SAP prête pour l’IA
Les organisations qui font tourner aujourd’hui cette couche d’intelligence n’y sont pas parvenues en ajoutant de l’IA par-dessus une implémentation SAP conventionnelle. Elles y sont parvenues en concevant pour l’IA dès le départ — ce qui, en pratique, recouvre plusieurs choses.
Premièrement, la qualité des données est traitée comme un livrable à part entière, et non comme un prérequis supposé acquis. Des standards de qualité explicites sont définis avant la migration, mesurés sur le système source et corrigés dans le cadre du programme, plutôt qu’en activité post-démarrage.
Deuxièmement, le paramétrage des processus reflète la réalité opérationnelle plutôt que le processus documenté. La logique de décision réelle qui régit les exceptions — les conditions dans lesquelles une commande contourne le circuit de validation standard, les critères qui déclenchent une dérogation à un blocage crédit — est recensée, validée et intégrée au paramétrage, au lieu d’être traitée par intervention manuelle hors système.
Troisièmement, l’architecture BTP est conçue en parallèle du cœur S/4HANA, et non après lui. Les modèles d’intégration sont définis tôt. Les décisions de localisation et de gouvernance des données sont prises explicitement. La couche d’extension est architecturée pour la maintenabilité, et pas seulement pour le besoin immédiat.
Quatrièmement, la couche IA est introduite progressivement, avec un dispositif de surveillance dès le premier jour. Les déploiements Joule qui fonctionnent bien sont généralement introduits par phases — en commençant par les cas d’usage où la qualité des données sous-jacentes est la meilleure et où les enjeux de décision sont bien compris, puis en élargissant à mesure que la confiance dans la couche de données se construit.
Le rendement cumulatif d’une mise en œuvre réussie
Ce n’est pas un hasard si les organisations qui ont investi dans des implémentations SAP prêtes pour l’IA rechignent à en détailler publiquement le contenu : l’avantage opérationnel est important et mesurable.
Les équipes achats qui disposent d’un scoring du risque fournisseur assisté par IA et d’un traitement automatisé des exceptions sur commandes traitent des volumes nettement supérieurs à effectif constant. Les équipes finance dotées d’une prévision de trésorerie en temps réel et d’une clôture assistée par IA prennent de meilleures décisions d’allocation du capital, plus vite. Les équipes supply chain équipées d’un demand sensing intelligent et d’une gestion des exceptions absorbent les perturbations avec moins d’escalades et moins de gestion de crise.
Il ne s’agit pas d’améliorations marginales. Elles traduisent un changement de nature dans ce que l’entreprise peut accomplir avec le même capital humain — ce qui est, en définitive, le retour qui justifie l’investissement dans la transformation.
La plateforme capable de délivrer tout cela existe déjà dans SAP. La question est de savoir si votre implémentation est conçue pour la supporter.
