{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...

  How can analytics pipelines be made portable?   Today, major cloud platforms offer extremely powerful data environments that are generally the target in data stack modernization projects: Microsoft Fabric, Databricks, Glue, Snowflake, BigQuery, etc. These platforms are very well suited to many analytics and Big Data uses. But in many projects, another question is beginning to emerge: how to ensure that a technological choice made today does not create a perpetual dependency? Behind the processes often lie specific runtimes, proprietary APIs, native authentication mechanisms and, more generally, strong dependencies on the chosen Cloud provider. It also concerns his own informational sovereignty. In short...     A portable and interoperable approach For several major clients, we are working on approaches aimed at preserving the portability of data pipelines and limiting their dependence on a specific environment. The idea is to keep SQL processes open, more ea...