La version 4.2 de SAP BusinessObjects a quitté le support prioritaire fin 2024 et approche de sa fin de support globale. La version 4.3 reste la trajectoire de maintenance SAP à examiner avant toute décision de remplacement. Votre calendrier dépend moins du numéro de version que des correctifs disponibles, des composants réellement utilisés et de la capacité à refaire une recette complète.
En bref
- La version 4.2 ne doit plus être considérée comme une base durable pour un parc décisionnel exposé à des audits de sécurité ou à des incidents éditeur.
- La version 4.3 prolonge la capacité à maintenir Web Intelligence, les univers et les outils clients, mais elle ne dispense pas d’un inventaire détaillé du parc.
- Une mise à jour BusinessObjects n’est pas une opération serveur isolée, car les rapports, les droits, les documents Crystal et les SDK peuvent porter des dépendances anciennes.
- Le calendrier de support doit être rapproché de vos journaux d’usage sur douze mois, faute de quoi vous financez la reprise de contenus qui ne servent plus.
Ce dossier vise les responsables BI SAP qui exploitent SAP BusinessObjects en environnement d’entreprise et doivent arbitrer entre maintien, passage en version 4.3 ou sortie progressive du socle. Il ne traite pas des clauses contractuelles SAP, de la sécurité réseau ou de la protection des données personnelles, qui relèvent de vos équipes compétentes.
Quelle fin de support concerne réellement SAP BusinessObjects 4.2 et 4.3
La première erreur consiste à confondre fin de maintenance prioritaire, fin de maintenance standard et indisponibilité immédiate du produit. Une plateforme BI SAP ne s’arrête pas mécaniquement le lendemain d’une échéance. En revanche, votre capacité à obtenir un correctif, un contournement validé ou une réponse du support technique SAP change selon la phase de maintenance applicable.
La note SAP 3263860 consacrée à la fin de vie de SAP BusinessObjects BI Platform 4.2, consultée le 12 mars 2026, rattache explicitement cette échéance à BI Platform 4.2 ainsi qu’aux outils clients, aux SDK et aux produits associés listés dans son périmètre. Elle vise notamment SAP BusinessObjects BI Platform 4.2, Information Platform Services 4.2, Live Office 4.2, Crystal Reports for Enterprise 4.2, Crystal Server 2016 et Crystal Reports 2016.
La fin du Priority-One Support de la version 4.2 est intervenue le 31 décembre 2024, d’après la note SAP citée. Cette date ne signifie pas que toutes les demandes cessent ce jour-là. Elle signifie que le cadre de traitement prioritaire dont bénéficiait la version a changé, ce qui doit être vérifié dans votre contrat et dans les conditions de maintenance alors actives.
Le calendrier publié par SAP distingue aussi les dates propres aux Support Packages. Un serveur BI Platform 4.2 installé depuis longtemps peut donc se trouver dans une situation moins favorable que celle suggérée par le seul numéro de version. Le support d’un Support Package, d’un connecteur ou d’un client riche peut expirer avant celui du produit principal. La page SAP consacrée aux informations de maintenance, consultée le 12 mars 2026, renvoie vers les cycles de vie et les documents de maintenance à contrôler produit par produit.
| Produit ou composant | Point de contrôle | Situation à examiner en 2026 | Conséquence projet |
|---|---|---|---|
| SAP BusinessObjects BI Platform 4.2 | Fin du Priority-One Support | Échéance atteinte le 31 décembre 2024 selon la KBA 3263860 | Vérifier les droits de maintenance restants et les correctifs disponibles |
| SAP BusinessObjects BI Platform 4.3 | Version exacte et Support Package | Contrôler la stratégie de maintenance de la version installée dans SAP for Me | Planifier les patchs avant de lancer une migration fonctionnelle |
| Live Office 4.2 et Crystal Reports 2016 | Dépendance aux usages bureautiques et documentaires | Composants explicitement cités dans le périmètre de la KBA 3263860 | Ne pas limiter l’inventaire à Web Intelligence et aux univers |
| SDK et développements spécifiques | Compatibilité de code et API | Tests nécessaires après toute mise à jour BusinessObjects | Prévoir une recette technique distincte de la recette métier |
Ce tableau repose sur la KBA 3263860 et sur les pages de maintenance SAP, relevées le 12 mars 2026. Les dates et phases exactes visibles dans SAP for Me peuvent dépendre de votre droit d’accès et de votre contrat. Il faut donc conserver dans votre dossier la capture ou l’export de la page consultée, avec la date de lecture.
La version 4.3 ne doit pas être traitée comme une date de répit sans limite. SAP fait évoluer ses logiciels SAP par versions, Support Packages et correctifs. Votre parc peut comporter un CMS en version 4.3, des postes clients installés en 4.2 et un développement SDK plus ancien. Cette configuration est fréquente après plusieurs années d’exploitation. Elle rend le calendrier de support plus contraignant que la lecture d’une seule ligne de feuille de route.
Le bon périmètre comprend le serveur central, les Processing Servers, les Repository Servers, les univers UNV et UNX, les documents Web Intelligence, les rapports Crystal, les publications, les connexions, les authentifications et les outils clients. Un audit qui ne regarde que le portail BI ne voit pas les dépendances qui bloqueront une mise à niveau.
La question suivante porte donc sur l’effet réel de cette date pour votre exploitation, et non sur la seule possibilité de se connecter encore au Launchpad.
Que risque un parc BI SAP maintenu après la fin de support
Rester sur une version hors de la phase de maintenance la plus favorable ne provoque pas un arrêt automatique de vos rapports. Le risque apparaît lorsqu’un incident touche le CMS, une authentification, un connecteur de base de données ou une vulnérabilité corrigée sur une version plus récente. À ce moment-là, votre équipe ne choisit plus librement son calendrier. Elle réagit sous contrainte.
La maintenance SAP couvre des situations différentes selon les produits, la version et le niveau de support souscrit. La documentation de maintenance accessible via le portail SAP Support, consultée le 12 mars 2026, doit être rapprochée des notes propres à votre plateforme. Une mention de support au niveau du produit ne garantit pas que votre Support Package, votre pilote ou votre add-on bénéficie du même traitement.
Le premier risque porte sur les correctifs. Une vulnérabilité affectant la plateforme peut obliger à appliquer un patch, à modifier une configuration ou à monter de version. Quand le socle est ancien, l’écart entre la version en production et la version corrigée augmente. Les tests deviennent alors plus larges, notamment sur l’ouverture des documents, la planification, les publications et les droits.
Le deuxième risque concerne l’incident applicatif. Un échec de rafraîchissement Web Intelligence peut provenir de la base source, du driver, du serveur de traitement, de la sécurité ou de l’univers. Sans support technique SAP correspondant à votre configuration, le diagnostic prend plus de temps et le contournement peut être laissé à votre seule équipe. Ce n’est pas un problème théorique lorsque le rapport alimente une clôture mensuelle ou un suivi commercial.
Le troisième risque est documentaire. Les anciens univers concentrent souvent des filtres invisibles dans le rapport. Une condition d’objet peut limiter les clients actifs, exclure un statut ou imposer une date de début. Le Webi affiche alors un chiffre cohérent avec l’ancien pilotage, mais la règle est absente de la requête visible par l’utilisateur. Lors d’une mise à jour BusinessObjects ou d’une reconstruction, cette règle peut disparaître si personne ne l’a relevée.
La dette de support devient une dette de recette
Un parc hors support n’impose pas nécessairement une sortie immédiate. Sur moins de cinquante rapports actifs, avec une base de données stable et aucune dépendance SDK, une stabilisation temporaire peut coûter moins cher qu’un programme lancé sous pression. Cet arbitrage s’inverse si vous avez des incidents répétés, des composants Crystal historiques ou des règles de gestion non documentées.
La décision doit être chiffrée avec un périmètre clair. Comptez séparément le maintien de la plateforme, la préparation d’une montée vers la version 4.3, la reprise éventuelle des contenus et la recette. Mélanger ces lignes produit un budget illisible, car une évolution de version et une migration vers une autre cible ne portent pas les mêmes risques.
Un double run réduit le risque métier, mais il n’efface pas les écarts. Pendant une période définie, l’ancien rapport et sa version reprise sont exécutés sur la même date d’arrêté, les mêmes populations et des extractions figées. Un écart de 0,4 % peut être acceptable ou bloquant selon la mesure. Il faut donc fixer la tolérance avant la comparaison, puis documenter la cause de chaque écart supérieur au seuil.
Les causes se retrouvent souvent dans les jointures, les dates de validité, les arrondis, les hiérarchies, les filtres de sécurité ou la définition de la période. Une différence sur le chiffre d’affaires n’est pas une anomalie à effacer par une formule. C’est une règle à expliquer, à faire valider ou à corriger dans le modèle.
Ce travail doit commencer avant la panne ou la date de fin de support, parce qu’une recette menée après incident devient une opération de secours et non un arbitrage maîtrisé.
Quand choisir la version 4.3 plutôt qu’une sortie de SAP BusinessObjects
Le passage de la version 4.2 à la version 4.3 répond d’abord à un besoin de maintien de plateforme. Il ne répond pas automatiquement à un besoin de refonte du reporting. Cette distinction évite de financer deux projets avec un seul budget et une seule recette, ce qui masque les responsabilités et allonge les délais.
SAP présente la version 4.3 comme la ligne de continuité de SAP BusinessObjects pour les clients qui doivent achever leur mise à niveau après 4.2. La communication relative à l’upgrade vers SAP BusinessObjects BI 4.3, consultée le 12 mars 2026, rappelait que la version 4.2 arrivait à la fin de son support prioritaire fin 2024 et indiquait la disponibilité de BI 4.3 Support Package 3 dès décembre 2022. Cette publication ne remplace pas la vérification de votre niveau de patch dans SAP for Me.
La version 4.3 est pertinente lorsque les usages actuels restent liés à des univers, à des rapports Web Intelligence complexes, à des publications planifiées ou à des documents Crystal difficiles à remplacer à court terme. Elle permet de traiter l’obsolescence immédiate du serveur tout en conservant une organisation connue des utilisateurs. Elle ne rend pas les contenus plus faciles à maintenir par elle-même.
Une montée de version devient risquée lorsque le parc comporte des add-ons non documentés, des scripts utilisant le SDK, des authentifications anciennes ou des développements autour de l’OpenDocument. Dans ce cas, la plateforme peut démarrer, mais les usages périphériques échouent lors des tests. Il faut donc inventorier les appels techniques avant la bascule, pas après la mise en production.
La version 4.3 prolonge la plateforme, elle ne trie pas votre parc
Un rapport peu ouvert ne devient pas utile parce qu’il a été mis à jour. L’usage doit être mesuré sur douze mois glissants, afin d’inclure les états annuels, trimestriels et les publications rares. Les journaux d’audit doivent être contrôlés avant exploitation. Une rétention de quatre-vingt-dix jours ne permet pas de conclure sur l’inutilité d’un état annuel.
La méthode de tri peut s’appuyer sur quatre catégories. Les rapports consultés régulièrement et utilisés en clôture sont prioritaires. Les rapports à usage périodique doivent être confirmés avec leur propriétaire. Les documents jamais ouverts mais alimentant une publication nécessitent une analyse technique. Les contenus sans usage ni dépendance peuvent être archivés hors du périmètre de reprise.
- Un document Web Intelligence mensuel doit être testé avec son univers, ses variables, ses invites et ses droits de restitution.
- Un rapport Crystal peut dépendre d’une impression, d’une diffusion ou d’un format de sortie qui ne se voit pas dans le portail.
- Un univers UNV ou UNX doit être analysé objet par objet lorsque des conditions sont intégrées aux objets métier.
- Un développement SDK doit être isolé dans un lot technique, avec des tests distincts de ceux des utilisateurs métier.
Sur un parc de moins de cent rapports, dont la moitié n’est plus consultée sur douze mois, la reconstruction des contenus actifs peut coûter moins cher que la reprise systématique. Au-delà de trois cents rapports portant des règles métier anciennes et peu documentées, le raisonnement peut s’inverser. Reprendre provisoirement vers la version 4.3 préserve alors du temps pour identifier les règles enfouies avant toute sortie vers une autre cible.
Les options de cible doivent rester séparées de la décision de maintenance. Si vous envisagez le remplacement d’un parc Web Intelligence par des rapports paginés, la comparaison des objets, des paramètres et des sorties imprimées est détaillée dans cette méthode de reprise de Webi vers des rapports paginés. Le coût de licence d’une cible relève d’un autre dossier que la charge de remise à niveau de BI SAP.
La version 4.3 constitue donc un choix de stabilisation lorsqu’elle protège un patrimoine de règles encore utile. Elle n’est pas le bon choix si votre inventaire montre que le patrimoine a déjà largement disparu.
Comment préparer une mise à jour BusinessObjects sans perdre les règles d’univers
Une mise à jour BusinessObjects se prépare à partir d’un inventaire technique et d’un inventaire d’usage. Le premier recense les serveurs, les bases CMS et Audit, les univers, les connexions, les documents, les publications, les utilisateurs, les groupes et les SDK. Le second établit quels livrables sont réellement consultés, planifiés ou utilisés lors des clôtures.
La documentation SAP rappelle que les informations de maintenance BI incluent les dates de fin de vie des Support Packages et un guide de montée de version. Les ressources de maintenance publiées dans la page SAP Community sur la maintenance BusinessObjects, consultée le 12 mars 2026, renvoient notamment vers les dates de fin de support des releases BI et vers le BI Up-ports Guide. Le guide doit être lu avant de choisir le chemin entre votre version source et la version cible.
La préparation doit isoler les dépendances fonctionnelles. Un univers peut contenir des classes abandonnées par les utilisateurs, des objets encore employés par des documents cachés, des listes de valeurs, des contextes de requête et des conditions d’objet. Ces éléments ne sont pas interchangeables. Une condition placée dans l’objet et une condition placée dans le rapport n’ont pas le même effet lors de la reprise.
Le protocole de recette doit partir des chiffres, pas des écrans
La recette commence par une liste de cas de contrôle. Chaque cas fixe une date de référence, une population, des filtres, un niveau de détail, la source du chiffre et le responsable métier qui arbitrera l’écart. La comparaison visuelle d’un tableau ne suffit pas. Deux rapports peuvent avoir une apparence identique tout en additionnant des populations différentes.
Un protocole utilisable consiste à figer une extraction de l’ancien rapport, à rejouer les mêmes invites dans l’environnement cible, puis à comparer les mesures au niveau le plus bas disponible. Si le total diffère, la recherche doit descendre vers les lignes de détail, les jointures et les filtres. La méthode de recette et réconciliation lors d’une migration BI permet de structurer cette séquence sans promettre une identité automatique des résultats.
Une estimation de charge doit afficher son calcul. Prenons un parc de 240 rapports, dont 144 Webi courants, 72 Webi comportant plusieurs requêtes ou variables, et 24 documents complexes avec publication ou dépendance Crystal. En retenant 2 heures de préparation et reprise technique pour un rapport courant, 6 heures pour un rapport intermédiaire et 14 heures pour un document complexe, le travail de reprise représente 288 + 432 + 336 heures, soit 1 056 heures.
Ce chiffre exclut la recette métier, la reprise des droits, la correction des univers, les formations, les indisponibilités planifiées et la gestion de projet. Ces ratios sont une hypothèse de chiffrage pour un inventaire qualifié, non un tarif ni une promesse de délai. Si les règles sont peu documentées ou si les rapports comportent plusieurs sources, le ratio doit augmenter après échantillonnage de vingt à trente documents représentatifs.
La recette métier peut représenter un volume comparable à la reprise lorsqu’une centaine de rapports participent à des clôtures. Il faut donc obtenir l’engagement des propriétaires dès le planning initial. Une validation laissée à la dernière semaine transforme les écarts non expliqués en refus de bascule.
La qualité de ce travail dépend davantage de la traçabilité des règles que de la rapidité apparente de l’installation. La plateforme ne doit être mise à jour qu’après avoir fixé ce qui sera mesuré et par qui.
Quel calendrier de support retenir pour arbitrer entre maintien et migration
Un calendrier de support utilisable ne se limite pas à inscrire une date de fin de support dans un tableau. Il doit relier l’échéance éditeur à vos propres dates de gel, de clôture, de renouvellement de maintenance et de disponibilité métier. Un passage en version 4.3 réalisé pendant une clôture annuelle peut coûter plus cher qu’un maintien temporaire correctement encadré.
La KBA SAP 2144559 sur la stratégie de maintenance de SAP BusinessObjects BI Platform, consultée le 12 mars 2026, est la référence à vérifier pour les phases applicables aux générations BI Platform 4.x et aux produits plus récents. La consultation peut nécessiter un accès SAP for Me. Votre dossier de décision doit citer la version exacte, le Support Package, le niveau de patch et la date de consultation de cette source.
La lecture correcte du calendrier commence par le serveur. Elle se poursuit avec les postes utilisant le client riche, les flux de publication, Live Office, les documents Crystal et les connecteurs. Le produit nommé SAP BusinessObjects cache un ensemble de composants. Les décisions prises à partir du seul serveur CMS oublient souvent les postes finance utilisant encore un add-in ou un export historisé.
Trois trajectoires peuvent être défendues selon l’état du parc
La première trajectoire consiste à stabiliser la version 4.2 pendant une durée strictement bornée. Elle n’est défendable que si votre contrat de maintenance le permet, si aucun risque connu ne rend la situation intenable et si le parc fait déjà l’objet d’un audit. Cette trajectoire n’est pas une absence de décision. Elle suppose une date de sortie, un suivi des incidents et un gel des nouveaux développements.
La deuxième trajectoire consiste à préparer la mise à niveau vers la version 4.3, puis à conserver SAP BusinessObjects comme couche de restitution pendant plusieurs exercices. Elle correspond aux organisations qui possèdent beaucoup de rapports actifs, des univers avec des règles peu documentées ou des usages Crystal sensibles. Le budget doit séparer l’infrastructure, la compatibilité, les tests techniques et la recette fonctionnelle.
La troisième trajectoire organise une sortie progressive de BI SAP. Elle demande d’abord de classer les contenus entre arrêt, archivage, reprise à l’identique fonctionnelle et reconstruction. Elle échoue lorsque tous les rapports sont déclarés stratégiques sans preuve d’usage. Elle échoue aussi lorsque la cible est choisie avant d’avoir compris les univers et les calculs Web Intelligence.
Le coût d’une migration ne peut pas être déduit du calendrier de support. Le calendrier vous donne une contrainte de temps. La charge dépend du volume actif, de la complexité des documents, des univers, des droits et du niveau de recette exigé. Pour établir une fourchette qui sépare clairement reprise, recette et conduite de projet, vous pouvez rapprocher votre inventaire de ce chiffrage du coût de migration de BusinessObjects vers Power BI.
La cible ne doit pas être imposée par le seul impératif de fin de support. Une organisation ayant besoin de rapports paginés, de diffusions formelles et de restitutions réglementées n’évalue pas la même chose qu’un parc de tableaux Webi consultés de manière interactive. L’arbitrage entre les outils de restitution doit reprendre les usages recensés, pas les seules tendances du marché.
Aucun environnement SAP BusinessObjects 4.2 ou 4.3 n’a été ouvert pour ce dossier. Les éléments de maintenance SAP cités reposent sur les pages et notes éditeur consultées le 12 mars 2026. Avant d’engager un budget, exportez les informations de version depuis votre Central Management Console et rapprochez-les des échéances affichées dans votre accès SAP for Me.
La version 4.2 de SAP BusinessObjects fonctionne-t-elle encore après le 31 décembre 2024 ?
La plateforme peut continuer à fonctionner, mais la fin du Priority-One Support modifie le cadre de prise en charge. La KBA SAP 3263860, consultée le 12 mars 2026, doit être vérifiée avec votre contrat de maintenance et votre niveau de Support Package.
La version 4.3 permet-elle de conserver les univers et les rapports Web Intelligence ?
La version 4.3 est conçue comme une continuité de BI Platform 4.x. La compatibilité réelle dépend toutefois de votre version source, des univers, des SDK, des extensions et du chemin de montée de version validé dans la documentation SAP.
Faut-il migrer tous les rapports avant une mise à jour BusinessObjects ?
Non. Commencez par mesurer les consultations sur douze mois et identifiez les publications, les rapports de clôture et les dépendances techniques. Les contenus non utilisés et sans dépendance peuvent être archivés après validation de leur propriétaire.
Comment vérifier le calendrier de support de mon installation BI SAP ?
Relevez la version exacte, le Support Package et le patch depuis votre environnement, puis consultez les KBA 3263860 et 2144559 ainsi que SAP for Me. Conservez la date de consultation et le périmètre de maintenance associé à votre contrat.
Le dossier complet Échéances éditeurs : les fins de support à surveiller
