Semantic Layer |

Migration DataViz - une couche sémantique interopérable - {oa-lake-ctx}

Thu, 02 Jul 2026 00:00:00 +0000

Les plateformes décisionnelles historiques reposaient généralement sur une couche sémantique permettant aux utilisateurs de manipuler des objets métier plutôt que des tables ou des requêtes SQL.

“Clients”, “contrats”, “produits” ou “chiffre d’affaires” étaient exposés sous une forme fonctionnelle indépendante des structures physiques de stockage.

Pour répondre à ce besoin, nous avons conçu {oa-lake-ctx}.

{oa-lake-ctx} constitue la couche sémantique de l’architecture {oa-lake}. Elle centralise les objets métier, les dimensions, les mesures, les KPIs, les règles de calcul et les mécanismes de sécurité.

Point clé : les outils consommateurs manipulent des objets métier. Les structures physiques restent masquées.

Architecture

{oa-lake-ctx} centralise les dimensions, mesures, hiérarchies, KPI et règles de calcul.

Ces composants sont définis une seule fois puis exposés aux outils consommateurs.

Contrairement à certaines couches sémantiques du marché, {oa-lake-ctx} ne nécessite ni modèle physique spécifique, ni table pivot, ni chemin de navigation imposé.

Les relations sont calculées dynamiquement à partir du modèle existant.

Point clé : un modèle métier unique pour toutes les données et tous les outils consommateurs.

Sources de données

{oa-lake-ctx} peut exploiter simultanément plusieurs systèmes de données.

Les données peuvent provenir de bases Oracle, SQL Server, PostgreSQL, DB2, Snowflake, BigQuery, Redshift, fichiers ou autres sources compatibles SQL.

Les objets métier peuvent combiner plusieurs sources dans une même définition fonctionnelle.

Usage typique : construire un KPI à partir de données réparties sur plusieurs plateformes.

Objets métier

Les catalogues exposés par {oa-lake-ctx} regroupent les dimensions, mesures, KPI, hiérarchies et nomenclatures métier.

Les relations entre objets sont définies dans la couche sémantique et non dans les outils de restitution.

Les catalogues peuvent être organisés indépendamment des structures physiques des bases de données.

Génération SQL

Les requêtes SQL sont générées dynamiquement à partir des objets métier, dimensions, mesures et filtres sélectionnés.

Les jointures, agrégations et règles de calcul sont appliquées par le moteur.

Les filtres utilisateurs sont propagés jusqu’aux systèmes sources via le mécanisme de Push-Down SQL : pas de copie systématique des données, les requêtes sont exécutées sur les systèmes existants, dans le respect des architectures en place.

Le SQL généré peut être exécuté par {oa-lake} ou par tout moteur SQL compatible.

Point clé : les utilisateurs manipulent des objets métier ; le SQL est généré automatiquement.

Smart Cache

Les données restent dans les systèmes sources lorsque cela est possible.

Les jeux de données les plus sollicités peuvent être matérialisés au format Parquet.

Le cache est piloté par le Cache Manager de {oa-lake}, géré automatiquement selon les usages observés.

La gestion du cache reste indépendante des outils consommateurs.

Point clé : les requêtes les plus coûteuses peuvent être accélérées sans modifier les systèmes sources.

SQL Engine

{oa-lake} s’appuie sur un moteur SQL columnar et in-memory.

Les requêtes générées par {oa-lake-ctx} sont exécutées par ce moteur ou propagées vers les systèmes sources selon le contexte.

Le SQL reste portable, standard et exécutable sur différents moteurs, indépendant des technologies de stockage utilisées — ce qui limite le lock-in technologique.

Point clé : le moteur SQL constitue la couche d’exécution de l’architecture.

Sécurité

La sécurité est gérée au niveau de la couche sémantique.

Les restrictions d’accès, profils utilisateurs, catalogues métier et filtres de sécurité sont appliqués avant génération des requêtes.

Cette approche permet de reproduire les mécanismes de sécurité rencontrés dans des plateformes telles que SAP BusinessObjects ou IBM Cognos.

Point clé : les règles de sécurité sont définies une seule fois puis appliquées à tous les outils connectés.

Restitution

Les catalogues exposés par {oa-lake-ctx} peuvent être consommés par tout outil capable d’interroger une source PostgreSQL.

Power BI, Looker, Spotfire, Tableau, Qlik ou d’autres plateformes accèdent aux mêmes objets métier, dimensions, mesures et KPI.

Les définitions fonctionnelles restent identiques quel que soit l’outil utilisé.

Résultat : plusieurs plateformes peuvent partager le même catalogue métier sans duplication des règles de calcul.

Gouvernance

Les objets métier, KPI, dimensions, mesures et règles de calcul sont centralisés dans un référentiel unique.

Les évolutions fonctionnelles sont réalisées dans {oa-lake-ctx} puis immédiatement disponibles pour les outils connectés.

Point clé : {oa-lake-ctx} constitue le point central de définition des objets métier et des KPI.

