Tous Socles hérités Chantiers de migration Recette & réconciliation Échéances éditeurs

Information Builders : WebFOCUS, histoire et rachat par TIBCO

24 min de lecture
Cet article a été généré par intelligence artificielle et publié sans révision humaine approfondie.

Information Builders, fondé en 1975, a construit autour de FOCUS puis de WebFOCUS une plateforme décisionnelle utilisée pour le reporting opérationnel, l’intégration et l’analyse de données. TIBCO a annoncé son rachat en octobre 2020 et l’a finalisé en janvier 2021, afin d’ajouter les actifs d’ibi à son portefeuille analytique et d’intégration.

En bref

  • Information Builders a précédé la plupart des éditeurs modernes de BI avec FOCUS, un langage et environnement de reporting destiné aux grands systèmes.
  • WebFOCUS a conservé une place particulière dans les organisations qui diffusent un grand nombre de rapports opérationnels à des utilisateurs non techniques.
  • Le rachat par TIBCO a été annoncé en octobre 2020, pour une valeur de transaction que Reuters estimait alors proche d’un milliard de dollars.
  • L’opération s’est achevée en janvier 2021 après la clôture de l’exercice 2020 d’Information Builders.
  • Pour un parc WebFOCUS encore exploité en 2026, l’enjeu n’est pas de rejouer l’annonce du rachat, mais d’identifier les règles de gestion, les chaînes d’intégration et les rapports réellement utilisés.

Ce dossier s’adresse aux responsables BI, DSI et chefs de projet qui doivent situer un environnement WebFOCUS dans son historique produit avant un audit, une mise à niveau ou une migration. Il traite du reporting, des métadonnées et de l’intégration ; les sujets de contrats, de protection des données et de sécurité relèvent des profils compétents dans ces domaines.

Comment Information Builders a construit l’historique de WebFOCUS

Information Builders naît en 1975, dans une période où le reporting d’entreprise dépend encore largement des mainframes, des traitements différés et d’équipes techniques centralisées. Son premier marqueur est FOCUS, un environnement de quatrième génération conçu pour interroger, structurer et restituer les données sans demander à chaque utilisateur de maîtriser les langages de programmation alors dominants.

Cette origine compte encore lorsqu’un parc WebFOCUS est audité. Le produit n’a pas été pensé au départ comme un outil de visualisation isolé. Il porte une logique de chaîne complète, depuis l’accès à des sources hétérogènes jusqu’à la diffusion d’états, de tableaux de bord et d’applications de reporting. Cette continuité explique pourquoi des organisations ont conservé WebFOCUS pendant plusieurs décennies.

La présentation historique publiée par ibi rappelle que l’éditeur a lancé FOCUS sur des machines en temps partagé, avec l’objectif de rendre la BI (Business Intelligence) accessible à un public plus large que les programmeurs. La source mérite d’être lue avec prudence, car elle relève naturellement la trajectoire de l’éditeur. Elle établit néanmoins les jalons produits et l’antériorité de la plateforme. La page officielle a été consultée le 1er janvier 2026 sur l’historique d’ibi.

Du langage FOCUS au reporting web industrialisé

Le passage vers WebFOCUS a déplacé le centre de gravité. Là où FOCUS était associé aux environnements historiques et aux requêtes de production, WebFOCUS a apporté une interface web, des mécanismes de diffusion et une couche de restitution plus adaptée aux intranets d’entreprise. Les rapports pouvaient être rendus sous forme HTML, PDF, Excel ou tableaux interactifs, selon les versions et les composants souscrits.

Cette évolution a renforcé un usage très concret. Un rapport WebFOCUS n’est pas toujours un tableau de bord de direction. Il peut être un état de suivi des commandes, une liste d’exceptions, un document de diffusion réglementaire ou une page embarquée dans une application métier. Dans certains parcs, cette diversité produit plusieurs centaines d’objets, avec des dépendances peu visibles entre procédures, métadonnées, fichiers de paramétrage et règles de sécurité.

La difficulté apparaît lorsque le parc est décrit uniquement comme une collection de rapports. Ce n’est pas suffisant. La couche FOCUS, les procédures, les synonymes de données, les jointures, les filtres implicites et les paramètres utilisateurs peuvent porter une part du calcul métier. Un rapport affichant douze colonnes peut appeler une procédure qui consolide plusieurs sources avant la restitution. La reprise de l’écran sans reprise de cette mécanique produit un résultat visuellement proche, mais fonctionnellement différent.

