Data Lineage |

Data lineage - alimentation des data catalogues tiers pour exposer son data lineage technique

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

{openAudit} permet la consultation du data lineage via son portail Web Mosaïc, mais les métadonnées consolidées peuvent également être publiées vers différents data catalogues du marché qui présentent souvent de fortes limitations pour ce qui concerne le data lineage. L’intérêt est de n’avoir qu’un outil pour une data governance optimale.

Le data lineage est reconstruit dans le référentiel technique {openAudit}, puis exposé vers les catalogues de données via des connecteurs dédiés.

Cette architecture permet de dissocier les mécanismes de collecte et de reconstruction du data lineage de la couche d’exposition utilisée par les équipes de gouvernance.

Point clé : le référentiel technique reste indépendant du catalogue cible. Les mécanismes de collecte et de reconstruction du lineage (et de connexion) ne dépendent pas du data catalogue utilisé.

Architecture

Les métadonnées collectées sont consolidées dans la base de données colomnar oA.mdb après traitement par le moteur oA.Job.

Le référentiel central contient notamment :

Le data lineage au champ.
Les usages.
Les informations de gouvernance associées le cas échéant.

Les catalogues sont ensuite alimentés à partir de ce référentiel unique via des connecteurs d’exposition indépendants des solutions de data catalogue.

Connecteurs d’exposition

Les connecteurs assurent :

La publication automatisée du lineage.
Les synchronisations continues.
La gestion des restrictions.
Le support des différents Workspaces.

L’exposition du data lineage peut être complète ou partielle selon les capacités d’affichage du catalogue cible, sachant que le data lineage produit en amont est, lui, disponible au champ.

Résultat : les catalogues ne consomment que les métadonnées consolidées et non les sources techniques d’origine.

Catalogues supportés

Les connecteurs disponibles permettent à ce jour d’alimenter les data catalogues suivants :

DataGalaxy
Zeenea
Collibra

Gestion des usages

Lorsque les logs d’audit sont disponibles, les usages observés sont intégrés au référentiel technique puis exposés vers le catalogue.

Les utilisateurs peuvent ainsi distinguer :

Les flux “vivants”, consommés par des outils ou requêtés.
Les flux et donc les objets non consommés (souvent plus de 80 % de l’ensemble).

Usage typique : enrichir le data catalogue avec des informations d’usage afin d’identifier les objets candidats à la rationalisation ou au décommissionnement.

Data lineage - architecture on prem'

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

Dans les environnements les plus exigeants en matière de sécurité (banque, assurance, etc.), {openAudit} peut être déployé directement dans l’environnement du Client, qu’il soit On-Premise ou dans un tenant Cloud du choix du Client.

L’architecture repose sur une VM dédiée hébergeant les différents composants de collecte, de traitement et d’exposition du data lineage.

Point clé : l’ensemble des traitements, métadonnées et référentiels restent hébergés dans l’environnement du Client. Aucun composant SaaS externe n’est requis.

Principes techniques

VM dédiée hébergée chez le Client.
Collecteurs conteneurisés par technologie.
Comptes de service dédiés.
Chiffrement des mots de passe après première utilisation.
Production de fichiers CSV standardisés.
Parsing et consolidation par oA.Job.
Référentiel technique oA.mdb (DuckDB).
Exposition via le portail Web Mosaïc.
Les logs d’audit pouvant contenir des informations sensibles peuvent être anonymisés avant traitement.

Bon à savoir : ce data lineage peut alimenter une solution tierce, typiquement un data catalogue nécessitant d’adresser plus précisément les sujets de data lineage.

Collecte des métadonnées

Les métadonnées sont collectées au moyen de conteneurs spécialisés par technologie. Ces composants se connectent aux bases de données, plateformes ETL/ELT, outils de data visualisation et bases d’audit via des comptes de service dédiés. Les mots de passe sont chiffrés après leur première utilisation.

Les collecteurs produisent des fichiers CSV standardisés contenant les métadonnées nécessaires à la reconstruction du lineage. Ces fichiers peuvent être contrôlés et validés par le Client avant traitement.

Lorsque des logs d’audit sont exploités, ceux-ci peuvent être anonymisés au moyen d’un conteneur dédié avant leur intégration dans le référentiel.

Traitement

Les fichiers sont ensuite transmis au serveur oA.Job, chargé du parsing et de la consolidation des métadonnées. Les résultats sont stockés dans la base columnar oA.mdb (DuckDB), qui constitue le référentiel technique utilisé par le portail Web Mosaïc.

Ce référentiel peut faire l’objet d’un dump au format souhaité par le client pour opérer des analyses spécifiques : le référentiel est extrêmement riche et différentes requêtes sont mises à disposition pour en faciliter l’exploration.

Exposition

Le data lineage est consultable via le portail Web propriétaire Mosaïc, hébergé sur la VM dédiée.

Cartographie globale des flux

Reconstruction automatique des dépendances entre bases de données, traitements ETL/ELT et usages dans les outils de data visualisation.

Usage typique : analyse d’impact avant modification d’une table ou d’un indicateur métier.

Analyse des usages

Croisement du data lineage avec les logs d’audit afin d’identifier les objets réellement utilisés et les branches non consommées.

Résultat : identification rapide des flux inutilisés et opportunités de simplification.

Data Lineage de détail

Navigation dans le data lineage jusqu’au niveau champ avec visualisation des transformations (drill through).

Point clé : descendre instantanément dans le code qui préside aux transformations pour identifier et fixer un problème dans un flux.

Data Lineage dans les dashboards

Traçabilité complète entre les données sources, les règles de gestion et la cellule du dashboard. Les données sources des dashboards sont rattachées au data lineage dès leurs alimentations, pour une analyse d’impact de bout en bout.

