Data lineage et simplification | Ellipsys

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…), {openAudit} peut être déployé directement chez le Client, On-Premise ou dans un tenant Cloud de son choix, sur une VM dédiée qui héberge la collecte, le traitement et l’exposition du data lineage.

Point clé : traitements, métadonnées et référentiels restent dans l’environnement du Client ; aucun composant SaaS externe n’est requis.

Collecte des métadonnées

Des conteneurs spécialisés par technologie 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. Ils produisent des fichiers CSV standardisés, contrôlables par le Client avant traitement.

Les logs d’audit, qui peuvent contenir des informations sensibles, peuvent être anonymisés par un conteneur dédié avant leur intégration.

Traitement

Le serveur oA.Job assure le parsing et la consolidation des métadonnées, stockées dans la base columnar oA.mdb (MonetDB). Ce référentiel, très riche, peut être exporté (dump) au format souhaité par le Client pour des analyses spécifiques ; des requêtes sont fournies pour l’explorer.

Exposition

Le data lineage est consultable via le portail Web Mosaïc, hébergé sur la VM. Il peut aussi alimenter une solution tierce, typiquement un data catalogue.

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

Le croisement du data lineage avec les logs d’audit distingue les objets réellement utilisés des branches non consommées, et fait apparaître les opportunités de simplification.

Data Lineage de détail

Navigation jusqu’au niveau champ, avec accès direct au code des transformations (drill through) pour identifier et corriger un problème dans un flux.

Data Lineage dans les dashboards

Traçabilité de bout en bout, des alimentations jusqu’à la cellule du dashboard, en passant par les règles de gestion.

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

Questions fréquentes

Peut-on déployer {openAudit} entièrement dans notre environnement, sans SaaS ?

Oui. {openAudit} peut être déployé On-Premise ou dans un tenant Cloud choisi par le client, sur une VM dédiée. Traitements, métadonnées et référentiels restent hébergés chez le client, et aucun composant SaaS externe n’est requis.

Quels composants sont installés pour un data lineage on-premise ?

Des collecteurs conteneurisés par technologie, le serveur oA.Job pour le parsing et la consolidation, le référentiel technique oA.mdb (MonetDB) et le portail Web Mosaïc pour la consultation, tous hébergés sur la VM dédiée.

Comment sont protégées les informations sensibles des logs d'audit ?

Les logs d’audit peuvent être anonymisés par un conteneur dédié avant leur intégration. Les collecteurs produisent des fichiers CSV standardisés que le client peut contrôler et valider avant traitement, et les mots de passe des comptes de service sont chiffrés après leur première utilisation.

Jusqu'à quel niveau de détail va le data lineage ?

Jusqu’au champ, avec visualisation des transformations, et jusqu’à la cellule du dashboard. Croisé avec les logs d’audit, il identifie aussi les objets réellement utilisés et les branches non consommées.

Data lineage - architecture SaaS

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

Dans un déploiement SaaS, la collecte reste dans l’environnement du Client ; le traitement, la consolidation et l’exposition sont hébergés sur une infrastructure dédiée, opérée par Ellipsys.

Point clé : seules les métadonnées techniques sont transférées, au format CSV contrôlable en amont ; les données métier ne sont jamais exploitées.

Collecte des métadonnées

Des extracteurs conteneurisés, un par technologie, collectent les métadonnées des bases de données, plateformes ETL/ELT, outils de datavisualisation 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. Ils produisent des fichiers CSV standardisés, contrôlables par le Client avant transfert.

Les logs d’audit peuvent être anonymisés par un conteneur dédié avant leur transfert.

Traitement

Le serveur oA.Job réalise le parsing des métadonnées, la reconstruction des dépendances, la consolidation des objets techniques et l’intégration des usages issus des logs d’audit. Les résultats sont stockés dans le référentiel oA.mdb (MonetDB, base columnar).

Exposition

Le data lineage est consultable via le portail Web Mosaïc, dans des solutions tierces (typiquement des data catalogues du marché) ou via les mécanismes d’intégration du Client : collecte et reconstruction sont indépendantes de l’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

Le croisement du data lineage avec les logs d’audit identifie les flux réellement utilisés, et donc les branches mortes.

Data Lineage de détail

Navigation jusqu’au niveau champ, transformation par transformation, 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.

Questions fréquentes

Comment fonctionne {openAudit} en mode SaaS ?

Les collecteurs restent dans l’environnement du client, sous forme de conteneurs spécialisés par technologie. Le traitement, la consolidation et l’exposition du data lineage sont hébergés sur une infrastructure dédiée, opérée par Ellipsys.

Quelles informations sont transférées vers la plateforme SaaS ?

Uniquement des métadonnées techniques, sous forme de fichiers CSV standardisés que le client peut contrôler avant leur transfert. Les données métier ne sont jamais exploitées, et les logs d’audit peuvent être anonymisés avant transfert.