Un audit sérieux commence donc par séparer les objets de présentation des objets de transformation. Les développeurs WebFOCUS ont souvent regroupé dans une même procédure l’extraction, le calcul et la mise en forme. Cette pratique était cohérente avec les usages de l’époque. Elle devient coûteuse lorsque l’organisation cherche à déplacer le reporting vers une autre plateforme décisionnelle sans reconstituer les règles de gestion.

WebFOCUS n’est donc pas seulement un produit ancien. C’est un empilement de choix techniques faits à différentes périodes, souvent encore actifs dans les restitutions quotidiennes. Avant de parler de remplacement, il faut savoir si les procédures FOCUS constituent encore le moteur du calcul ou si elles ne servent plus qu’à alimenter des exports peu consultés.

Pourquoi la base installée a résisté aux cycles de marché

Information Builders a construit sa présence auprès d’organisations ayant besoin de diffuser du reporting à un volume important d’utilisateurs. Les administrations et services publics américains ont été souvent associés à cette base installée dans les communications et articles du secteur. Cette présence s’explique par des contraintes de continuité, de volumétrie, de sécurité applicative et de diffusion d’états standardisés, plutôt que par la recherche d’un outil de visualisation à la mode.

Le produit répondait aussi à un besoin que beaucoup de projets BI ont sous-estimé. Un utilisateur métier n’a pas nécessairement besoin de concevoir un modèle sémantique complet. Il doit parfois filtrer une liste, lancer un état paramétré, recevoir un document ou explorer un détail lié à une application opérationnelle. WebFOCUS a longtemps couvert cet espace entre le reporting administré et l’application métier.

Cette place explique la prudence nécessaire en migration. Lorsque 80 % des usages sont des rapports paginés, des listes de contrôle ou des exports Excel programmés, remplacer WebFOCUS par un outil centré sur le tableau de bord peut laisser un vide fonctionnel. Le choix de cible doit alors intégrer les besoins de diffusion, de génération de documents et de planification, pas seulement la capacité à dessiner des graphiques.

L’historique d’Information Builders pèse donc directement sur le périmètre d’un chantier actuel. Un inventaire qui ne recense que les tableaux visibles ne mesure pas le socle réellement exploité. Les procédures, les planifications et les destinataires font partie du patrimoine décisionnel à examiner.

Illustration éditoriale du sujet : Information Builders : WebFOCUS, histoire et rachat par TIBCO
Illustration générée par intelligence artificielle.

Pourquoi TIBCO a engagé le rachat d’Information Builders

TIBCO a annoncé le projet de rachat d’Information Builders le 22 octobre 2020. Dans son communiqué, l’éditeur présentait l’opération comme un renforcement de sa plateforme Connected Intelligence, avec l’ajout de capacités d’intégration, de gestion des données et d’analyse. La source primaire est le communiqué de TIBCO annonçant l’accord, consulté le 1er janvier 2026.

Le montant exact n’a pas été détaillé dans le communiqué de TIBCO. Reuters, repris par plusieurs publications professionnelles à l’époque, évoquait une transaction proche d’un milliard de dollars. Cette estimation ne doit pas être transformée en prix officiel. Elle donne seulement un ordre de grandeur du poids attribué à la base clients, aux produits et aux équipes d’Information Builders lors de l’opération.

Le raisonnement industriel est lisible. TIBCO disposait déjà d’actifs d’intégration applicative, de traitement événementiel et d’analyse, notamment autour de Spotfire. Information Builders apportait une plateforme de reporting et de préparation de données ayant une implantation historique dans de grands comptes. Le rapprochement cherchait à rapprocher des composants qui étaient souvent achetés séparément par les entreprises.

La complémentarité entre intégration, qualité et analyse de données

Dans son annonce, TIBCO insistait sur les capacités complémentaires des deux portefeuilles. Information Builders était connu pour WebFOCUS, mais aussi pour des outils d’intégration et de gestion de données. TIBCO mettait en avant son Any Data Hub et son Responsive Application Mesh. Les mots employés dans le communiqué relèvent de la communication d’éditeur ; ils ne prouvent pas, à eux seuls, qu’une intégration fonctionnelle complète était déjà disponible le jour de l’annonce.

Pour un responsable de plateforme décisionnelle, la question utile est plus précise. Quels composants communiquent réellement, dans quelle version, et avec quel niveau de reprise des métadonnées ? Une suite élargie peut réunir des outils complémentaires sans supprimer les travaux de mapping, de recette ou de sécurisation des flux. Une acquisition ne convertit pas automatiquement une procédure WebFOCUS en modèle sémantique ou en flux d’intégration cible.

