Fiche concept

SAP Analytics Cloud (SAC)

À jour au 2026-10-10

É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 SAP Analytics Cloud (SAC) ?

Ce que c'est et pourquoi cela compte

SAP Analytics Cloud est la surface unique de SAP pour la business intelligence, la planification et l'analytique prédictive, et c'est la couche de consommation qui coiffe presque tous les déploiements Datasphere ou BDC. Les utilisateurs métier touchent SAC directement ; c'est aussi, sans gloire, l'endroit où atterrissent la plupart des tickets « pourquoi le tableau de bord est-il lent », parce que la frontière entre SAC et sa source de données est précisément l'endroit où les décisions d'architecture sur le push-down et la concurrence se paient réellement. Comprendre cette frontière, et pas seulement construire des stories, est ce qui distingue un architecte SAC senior de quelqu'un qui sait seulement glisser des champs sur un canevas.

Comment cela fonctionne : trois modes de connexion

Les stories SAC peuvent reposer sur trois modes de connexion distincts, et ce choix est le levier de performance et de coût le plus important de tout déploiement. La connexion Live interroge Datasphere ou HANA Cloud directement à chaque rendu — chaque visualisation correspond à une ou plusieurs requêtes SQL fédérées poussées vers le moteur source. Cela offre une fraîcheur temps réel au prix d'une latence typiquement comprise entre 100 et 500 ms en médiane, et d'un plafond pratique de concurrence d'environ 200 utilisateurs ad hoc simultanés par Analytic Model avant que la latence de queue ne se dégrade. La connexion Import, à l'inverse, rapatrie les données dans le cache en mémoire propre à SAC selon un planning ; les stories interrogent alors ce cache plutôt que la source, ce qui ramène la latence médiane sous 100 ms et fait grimper le plafond de concurrence à plusieurs milliers d'utilisateurs par modèle. Le prix à payer est l'obsolescence — la donnée n'est fraîche qu'à hauteur du dernier rafraîchissement, typiquement toutes les une à vingt-quatre heures — et une taille de cache plafonnée, environ 5 Go par modèle par défaut, quoique relevable. Les connexions Hybrid combinent les deux : Live pour la tranche volatile des données, Import pour la tranche historique stable, jointes au niveau de la story.

Quand utiliser chaque mode — les arbitrages

La décision est rarement « lequel est le meilleur » et presque toujours « quel arbitrage cette audience tolère-t-elle ». Un contrôleur de gestion qui surveille un chiffre opérationnel en temps réel se soucie davantage de la fraîcheur que de la vitesse brute, donc la connexion Live s'impose, quitte à accepter la latence et le plafond de concurrence plus bas. Un tableau de bord exécutif consulté par deux mille personnes une fois par semaine se soucie bien davantage d'un chargement instantané que d'une fraîcheur à la seconde près — la connexion Import est le choix évident, et la fenêtre d'obsolescence reste invisible pour cette audience. Dès qu'un déploiement franchit environ deux cents utilisateurs simultanés tout en ayant aussi besoin d'un peu de fraîcheur, l'Hybrid devient le schéma par défaut de la plupart des déploiements d'entreprise : garder les chiffres qui bougent vite en Live, mettre en cache la base historique. L'anti-pattern consiste à choisir la connexion Live par défaut parce qu'elle « paraît plus correcte » — pour un tableau de bord à large audience, cette seule décision peut être la cause racine complète d'un ralentissement lié à la concurrence, qui sera ensuite diagnostiqué à tort comme un problème de performance de Datasphere.

SAC face à Power BI face à Tableau est une comparaison qui revient dans presque tous les arbitrages de frontal BI, mais l'arbitrage qui compte n'est pas la qualité de la visualisation — SAC est le seul des trois à intégrer nativement un moteur de planification à écriture, dans la même famille d'outils et de licence. Choisir SAC uniquement pour la BI alors que l'organisation ne dispose d'aucune couche sémantique centrée SAP à consommer est un argument plus faible que de le choisir spécifiquement parce que des Analytic Models Datasphere existent déjà et que la planification figure à la feuille de route.

Le schéma d'association SAC-Datasphere

