Fiche concept

SAP BW/4HANA

À jour au 27 octobre 2026

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

Qu'est-ce que SAP BW/4HANA ?

SAP BW/4HANA est le produit d'entrepôt de données exclusivement HANA de SAP, en disponibilité générale depuis 2016. Le nom invite à une erreur qu'il vaut mieux nommer tout de suite : ce n'est pas « BW, version 4 ». C'est un produit distinct, avec sa propre ligne de code, et un client n'y monte pas de version — il y emménage.

Ce qui a été retiré délibérément. BW avait accumulé des types d'objets pendant dix-huit ans ; BW/4HANA les a taillés. L'Advanced DSO (aDSO) a absorbé les rôles que tenaient séparément les DSO standard, les DSO write-optimised et les InfoCubes — un objet à drapeaux de configuration au lieu de trois objets aux sémantiques distinctes. Les CompositeProviders ont absorbé MultiProviders et InfoSets. InfoCubes classiques, flux 3.x, règles de transfert et modélisation côté extracteur ont disparu. Ce qui survit est ce qui portait le sens analytique : InfoObjects, transformations, DTP, chaînes de processus, couche de requête.

Pourquoi cela en fait un exercice de modélisation. Parce que la cible a moins de types d'objets que la source, il n'existe pas de traduction fidèle terme à terme pour un patrimoine BW mûr. Chaque InfoCube doit devenir un aDSO configuré ; chaque MultiProvider doit devenir un CompositeProvider avec une décision explicite de jointure ou d'union. L'outillage en porte une grande part et SAP livre des chemins de conversion — in-place, remote, shell — mais le reliquat est du jugement, et c'est là que la charge se concentre. C'est le mécanisme derrière ce constat : les projets BW/4HANA ressemblent rarement à des montées de version.

L'échelle, énoncée comme un plancher. Le registre porte ~2 500 clients BW/4HANA face aux 20 000 à 30 000 clients BW 7.5 classiques nommés par SAP à Sapphire 2025 (D. K., repris par SAPinsider). Les deux sont des planchers issus de publications, non des comptes tirés d'un registre, et c'est le rapport qui est le plus robuste : la cohorte modernisée est nettement minoritaire dans le patrimoine BW. C'est cette asymétrie, et non l'un ou l'autre chiffre isolé, qui porte l'argument de demande de migration.

Sa place face à Datasphere et BDC. BW/4HANA est le successeur dans la lignée BW. SAP Datasphere est un service d'entreposage cloud au modèle de modélisation différent, et SAP Business Data Cloud la couche de produits de données au-dessus. Ce ne sont pas des réponses rivales à une même question. Un client peut exploiter BW/4HANA et Datasphere ensemble, et BW Bridge existe précisément pour faire atterrir du contenu BW dans Datasphere. Traiter le choix en soit/soit est l'erreur de cadrage la plus répandue de cette partie de la pile.

Les chemins de conversion, et ce que chacun coûte réellement

SAP publie trois chemins documentés, et aucun n'échappe au reliquat de modélisation décrit plus haut.

La conversion in-place s'exécute dans le système existant : les objets sont convertis sur place, dans un ordre contrôlé, et le système finit exclusivement HANA en conservant son identité technique. Elle convient à un système unique disposant d'une fenêtre d'indisponibilité acceptable et d'une dette technique que l'équipe accepte de transporter telle quelle — car la conversion in-place n'impose pas de refonte, elle exécute seulement le mappage de types d'objets (DSO/InfoCube vers aDSO, MultiProvider/InfoSet vers CompositeProvider) qu'exige le modèle d'objets réduit.

La conversion remote monte un nouveau système BW/4HANA et rapatrie le contenu du système source objet par objet, ce qui est le point naturel pour consolider plusieurs systèmes sources ou retirer du contenu que personne n'utilise. Elle coûte plus de temps calendaire que l'in-place mais achète une remise à plat architecturale réelle.

La conversion shell ne conserve que la coquille technique du système cible et reconstruit ou transporte sélectivement le contenu dedans. C'est le bon choix quand le patrimoine source porte assez de dette technique non documentée pour qu'une conversion mécanique ne fasse que déplacer le problème — mais c'est aussi le chemin où le reliquat de jugement est le plus important, car rien n'y est porté par l'outillage seul.