Le tableau suivant distingue les apports historiques annoncés autour de l’opération. Il ne décrit pas une équivalence technique entre les produits. Les dénominations sont reprises du communiqué TIBCO et des pages historiques d’ibi, consultées le 1er janvier 2026.

Actif concerné Rôle avant le rachat Complément recherché par TIBCO Point à vérifier dans un parc existant
WebFOCUS Reporting web, diffusion d’états et tableaux de bord Élargir l’offre analytique et la restitution pour les métiers Procédures, formats de sortie, planifications et droits
Fonctions d’intégration d’Information Builders Accès, préparation et mouvement de données entre sources Renforcer la chaîne d’intégration de TIBCO Mappings, traitements de rejets et dépendances de sources
Spotfire et composants analytiques TIBCO Analyse visuelle et exploration de données Créer une offre plus large de restitution et d’analyse Cas d’usage nécessitant du reporting paginé plutôt que visuel
Base clients d’Information Builders Parcs historiques dans plusieurs secteurs Accroître la présence de TIBCO dans l’analytique d’entreprise Versions réellement déployées et contrats de maintenance

La source de ce tableau est le communiqué TIBCO du 22 octobre 2020 et la page History d’ibi, relevés le 1er janvier 2026. Le tableau croise le rôle produit et la conséquence opérationnelle, car c’est là que se situe la charge réelle d’un audit.

La transaction était alors annoncée sous réserve des conditions habituelles de clôture et des approbations requises. Cette réserve n’était pas décorative. Elle explique l’écart entre l’annonce d’octobre 2020 et la finalisation intervenue après la clôture de l’exercice d’Information Builders.

Ce que TIBCO achetait au-delà d’un produit de BI

La valeur d’un éditeur de reporting ne se limite pas à son interface. Elle comprend des connecteurs, des modèles de sécurité, une communauté de développeurs, des composants d’administration et un portefeuille de clients dont les processus métiers dépendent de rapports planifiés. Dans le cas d’Information Builders, le rachat visait aussi cette densité opérationnelle.

Un parc installé peut contenir des rapports rarement ouverts mais indispensables à une échéance mensuelle, trimestrielle ou réglementaire. Les logs d’usage sur quatre-vingt-dix jours les classent parfois comme inactifs. Cette erreur fausse l’estimation de périmètre. Il faut examiner au minimum douze mois de traces, puis rapprocher les planifications serveur et les listes de diffusion.

L’acquisition a donc renforcé une offre, mais elle a également rendu les trajectoires produit moins immédiates à lire pour les clients. Après un rachat, les noms commerciaux évoluent, les équipes de support changent et la documentation est progressivement déplacée. La première action utile reste la même : identifier exactement la version WebFOCUS, son mode de déploiement et la liste des composants utilisés.

Comment le rachat de TIBCO a modifié la trajectoire de WebFOCUS

TIBCO a annoncé la clôture de l’acquisition le 7 janvier 2021. Le communiqué précise que l’opération avait été finalisée après l’annonce d’octobre et après la clôture de l’exercice 2020 d’Information Builders, le 31 décembre. Cette date est documentée dans le communiqué officiel de finalisation, consulté le 1er janvier 2026.

Dans les mois ayant précédé le rachat, Information Builders avait déjà repositionné sa marque sous le nom ibi. Ce changement est parfois source de confusion dans les inventaires. Des contrats, serveurs, documentations et références de formation peuvent mentionner Information Builders, ibi ou WebFOCUS. Il faut traiter ces appellations comme des repères historiques, pas comme la preuve qu’un même composant est dans la même version.

La trajectoire de WebFOCUS après 2021 doit être regardée à travers les documents produits et de maintenance disponibles au moment de votre décision. Les annonces de marché donnent le contexte, mais elles ne remplacent pas une note de support applicable à votre version. Un responsable qui possède WebFOCUS 8.x n’obtient pas une réponse exploitable en lisant une annonce de rachat visant un portefeuille global.

La continuité produit ne dispense pas d’un audit technique

Après une acquisition, le premier risque est de supposer que la continuité commerciale garantit la continuité de toutes les configurations. Or un environnement WebFOCUS repose souvent sur des choix locaux : authentification, répertoires, connecteurs, procédures FEX, traitements planifiés, moteur de distribution et formats de sortie. Même si le produit est maintenu, ces éléments peuvent être affectés par une mise à niveau ou un changement de politique de support.