Où consulter le data lineage en mode SaaS ?

Dans le portail Web Mosaïc, dans des solutions tierces comme les data catalogues du marché, ou via les mécanismes d’intégration du client.

Comment détecter les flux inutilisés ?

En croisant le data lineage avec les logs d’audit : les flux réellement utilisés sont identifiés, et les flux inutilisés (les branches mortes) apparaissent.

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

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

{openAudit} expose le data lineage via son portail Web Mosaïc, mais les métadonnées consolidées peuvent aussi être publiées vers les data catalogues du marché, souvent limités en matière de data lineage. Les équipes de gouvernance travaillent ainsi dans un seul outil.

Point clé : collecte, connexion et reconstruction du data lineage restent dans le référentiel technique {openAudit}, indépendant du catalogue cible.

Architecture

Après traitement par le moteur oA.Job, les métadonnées sont consolidées dans la base de données columnar oA.mdb : data lineage au champ, usages et, le cas échéant, informations de gouvernance. Les catalogues sont alimentés à partir de ce référentiel unique, via des connecteurs d’exposition dédiés ; ils ne consomment que ces métadonnées consolidées, jamais les sources techniques d’origine.

Connecteurs d’exposition

Les connecteurs assurent la publication automatisée du data lineage, les synchronisations continues, la gestion des restrictions et le support de plusieurs Workspaces. L’exposition peut être complète ou partielle selon les capacités d’affichage du catalogue, le data lineage produit en amont restant disponible au champ.

Catalogues supportés à ce jour : 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 puis exposés dans le catalogue. Les utilisateurs distinguent ainsi les flux « vivants », consommés par des outils ou requêtés, des flux et objets non consommés (souvent plus de 80 % de l’ensemble).

Usage typique : identifier dans le data catalogue les objets candidats à la rationalisation ou au décommissionnement.

Questions fréquentes

Quels data catalogues {openAudit} peut-il alimenter en data lineage ?

Les connecteurs disponibles alimentent à ce jour DataGalaxy, Zeenea et Collibra.

Pourquoi alimenter un data catalogue avec le data lineage d'{openAudit} ?

Les data catalogues présentent souvent de fortes limitations sur le data lineage. {openAudit} le reconstruit dans son référentiel technique, puis le publie vers le catalogue via des connecteurs dédiés : publication automatisée, synchronisations continues, gestion des restrictions et support des différents Workspaces. Les équipes de gouvernance n’ont ainsi qu’un seul outil.

Le data lineage est-il exposé au niveau du champ dans le catalogue ?

Le data lineage est produit au champ dans le référentiel d’{openAudit}. Son exposition dans le catalogue peut être complète ou partielle, selon les capacités d’affichage du catalogue cible.

Peut-on voir dans le catalogue quelles données sont réellement utilisées ?

Oui, lorsque les logs d’audit sont disponibles. Les usages sont intégrés au référentiel puis exposés vers le catalogue, qui distingue les flux consommés des objets non consommés, souvent plus de 80 % de l’ensemble.

Data lineage - les principes de la conteneurisation des connecteurs

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

La collecte {openAudit} repose sur des composants conteneurisés déployés dans l’environnement du Client, au plus près des systèmes analysés : un conteneur par technologie (bases de données, plateformes ETL/ELT, outils de data visualisation, bases d’audit), compatible Docker et Podman, en déploiement On-Premise, SaaS ou hybride.

ETL / ELT

SAP Data ServicesIBM DataStageTalendSSISAb InitioStambiadbtOracle Data IntegratorInformatica PowerCenter

Bases de données

OracleTeradataIBM DB2SQL ServerGoogle BigQueryPostgreSQL

Langages et scripts

SQLJavaPerlCOBOL

Datavisualisation et reporting

SAP BusinessObjectsIBM CognosPower BITableauQlik SenseSSRSCrystal ReportsDigDashStrategySASLookerSpotfire

Point clé : extracteurs et anonymiseurs sont découplés des moteurs de traitement ; chaque composant se déploie et se met à jour indépendamment.

Extraction

Les extracteurs se connectent aux technologies analysées via des comptes de service dédiés et collectent les métadonnées des bases de données, plateformes ETL/ELT, outils de datavisualisation, bases d’audit et du scheduleur. Chaque extracteur produit un format de sortie homogène, quelle que soit la technologie.

Anonymisation

Lorsqu’elle est requise, un conteneur d’anonymisation s’insère entre la collecte et la production des fichiers d’échange : chaînes de caractères, paramètres applicatifs et valeurs littérales (constantes SQL…) sont remplacés par des variables techniques. Les dépendances sont conservées, les informations sensibles supprimées.

Fichiers d’échange

