Fiche concept

SAC Planning (planification SAP Analytics Cloud) — ce que c'est et quand l'utiliser

À jour au 10 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 SAC Planning (planification SAP Analytics Cloud) ?

« SAC Planning » est une expression que l'on cherche avant de savoir laquelle des cinq choses on veut dire.

« SAC Planning » est une expression que l'on cherche avant de savoir laquelle des cinq choses on veut dire. Cette page est la carte : ce qu'est réellement la capacité, les quatre briques que porte tout déploiement, comment elle passe d'un analyste seul à un cycle budgétaire à cinquante centres de coûts, et quand un outil de planification dédié est la réponse honnête à la place.

Ce que c'est, en une distinction

Un tableau de bord BI lit. Un Planning Model lit et écrit. C'est toute la différence, et c'est la seule capacité de la famille SAP Analytics Cloud sans équivalent dans Power BI ou Tableau, sauf à acheter un produit de planification dédié comme Anaplan, Pigment ou OneStream.

Concrètement : des jeux de données multi-versions, bornés dans le temps et tracés en audit, où les utilisateurs finance et opérations saisissent prévisions, budgets et inducteurs, pendant que la plateforme calcule les valeurs dérivées en temps réel. Un analyste saisit au niveau cellule, un planificateur joue des scénarios, la finance clôt une version et cette version devient un historique permanent et auditable.

Les quatre briques

Le modèle est le schéma — dimensions, mesures, temps et version — stocké dans HANA avec un journal d'audit complet.

Une version est un état nommé de ce modèle : Réalisé, Budget, Prévision T3, What-If Pessimiste. La juxtaposition de plusieurs versions dans une même vue est native, pas un contournement.

Une dimension publique est partagée entre modèles — Centre de coûts, Produit, Temps, Devise — de sorte qu'un changement de structure se propage partout où elle est utilisée au lieu d'être répété modèle par modèle.

Une allocation est l'algorithme qui répartit une valeur sur une dimension : descendante, ascendante ou par inducteur. C'est ainsi qu'un objectif corporate devient mille chiffres par centre de coûts, et que mille saisies ascendantes remontent en un chiffre de comité.

Où ça va une fois que ça marche

Deux directions, et chacune est un concept à part qu'il vaut mieux lire avant de promettre quoi que ce soit.

Collaborative Planning est la couche multi-utilisateurs pilotée par workflow — la réponse à la question que tout responsable FP&A finit par poser : comment un cycle budgétaire à cinquante centres de coûts tourne-t-il réellement dans l'outil ? C'est ce qui fait passer SAC Planning du statut de remplaçant de tableur pour un analyste à celui d'application capable d'orchestrer des centaines de participants dans une hiérarchie d'approbation définie et auditable.

Seamless Planning (généralement disponible depuis la version SAC du T1 2025), c'est SAC Planning dont les données de modèle sont persistées dans SAP Datasphere : le modèle est construit et exploité dans SAC, ses données de faits et de référence vivent dans un space Datasphere, il n'y a aucune réplication entre les deux, et les versions de plan sont lisibles par les vues Datasphere dès leur enregistrement. Il n'écrit pas de valeurs de plan dans S/4HANA — c'est un export SAC distinct — mais c'est ainsi qu'un « sortez-nous d'Excel » devient un programme Datasphere + SAC plutôt qu'un changement d'outil (voir C020).

Quand SAC Planning est le bon choix — et quand il ne l'est pas

Trois facteurs tranchent : à quel point la planification doit être collée aux réalisés issus de Datasphere, à quel point l'organisation investit déjà dans la pile analytique SAP, et à quel point la logique de planification doit être sophistiquée.

SAC Planning gagne nettement quand les réalisés vivent déjà dans Datasphere et que l'organisation veut l'analyse d'écart Réalisé/Plan dans la même famille d'outils, sans couche d'intégration séparée à construire et maintenir.