Le second risque consiste à lancer une migration uniquement parce que le nom de l’éditeur a changé. Ce n’est pas un motif suffisant. Sur un parc inférieur à cent rapports, dont plus de la moitié n’a pas été exécutée ou consultée sur douze mois, une reconstruction ciblée peut coûter moins de charge que la reprise systématique. L’arbitrage s’inverse lorsque plusieurs centaines de rapports actifs reposent sur des règles non documentées et des calendriers de diffusion sensibles.

Le calcul doit être explicite. Prenons un parc de 240 restitutions, sans prétendre qu’il représente tous les environnements. Supposons 144 rapports standards à reprendre à raison de deux heures chacun pour l’inventaire fonctionnel et la réécriture initiale, puis 96 rapports complexes à six heures chacun. La charge de reprise initiale atteint 864 heures, soit 288 + 576. Cette estimation exclut la recette, la reprise des droits, les flux d’alimentation, la correction des écarts et la formation.

Si la recette mobilise ensuite une heure par rapport standard et trois heures par rapport complexe, elle ajoute 432 heures. Le total passe à 1 296 heures avant pilotage et avant aléas. Les ratios ne proviennent pas d’une grille éditeur. Ils constituent une hypothèse de chiffrage à faire valider par l’équipe qui connaît les procédures et les règles. Leur intérêt est de rendre visible ce qui est inclus et ce qui ne l’est pas.

Ce type de calcul évite une confusion fréquente. La conversion d’un écran ne représente qu’une part de la charge. La compréhension des filtres implicites, des jointures, des valeurs par défaut et des destinataires programmés demande souvent davantage de temps que la construction visuelle de la cible.

Les objets WebFOCUS qui changent réellement le coût du chantier

Un inventaire utile ne se limite pas à compter les dossiers du portail. Il relève la nature de chaque objet. Les procédures FEX doivent être distinguées des pages de restitution. Les synonymes et métadonnées doivent être reliés à leurs sources. Les planifications, listes de diffusion et paramètres utilisateurs doivent être extraits séparément. Cette granularité permet d’identifier les éléments qui portent une règle de gestion.

Une condition placée dans une procédure de préparation ne se voit pas forcément sur la page finale. Si elle exclut les comptes inactifs, les écritures annulées ou une catégorie de produit, elle modifie le chiffre restitué. La comparaison entre ancien et nouveau reporting doit alors documenter l’écart attendu, le périmètre des données comparées et l’acceptation métier. Aucun projet sérieux ne promet des chiffres identiques sans protocole de réconciliation.

La clôture du rachat a donc modifié le cadre éditorial et commercial de WebFOCUS. Elle n’a pas réduit la responsabilité du client sur son propre patrimoine décisionnel. La prochaine vérification doit porter sur vos procédures les plus exécutées et sur les rapports programmés qui ne remontent pas dans les statistiques de consultation.

Quels usages WebFOCUS faut-il distinguer avant une migration de reporting

WebFOCUS rassemble souvent des usages hétérogènes sous une même bannière. Cette diversité explique pourquoi les projets de sortie sont fréquemment sous-estimés. Un tableau de bord filtrable, un rapport PDF envoyé chaque nuit, un export Excel à destination d’un contrôle de gestion et une page intégrée à une application métier ne se reprennent pas avec les mêmes composants ni les mêmes critères de recette.

La première étape consiste à établir un inventaire sur douze mois glissants. La période doit couvrir les productions mensuelles, trimestrielles et annuelles. Une fenêtre de trente ou quatre-vingt-dix jours peut exclure des états pourtant nécessaires à une clôture ou à une déclaration. Les traces de consultation doivent être croisées avec les journaux de planification, les répertoires de sortie et les listes de destinataires.

Il ne faut pas confondre absence d’ouverture dans un portail et absence d’usage. Un fichier produit automatiquement puis déposé dans un partage réseau peut ne générer aucune consultation WebFOCUS identifiable. Il peut néanmoins alimenter une réunion de direction, une opération logistique ou un contrôle financier. Seule la chaîne complète permet de le qualifier.

Les quatre familles d’objets à isoler dans le parc