Usage typique : validation d’un indicateur métier ou analyse de l’origine d’une valeur affichée dans un dashboard.

Data lineage - architecture SaaS

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

Dans un déploiement SaaS, les composants de collecte restent hébergés dans l’environnement du Client tandis que les composants de traitement, de consolidation et d’exposition sont hébergés sur une infrastructure dédiée, opérée par Ellipsys.

Les extracteurs sont déployés sous forme de conteneurs spécialisés par technologie. Ils collectent les métadonnées des bases de données, plateformes ETL/ELT, outils de datavisualisation et bases de données d’audit à l’aide de comptes de service dédiés.

Les métadonnées collectées sont produites sous forme de fichiers CSV standardisés. Ces fichiers peuvent être contrôlés par le Client avant leur transfert vers l’infra Ellipsys.

Les fichiers sont ensuite transmis au serveur oA.Job, chargé du parsing et de la reconstruction des dépendances. La consolidation des métadonnées se fait dans le référentiel technique oA.mdb basé sur DuckDB (columnar database).

Le data lineage est ensuite exposé via le portail Web propriétaire Mosaïc ou via des solutions tierces, typiquement des solutions de data catalogue de marché.

Lorsque des logs d’audit sont exploités, ceux-ci peuvent être anonymisés au moyen d’un conteneur dédié avant leur transfert.

Point clé : les métadonnées nécessaires à la reconstruction du lineage sont transférées vers la plateforme SaaS sous format CSV et peuvent être contrôlées en amont.

Principes techniques

Extracteurs conteneurisés déployés dans l’environnement Client.
Comptes de service dédiés à la collecte.
Chiffrement des mots de passe après première utilisation.
Production de fichiers CSV standardisés.
Anonymisation optionnelle des logs d’audit.
Parsing et consolidation via oA.Job.
Base de données en source du data lineage oA.mdb (DuckDB).
Exposition via le portail Web Mosaïc ou dans des solutions de data catalogue.

Bon à savoir : les données métier ne sont jamais exploitées. Seules les métadonnées techniques sont collectées.

Collecte des métadonnées

Les collecteurs peuvent analyser :

Bases de données.
Plateformes ETL / ELT.
Outils de data visualisation.
Bases d’audit.

Chaque technologie est prise en charge par un composant dédié.

Traitement

Le serveur oA.Job réalise :

Le parsing des métadonnées.
La reconstruction des dépendances.
La consolidation des objets techniques.
L’intégration des usages issus des logs d’audit.

Les résultats sont stockés dans le référentiel oA.mdb.

Exposition

Le data lineage peut être consulté :

Via le portail Web Mosaïc.
Via une exposition du data lineage d’{openAudit} dans des solutions tierces.
Via les mécanismes d’intégration du Client.

Point clé : les mécanismes de collecte et de reconstruction du lineage sont indépendants des mécanismes d’exposition.

Cartographie globale des flux

Cartographie des dépendances entre bases de données, traitements ETL/ELT et usages de la donnée.

Usage typique : analyse d’impact avant modification d’un objet technique.

Analyse des usages

Croisement du data lineage avec les logs d’audit afin d’identifier les flux réellement utilisés.

Résultat : détection des flux inutilisés, ie les branches mortes.

Data Lineage de détail

Navigation dans le data lineage jusqu’au niveau champ avec visualisation des transformations intermédiaires.

Point clé : les dépendances sont consultables par itérations, des sources opérationnelles jusqu’aux usages.

Data Lineage dans les dashboards

Traçabilité entre données sources, transformations, règles de calcul et objets de restitution.

Usage typique : analyse de l’origine d’un indicateur métier ou validation d’une règle de gestion.

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 ETL - de l'ETL legacy vers dbt

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

La migration vers dbt consiste à transformer des traitements ETL propriétaires en modèles SQL exécutés directement dans le moteur de données cible.

Avant toute conversion, {openAudit} analyse les flux, les dépendances et les usages afin d’identifier le périmètre réellement utile.

Point clé : la migration commence par une phase de rationalisation du patrimoine existant.

Analyse des flux

Les traitements ETL sont analysés pour reconstruire les dépendances, les transformations et les usages.

Le data lineage est utilisé pour identifier les flux actifs, les branches mortes et les composants non consommés.

Cette phase permet de réduire le volume de traitements à migrer.

Résultat : un périmètre de migration recentré sur les traitements réellement utilisés.

Conversion vers SQL

Les jobs ETL sont décomposés en opérations élémentaires : filtres, jointures, agrégations, lookups, calculs métier et transformations.

Ces composants sont convertis en SQL documenté et indépendant de la technologie source.

Le SQL devient la représentation pivot des traitements.

Point clé : la logique métier est reconstruite en SQL avant génération du projet dbt.

Génération des modèles dbt

Les traitements SQL sont organisés sous forme de modèles dbt.

Les dépendances entre modèles sont générées automatiquement à partir des flux identifiés pendant l’analyse.

La structure du projet, les références entre modèles et la documentation peuvent être produites automatiquement.

Validation progressive

La migration est réalisée par lots.

Les modèles générés sont validés puis intégrés progressivement dans l’environnement cible.

Les écarts peuvent être contrôlés traitement par traitement pendant la phase de transition.

Usage typique : migration progressive de plusieurs centaines de jobs ETL vers dbt.

Architecture cible

Les traitements deviennent des modèles SQL versionnables et maintenables.

Les dépendances sont explicites, les transformations sont visibles et les traitements peuvent être exécutés directement par Snowflake, BigQuery, Databricks SQL, Redshift, PostgreSQL ou tout autre moteur compatible.

Point clé : les traitements ne dépendent plus de la plateforme ETL historique mais d’un projet dbt basé sur du SQL ouvert.