Migration DataViz - migrer de Cognos vers Power BI
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é.
La conversion s’appuie sur {oa-lake} : les calculs et règles métier issus des Frameworks sont encapsulés sous forme de pipelines SQL, et les objets métier alimentent la couche sémantique interopérable d’{oa-lake}. Power BI se connecte à ce modèle prêt à l’emploi (voir ci-dessous).
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.
{oa-lake} : le socle de toute migration DataViz
Migrer d’un outil de reporting à un autre répond au besoin immédiat, mais déplace la logique métier dans un nouveau modèle propriétaire : au prochain changement d’outil, tout est à reconstruire.
C’est pourquoi chaque migration DataViz s’appuie désormais sur le middleware {oa-lake}, qui joue deux rôles :
- Encapsuler l’intelligence. Les requêtes, calculs, variables et règles métier extraits par {openAudit} sont transcrits en SQL et exécutés dans {oa-lake} sous forme de mini pipelines SQL (un mini ETL), au lieu d’être réécrits dans l’outil cible.
- Préserver la couche sémantique. La couche sémantique construite au fil des années dans la plateforme source (univers, Frameworks, modèles) est reconstituée dans la couche sémantique interopérable d’{oa-lake}, qui alimente ensuite l’outil cible.
Power BI se connecte à {oa-lake} et consomme un modèle déjà prêt : objets métier, KPI et sécurité ne sont plus enfermés dans un nouveau modèle propriétaire.
- Définir une fois, utiliser partout : client, contrat, produit… une seule définition, valable pour tous les outils consommateurs.
- KPI et sécurité centralisés : des indicateurs calculés une seule fois et une sécurité appliquée uniformément, quel que soit l’outil de restitution.
- Data prep rationalisée : des mini pipelines SQL mutualisés remplacent la préparation dispersée dans chaque outil.
- Outils BI interchangeables : Power BI, Looker, DigDash ou tout autre outil se connecte à un modèle déjà prêt, sans redéfinir la logique métier.
- Piloté comme du code : pipelines SQL et modèle sémantique en YAML/JSON, versionnés dans Git et déployés par Terraform.
- Prêt pour l’IA : les mêmes données et la même sémantique alimentent la BI, les LLM et les agents IA.
Point clé : migrer vers {oa-lake}, c’est migrer une dernière fois. La logique métier devient un actif de l’entreprise, indépendant des éditeurs.
Découvrir {oa-lake} → · Interopérabilité SQL et couche sémantique →