C'est le choix le plus faible quand la logique de planification est elle-même la partie difficile et que le parc SAP est accessoire. Le Planning Survey de BARC — même méthodologie que son cousin BI, des milliers d'utilisateurs finaux notant des dizaines de KPI, segmentés par groupe de pairs — le dit sans détour : SAC Planning se classe fortement là où l'intégration S/4HANA compte, et plus faiblement sur l'ergonomie face à Anaplan et Pigment dans les groupes de planification opérationnelle. Citez le groupe de pairs, ou ne citez pas l'enquête.

Pièges

Vendre la planification comme une montée de version du reporting. C'est une discipline différente, avec d'autres utilisateurs, un autre cycle et un autre mode de panne ; une équipe qui la pose en « SAC phase deux » découvre les exigences de workflow au troisième mois.

Modéliser des dimensions par modèle. Les dimensions locales paraissent plus rapides le premier jour et coûtent un projet de restructuration à la première évolution du Centre de coûts. Les dimensions publiques existent pour cela.

Promettre Seamless Planning sur un paysage sans tenant Datasphere lié (un tenant SAC ↔ un tenant Datasphere, même data center, SAC sur HANA Cloud) — ou le vendre comme un write-back S/4. Toute sa valeur est le plan persisté dans Datasphere ; sans cela, c'est du SAC Planning ordinaire avec un meilleur nom.

Sauter la discipline des versions. Si personne ne définit qui peut clore une version et quand, le journal d'audit enregistre fidèlement un désordre.

L'angle Joule, septembre 2026

Deux capacités GA changent la façon dont un projet de planification se cadre en 2026. D'abord, Joule est désormais intégré directement dans l'interface de Datasphere elle-même (GA, documentation help.sap.com datée du 24/09/2026) pour la navigation en langage naturel et les questions-réponses inter-spaces — ce qui compte spécifiquement pour Seamless Planning, car une fois que les données de faits et de référence d'un modèle de plan vivent dans un space Datasphere, ces données deviennent interrogeables par la même couche conversationnelle qu'un analyste utilise déjà pour les Actuals, sans intégration séparée. Ensuite, les « just ask » insights analytiques de Joule dans SAC indexent les modèles SAC pris en charge plus les modèles analytiques Datasphere qui font partie d'une formation BDC — un planificateur peut donc, en principe, poser une question de variance Actual-vs-Plan en langage naturel et la voir résolue à la fois contre le Planning Model et les Actuals Datasphere liés en une seule passe, ce qui est le gain pratique que Seamless Planning a été conçu pour permettre. Le piège de cadrage à signaler d'emblée : la version 2506 de Joule a ajouté un prérequis dur — SAP Build Work Zone doit provisionner et synchroniser les utilisateurs et rôles depuis SAC vers Work Zone — pour que cette intégration d'analytique conversationnelle continue de fonctionner ; un programme de planification qui promet « demandez à Joule votre budget » sans couche d'identité synchronisée avec Work Zone promet une fonctionnalité cassée, pas cadrée.

Ce qui ne change pas, c'est la distinction centrale sur laquelle s'ouvre la fiche. La couche en langage naturel de Joule est une surface de lecture et de navigation sur le modèle ; elle n'effectue pas le write-back, ne fait pas tourner l'allocation, et ne clôture pas une version — cela reste la mécanique déterministe et auditée de SAC Planning, et aucun vernis conversationnel ne remplace la discipline de gouvernance des versions déjà nommée dans la section Pièges. Là où un schéma véritablement nouveau émerge, à surveiller plutôt qu'à promettre comme livré, c'est l'usage d'un modèle de fondation tabulaire — SAP-RPT-1.6, GA depuis septembre 2026 sur la bibliothèque de modèles du generative AI hub — pour générer une prévision de référence statistique pour un driver (une tendance de revenu, un run-rate de centre de coûts) qu'un planificateur charge ensuite comme Version de départ et ajuste via le workflow normal d'allocation et d'approbation. SAP n'a pas publié ceci comme un schéma d'intégration SAC Planning livré à l'heure où ces lignes sont écrites ; à traiter comme une extension architecturalement plausible à signaler à un client qui évalue sa feuille de route IA, pas comme une fonctionnalité à cadrer dans un statement of work.

