Ellipsys — Data lineage & migration BI/ETL vers des architectures ouvertes |

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

Thu, 02 Jul 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.

Point clé : les traitements migrés deviennent des instructions SQL exécutables indépendamment de la plateforme ETL d’origine.

Principes

L’encapsulation du SQL se fait dans des conteneurs ouverts, en mode ETL.

Des conteneurs : les transformations s’exécutent dans un conteneur externe, {oa.tbx}, détaché de la base de données cible. Les conteneurs temporaires servent de zones de stockage intermédiaires où les données sont chargées avant transformation. Les jobs sont testés pour vérifier leur fonctionnement, et possiblement les données, pour garantir leur intégrité.
Orchestration avec Airflow : Airflow pilote l’exécution des conteneurs, étape par étape. Chaque transformation, au sein d’un conteneur, est définie comme un job.

Le scheduling d’un ETL migré vers Airflow reprend automatiquement l’ensemble des instructions et de l’ordonnancement d’origine.

Chaîne d’exécution

Les jobs ETL sont convertis en SQL par {openAudit}.

Les traitements produits sont intégrés dans un référentiel de configuration et un référentiel de pilotage utilisés par {oa.tbx}.

Les workflows sont ensuite orchestrés par des outils tels qu’Airflow ou Dagster.

Conteneur d’exécution

{oa.tbx} exécute les traitements décrits dans les workflows.

Les dataflows peuvent combiner :

SQL ;
Python ;
Java ;
autres.

Le moteur peut également s’appuyer sur des bases embarquées telles que DuckDB pour certains traitements intermédiaires.

Sources et cibles

Les données d’entrée peuvent provenir de n’importe quelle technologie accessible en SQL ou JDBC.

Les résultats peuvent être chargés vers tout système cible compatible avec les mécanismes d’écriture standards.

L’architecture reste indépendante des technologies source et cible.

Orchestration

L’orchestration reste séparée des traitements.

Les dépendances, paramètres d’exécution, planifications et déclenchements sont gérés par la couche workflow.

Les traitements métier restent contenus dans les scripts SQL et les dataflows exécutés par {oa.tbx}.

Bénéfices

{oa.tbx} exécute des pipelines SQL ouverts, orchestrés par Airflow et indépendants des runtimes propriétaires des plateformes Cloud.

Sur l’ensemble des jobs migrés — des volumes allant de quelques milliers à plus de 50 millions de lignes — les temps d’exécution se comptent souvent en quelques secondes seulement, avec un statut OK quasi systématique.

Gouvernance et data lineage

Une fois les traitements ETL convertis en SQL, {oa.tbx} conserve la trace complète entre la logique d’origine et le SQL exécuté. Ce data lineage est exposé à deux niveaux de lecture, adaptés à des besoins différents.

Point clé : une vue synthétique pour la gouvernance, un détail exhaustif pour la maintenance.

Vue high level du pipeline : seules les tables source et cible sont visibles ; les stages ETL intermédiaires sont regroupés en un bloc SQL unique. Une vue lisible, même sur des pipelines complexes.

Détail au clic sur une transformation : au clic sur un stage (par exemple un Transformer), son équivalent SQL généré s’affiche, avec ses inputs/outputs et ses métadonnées d’origine (type, stage ID). Le mapping est immédiat entre la logique ETL d’origine et le SQL exécuté.

Résultat : une gouvernance complète du pipeline migré, de la vue d’ensemble jusqu’au SQL exécuté, quelle que soit la plateforme ETL d’origine.

SQL comme format pivot

Le SQL produit par {openAudit} devient le support principal des transformations.

Les règles métier, jointures, agrégations et calculs sont exprimés dans un format ouvert, versionnable et indépendant des outils ETL historiques.

Résultat : une chaîne ETL/ELT basée sur SQL, orchestrée par workflows et exécutée dans un environnement ouvert.

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

Fri, 03 Jul 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.

Point clé : les sources de données et les outils de restitution deviennent indépendants les uns des autres.

Architecture

{oa-lake} se connecte simultanément à plusieurs systèmes de données : bases relationnelles, data warehouses, lakehouses, fichiers ou APIs.

Les requêtes sont fédérées par un moteur SQL distribué qui exécute les jointures, calculs et transformations nécessaires.

Le SQL produit reste standard et exécutable sur différents moteurs, ce qui limite le lock-in technologique.

Les objets métier sont définis une seule fois puis exposés aux outils consommateurs.

Sources de données

Les données restent dans leurs systèmes d’origine.

