Fiche concept

Produits de données SAP — le catalogue 300+

À jour au 2026-09-27

Édité par Cédric Mary, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Produits de données SAP ?

Les Produits de données SAP sont des actifs de données conservés, versionnés, gouvernés, façonnés pour la consommation downstream — les briques élémentaires de BDC.

De quoi il s'agit

Les Produits de données SAP sont des actifs de données conservés, versionnés, gouvernés, façonnés pour la consommation downstream — les briques élémentaires de BDC. Sapphire 2026 a confirmé 300+ en production et annoncé une cible de 500+ pour le T2 2026 ; ce jalon n'a pas été confirmé comme atteint, donc citer le compte de catalogue vérifiable sur le tenant.

Couverture par domaine visible dans la slide keynote. Finance : Facturation & Paiements · Cash Flow · Rémunération. Supply Chain : Livraisons · Stocks · Matériel de fabrication · Bons de commande. Ressources humaines : Effectifs. Service & Ventes : Cas & Tickets. Plus extensions sur Gestion des dépenses et produits spécifiques à l'industrie.

Ce que contient réellement un Produit de données. Chaque Produit est un schéma typé + KPIs métier significatifs + lignée vers le système SAP source + métadonnées de gouvernance (propriétaire, fréquence de rafraîchissement, classification) + les données elles-mêmes. Un consommateur (agent Joule, dashboard SAC, modèle Datasphere) interroge un Produit comme objet de première classe — sans avoir à écrire des jointures sur les tables S/4HANA brutes.

Pourquoi 300 → 500 compte. Chaque nouveau Produit est une fonctionnalité que SAP livre gratuitement aux clients BDC existants. Le rythme (200 produits ajoutés en 2 trimestres) prouve que SAP investit dans la profondeur de contenu BDC, pas seulement dans la plateforme. Un consultant doit suivre les release notes Data Products trimestrielles comme un consultant BW suivait les livraisons Business Content.

Quand consommer un Produit de données SAP packagé plutôt que construire une vue Datasphere sur mesure — la décision d'arbitrage. Le Produit packagé est le bon point de départ dès lors qu'un domaine SAP standard est dans le périmètre et que les besoins de reporting de l'entreprise s'alignent sur l'ensemble de KPIs livré. Consommer un produit standard signifie que SAP absorbe la charge de maintenance : mises à jour de schéma, corrections de lignée et certification relèvent de la responsabilité de SAP, non de l'équipe projet. Le gain de vitesse est réel — une équipe Finance peut commencer à interroger un Produit Cash Flow standardisé en quelques jours après le provisionnement BDC, contre des semaines pour construire et valider un Analytic Model Datasphere équivalent sur mesure.

Choisir une vue Datasphere personnalisée quand la logique métier diverge du produit standard : méthodes de calcul propriétaires, structures d'allocation de coûts non standard, fusion multi-systèmes SAP et non-SAP, ou définitions de KPIs spécifiques à l'industrie que SAP n'a pas encore livrées en produit packagé. Le prix à payer est la pleine propriété de la maintenance. Quand une mise à jour S/4HANA modifie la structure des tables sous-jacentes, une vue Datasphere sur mesure se brise silencieusement jusqu'à ce qu'un écart de rapport soit détecté ; un Produit de données packagé ne se brise pas. Cette asymétrie de maintenance est l'argument le plus fort pour commencer par le produit standard et ne personnaliser que là où l'écart est documenté et justifié.

Plutôt que de répliquer directement les tables S/4HANA brutes dans Datasphere : la réplication brute offre une flexibilité maximale mais zéro couche sémantique — chaque équipe consommatrice réimplémente les mêmes jointures, conversions de devises et définitions de KPIs de façon indépendante. La couche Produit de données est le contrat de gouvernance qui prévient cette fragmentation.

La connexion BW. SAP BW Data Product Generator (Disponible) convertit les InfoProviders BW existants en Produits de données, le chemin canonique de modernisation BW. Ne reconstruisez pas la logique BW from scratch dans BDC — générez-la.

Gouverner un catalogue qui continue de grandir. Un catalogue de 300 à 500 produits n'est pas une liste statique qu'un consultant mémorise une fois pour toutes ; c'est une cible mouvante avec sa propre discipline de versionnement. Chaque Data Product publie un contrat de données à côté de son schéma — un propriétaire nommé, une cadence de rafraîchissement déclarée, une classification de sensibilité et une liste explicite de consommateurs — et c'est ce contrat qui distingue réellement un Data Product d'une table partagée avec une étiquette plus soignée. Quand SAP livre un changement de schéma sur un Data Product existant (un nouveau champ, un KPI renommé, une classification resserrée), c'est le contrat qui indique à un agent Joule ou un dashboard SAC consommateur si le changement est additif et sans risque, ou s'il casse quelque chose et nécessite une revue avant le prochain rafraîchissement.

Exemple appliqué : une équipe Finance consommant le Data Product packagé Cash Flow pour un dashboard de fonds de roulement remarque, au début d'un nouveau trimestre, que les notes de version de SAP listent une mise à jour de schéma ajoutant un champ de couverture de change à ce produit. Parce que l'équipe consommait le Data Product comme objet de première classe plutôt que de joindre des tables brutes, la mise à jour arrive comme une colonne additive sans aucun retravail nécessaire sur le dashboard existant — exactement le scénario que la couche Data Product existe pour garantir. À l'inverse, une équipe ayant construit une vue Datasphere custom équivalente sur les mêmes tables S/4HANA brutes voit une montée de version S/4 sans rapport, modifiant la structure d'une table sous-jacente, casser silencieusement cette vue — et personne ne le remarque avant qu'un chiffre du dashboard ne paraisse faux des semaines plus tard.