Chiffrer un projet BW/4HANA honnêtement

Les trois chemins ci-dessus ne remplacent pas le cadrage : ce sont des répartitions différentes de l'endroit où atterrit le travail de jugement. Un devis fournisseur qui ne nomme que le chemin, sans l'inventaire d'objets — combien d'InfoCubes, combien de MultiProviders, combien de routines de transformation sur mesure — n'a pas réellement cadré le projet, car les décisions de mappage vers aDSO et CompositeProvider sont exactement les postes que ni l'outillage ni le choix du chemin ne suppriment.

La décision que cela impose

Deux décisions, prises dans cet ordre, et c'est la seconde qui porte le chiffrage. D'abord le chemin : in-place, remote ou shell — un arbitrage entre temps calendaire et remise à plat d'architecture, pas entre bon marché et cher. Ensuite, pour chaque objet sans successeur dans le modèle réduit, une décision objet par objet : le mapper mécaniquement, le refondre, ou le retirer. L'outillage porte le mapping ; il ne porte ni la refonte ni les conversations de retrait. Présenter le passage comme une montée de version masque précisément cette seconde décision, et c'est pourquoi un chiffrage qui nomme un chemin sans inventaire d'objets n'est pas un chiffrage — c'est une préférence.

L'angle Joule, septembre 2026

Le modèle d'objets réduit de BW/4HANA — l'aDSO et le CompositeProvider remplaçant l'ancien ensemble DSO/InfoCube/MultiProvider/InfoSet — compte dans une conversation IA pour une raison qui n'a rien à voir avec la performance : un ensemble de types d'objets plus petit et plus cohérent est plus facile à publier comme data product BDC gouverné, et un data product gouverné est la seule forme de contenu BW/4HANA sur laquelle le SAP Knowledge Graph ou un agent Joule peuvent réellement ancrer leur raisonnement. Un CompositeProvider BW/4HANA proprement modélisé — avec une décision explicite de jointure ou d'union déjà prise, plutôt que laissée comme une union ambiguë façon MultiProvider — se convertit en data product BDC avec beaucoup moins de reliquat de jugement que l'objet BW classique équivalent, parce que la moitié de la décision de modélisation (quels champs, quelle jointure) est déjà résolue côté source.

C'est un argument réel, quoique sous-employé, pour choisir le chemin BW/4HANA plutôt que de rester sur BW 7.x classique quand Business Data Cloud et Joule sont la cible à moyen terme : l'effort de chemin de conversion décrit sur cette fiche (in-place, remote, shell) est dépensé une fois, et il se rembourse deux fois — une première fois vers BW/4HANA lui-même, une seconde vers la façon dont ce contenu atteindra plus tard la couche data product de BDC, parce que le modèle d'objets réduit de BW/4HANA est structurellement plus proche d'un data product que ne l'est celui de BW classique. Un consultant qui cadre un passage à BW/4HANA uniquement contre l'échéance de maintenance 2027 de BW 7.5 laisse ce second bénéfice non énoncé.

Ce qu'il faut décider : quand un client choisit entre BW/4HANA et rester sur BW classique alors que tout le reste renvoie à Datasphere/BDC, demander si le parc est destiné à devenir du contenu ancré au Knowledge Graph dans les deux à trois prochaines années. Si oui, la simplification du modèle d'objets qu'impose BW/4HANA n'est pas un effort de modélisation perdu — c'est un effort sur lequel le BW Data Product Generator (voir la fiche compagnon sur la fin de support BW) peut bâtir moins cher que sur un parc BW classique portant des InfoCubes et MultiProviders sans successeur. Ce qu'il faut surveiller : SAP n'a publié aucune préférence énoncée entre convertir via BW/4HANA avant de générer des data products BDC ou générer directement depuis BW classique — traiter cela comme un jugement d'architecture que votre équipe rend explicite dans le chiffrage, pas comme une recommandation SAP documentée.

Pourquoi c'est important

BW/4HANA est le seul chemin qui préserve intact le paradigme de modélisation BW. Que ce soit un atout ou un sursis dépend de là où le client veut être une fois BDC et Datasphere posés en cibles stratégiques.