Le classement suivant permet de préparer le chiffrage sans masquer les différences de charge. Chaque famille doit rester liée à une source, un propriétaire métier et une fréquence d’exécution. Lorsqu’aucun propriétaire n’est identifié, l’objet ne doit pas être supprimé immédiatement. Il doit passer dans une phase de validation avec une date limite et une conservation des preuves.

  1. Les rapports interactifs doivent être examinés pour leurs filtres, leurs possibilités de navigation et leurs exports, car ces fonctions déterminent le choix de la restitution cible.
  2. Les états planifiés doivent être reliés à leurs calendriers, formats de fichier et listes de diffusion, qui sont souvent plus critiques que leur mise en page.
  3. Les procédures de préparation doivent être analysées pour les calculs, jointures, règles de rejet et valeurs par défaut qu’elles appliquent avant le reporting.
  4. Les contenus embarqués dans une application doivent être recensés avec leurs mécanismes d’authentification et les paramètres transmis par l’application appelante.

Cette segmentation révèle les zones qui peuvent être arrêtées et celles qui doivent être reprises. Sur un parc de 400 objets, 180 rapports inactifs sur douze mois ne signifient pas automatiquement que 180 objets sont supprimables. Il faut vérifier les exécutions planifiées et les usages indirects. En revanche, si l’absence de consultation, d’exécution et de propriétaire est confirmée, la migration de ces objets n’a pas de justification opérationnelle.

Le traitement des rapports fantômes a un effet direct sur la charge, sans constituer une promesse d’économie. Un objet supprimé avant la construction cible évite d’alourdir la recette et la maintenance future. Il faut toutefois conserver l’export de l’inventaire, le résultat de validation métier et la date de décision. Sans cette trace, un rapport demandé six mois après bascule devient un incident impossible à arbitrer.

Pourquoi les écarts de chiffres sont prévisibles

Les écarts entre une restitution WebFOCUS et sa cible sont normaux tant qu’ils sont repérés et expliqués. Une date peut être tronquée à minuit dans un outil et conservée avec son heure dans un autre. Une jointure peut éliminer les lignes sans correspondance. Un filtre de statut peut être inscrit dans une procédure FEX au lieu d’être visible dans le rapport. Ces différences changent les totaux.

La recette doit donc partir d’un jeu de contrôle fixé dans le temps. Il faut retenir une période close, extraire les résultats anciens, documenter les paramètres appliqués et comparer les détails avant les agrégats. Un écart de 0,4 % sur le chiffre d’affaires ne se traite pas en demandant aux équipes de l’accepter. Il faut isoler les lignes concernées, identifier la règle en cause puis décider si la cible reproduit, corrige ou abandonne cette règle.

La tolérance dépend de l’indicateur. Un nombre de lignes ou un montant de facture appelle souvent une égalité stricte. Une mesure issue d’arrondis, de fuseaux horaires ou de calendriers différents peut nécessiter une tolérance écrite. La direction financière doit valider ce cadre avant la bascule, pas après la découverte d’un écart.

Un double run est pertinent pour les restitutions de pilotage dont la fréquence est mensuelle ou hebdomadaire. Les deux plateformes produisent alors les mêmes indicateurs pendant une période définie. Cette méthode ne démontre pas une identité abstraite entre les systèmes. Elle rend les écarts observables et donne le temps de qualifier les règles encore enfouies.

La migration d’un parc WebFOCUS commence donc par le tri des usages et par la mise sous preuve des règles de calcul. Sans cet inventaire, le choix d’une cible devient une discussion d’outils alors que le problème est d’abord un problème de périmètre.

Quelle décision prendre en 2026 pour une plateforme décisionnelle WebFOCUS

Le rachat d’Information Builders par TIBCO appartient désormais à l’historique du produit, mais il reste utile pour comprendre les environnements encore en place. La décision actuelle ne porte pas sur l’annonce de 2020. Elle porte sur la capacité de votre organisation à maintenir, faire évoluer ou remplacer les usages réels de WebFOCUS sans perdre les règles intégrées dans les procédures et le reporting planifié.

Le premier document à demander est la documentation de maintenance correspondant exactement à votre version. Les portails de support éditeur évoluent avec les offres et les droits de souscription. Une mention générique de WebFOCUS ne suffit pas. Il faut relever le numéro de version du serveur, des composants de reporting, des connecteurs et, lorsque c’est applicable, des outils de développement utilisés par les équipes.

La documentation publique consultée pour cet article ne donne pas une échéance unique applicable à tous les parcs WebFOCUS. Les calendriers dépendent de la version et du contrat souscrit. Cette absence de date universelle ne doit pas être comblée par une estimation. Il faut obtenir la note de maintenance rattachée à votre référence produit et l’archiver dans le dossier d’arbitrage.

