La plateforme SAP BI 4 reste exploitable après la fin de maintenance principale, mais le périmètre de support technique se réduit fortement. Pour BI 4.3, la date qui engage votre calendrier est le 31 décembre 2026. Après cette échéance, les correctifs et les Service Packs ne suivent plus le cycle standard.
En bref.
- La version SAP BusinessObjects BI 4.3 reste sous maintenance principale jusqu’au 31 décembre 2026 selon les informations de maintenance SAP consultées en 2026.
- La version BI 4.2 a quitté la maintenance principale le 31 décembre 2022 et son support prioritaire s’est terminé le 31 décembre 2024.
- Le dernier niveau de mise à jour BI 4.3 est le Service Pack 5, dont la période de maintenance suit l’échéance de la version 4.3.
- Les versions SAP BI ne se pilotent pas seulement avec la date de la plateforme SAP : les systèmes d’exploitation, Java, les pilotes de base de données et les navigateurs peuvent bloquer l’exploitation avant cette date.
- Le passage vers BI 2025, puis vers les versions annoncées BI 2027 et BI 2029, doit être précédé d’un inventaire des rapports Web Intelligence, univers, droits et dépendances techniques.
Ce contenu s’adresse aux responsables BI, administrateurs BusinessObjects et chefs de projet qui maintiennent une plateforme SAP on-premise. Il traite de la gestion des versions, des échéances et de la préparation d’une mise à jour ; il ne couvre pas la négociation des contrats SAP ni l’architecture cloud au-delà des informations publiées par l’éditeur.
Quel est le calendrier de maintenance de SAP BI 4 en 2026 ?
Le calendrier de maintenance de SAP BI 4 doit être lu comme un calendrier de réduction progressive du support technique, et non comme une date d’arrêt automatique de vos serveurs. Une plateforme SAP BusinessObjects installée en BI 4.3 continuera à démarrer après le 31 décembre 2026. Vos univers, vos rapports Web Intelligence et vos instances planifiées ne cessent pas spontanément de fonctionner à minuit. Le problème apparaît lorsqu’un incident de production survient ou qu’une dépendance technique évolue.
La première échéance est la fin de la maintenance principale, parfois appelée maintenance mainstream. SAP ne livre alors plus le même rythme de correctifs, de Support Packs et d’améliorations fonctionnelles. La documentation de maintenance de SAP doit rester votre référence, car l’éditeur modifie parfois son calendrier ou précise le périmètre d’une extension. La page stratégie de maintenance SAP, consultée en 2026, décrit ce fonctionnement général et renvoie aux informations produit détaillées accessibles via SAP for Me et la Product Availability Matrix.
Pour SAP BI 4.3, la date communiquée dans les éléments de maintenance disponibles est le 31 décembre 2026 pour la maintenance principale. La phase de support prioritaire ou de maintenance spécifique client court ensuite jusqu’au 31 décembre 2027. Cette seconde période ne doit pas être assimilée à une année supplémentaire de maintenance normale. Elle vise les incidents de gravité maximale qui affectent la production, sans garantir de nouveaux correctifs, de hotfixes génériques ou de fonctionnalités.
Le calendrier est plus contraignant pour SAP BI 4.2. La maintenance principale s’est achevée le 31 décembre 2022, puis le support prioritaire le 31 décembre 2024. Un environnement BI 4.2 maintenu en 2026 peut donc encore servir des rapports, mais il n’est plus dans un cycle de support éditeur comparable à celui de BI 4.3 SP5. Cette distinction compte lors d’un audit de sécurité, lors du renouvellement d’un système d’exploitation ou lorsqu’un incident touche le CMS, le serveur Web Intelligence Processing Server ou le dépôt d’audit.
La maintenance spécifique client ne remplace pas un cycle de correctifs
La confusion vient souvent du vocabulaire. Une maintenance spécifique client laisse entendre qu’un support demeure, ce qui est exact dans un périmètre restreint. Elle ne signifie pas que SAP publiera une correction pour une incompatibilité avec un navigateur récent, une base de données mise à niveau ou un composant Java devenu obsolète. Le traitement porte d’abord sur les incidents de priorité maximale, ceux qui empêchent réellement une activité de production.
Une équipe BI doit donc classer les échéances selon leur effet opérationnel. La fin de maintenance principale est celle qui impose le budget, l’inventaire et la planification maintenance. La fin du support prioritaire est celle qui expose le socle à une absence de recours en cas de panne majeure. Entre les deux, le projet peut encore avancer, mais la marge de manœuvre se réduit à chaque changement imposé par l’infrastructure.
La lecture des versions BusinessObjects encore prises en charge permet de relier cette date générale au niveau exact de votre parc. Une décision prise uniquement sur le libellé « BI 4.3 » est insuffisante : il faut identifier le Support Pack, la base CMS, le système d’exploitation, le navigateur utilisé pour le BI reporting et les connecteurs de données concernés.
Quelles versions SAP BI sont encore concernées par les échéances éditeur ?
Les versions SAP BI ne doivent pas être mises sur le même plan. BI 4.2 et BI 4.3 sont deux générations proches pour l’utilisateur qui ouvre un rapport Web Intelligence, mais elles ne portent pas le même niveau de support technique ni la même fenêtre de mise à jour. SAP BI 4.2 est hors du cycle annoncé de support prioritaire depuis la fin de 2024. BI 4.3 reste la base on-premise suivie jusqu’à la fin de 2026, sous réserve de rester sur le dernier Service Pack disponible.
SAP a également fait évoluer sa nomenclature avec SAP BusinessObjects BI 2025. Cette version a été communiquée en 2025 comme une voie on-premise pour les organisations qui ne basculent pas leur BI reporting vers SAP Analytics Cloud. Les informations 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 aussi annoncé BI 2027, attendue au premier trimestre 2027, puis BI 2029 deux ans plus tard. Ces dates doivent être revérifiées dans la Product Availability Matrix avant validation d’un budget pluriannuel.
| Version de la plateforme SAP | Fin de maintenance principale | Fin de support ou correctifs annoncés | Lecture pour votre planification |
|---|---|---|---|
| SAP BusinessObjects BI 4.2 | 31 décembre 2022 | 31 décembre 2024 pour le support prioritaire | Sortie de maintenance déjà effective en 2026 |
| SAP BusinessObjects BI 4.3 | 31 décembre 2026 | 31 décembre 2027 pour le support prioritaire | Dernière fenêtre pour préparer une montée de version |
| SAP BusinessObjects BI 2025 | Quatrième trimestre 2027 | Quatrième trimestre 2028 pour les correctifs de sécurité annoncés | Cible on-premise à examiner pour les parcs conservés chez SAP |
| SAP BusinessObjects BI 2027 | Quatrième trimestre 2029 | Quatrième trimestre 2030 pour les correctifs de sécurité annoncés | Version annoncée, à confirmer dans la PAM lors de sa disponibilité |
| SAP BusinessObjects BI 2029 | Quatrième trimestre 2031 | Quatrième trimestre 2032 pour les correctifs de sécurité annoncés | Horizon long, non disponible à la date de consultation |
Ce tableau croise les versions, le calendrier de maintenance et le niveau de risque de planification. Les dates BI 4.2 et BI 4.3 proviennent des informations de maintenance SAP et des ressources BI recensées par SAP, consultées en 2026 via le centre de ressources SAP BusinessObjects Business Intelligence. Les échéances annoncées pour BI 2025, BI 2027 et BI 2029 doivent rester marquées comme prévisionnelles tant que la Product Availability Matrix ne les confirme pas pour votre contrat et votre paysage technique.
La cible ne doit pas être choisie à partir de la seule date de fin de support
Rester on-premise peut justifier une trajectoire vers BI 2025. Ce choix est cohérent si le parc contient plusieurs centaines de rapports Web Intelligence, des univers UNV ou UNX très utilisés, des publications complexes et des règles de sécurité déjà maîtrisées. Il ne devient pas automatiquement moins coûteux qu’une reconstruction sur une autre cible. Les droits, les objets d’univers, les formats d’export et les habitudes de diffusion peuvent représenter une part importante de la charge.
À l’inverse, un parc réduit, peu consulté et composé de rapports peu complexes ne justifie pas toujours une reprise complète dans une nouvelle version de Business Intelligence. Sous cent rapports, dont une part significative n’a aucun usage vérifiable sur douze mois, la reconstruction sélective mérite d’être chiffrée face à la migration. Au-delà de trois cents rapports avec des règles de gestion non documentées, la reprise contrôlée devient souvent plus prudente, parce que les filtres cachés dans les univers et les contextes de requête coûtent plus cher à redécouvrir qu’à transporter.
Le prochain travail ne consiste donc pas à réserver une fenêtre technique. Il consiste à déterminer quel niveau de Service Pack est réellement installé sur chaque environnement.
Pourquoi le Service Pack détermine-t-il le support technique réel ?
Un inventaire indiquant seulement « SAP BI 4.3 » ne permet pas de décider. Dans SAP BusinessObjects, le Service Pack est une information de gestion des versions à part entière. SAP concentre le support sur les niveaux les plus récents. Un serveur BI 4.3 SP0 ou SP2 n’offre pas le même niveau de correction qu’un serveur BI 4.3 SP5, même si l’écran de connexion affiche la même famille de produit.
Les dates de fin de vie des Service Packs illustrent ce mécanisme. Pour BI 4.2, SP2 était déjà arrivé à son terme estimé en septembre 2017, SP3 en février 2018, SP4 en novembre 2018, SP5 en juin 2019, SP6 en décembre 2019, SP7 en septembre 2020, SP8 au troisième trimestre 2021 et SP9 en décembre 2022. Le prolongement de support prioritaire de SP9 suivait la version 4.2 jusqu’en décembre 2024. En 2026, aucune de ces branches ne doit donc être présentée comme un niveau maintenu.
Pour BI 4.3, la succession est plus récente. SP0 avait une échéance estimée en juin 2021, SP1 au deuxième trimestre 2022, SP2 au deuxième trimestre 2023, SP3 au deuxième trimestre 2024, SP4 au deuxième trimestre 2025 et SP5 au quatrième trimestre 2026. La documentation SAP indique que BI 4.3 SP5 constitue le dernier Service Pack de cette ligne. Les éventuels correctifs publiés avant la fin de maintenance restent donc à apprécier au regard de ce niveau précis.
Un rapport Web Intelligence peut dépendre d’un composant hors support
Le risque ne se limite pas au serveur BusinessObjects. Les anciennes configurations reposaient sur des composants de navigateur, des versions de Java ou des mécanismes de visualisation qui ne sont plus pris en charge par les navigateurs actuels. Adobe Flash et les anciens plug-ins Java ont disparu des usages standards. Une organisation qui conserve une ancienne version de SAP BI peut alors constater qu’un utilisateur ne peut plus créer ou modifier un document Webi depuis son poste, alors même que le rapport planifié continue à être exécuté sur le serveur.
Le passage au visualiseur DHTML dans les versions plus récentes a réduit cette dépendance, mais il ne corrige pas à lui seul les incompatibilités de poste. Les extensions de navigateur, les politiques de sécurité, les certificats internes et les versions de Java utilisées par les outils d’administration doivent être recensés. Un test réalisé uniquement avec un compte administrateur ne suffit pas. Les utilisateurs métier exploitent parfois des fonctions d’export, de saisie ou de planification qui ne sont pas couvertes par ce premier test.
La même contrainte existe côté base de données. Windows Server 2008 R2 SP1 a quitté le support étendu Microsoft le 14 janvier 2020. SQL Server 2008 R2 SP3, Oracle 10.2, Oracle 11.1 et Oracle 11.2 ont également quitté leurs cycles standards depuis plusieurs années. Ces échéances ne prouvent pas qu’un CMS ne fonctionne plus, mais elles montrent que la plateforme SAP peut être coincée entre une infrastructure ancienne non soutenue et une infrastructure récente non certifiée pour son niveau de BI.
La vérification des dépendances entre BusinessObjects et l’écosystème SAP doit donc être faite avant toute mise à jour d’infrastructure. La Product Availability Matrix de SAP reste le point de contrôle pour les systèmes d’exploitation, bases de données, versions Java et chemins d’upgrade. Cette vérification exige souvent un accès SAP authentifié ; aucune capture d’environnement n’a été utilisée ici.
Un Service Pack non actualisé n’est pas un détail de patching : il peut imposer une trajectoire de migration entière lorsque l’infrastructure sous-jacente doit évoluer.
Comment bâtir une planification maintenance avant la fin de SAP BI 4.3 ?
La planification maintenance doit démarrer par un relevé factuel et non par la réservation d’un projet de migration. Il faut d’abord extraire la version exacte du CMS, le Support Pack, les Patch Levels, les serveurs actifs, les bases utilisées par le référentiel et l’audit, ainsi que les systèmes d’exploitation. Ce relevé doit être complété par les univers, les connexions, les documents Web Intelligence, Crystal Reports, publications, profils de sécurité et destinations de diffusion.
Le second relevé porte sur l’usage. Les logs d’audit sur douze mois sont préférables à une liste des documents présents dans le Central Management Console. Un rapport présent dans un dossier financier n’est pas nécessairement consulté. À l’inverse, un rapport trimestriel peut ne pas apparaître si le dépôt d’audit ne conserve que quatre-vingt-dix jours. La durée de conservation doit être vérifiée avant de décider qu’un document est abandonné.
Sur un parc de 240 rapports, une estimation de reprise peut être construite sans masquer les hypothèses. Si 60 % des documents sont des Webi simples, soit 144 rapports à deux heures de reprise unitaire, la première charge atteint 288 heures. Si les 96 autres documents sont complexes, avec variables, sous-requêtes, ruptures, plusieurs contextes d’univers ou publications, un ratio de six heures représente 576 heures. La reprise des rapports seule se situe donc à 864 heures.
Cette estimation exclut la recette métier, la reprise des droits, les corrections de données, la formation, les procédures d’exploitation et les retours après bascule. Avec une provision de recette comprise entre 30 % et 50 % de la charge de reprise selon le nombre de domaines fonctionnels, le chantier atteint une fourchette de 1 123 à 1 296 heures avant conduite du changement. Ces ratios constituent une méthode de cadrage, pas un tarif ni un engagement. Un rapport de dix pages avec un univers stable peut demander moins de travail qu’un rapport de deux pages utilisant des conditions d’objet et des filtres masqués.
Les contrôles à effectuer avant tout arbitrage
- Relevez la version SAP BI 4, le Service Pack et le Patch Level de chaque environnement, y compris recette et préproduction.
- Exportez les journaux d’audit sur douze mois et documentez leur durée réelle de rétention.
- Classez les rapports selon leur fréquence de consultation, leur complexité technique et leur importance métier.
- Identifiez les univers UNV et UNX, les connexions, les contextes, les listes de valeurs et les objets contenant des règles de gestion.
- Recensez les dépendances de la plateforme SAP avec Windows, Linux, Java, pilotes de base de données, navigateurs et certificats.
Cette séquence évite de chiffrer deux fois les mêmes objets et de découvrir trop tard les rapports planifiés qui ne sont jamais ouverts dans le portail. Elle prépare aussi la comparaison entre une montée de version BusinessObjects et un changement de cible. Lorsqu’une alternative est étudiée, le calcul de charge d’une migration BusinessObjects vers Power BI doit rester séparé du coût des licences. Mélanger les jours de reprise et les abonnements annuels produit des dossiers budgétaires impossibles à vérifier.
La bonne échéance n’est pas celle où le serveur devient instable. C’est celle à laquelle le temps restant ne permet plus de terminer l’inventaire, la recette et la bascule avant la fin du support technique.
Comment sécuriser la mise à jour sans promettre des chiffres identiques ?
Une mise à jour SAP BI 4.3 ou une migration vers BI 2025 ne doit jamais être validée sur la seule ouverture des rapports. Un Webi peut s’afficher et produire pourtant un montant différent de l’ancien environnement. Les causes sont souvent modestes en apparence : un objet d’univers modifié, une condition de sécurité appliquée différemment, une liste de valeurs rafraîchie, un contexte de requête non repris ou une base de données dont les paramètres ont évolué.
La documentation de mise à niveau SAP précise que le passage vers BI 4.3 implique un nouveau déploiement, puis une copie du contenu et des données système provenant de l’environnement existant. Cette mécanique explique pourquoi la recette ne se limite pas à un test de connexion. Les objets techniques sont copiés ou adaptés, mais les résultats doivent être rapprochés sur des périodes et filtres strictement identiques. Le guide de mise à niveau publié par SAP, consultable depuis les ressources produit, reste la base documentaire à confronter avec la version réellement installée.
Le protocole doit partir d’un échantillon représentatif. Il faut sélectionner des rapports par domaine, volumétrie, niveau de confidentialité et complexité. Un rapport de ventes mensuelles, un rapport de stock, un document de marge avec variables Webi et une publication avec destinataires dynamiques ne testent pas les mêmes mécanismes. Chaque comparaison doit conserver la date d’extraction, les invites saisies, le périmètre de données et le résultat attendu.
Un écart peut être acceptable lorsqu’il est expliqué et validé par le métier. Un écart de 0,4 % sur le chiffre d’affaires ne se traite pas comme une tolérance abstraite. Il faut déterminer si l’écart provient d’une ligne chargée tardivement, d’un statut client filtré dans une condition d’objet, d’un changement de règle de gestion ou d’une erreur de reprise. Sans cette origine, le chiffre reste contestable et la bascule reste fragile.
Le double run protège la décision de bascule
Le double run consiste à exécuter, pendant une période définie, les rapports critiques dans l’ancien et le nouveau socle. Il ne garantit pas une identité automatique des résultats. Il donne le temps de mesurer les écarts, de les expliquer et d’obtenir leur acceptation. Pour les tableaux de bord financiers, un cycle de clôture complet est souvent plus utile qu’une semaine de tests techniques, car les corrections manuelles et les chargements tardifs apparaissent alors réellement.
Les rapports ayant franchi les critères de recette doivent être tracés avec leur version d’univers, la date de validation, le validateur métier et les écarts résiduels acceptés. Les documents non validés restent explicitement hors bascule. Cette discipline évite qu’un rapport ancien, rarement ouvert mais utilisé lors d’une clôture annuelle, soit découvert après l’arrêt de l’ancienne plateforme.
Lorsque la cible n’est plus BusinessObjects, les rapports paginés doivent recevoir un traitement distinct des tableaux de bord interactifs. La reprise d’un Webi vers un rapport paginé Power BI montre pourquoi la pagination, les ruptures, les exports et la diffusion doivent être testés séparément du modèle sémantique. Une conversion de présentation ne reconstitue pas automatiquement les règles contenues dans un univers.
Avant de fixer la date de bascule, sortez les logs d’audit, vérifiez leur rétention et sélectionnez les rapports qui devront passer en double run. Toute la crédibilité du calendrier de maintenance repose sur ce périmètre vérifiable.
Quelle est la date de fin de maintenance de SAP BI 4.3 ?
La maintenance principale de SAP BusinessObjects BI 4.3 est annoncée jusqu’au 31 décembre 2026. Un support prioritaire ou spécifique client est ensuite indiqué jusqu’au 31 décembre 2027, avec un périmètre plus réduit.
SAP BI 4.2 est-il encore supporté en 2026 ?
Non. La maintenance principale de BI 4.2 s’est arrêtée le 31 décembre 2022 et le support prioritaire a pris fin le 31 décembre 2024. Une plateforme peut encore fonctionner, mais elle ne se situe plus dans le cycle annoncé de support SAP.
Pourquoi vérifier le Service Pack de SAP BusinessObjects ?
SAP concentre ses correctifs sur les niveaux les plus récents. BI 4.3 SP5 est le dernier Service Pack de la ligne BI 4.3 ; un environnement sur un SP plus ancien peut être exposé à des correctifs et compatibilités moins favorables.
La fin de maintenance arrête-t-elle automatiquement les rapports Web Intelligence ?
Non. Les rapports peuvent continuer à fonctionner, mais les correctifs, les réponses aux incidents et la compatibilité avec les composants tiers ne sont plus assurés au même niveau. Le risque apparaît surtout lors d’un incident ou d’une évolution de l’infrastructure.
Le dossier complet Échéances éditeurs : les fins de support à surveiller