Oracle, SQL Server, PostgreSQL, DB2, BigQuery, Snowflake, Redshift, Azure SQL (et autres) ou des fichiers peuvent être interrogés dans une même requête.

Le mécanisme de Push-Down SQL évite toute copie systématique des données : les requêtes s’exécutent directement sur les systèmes existants, dans le respect des architectures en place.

Usage typique : construire un dashboard à partir de données réparties sur plusieurs plateformes sans migration préalable.

Couche métier SQL

Les dimensions, mesures, hiérarchies et règles de calcul sont centralisées dans {oa-lake}.

Cette couche devient le point d’entrée unique pour les outils de restitution.

Les règles de gestion ne sont plus dupliquées dans chaque plateforme de datavisualisation.

Point clé : une seule définition des indicateurs pour l’ensemble du système décisionnel.

Cache Parquet

Les données peuvent être matérialisées au format Parquet.

Cette couche de cache réduit les temps de réponse et limite les sollicitations des systèmes sources. Elle est gérée automatiquement selon les usages observés, sans intervention manuelle.

Usage typique : accélérer les traitements analytiques les plus coûteux.

Data visualisation

Les outils de restitution se connectent au modèle exposé par {oa-lake}.

Power BI, Looker, Spotfire, Tableau, Qlik, SAP BusinessObjects ou tout outil compatible SQL peuvent exploiter les mêmes objets métier.

Les changements d’outils de data visualisation n’impliquent plus de reconstruire les dimensions, mesures et règles de calcul.

Migration progressive

Plusieurs outils peuvent coexister pendant une phase de transition.

Un même modèle métier peut être exposé simultanément vers plusieurs plateformes de restitution.

Résultat : migration progressive des usages sans modification des systèmes de données.

Data Lineage

Le data lineage reconstruit par {openAudit} reste disponible sur l’ensemble de la chaîne.

Les dépendances sont documentées depuis les systèmes sources jusqu’aux indicateurs exposés dans les dashboards.

Point clé : les transformations, calculs et usages restent traçables sur l’ensemble de l’architecture.

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.

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.

Data lineage - les principes de la conteneurisation des connecteurs

Thu, 02 Jul 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.

Point clé : les extracteurs et les anonymiseurs sont découplés des moteurs de traitement. Chaque composant peut être déployé et mis à jour indépendamment.

Principes techniques

Un conteneur dédié par technologie.
Collecte des métadonnées au plus près des systèmes analysés.
Anonymisation optionnelle avant transfert.
Production de fichiers CSV standardisés.
Compatibilité Docker, Podman.
Déploiement On-Premise, SaaS ou hybride.
Mise à jour indépendante des composants.

Extraction

Les extracteurs se connectent aux technologies analysées à l’aide de comptes de service dédiés.

Les métadonnées collectées concernent :

Les bases de données.
Les plateformes ETL / ELT.
Les outils de datavisualisation.
Les bases d’audit.
Le scheduleur.

Chaque extracteur produit un format de sortie homogène indépendamment de la technologie analysée.

Anonymisation

Un conteneur d’anonymisation peut être positionné entre la collecte et le transfert des métadonnées.

Les éléments suivants peuvent être remplacés par des variables techniques :

Chaînes de caractères.
Paramètres applicatifs.
Valeurs littérales.

L’objectif est de conserver les dépendances techniques tout en supprimant les informations sensibles.

Point clé : l’anonymisation intervient avant la génération des fichiers transférés.

Fichiers d’échange

Les composants produisent des fichiers CSV standardisés contenant :

Les objets techniques.
Les dépendances.
Les transformations.
Les informations d’usage lorsque celles-ci sont disponibles.

Ces fichiers peuvent être archivés, contrôlés ou validés par le Client avant leur transfert.

Traitement

Les fichiers produits sont exploités par les composants centraux de {openAudit} 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.

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

Thu, 02 Jul 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.

Point clé : les collecteurs utilisent les mécanismes officiellement exposés par les éditeurs (JDBC, ODBC, API REST, SDK, référentiels techniques, exports).

Principes techniques

Comptes de service dédiés.
Accès limité aux métadonnées.
Compatibilité On-Premise, Cloud et hybride.
Utilisation des interfaces natives des plateformes.
Chiffrement des mots de passe après première utilisation.

Bases de données

Les bases relationnelles sont analysées via :

JDBC.
ODBC.
Connecteurs propriétaires.

Les collectes portent sur :

Schémas.
Tables.
Vues.
Procédures stockées.
Statistiques d’usage (lorsque analysés).