Les composants produisent des fichiers CSV standardisés : objets techniques, dépendances, transformations et, lorsqu’elles sont disponibles, informations d’usage. Le Client peut les archiver, les contrôler ou les valider avant leur transfert.

Traitement

Les composants centraux d’{openAudit} exploitent ces fichiers pour reconstruire les dépendances, consolider les métadonnées, intégrer les usages issus des logs d’audit et produire le data lineage.

Résultat : une chaîne de collecte homogène, indépendante des technologies analysées et des modes de déploiement.

Questions fréquentes

Comment {openAudit} collecte-t-il les métadonnées ?

Avec des composants conteneurisés déployés dans l’environnement du client, un par technologie. Ils se connectent aux bases de données, plateformes ETL/ELT, outils de datavisualisation, bases d’audit et au scheduleur avec des comptes de service dédiés, et produisent des fichiers CSV standardisés.

Quelles technologies sont couvertes par les collecteurs ?

Côté ETL/ELT : SAP Data Services, IBM DataStage, Talend, SSIS, Ab Initio, Stambia, dbt, Oracle Data Integrator et Informatica PowerCenter. Côté bases : Oracle, Teradata, IBM DB2, SQL Server, Google BigQuery et PostgreSQL. Côté dataviz : SAP BusinessObjects, IBM Cognos, Power BI, Tableau, Qlik Sense, SSRS, Crystal Reports, DigDash, Strategy, SAS, Looker et Spotfire. Ainsi que les langages SQL, Java, Perl et COBOL.

Comment fonctionne l'anonymisation des métadonnées ?

Un conteneur dédié, placé entre la collecte et le transfert, remplace les chaînes de caractères, paramètres applicatifs et valeurs littérales par des variables techniques, avant la production des fichiers d’échange. Les dépendances techniques sont conservées.

Dans quels environnements les collecteurs peuvent-ils être déployés ?

En On-Premise, en SaaS ou en hybride, avec Docker ou Podman. Chaque composant peut être déployé et mis à jour indépendamment.

Data lineage - protocoles de connexion aux différentes technologies analytiques

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

{openAudit} acquiert les métadonnées par les interfaces natives que les éditeurs exposent officiellement : protocoles de base de données (JDBC, ODBC), API REST, SDK, référentiels techniques ou exports standardisés. Les collectes passent par des comptes de service dédiés, limités aux métadonnées, avec chiffrement des mots de passe après première utilisation.

Connecteurs disponibles

ETL / ELT

SAP Data ServicesIBM DataStageTalendSSISAb InitioStambiadbtOracle Data IntegratorInformatica PowerCenter

Bases de données

OracleTeradataIBM DB2SQL ServerGoogle BigQueryPostgreSQL

Langages et scripts

SQLJavaPerlCOBOL

Datavisualisation et reporting

SAP BusinessObjectsIBM CognosPower BITableauQlik SenseSSRSCrystal ReportsDigDashStrategySASLookerSpotfire

Bases de données

Via JDBC, ODBC ou des connecteurs propriétaires : schémas, tables, vues, procédures stockées et, lorsqu’elles sont analysées, statistiques d’usage.

ETL / ELT

Via les référentiels techniques, les API d’administration ou des exports XML / JSON : jobs, transformations, dépendances et flux de données.

Outils de Data Visualisation

Via SDK, API REST ou référentiels internes : sources de données, couches sémantiques, dashboards et règles de gestion. Le data lineage des sources est ainsi prolongé jusqu’à la cellule du dashboard.

Environnements sécurisés

Les collectes peuvent être supervisées via VMware Horizon, OpenOTP (double authentification) ou un bastion d’administration, avec journalisation et traçabilité des opérations. Le mécanisme est le même en environnement Cloud, On-Premise ou hybride.

Questions fréquentes

Quels protocoles {openAudit} utilise-t-il pour collecter les métadonnées ?

Les interfaces natives exposées par les éditeurs : JDBC, ODBC et connecteurs propriétaires pour les bases de données ; référentiels techniques, API d’administration et exports XML ou JSON pour les ETL/ELT ; SDK, API REST et référentiels internes pour les outils de datavisualisation.

Quels accès faut-il accorder pour un projet de data lineage ?

Des comptes de service dédiés, avec un accès limité aux métadonnées. Les mots de passe sont chiffrés après leur première utilisation.

Que collecte-t-on dans les outils de datavisualisation ?

Les sources de données, les couches sémantiques, les dashboards et les règles de gestion. Le data lineage est ainsi prolongé jusqu’à la couche de restitution, et jusqu’à la cellule du dashboard.

La collecte est-elle possible dans un environnement très sécurisé ?

Oui. Les collectes peuvent être supervisées via VMware Horizon, OpenOTP (double authentification), un bastion d’administration, avec journalisation et traçabilité des opérations. Le mécanisme est le même en environnement Cloud, On-Premise ou hybride.