Points clés

Un produit distinct, pas une version de BW : sa propre ligne de code, exclusivement HANA, en disponibilité générale depuis 2016.
Plancher du parc installé ~2 500 clients face à 20 000-30 000 clients BW 7.5 (SAP, Sapphire 2025) — la cohorte modernisée est minoritaire dans le patrimoine BW.
L'aDSO remplace le clivage DSO/InfoCube ; les CompositeProviders remplacent MultiProviders et InfoSets. Moins de types d'objets, plus de décisions poussées dans la modélisation.
🔴 C'est un successeur de BW, pas une alternative à Datasphere ou BDC — ils se situent à des couches différentes, et choisir l'un ne tranche pas l'autre.
Des chemins de conversion existent (in-place, remote, shell) mais le reliquat est du jugement, et c'est là que l'effort se concentre.
La décision de chemin (in-place · remote · shell) arbitre entre temps calendaire et remise à plat d'architecture ; ce n'est pas un choix bon-marché contre cher.
Le chiffrage vit dans la décision objet par objet — mapper, refondre ou retirer — pour chaque objet sans successeur dans le modèle réduit.
Un chiffrage qui nomme un chemin sans inventaire d'objets est une préférence, pas un chiffrage.

Pièges courants

Lire le nom comme un numéro de version — Signal : « On va juste monter vers BW/4 » Correctif : Produit séparé, ligne de code séparée. Planifier un déménagement, pas une montée de version.
Cadrer BW/4HANA contre Datasphere comme un choix exclusif — Signal : Une diapositive avec une flèche et deux cases Correctif : Des couches différentes. BW Bridge existe précisément pour que les deux puissent coexister.
Citer la base installée BW pour BW/4HANA — Signal : 20 000-30 000 attaché à BW/4HANA Correctif : 20 000-30 000, c'est BW 7.5 classique (SAP, Sapphire 2025) ; le plancher BW/4HANA est ~2 500. Le ratio est ce qui compte.

Cadre de décision

Cadre de décision
Décision	Option A	Choisir A quand	Option B	Choisir B quand
BW/4HANA ou directement vers Datasphere/BDC	BW/4HANA	Le paradigme de modélisation BW est un atout ; le parc est grand et l'équipe maîtrise BW	Datasphere / BDC	Le modèle opérationnel cible est des data products cloud ; le parc est assez petit pour être reconstruit
Comment dimensionner le mouvement	En forme de montée de version	Rarement correct — seulement pour un parc déjà réduit	En forme de modélisation	Le défaut : moins de types d'objets cibles que de types source signifie des décisions objet par objet

Chiffres à citer

Le plancher de base installée de SAP BW/4HANA est d'environ 2 500 clients face aux 20 000 à 30 000 clients BW 7.5 classiques nommés par SAP à Sapphire 2025 (SAP — D. K., Senior Director Product Management SAP BW/4HANA & BW Bridge, Sapphire 2025, repris par SAPinsider) — une minorité du parc BW.
SAP BW/4HANA est généralement disponible depuis 2016 — près d'une décennie d'historique de disponibilité générale face à laquelle le plancher d'environ 2 500 clients est mesuré.
3 chemins de conversion documentés existent — in-place, remote, shell — et les recommandations propres de SAP indiquent que l'outillage porte une large part de chacun, le résidu retombant sur le jugement.
Le modèle d'objet réduit fusionne ce qui était trois sémantiques distinctes (DSO standard, DSO optimisé en écriture, InfoCube) en un seul aDSO avec des indicateurs de configuration — une consolidation 3 vers 1.
Les MultiProviders et les InfoSets — deux types d'objet séparés dans le BW classique — fusionnent tous deux en CompositeProviders dans BW/4HANA — une consolidation 2 vers 1.

Sources

Ouvrir dans l'application →

Les guides qui répondent avec cette page

Ces guides citent cette page parmi les sources sur lesquelles leur réponse s'appuie.

Missions ouvertes

56 postes et missions SAP BW/4HANA ouverts en ce moment — voir les missions SAP BW/4HANA · missions freelance SAP.