ETL / ELT

Les plateformes ETL/ELT sont analysées via :

Référentiels techniques.
API d’administration.
Exports XML ou JSON.

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

Les jobs.
Les transformations.
Les dépendances.
Les flux de données.

Outils de Data Visualisation

Les outils de data visualisation sont analysés via :

SDK.
API REST.
Référentiels internes.

Les collectes portent sur :

Les sources de données.
Les couches sémantiques.
Les dashboards.
Les règles de gestion.

Ces informations permettent de prolonger le data lineage jusqu’à la couche de restitution.

Usage typique : faire du data lineage dans les sources et le relier au data lineage dans la couche de data visualisation, jusqu’à la cellule du dashboard.

Environnements sécurisés

Les collectes peuvent être supervisées de façon sécurisée via :

VMware Horizon.
OpenOTP (double authentification).
Bastion d’administration.
Journalisation et traçabilité des opérations.

Les accès restent limités aux composants nécessaires à la collecte des métadonnées.

Pour information : même mécanisme de collecte en environnement Cloud, On-Premise ou hybride.

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.

Migration ETL - connecteurs ETL legacy pour migration SQL

Thu, 02 Jul 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.

Point clé : la conversion repose sur l’analyse des composants ETL et non sur une simple traduction syntaxique.

Analyse des composants

Les référentiels techniques sont analysés pour identifier les connecteurs, les transformations, les paramètres, les dépendances et les mécanismes d’exécution.

Les composants sont convertis vers un modèle intermédiaire commun avant génération SQL.

Cette approche est identique quelle que soit la technologie source.

Connecteurs

Les connecteurs de lecture et d’écriture sont analysés pour reconstruire les flux entre les systèmes.

Les paramètres de connexion, les requêtes, les formats de données et les mappings sont intégrés dans le modèle de migration.

Les flux peuvent provenir de bases relationnelles, de fichiers, d’APIs ou de plateformes Cloud.

Usage typique : reconstruction des échanges entre Oracle, SQL Server, PostgreSQL, fichiers plats ou stockages Cloud.

Transformations

Les composants de transformation sont convertis en instructions SQL.

Filtres, jointures, agrégations, lookups, mappings, conversions de types, calculs de colonnes et expressions conditionnelles sont reconstruits dans le modèle SQL cible.

Point clé : chaque transformation devient une opération SQL explicite.

Paramétrage

Les variables d’environnement, paramètres de jobs, bibliothèques partagées et composants réutilisables sont analysés pendant la conversion.

Les dépendances entre traitements et les mécanismes de paramétrage sont conservés dans le modèle généré.

Technologies supportées

Les moteurs de migration couvrent notamment IBM DataStage, Talend, SAP BODS, SSIS, ODI, Informatica PowerCenter, Stambia, Semarchy xDI et Ab Initio.

La méthodologie reste identique : analyse des composants, reconstruction des flux puis génération SQL.

Résultat : une approche homogène appliquée à des technologies ETL différentes.

SQL comme format pivot

Une fois les composants reconstruits, les traitements sont convertis vers un modèle SQL indépendant de la plateforme source.

Le SQL généré peut ensuite être adapté à Snowflake, BigQuery, Databricks SQL, Redshift, PostgreSQL, SQL Server ou tout autre moteur compatible.

Point clé : le SQL devient le format commun de représentation des traitements.

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.

Migration ETL - de l'ETL legacy vers le SQL

Thu, 02 Jul 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.

Point clé : les traitements sont reconstruits sous forme de SQL documenté et versionnable.

Analyse des traitements

Les référentiels ETL sont analysés pour reconstruire les sources, les cibles, les transformations, les paramètres et les dépendances entre traitements.

Les métadonnées collectées permettent de reconstituer le fonctionnement réel des flux.

Les composants inutilisés ou non consommés peuvent être identifiés avant migration.

Résultat : un périmètre de migration réduit aux traitements réellement utilisés.

Reconstruction des flux

Les chaînes de traitement sont reconstruites à partir des jobs ETL.

Les dépendances entre traitements, les flux intermédiaires, les variables et les paramètres sont intégrés dans le modèle cible.

Cette cartographie constitue le point d’entrée de la conversion.

Rationalisation

Le croisement du data lineage (jusqu’au champ) avec les usages réellement observés permet d’identifier les données effectivement consommées et d’écarter celles qui ne le sont pas.