Pour les conversations tarifaires : tout usage de Joule contre un modèle de planification — questions-réponses copilote ou, à terme, un agent agissant sur un plan — est mesuré en AI Units comme toute autre consommation d'IA Premium sur la plateforme ; vérifier le coût AI Units en vigueur et les conditions de mutualisation de Joule for Consultants avant de chiffrer un périmètre planification-plus-IA, car le modèle de SAP tarife ce que l'assistant fait, pas ce que le tenant de planification licence déjà.

SAP Connect 2026 (oct. 2026)

Connect n'a pas annoncé de nouvelle fonction SAC Planning (aucune n'a été trouvée dans les sources consultées), mais a modifié la feuille de route autour. Selon ERP Today, SAP positionne SAP Enterprise Planning (lancé à Sapphire en mai 2026) avec la nouvelle SAP Enterprise Financial Consolidation comme plateforme EPM « Autonomous Performance Management » sur Business Data Cloud ; les clients SAC Planning peuvent passer à Enterprise Planning ; des services de migration BPC et BFC sont prévus à partir du T1 2027, les applications EPM sont packagées avec la capacité cœur BDC et les Joule Assistants se consomment en AI Units. Ces dates et conditions de packaging proviennent de la presse indépendante ; la page SAP n'a pas été lue et aucune grille de prix n'existe.

À en faire : garder SAC Planning comme réponse livrée pour les programmes 2026, et ajouter une question datée « passage à Enterprise Planning » à toute feuille de route de planification pluriannuelle, sans la promettre. SAP n'a pas annoncé de fin de vie de SAC Planning dans les sources consultées.

Pourquoi c'est important

La planification est la seule capacité SAC sans équivalent gratuit dans le groupe BI, et la plus souvent vendue comme une montée de version du reporting — c'est ainsi qu'un cycle budgétaire découvre ses exigences de workflow au troisième mois.

Points clés

