Fiche concept

SAP BW/4HANA

À jour au 2026-08-29

Édité par Cédric-Olivier Mâry, é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 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 (Dominik Kurz, 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.

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.

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.