Loading...
Loading...
Modernisation d'une plateforme IBM Cognos Analytics vers Power BI Premium : conversion des modèles Framework Manager en modèles tabulaires, refonte des rapports Report Studio en visuels Power BI, sécurité ligne par ligne préservée, audit de parité.
IBM Cognos Analytics est une plateforme de business intelligence d'entreprise déployée massivement dans les années 2000 à 2015 dans la banque, l'assurance, le secteur public, l'industrie et la distribution. Elle agrège un studio de modélisation (Framework Manager), un studio de rapports (Report Studio), un studio d'analyse (Analysis Studio) et, dans certains cas, un moteur multidimensionnel (TM1). Les organisations qui l'ont adoptée disposent typiquement de plusieurs centaines à plusieurs milliers de rapports actifs, de plusieurs dizaines de modèles Framework Manager et d'une directory Cognos qui gère la sécurité utilisateur. IBM continue de faire évoluer Cognos Analytics, mais la dynamique de marché s'est inversée : la plupart des nouveaux projets BI grandes entreprises se font désormais sur Power BI, Tableau ou Looker. Pour les DSI engagées dans une rationalisation de leur stack data et une bascule vers Microsoft Azure, la question n'est plus si migrer mais quand et comment.
Trois raisons techniques rendent Power BI Premium un successeur naturel à Cognos pour les organisations Microsoft. Premièrement, le modèle tabulaire Power BI (basé sur le moteur SSAS Tabular ou les datasets Power BI) répond aux mêmes besoins que les modèles Framework Manager DMR, en plus performant grâce au moteur en mémoire VertiPaq. Deuxièmement, DAX offre une expressivité comparable aux expressions Cognos et au MDX, avec un écosystème de patterns documenté (DAX Patterns, SQLBI). Troisièmement, l'intégration native dans Microsoft 365 et Azure (Teams, SharePoint, Excel, Synapse) raccourcit la chaîne de diffusion et abaisse la friction d'adoption. Notre expertise IA, Data et Automatisation s'applique à ces migrations, encadrée par la méthodologie ATLAS.
Quatre signaux convergent typiquement vers la décision de migrer. D'abord, le renouvellement des licences Cognos approche et son coût devient difficile à justifier face à un stack Microsoft déjà payé. Ensuite, l'équipe Cognos interne se réduit — départs en retraite des experts, recrutement impossible sur un produit en perte de vitesse. Puis, le métier réclame des fonctionnalités modernes : self-service BI, intégration Excel, mobile natif, IA générative dans le reporting. Enfin, la stratégie data globale bascule vers Azure Synapse, Microsoft Fabric ou un lakehouse Databricks, et la couche de visualisation doit suivre. Quand trois de ces quatre signaux sont présents, le projet de migration s'impose.
Choix par défaut pour les organisations engagées dans Microsoft 365 et Azure. Capacité dédiée, datasets partagés entre workspaces, RLS gérée centralement, intégration native Office. Recommandation principale pour la majorité des migrations Cognos.
Projet plus large incluant un lakehouse moderne, Direct Lake sur OneLake, ingestion Synapse Real-Time. Choix pertinent quand la migration BI s'inscrit dans une refonte data plus globale, pas uniquement un remplacement Cognos.
L'organisation est multi-cloud ou veut éviter une dépendance Microsoft renforcée. Tableau couvre fonctionnellement Cognos mais l'effort de migration est plus important car la sémantique du modèle diffère davantage.
Cas spécifiques liés à l'écosystème data déjà en place : Looker pour les organisations BigQuery / GCP, Qlik pour celles qui valorisent l'approche associative et possèdent déjà la stack Qlik.
Un programme de migration Cognos vers Power BI se structure généralement sur six à dix-huit mois selon la volumétrie et la criticité du parc. Pour un patrimoine de deux cents à cinq cents rapports avec dix à vingt modèles Framework Manager, comptez huit à douze mois avec une cellule de quatre à six personnes : un architecte data Power BI, un développeur senior DAX et tabular, deux ou trois développeurs Power BI, un référent métier détaché à 30 % et un chef de projet. Pour des parcs plus larges (mille rapports et plus, cubes TM1 inclus), un programme pluriannuel structuré en vagues est nécessaire, avec une cellule pouvant monter à dix personnes pendant la phase de pic.
Sous-estimer la discovery initiale. Une instance Cognos mature comporte souvent des centaines de rapports inactifs et des modèles redondants que personne n'a osé supprimer. Migrer à l'identique conduirait à reproduire la dette.
Discovery systématique avec extraction de la directory Cognos par scripts (cogtools, REST API Cognos), classification de chaque rapport par fréquence d'exécution, criticité métier et redondance. Seuls les rapports actifs et stratégiques entrent dans le périmètre de migration, les autres sont archivés ou supprimés. Cette étape réduit typiquement le périmètre de 30 à 50 %.
Reproduire en DAX les calculs Cognos sans saisir l'occasion d'optimiser. Les expressions Cognos ont parfois été contournées sur des limitations historiques du moteur, ces contournements deviennent inutiles voire nuisibles en tabular.
Refactorisation ciblée : chaque mesure complexe est analysée, les contournements documentés sont remplacés par des patterns DAX standards (variables, CALCULATE, time intelligence native). Les optimisations sont enregistrées dans le registre des discordances comme adaptations plateforme, distinctes de la parité métier stricte. Voir la méthodologie ATLAS.
Négliger la sécurité ligne par ligne (RLS). Cognos gère la sécurité via la directory et des filtres dans les packages FM, Power BI utilise des rôles et des filtres DAX. Une mauvaise traduction expose des données ou en cache d'autres à tort.
Audit dédié de la sécurité : extraction du modèle de sécurité Cognos (utilisateurs, rôles, filtres), conception du modèle Power BI équivalent (RLS dynamique via USERPRINCIPALNAME, rôles statiques, sécurité Object Level si nécessaire). Tests de parité spécifiques avec comptes utilisateurs représentatifs avant mise en production. Aucune bascule sans validation explicite du référent sécurité.
Oublier les rapports planifiés et les distributions automatiques. Cognos pousse des PDF ou Excel à des centaines de destinataires via des plannings. Power BI Premium gère cela différemment (subscriptions, Power Automate, paginated reports).
Cartographie des distributions Cognos dès la phase de capture : nombre de plannings, formats, destinataires, fréquences. Pour chaque distribution, un équivalent Power BI est conçu (subscription native, paginated report exporté, ou flux Power Automate). Les destinataires sont migrés progressivement avec double envoi pendant deux à quatre semaines pour valider l'équivalence.
Laisser Cognos et Power BI coexister trop longtemps par prudence. Au-delà de douze mois, la double maintenance coûte plus que la migration elle-même et les écarts de chiffres deviennent inévitables.
Plan de bascule daté par périmètre fonctionnel (finance, RH, opérations, etc.). Chaque périmètre suit un cycle court : migration sur deux à trois mois, double run de deux à quatre semaines, décommissionnement Cognos sous trois mois. La coexistence globale du parc ne doit pas dépasser douze à dix-huit mois, jalons et critères de sortie validés en amont par la gouvernance programme.
L'effort dépend du nombre de rapports actifs, de la complexité des modèles Framework Manager et de la présence ou non de cubes TM1. À titre de repère, un parc de deux cents à cinq cents rapports avec dix à vingt modèles FM se migre typiquement en huit à douze mois avec une cellule de quatre à six personnes en co-delivery nearshore. Pour un parc de mille rapports et plus, ou si TM1 fait partie du périmètre, comptez un programme pluriannuel structuré en vagues, avec une équipe pouvant monter à dix personnes pendant les phases de pic.
La migration progressive par périmètre fonctionnel est la meilleure approche. Les deux plateformes coexistent sans difficulté grâce à la séparation des sources de données. Chaque périmètre (finance, RH, opérations, ventes) suit son propre cycle : modélisation tabulaire, migration des rapports, double run de deux à quatre semaines, validation métier, décommissionnement Cognos. Cette approche étale le risque, permet la montée en compétences et facilite la conduite du changement utilisateur. Attention à ne pas étirer la coexistence au-delà de douze à dix-huit mois — la double maintenance devient alors plus coûteuse que la migration elle-même.
Les modèles Framework Manager (FM) sont conceptuellement proches des modèles tabulaires Power BI mais les implémentations diffèrent. Un modèle FM se traduit par un dataset Power BI partagé ou un modèle tabulaire SSAS, avec ses tables, relations, hiérarchies et mesures. Les calculs en expression Cognos sont réécrits en DAX, en s'appuyant sur les patterns publiés (DAX Patterns, time intelligence native). Les packages partagés deviennent des datasets partagés référencés par plusieurs rapports. Pour les modèles DMR (Dimensionally Modelled Relational), la conversion est directe ; pour les modèles relationnels purs, une refonte plus profonde est nécessaire.
TM1 est un moteur multidimensionnel à part, et la migration vers Power BI nécessite une refonte conceptuelle. Trois options selon le cas : reconstruction du cube en modèle tabulaire Power BI Premium si la volumétrie le permet et que les calculs TM1 peuvent être réécrits en DAX, conservation de TM1 comme moteur de calcul connecté à Power BI via un connecteur OData ou une couche d'API, ou bascule vers Microsoft Analysis Services Multidimensional pour les cas où le pattern multidimensionnel doit absolument être préservé. Le choix dépend de la complexité des règles TM1, de la volumétrie et de l'horizon stratégique de l'organisation.
La sécurité Cognos repose sur la directory (LDAP, Active Directory) et des filtres définis dans les packages Framework Manager. En Power BI, la sécurité ligne par ligne (RLS) est définie par des rôles et des filtres DAX, dynamiques (USERPRINCIPALNAME) ou statiques. La migration suit trois étapes : extraction du modèle de sécurité Cognos (utilisateurs, rôles, filtres), conception du modèle RLS Power BI équivalent, validation par tests avec comptes utilisateurs représentatifs avant mise en production. Aucun rapport sensible n'est mis en production sans accord explicite du référent sécurité métier sur les tests RLS.
Cinq gains typiques constatés sur les programmes que nous accompagnons. Premièrement, les coûts d'infrastructure et de licence Cognos sont libérés (serveurs, licences IBM, support). Deuxièmement, l'expérience utilisateur progresse fortement (intégration Excel, Teams, mobile, accessibilité). Troisièmement, le délai entre une demande métier et la mise à disposition d'un nouveau rapport diminue grâce au self-service Power BI. Quatrièmement, la gouvernance data se centralise autour des datasets partagés. Enfin, la plateforme bénéficie des évolutions IA Microsoft (Copilot dans Power BI, narratives automatiques) sans coût additionnel pour les capacités Premium. Si la souveraineté ou le coût licences Premium devient bloquant pour 10 000+ utilisateurs, regarder l'audit comparatif Power BI vs Apache Superset.
Cognos n'est pas abandonné — IBM continue les releases (Cognos Analytics 12.x en 2024) — mais le produit perd du terrain rapidement. Microsoft Power BI domine le marché de la BI en nombre de licences et en visibilité analyste (Leader Gartner Magic Quadrant depuis 2017). Le vivier de compétences Cognos se réduit, les ressources de formation vieillissent, et l'intégration aux fonctionnalités IA modernes (Copilot, Q&A en langage naturel, embedded analytics) accuse plusieurs années de retard sur Power BI et Tableau. Pour un nouvel investissement BI, presque personne ne choisit Cognos en 2026. Pour un parc Cognos existant, la question n'est plus « faut-il migrer », mais « quand ». Une migration complète Cognos vers Power BI dure typiquement 6 à 18 mois selon le volume. Voir le parcours Cognos vers Power BI et la méthodologie ATLAS appliquée au reporting legacy.
Cela dépend de la taille du parc de rapports, de la complexité des packages et FM models Cognos, et du niveau de personnalisation utilisateur. En ordre de grandeur : 100 à 200 rapports avec 5-10 packages FM migrent en 6 à 9 mois pour 250 à 600 k€. Un parc entreprise de 1 000+ rapports avec packages complexes, paginated reports et cas d'usage embarqués dure 12 à 24 mois et coûte 1,5 à 4 M€. Le facteur qui pèse le plus n'est pas la réécriture des rapports — c'est la reconstruction du modèle sémantique en tabulaire Power BI, la formation utilisateurs finaux et la gestion du run parallèle pendant la transition. Nous démarrons par un POC de 4-8 semaines sur 10-20 rapports représentatifs pour mesurer la productivité réelle avant d'engager le programme complet. La méthodologie ATLAS s'applique au reporting legacy avec parité auditée par rapport. Voir le parcours Cognos vers Power BI.
Nous cadrons la trajectoire, le chiffrage et les livrables en un premier échange de trente minutes. Un POC court peut être proposé avant engagement du programme complet.
Lancer ce parcours →