OLAP désigne un mode d’analyse destiné à lire, croiser et agréger des données historiques selon plusieurs axes. OLTP traite au contraire les opérations unitaires du quotidien. La différence OLAP OLTP détermine le modèle de données, la fréquence des mises à jour, le niveau de détail disponible et la façon de construire vos rapports.
En bref
- Un système OLAP sert aux rapports, aux analyses de tendances et aux calculs complexes sur des données consolidées.
- Un système transactionnel OLTP enregistre les ventes, les commandes, les mouvements de stock ou les modifications de comptes au fil de l’eau.
- Le cube OLAP organise les mesures selon des dimensions, telles que le temps, le produit, l’organisation ou le canal de vente.
- Les opérations OLAP permettent de passer d’une vue synthétique à un détail contrôlé, sans transformer un rapport en extraction brute.
- Dans un chantier de migration, la règle de gestion portée par une agrégation doit être recensée avant toute reprise du modèle sémantique.
Ce contenu s’adresse aux responsables BI, chefs de projet décisionnel et équipes métier qui doivent distinguer les usages analytiques des usages opérationnels. Il ne traite ni la conception d’algorithmes prédictifs ni l’architecture d’infrastructure pour elle-même.
Que recouvre la définition OLAP dans une base de données décisionnelle ?
OLAP signifie Online Analytical Processing, soit traitement analytique en ligne. Le terme désigne une organisation de données et de requêtes pensée pour l’analyse multidimensionnelle. L’objectif n’est pas d’enregistrer une commande supplémentaire ou de modifier un statut client. Il consiste à lire des volumes consolidés, à comparer des périodes et à comprendre les écarts d’activité.
Dans une base de données décisionnelle, un responsable financier peut demander le chiffre d’affaires par mois, par famille de produits, par canal et par entité. Ces axes ne sont pas de simples colonnes affichées côte à côte. Ils constituent des dimensions de lecture. La mesure, par exemple le montant facturé, est analysée à l’intersection de ces dimensions.
Le mot « en ligne » mérite une précision. Il ne signifie pas que les données sont nécessairement mises à jour à chaque transaction. Il signifie que l’utilisateur accède à une analyse interactive, au moyen d’un rapport, d’un tableau croisé, d’un outil de restitution ou d’un modèle sémantique. Une actualisation nocturne reste fréquente dans les socles décisionnels issus d’applications opérationnelles.
Pourquoi l’OLAP privilégie la lecture et les rapprochements
Une requête analytique porte souvent sur un périmètre beaucoup plus large qu’une opération métier. Elle peut lire plusieurs années de ventes, rapprocher des budgets et des réalisés, puis ventiler l’écart par centre de coût. Ce type de demande mobilise des jointures, des filtres, des hiérarchies, des mesures calculées et des fonctions d’aggregation.
La documentation Oracle décrit les outils OLAP comme orientés vers les requêtes et le reporting, par opposition aux applications OLTP dédiées aux tâches transactionnelles. Cette distinction est rappelée par la présentation Oracle de l’OLAP, consultée le 24 mars 2026. Elle reste utile pour éviter une confusion fréquente dans les dossiers de remplacement d’outils.
Une base analytique ne remplace pas l’application qui valide une commande ou qui réserve un article. Elle reçoit les données de cette application, les contrôle, les historise et les rend comparables. Lorsque la clôture mensuelle doit expliquer une variation de marge, le besoin relève du décisionnel. Lorsque le magasin doit confirmer qu’un produit est encore disponible, le besoin relève du transactionnel.
L’OLAP prend tout son intérêt lorsque l’utilisateur doit naviguer dans une information agrégée sans demander une nouvelle extraction à l’équipe BI à chaque question. Les restitutions ne sont pourtant fiables que si les règles de calcul sont documentées. Un chiffre d’affaires peut exclure les avoirs, les commandes annulées ou certains statuts de facture. Ces choix doivent rester visibles dans le modèle.
Les règles de gestion restent plus importantes que le moteur
Un cube performant ne corrige pas une définition métier ambiguë. Une mesure appelée « ventes nettes » peut correspondre à des réalités différentes selon qu’elle inclut les remises, les frais de port ou les retours. Dans BusinessObjects, une condition peut aussi être placée dans un objet d’univers plutôt que dans le rapport Webi. L’utilisateur voit alors un résultat filtré sans voir la règle qui l’a produit.
La reprise d’un socle demande donc de relever les objets, les classes, les contextes de requête et les filtres implicites. Le travail de recensement des règles de gestion dans un univers BusinessObjects évite de migrer une apparence de rapport tout en perdant son calcul réel.
Le terme OLAP ne garantit ni la qualité des données ni l’unicité des indicateurs. Il décrit une capacité d’exploration. Si deux rapports affichent des marges distinctes, le problème peut venir de la date retenue, du taux de change, du statut de commande ou du périmètre organisationnel. Le cube rend l’écart investigable. Il ne le résout pas par nature.
Vous devez donc séparer trois objets dans votre inventaire : la donnée source, la règle de transformation et la restitution. Cette séparation devient déterminante lorsque l’ancien univers, l’InfoCube ou le datamart doit être remplacé.
Comment fonctionne un cube OLAP et quelles dimensions faut-il modéliser ?
Le cube OLAP est une représentation multidimensionnelle des données. Son principe est de croiser des dimensions avec une ou plusieurs mesures. Un cube de ventes peut réunir les dimensions Temps, Produit, Client, Géographie et Organisation, puis stocker ou calculer le chiffre d’affaires, les quantités, la marge et le budget.
Un visuel en trois dimensions aide à comprendre le mécanisme, mais il devient vite insuffisant. Dans un environnement réel, le cube comporte souvent davantage de trois axes. Il s’agit alors d’un hypercube. Un rapport n’en montre généralement que deux en lignes et colonnes, tandis que les autres dimensions servent de filtres, de segments ou de variables.
Chaque dimension comprend des membres et, fréquemment, une hiérarchie. La dimension Temps peut relier jour, semaine, mois, trimestre et année. La dimension Produit peut relier référence, famille et gamme. Cette organisation permet de consolider une mesure sans recomposer manuellement chaque niveau de restitution.
Dimensions, mesures et hiérarchies dans l’analyse multidimensionnelle
Une dimension répond à la question « selon quoi analyse-t-on ? ». Une mesure répond à la question « que calcule-t-on ? ». Cette différence paraît théorique jusqu’au jour où une équipe tente d’agréger un taux comme s’il s’agissait d’un montant. Un chiffre d’affaires se somme. Un taux de marge doit souvent être recalculé à partir du montant de marge et du chiffre d’affaires.
Le tableau suivant croise des objets de modélisation, leur rôle et le risque rencontré lors d’une reprise. Il est construit à partir des mécanismes documentés dans la documentation Oracle sur l’OLAP, consultée le 24 mars 2026, et des pratiques de recette de socles décisionnels.
| Objet du cube OLAP | Exemple de contenu | Usage dans le rapport | Risque lors d’une migration |
|---|---|---|---|
| Dimension Temps | Jour, mois, trimestre, année | Comparer le réalisé et le budget par période | Une hiérarchie fiscale peut être remplacée à tort par une hiérarchie calendaire. |
| Dimension Produit | Référence, famille, gamme | Analyser le mix et les volumes vendus | Une référence inactive peut disparaître alors qu’elle reste nécessaire à l’historique. |
| Dimension Organisation | Entité, direction, centre de coût | Ventiler les responsabilités de gestion | Un changement de rattachement peut fausser les comparaisons pluriannuelles. |
| Mesure additive | Quantité, montant facturé | Sommer sur plusieurs axes | Les doublons issus d’une jointure produisent une agrégation excessive. |
| Mesure calculée | Taux de marge, part de marché | Comparer des ratios consolidés | La somme des pourcentages remplace à tort une formule pondérée. |
Le modèle doit aussi gérer les croisements sans données. Une entreprise peut disposer de milliers de produits, de centaines de zones et de nombreuses périodes. Toutes les combinaisons ne correspondent pas à une vente réelle. Cette « sparsité » influence le stockage et les temps de traitement. Elle ne doit pas être masquée dans une estimation de capacité.
MOLAP, ROLAP et HOLAP répondent à des contraintes différentes
Le MOLAP stocke les données dans une structure multidimensionnelle et s’appuie volontiers sur des agrégats préparés. Il vise des lectures analytiques rapides, mais impose de gérer le traitement et le rafraîchissement du cube. Des produits historiques comme Microsoft Analysis Services ou Oracle Essbase ont porté ce type d’approche dans de nombreux parcs décisionnels.
Le ROLAP conserve davantage la logique relationnelle. Les dimensions et les faits restent dans des tables, souvent organisées en schéma en étoile. Les calculs sont produits au moment de la requête ou par des tables d’agrégats. Cette option réutilise plus directement le stockage relationnel, mais elle demande une attention précise aux index, aux jointures et aux volumes lus.
Le HOLAP combine les deux logiques. Les données synthétiques peuvent être servies par une structure multidimensionnelle, tandis que le détail est lu dans des tables relationnelles. Le mécanisme convient lorsqu’un lecteur navigue d’un total mensuel à une ligne de facture, mais le drill-through doit être testé sur les droits, les filtres et les temps de réponse.
Le choix ne se tranche pas sur le seul vocabulaire du produit. Sur un parc de rapports peu consultés dont les règles ne sont pas documentées, reconstruire un modèle décisionnel réduit peut coûter moins cher que de reproduire chaque agrégat ancien. L’arbitrage s’inverse si plusieurs centaines de restitutions utilisent des hiérarchies et des mesures dont personne ne connaît plus la logique.
Quelles opérations OLAP permettent de passer du total au détail ?
Les opérations OLAP organisent la navigation dans une analyse. Elles permettent de changer le niveau de synthèse, de limiter le périmètre ou de réorienter l’affichage. Elles sont parfois présentées comme des gestes d’interface. Dans un projet de reprise, elles révèlent surtout quelles hiérarchies et quelles règles de filtrage doivent être préservées.
Le drill-down descend vers un niveau plus détaillé. Un responsable qui consulte le chiffre d’affaires annuel peut descendre au trimestre, puis au mois, avant d’examiner une famille de produits. Le drill-up suit le chemin inverse. Il consolide les éléments détaillés vers un niveau supérieur, par exemple du jour vers le mois ou de la référence vers la gamme.
Le slicing isole une tranche d’information en fixant une valeur sur une dimension. Sélectionner l’exercice 2025 dans un cube qui contient plusieurs années constitue un slice. Le dicing, parfois nommé scoping, découpe un sous-ensemble sur plusieurs axes. Vous pouvez retenir deux régions, trois familles de produits et un semestre, puis observer les mesures à l’intérieur de ce bloc.
Pivot, slice et dice modifient la vue, pas la définition de la mesure
Le pivot fait tourner les dimensions visibles. Une dimension placée en colonne passe en ligne, ou devient un filtre. Ce changement paraît neutre, mais il doit conserver les mêmes règles de calcul. Si le total affiché varie après un pivot, il faut vérifier les contextes, les éléments masqués, les filtres de rapport et les agrégations non additives.
Le slice et le dice peuvent aussi être à l’origine de malentendus en recette. Une direction financière peut comparer un rapport ancien filtré sur les factures validées à une restitution nouvelle filtrée sur les factures émises. Les deux tableaux portent peut-être le même titre. Ils ne couvrent pas le même périmètre. L’écart est alors explicable, mais il ne doit pas être présenté comme une anomalie de moteur.
- Le drill-down doit suivre une hiérarchie métier validée, comme année, trimestre, mois et jour, plutôt qu’une succession de codes techniques.
- Le drill-up doit recalculer les ratios lorsque la mesure n’est pas additive, notamment pour les taux et les prix moyens.
- Le slicing doit rendre visible la valeur de filtre retenue afin qu’un export ne perde pas son contexte.
- Le dicing doit être testé avec les droits utilisateurs, car une restriction organisationnelle peut réduire le bloc visible.
- Le pivot doit conserver le périmètre de données, même lorsque l’outil modifie l’ordre ou le format des colonnes.
Le drill-through exige une traçabilité jusqu’au détail transactionnel
Le drill-through relie une cellule agrégée à un détail plus fin, souvent issu de tables relationnelles. Une marge mensuelle par entité peut ainsi ouvrir la liste des écritures ou factures qui composent le total. Cette fonction est utile, mais elle ne doit pas devenir un contournement de la modélisation. Un utilisateur qui doit systématiquement descendre au détail pour comprendre le chiffre ne dispose pas de la bonne restitution de synthèse.
Le détail doit aussi respecter la sécurité appliquée au rapport. Un directeur de région peut avoir le droit de consulter son total, sans avoir accès à des attributs sensibles dans les lignes transactionnelles. Cette question relève de la conception des autorisations du socle. Pour les aspects de protection des données personnelles, votre DPO reste l’interlocuteur compétent. Le périmètre traité ici s’arrête au comportement décisionnel des filtres et des droits.
Le langage MDX a historiquement servi à exprimer des requêtes sur des structures multidimensionnelles. Sa logique diffère de SQL, qui interroge des tables relationnelles. Un utilisateur métier n’a pas à écrire du MDX pour utiliser un rapport. En revanche, une équipe qui remplace un cube doit identifier les calculs MDX existants, car ils peuvent contenir des ratios, des allocations ou des filtres absents des couches de restitution.
La navigation n’est donc pas un décor. Chaque opération exprime une attente métier sur la granularité, le périmètre et le mode d’agrégation. C’est ce qui doit être vérifié avant de traduire un cube en modèle sémantique.
Quelle différence OLAP OLTP pour les données, les performances et les usages ?
La différence OLAP OLTP tient d’abord à l’objectif. Un système transactionnel OLTP enregistre une action métier élémentaire. Il crée une commande, applique un paiement, réserve un stock ou modifie une fiche client. Un système OLAP lit, consolide et compare les données produites par ces actions afin de fournir une vision de pilotage.
Dans un contexte commercial, l’OLTP traite la vente au moment où elle est réalisée. Il doit garantir que deux opérations simultanées ne vendent pas le dernier article disponible deux fois. Il met donc l’accent sur l’intégrité, la disponibilité et le temps de réponse mesuré en millisecondes. La requête porte sur peu de lignes, mais les écritures sont nombreuses.
L’OLAP intervient après intégration des données. Il permet d’examiner les ventes par période, par produit, par canal ou par organisation. Une requête peut parcourir plusieurs années d’historique, calculer une comparaison avec le budget et produire une ventilation des écarts. Le délai acceptable peut être plus élevé, à condition qu’il reste compatible avec l’usage de restitution.
Les structures relationnelles OLTP ne répondent pas au même besoin
Une base OLTP utilise souvent des tables normalisées. Chaque ligne représente une entité ou un événement, comme une ligne de commande, un mouvement de stock ou une facture. Les colonnes portent les attributs nécessaires au traitement. Cette organisation limite la redondance et facilite les mises à jour cohérentes.
Une structure analytique prépare au contraire la lecture transversale. Elle peut adopter un schéma en étoile avec une table de faits et des dimensions, ou s’appuyer sur un cube multidimensionnel. Les données sont fréquemment chargées par lots après contrôle. Une alimentation nocturne est courante, mais le rythme peut être intra-journalier si le besoin de pilotage le justifie et si les flux sont dimensionnés pour cela.
| Critère comparé | OLTP | OLAP | Conséquence pour votre socle |
|---|---|---|---|
| Finalité | Exécuter une transaction métier | Analyser une activité consolidée | Une commande doit rester dans l’application opérationnelle. |
| Type de charge | Écritures fréquentes et courtes | Lectures larges et calculs complexes | Le même moteur ne doit pas être dimensionné sans distinguer les deux usages. |
| Modèle dominant | Tables relationnelles normalisées | Cube, étoile ou modèle analytique | Les jointures et agrégats doivent être revus lors d’une migration. |
| Mise à jour | Temps réel ou quasi temps réel | Lot planifié ou rafraîchissement contrôlé | La fraîcheur attendue doit être écrite dans le besoin métier. |
| Granularité | Événement détaillé | Total, détail navigable et historique | Le drill-through relie les deux niveaux sans les confondre. |
Ce tableau ne signifie pas qu’une entreprise doit isoler physiquement toute analyse de tout système opérationnel. Il montre que les objectifs de conception divergent. Faire exécuter chaque matin une requête de marge sur plusieurs années directement sur la base de production peut dégrader le traitement des utilisateurs. Copier des transactions sans conserver les clés et les dates de référence peut, inversement, rendre le reporting incohérent.
Le délai d’actualisation doit être contractualisé dans le besoin
Un indicateur de stock utilisé pour préparer une réunion hebdomadaire n’exige pas la même fraîcheur qu’un stock utilisé pour accepter une commande. Le premier peut être alimenté la nuit, sous réserve que l’heure de disponibilité soit connue. Le second relève du système transactionnel. La confusion vient souvent d’un tableau de bord qui semble opérationnel alors qu’il repose sur une alimentation différée.
Vous devez demander une heure de dernière alimentation visible dans la restitution. Cette information limite les décisions prises sur un chiffre périmé. Elle facilite aussi la recette lorsqu’un écart est constaté entre le rapport et l’application source. Avant d’accuser le modèle, il faut comparer le même instant de référence.
Les approches en mémoire peuvent réduire certains temps de lecture, mais elles ne dispensent ni de modélisation ni de contrôle des agrégats. Le sujet est détaillé dans cette analyse des gains et limites de la BI in-memory. Une accélération de requête ne rend pas automatiquement une mesure juste.
Le choix entre OLAP et OLTP ne se formule donc pas comme un duel technologique. Les deux mécanismes coexistent souvent dans le même système d’information, à des étapes différentes de la circulation de la donnée.
Comment auditer un cube OLAP avant une migration de socle décisionnel ?
Un cube OLAP doit être audité comme un ensemble de règles de calcul, de hiérarchies, de sources et de restitutions. Migrer uniquement les écrans ou les noms de rapports laisse de côté ce qui produit les chiffres. La première question porte sur l’usage réel. La seconde porte sur les calculs réellement utilisés. La troisième porte sur la capacité de l’équipe à expliquer les écarts.
Le recensement commence par les rapports, les tableaux de bord, les univers, les modèles sémantiques et les flux d’alimentation. Les journaux d’audit constituent une base utile, mais leur durée de rétention doit être connue. Une analyse portant sur seulement quatre-vingt-dix jours peut ignorer des rapports trimestriels, annuels ou utilisés pendant une clôture.
La documentation de version influence aussi l’arbitrage. Une formule développée pour une version ancienne de SAP BusinessObjects ne se reprend pas toujours à l’identique dans une cible. Avant de chiffrer, consultez l’état exact de votre parc dans ce point sur les versions SAP BusinessObjects et leurs échéances. Une version produit est une donnée de périmètre, pas un détail administratif.
Un chiffrage de reprise doit séparer la construction de la recette
Le calcul suivant fournit un ordre de grandeur de reprise fonctionnelle. Il ne constitue pas un devis et ne comprend ni la formation, ni la reprise des habilitations, ni les corrections de source. Il part d’un parc de 240 rapports. L’inventaire identifie 144 rapports simples, 72 rapports intermédiaires et 24 rapports complexes après exclusion des doublons et des rapports abandonnés.
Le ratio appliqué est de deux heures par rapport simple pour la reprise de la structure et des filtres visibles, de cinq heures pour un rapport intermédiaire avec variables et calculs, puis de dix heures pour un rapport complexe intégrant plusieurs requêtes ou des règles de réconciliation. Ces ratios servent de base de planification interne et doivent être révisés après un échantillon de reprise. Le calcul donne 288 heures pour les rapports simples, 360 heures pour les intermédiaires et 240 heures pour les complexes.
La reprise seule représente donc 888 heures. Une recette fonctionnelle ajoutée à hauteur de 40 % représente 355 heures, soit un total de 1 243 heures avant formation, conduite du changement, gestion des droits et corrections de flux. Ce résultat est borné par les hypothèses écrites. Si les 24 rapports complexes contiennent des calculs d’allocation non documentés, les dix heures prévues ne suffisent plus.
À l’inverse, si les logs sur douze mois montrent que la moitié des rapports n’est plus ouverte, une reconstruction limitée aux usages actifs peut être préférable à une reprise exhaustive. Le projet ne doit pas reprendre un objet parce qu’il existe encore sur le serveur. Il doit le reprendre parce qu’un usage et une règle de gestion le justifient.
La réconciliation doit accepter des écarts expliqués, pas promettre une identité fictive
La recette compare des périmètres identiques. Elle fixe une date de référence, une liste de filtres, une granularité et une tolérance par indicateur. Un écart de 0,4 % sur le chiffre d’affaires peut être acceptable ou bloquant selon son origine. S’il résulte d’un chargement décalé d’une journée, il doit disparaître lors de la comparaison au même instant. S’il résulte de factures annulées exclues dans un ancien univers mais incluses dans la cible, la règle doit être arbitrée par le métier.
Un double run reste le moyen le plus sûr de faire émerger ces différences avant la bascule. Pendant une période définie, l’ancien et le nouveau socle produisent les mêmes indicateurs sur le même calendrier. Les écarts sont inscrits dans un journal avec leur montant, leur cause, leur propriétaire et leur décision. Une anomalie résolue sans trace revient souvent au moment où la direction demande l’explication du premier chiffre divergent.
Un cube OLAP n’est pas un actif autonome. Il dépend de la qualité des flux, de la définition des mesures, de la stabilité des hiérarchies et de la capacité à prouver ce qui a changé. Avant d’engager une reprise, sortez les logs d’usage sur douze mois, relevez les règles cachées dans les objets et construisez votre matrice de réconciliation sur les indicateurs réellement pilotés.
OLAP et entrepôt de données désignent-ils la même chose ?
Non. Un entrepôt de données stocke et organise des données destinées à l’analyse. OLAP décrit surtout la manière de les interroger et de les restituer selon plusieurs dimensions. Un entrepôt peut alimenter un cube ou un modèle analytique sans être lui-même un cube.
Un cube OLAP contient-il forcément trois dimensions ?
Non. La représentation en trois dimensions est pédagogique. Les cubes utilisés en entreprise comportent souvent davantage d’axes, tels que le temps, le produit, le client, l’organisation, le canal et la devise. On parle alors plus précisément d’hypercube.
Quelle opération OLAP permet de passer du mois au jour ?
Le drill-down permet de descendre dans une hiérarchie, par exemple de l’année au trimestre, puis au mois et au jour. Cette navigation suppose que la hiérarchie de temps et les règles de calendrier aient été correctement modélisées.
Pourquoi ne pas lancer les rapports analytiques directement sur la base OLTP ?
Les requêtes analytiques lisent souvent beaucoup de données et exécutent des agrégations coûteuses. Elles peuvent gêner les écritures opérationnelles, telles que les commandes ou les mises à jour de stock. Une base de données décisionnelle sépare ces charges et prépare les données pour le reporting.
Le dossier complet Socles BI hérités : auditer le parc réel avant de le migrer