Migration DataViz - migrer de Cognos vers Power BI

Thu, 02 Jul 2026 00:00:00 +0000

Les plateformes IBM Cognos Analytics contiennent généralement plusieurs années de modélisation métier : Frameworks, hiérarchies, calculs, dimensions, mesures, variables et rapports.

{openAudit} analyse les Frameworks Cognos, les rapports et les logs d’usage afin de reconstruire les dépendances entre les sources de données, les objets métier et les restitutions.

Point clé : dans la plupart des patrimoines Cognos, la valeur se situe davantage dans les Frameworks et les règles métier que dans les rapports eux-mêmes.

Analyse du patrimoine Cognos

L’analyse porte sur les Frameworks Manager, les rapports, les requêtes, les dimensions, les hiérarchies, les calculs, les filtres, les variables.

Les métadonnées collectées permettent de reconstruire :

les dépendances entre objets ;
les relations avec les sources de données ;
les objets métier et indicateurs exposés dans les rapports.

Rationalisation du périmètre

Les logs d’usage sont croisés avec les métadonnées de la plateforme.

Cette phase permet d’identifier les rapports inutilisés, les doublons et les Frameworks obsolètes.

Résultat : le périmètre réellement utilisé est isolé avant migration.

Conversion vers Power BI

Les Frameworks Cognos sont analysés puis convertis vers le modèle cible Power BI.

Les dimensions, hiérarchies, mesures, calculs, variables et relations entre objets sont reconstruits dans le modèle sémantique cible.

Les expressions Cognos sont converties en SQL ou en DAX selon leur nature.

Les dépendances entre Frameworks, rapports et sources de données sont conservées dans le modèle généré.

Point clé : les objets métier et les règles de calcul sont reconstruits directement à partir des Frameworks Cognos.

Validation

Les migrations peuvent être réalisées en double exécution Cognos / Power BI.

Les indicateurs produits par les deux plateformes sont comparés pendant les phases de recette.

Usage typique : validation progressive des rapports avant bascule.

Migration pilotée par les usages

Les rapports peuvent être migrés par lots en fonction de leur fréquence d’utilisation et de leur criticité métier.

Les usages observés servent de base à la planification du projet et à la priorisation des développements.

Résultat : réduction du volume à migrer et concentration des efforts sur les usages actifs.

Migration DataViz - migrer de SAP BO vers GCP Looker

Thu, 02 Jul 2026 00:00:00 +0000

Les patrimoines SAP BusinessObjects regroupent généralement plusieurs années de modélisation : univers, rapports Web Intelligence, objets métier, calculs, filtres, invites et couches sémantiques.

{openAudit} analyse ces composants afin de reconstruire les dépendances entre les sources de données, les univers, les rapports et les usages observés.

Point clé : les univers et les objets métier constituent généralement la principale source d’information pour reconstruire le modèle cible.

Prérequis d’analyse SAP BusinessObjects

L’analyse repose sur l’accès aux services SAP BusinessObjects, aux référentiels techniques et à la base d’audit.

Les extracteurs sont exécutés dans l’environnement du Client. Les métadonnées collectées peuvent être anonymisées avant traitement.

Bon à savoir : seules les métadonnées techniques sont exploitées.

Analyse du patrimoine

L’analyse couvre les rapports Web Intelligence, les univers UNV et UNX, les Data Providers, les objets métier, les variables, les filtres, les invites et les composants graphiques.

Les dépendances techniques et les usages observés sont consolidés dans un référentiel.

Rationalisation

Les logs d’audit sont croisés avec les métadonnées de la plateforme.

Les rapports inutilisés ou cassés, les rapports répliqués, les objets non consommés, les univers obsolètes, etc. sont identifiés avant migration.

Résultat : réduction massive du volume à migrer.

Conversion vers Looker

Les Data Providers, les objets métier et les requêtes sont convertis vers les composants Looker.

Les dimensions, mesures, jointures et calculs sont reconstruits dans les modèles LookML.

Les dashboards, filtres, prompts, tableaux, graphiques et mécanismes de navigation sont reconstruits à partir des rapports SAP BusinessObjects.

L’organisation fonctionnelle des univers est reprise dans les dossiers, Explores et catalogues métier de la plateforme cible.

Point clé : les objets fonctionnels et les composants de restitution sont reconstruits à partir des univers et rapports SAP BusinessObjects.

Validation

Les migrations peuvent être réalisées en double exécution SAP BusinessObjects / Looker.

Les indicateurs produits par les deux plateformes sont comparés pendant les phases de recette.

Prompts SAP BusinessObjects

Les invites SAP BusinessObjects sont converties vers les filtres natifs de Looker.

Les listes de valeurs et paramètres de saisie sont conservés.

Objets métier et modèles LookML

Les requêtes, objets métier, dimensions, mesures et jointures sont convertis vers les composants LookML.

Structure fonctionnelle

L’organisation des univers est reconstruite sous forme d’Explores, de dimensions et de mesures.

Pivots et analyses matricielles

