Changer d'outil de dataviz - Ne pas perdre sa couche sémantique en route

 

Changer d'outil de dataviz -  Ne pas perdre sa couche sémantique en route  Les projets de sortie d'outils de dataviz legacy (SAP BO, Cognos, Spotfire…) se multiplient : modernisation de la data stack, compétences qui se raréfient, et désormais des enjeux de souveraineté. Sauf que… Au fil des années, métiers et IT ont rivalisé de créativité, rendant chaque technologie un peu plus "indéboulonnable", avec : Une couche sémantique propre à chaque outil (univers BO, Framework Manager Cognos, Information Designer Spotfire…), qui traduit les champs techniques en notions métier : Clients, Contrats, Chiffre d'affaires, Marge, etc.  Une data prep' propre à chaque outil, et souvent à chaque rapport : jointures, filtres, calculs…   Sortir de son legacy est donc risqué, rarement plébiscité par le métier (qui est souvent le payeur)… et si c'est pour se retrouver coincé dans une nouvelle techno dans 5 ou 10 ans… Et si la couche sémantique et la data prep' en place survivaient à la migration ? Une autre approche consisterait à sortir ces logiques de la couche de dataviz pour les placer dans un socle ouvert : une couche d'interopérabilité SQL open source, née de nos projets de migration dataviz, que nous avons baptisée {oa‑lake}. schéma d'architecture :  Retour d'Expérience 3' :  Groupe ADEO / Leroy Merlin - Salon Big Data & AI Paris 2026    1. La couche sémantique, reconduite et mutualisée La couche sémantique est sans doute l'actif le plus précieux de la couche de dataviz, quand elle existe. Or elle n'a souvent pas d'équivalent formel dans les outils cibles. Power BI, par exemple, propose des « modèles sémantiques », mais ils restent propres à l'outil, écrits en DAX, et se multiplient au fil des rapports et des équipes : rien de comparable à un univers BO partagé par toute l'entreprise. Dans {oa‑lake}, elle est reconduite et mutualisée, y compris dans ses mécanismes les plus fins : prompts, objets imbriqués ou agrégés (Aggregate_Aware), contextes. Un catalogue unique d'objets métier, de KPI et de règles de sécurité, quel que soit l'outil.   2. La data prep' et les règles de gestion, converties en SQL Bien cachées dans les rapports, elles sont extraites et converties automatiquement en SQL, puis rationalisées et mutualisées. Et tout étant en SQL interopérable, les sources peuvent être multiples (Oracle, SQL Server, Snowflake, BigQuery, fichiers…) : chaque modèle s'appuie sur sa source, et une même requête peut croiser des objets métier issus de modèles différents. L'outil de dataviz, lui, n'envoie plus que du SQL standard à {oa‑lake}.   3. La prochaine migration se limite à reconnecter un outil Power BI, Looker, Tableau, Qlik… consomment alors les mêmes objets métier, les mêmes règles de gestion, et bénéficient des mêmes sécurités. Puisqu'ils n'embarquent plus la complexité, les outils de dataviz deviennent interchangeables, y compris avec des outils open source comme Apache Superset, pour construire une chaîne décisionnelle ouverte de bout en bout. Côté utilisateur, le portail {oa‑lake} propose une interface d'exploration : on manipule des objets métier sans écrire de SQL, le SQL généré reste visible, avec possibilité de créer simplement des variables imbriquées très évoluées.   Interface de gestion de la couche sémantique :