{openAudit}, le data lineage et les usages de l'information pour transformer les SI

  Changer d'outil de DataViz, sans lock-in   Changer d'outil de dataviz est rarement un choix de confort. Fin de support, coûts de licence, rachat d'éditeur, limites techniques, etc.  Le problème, c'est que la migration n'est que la moitié du chemin. Une fois l'effort fait, on se retrouve souvent embarqué avec une nouvelle solution tout aussi "propriétaire". Elle marie souvent en plus les sources et la restitution. Au prochain changement d'outil, tout est à refaire...   Une approche permet de remédier à ça : création d'une couche d'interopérabilité agnostique amont / aval   - Comment ? 3 étapes (à découvrir en live au salon Big Data et AI 2026 avec ADEO / Leroy Merlin) : Conférence ADEO / Leroy Merlin     1, Migrer les sources vers une couche SQL ouverte Oracle, SQL Server, PostgreSQL, BigQuery, Snowflake, Redshift, fichiers… Chaque source y est connectée et interrogée par un moteur SQL fédéré et ouvert, {oa-lake} . Un cache Parquet ac...

Exit    [  DataStage  ] - and retain its business processes When we talk about leaving DataStage (or another ETL tool), we often think of "technical migration."   While this is certainly a thorny issue, it's an oversimplification. In reality, the real challenge lies (primarily) elsewhere.   In simplified terms, DataStage (or other ETL tools) contains two essential elements at the heart of a company's collective intelligence: Data   that we will call   "   information assets"  , Transformation flows  that    carry business rules and transform this data, which we will call   "functional assets"  .   The risk of a poorly prepared migration is simple: We will change tools… but we will lose or degrade all the intelligence built up over a long period in business processes. Mapping the data and transformations The first step is therefore to offer everyone the opportunity to understand ...