Modernisation d'une plateforme Pentaho vers Power BI Premium : conversion des transformations Pentaho Data Integration (Kettle) vers Azure Data Factory ou Power Query, refonte des rapports Pentaho Report Designer et Community Dashboard Editor en Power BI, refonte des cubes Mondrian en modèles tabulaires.
Pentaho a été l'une des suites BI open source de référence dans les années 2005 à 2018, adoptée par des entreprises de taille moyenne et grande qui cherchaient une alternative aux licences IBM Cognos, SAP BO ou Oracle BI. La suite couvre un ETL puissant (Pentaho Data Integration, alias Kettle), un serveur BI (Pentaho BI Server, alias Pentaho User Console), un studio de rapports (Report Designer), un éditeur de dashboards communautaire (CDE) et un moteur OLAP (Mondrian). Acquis par Hitachi en 2015 puis intégré à Hitachi Vantara, Pentaho a connu plusieurs ralentissements de feuille de route. La distribution Community Edition a été progressivement délaissée au profit de l'Enterprise Edition payante, et beaucoup d'entreprises se retrouvent aujourd'hui face à un choix : payer des licences Hitachi Vantara, maintenir une version Community vieillissante, ou migrer.
Pour les organisations déjà engagées dans Microsoft 365 et Azure, Power BI Premium offre une cible naturelle pour Pentaho. Les transformations Kettle trouvent leur équivalent dans Azure Data Factory (orchestration cloud-native) ou dans Power Query M (transformations légères côté dataset). Les schémas Mondrian se traduisent en modèles tabulaires Power BI, plus performants grâce au moteur VertiPaq. Les rapports Report Designer et dashboards CDE sont reconstruits en visuels Power BI, avec un saut d'expérience utilisateur considérable (interactivité, mobile, intégration Office). Notre expertise IA, Data et Automatisation couvre ces migrations de bout en bout, encadrées par la méthodologie ATLAS.
Quatre signaux convergent vers la décision de migrer. D'abord, le renouvellement des licences Hitachi Vantara approche et son coût devient difficile à justifier face à un stack Microsoft déjà payé. Ensuite, l'équipe Pentaho interne se réduit — départs des experts Kettle, recrutement quasi impossible. Puis, les utilisateurs métier réclament des fonctionnalités modernes absentes ou en retard sur Pentaho (mobile fluide, self-service, IA générative). Enfin, la stratégie data globale bascule vers Microsoft Fabric, Azure Synapse ou Databricks, et la couche de visualisation et d'ETL doit suivre. Quand trois de ces quatre signaux sont présents, la migration s'impose comme priorité IT.
Pentaho BI Server, Pentaho Data Integration (Kettle), Report Designer, CDE, Mondrian
Power BI Premium, modèles tabulaires, Azure Data Factory, Power Query M, Microsoft Fabric (optionnel)
Choix par défaut pour les organisations Microsoft. ETL orchestré dans Azure Data Factory pour les pipelines complexes, Power Query pour les transformations légères, Power BI Premium pour la visualisation. Recommandation principale pour la majorité des migrations Pentaho.
Projet plus ambitieux incluant un lakehouse moderne, OneLake, notebooks Spark et Direct Lake. Pertinent quand la migration Pentaho s'inscrit dans une refonte data complète, avec ingestion temps réel et data science.
L'organisation conserve un ETL d'entreprise dédié, distinct de la plateforme BI. Pertinent quand les pipelines Kettle sont très volumineux ou intègrent des sources non-Microsoft où un ETL spécialisé apporte de la valeur.
Cas spécifiques où la souveraineté ou la stack open source moderne sont prioritaires. Effort de migration important car la sémantique diffère davantage de Pentaho que la cible Microsoft.
Un programme de migration Pentaho vers Power BI se structure généralement sur six à dix-huit mois selon la volumétrie ETL et le nombre de rapports. Pour un parc de cinquante à cent cinquante transformations Kettle et deux cents à quatre cents rapports, comptez huit à douze mois avec une cellule de cinq à sept personnes : un architecte data Power BI / Azure, un data engineer senior Azure Data Factory, deux développeurs Power BI / DAX, un développeur ETL pour la traduction Kettle, un référent métier détaché à 30 % et un chef de projet. Pour des parcs très large incluant Mondrian, comptez un programme de douze à vingt-quatre mois en vagues successives.
Sous-estimer l'effort de traduction des transformations Kettle. Une transformation Pentaho complexe utilise des étapes (steps) très spécifiques (ScriptValueMod, Modified JavaScript, JSON Input, JMS Producer) qui n'ont pas tous d'équivalent direct dans Azure Data Factory.
Cartographie systématique des steps Kettle utilisés sur tout le parc, avec inventaire de leur fréquence. Chaque step rare ou complexe fait l'objet d'une étude de faisabilité dédiée (équivalent ADF natif, Azure Function custom, ou refactorisation logique). Les choix sont consignés dans le registre des discordances, pour validation et documentation. Voir la méthodologie ATLAS.
Reproduire à l'identique les rapports Report Designer et CDE. Ces outils ont une logique d'affichage très différente de Power BI, et copier le rendu pixel-perfect produit des visuels Power BI lourds, non-interactifs, qui ne tirent pas parti de la plateforme.
Refonte ciblée : pour chaque rapport critique, un atelier de 30 minutes avec le métier permet de redéfinir l'objectif (qu'est-ce que l'utilisateur cherche réellement à voir) avant de reconstruire en Power BI. Les rapports purement opérationnels (export PDF mensuel) sont reproduits en Paginated Reports. Les dashboards CDE deviennent des rapports Power BI interactifs avec slicers et drill-through.
Migrer les schémas Mondrian en MDX vers DAX sans repenser le modèle. MDX et DAX répondent à des paradigmes différents (multidimensionnel vs tabulaire), et une traduction littérale produit du DAX inefficient.
Re-conception tabulaire : chaque schéma Mondrian est analysé pour identifier les hiérarchies, les calculs et la granularité, puis reconstruit en modèle tabulaire Power BI. Les mesures DAX s'appuient sur les patterns publiés (DAX Patterns, time intelligence). Les optimisations Mondrian historiques (caches, agrégations matérialisées) sont remplacées par les optimisations natives Power BI (agrégations automatiques, mode Direct Lake).
Ignorer les plannings et déclencheurs Pentaho. Le parc tourne grâce à des jobs schedulés (Quartz, cron-like) qui orchestrent Kettle. Les oublier, c'est perdre des chaînes de production data critiques le jour de la bascule.
Inventaire des plannings dès la phase de capture : nombre de jobs, fréquences, dépendances, criticité. Pour chaque planning, un équivalent Azure est conçu (déclencheur ADF, Logic App, Azure Function planifiée). Les chaînes critiques sont migrées en double run pendant deux à quatre semaines pour valider la parité avant décommissionnement Pentaho.
Laisser Pentaho et Power BI coexister sans plan de sortie. La double maintenance (deux ETL, deux moteurs de rapport, deux logiques de sécurité) consomme rapidement plus que la migration elle-même.
Plan de bascule daté par périmètre fonctionnel. Chaque périmètre suit un cycle court : migration sur deux à trois mois, double run de deux à quatre semaines, décommissionnement Pentaho sous trois mois. La coexistence globale ne doit pas dépasser douze à dix-huit mois, jalons et critères de sortie validés en gouvernance programme.
Migration des rapports décisionnels d'une plateforme Pentaho vieillissante vers Power BI. Enrichissement du modèle de données, industrialisation des rafraîchissements, gouvernance des accès, intégration dans l'écosystème Microsoft existant.
L'effort dépend du nombre de transformations Kettle, de la complexité des rapports et de la présence ou non de schémas Mondrian. À titre de repère, un parc de cinquante à cent cinquante transformations et deux cents à quatre cents rapports se migre typiquement en huit à douze mois avec une cellule de cinq à sept personnes en co-delivery nearshore. Pour des parcs très importants ou intégrant Mondrian, un programme pluriannuel structuré en vagues est nécessaire.
Trois options selon le pattern. Premièrement, les transformations simples (extraction, jointures, agrégations) deviennent des pipelines Azure Data Factory ou des étapes Power Query M. Deuxièmement, les transformations complexes utilisant du JavaScript Modified ou des steps custom Kettle sont réécrites en Azure Functions appelées depuis ADF. Troisièmement, les transformations purement orchestrales (jobs Pentaho qui chaînent d'autres jobs) deviennent des pipelines ADF avec dépendances explicites. Chaque pattern de step Kettle utilisé fait l'objet d'une cartographie systématique au début du programme.
Mondrian est un moteur OLAP multidimensionnel basé sur des schémas XML et des requêtes MDX. Power BI utilise un moteur tabulaire avec DAX. Les deux paradigmes diffèrent, et une re-conception est nécessaire. En pratique, chaque schéma Mondrian est analysé pour identifier ses hiérarchies, ses mesures et ses calculs, puis reconstruit en modèle tabulaire Power BI Premium. Les calculs MDX sont réécrits en DAX en s'appuyant sur les patterns publiés. Pour les cas où le pattern multidimensionnel doit absolument être préservé, Microsoft Analysis Services Multidimensional reste une option mais elle est de moins en moins utilisée.
Pentaho s'appuie sur Quartz Scheduler ou des cron jobs externes pour déclencher les transformations Kettle. La migration vers Azure suit trois étapes. D'abord, l'inventaire complet des plannings est figé en début de programme (fréquence, criticité, dépendances). Ensuite, chaque planning est traduit en Azure Data Factory trigger, Logic App, ou Azure Function planifiée selon la complexité. Enfin, les chaînes critiques sont basculées en double run pour valider que les sorties sont identiques pendant deux à quatre semaines avant le décommissionnement Pentaho.
Pentaho gère les autorisations via des ACL au niveau dossiers et rapports, plus des contraintes Mondrian côté cubes. Power BI utilise des permissions au niveau workspace et dataset, plus la sécurité ligne par ligne (RLS) via des rôles et filtres DAX. La migration suit trois étapes : extraction du modèle de sécurité Pentaho (utilisateurs, groupes, ACL, contraintes Mondrian), conception du modèle équivalent Power BI (permissions workspace, RLS dynamique via USERPRINCIPALNAME, sécurité Object Level si nécessaire), validation par tests avec comptes utilisateurs représentatifs avant chaque mise en production.
Cinq gains typiques. Premièrement, les coûts de licence Hitachi Vantara et d'infrastructure Pentaho sont libérés. Deuxièmement, l'expérience utilisateur progresse fortement (mobile, intégration Excel, Teams, accessibilité native). Troisièmement, le délai entre une demande métier et la livraison d'un rapport diminue grâce au self-service Power BI et au modèle tabulaire central. Quatrièmement, la gouvernance data se consolide autour des datasets partagés et de Microsoft Purview. Enfin, la plateforme bénéficie sans coût additionnel des évolutions IA Microsoft (Copilot dans Power BI, narratives, Q&A en langage naturel).
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 →