Fiche concept

BW Bridge : l'arbitrage de migration

À jour au 2026-10-06

É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 BW Bridge ?

BW Bridge est le chemin de transition SAP qui permet à l'investissement BW/4HANA on-prem existant de coexister avec Datasphere — en faisant tourner des objets de type BW/4HANA (advanced DataStore Objects, CompositeProviders, transformations, chaînes de processus — ni InfoCubes, ni requêtes BEx) à l'intérieur du tenant Datasphere. C'est l'accélérateur de migration qui offre aux clients 2 à 4 ans pour passer de BW à la modélisation Datasphere-native sans rip-and-replace.…

Qu'est-ce que le BW bridge SAP ?

Le BW Bridge est un runtime BW/4HANA embarqué dans un tenant SAP Datasphere : il fait tourner les objets BW existants, leurs extracteurs et leurs transformations ABAP à l'intérieur de Datasphere, exposés comme remote tables aux vues Datasphere. Il permet de migrer un paysage BW sans tout reconstruire d'abord. C'est un outil de transition : ce qu'il porte doit recevoir une date d'arrêt, pas devenir la cible permanente.

La réalité architecturale. BW Bridge fait tourner un système BW/4HANA à l'intérieur de Datasphere avec un stockage partagé. Les objets BW existants continuent de fonctionner ; la nouvelle modélisation se fait en Datasphere-natif (Spaces, Analytic Models, Data Builder). Les deux coexistent ; au fil du temps, les objets BW migrent ou sont retirés au choix du client.

Quand BW Bridge est la bonne option. Grand estate BW (1 000+ queries, 100+ InfoProviders) où le rip-and-replace consommerait 18 à 24 mois et casserait le reporting quotidien. Le pont achète du temps : 2 à 4 ans pour migrer objet par objet tout en restant opérationnel.

Quand BW Bridge n'est pas la bonne option. Petit estate BW (moins de 50 objets) — la migration directe vers Datasphere est plus rapide et moins coûteuse. Client greenfield — pas besoin de ponter ce qui n'existe pas.

Signal craft senior — cadence de migration. Un junior provisionne BW Bridge et le laisse stagner. Un senior pilote un sprint trimestriel : 5 à 10 objets BW vers Datasphere-natif chaque trimestre, séquencés par valeur métier et complexité. En année 3, BW Bridge représente moins de 30 % de la surface analytics ; en année 5, il peut être retiré.

Discipline coût. BW Bridge consomme des capacity units Datasphere en plus de l'empreinte de licence BW/4 embarquée. Les clients paient les deux pendant la période de pont. Documenter une date de fin dans l'ADR est la différence entre un pont de 2 ans et un dispositif permanent de 7 ans.