L'architecture canonique de niveau 1 utilise les Analytic Models de Datasphere comme couche sémantique gouvernée et les stories SAC purement comme surface de restitution. Chaque Analytic Model porte la logique métier qui doit rester cohérente partout — conversion de devise, mesures restreintes, sémantique des hiérarchies, lignes protégées par les Data Access Controls — et les stories SAC se contentent de piocher dans ce que le modèle expose. La règle d'architecture que les équipes expérimentées appliquent sans exception : ne jamais pointer une story SAC directement vers une vue SQL Datasphere brute ; toujours l'envelopper d'abord dans un Analytic Model. La raison n'est pas une préférence de style, c'est la cohérence. Si cinq stories différentes réimplémentent chacune la conversion de devise ou un filtre de mesure restreinte de manière indépendante, elles finiront par diverger, et personne ne pourra expliquer pourquoi deux chiffres « identiques » sur deux tableaux de bord ne correspondent pas.

Pièges et anti-patterns

Au-delà de l'anti-pattern de la vue brute, les deux échecs récurrents sont la prolifération de stories et l'obsolescence silencieuse. La prolifération de stories survient quand chaque analyste construit sa propre story personnelle au lieu de consommer une story gouvernée, si bien que la même métrique finit calculée de cinq façons légèrement différentes à travers le tenant — un échec de gouvernance déguisé en activation du libre-service. L'obsolescence silencieuse survient quand le planning de rafraîchissement d'une connexion Import se casse discrètement — un job en échec, un identifiant expiré — et que personne ne s'en aperçoit avant qu'un utilisateur métier ne signale que « les chiffres semblent faux » ; traiter le job de rafraîchissement lui-même comme une infrastructure surveillée et alertante, plutôt que comme une planification qu'on lance et qu'on oublie, est le remède. Un troisième piège est le sous-dimensionnement pour la concurrence : les équipes dimensionnent un Analytic Model pour les dix utilisateurs du pilote et ne reviennent jamais sur le choix du mode de connexion à mesure que le déploiement passe à l'échelle vers des centaines d'utilisateurs, ce qui est exactement le point où le plafond d'environ 200 utilisateurs de la connexion Live cesse d'être une note de bas de page pour devenir un incident.

La couche « just ask » de Joule dans SAC, et son nouveau prérequis opérationnel

La capacité d'insights analytiques de Joule dans SAP Analytics Cloud repose sur une fonctionnalité « just ask » qui indexe les modèles SAC pris en charge plus tout modèle analytique SAP Datasphere faisant partie d'une formation BDC — ce qui signifie que la question en langage naturel qu'un utilisateur métier tape dans Joule trouve sa réponse en lisant la même couche sémantique gouvernée sur laquelle cette fiche recommande de construire toute story SAC, pas une copie séparée des données spécifique à l'IA (help.sap.com ; community.sap.com, 2026). C'est la raison concrète pour laquelle la règle architecturale du corps de cette fiche — ne jamais exposer une vue Datasphere brute directement à SAC, toujours l'envelopper dans un Analytic Model — porte désormais des enjeux de consommation IA en plus des enjeux de consommation BI : une story construite sur une vue brute est invisible ou incohérente pour l'indexation « just ask » de Joule exactement comme elle l'est pour une seconde story construite par un humain.

Le détail opérationnel à signaler à tout client qui exploite ou envisage cette intégration : la version Joule 2506 a introduit un prérequis cassant exigeant SAP Build Work Zone pour provisionner et synchroniser les utilisateurs et rôles de SAC vers Work Zone afin que l'intégration d'analytique conversationnelle continue de fonctionner (SAP Community, 2026). C'est exactement le type de dépendance que le piège « fonctions en accès anticipé vendues comme disponibles » de cette fiche (voir C024) signale — une conversation de cadrage qui a chiffré « Joule dans SAC » sans vérifier si le client exploite déjà Work Zone, ou si son provisionnement est dans le périmètre, découvrira l'écart après la mise en production plutôt que pendant le chiffrage. Confirmer la présence de Work Zone, ou son coût d'ajout, avant de proposer un engagement Joule-dans-SAC à prix fixe.

