{openAudit}

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

Tue, 02 Jun 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.

Data lineage - architecture on prem'

Tue, 02 Jun 2026 00:00:00 +0000

Dans les environnements les plus exigeants en matière de sécurité (banque, assurance, etc.), type {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.

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.

Les fichiers sont ensuite transmis à notre 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érenciel peut faire l’objet de dump au format souhaité par le client pour opérer des analyses spécifiques : le référérenciel est extrêmement riche et nous mettons à disposition différentes requêtes pour en faciliter l’exploration.

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.

Data lineage - architecture SaaS

Tue, 02 Jun 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.

Data lineage - les principes de la conteneurisation des connecteurs

Tue, 02 Jun 2026 00:00:00 +0000

L'architecture {openAudit} repose sur des composants conteneurisés déployés dans l'environnement du Client.

Chaque composant est spécialisé pour une technologie donnée et assure la collecte des métadonnées nécessaires à la reconstruction du data lineage : bases de données, plateformes ETL/ELT, outils de data visualisation et bases d’audit.

Les extracteurs produisent des fichiers CSV standardisés contenant les métadonnées collectées. Ces fichiers peuvent être contrôlés par le Client avant leur transfert vers les composants centraux de traitement.

Lorsqu’une anonymisation est requise, un conteneur dédié est inséré dans la chaîne de collecte afin de remplacer les chaînes de caractères, constantes SQL et autres informations sensibles par des variables avant la production des fichiers d’échange.-

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

Tue, 02 Jun 2026 00:00:00 +0000

L'acquisition des métadonnées repose sur les interfaces natives exposées par les technologies analysées par {openAudit}.

Selon les plateformes, les collectes utilisent des protocoles de base de données, des API REST, des SDK, des référentiels techniques ou des exports standardisés.

Migration DataViz - migrer de Cognos vers Power BI

Tue, 02 Jun 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.

Migration DataViz - migrer de SAP BO vers GCP Looker

Tue, 02 Jun 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.

Migration DataViz - migrer de SAP BO vers Power BI

Tue, 02 Jun 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 .

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

Tue, 02 Jun 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.

Migration DataViz - une couche d’interopérabilité SQL amont-aval - {oa-lake}

Tue, 02 Jun 2026 00:00:00 +0000

Les plateformes décisionnelles reposent souvent sur plusieurs bases de données, plusieurs data warehouses / data lakes et plusieurs outils de restitution.

{oa-lake} introduit une couche SQL intermédiaire entre les sources de données et les outils de datavisualisation.

Les règles de gestion, objets métier, dimensions, mesures et calculs sont centralisés dans cette couche puis exposés aux outils consommateurs.

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

Tue, 02 Jun 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é.

Migration ETL - connecteurs ETL legacy pour migration SQL

Tue, 02 Jun 2026 00:00:00 +0000

Les plateformes ETL reposent sur des connecteurs, des composants de transformation, des mécanismes de paramétrage et des stratégies d'exécution propres à chaque éditeur.

{openAudit} analyse ces composants, reconstruit leur comportement puis génère une représentation SQL indépendante de la technologie source.

Migration ETL - de l'ETL legacy vers dbt

Tue, 02 Jun 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.

Migration ETL - de l'ETL legacy vers le SQL

Tue, 02 Jun 2026 00:00:00 +0000

Les plateformes ETL historiques implémentent principalement des filtres, jointures, agrégations, mappings et transformations qui peuvent être exprimés en SQL.

{openAudit} analyse les jobs ETL, reconstruit les flux et génère un équivalent SQL indépendant de la technologie source.

Migration ETL - de l'ETL legacy vers un ETL SQL ouvert - {oa.tbx}

Tue, 02 Jun 2026 00:00:00 +0000

Une fois les traitements ETL convertis en SQL par {openAudit}, ils peuvent être exécutés dans le conteneur {oa.tbx}.

{oa.tbx} fournit un environnement d’exécution pour des traitements SQL, Python ou Java, pilotés par des référentiels de configuration et d’orchestration.

About

Mon, 01 Jan 0001 00:00:00 +0000

Ellipsys a été fondée par Samuel Morin en 2013 au Luxembourg. Ellipsys porte principalement la solution {openAudit} qui a pour principal objectif de donner de la visibilité sur la complexité des Systèmes d’Information. En effet, l’évolution de ces derniers est de moins en moins bien maîtrisée : une volumétrie galopante, des technologies plus nombreuses, des processus plus complexes, plus hétérogènes et plus imbriqués qui ne sont pas nécessairement en adhérence avec l’usage de ces informations.