Chaque job est également analysé pour en évaluer la complexité : nombre d’étapes, profondeur des sous-traitements, types de transformations et dépendances externes. Ces métriques sont agrégées en un score de complexité, utilisé pour prioriser et planifier la migration.

Résultat : un périmètre de migration réduit aux traitements réellement utilisés, priorisé selon leur complexité réelle.

Génération SQL

Les transformations détectées sont converties en SQL.

Filtres, jointures, agrégations, lookups, mappings et calculs sont traduits en instructions SQL successives, à plat.

Le SQL produit conserve le découpage logique des traitements d’origine.

Point clé : chaque étape du traitement reste identifiable dans le SQL généré.

Exemple : jobs IBM DataStage

Sur un patrimoine DataStage, chaque type de stage est traduit selon sa logique propre :

Runtime Column Propagation (RCP) : la liste des colonnes n’est pas figée dans le job ; elle est générée dynamiquement dans le SQL, pilotée par les variables passées au job.
Connecteurs Oracle (lecture / écriture) : SELECT, UPDATE, MERGE ou INSERT générés à partir des options du stage.
Change Capture (CDC) : comparaison Before/After sur clés primaires, détection des lignes nouvelles, modifiées et supprimées.
Transformer CDC : routage conditionnel vers un flux dédié selon le code de changement détecté.
Shared Container : bloc logique factorisé, rendu comme un bloc SQL standardisé et réutilisé dans plusieurs jobs.
Column Generator : colonnes calculées traduites en expressions SQL typées.
Modify : conversions de types traduites en CAST SQL (ex. string vers timestamp).
Funnel : fusion de plusieurs flux via UNION SQL, avec homogénéisation du schéma de sortie.

Résultat observé : sur un patrimoine de plusieurs centaines de jobs DataStage, plus de 95 % des traductions SQL aboutissent dès la première exécution.

Adaptation aux plateformes cibles

Le SQL généré peut être adapté aux dialectes des plateformes cibles.

Les fonctions, types de données et mécanismes spécifiques sont pris en compte lors de la génération.

Les mêmes traitements peuvent être produits pour Snowflake, BigQuery, Databricks SQL, Redshift, PostgreSQL, SQL Server ou d’autres moteurs compatibles SQL.

Orchestration

Les dépendances et l’ordonnancement des traitements sont conservés.

Les traitements générés peuvent être intégrés dans les outils d’orchestration déjà présents dans le Système d’Information.

Usage typique : intégration dans Airflow, Control-M ou tout autre ordonnanceur existant.

SQL comme format pivot

Le SQL devient la représentation commune des traitements.

Les transformations ne dépendent plus des composants propriétaires de la plateforme ETL d’origine.

Les traitements peuvent être versionnés, relus, testés et déployés indépendamment de la technologie source.

Point clé : la logique de transformation reste maîtrisée par l’entreprise et ne dépend plus d’un moteur ETL spécifique.

Politique de confidentialité

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

Cette page décrit comment Ellipsys traite les données personnelles des visiteurs de ce site.

Responsable du traitement

Ellipsys est responsable du traitement des données collectées via ce site. Pour toute question, vous pouvez nous contacter via le formulaire de la page Contact.

Données collectées

Ce site ne dépose aucun cookie et n’utilise aucun outil de suivi ou d’analyse d’audience.

La seule donnée personnelle collectée est celle que vous nous transmettez volontairement via le formulaire de contact (nom, adresse e-mail, société, message). Ces informations sont utilisées uniquement pour répondre à votre demande.

Conservation des données

Les données transmises via le formulaire de contact sont conservées le temps nécessaire au traitement de votre demande, puis supprimées.

Vos droits

Conformément au Règlement Général sur la Protection des Données (RGPD), vous disposez d’un droit d’accès, de rectification et de suppression des données vous concernant. Pour exercer ces droits, contactez-nous via la page Contact.

Modifications

Cette politique de confidentialité peut être mise à jour. La date de dernière mise à jour figure en haut de cette page.

{oa-lake} — couche d'interopérabilité

Wed, 01 Jul 2026 00:00:00 +0000

{oa.tbx} — un ETL SQL

Wed, 01 Jul 2026 00:00:00 +0000

À propos

Wed, 01 Jul 2026 00:00:00 +0000

Contact

Wed, 01 Jul 2026 00:00:00 +0000

{openAudit} - Migration

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

{openAudit} - Data Lineage

Mon, 29 Jun 2026 00:00:00 +0000

Terms of Service

Fri, 01 Dec 2023 00:00:00 +0000

Add your company legal terms here…