Côté prédictif, que cette fiche couvre déjà (Smart Predict pour les workflows de citizen-data-scientist, Databricks pour le ML complexe), la Business AI Platform plus large porte désormais aussi les modèles de fondation tabulaires de SAP — SAP-RPT-1.6 et RPT-1.6-large sont la génération actuelle sur generative AI hub à septembre 2026, aux côtés d'un workflow géré de Tabular Orchestration et d'une API RPT Playground (jusqu'à 1 000 requêtes/heure) pour l'expérimentation. Ils se situent architecturalement entre la simplicité de Smart Predict et le poids complet d'ingénierie ML de Databricks : un modèle à apprentissage en contexte qui prédit à partir d'une table étiquetée au moment de l'inférence, sans étape d'entraînement — à nommer comme une troisième option prédictive dans une conversation de cadrage plutôt que de se rabattre directement sur le binaire Smart-Predict-ou-Databricks que cette fiche cadre actuellement — le bon choix dépend de si le besoin prédictif du client se rapproche de « rapide, tabulaire, sans équipe ML » (RPT), « gouverné, reproductible, convivial pour le citizen dans SAC » (Smart Predict), ou « sur mesure, grande échelle, porté par une équipe ML » (Databricks).

Ce qui a changé depuis fin septembre 2026

28 septembre 2026 — add-in Excel 2026.21 (documentation primaire SAP). La conversion de devises peut désormais être définie et gérée directement dans le classeur : une nouvelle action Add Currency Conversion sur la dimension Mesure ou Structure, disponible lorsque le modèle SAC sous-jacent prend en charge la conversion de devises, produit un membre calculé (membre source, devise cible, catégorie, date) utilisable comme n'importe quelle mesure. Cela confirme le propos de la fiche : la logique de conversion doit résider dans le modèle, puisque l'add-in la lit désormais à cet endroit.
28 septembre 2026 — même version. Un nouveau paramètre optionnel Enable advanced data retrieval (incl. optimized retrieval) recourt au regroupement (clustering) des données pour réduire le risque de dépasser les limites du serveur sur les gros classeurs. Il n'est pas activé par défaut afin de ne pas affecter les classeurs existants.

Mise à jour du 10 octobre 2026

8 oct. 2026 - chemin de montée de version SAC Planning (ERP Today, source primaire SAP non lue). Après SAP Connect, les clients SAC Planning peuvent évoluer vers SAP Enterprise Planning ; les clients Group Reporting peuvent ajouter le Financial Consolidation Assistant ou migrer ; des services de migration BPC et BFC sont prévus à partir du T1 2027, et les applications EPM sont packagées avec la capacité cœur de BDC. Pour un client SAC Planning, c'est une option datée, pas une raison de replateformer maintenant : gardez le modèle de planification actuel stable et inscrivez les livrables du T1 2027 au calendrier de décision.
8 oct. 2026 - formation. La SAP Community annonce que les tutoriels vidéo SAC ont été entièrement mis à jour pour Horizon.
Ce qui n'a pas changé. Les sources examinées ne contiennent aucune annonce SAC propre à Connect : les recommandations ci-dessus sur l'add-in Excel et Datasphere restent valables.

Pourquoi c'est important

Les connexions Live plafonnent à environ 200 utilisateurs ad hoc simultanés par Analytic Model avant que la latence de queue ne se dégrade — au-delà, Import ou Hybride devient nécessaire.
Le mode Import échange la fraîcheur contre l'échelle (milliers d'utilisateurs, sous les 100 ms) mais laisse la donnée obsolète entre rafraîchissements, typiquement 1 à 24 h — inadapté au reporting gouverné temps réel.
Sauter l'enveloppe Analytic Model casse la cohérence de la conversion de devise, des restrictions et des mesures calculées dont dépendent les stories SAC.

Points clés

Trois modes : Live (push-down, < 200 user, temps réel) · Import (cache, milliers d'utilisateurs, données figées) · Hybrid (les deux).
Toujours envelopper les vues Datasphere raw dans un Analytic Model avant de les exposer à SAC.
Planning est le différenciateur SAP — write-back, contrôle de version, audit, réconciliation top-down/bottom-up.
Prédictif : Smart Predict pour le citizen-data-scientist + les cas simples ; Databricks pour le data scientist + le ML complexe.
Le DAC au niveau de Datasphere est la source de vérité pour la sécurité des lignes — il atteint SAC + Joule + Delta + OData.
Plafond de concurrence en mode Live : ~200 simultanés ; hybrid au-delà.
Joule lit les métadonnées des stories SAC + les Analytic Models Datasphere pour du Q&A en langage naturel avec citations.
SAC est facturé séparément des CU Datasphere (modèle par utilisateur nommé / par utilisateur simultané).

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.