WebFOCUS est une plateforme de business intelligence construite autour d’un serveur de reporting, d’un client web, d’un serveur d’applications et de connecteurs vers les sources de données. Son évolution récente privilégie une porte d’entrée unifiée, le Hub, sans supprimer les objets historiques dont dépend souvent le reporting existant.
En bref
- WebFOCUS sépare l’exécution des requêtes, la présentation des rapports et l’administration, ce qui explique sa capacité à servir des usages très différents.
- Les rapports, tableaux de bord, procédures de transformation et métadonnées doivent être inventoriés séparément avant toute évolution du produit.
- Le WebFOCUS Hub rapproche la création, la recherche et le partage de contenu, mais ne remplace pas automatiquement les objets développés dans les interfaces antérieures.
- Une reprise vers une autre plateforme ne consiste pas à exporter des écrans : les règles portées par les procédures, les synonymes et les filtres doivent être réconciliées.
Ce dossier concerne les responsables BI qui exploitent ou évaluent un parc WebFOCUS pour du reporting d’entreprise. Il traite l’architecture logicielle, les fonctionnalités et les conséquences d’une évolution produit sur les objets existants. Les clauses contractuelles, la sécurité des données personnelles et les choix d’infrastructure hors décisionnel relèvent des profils compétents concernés.
Comment l’architecture logicielle de WebFOCUS répartit les traitements
L’architecture de WebFOCUS repose sur une séparation nette entre l’accès utilisateur, les services d’application et le moteur qui interroge les données. Cette séparation compte lors d’un audit. Un rapport visible dans un navigateur n’indique pas où se trouve la règle qui calcule une marge, limite une période ou transforme un code métier.
Le navigateur accède habituellement au WebFOCUS Client. Cette couche expose les espaces de travail, les rapports, les tableaux de bord et les mécanismes de diffusion. Elle porte aussi une part de l’organisation documentaire : dossiers, droits, publications et accès aux contenus. Le client ne doit pas être confondu avec le moteur de requête.
Le Reporting Server reçoit les demandes d’exécution et produit les jeux de résultats. Il s’appuie sur des synonymes, qui décrivent les structures sources, ainsi que sur des procédures FOCUS, SQL ou Dialogue Manager selon les développements. Une procédure peut contenir des jointures, des calculs, des paramètres, des ruptures de format et des règles de filtrage. C’est souvent là que se cache l’écart entre un rapport WebFOCUS et sa reprise apparente dans un outil cible.
Le serveur d’applications assure la communication entre la couche web, les services de sécurité et les composants d’exécution. Selon le déploiement, un serveur web frontal gère ensuite les requêtes HTTP, l’authentification déléguée et le routage. La documentation d’architecture publiée dans la communauté ibi décrit précisément cette coexistence entre Web Server, WebFOCUS Client, Application Server et Reporting Server. La lecture d’une présentation du rattachement de WebFOCUS à TIBCO aide aussi à replacer l’évolution de l’éditeur dans le calendrier du produit.
Les objets techniques ne portent pas tous le même risque de reprise
Un rapport HTML exécuté à partir d’une procédure et un tableau de bord composé de plusieurs requêtes n’ont pas le même coût de compréhension. Le premier risque se situe dans les objets réutilisés. Un synonyme peut être appelé par plusieurs procédures. Une modification de type de colonne, de libellé ou de jointure peut donc toucher un périmètre plus large que le dossier applicatif observé.
Les métadonnées jouent un rôle comparable à celui d’un univers dans SAP BusinessObjects. Elles fournissent aux développeurs et, selon les cas, aux utilisateurs métier, une représentation exploitable des sources. Le nom affiché dans le reporting peut masquer une table, une vue, un fichier ou une procédure d’accès. La migration ne doit pas reprendre uniquement les libellés visibles. Elle doit vérifier la source réelle, la granularité et le filtre appliqué avant agrégation.
Les procédures de transformation exigent une attention particulière. Une instruction de calcul dans un flux peut produire une colonne qui n’existe pas dans la base. Si cette colonne devient une mesure dans un modèle sémantique cible, son expression doit être documentée avec la même unité, le même arrondi et la même période de référence. Un écart de quelques dixièmes peut rester acceptable pour une visualisation exploratoire. Il ne l’est pas forcément pour une restitution financière.
| Composant WebFOCUS | Fonction dans l’architecture | Objet à inventorier | Risque lors d’une évolution ou d’une reprise |
|---|---|---|---|
| WebFOCUS Client | Accès aux contenus et gestion des espaces utilisateurs | Dossiers, portails, publications, droits | Un contenu peut disparaître de la navigation sans que la procédure source soit supprimée. |
| Reporting Server | Exécution des requêtes et génération des sorties | Procédures, synonymes, connexions, fichiers temporaires | Des calculs ou filtres peuvent rester invisibles dans la mise en page du rapport. |
| Serveur d’applications | Services applicatifs et échanges entre composants | Paramètres de déploiement, authentification, journaux | Les droits et chemins d’exécution peuvent changer après une mise à niveau. |
| Serveur web | Exposition HTTP et routage | Configuration d’accès, certificats, règles de routage | La disponibilité du portail ne garantit pas l’exécution correcte des rapports. |
Ce tableau reprend la répartition fonctionnelle décrite par la documentation d’architecture de la communauté ibi, consultée le 24 mars 2026. Il ne remplace pas un relevé de configuration : les noms d’hôtes, les connexions et les mécanismes d’authentification dépendent de chaque installation.
Un inventaire utile commence donc par les dépendances entre rapports, procédures et synonymes. Il doit ensuite rapprocher ces dépendances des logs d’exécution sur douze mois glissants. Sans cette double lecture, une équipe surestime fréquemment le volume à reprendre parce qu’elle confond objets stockés et objets réellement utilisés.
Quelles fonctionnalités WebFOCUS doivent être examinées avant une migration
Les fonctionnalités de WebFOCUS couvrent davantage que l’affichage de graphiques. La plateforme assemble reporting paramétré, diffusion de documents, analyse de données, accès à des sources variées et administration des contenus. Cette amplitude explique qu’un parc réduit en nombre de rapports puisse porter une charge élevée de reprise.
Le reporting demeure le point de départ de nombreux déploiements. Les sorties peuvent être distribuées dans plusieurs formats, planifiées ou déclenchées selon des conditions de gestion. Un rapport PDF envoyé chaque mois à un groupe restreint paraît stable. Pourtant, il peut intégrer une procédure avec une période glissante, une table de correspondance et une règle d’exclusion. La cible doit reproduire la règle validée, non le seul format PDF.
La visualisation intervient par les graphiques, les assemblages de composants et les tableaux de bord. Les utilisateurs retiennent souvent les indicateurs visibles. L’audit doit aller plus loin et examiner la construction de chaque indicateur : source, niveau de détail, filtre obligatoire, agrégation et comportement lorsqu’une valeur est absente. Un taux affiché à deux décimales peut provenir d’un calcul effectué avant ou après agrégation. Les deux approches ne donnent pas toujours le même résultat.
La plateforme propose également des mécanismes de préparation, de gestion et d’intégration de données. Le vocabulaire commercial de l’éditeur regroupe ces capacités dans une offre large. Pour un chantier décisionnel, la question utile reste plus concrète : quel objet appelle quelle source, avec quelle fréquence, et quel utilisateur dépend de la sortie produite ? Une connexion inactive n’a pas le même statut qu’une procédure exécutée chaque nuit.
Le Hub modifie l’entrée utilisateur, pas la nécessité d’inventorier
Dans un billet publié le 22 février 2023, ibi présentait le WebFOCUS Hub comme un point d’entrée destiné à trouver, gérer, créer et partager contenus et données. La source décrivait aussi une recherche d’expérience plus cohérente entre profils métier, développeurs BI et administrateurs. Cette orientation est documentée dans l’historique WebFOCUS publié sur ce site, à rapprocher des documents éditeur avant toute décision de version.
Le Hub peut réduire la dispersion des accès pour les utilisateurs. Il ne supprime pas les objets construits antérieurement dans d’autres interfaces. Une organisation qui évalue l’évolution produit doit distinguer trois questions. La première porte sur l’expérience de consultation. La deuxième concerne la maintenance des développements. La troisième concerne les dépendances techniques entre le portail, les procédures et les sources.
- Les rapports paramétrés doivent être classés selon leur fréquence d’exécution, leur destinataire et la présence de calculs dans les procédures.
- Les tableaux de bord doivent être décomposés en requêtes unitaires afin d’identifier les filtres communs et les agrégations distinctes.
- Les mécanismes de diffusion doivent être contrôlés avec leurs listes de destinataires, leurs calendriers et leurs éventuelles pièces jointes.
- Les connexions doivent être rapprochées des synonymes et des procédures pour séparer les accès actifs des accès historiques.
La documentation et les communications de l’éditeur doivent être relues à la version exacte de votre socle. Une fonctionnalité annoncée pour WebFOCUS 9.2 ne doit pas être projetée sur un environnement WebFOCUS 8 sans vérification. Cette règle paraît administrative. Elle évite pourtant de chiffrer une évolution à partir d’un périmètre fonctionnel qui n’existe pas dans l’installation concernée.
Le produit propose des capacités d’analyse avancée dans son positionnement éditeur. Leur évaluation détaillée dépasse le périmètre d’un audit de socle décisionnel. La reprise doit se concentrer sur les rapports consommés, leurs règles de calcul et les conditions de validation qui permettent à une direction de continuer à piloter son activité.
La fonctionnalité réellement critique n’est donc pas celle qui figure le mieux dans une démonstration. C’est celle dont dépend un chiffre distribué, commenté ou rapproché chaque mois. Le prochain examen porte logiquement sur les flux qui alimentent ce chiffre.
Comment WebFOCUS organise l’intégration et l’analyse de données
L’intégration dans WebFOCUS ne se résume pas à l’ouverture d’une connexion vers une base relationnelle. Le Reporting Server accède à des sources décrites par des synonymes et peut combiner données relationnelles, fichiers, services ou autres formats pris en charge par l’environnement. La structure retenue détermine ensuite les possibilités de jointure, de filtre, de calcul et de restitution.
Cette organisation a une conséquence directe lors d’un audit. Une table source connue des équipes techniques ne dit pas quelle version de cette table est réellement interrogée par le rapport. Une procédure peut appeler une vue, reformater un champ, créer une clé de jointure ou écrire une table de travail avant de produire la sortie finale. Reprendre seulement le SQL identifié dans un outil de supervision ne suffit pas à expliquer la chaîne complète.
Le synonyme est un point de contrôle utile. Il relie un nom exploitable dans les développements WebFOCUS à une structure de données sous-jacente. Ses attributs peuvent préciser des formats, des descriptions de colonnes, des segments et d’autres éléments utilisés par les requêtes. Lorsque le modèle cible est préparé, chaque champ utile doit être rapproché de cette définition et de son résultat effectif sur un échantillon de périodes validées.
Les écarts viennent souvent de la granularité, pas du graphique
Les écarts de réconciliation naissent fréquemment avant la visualisation. Une mesure de chiffre d’affaires peut être calculée sur la ligne de facture, sur la commande ou sur le client. Si le rapport historique joint une dimension qui multiplie les lignes avant l’agrégation, le résultat ne correspondra pas à une mesure reconstruite sur une table déjà agrégée. Le nouvel affichage peut paraître plus cohérent tout en s’écartant de la référence historique.
La méthode doit donc isoler les étapes. Une première comparaison porte sur le nombre de lignes extraites. Une deuxième porte sur les montants bruts avant calcul. Une troisième vérifie les filtres, notamment les statuts, les dates et les entités exclues. La dernière comparaison concerne l’arrondi, le format et la mise en page. Cette séquence permet de localiser l’origine d’un écart plutôt que de la chercher dans le tableau de bord final.
Un protocole de contrôle utilisable en projet peut suivre l’ordre ci-dessous.
- Extraire sur une période clôturée le résultat détaillé du rapport WebFOCUS et conserver les paramètres employés.
- Identifier dans la procédure les synonymes, jointures, filtres et colonnes calculées qui contribuent au résultat.
- Exécuter la logique cible sur le même périmètre, à la même date de référence et avec les mêmes exclusions documentées.
- Comparer les volumes, les montants par niveau de détail et les totaux, puis consigner chaque différence dans un registre d’écarts.
- Faire valider par le propriétaire métier les écarts expliqués avant de modifier les règles ou la restitution.
La tolérance doit être décidée par indicateur. Une différence de présentation de 0,01 liée à l’arrondi peut être acceptée si elle est traçable. Une différence de périmètre liée à un statut client ne l’est pas sans validation formelle. Le rapport de recette doit aussi préciser si l’écart provient du socle historique, de la cible ou d’une règle métier modifiée entre les deux périodes.
La question de la protection des données personnelles peut apparaître lorsque les extraits contiennent des identifiants ou des coordonnées. Elle relève du DPO et des responsables sécurité, pas d’un arbitrage sur les procédures de reporting. L’examen décisionnel s’arrête ici à la minimisation des extraits de recette et à la traçabilité de leurs accès.
Une intégration correctement cartographiée réduit les surprises lors de la recette, mais elle ne dispense pas de mesurer le parc réel. Le volume stocké et le volume consulté racontent rarement la même histoire.
Comment mesurer le parc WebFOCUS avant de décider une évolution produit
La première décision n’est pas de migrer, de mettre à niveau ou de reconstruire. Elle consiste à établir ce qui est réellement utilisé. Un répertoire peut contenir plusieurs centaines de rapports, procédures et versions archivées. Une partie correspond à des besoins abandonnés, à des essais non supprimés ou à des restitutions annuelles qui n’apparaissent pas dans une période d’observation trop courte.
Les journaux d’audit sont la source prioritaire lorsqu’ils sont conservés avec une profondeur suffisante. Ils doivent être extraits sur douze mois glissants pour inclure les opérations mensuelles, trimestrielles et annuelles. Leur lecture doit distinguer l’ouverture d’un portail, l’exécution d’un rapport, la planification d’une diffusion et l’échec d’une demande. Un rapport peut être distribué automatiquement sans générer de consultation interactive.
Le relevé technique doit être confronté aux propriétaires métier. Un contenu consulté une fois par an peut soutenir une obligation de clôture ou de contrôle. À l’inverse, un rapport exécuté quotidiennement peut ne servir qu’à vérifier un traitement qui a été remplacé. Le log donne la fréquence. Il ne donne pas la valeur de gestion du contenu.
Un calcul de charge doit séparer la reprise, la recette et les droits
Un exemple chiffré permet de poser le périmètre. Prenons un inventaire de 240 rapports, dont 144 restitutions standard, 72 rapports comportant des paramètres et des calculs, et 24 tableaux de bord composites. L’hypothèse de travail retient 2 heures pour inventorier et reconstruire une restitution standard, 6 heures pour un rapport avec calculs ou paramètres, et 14 heures pour un tableau de bord composé de plusieurs requêtes.
La charge de reprise seule se calcule ainsi : 144 × 2 heures, soit 288 heures ; 72 × 6 heures, soit 432 heures ; 24 × 14 heures, soit 336 heures. Le total atteint 1 056 heures. Cette estimation exclut la recette métier, la reprise des droits, la formation, la correction des sources et la conduite du changement. Elle est fondée sur des ratios de cadrage utilisés uniquement pour cet exemple ; elle ne constitue pas un tarif ni un engagement de durée.
La recette peut représenter une charge comparable sur les rapports les plus sensibles, car elle mobilise les propriétaires de chiffres. Les droits demandent également une analyse spécifique lorsque les accès proviennent de groupes externes, de règles d’annuaire ou de périmètres organisationnels. Additionner ces travaux à une estimation de reprise sans les distinguer masque le risque au moment où le planning est présenté.
| Type d’objet inventorié | Nombre d’objets | Ratio de reprise retenu | Charge calculée | Périmètre non compris |
|---|---|---|---|---|
| Rapport standard | 144 | 2 heures par rapport | 288 heures | Recette métier et reprise des droits |
| Rapport paramétré ou calculé | 72 | 6 heures par rapport | 432 heures | Correction de source et formation |
| Tableau de bord composite | 24 | 14 heures par tableau de bord | 336 heures | Recette détaillée des indicateurs |
| Total de reprise seule | 240 | Hypothèses explicitées ci-dessus | 1 056 heures | Tout travail transverse reste à chiffrer séparément |
Ce tableau est un calcul de dimensionnement, établi le 24 mars 2026 pour illustrer la méthode. Sur un parc inférieur à cent rapports, dont la moitié n’est plus consultée et dont les règles sont accessibles, la reconstruction peut coûter moins que la reprise systématique. Au-delà de trois cents objets avec des procédures peu documentées et des diffusions actives, la conservation des dépendances devient souvent plus prudente.
La documentation publique consultée ne donne pas accès à un environnement WebFOCUS de cette version. L’analyse s’appuie donc sur les descriptions d’architecture et de fonctionnalités publiées, ainsi que sur une méthode de cartographie applicable à un parc existant. Aucun écran ni aucun retour d’exécution n’est reconstitué ici.
La décision devient défendable lorsque le volume actif, les règles cachées et la charge exclue sont visibles dans le même dossier. L’étape suivante consiste à interpréter l’évolution produit sans confondre modernisation d’interface et remplacement du socle.
Que change l’évolution de WebFOCUS pour les rapports et tableaux de bord existants
L’évolution produit de WebFOCUS vers une plateforme davantage centrée sur le Hub répond à un besoin d’unification des usages. Le billet ibi publié le 22 février 2023 décrit le passage d’un ensemble d’applications à des capacités plus connectées autour de la recherche, de la création et du partage de contenu. Cette orientation peut améliorer l’accès aux fonctionnalités. Elle ne transforme pas, à elle seule, les procédures historiques en objets faciles à maintenir.
Pour un responsable BI, la question porte moins sur la nouveauté de l’interface que sur la continuité des dépendances. Les rapports existants peuvent s’appuyer sur des conventions de nommage, des répertoires, des synonymes et des routines développées au fil du temps. Une évolution majeure doit être précédée d’un relevé des objets exécutés, de leurs propriétaires et de leurs sources. Sans ce relevé, les incidents apparaissent après bascule sous la forme la plus coûteuse : un chiffre attendu n’est plus disponible au moment d’une clôture.
Les tableaux de bord doivent être traités comme des assemblages. Leur apparence peut être reprise dans une interface récente. Le comportement des filtres, des rafraîchissements et des interactions doit être vérifié composant par composant. Un filtre appliqué à l’ensemble de la page ne produit pas le même résultat qu’un filtre présent dans chaque requête. Cette différence devient visible dès qu’un utilisateur compare un total de tableau de bord à un rapport exporté.
La mise à niveau et la migration répondent à deux arbitrages différents
La mise à niveau conserve en principe le cadre WebFOCUS et vise une version plus récente du produit. La migration vers une autre plateforme reconstruit ou traduit des objets vers un autre modèle sémantique, un autre moteur de reporting et une autre administration. Les deux opérations comportent de la recette. Elles ne portent pas le même risque de réécriture.
Une mise à niveau convient lorsqu’un parc reste actif, que les procédures sont connues, que les sources demeurent disponibles et que les usages correspondent encore au produit. Une migration peut être étudiée lorsque les compétences nécessaires se raréfient, que les contenus réellement utilisés sont limités ou que l’organisation veut rationaliser plusieurs plateformes. La seconde option échoue lorsque l’on traite chaque rapport comme une copie visuelle et que les règles de calcul n’ont pas été extraites.
Les communications éditeur doivent être relues avec leur date de publication et la version concernée. La page de présentation de 2023 ne constitue pas une note de maintenance ni une garantie de disponibilité pour toutes les versions. Pour les échéances contractuelles, le bon document reste celui fourni dans le portail de support de l’éditeur et associé à votre référence produit. Les conditions de support et de licence relèvent ensuite de votre contrat et de votre interlocuteur juridique ou achats.
La trajectoire proposée par l’éditeur met en avant une expérience plus intégrée, des outils de recherche et de création de contenu, ainsi que des modes d’exploration plus accessibles. Ces éléments peuvent modifier les pratiques des utilisateurs. Ils ne dispensent pas de maintenir une séparation entre contenu exploratoire et reporting de référence. Un indicateur de pilotage doit conserver sa définition, sa source, son propriétaire et son protocole de validation.
Avant de lancer une évolution WebFOCUS, extrayez les journaux sur douze mois, classez les procédures par dépendance et faites valider les vingt rapports les plus consultés sur une période clôturée. Ce travail détermine si le projet porte sur une mise à niveau maîtrisée, une reconstruction ciblée ou une conservation temporaire du socle existant.
Quels sont les principaux composants de l’architecture WebFOCUS ?
L’architecture comprend habituellement un serveur web, le WebFOCUS Client pour l’accès aux contenus, un serveur d’applications et le Reporting Server qui exécute les requêtes, utilise les synonymes et génère les restitutions. Les noms et paramètres exacts dépendent du déploiement.
Le WebFOCUS Hub remplace-t-il les rapports historiques ?
Le Hub fournit une entrée unifiée pour trouver, gérer, créer et partager des contenus. Il ne convertit pas automatiquement les procédures, les synonymes, les filtres ou les mécanismes de diffusion construits dans les environnements antérieurs.
Comment vérifier qu’un rapport WebFOCUS est encore utilisé ?
Les logs d’audit doivent être analysés sur douze mois glissants, puis comparés aux calendriers de diffusion et validés avec les propriétaires métier. Cette durée évite d’écarter des restitutions trimestrielles ou annuelles.
Pourquoi deux rapports peuvent-ils produire des chiffres différents après une reprise ?
Les écarts proviennent souvent d’une différence de granularité, de jointure, de filtre, de période ou d’arrondi. La comparaison doit commencer sur les lignes extraites et les montants bruts avant de porter sur la visualisation finale.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