Décision de chemin de migration : BW Bridge vs. Datasphere greenfield vs. maintien on-prem BW/4HANA. La décision à trois branches est la conversation consulting centrale chez tout compte BW. Maintenir on-prem BW/4HANA : valide uniquement si le client n'a pas de mandat cloud et que l'estate BW est stable et totalement amorti. Rester on-prem est une décision de stratégie, pas une décision d'échéance : la maintenance de BW/4HANA court jusqu'en 2040 au moins, alignée sur SAP S/4HANA (annonce de maintenance SAP du 23 avril 2020). La pression vient de la direction prise vers BDC — et, s'il reste du BW 7.5 classique dans le parc, de son propre calendrier : maintenance mainstream jusqu'au 31 décembre 2027, extension payante jusqu'en 2030. Datasphere greenfield sans BW Bridge : le bon choix quand l'estate BW est petit (moins de 50 InfoProviders actifs, moins de 100 queries actives) ou quand l'entreprise accepte de geler le reporting pendant un sprint de migration — généralement 6 à 9 mois pour un petit estate. L'avantage est une architecture Datasphere propre dès le premier jour, sans double coût de runtime, sans dette d'objets legacy, et sans risque de fin de pont. BW Bridge : choisir quand l'estate est large (des centaines d'InfoProviders, des milliers de queries), que l'entreprise ne peut pas tolérer un gel du reporting, et qu'il existe un programme de modernisation financé sur 3 à 5 ans. Le pont n'est pas une destination — c'est une phase de coexistence limitée dans le temps. Le rôle du consultant est de rendre cette limite temporelle explicite dans l'ADR dès le lancement du projet.

Face à BW/4HANA Public Cloud Edition (PCE) : BW PCE est une instance BW/4HANA gérée dans le cloud SAP, pas Datasphere. Elle prolonge le runtime BW plus longtemps que l'on-prem mais ne donne pas l'intégration lakehouse BDC ni la couche sémantique Datasphere. BW Bridge vers Datasphere est le chemin vers BDC ; BW PCE est un lift d'infrastructure sans modernisation de la couche sémantique. Choisir PCE quand le moteur principal du client est la modernisation de l'infrastructure, pas la modernisation analytics.

La falaise de maintenance BW. Deux produits, deux horloges : SAP BW 7.5 sort de maintenance mainstream le 31 décembre 2027, avec une maintenance étendue payante en option jusqu'en 2030 (annonce de maintenance SAP du 23 avril 2020) — tandis que SAP BW/4HANA est maintenu, indépendamment, jusqu'en 2040 au moins, aligné sur SAP S/4HANA (même annonce). BW Bridge n'étend pas cette échéance — il prend fin avec le produit parent. BW Bridge hérite de l'horloge du produit qu'il exécute, et ce qui tourne dans Datasphere est BW/4HANA : le pont n'est donc pas ce qui expire. Un client encore sur BW 7.5 a une échéance datée et contractuelle ; un client BW/4HANA a une échéance stratégique — les vendre l'une pour l'autre se voit.

Où vit la mécanique. Cette fiche arbitre : faut-il un pont, contre quelle alternative, pour combien de temps et à quel coût permanent. Comment le pont fonctionne réellement — ce que l'outillage de transfert SAP transporte, quels extracteurs ODP continuent de l'alimenter sans réécriture, pourquoi l'ABAP spécifique doit être repris contre le jeu d'API libéré, et comment les CompositeProviders se présentent en tables distantes Datasphere — fait l'objet de la fiche jumelle, SAP BW Bridge : le runtime dans Datasphere.

L'angle de préparation IA, septembre 2026

La question de la date de sunset de BW Bridge n'est plus seulement un argument de coût — c'est aussi un argument de préparation IA, et nommer les deux ensemble dans la conversation ADR est nettement plus persuasif que le coût seul. Tout ce que la SAP Business AI Platform promet pour l'analytics — la couche de requête en langage naturel de Joule, l'ancrage du generative AI hub, le SAP Knowledge Graph qui lit les entités métier — tourne sur des data products BDC gouvernés exposés via Datasphere, pas sur des objets BW encore en cours d'exécution dans le runtime embarqué du bridge. Un advanced DataStore Object ou un CompositeProvider qui n'a pas encore été replateformé en modèle ou space Datasphere natif est, tant qu'il reste sur le bridge, invisible pour toute cette couche IA : Joule ne peut répondre à aucune question en langage naturel ancrée dessus, et le Knowledge Graph n'a rien de publié à lire.

Cela recadre la cadence de migration que cette fiche recommande déjà. Un sprint trimestriel de cinq à dix objets n'est pas seulement une discipline de maîtrise des coûts contre la double dépense CU-plus-licence — c'est aussi, objet par objet, le rythme auquel la donnée du client devient atteignable par le prochain agent Joule ou cas d'usage d'IA générative que le métier veut construire. Le BW Data Product Generator de SAP, un add-on qui convertit les InfoProviders BW/4HANA et le transfert de modèle BW/4HANA en vues et Analytic Models Datasphere gouvernés, existe précisément pour retirer le travail mécanique de traduction de ce sprint — ce qui reste manuel, c'est renommer les champs techniques en libellés métier, câbler les Data Access Controls, et compléter le data contract BDC, la même discipline d'annotation qui détermine aussi si Joule peut s'ancrer sur le résultat.

L'implication pratique pour le cadrage : quand un client demande pourquoi le bridge ne devrait pas simplement tourner indéfiniment à faible coût, la réponse de préparation IA est plus incisive que celle de licence. Un bridge à l'arrêt ne porte pas seulement une facture permanente — il gèle aussi la donnée du client hors de toute capacité IA que SAP déploie dans la plateforme vers laquelle ce parc est censé converger, pendant que les concurrents qui migrent dans les temps y arrivent en premier.

Ce que le marché des missions a demandé, du 27 septembre au 6 octobre 2026

Six des dix missions listées étaient en Allemagne et citaient directement BW/4HANA ou BW : un poste de consultant BW on HANA en interne à Heidelberg (60 % de télétravail), un chef d'équipe BI/BW, un Data Platform Consultant pour BW et data et analytics, un consultant senior BW/4HANA et Business Data Cloud, un développeur ABAP sécurité pour BW/4HANA, et un consultant BW / architecte solution à partir du 1er novembre 2026 pour 12 mois, à distance ou à Berlin. Le parc BW installé continue d'être staffé, pas seulement maintenu.
BW était régulièrement co-demandé avec la plateforme cible : BW/4HANA avec Business Data Cloud (Allemagne), BW avec data et analytics (Allemagne), un consultant « SAP BW / DataSphere » (Mexique) et un architecte Datasphere (États-Unis). Le profil recherché est celui qui sait tenir les deux côtés du pont.
Deux annonces belges, un analyste applicatif BW/HANA et un senior business and data analyst SAP BW, relèvent d'une demande côté exploitation : maintenir le contenu BW existant tant que la question de la migration reste ouverte.
Aucun des titres listés ne citait BW Bridge. Pour le praticien, l'arbitrage se plaide donc en compétences « BW plus Datasphere ou BDC » : une recommandation sur le bridge doit s'appuyer sur la profondeur BW/4HANA et sur la modélisation Datasphere, pas sur un vocabulaire propre au bridge.

Pourquoi c'est important

Les grands estates BW (1 000+ queries, 100+ InfoProviders) évitent un rip-and-replace de 18-24 mois qui casserait le reporting quotidien.
Sans date de fin documentée dans l'ADR, un pont de 2 ans devient silencieusement un dispositif permanent de 7 ans — le client paie capacity units Datasphere ET licence BW/4 tout du long.
En-dessous de 50 objets BW, la migration directe vers Datasphere est plus rapide et moins chère — provisionner BW Bridge y est du pur surcoût.

Points clés

Fait le pont entre le parc BW existant et le tenant Datasphere
Gagne 2-4 ans pour une migration objet par objet
Pertinent pour les parcs de 1 000+ requêtes ; perdant pour les petits parcs
Date de sunset inscrite dans l'ADR, pas ouverte
Cadence de migration de 5-10 objets/trimestre
Mélanger les couches DAC dans une même story = dérive
Deux horloges : BW 7.5 mainstream jusqu'en 2027 (extension payante 2030), BW/4HANA jusqu'en 2040 au moins (SAP, 23 avril 2020)
Migrations ABAP custom : complexité 3-5×

Sources

Ouvrir dans l'application →

BW Bridge : l'arbitrage de migration

Qu'est-ce que BW Bridge ?

Qu'est-ce que le BW bridge SAP ?

L'angle de préparation IA, septembre 2026

Ce que le marché des missions a demandé, du 27 septembre au 6 octobre 2026

Pourquoi c'est important

Points clés

Sources

Concepts liés

Modules d'académie associés

Études approfondies

Guides SAP analytics & TJM