Le cas limite à signaler explicitement à un client : un domaine passant de « aucun Data Product packagé n'existe encore » à « un Data Product le couvre désormais » en cours de projet. Quand cela arrive, toute vue custom construite pendant la période intermédiaire exige une décision explicite — la retirer au profit du nouveau produit packagé, ou documenter précisément pourquoi elle diverge encore (un calcul propriétaire que le produit standard ne prend pas en charge, par exemple). Laisser les deux vivre silencieusement est la façon la plus courante dont deux dashboards Finance finissent par afficher deux chiffres de fonds de roulement différents sur les mêmes transactions sous-jacentes, et c'est la plainte de qualité de données la plus fréquente qui remonte en réalité à la croissance du catalogue de Data Products plutôt qu'à une véritable erreur de donnée.

L'angle Joule, septembre 2026. Le SAP Knowledge Graph lit les métadonnées des Data Products — propriétaire, lignée, cadence de rafraîchissement, classification de sensibilité — comme substrat d'ancrage, ce qui signifie que la course du catalogue de 300 à 500 n'est pas seulement une histoire de contenu, c'est aussi une histoire de capacité Joule. Chaque nouveau Data Product livré par SAP est une entité de plus sur laquelle les agents Joule et le service d'orchestration du generative AI hub peuvent ancrer une réponse sans qu'un consultant ait à câbler un modèle sémantique à la main au préalable. En pratique : avant de cadrer un agent Joule pour un cas d'usage Finance ou SCM, vérifier si le domaine dispose déjà d'un Data Product packagé, car un domaine couvert se convertit en agent ancrable en quelques jours, tandis qu'un domaine couvert seulement par une table brute ou une vue custom non documentée force le projet à construire la couche d'ancrage à la main — le même compte de catalogue 300+ qui tranche une décision construire-ou-acheter pour le reporting tranche aussi une décision construire-ou-acheter pour l'ancrage IA.

L'ajout en mai 2026 de l'inférence par lots depuis SAP AI Core, intégrée directement dans les data products prêts pour le métier (si bien qu'une prédiction de modèle tabulaire — SAP-RPT-1.6 en septembre 2026, la génération courante sur le generative AI hub — arrive comme un champ à côté de la donnée gouvernée que Joule lit déjà), est le mécanisme concret à nommer devant un client : cela signifie qu'un Data Product n'est plus seulement une cible de requête, il peut porter une colonne de prédiction alimentée par le propre modèle tabulaire fondation de SAP sans pipeline MLOps séparé. Pour un consultant, la décision à soulever explicitement est de savoir si le Data Product d'un domaine donné doit être enrichi maintenant d'une colonne d'inférence par lots AI Core, ou rester descriptif tant que le cas d'affaires de la prédiction n'est pas prouvé — enrichir trop tôt ajoute un coût en AI Units et une obligation de rafraîchissement de modèle que personne n'a budgétée.

La Modernization Option BDC pour SAP BW NetWeaver, ouverte à l'abonnement depuis septembre 2026, change la question de séquencement pour les comptes à forte présence BW : elle retire la pression de convertir chaque InfoProvider en Data Product avant que l'ancrage IA puisse démarrer, parce que l'option elle-même est un pont, pas une contrainte. Une règle de cadrage pragmatique pour 2026 : convertir en Data Products d'abord partout où un cas d'usage Joule est déjà financé, et laisser le reste sur le pont de la Modernization Option jusqu'à ce qu'un cas d'usage les nomme.

Pourquoi c'est important

Le mode de consommation est concret : un consommateur interroge un Produit de données comme objet de première classe, sans écrire de jointures sur les tables S/4HANA brutes.
Le rythme 300→500 (200 produits nets nouveaux en deux trimestres) est la preuve avancée que SAP investit dans la profondeur de contenu, pas seulement la plateforme — à suivre comme les consultants BW suivaient les livraisons de Business Content.
La règle construire-vs-acheter est explicite : utiliser un Produit packagé quand le domaine standard et le jeu de KPIs correspondent au besoin — construire du custom Datasphere seulement quand la logique métier diverge réellement.

Points clés

300+ Produits de données confirmés en production à Sapphire 2026 ; le jalon 500+ annoncé pour le T2 2026 n'a pas été confirmé comme atteint — vérifier le compte de catalogue avant de le citer.
Domaines : Finance (Facturation, Cash Flow, Rému) · SCM (Livraisons, Stocks, Mat Prod, Cdes) · RH (Effectifs) · Service (Cas/Tickets) · Dépenses · Industrie.
Chaque produit : schéma typé + KPIs + lignée + métadonnées gouvernance + données.
Consommateurs (Joule, SAC, Datasphere) interrogent les Produits comme objets première classe — pas de jointures S/4HANA brutes.
SAP BW Data Product Generator convertit les InfoProviders BW en Produits — chemin canonique de modernisation BW.
Chaque Data Product publie un contrat de données (propriétaire, cadence de rafraîchissement, classification de sensibilité, liste de consommateurs) — c'est ce contrat, pas le seul schéma, qui le distingue d'une table partagée.
Le SAP Knowledge Graph et Joule ancrent leurs réponses directement sur les métadonnées des Data Products : un trou de catalogue dans un domaine est donc aussi un trou d'ancrage IA, pas seulement un trou de reporting.

Sources

Ouvrir dans l'application →

Produits de données SAP — le catalogue 300+

Qu'est-ce que Produits de données SAP ?

De quoi il s'agit

Pourquoi c'est important

Points clés

Sources

Concepts liés

Modules d'académie associés

Études approfondies

Guides SAP analytics & TJM