Un dashboard BI lit ; un Planning Model lit ET écrit — multi-version, borné dans le temps, avec piste d'audit.
C'est la seule capacité SAC sans équivalent dans Power BI ou Tableau sans acheter Anaplan, Pigment ou OneStream.
Quatre briques : le model (schéma dans HANA avec piste d'audit complète), la version, la dimension publique, l'allocation.
Une version est un état nommé — Actuals, Budget, Forecast Q3, What-If Pessimiste — et le blending de plusieurs versions dans une même vue est natif.
Les dimensions publiques propagent un changement structurel partout où elles sont utilisées ; les dimensions locales par modèle achètent de la vitesse au jour 1 et un projet de restructuration plus tard.
Une allocation transforme un objectif corporate unique en mille chiffres par centre de coût, ou remonte mille saisies bottom-up en un seul chiffre de conseil d'administration.
Collaborative Planning est la couche de workflow qui fait tourner un cycle budgétaire à cinquante centres de coûts avec une hiérarchie d'approbation auditable.
Seamless Planning (GA T1 2025) : le modèle est construit dans SAC, ses données sont persistées dans Datasphere — une seule copie, aucune réplication, pas de write-back S/4 (voir C020).
SAC Planning gagne quand les Actuals vivent déjà dans Datasphere et que l'analyse Actual-vs-Plan est voulue dans une seule famille d'outils.
BARC Planning Survey : fort là où compte l'intégration S/4HANA, plus faible en facilité d'usage face à Anaplan et Pigment sur la planification opérationnelle — citez le GROUPE DE PAIRS.
SAP Connect (oct. 2026) : aucune nouvelle fonction SAC Planning trouvée ; selon ERP Today les clients SAC Planning peuvent passer à SAP Enterprise Planning, apps EPM packagées avec la capacité cœur BDC (feuille de route T1 2027) — presse indépendante, pas de grille de prix.

Pièges courants

Planification vendue comme une mise à niveau de reporting — Signal : Elle est cadrée comme « SAC phase deux ». Correctif : La cadrer comme sa propre discipline — utilisateurs, cycle, et mode d'échec différents ; obtenir les exigences de workflow en amont.
Dimensions locales par modèle — Signal : Centre de coûts défini séparément dans trois modèles. Correctif : Des dimensions publiques, pour qu'un changement structurel se propage au lieu de forker.
Seamless Planning sans tenant Datasphere lié — Signal : Seamless Planning est dans la présentation ; le lien 1:1 des tenants SAC ↔ Datasphere (même data center) n'est pas dans le paysage — ou le client attend des valeurs de plan dans S/4HANA. Correctif : Lier d'abord les tenants et cadrer tout export S/4 à part, ou arrêter de l'appeler Seamless Planning.
Aucune gouvernance de version — Signal : N'importe qui peut clôturer une version. Correctif : Nommer qui clôture et quand — la piste d'audit enregistre le désordre aussi fidèlement que l'ordre.
Score BARC agrégé cité — Signal : Un seul chiffre de planification, aucun groupe de pairs. Correctif : Citer le segment : la force d'intégration S/4 et la faiblesse d'utilisabilité opérationnelle sont des constats différents.

Cadre de décision

Cadre de décision
Décision	Option A	Choisir A quand	Option B	Choisir B quand
L'écriture retour est-elle requise	Oui — les utilisateurs saisissent des chiffres	C'est de la planification. Un outil BI ne peut pas le faire sans un produit payant séparé.	Non — analyse en lecture seule	Ne pas acheter de planification. Une story sur un modèle Datasphere est la réponse la moins chère et la plus simple.
Où résident les réalisés	Datasphere / BDC	SAC Planning est l'argument fort — l'analyse d'écarts reste dans une seule famille d'outils.	Hors du parc SAP	Envisager un outil de planification dédié ; l'argument d'intégration qui favorise SAC est absent.
Combien de participants	Un analyste ou une petite équipe	SAC Planning de base suffit.	Des dizaines de centres de coûts, chaîne d'approbation	Vous avez besoin de Collaborative Planning — planifier le workflow avant le modèle.
Portée de la dimension	Dimensions publiques	Par défaut. Un changement se propage partout où c'est utilisé.	Dimensions locales au modèle	Seulement pour des concepts réellement mono-modèle — sinon vous programmez une restructuration.
Promettez-vous Seamless Planning	Tenants SAC et Datasphere liés 1:1	Oui — le plan est persisté dans Datasphere et y est lisible dès son enregistrement ; c'est le différenciateur.	Pas de tenant Datasphere lié	Non. Sans la persistance Datasphere, c'est du SAC Planning ordinaire avec un meilleur nom.

Chiffres à citer

SAC Planning est licencié comme un palier séparé, plus cher que SAC BI — typiquement 2-3x le coût par utilisateur du palier BI.
Les consultants spécialisés en SAC Planning commandent généralement une prime de TJM de 15-25 % par rapport aux consultants BI seul.
Dans un modèle de planification SAC classique, le motif d'intégration recommandé réplique les Actuals de Datasphere vers SAC Planning en fin de mois et n'écrit jamais en retour de Planning vers Datasphere — une discipline à sens unique qui garde la propriété du système de référence sans ambiguïté. Seamless Planning (C020) supprime ce tronçon : le plan est persisté dans Datasphere par construction.
Les formulaires de saisie SAC peuvent être verrouillés à trois granularités distinctes : version entière, membre individuel, ou mesure individuelle.
Les Data Access Controls (DAC) partitionnent le périmètre de planification par attributs tels que centre de coûts, région, ou unité métier — exigé pour la séparation des tâches conforme à SOX.
Les commentaires SAC sont au niveau cellule, rattachés à une intersection de données spécifique (par exemple centre de coûts x mesure x période), prennent en charge les réponses en fil, et persistent à travers les soumissions de version.

Sources

Ouvrir dans l'application →

Missions ouvertes

21 postes et missions SAC Planning ouverts en ce moment — voir les missions SAC Planning · missions freelance SAP.