BI 4 désigne la génération 4.x de SAP BusinessObjects Business Intelligence, dont BI 4.3 est la dernière version de cette lignée. Au relevé effectué le 12 mars 2026, la maintenance standard de BI 4.3 court jusqu’au 31 décembre 2026, puis le support prioritaire jusqu’au 31 décembre 2027, sous réserve des conditions SAP applicables.
En bref
- BI 4 ne désigne pas un seul produit figé, mais une famille de versions SAP BusinessObjects, notamment BI 4.1, BI 4.2 et BI 4.3.
- La date qui doit piloter votre calendrier est la fin de maintenance standard, car elle arrête les évolutions et les correctifs réguliers.
- BI 4.2 a quitté son support prioritaire le 31 décembre 2024 ; un parc encore actif sur cette version porte déjà une contrainte de support.
- BI 4.3 reste maintenue jusqu’à fin 2026, mais le Service Pack installé et la compatibilité des composants tiers doivent être vérifiés séparément.
- BI 2025 constitue la trajectoire on-premise publiée par SAP pour prolonger l’usage de BusinessObjects sans basculer mécaniquement vers une offre SaaS.
Ce contenu s’adresse aux responsables BI, administrateurs SAP BusinessObjects et chefs de projet qui doivent documenter la durée de support d’une plateforme existante. Il traite des versions on-premise de SAP BusinessObjects ; les conditions contractuelles, la sécurité détaillée et les sujets de protection des données relèvent de vos équipes compétentes et de votre contrat SAP.
Que recouvre exactement BI 4 dans SAP BusinessObjects Business Intelligence ?
Dans un inventaire de socle décisionnel, l’expression BI 4 est souvent utilisée comme un raccourci. Elle désigne la famille SAP BusinessObjects Business Intelligence Platform 4.x, et non une version unique. Cette distinction change la réponse sur le support, la mise à jour possible et la compatibilité technique. Un serveur BI 4.1, un environnement BI 4.2 SP09 et une plateforme BI 4.3 SP05 relèvent tous de BI 4, mais ne portent ni les mêmes correctifs ni les mêmes échéances.
La génération BI 4 a regroupé plusieurs composants utilisés dans les parcs décisionnels : Web Intelligence, Crystal Reports, Information Design Tool, la Central Management Console, les univers UNV et UNX, les connexions relationnelles ou OLAP, ainsi que les services de planification et de diffusion. Le numéro majeur identifie la plateforme. Le numéro mineur précise la release. Le Support Package, ou SP, situe enfin le niveau de correction réellement installé.
La version serveur ne suffit pas pour qualifier votre parc
Un relevé fiable ne se limite donc pas à écrire « BusinessObjects BI 4 ». Il faut relever la version complète du CMS, le niveau de Support Package, les correctifs appliqués, les systèmes d’exploitation, les bases de données du référentiel et les pilotes utilisés. Un univers peut paraître intact alors que son pilote JDBC n’est plus pris en charge sur le serveur mis à jour. Le risque ne se voit pas dans le rapport Webi avant le premier incident de connexion.
SAP publie les compatibilités produit, plateforme et base de données dans sa Product Availability Matrix. Cette source doit être consultée avec vos références exactes de produit et de Support Package. Le relevé réalisé le 12 mars 2026 confirme que la matrice reste le point de contrôle primaire pour les composants supportés, plutôt qu’une date reprise dans une présentation de projet.
Un point revient régulièrement dans les audits : la version affichée dans la console d’administration ne recouvre pas toujours le niveau réel des postes clients. Les add-ons Office, les outils de conception et certains clients riches peuvent rester sur une release plus ancienne. Or la compatibilité entre le serveur BI 4.3 et ces composants ne se déduit pas du seul numéro du CMS. Elle doit être testée, surtout si les utilisateurs conçoivent encore des univers ou planifient des publications localement.
| Élément observé | Information à relever | Effet sur le support | Effet sur une mise à jour |
|---|---|---|---|
| Plateforme BI | BI 4.1, BI 4.2 ou BI 4.3 | Détermine l’échéance de maintenance de la release | Détermine les chemins de montée de version admis |
| Support Package | SP04, SP09, SP05 ou autre niveau exact | Le support actif porte habituellement sur les niveaux récents | Peut imposer une étape intermédiaire avant migration |
| Composant tiers | Système d’exploitation, SGBD, navigateur, pilote | Peut retirer la compatibilité avant la fin de BI 4 | Peut créer un chantier technique distinct |
| Contenu décisionnel | Univers UNV, UNX, Webi, Crystal, publications | Ne modifie pas la date SAP | Détermine la charge de recette et de reprise |
Ce tableau a été construit à partir du périmètre fonctionnel documenté par SAP et des contrôles nécessaires sur un parc BI 4 ; la matrice officielle doit être revue à chaque changement de Support Package. Un inventaire qui mélange version de plateforme et version de rapport produit une date de fin de vie inutilisable. La première décision consiste donc à qualifier précisément ce qui fonctionne derrière l’étiquette BI 4.
Jusqu’à quand SAP BusinessObjects BI 4.3 reste-t-il supporté ?
Au relevé effectué le 12 mars 2026 dans la documentation de maintenance SAP et dans la Product Availability Matrix, SAP BusinessObjects BI 4.3 reste sous maintenance standard jusqu’au 31 décembre 2026. Cette date concerne la release BI 4.3. Elle ne signifie pas qu’un Support Package ancien recevra les mêmes corrections qu’un niveau plus récent, ni qu’un composant tiers sera encore compatible jusqu’à cette échéance.
Après cette date, les informations publiées pour BI 4.3 prévoient un support prioritaire jusqu’au 31 décembre 2027. La terminologie compte. Ce régime ne correspond pas à la maintenance standard : SAP limite alors le traitement aux incidents de priorité élevée et ne poursuit pas le même cycle de correctifs, de patches ou d’évolutions. Pour une DSI, ce n’est pas une année supplémentaire identique. C’est une période de sortie sous contrainte.
La fin de maintenance ne coupe pas votre plateforme le 1er janvier
Le serveur ne s’arrête pas automatiquement le lendemain de la fin de support. Les utilisateurs peuvent continuer à ouvrir leurs rapports, les planifications peuvent continuer à produire des instances et les univers restent techniquement présents. Le problème se déplace vers la capacité à résoudre un incident, à appliquer un correctif et à maintenir une compatibilité documentée avec l’infrastructure.
Cette différence est décisive lorsqu’une direction demande si elle peut « rester encore un an ». Rester sur BI 4.3 après décembre 2026 peut être un arbitrage défendable si le parc est stable, si les dépendances sont maîtrisées et si un calendrier de sortie est financé. Cet arbitrage devient fragile si votre système d’exploitation ou votre base de données sortent eux-mêmes de support avant la plateforme Business Intelligence.
La documentation SAP de stratégie de maintenance doit être lue avec la matrice produit, car les règles de couverture ne s’appliquent pas indistinctement à chaque combinaison technique. La page SAP Maintenance Strategy, consultée le 12 mars 2026, décrit les régimes de maintenance et leurs périmètres. Elle ne remplace pas la vérification de votre version, de votre contrat et de vos composants installés.
BI 4.2 illustre l’écart entre une plateforme encore utilisée et une plateforme encore supportée. La maintenance standard de BI 4.2 s’est achevée le 31 décembre 2022, puis le support prioritaire le 31 décembre 2024 selon les échéances publiées pour cette release. En 2026, un parc BI 4.2 ne doit donc plus être présenté comme un parc sous maintenance SAP courante. Il faut documenter les risques d’exploitation et la date réaliste de bascule ou de retrait.
Une précision mérite d’être conservée dans le dossier d’arbitrage : SAP a publié BI 2025 comme continuité on-premise de la gamme. Le passage de BI 4.3 à BI 2025 n’est pas une preuve de compatibilité automatique pour chaque univers, rapport ou extension. SAP documente le chemin d’upgrade dans sa note 3654924 sur la montée de version vers BI 2025 ou une release ultérieure. La lecture de cette note doit être complétée par une recette sur une copie du référentiel, pas par une hypothèse prise dans une feuille de route.
Votre échéance réelle est donc la plus proche entre la fin de support BI 4.3, la date de support de vos composants tiers et la date à laquelle votre capacité de recette devient insuffisante. C’est cette date rapprochée qui doit apparaître dans votre calendrier.
Pourquoi le Support Package BI 4.3 modifie-t-il la durée de support réelle ?
La confusion la plus coûteuse consiste à voir BI 4.3 comme un bloc homogène jusqu’à fin 2026. SAP maintient la release, mais le niveau de Support Package conditionne l’accès aux correctifs et la compatibilité opérationnelle. Un environnement BI 4.3 SP00 n’offre pas le même point de départ qu’un environnement BI 4.3 SP05, même si la Central Management Console affiche la même famille de version.
Les informations disponibles pour BI 4.3 placent la fin de cycle du SP00 en juin 2021, celle du SP01 au deuxième trimestre 2022, du SP02 au deuxième trimestre 2023, du SP03 au deuxième trimestre 2024, du SP04 au deuxième trimestre 2025 et du SP05 au quatrième trimestre 2026. Ces dates doivent être rapprochées de la documentation SAP active au moment de votre décision. Elles montrent surtout qu’un parc non mis à jour perd progressivement sa couverture avant la fin de la plateforme.
Un niveau de patch ancien transforme une date théorique en risque immédiat
Une équipe peut disposer d’une BI 4.3 officiellement maintenue tout en restant sur un SP qui ne reçoit plus le niveau de correction attendu. Le décalage crée une situation difficile à expliquer après un incident. Le contrat de support existe, mais la configuration installée n’est plus celle sur laquelle les correctifs les plus récents sont livrés ou validés.
La mise à jour d’un Support Package ne se traite pas comme une opération purement technique. Elle peut modifier des comportements sur les services Web Intelligence, l’authentification, les pilotes, l’export, les publications ou les connexions. Le plan de recette doit donc cibler les rapports réellement consultés, les publications critiques et les traitements planifiés. Migrer tous les objets sans mesure d’usage revient à financer la conservation d’un parc dont une part n’a peut-être plus de lecteur.
Sur un parc de 240 rapports, une première qualification peut distinguer 144 Webi à structure stable, 60 rapports avec variables, sous-requêtes ou contextes complexes, et 36 rapports obsolètes à confirmer. En utilisant un ratio de deux heures pour l’analyse et la recette d’un Webi stable, puis six heures pour un rapport complexe, le calcul donne 144 × 2 heures + 60 × 6 heures, soit 648 heures. Ce chiffrage exclut la préparation de l’environnement, la reprise des droits, les univers, les incidents et la formation. Il ne mesure donc pas le coût total d’une montée de version.
Le ratio est une hypothèse de cadrage, pas un tarif de marché. Il sert à rendre visible ce que la formule « appliquer un SP » masque habituellement. Si 36 rapports sont sans usage sur douze mois, leur exclusion de la recette représente 72 à 216 heures évitées selon leur complexité. Cette économie potentielle ne doit toutefois être retenue qu’après validation métier, notamment pour les rapports trimestriels ou annuels.
- Extrayez la version exacte du CMS et de chaque serveur BI 4.
- Contrôlez le Support Package et les patches installés sur les composants actifs.
- Recensez les connexions, pilotes et systèmes d’exploitation réellement utilisés.
- Analysez au moins douze mois de logs d’audit avant de définir le périmètre de recette.
- Faites valider les rapports à faible usage par leurs propriétaires fonctionnels.
Cette séquence rejoint le travail nécessaire lors d’un passage de BO vers Power BI, même si la cible et les règles de reprise changent. Dans les deux cas, la version visible ne suffit pas : les calculs, filtres, droits et dépendances doivent être examinés objet par objet.
Le bon indicateur n’est donc pas seulement « BI 4.3 est-elle supportée ? ». Il faut pouvoir répondre aussi : « quel SP est installé, quels rapports sont encore lus et quel périmètre doit être validé avant le prochain changement ? »
Quels composants tiers peuvent forcer une mise à jour avant la fin de vie de BI 4 ?
La fin de vie de BI 4 ne résume pas la durée de support de votre environnement. Une plateforme BusinessObjects dépend d’un système d’exploitation, d’une base de données de référentiel, de navigateurs, de pilotes, d’outils clients et parfois d’extensions anciennes. Chacun suit son propre calendrier. Le premier composant qui devient incompatible peut imposer une décision avant l’échéance SAP de la plateforme.
Les dépendances liées aux navigateurs ont marqué les anciennes générations BusinessObjects. L’arrêt des plugins historiques Java et Adobe Flash a rendu certains usages impraticables dans les navigateurs modernes. Pour les environnements encore dépendants d’anciens visualiseurs ou d’outils clients, le sujet n’est pas théorique : un utilisateur peut perdre la possibilité de créer ou de consulter un document dans son poste standardisé, alors que le serveur reste démarré.
La compatibilité doit être vérifiée dans les deux sens
Une mise à jour de Windows Server ou de SQL Server répond souvent à une exigence de sécurité ou de support infrastructure. Elle peut cependant rendre non supportée une version ancienne de BusinessObjects. L’inverse existe aussi : une plateforme BI ancienne peut exiger un pilote ou une version de base qui n’est plus admise par les standards d’infrastructure. Dans ce cas, différer la mise à jour BI revient à bloquer le cycle de maintenance d’un autre composant.
Les calendriers historiques montrent la vitesse de ce mécanisme. Windows Server 2008 R2 Service Pack 1 a terminé sa maintenance étendue le 14 janvier 2020 selon le cycle de vie Microsoft. SQL Server 2008 R2 Service Pack 3 a terminé son support étendu le 9 juillet 2019. Ces produits ne doivent pas être utilisés pour déterminer votre calendrier actuel, mais ils rappellent qu’un socle décisionnel peut devenir non supporté par accumulation de dépendances, sans changement visible dans les rapports.
Les dates actualisées des produits Microsoft doivent être vérifiées sur la page officielle du cycle de vie Microsoft, consultée le 12 mars 2026. SAP publie de son côté les systèmes et bases de données certifiés dans la Product Availability Matrix. Le rapprochement des deux sources fait partie du dossier de compatibilité. Une liste d’infrastructure sans versions précises ne permet pas de défendre une décision devant un comité.
Les bases de données demandent une attention particulière. Le CMS, l’Audit Data Store et les univers peuvent ne pas dépendre des mêmes connexions. Une équipe peut valider le démarrage du CMS après une évolution de SGBD et découvrir ensuite qu’une publication Webi planifiée échoue sur une connexion métier. Ce type d’incident est évitable si la recette couvre les chemins de consultation, de rafraîchissement, de planification et d’export, plutôt qu’un seul test de connexion.
Le SaaS entre aussi dans l’arbitrage, mais il ne résout pas automatiquement la compatibilité de vos contenus. Une cible SaaS peut réduire certaines dépendances d’infrastructure locales, tout en imposant la reprise des univers, des droits et des documents. La question de l’hébergement, du transfert de données ou des clauses contractuelles relève de votre DPO et de vos juristes ; le périmètre décisionnel s’arrête ici à la continuité des rapports et des règles de gestion.
Un registre de dépendances daté doit accompagner votre inventaire BI 4. Sans lui, la date du 31 décembre 2026 risque de devenir un faux confort alors que votre contrainte technique est déjà plus proche.
Comment préparer la sortie de BI 4.3 vers BI 2025 sans promettre des chiffres identiques ?
BI 2025 est la version on-premise présentée par SAP pour prendre le relais de BI 4.3. Les éléments de feuille de route disponibles indiquent une maintenance principale jusqu’au quatrième trimestre 2027 et des correctifs de sécurité jusqu’au quatrième trimestre 2028. SAP a également annoncé BI 2027 puis BI 2029, avec des échéances successives publiées dans ses communications de direction produit. Ces jalons doivent être recontrôlés dans la documentation SAP au moment où votre budget est arbitré, car une feuille de route n’est pas un plan de projet.
Le choix entre une mise à jour BI 4.3 vers BI 2025 et une migration vers une autre cible ne se décide pas sur le seul support. Il dépend du volume de contenus utiles, de la dette d’univers, du nombre de règles de gestion non documentées et de la capacité à conduire une recette. Sur un parc inférieur à cent rapports dont la moitié n’est plus consultée, une reconstruction ciblée peut coûter moins de charge qu’une reprise exhaustive. Au-delà de trois cents rapports avec des règles enfouies dans les objets d’univers, la conservation d’une partie du modèle existant peut redevenir rationnelle.
Le double run sert à expliquer les écarts, pas à les masquer
Une bascule ne doit pas promettre que le nouveau socle donnera des chiffres identiques à l’ancien dans tous les cas. Des écarts apparaissent fréquemment : filtre de statut posé dans une condition d’objet, différence de date de rafraîchissement, arrondi, jointure, sécurité ou hiérarchie. Le travail de recette consiste à quantifier ces écarts, à en identifier la règle et à obtenir l’acceptation métier sur les cas retenus.
Un protocole utile démarre par un jeu de rapports critiques, pas par tous les documents. Pour chacun, conservez la requête source, les filtres, le nombre de lignes, les agrégats et la date d’extraction. Comparez ensuite les résultats sur la même période de données. Une tolérance peut être nulle pour une balance financière et bornée pour un indicateur alimenté par des rafraîchissements distincts, à condition que l’origine de l’écart soit écrite et validée.
La définition des indicateurs mérite le même niveau de preuve. Un chiffre d’affaires, un stock ou une marge ne se résume pas à son libellé dans un tableau de bord. Le lien entre une mesure et sa règle de calcul doit être documenté dans un dictionnaire de données décisionnel. Cette discipline évite de découvrir après la bascule qu’un filtre historique était porté par une classe d’univers et non par le rapport Web Intelligence.
La trajectoire vers BI 2025 ne convient pas à tous les cas. Elle est cohérente lorsque l’organisation souhaite rester on-premise, préserver une part importante de ses usages BusinessObjects et réduire le risque de calendrier lié à la fin de maintenance de BI 4.3. Elle est moins pertinente si le parc est peu utilisé, si les univers sont devenus illisibles et si la majorité des rapports doit être redéfinie avec les métiers. Dans cette seconde situation, une reprise sélective peut être plus défendable qu’un upgrade complet.
Avant de lancer le chantier, extrayez douze mois de logs d’audit, relevez le Support Package réel, croisez les dates de support de la plateforme et des composants tiers, puis sélectionnez les vingt rapports qui portent vos décisions financières ou opérationnelles. Le calendrier de sortie de BI 4 se construira sur ces objets vérifiés, non sur le nombre total de documents stockés dans le référentiel.
BI 4 et BI 4.3 désignent-ils la même version ?
Non. BI 4 désigne la famille SAP BusinessObjects 4.x. BI 4.3 est une release précise de cette famille, avec ses propres dates de maintenance, ses Support Packages et ses règles de compatibilité.
BI 4.3 sera-t-elle encore supportée après le 31 décembre 2026 ?
La maintenance standard de BI 4.3 se termine le 31 décembre 2026. Les informations publiées indiquent un support prioritaire jusqu’au 31 décembre 2027, avec un périmètre plus limité. Vérifiez votre contrat et la Product Availability Matrix SAP avant tout arbitrage.
Peut-on rester sur BI 4.2 en 2026 ?
La plateforme peut continuer à fonctionner, mais BI 4.2 a terminé son support prioritaire le 31 décembre 2024. Un maintien doit donc être documenté comme un risque d’exploitation et non comme une situation sous maintenance courante.
Un Support Package ancien est-il couvert jusqu’à la fin de BI 4.3 ?
Pas nécessairement. La durée de support d’un Support Package est distincte de celle de la release BI 4.3. Relevez le SP exact installé et vérifiez les correctifs disponibles dans la documentation SAP.
BI 2025 impose-t-elle un passage au SaaS ?
Non. BI 2025 est annoncée comme une continuité on-premise de SAP BusinessObjects. Le choix d’une cible SaaS reste un arbitrage distinct, qui doit tenir compte des contenus à reprendre, des règles de gestion et de vos contraintes contractuelles.
Le dossier complet Échéances éditeurs : les fins de support à surveiller