Les situations dans lesquelles la migration ne vaut pas sa charge

Une migration ne se justifie pas uniquement par l’âge apparent d’une plateforme. Si le parc est restreint, stable, documenté, sous maintenance et composé de rapports encore utiles, une mise à niveau ou une conservation temporaire peut être plus défendable qu’un programme de reprise. Cette position s’inverse si les compétences disparaissent, si les versions ne sont plus couvertes, si les flux sont fragiles ou si les besoins de restitution ne peuvent plus être satisfaits.

Sur un parc de moins de 100 rapports, avec 50 % d’objets confirmés inactifs sur douze mois et peu de procédures complexes, la reconstruction des 50 rapports nécessaires mérite d’être comparée à une reprise exhaustive. Le résultat dépend du nombre de planifications, des droits et des écarts de données. À l’inverse, un parc de 300 à 500 restitutions actives, avec des règles FOCUS non documentées, justifie d’abord une phase de rétroanalyse avant toute décision de reconstruction.

Il faut aussi isoler la question des licences de celle de la charge. Un coût de souscription cible ne dit rien du coût de recette, de reprise des droits ou de maintenance des modèles. Inversement, une cible moins chère à l’achat peut réclamer des développements additionnels pour produire des documents paginés ou des distributions programmées. Les deux calculs doivent être présentés séparément au comité de décision.

Les conditions commerciales et les clauses de support relèvent de votre direction des achats, de votre juriste et de votre interlocuteur éditeur. Le présent dossier s’arrête au périmètre décisionnel : inventaire, dépendances, reporting, intégration et réconciliation des chiffres.

Un protocole de vérification utilisable avant tout arbitrage

Avant de valider un budget ou une cible, vous pouvez engager une séquence courte de vérification documentaire. Elle ne remplace pas un chantier, mais elle évite de dimensionner un projet sur le nombre de dossiers visibles dans le portail.

  • Exportez les logs de consultation et d’exécution sur douze mois, en vérifiant que leur politique de rétention couvre les cycles annuels et trimestriels.
  • Recensez les procédures FEX, les synonymes, les sources, les planifications et les listes de diffusion associés à chaque restitution active.
  • Classez les objets selon leur usage, leur propriétaire, leur fréquence, leur criticité et la présence de règles de calcul non documentées.
  • Conservez un jeu de données clos pour la recette et définissez, avec les métiers, les écarts qui doivent être strictement nuls ou explicitement justifiés.
  • Demandez la note de maintenance correspondant à votre version exacte avant d’utiliser une échéance dans un dossier de calendrier ou de budget.

Cette méthode produit un arbitrage plus solide qu’une comparaison de catalogues. Elle permet également de décider qu’un objet ne doit pas être migré, ce qui est parfois la décision la plus rationnelle. Le sujet n’est pas de conserver chaque trace de l’historique, mais de conserver les restitutions, les flux et les règles dont l’organisation a encore besoin.

La page de référence TIBCO sur la clôture du rachat, consultée le 1er janvier 2026, confirme le point historique sans apporter de calendrier de support applicable à toutes les versions. Votre prochaine action doit donc être de rapprocher cette histoire produit de l’inventaire réel de votre serveur WebFOCUS et de sa documentation de maintenance.

Quand TIBCO a-t-il racheté Information Builders ?

TIBCO a annoncé son accord de rachat le 22 octobre 2020 et a annoncé la finalisation de l’opération le 7 janvier 2021. Le communiqué officiel de clôture indique que celle-ci est intervenue après la clôture de l’exercice 2020 d’Information Builders, le 31 décembre 2020.

WebFOCUS appartient-il à l’historique d’Information Builders ?

Oui. WebFOCUS est la plateforme de reporting et d’analyse associée à Information Builders, ensuite renommé ibi. Son héritage comprend également FOCUS, environnement historique de requête et de restitution.

Le rachat par TIBCO impose-t-il une migration WebFOCUS ?

Non. Le rachat ne constitue pas, à lui seul, un motif de migration. La décision dépend de votre version exacte, de la couverture de maintenance, des compétences disponibles, de la criticité des flux et du volume de règles métier à reprendre.

Pourquoi un inventaire WebFOCUS doit-il couvrir douze mois ?

Cette durée permet d’identifier les rapports mensuels, trimestriels et annuels. Une analyse fondée sur quelques semaines ou sur quatre-vingt-dix jours risque d’écarter des états programmés qui ne sont pas consultés dans le portail mais restent nécessaires aux opérations.