Les tableaux croisés et analyses multidimensionnelles sont convertis vers les mécanismes de pivot de Looker.

Graphiques

Les courbes et analyses comparatives sont reconstruites à partir des indicateurs identifiés dans les rapports.

Bar charts

Les bar charts sont adaptés aux composants de visualisation Looker.

Pie charts

Les pie charts sont convertis vers les visualisations natives de Looker.

Migration DataViz - migrer de SAP BO vers Power BI

Thu, 02 Jul 2026 00:00:00 +0000

{openAudit} analyse les univers, les rapports et les logs d’usage afin de reconstruire les dépendances entre les sources de données, les objets métier et les visualisations.

Point clé : la migration porte sur les univers, les objets métier, les règles de gestion, autant que sur les rapports.

Prérequis d’analyse SAP BusinessObjects

L’analyse nécessite l’accès aux services SAP BusinessObjects, aux référentiels techniques et à la base d’audit.

Les extracteurs sont exécutés dans l’environnement du Client. Les métadonnées collectées peuvent être anonymisées avant traitement.

Bon à savoir : seules les métadonnées techniques sont exploitées.

Analyse du patrimoine

L’analyse couvre les rapports Web Intelligence, les univers UNV et UNX, les Data Providers, les objets métier, les variables, les filtres, les invites et les composants graphiques.

Les dépendances techniques et les usages observés sont consolidés dans un référentiel.

Rationalisation

Les logs d’audit sont croisés avec les métadonnées de la plateforme.

Les rapports inutilisés, les doublons, les objets non consommés et les univers obsolètes sont identifiés avant migration.

Résultat : réduction du volume à migrer.

Conversion vers Power BI

Les Data Providers sont convertis en datasets Power BI.

Les requêtes, calculs et variables sont convertis en SQL ou DAX. Les objets métier sont reconstruits sous forme de dimensions et de mesures.

Les dépendances entre univers, rapports et sources de données sont conservées dans le modèle cible.

Les tableaux, graphiques, filtres, sections et éléments de mise en page sont analysés puis reconstruits dans Power BI.

Point clé : la migration couvre à la fois la couche métier et la couche de restitution.

Validation

Les migrations peuvent être réalisées en double exécution SAP BusinessObjects / Power BI.

Les indicateurs produits par les deux plateformes sont comparés pendant les phases de recette.

Tables, filtres et slicers

Conversion des tables, filtres et sections SAP BusinessObjects vers les composants Power BI.

Pie Charts

Conversion des pie charts SAP BusinessObjects vers les visuels Power BI.

Graphiques

Conversion des graphiques SAP BusinessObjects vers les visuels Power BI.

Dashboards

Conversion des dashboards SAP BusinessObjects vers Power BI.

Migration DataViz - SAP BO, Power BI, Spotfire ou Cognos vers une architecture ouverte et interopérable

Thu, 02 Jul 2026 00:00:00 +0000

Les plateformes de datavisualisation évoluent régulièrement.

SAP BusinessObjects, IBM Cognos, Power BI ou Spotfire peuvent se succéder au sein d’un même Système d’Information. Les objets métier, les calculs, les indicateurs et les règles de gestion restent généralement iso d’une plateforme à l’autre.

{openAudit} analyse les référentiels techniques, les couches sémantiques et les rapports afin de reconstruire les dépendances entre les sources de données, les traitements intermédiaires et les objets exposés dans les dashboards.

Point clé : les composants fonctionnels des plateformes de restitution sont extraits puis reconstruits dans un format indépendant de la technologie cible.

Analyse du patrimoine décisionnel

Les mécanismes d’analyse basés sur des parsers couvrent les univers SAP BusinessObjects, les Frameworks Cognos, les modèles Power BI, les Information Links Spotfire ainsi que les rapports, dashboards, calculs, filtres et objets métier associés.

Les métadonnées collectées permettent de reconstruire les dépendances techniques, les couches sémantiques et les règles de gestion.

Rationalisation

Les référentiels techniques sont croisés avec les logs d’usage. Les rapports inutilisés, les doublons et les composants obsolètes sont identifiés avant la phase de migration.

Résultat : réduction du périmètre réellement migré.

Transcription SQL

Les requêtes, calculs, filtres, agrégations, jointures, variables et règles métier sont reconstruits sous forme de SQL.

Le SQL produit constitue une représentation ouverte de la logique fonctionnelle initialement portée par la plateforme de datavisualisation.

Point clé : le SQL devient le format pivot de représentation des objets métier.

{oa-lake}

Les traitements SQL sont intégrés dans {oa-lake}.

{oa-lake} centralise les objets métier, les indicateurs, les dimensions, les règles de gestion et les transformations SQL. Le moteur fédère plusieurs systèmes de données et expose un modèle unique aux outils de restitution.

Les données peuvent être matérialisées au format Parquet. Les requêtes sont générées vers les systèmes physiques ou exécutées à partir du cache quand nécessaire.

Point clé : la logique métier est définie une seule fois puis exposée à plusieurs plateformes de datavisualisation.