Un rapport Webi ne se transpose pas automatiquement en rapport paginé Power BI. Les tableaux peuvent être repris, mais les contextes d’univers, les ruptures, les variables de rapport, certains formats conditionnels et la navigation utilisateur doivent être redéfinis. La perte porte moins sur les données brutes que sur les règles de restitution accumulées.
- Un rapport Webi combine souvent requête, calcul, filtre et présentation dans un même document, tandis qu’un rapport paginé sépare plus nettement jeu de données et mise en page.
- Le formatage au pixel près peut être recréé, mais les ruptures, sections, tableaux croisés et variables Webi exigent une analyse objet par objet.
- Les univers BusinessObjects ne deviennent pas un modèle sémantique Power BI par conversion directe, ce qui expose les règles de gestion invisibles à une perte de données fonctionnelle.
- La recette doit comparer des populations, des agrégats, des exceptions et des exports PDF, sans promettre une identité mécanique entre l’ancien et le nouveau rendu.
Ce contenu concerne la migration d’un parc SAP BusinessObjects 4.2 ou 4.3 vers des rapports paginés Power BI créés dans Power BI Report Builder. Il ne traite ni le remplacement global d’un entrepôt de données, ni les clauses contractuelles de licence, qui doivent être relues avec les profils compétents de votre organisation.
Pourquoi un rapport Webi ne devient pas un rapport paginé Power BI par simple reprise
Le premier écart concerne l’objet même du document. Un rapport Webi rassemble une ou plusieurs requêtes, des blocs, des variables, des filtres de rapport, des sections, des ruptures et des règles de mise en forme. Le rapport paginé Power BI s’appuie sur un jeu de données, généralement interrogé par DAX, SQL ou une procédure stockée, puis restitue ce résultat dans une définition RDL.
Cette séparation paraît saine sur le papier. Elle devient coûteuse lorsque les règles métier se sont accumulées dans le document Webi plutôt que dans l’univers ou dans le flux ETL. Une variable Webi peut par exemple calculer une marge uniquement pour certaines familles de produits, avec une formule masquée dans les propriétés du rapport. Si cette formule n’est pas inventoriée, le nouveau rapport affichera une valeur cohérente techniquement mais différente pour les utilisateurs.
La documentation Microsoft décrit le rapport paginé comme un document conçu pour être imprimé ou exporté avec une mise en page précise, notamment vers PDF, Excel, Word ou CSV. Le fonctionnement RDL est documenté sur Microsoft Learn, page consultée le 18 juin 2026. Cette orientation explique pourquoi la visualisation paginée convient aux états détaillés, mais ne reprend pas spontanément les usages interactifs d’un rapport Webi.
Les objets Webi qui changent réellement de nature pendant la migration
Un bloc Webi peut contenir un tableau croisé, une rupture sur une dimension, un saut de page après chaque entité et des calculs affichés dans l’en-tête de section. Dans Power BI Report Builder, ces éléments peuvent être reconstruits avec un tablix, des groupes de lignes, des groupes de colonnes et des expressions RDL. Ils ne sont toutefois pas importés depuis le document source.
Les invites constituent un second point de divergence. Dans Webi, une invite peut provenir d’une condition d’univers, d’un filtre ajouté au document ou d’une requête distincte. Dans un rapport paginé, le paramètre doit être défini, alimenté par un jeu de données de valeurs disponibles, puis relié explicitement à la requête principale. La compatibilité fonctionnelle dépend donc du comportement attendu pour les valeurs multiples, les valeurs facultatives et les sélections par défaut.
Les liens de navigation sont également concernés. Un rapport Webi peut appeler un autre document, transmettre une valeur de contexte ou ouvrir un détail selon la valeur d’une cellule. Le RDL peut produire des liens URL et des actions de drill-through, mais ces mécanismes doivent être reconstruits et testés dans le portail de publication retenu. Conserver un lien qui pointe vers une adresse Webi retirée du service ne sert à rien le jour de la bascule.
| Objet du rapport Webi | Équivalent dans le rapport paginé Power BI | Risque de perte pendant la reprise | Vérification à mener avant recette |
|---|---|---|---|
| Bloc avec rupture et saut de page | Tablix, groupe de lignes et page break RDL | Ordre d’impression ou sous-total placé à un niveau différent | Comparer un PDF sur une période courte et une période complète |
| Variable de rapport | Mesure du modèle, requête DAX ou expression RDL | Formule locale oubliée ou évaluée à un autre grain | Tracer la formule, le grain et les valeurs nulles |
| Filtre de rapport Webi | Paramètre, filtre de dataset ou filtre de tablix | Population différente selon l’emplacement du filtre | Contrôler le nombre de lignes avant agrégation |
| Section Webi | Groupe parent RDL | En-tête répété ou total de section non repris | Vérifier les premières et dernières pages de chaque groupe |
Ce tableau a été construit à partir des mécanismes décrits dans la documentation de Power BI Report Builder, consultée le 18 juin 2026, et du comportement connu des documents Web Intelligence. Il ne remplace pas un inventaire du contenu réel de votre parc.
La conversion annoncée en quelques minutes dans certains contenus publiés autour de 2022 confond la récupération d’une requête et la reprise d’un rapport. Réutiliser une requête DAX capturée peut accélérer la construction du dataset. Cela ne reconstruit ni les groupes, ni les en-têtes, ni les règles d’affichage, ni les exceptions de calcul.
La première décision n’est donc pas de choisir l’outil de conversion. Elle consiste à déterminer si le rapport Webi porte encore de la logique de gestion que personne n’a documentée ailleurs.
Quelles données et règles de gestion risquent de disparaître dans Power BI Report Builder
La perte de données n’est pas toujours une ligne absente d’un export. Elle prend souvent la forme d’une population modifiée, d’un total calculé à un autre niveau ou d’un indicateur dont la formule n’est plus appliquée dans les mêmes conditions. Le risque augmente lorsque le rapport Webi interroge un univers ancien, enrichi au fil des années sans documentation de chaque objet.
Un filtre de statut client posé au niveau d’une condition d’objet peut, par exemple, exclure des comptes inactifs sans apparaître dans l’onglet des filtres du rapport Webi. Si le dataset Power BI lit directement une table ou une vue SQL sans reprendre cette condition, l’écart se retrouve dans le chiffre d’affaires, les effectifs clients ou les encours. Le nouveau rendu n’est pas défaillant. Il répond à une règle différente.
Les contextes d’univers ne se traduisent pas en relation Power BI
Dans BusinessObjects, le contexte d’univers évite des jointures ambiguës. Il détermine le chemin de jointure appliqué lorsqu’un utilisateur combine certains objets dans une requête. Dans Power BI, la logique repose sur les relations du modèle sémantique, sur le sens de filtrage et, le cas échéant, sur les mesures DAX.
Les deux mécanismes n’ont pas le même comportement. Une requête Webi qui bascule entre un contexte « ventes » et un contexte « stocks » peut produire des décomptes distincts sans que l’utilisateur voie cette sélection. Dans Power BI, une relation bidirectionnelle ajoutée pour reproduire un résultat peut corriger un état et dérégler les autres. La règle doit être ramenée dans une vue source, un modèle contrôlé ou une mesure explicitement nommée.
Microsoft documente la connexion d’un rapport paginé à un modèle sémantique Power BI ainsi que l’usage des requêtes DAX dans la page consacrée aux sources de données de rapports paginés, consultée le 18 juin 2026. Cette documentation décrit la connexion. Elle ne fournit pas de mécanisme de conversion des contextes d’univers BusinessObjects.
Les variables Webi doivent être classées avant toute réécriture
Les variables de rapport ne présentent pas toutes le même risque. Une concaténation de libellés peut être reprise dans une expression RDL. Un indicateur reposant sur une fonction de type ForEach, ForAll ou sur un contexte de bloc doit être analysé au grain auquel il s’évalue.
Une variable de marge calculée au niveau de la ligne produit souvent un résultat différent d’une marge calculée sur le total de la page. Cette différence n’est pas un détail de formatage. Elle modifie une décision commerciale ou financière si l’indicateur sert à classer les entités, à déclencher une revue ou à calculer une prime.
- Recensez les variables locales, leurs formules, leur type et le bloc Webi qui les utilise avant de concevoir le dataset cible.
- Repérez les objets dont le nom paraît générique, notamment « CA », « marge », « client actif » ou « dernière période », car leur définition peut être enfouie dans l’univers.
- Conservez dans le dossier de recette les valeurs nulles, les divisions par zéro et les libellés substitués, puisque ce sont eux qui révèlent les écarts de logique.
- Faites valider les règles métier par le propriétaire du rapport, pas seulement par l’équipe qui construit le RDL.
Cette liste ne vise pas à rallonger l’inventaire. Elle réduit le risque de considérer une formule d’affichage comme une mesure officielle, puis de la diffuser dans un nouvel environnement comme si elle avait été validée historiquement.
Les objets fusionnés Webi appellent la même prudence. Une fusion peut rapprocher deux dimensions portant des libellés similaires, mais les valeurs non appariées, les doublons et les dimensions incompatibles sont traités selon le comportement du document. Dans un modèle Power BI, cette opération doit devenir une relation maîtrisée, une table de correspondance ou une transformation en amont. La reprise manuelle dans le RDL dégraderait les performances et rendrait la maintenance difficile.
Le chantier doit donc classer chaque règle en trois catégories. Certaines vont dans le modèle sémantique, d’autres restent dans l’expression de rendu, et les dernières doivent être retirées parce qu’elles ne correspondent plus à une règle validée.
Comment le formatage Webi se dégrade lors de la production PDF et Excel
Un rapport paginé est conçu pour maîtriser le format papier, le PDF et les exports. Cette capacité ne signifie pas que le formatage d’un rapport Webi est récupéré sans perte. Les polices, largeurs de colonnes, bordures, niveaux de regroupement et règles de répétition d’en-tête doivent être reproduits dans la matrice RDL.
Le terme « paginé » renvoie au découpage physique du document. Les utilisateurs d’un état de facturation, d’un bordereau de livraison ou d’une liste détaillée attendent une pagination stable. Une colonne déplacée sur une seconde page, un sous-total isolé ou une ligne d’en-tête absente suffit à faire rejeter le document par une équipe opérationnelle.
Les ruptures et les sections Webi ne sont pas des détails esthétiques
Une rupture Webi découpe un bloc lorsqu’une dimension change et peut afficher un sous-total associé. Une section organise le document autour d’une valeur et peut entraîner une nouvelle page. Dans Power BI Report Builder, ces comportements reposent sur des groupes imbriqués, des propriétés de saut de page et des zones d’en-tête.
La difficulté apparaît lorsque la même dimension est utilisée à plusieurs endroits. Un rapport peut présenter une section par société, une rupture par établissement et un total par devise. Si les groupes sont construits dans le mauvais ordre, les totaux deviennent corrects au global mais sont affichés sous une mauvaise entité. Le PDF semble propre. Le rapprochement métier échoue.
La documentation Microsoft sur la mise en page des rapports paginés, consultée le 18 juin 2026, précise que la taille du corps du rapport, les marges et les éléments placés hors largeur imprimable influencent la pagination. Cette contrainte change selon le format retenu, notamment A4 portrait, A4 paysage ou lettre américaine. Le format cible doit être fixé avant la recette graphique.
Les exports Excel modifient la lecture de l’état
Un PDF cherche à préserver le rendu. Excel cherche à restituer des cellules exploitables, avec les compromis propres à l’export RDL. Des cellules fusionnées, des objets placés librement ou une mise en page trop fragmentée créent des colonnes supplémentaires et compliquent les tris. Le document peut être fidèle à l’impression tout en étant inutilisable pour les utilisateurs qui retraitent l’export.
Un rapport Webi est souvent consommé dans les deux formes. Les équipes impriment le PDF mensuel, puis exportent le détail dans Excel pour réaliser des contrôles locaux. Reprendre seulement le support officiel de diffusion ne suffit pas si l’export constitue une étape réelle du processus de clôture.
| Élément de restitution | Comportement attendu dans Webi | Point de contrôle dans le rapport paginé | Défaut observable |
|---|---|---|---|
| En-tête de tableau | Répété à chaque page imprimée | Propriété de répétition du membre statique du tablix | Colonnes non identifiables après la première page |
| Sous-total de rupture | Affiché après chaque groupe | Portée de l’agrégat dans le groupe RDL | Total calculé sur un périmètre trop large |
| Largeur des colonnes | Stable dans le PDF | Largeur du corps, marges et taille de page | Page blanche ou tableau coupé |
| Export Excel | Colonnes réutilisables par les contrôleurs | Réduction des cellules fusionnées et objets flottants | Colonnes vides ajoutées dans le classeur |
Les critères de réception doivent donc prévoir deux contrôles distincts. Le premier compare la pagination et le positionnement PDF sur un échantillon représentatif. Le second ouvre l’export Excel, compte les colonnes créées, vérifie les en-têtes et teste un filtre sur les données détaillées.
Le rapport paginé peut restituer un format très contraint. Il ne dispense pas de définir ce qui relève de l’apparence et ce qui relève d’une information que le lecteur doit conserver dans son export.
Quels écarts de fonctionnalités et de performances faut-il accepter ou corriger
Un rapport Webi est fréquemment utilisé comme un document interactif, même lorsqu’il a été conçu pour être imprimé. Les utilisateurs filtrent, explorent, changent le niveau de détail, exportent ou rafraîchissent à la demande. Le rapport paginé répond mieux à une diffusion structurée, mais ses fonctionnalités ne recouvrent pas l’ensemble de l’expérience Web Intelligence.
Le premier arbitrage concerne la cible réelle. Si le besoin est un état détaillé signé, archivé ou envoyé régulièrement au format PDF, le RDL est cohérent. Si le besoin porte sur une exploration libre de dimensions, une navigation visuelle et une comparaison instantanée de périodes, un rapport Power BI interactif répond souvent mieux au besoin que le rapport paginé.
Les interactions utilisateur doivent être mesurées dans les journaux
Un parc de rapports ne se migre pas sur la base des seules listes de documents. Il faut mesurer qui consulte, à quelle fréquence, avec quels paramètres et quel format de sortie. Sans logs d’audit conservés sur douze mois, les rapports trimestriels, annuels et les éditions de clôture risquent d’être classés à tort parmi les documents inutilisés.
Un rapport ouvert chaque matin pour rechercher une anomalie n’a pas le même avenir qu’un rapport diffusé en PDF à cinq cents destinataires. Le premier peut être remplacé par une visualisation interactive ou par un rapport opérationnel mieux ciblé. Le second demande surtout une restitution stable, des paramètres verrouillés et un contrôle de pagination.
La documentation de Microsoft sur les rapports paginés, consultée le 18 juin 2026, positionne ces documents pour les sorties très formatées et adaptées à l’impression. Elle ne les présente pas comme un substitut universel aux rapports interactifs Power BI. Cette distinction doit guider le tri du parc avant toute estimation de charge.
Les performances dépendent d’abord du dataset
Dans un rapport paginé, le rendu peut être lent parce que la requête ramène trop de lignes, parce que les paramètres ne filtrent pas assez tôt ou parce que des expressions lourdes sont évaluées dans chaque cellule. Déplacer une logique calculée dans le RDL masque le problème au début. Sur un état de plusieurs milliers de lignes, les performances se dégradent et le diagnostic devient plus difficile.
La requête source doit donc être examinée avant la maquette. Un dataset ramenant le détail journalier pour produire un total mensuel coûte plus cher en temps de traitement qu’un dataset déjà agrégé au bon grain. À l’inverse, pré-agréger un état destiné à l’audit retire le niveau de détail dont les contrôleurs ont besoin. La bonne granularité dépend du rapport, pas du nom de sa catégorie.
Certains contenus publiés en 2022 avancent qu’une requête DAX capturée via SQL Server Profiler ou DAX Studio permettrait de ramener une conversion de plusieurs dizaines d’heures à quelques minutes. Cette pratique peut fournir une trace utile de la requête exécutée par un visuel Power BI. Elle ne permet pas de déduire la charge de reprise d’un rapport Webi, dont les objets, l’univers et les règles de présentation sont différents.
Microsoft décrit les prérequis et méthodes de publication dans son guide de prise en main des rapports paginés, consulté le 18 juin 2026. La documentation doit être lue avec vos contraintes d’accès, de capacité et de diffusion. Les paramètres commerciaux et les droits de publication évoluent, ils doivent être vérifiés dans votre contrat et sur les pages officielles avant engagement.
La meilleure réponse peut donc être de ne pas produire un RDL pour chaque document Webi. Un rapport rarement consulté peut être retiré après validation métier, tandis qu’un état réglementaire ou opérationnel reste candidat à une reprise détaillée.
Comment chiffrer la migration Webi vers un rapport paginé sans sous-estimer la recette
La charge de migration ne se calcule pas en divisant le nombre de rapports par une durée arbitraire. Elle dépend du nombre de requêtes, des variables, des groupes de restitution, des paramètres, des sources de données et du niveau de contrôle attendu. Le rapport paginé est souvent plus rapide à construire lorsqu’il ne fait que présenter un dataset déjà validé. Il devient plus long lorsque le document Webi contient des règles de gestion dispersées.
Un chiffrage utile sépare la reprise du rendu, la construction des datasets, la recette de données, la recette PDF et Excel, la reprise des droits et la phase de double run. Mélanger ces postes revient à annoncer une durée de développement alors que le comité attend le coût complet de bascule.
Un exemple de calcul borne la charge de reprise
Le calcul suivant est un exemple de dimensionnement, et non un tarif ni une promesse contractuelle. Il repose sur un parc de 120 rapports Webi, dont 60 états standardisés, 36 états avec variables ou ruptures complexes, et 24 documents à retirer après vérification d’usage. Les ratios affichés représentent la reprise du rapport et son test technique initial, hors recette métier, hors formation, hors gestion des habilitations et hors travaux sur le modèle de données.
| Catégorie de document | Volume retenu | Ratio de reprise retenu | Calcul | Charge obtenue |
|---|---|---|---|---|
| État standard avec un dataset et un tablix | 60 rapports | 6 à 10 heures par rapport | 60 × 6 à 10 heures | 360 à 600 heures |
| État complexe avec variables, groupes et paramètres | 36 rapports | 18 à 30 heures par rapport | 36 × 18 à 30 heures | 648 à 1 080 heures |
| Rapport écarté après analyse d’usage | 24 rapports | 0 heure de reprise | 24 × 0 heure | 0 heure |
| Total de reprise technique | 96 rapports repris | Selon la répartition ci-dessus | 360 à 600 + 648 à 1 080 | 1 008 à 1 680 heures |
Ces ratios sont une hypothèse de travail établie pour cet exemple au 18 juin 2026. Ils ne couvrent pas la recette fonctionnelle, les corrections d’écarts, le double run, les droits ni l’industrialisation de la diffusion. Une équipe qui annonce 1 008 heures comme charge totale reprendrait donc un chiffre incomplet dans son budget.
La recette ajoute un poste distinct. Chaque état doit être comparé sur des périodes qui révèlent les cas limites, notamment une période courante, une période clôturée, une période contenant des annulations et une période avec peu de lignes. La comparaison doit porter sur les volumes, les agrégats, les valeurs détaillées et la pagination.
- Figez une extraction de référence Webi avec les paramètres et la date de rafraîchissement utilisés.
- Exécutez le rapport paginé sur la même période et avec la même définition de population.
- Classez chaque écart entre donnée source, règle de calcul, filtre, arrondi ou formatage.
- Faites signer l’acceptation des écarts justifiés avant de retirer le document Webi.
Un écart de zéro virgule quatre pour cent ne doit pas être déclaré acceptable parce qu’il paraît faible. Il peut correspondre à un filtre de statut, à une devise, à des avoirs ou à des lignes exclues. La tolérance doit être définie par indicateur, par population et par propriétaire métier.
Avant d’engager la reprise, exportez les métadonnées disponibles, les logs d’usage sur douze mois et les PDF représentatifs de chaque famille de documents. C’est ce dossier qui permet de décider quels rapports méritent un rapport paginé Power BI, lesquels doivent devenir interactifs et lesquels doivent sortir du périmètre.
Peut-on convertir automatiquement un rapport Webi en rapport paginé Power BI ?
Aucun mécanisme standard ne convertit directement un document Webi et ses règles de présentation en fichier RDL. Les tableaux, groupes, paramètres, expressions et liens doivent être repris puis testés. La réutilisation d’une requête source peut réduire une partie du travail, sans remplacer la reconstruction du rendu.
La migration vers Power BI provoque-t-elle forcément une perte de données ?
Les données présentes dans la source ne disparaissent pas mécaniquement. Le risque porte sur les filtres, contextes d’univers, variables locales, objets fusionnés et règles de calcul qui modifiaient le périmètre affiché dans Webi. Une recette de population et d’agrégats permet de repérer ces écarts.
Quand un rapport paginé est-il préférable à un rapport Power BI interactif ?
Le rapport paginé convient aux états détaillés, aux documents PDF, aux impressions structurées et aux exports dont la mise en page doit rester stable. Un rapport interactif est plus adapté lorsqu’un utilisateur doit explorer librement les dimensions, changer l’angle d’analyse et naviguer entre plusieurs visualisations.
Pourquoi comparer aussi les exports Excel pendant la recette ?
Un RDL peut être correct en PDF et produire un classeur difficile à exploiter en raison de cellules fusionnées, de colonnes supplémentaires ou d’en-têtes mal positionnés. Si les utilisateurs retraitent l’export Excel, ce support doit faire partie des critères de réception.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
