SAP Datasphere vs BW/4HANA : Quelle architecture choisir en 2026 ?

Introduction

En 2026, les projets d’analytique en mode cloud continuent de gagner du terrain, notamment dans les pays du Maghreb où les exigences de conformité (RGPD, loi 09-08 sur la protection des données) et de performance sont élevées. Les consultants SAP au Maroc doivent donc maîtriser les deux plateformes majeures : SAP Datasphere (anciennement SAP Data Warehouse Cloud) et SAP BW/4HANA. Ce document compare les deux solutions sur les axes d’architecture, de coût, de flexibilité, de gouvernance et de cas d’usage, afin de guider votre décision d’implémentation.

1. Vue d’ensemble des deux plateformes

2. Architecture cible recommandée en 2026

2.1. Architecture hybride « Data Lake + Data Warehouse as a Service (DWaaS) »

flowchart TD
    subgraph Cloud[Cloud Landscape]
        S4HANA[S/4HANA Cloud]
        SF[SuccessFactors]
        Snow[Snowflake Data Lake]
        DS[SAP Datasphere]
    end
    subgraph OnPrem[On‑Premise Landscape]
        BW[BW/4HANA]
        ABAP[ABAP Stack]
    end
    S4HANA -->|ODS/CDC| DS
    SF -->|OData| DS
    Snow -->|Federated Tables| DS
    DS -->|Virtual/Composite Views| BW
    BW -->|Open Hub Export| DataMart[Data Mart on‑prem]
    ABAP -->|Custom Extraction| BW

Principes clés - Ingestion : les sources transactionnelles (S/4HANA, SuccessFactors) sont répliquées en temps réel via SAP SLT ou OData vers Datasphere. - Lake‑house : les gros volumes bruts restent dans le Data Lake (Snowflake, Azure Data Lake) et sont federated dans Datasphere grâce aux remote tables. - Modélisation : les modèles de reporting standard (Finance, Supply Chain) sont créés dans BW/4HANA (CompositeProviders) pour profiter de la puissance de calcul HANA on‑prem. Les modèles ad‑hoc et les data‑science notebooks résident dans Datasphere. - Consommation : Tableau, Power BI, SAP Analytics Cloud (SAC) se connectent indifféremment à BW/4HANA ou Datasphere via ODBC/JDBC ou les services OData.

2.2. Quand choisir une architecture pure BW/4HANA ?

• Contraintes de souveraineté : si la réglementation marocaine impose que les données restent sur le territoire et que le client ne souhaite pas de cloud public.
• Investissement existant : infrastructures HANA déjà en place, licences BW/4HANA sous contrat de maintenance.
• Performance ultra‑low latency : besoins de reporting en temps réel sur des volumes < 1 TB.

2.3. Quand choisir une architecture pure Datasphere ?

• Start‑up ou PME : budget OPEX limité, besoin d’une mise en œuvre rapide (< 3 mois).
• Scénario de data‑science : utilisation de SAP Data Warehouse Cloud + SAP Data Intelligence pour le Machine Learning.
• Multi‑cloud : besoin de fédérer des sources hétérogènes (Snowflake, Azure Synapse, Google BigQuery).

3. Exemple pratique : Migration d’un modèle BW/4HANA vers Datasphere

3.1. Contexte

Une société de distribution marocaine possède un InfoProvider ZFI_SALES dans BW/4HANA contenant les ventes par région. Le client souhaite exposer ces données dans SAP Analytics Cloud via un modèle Live et réduire les coûts d’infrastructure.

3.2. Étapes de migration

1. Export du modèle BW

   *Export du CompositeProvider en XML
   CALL '/BIC/PROV_EXPORT'
     EXPORTING
       i_cprovider = 'ZFI_SALES'
       i_format    = 'XML'
     IMPORTING
       e_xml       = lv_xml.
   

2. Création d’une Remote Table dans Datasphere

   CREATE REMOTE TABLE ZFI_SALES_REMOTE (
       SALES_ORG   NVARCHAR(10),
       REGION      NVARCHAR(50),
       SALES_AMT   DECIMAL(15,2),
       SALES_DATE  DATE
   ) WITH CONNECTION "BW_CONNECTION";
   

3. Mapping du schéma (Data Builder → Semantic Layer)

   • Import du XML via l’assistant Import BW Model de Datasphere.
   • Ajustement des attributs (ex. conversion de CURR → DECIMAL).
4. Publication vers SAC
   • Créez un Live Connection depuis SAC → Datasphere → Model ZFISALESREMOTE.
   • Vérifiez les performances (latence < 200 ms).

3.3. Bonnes pratiques

• Activer le Push‑down sur la connexion BW → Datasphere pour que les filtres soient exécutés côté HANA.
• Utiliser les Semantic Tags (ex. @Analytics.Area = 'Finance') afin de faciliter la gouvernance.
• Planifier les sauvegardes via les snapshots de SAP HANA Cloud (rétention 30 jours).

4. Comparaison des coûts (exemple 2026 – Maroc)

Note : les tarifs sont indicatifs et varient selon le contrat SAP et l’hyperscaler choisi.

5. Gouvernance et sécurité

• Datasphere utilise le SAP Business Technology Platform (BTP) Identity Authentication Service (IAS) – SSO SAML, MFA, et authorisation basée sur scopes.
• BW/4HANA repose sur les authorisations ABAP (R‑authorizations, S‑authorizations) et les Data Access Controls.
• Recommandation : centraliser les rôles dans SAP Identity Management et les répliquer via SCIM vers les deux environnements pour garantir la cohérence.

6. Checklist de décision pour le consultant marocain

7. Conclusion

En 2026, SAP Datasphere s’impose comme la plateforme de choix pour les projets d’analytique cloud, d’intégration multi‑source et de data‑science, grâce à sa flexibilité et son modèle OPEX. SAP BW/4HANA reste pertinent pour les organisations ayant des contraintes de souveraineté, des investissements HANA existants ou des besoins ultra‑performants. La plupart des clients marocains bénéficieront d’une architecture hybride, où Datasphere agit comme couche d’accès et de gouvernance, tandis que BW/4HANA assure les modèles de reporting consolidés et les charges de travail critiques.

Prochaine étape : réaliser un proof‑of‑concept (POC) de 4 semaines en créant un Remote Table Datasphere depuis votre système BW/4HANA, mesurer la latence et le coût, et présenter les résultats au comité de pilotage.

Auteur : Senior SAP BI Consultant – spécialité Data Warehouse – basé à Casablanca