Pour remplacer un parc BusinessObjects, Power BI convient mieux lorsque les rapports sont normalisés, que Microsoft 365 est déjà largement utilisé et que la diffusion concerne beaucoup de lecteurs. Qlik Sense devient plus cohérent lorsque l’exploration libre de sources nombreuses et hétérogènes constitue le besoin métier principal.
- Un univers BusinessObjects ne se convertit pas automatiquement en modèle Power BI ni en application Qlik Sense, car les contextes, objets, variables et règles de sécurité doivent être repris puis testés.
- Power BI présente un coût catalogue par utilisateur plus lisible, mais les droits de partage et les besoins de capacité doivent être chiffrés avant tout arbitrage.
- Qlik Sense apporte un moteur associatif utile lorsque les utilisateurs doivent remonter librement dans des jeux de données complexes, sans parcours de filtres fixé d’avance.
- La migration ne doit porter que sur les rapports réellement utilisés, après analyse des logs d’audit et validation auprès des directions métier.
Ce contenu s’adresse aux responsables BI qui doivent remplacer des rapports Web Intelligence, des univers et des tableaux de bord BusinessObjects. Il traite du choix de cible et de la reprise fonctionnelle ; la négociation contractuelle, la protection des données personnelles et l’architecture d’hébergement relèvent respectivement de vos achats, de votre DPO et de vos équipes infrastructure.
Quel outil choisir pour reprendre les rapports BusinessObjects réellement utilisés ?
Le choix ne commence pas par une démonstration de Power BI ou de Qlik Sense. Il commence par le parc BusinessObjects tel qu’il est réellement consommé. Un inventaire issu du CMS, des dossiers publics et des univers donne un volume technique. Il ne donne pas un volume métier. Un rapport Web Intelligence peut exister dans le référentiel, être planifié chaque nuit et n’être ouvert par personne.
La première extraction doit couvrir au moins douze mois glissants de consultation. Les logs d’audit permettent de distinguer les rapports ouverts par des utilisateurs, les documents planifiés, les échecs de rafraîchissement et les publications automatiques. Cette distinction évite de migrer une production historique uniquement parce qu’un objet est encore présent dans un dossier BusinessObjects 4.3.
Les rapports qui restent après ce tri doivent être classés par finalité. Le reporting financier mensuel, les états de contrôle, les tableaux de bord commerciaux et les analyses ponctuelles n’appellent pas la même cible. Power BI est souvent retenu pour la diffusion de tableaux de bord standardisés, avec un modèle sémantique central et des mesures partagées. Qlik Sense mérite d’être comparé lorsque l’utilisateur doit partir d’un indicateur, sélectionner une valeur, puis examiner immédiatement les valeurs associées et non associées dans plusieurs domaines.
La logique d’un univers BusinessObjects ne correspond pas à celle d’un modèle cible
Un univers BusinessObjects rassemble des classes, des objets, des conditions, des jointures et parfois des contextes de requête. Une règle de gestion peut se trouver dans une expression SQL d’objet, dans une condition obligatoire, dans une variable Web Intelligence ou dans une requête fusionnant plusieurs fournisseurs de données. Aucun de ces éléments ne doit être supposé visible dans le seul rendu du rapport.
Dans Power BI, cette logique se répartit habituellement entre les transformations Power Query, le modèle tabulaire, les relations, les mesures DAX et les règles de sécurité au niveau des lignes. Dans Qlik Sense, la reprise passe notamment par le script de chargement, les associations entre champs, les expressions de mesures et la structure des applications. La question n’est donc pas de savoir quel outil « importe » un univers. Les deux demandent une reconstruction explicite.
Un filtre de statut client posé au niveau d’une condition d’objet dans l’univers ne se voit pas nécessairement dans le rapport Web Intelligence. S’il est oublié lors de la reprise, le chiffre d’affaires de la cible peut être supérieur à celui de l’ancien rapport. Cet écart n’indique pas automatiquement une erreur de calcul. Il signale souvent une règle qui n’avait jamais été documentée.
Le tableau de décision doit partir de la nature des usages
| Usage issu de BusinessObjects | Éléments à reprendre | Power BI est cohérent si | Qlik Sense est cohérent si |
|---|---|---|---|
| Tableau de bord mensuel diffusé à grande échelle | Indicateurs, droits, calendrier de rafraîchissement, export | Les mesures sont stables et la diffusion s’inscrit dans Microsoft 365 | Les lecteurs doivent analyser librement les associations entre domaines |
| Rapport Web Intelligence à invites | Variables, filtres, listes de valeurs, mises en forme | Les invites peuvent devenir des segments et paramètres documentés | Les sélections doivent révéler immédiatement les valeurs exclues ou associées |
| Rapport de contrôle détaillé | Colonnes, ruptures, règles de calcul, export | Un rapport paginé ou une table détaillée répond au besoin validé | Le contrôle demande des parcours d’exploration successifs dans plusieurs sources |
| Analyse ad hoc construite par les métiers | Autonomie, vocabulaire métier, gouvernance des jeux de données | Le modèle sémantique est cadré et les utilisateurs acceptent ses relations | La valeur provient d’explorations non prévues à l’avance |
Ce tableau ne remplace pas la recette. Il fixe un premier périmètre de décision. Une visualisation des données réussie dans une maquette n’apporte aucune preuve sur la reprise des règles enfouies dans un univers. Vous devez donc choisir l’outil après avoir identifié les documents actifs, leurs sources et leurs calculs, non avant.
Pourquoi le modèle tabulaire de Power BI change la reprise des univers BusinessObjects
Power BI repose sur un modèle tabulaire. Les données peuvent être importées, transformées dans Power Query, reliées dans un modèle puis exploitées au moyen de mesures. Cette mécanique est très différente d’un univers BusinessObjects, même lorsque les deux outils affichent les mêmes indicateurs. Le travail de migration consiste à décider où placer chaque règle de gestion.
Les transformations de structure doivent être traitées dans Power Query ou dans le flux ETL existant. Les relations entre faits et dimensions doivent être documentées dans le modèle. Les calculs d’indicateurs doivent être portés par des mesures lorsque leur résultat dépend du contexte de filtre. Une colonne calculée utilisée à la place d’une mesure peut produire un résultat correct dans un visuel et faux dans un total. Ce point doit être contrôlé avant toute recette métier.
Le modèle en étoile réduit les ambiguïtés, à condition de le construire
Un parc BusinessObjects contient fréquemment plusieurs univers construits à des époques différentes. Un même client peut être joint à la vente par un identifiant dans un univers commercial, et par un code historique dans un univers de facturation. Le modèle Power BI ne peut pas reprendre ces divergences sans arbitrage. Il faut désigner la dimension de référence, tracer les clés de rapprochement et isoler les exceptions.
Le modèle en étoile apporte un cadre utile pour des tableaux de bord de pilotage. Une table de faits porte les montants, quantités ou mouvements. Des dimensions décrivent la date, le client, le produit ou l’organisation. Cette structure rend les relations plus lisibles lors de la recette. Elle n’élimine pas les écarts. Elle permet de les localiser plus vite, car une mesure, une relation et un filtre peuvent être vérifiés séparément.
Power BI devient un choix solide lorsque les rapports BusinessObjects reposent sur des indicateurs récurrents, des hiérarchies partagées et des populations de lecteurs nombreuses. La diffusion dans Teams, SharePoint ou l’environnement Microsoft 365 peut alors réduire le nombre de canaux à maintenir. Microsoft documente les offres, les droits de partage et les capacités sur sa page de tarification, consultée le 24 mars 2026 : tarification officielle Power BI.
Les coûts de licence doivent être séparés de la charge de reprise
Microsoft a annoncé une évolution des tarifs Power BI en avril 2025. La communication officielle indique un prix catalogue de 14 dollars par utilisateur et par mois pour Power BI Pro et de 24 dollars par utilisateur et par mois pour Premium Per User, hors fiscalité et hors remise négociée. La source doit être revérifiée à chaque arbitrage, car les devis, devises, contrats Microsoft 365 et conditions locales modifient le coût réellement engagé : annonce Microsoft sur l’évolution tarifaire, consultée le 24 mars 2026.
Sur un périmètre de 100 créateurs et lecteurs sous licence Pro, le calcul catalogue est de 100 × 14 × 12, soit 16 800 dollars par an. Ce calcul ne comprend ni l’accompagnement de la migration, ni la capacité Fabric, ni les comptes déjà couverts par un abonnement Microsoft 365 incluant Power BI Pro. Il ne préjuge donc pas du budget complet.
Le remplacement de Power BI Premium par des capacités Fabric impose aussi un contrôle précis des besoins de diffusion. Microsoft décrit cette évolution dans sa communication officielle sur les licences Premium, consultée le 24 mars 2026 : évolution de Power BI Premium vers Fabric. Une capacité ne doit pas être retenue parce qu’elle paraît avantageuse sur une simulation isolée. Elle doit correspondre à une fréquence de rafraîchissement, à un volume d’usage et à un nombre de lecteurs établis.
Power BI ne convient pas lorsque la décision vise à reproduire sans examen tous les rapports existants. Sur un parc inférieur à cent documents, dont la moitié n’est plus consultée, la reconstruction d’un noyau d’indicateurs coûte souvent moins de charge que la reprise des anciennes variantes. L’arbitrage s’inverse lorsque plusieurs centaines de rapports actifs reposent sur des règles métier encore inconnues.
Le point de contrôle suivant porte alors sur les usages exploratoires. C’est là que Qlik Sense se différencie réellement, non par la quantité de graphiques disponibles, mais par sa manière d’exposer les associations entre les données.
Dans quels cas le moteur associatif de Qlik Sense justifie une cible différente ?
Qlik Sense ne demande pas aux utilisateurs de suivre uniquement un chemin d’analyse préparé dans un tableau de bord. Son moteur associatif met en évidence les données sélectionnées, les données associées et les valeurs exclues. Cette logique change la manière dont un utilisateur explore un domaine complexe. Elle peut être particulièrement utile après BusinessObjects lorsque les documents existants ont multiplié les invites, les variantes de requêtes et les exports pour répondre à des questions non anticipées.
Un univers BusinessObjects offre déjà une couche sémantique et des listes d’objets métier. Pourtant, l’exploration reste souvent organisée par requête : l’utilisateur choisit des objets, fixe des conditions et lance un résultat. Dans Qlik Sense, les sélections successives font partie de l’analyse. L’utilisateur peut constater qu’un segment de clientèle n’est associé à aucun produit sur une période, puis remonter vers les régions, les canaux ou les responsables concernés.
La liberté d’exploration exige une gouvernance plus ferme
Le moteur associatif ne dispense pas de modélisation. Il déplace une partie de la vigilance vers les scripts de chargement, les noms de champs, les clés et les tables. Deux champs portant le même nom peuvent s’associer alors qu’ils ne décrivent pas le même objet métier. À l’inverse, deux champs décrivant la même notion mais nommés différemment ne seront pas associés sans traitement explicite.
Une migration vers Qlik Sense doit donc établir un dictionnaire de données avant de laisser les utilisateurs explorer. Les équivalents de la classe et de l’objet BusinessObjects doivent être identifiés. Les champs techniques doivent être séparés des champs de pilotage. Les mesures doivent préciser leur grain, leur période de comparaison et les exclusions appliquées. Sans cette discipline, la liberté offerte par l’application produit plusieurs interprétations d’un même indicateur.
Qlik Sense est adapté lorsque l’organisation possède des sources très variées et que les équipes métier ont une pratique confirmée de l’analyse décisionnelle. L’outil peut agréger des fichiers, des bases relationnelles et des applications, mais le connecteur disponible ne prouve pas que la donnée est prête à être comparée. L’ETL, les règles de dédoublonnage et les contrôles de qualité restent à traiter dans le flux de reprise.
Le coût Qlik doit être confirmé dans une proposition commerciale datée
Qlik publie ses offres et ses modalités d’accès sur sa page officielle, consultée le 24 mars 2026 : tarification Qlik. Les prix affichés peuvent varier selon le pays, le type d’utilisateur, le mode de déploiement et les options retenues. La tarification Qlik Sense Enterprise en environnement sur site relève habituellement d’un devis ; elle ne doit donc jamais être remplacée dans votre dossier par une estimation trouvée sur un comparateur.
Les repères de prix catalogue communiqués pour Qlik Sense Business et les profils Enterprise doivent être vérifiés au moment de l’achat. Pour une comparaison cohérente avec Power BI, vous devez mettre en regard le coût annuel des créateurs, celui des lecteurs, les capacités de diffusion, les environnements de développement et les options de support. Comparer un lecteur Power BI Pro à un utilisateur Qlik Full User ne produit pas un résultat défendable, car les droits fonctionnels ne sont pas alignés.
Le prix supérieur de Qlik Sense ne suffit pas à écarter l’outil. Il est justifié seulement si l’exploration associative répond à une pratique qui existe déjà et dont la valeur est démontrable. Si les utilisateurs consultent surtout dix indicateurs mensuels et exportent un état de contrôle, un modèle Power BI bien gouverné répond plus directement au besoin. Si les directions opérationnelles doivent investiguer chaque semaine des écarts entre domaines multiples, l’arbitrage peut basculer vers Qlik.
La capacité à explorer ne garantit toutefois pas que les chiffres soient recevables. La reprise d’un parc BusinessObjects exige ensuite un protocole de réconciliation, quel que soit l’outil choisi.
Comment chiffrer la migration BusinessObjects vers Power BI ou Qlik Sense sans masquer la recette ?
La charge de migration ne se calcule pas en divisant le nombre de rapports BusinessObjects par un ratio unique. Un document Web Intelligence de trois tableaux, alimenté par une requête unique et sans variable, n’a pas le même coût qu’un rapport comportant plusieurs fournisseurs de données, des fusions, des sections, des alertes et des macros d’export. Les univers, les droits et les workflows de diffusion doivent être chiffrés séparément.
Un inventaire exploitable attribue à chaque document une complexité et une décision : abandon, reconstruction, reprise ou maintien temporaire. La reconstruction est souvent préférable lorsque le rapport est peu consulté mais chargé d’anciennes mises en forme. La reprise peut être préférable lorsque l’état est réglementaire, encore utilisé et fondé sur des règles de gestion difficiles à reconstituer.
Un exemple de charge doit afficher ses hypothèses
Le calcul suivant concerne un parc hypothétique de 240 rapports Web Intelligence actifs après élimination des documents non consultés. Il ne s’agit pas d’un tarif de marché ni d’un engagement de délai. Les ratios servent à exposer les postes de travail nécessaires à la reprise fonctionnelle.
- 144 rapports sont classés comme standard, avec une requête, quelques variables et une mise en page limitée ; l’hypothèse de reprise est de 2 heures par rapport.
- 72 rapports sont classés comme intermédiaires, avec plusieurs blocs, des filtres conditionnels ou des ruptures ; l’hypothèse est de 5 heures par rapport.
- 24 rapports sont classés comme complexes, avec plusieurs fournisseurs, des variables imbriquées ou une logique d’export ; l’hypothèse est de 10 heures par rapport.
- Le calcul exclut la recette métier, la reprise des droits, la formation, la correction des sources et l’automatisation des rapports planifiés.
La reprise des rapports représente donc 144 × 2, plus 72 × 5, plus 24 × 10. Le résultat est de 888 heures pour les seuls documents. Cette valeur doit être augmentée du travail de modèle, de reprise des règles de sécurité, de validation des données et de gestion du changement. Si 20 % des rapports complexes révèlent des calculs enfouis dans des variables Web Intelligence, la charge initiale ne suffit plus.
Le ratio de 2 à 10 heures est une hypothèse de cadrage, pas une donnée universelle. Il doit être remplacé par vos propres relevés après lecture d’un échantillon de documents. Un échantillon utile couvre les univers les plus sollicités, les états financiers, les documents à forte diffusion et les rapports comportant le plus d’objets calculés.
La reprise des planifications est un lot distinct
BusinessObjects peut planifier des documents selon un calendrier, un événement, une destination et une liste de destinataires. La cible ne reproduit pas nécessairement cette mécanique avec les mêmes paramètres. Dans Power BI, la diffusion peut s’appuyer sur le service, les abonnements, les applications, les rapports paginés ou des mécanismes complémentaires. Dans Qlik Sense, elle dépend de l’offre retenue et de la conception des applications.
L’automatisation des rapports doit donc être recensée avec le même sérieux que les visuels. Un fichier envoyé chaque matin n’est pas seulement un tableau. Il peut déclencher un contrôle opérationnel, alimenter une réunion ou servir de pièce de rapprochement. La suppression d’une planification doit être validée par son propriétaire métier, pas déduite de son ancienneté.
La source BusinessObjects importe également. Un rapport alimenté par SAP BW, Oracle ou SQL Server demande une vérification des requêtes, des agrégats et des horaires de disponibilité. Une cible qui rafraîchit les données avant la fin du chargement ETL peut afficher une situation provisoire tout en paraissant correcte visuellement. La migration doit documenter les dépendances de bout en bout.
La charge complète n’est défendable qu’après ce découpage. Un devis qui annonce seulement un nombre de jours pour « migrer les tableaux de bord » laisse hors champ les postes qui provoquent la plupart des retards : règles métier, sécurité, recette et diffusion.
Comment prouver que les nouveaux tableaux de bord restent acceptables après la bascule ?
Ni Power BI ni Qlik Sense ne produiront spontanément des chiffres identiques à ceux de BusinessObjects. Les différences de filtre, de fuseau horaire, d’arrondi, de jointure, de calendrier ou de date de rafraîchissement créent des écarts. Le travail de recette consiste à les mesurer, à les expliquer et à faire accepter une tolérance adaptée à chaque indicateur.
Le double run reste la méthode la plus solide pour les rapports de pilotage. Pendant une période définie, l’ancien document BusinessObjects et le nouveau tableau de bord sont alimentés selon un calendrier comparable. Les résultats sont rapprochés au même instant et au même niveau de détail. Comparer un rapport BusinessObjects rafraîchi à 6 heures avec un tableau Power BI chargé à 10 heures ne prouve rien sur le calcul.
Un protocole de réconciliation doit isoler les causes d’écart
La réconciliation commence par les données sources. Le nombre de lignes, les clés distinctes, les périodes, les statuts et les exclusions doivent être comparés. Vient ensuite le niveau de calcul. Une mesure de chiffre d’affaires net doit préciser si les avoirs, annulations, commandes internes ou factures provisoires sont inclus. Enfin, le rendu agrégé doit être confronté au détail.
Une tolérance peut être exprimée en montant, en pourcentage ou en nombre de lignes selon la nature de l’indicateur. Pour un total financier de clôture, une différence de quelques centimes peut être inacceptable si elle résulte d’un arrondi différent répété sur des milliers de lignes. Pour un indicateur de tendance opérationnelle, une tolérance relative peut être admise si les données arrivent à des horaires distincts. Cette règle doit être décidée avec le métier avant la recette, non lors du refus de bascule.
| Contrôle de recette | Comparaison attendue | Cause fréquente d’écart | Décision à tracer |
|---|---|---|---|
| Périmètre de données | Nombre de lignes et clés distinctes | Filtre d’objet BusinessObjects non repris | Corriger le modèle ou acter l’exclusion |
| Indicateur agrégé | Total par période et organisation | Règle d’arrondi ou de date différente | Documenter la méthode de calcul |
| Niveau détaillé | Échantillon de transactions | Jointure dupliquant ou excluant des lignes | Corriger la relation ou le script ETL |
| Sécurité utilisateur | Population visible par rôle | Règle de sécurité non transposée | Valider les droits avant diffusion |
Les droits doivent être testés avec des comptes représentatifs, sans utiliser un compte administrateur comme preuve de conformité. Dans BusinessObjects, la sécurité peut résulter des dossiers, groupes, niveaux d’accès et restrictions d’univers. Dans Power BI, elle peut être portée par les espaces de travail, les applications et la sécurité au niveau des lignes. Dans Qlik Sense, elle dépend des règles d’accès, des applications et du mode de diffusion retenu.
La bascule doit reposer sur des critères signés
Un rapport peut être techniquement publié alors que son propriétaire métier refuse encore le nouvel indicateur. Cette situation doit être prévue. Les critères de bascule doivent lister les rapports validés, les écarts acceptés, les écarts corrigés, les restrictions de sécurité contrôlées et les planifications actives. Un écart non expliqué ne doit pas être masqué par une mise en forme identique à l’ancien rapport.
Les fonctions de visualisation des données ne sont pas le bon lieu pour dissimuler une différence de périmètre. Un total affiché avec moins de décimales peut donner l’illusion d’une concordance alors que le calcul détaillé diverge. La preuve reste le rapprochement par segment, période, organisation et transaction lorsque le métier le demande.
Les pages officielles Microsoft et Qlik décrivent les offres de leurs plateformes, mais elles ne décrivent pas les règles spécifiques contenues dans vos univers BusinessObjects. Les sources éditeurs consultées le 24 mars 2026 sont la grille Power BI de Microsoft et la grille Qlik. Aucun environnement client n’a été ouvert pour ce contenu ; la méthode proposée s’appuie donc sur la documentation publique et sur un protocole de recette reproductible.
Avant toute sélection définitive, sortez les logs d’audit sur douze mois, classez chaque rapport actif, puis faites reconstruire un échantillon représentatif dans les deux cibles. C’est la seule comparaison qui relie réellement le coût des licences, la charge de migration et la qualité des chiffres attendus.
Power BI peut-il importer directement les univers BusinessObjects ?
Non. Les objets, jointures, contextes, conditions et règles de sécurité d’un univers doivent être analysés puis reconstruits dans Power Query, le modèle tabulaire, les relations et les mesures Power BI. Une reprise sans lecture de l’univers expose à des écarts de périmètre.
Qlik Sense remplace-t-il tous les rapports Web Intelligence ?
Qlik Sense peut reprendre des usages de reporting et d’exploration, mais chaque rapport doit être classé. Les états très formatés, les éditions planifiées et certains exports de contrôle demandent une conception spécifique. Le moteur associatif ne remplace pas automatiquement la logique d’un document Web Intelligence.
Quel coût comparer entre Power BI et Qlik Sense ?
Comparez le coût annuel des créateurs, des lecteurs, des capacités de diffusion, du support et des options nécessaires. Les tarifs catalogue doivent être relevés à la date de l’arbitrage, hors remise négociée, puis rapprochés des droits réels de chaque profil utilisateur.
Faut-il viser des chiffres identiques entre BusinessObjects et la nouvelle plateforme ?
Non. L’objectif est de mesurer et d’expliquer les écarts. Les filtres, arrondis, dates de rafraîchissement, jointures et règles de gestion doivent être comparés dans un double run, avec une tolérance validée par les propriétaires métier.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
