SAP BusinessObjects reste exploitable après une échéance de maintenance, mais cette situation retire progressivement les correctifs, l’assistance sur incident et la capacité à justifier le socle devant un audit. Pour un parc BI, la décision dépend moins du nombre de rapports que des composants réellement utilisés, de leur version exacte et de la documentation des univers.
- SAP BusinessObjects BI 4.2 a atteint sa fin de support le 31 décembre 2024, selon la communication SAP reprise dans la documentation communautaire de l’éditeur.
- La version BI 4.3 reste un palier de continuité pour les parcs qui dépendent encore de Web Intelligence, Crystal Reports ou de l’administration Central Management Console.
- BI 2025 modifie le périmètre de certains composants historiques, ce qui impose un inventaire avant toute mise à niveau ou migration.
- Un univers non documenté peut contenir des filtres de sécurité, des contextes ou des règles de calcul absents des rapports Web Intelligence visibles par les utilisateurs.
Ce contenu s’adresse aux responsables BI, DSI et chefs de projet qui administrent un socle SAP BusinessObjects on-premise. Il traite des composants, des versions et de la fin de support ; les clauses de contrat, les remises commerciales et les sujets de protection des données relèvent de vos équipes juridiques, achats et DPO.
Quels composants SAP BusinessObjects doivent être inventoriés avant toute décision
Un parc SAP BusinessObjects ne se résume pas à des rapports Web Intelligence. L’erreur la plus coûteuse consiste à compter les documents visibles dans les dossiers publics et à considérer le reste comme technique. Or, les règles qui expliquent un chiffre se trouvent souvent dans l’univers, dans une condition d’objet, dans un contexte de requête ou dans un rapport Crystal Reports exécuté par planification.
Le premier relevé porte donc sur les composants effectivement installés et utilisés. La Central Management Console, ou CMC, fournit une partie de la réponse. Les serveurs déclarés, les événements, les comptes techniques, les destinations de planification et les droits applicatifs y apparaissent. Elle ne suffit pas à expliquer l’usage métier. Les logs d’audit, lorsqu’ils sont conservés sur douze mois, permettent de distinguer un rapport mensuel d’un document abandonné.
Web Intelligence, univers et couche sémantique
Web Intelligence est fréquemment la partie la plus visible de SAP BusinessObjects. Les utilisateurs y construisent des requêtes, appliquent des filtres, créent des variables et distribuent des documents. Pourtant, le rapport ne porte pas toujours la règle métier la plus déterminante. Un filtre de statut client peut être placé au niveau d’une condition d’objet dans l’univers et non dans le document Webi. Il ne sera alors pas visible dans l’onglet des filtres du rapport.
Les univers UNV et UNX doivent être distingués. L’univers UNV relève de l’ancien outil Universe Designer. L’univers UNX est construit dans Information Design Tool et s’appuie sur une couche de fondation de données ainsi qu’une couche métier. Cette différence ne relève pas du vocabulaire. Elle conditionne la méthode de reprise, les possibilités de conversion et le temps nécessaire pour retrouver les jointures, les contextes et les objets calculés.
Un inventaire utile recense au minimum le nombre d’univers, leur type, leur date de dernière modification, leurs connexions, leurs objets les plus appelés et les rapports qui en dépendent. Il faut également isoler les objets contenant du SQL personnalisé. Un objet qui incorpore une expression propriétaire de base de données ne se transpose pas automatiquement vers un modèle sémantique cible.
Crystal Reports, planification et composants moins visibles
Crystal Reports reste présent dans de nombreux environnements pour les documents paginés, les états réglementaires internes, les factures ou les extractions de détail. Sa logique diffère de Web Intelligence. Les formules, les sous-rapports, les paramètres en cascade et les connexions directes doivent être analysés séparément. Reprendre un Crystal Reports comme un rapport de visualisation conduit souvent à perdre la mise en page, la logique de pagination ou le comportement d’impression.
La planification représente un second angle mort. Un document peu consulté dans l’interface peut produire chaque nuit un fichier CSV, un PDF ou un envoi par messagerie vers une boîte fonctionnelle. La CMC permet de recenser les instances, les horaires, les événements déclencheurs et les destinations. Ce relevé doit être rapproché des usages métier, car une planification encore active n’est pas une preuve que son contenu est lu.
La page SAP consacrée à la maintenance des produits SAP doit rester votre point de contrôle pour les informations de cycle de vie et de support. SAP renvoie également, pour les prochaines livraisons et les dates détaillées, vers SAP for Me avec authentification S-user. Le relevé doit donc être archivé avec la date de consultation et le numéro de version concerné.
| Composant SAP BusinessObjects | Objet à relever | Risque lors d’une migration | Vérification prioritaire |
|---|---|---|---|
| Web Intelligence | Documents, variables, requêtes, filtres et fournisseurs de données | Écart de calcul ou de filtre entre le document repris et le document source | Comparer les résultats sur une période clôturée |
| Univers UNV ou UNX | Objets, classes, conditions, contextes et connexions | Règle de gestion cachée dans la couche sémantique | Exporter la structure et identifier les objets réellement appelés |
| Crystal Reports | Formules, paramètres, sous-rapports et mise en page | Perte de pagination ou de logique d’impression | Tester une sortie PDF sur un échantillon complet |
| CMC et planification | Instances, événements, destinations et comptes de service | Interruption d’une diffusion automatisée après bascule | Vérifier les exécutions sur douze mois |
Ce tableau est construit pour un audit de parc. Il croise les composants SAP BusinessObjects, les objets à relever, le risque de reprise et la vérification à mener. Les noms de composants et les ressources de maintenance ont été relevés le 12 mars 2026 sur le portail de support SAP et sur la documentation SAP BusinessObjects accessible depuis ce portail.
Quelle différence entre SAP BusinessObjects BI 4.2, BI 4.3 et BI 2025
Les versions ne doivent pas être regroupées sous l’étiquette générique SAP BO. BI 4.2, BI 4.3 et BI 2025 ne portent pas les mêmes contraintes de maintenance, ni exactement le même périmètre fonctionnel. Une décision valable pour un environnement BI 4.3 peut devenir inapplicable si le parc conserve des composants retirés ou des univers historiques non pris en charge dans la cible retenue.
SAP a indiqué que SAP BusinessObjects BI 4.2 atteignait sa fin de support le 31 décembre 2024. Cette échéance a été rappelée dans la publication SAP Community consacrée au calendrier de BI 2025, consultée le 12 mars 2026 via les ressources de support SAP. Pour un socle resté en 4.2, la discussion ne porte donc plus sur une future échéance. Elle porte sur le niveau de risque déjà accepté par l’entreprise.
BI 4.2, une version qui ne doit plus porter votre calendrier
BI 4.2 a longtemps constitué le standard de nombreux parcs. Cette version héberge des documents Web Intelligence, des univers UNV, des univers UNX et parfois des composants très anciens conservés pour des raisons de compatibilité. Son âge ne signifie pas qu’elle cesse de fonctionner le jour de la fin de support. Les traitements peuvent continuer. En revanche, l’organisation ne dispose plus du même cadre pour traiter un incident produit ou appliquer les corrections maintenues par l’éditeur.
Un parc BI 4.2 ne doit pas être basculé en urgence sans audit. La pression de support fait parfois accélérer un projet dont le périmètre reste inconnu. Cela produit une reprise documentaire, sans analyse des objets d’univers ni des planifications. À court terme, l’équipe peut afficher des rapports dans une cible. À moyen terme, elle découvre des écarts de périmètre, des envois planifiés manquants ou une logique de sécurité non reprise.
BI 4.3, un palier de continuité mais pas une dispense d’inventaire
BI 4.3 constitue un chemin d’évolution pour les organisations qui souhaitent conserver la plateforme SAP BusinessObjects pendant une période supplémentaire. SAP publie les compatibilités de mise à niveau dans son BI Up-ports Guide. Ce guide doit être vérifié avant toute opération, car la compatibilité dépend à la fois de la version de départ, du niveau de Support Package et de la cible envisagée.
Une mise à niveau technique vers BI 4.3 répond au sujet du maintien de plateforme. Elle ne règle pas automatiquement le problème de dette documentaire. Un univers contenant deux cents objets dont seulement trente sont utilisés conservera la même opacité après l’opération. Si le but est uniquement de prolonger le socle, la montée de version peut se justifier. Si le but est de réduire le parc, de clarifier les indicateurs et de supprimer des rapports fantômes, il faut traiter les deux sujets dans des lots séparés.
BI 2025 impose de vérifier les composants retirés
BI 2025 s’inscrit dans la continuité de la suite SAP BusinessObjects, mais certains composants historiques ne suivent plus la même trajectoire. Les organisations utilisant des univers UNV, Lumira ou Analysis for OLAP doivent donc vérifier leur dépendance réelle avant de choisir cette version. Il ne faut pas se contenter de constater qu’un composant est installé. Il faut mesurer le nombre de documents actifs, les utilisateurs concernés et l’existence d’une solution de remplacement acceptable.
La documentation officielle des nouveautés BI 2025, accessible dans SAP Help Portal, décrit les fonctions ajoutées et les évolutions de périmètre. Ce relevé documentaire doit être complété par l’ouverture d’un environnement réel avant une décision de compatibilité. Aucun environnement BI 2025 n’a été ouvert pour ce contenu ; les éléments cités reposent sur la documentation éditeur consultée le 12 mars 2026.
Que se passe-t-il concrètement après la fin de support SAP BusinessObjects
La fin de support ne coupe pas les serveurs BI à minuit. Les rapports continuent de s’exécuter tant que l’infrastructure, les bases de données, les annuaires et les connecteurs restent opérationnels. Cette nuance est souvent utilisée pour différer toute décision. Elle ne doit pas masquer le changement réel : l’organisation assume alors seule une partie croissante du risque technique.
Après une échéance de maintenance, l’incident le plus gênant n’est pas forcément une panne générale. Il peut s’agir d’un échec de planification après une évolution de messagerie, d’un problème de compatibilité navigateur, d’un connecteur qui ne suit plus une base de données mise à jour, ou d’une anomalie qui affecte un rapport exécuté pour une clôture. Sans support actif adapté, l’équipe doit contourner le problème, restaurer une version antérieure ou faire évoluer un composant voisin.
Le risque se concentre sur les dépendances du socle
SAP BusinessObjects dépend de services qui évoluent à leur propre rythme. Le CMS, les serveurs Web Intelligence Processing Server, les services de planification, les répertoires de fichiers, les bases de données de référentiel et les mécanismes d’authentification forment une chaîne. La plateforme peut être stable alors qu’une évolution de certificat, de protocole de messagerie ou de navigateur dégrade un usage précis.
Le risque doit être formulé en scénario observable. Une phrase comme « la plateforme est ancienne » ne permet aucun arbitrage. En revanche, « le rapport mensuel de marge est planifié vers une boîte fonctionnelle, utilise Crystal Reports et dépend d’un compte technique dont le mode d’authentification doit changer » décrit un risque que le responsable peut tester et budgéter.
Les notes de maintenance SAP indiquent aussi que les dates détaillées de Support Package sont disponibles dans les ressources de fin de vie BI. Il faut distinguer le cycle de vie de la version majeure de celui du correctif installé. Un serveur BI 4.3 à un niveau de Support Package ancien ne bénéficie pas nécessairement du même cadre qu’un serveur à jour. Le contrôle passe par le numéro exact de version dans CMC, puis par la documentation associée sur SAP for Me et le support SAP, relevée le 12 mars 2026.
Le support ne remplace pas un protocole de continuité
Rester sur une version prise en charge ne supprime pas les risques fonctionnels. Un univers peut être techniquement supporté tout en restant incompréhensible. Une planification peut être active tout en diffusant un fichier qui n’est plus ouvert. Il faut donc dissocier deux décisions : conserver ou mettre à niveau la plateforme, puis conserver, reconstruire ou supprimer les contenus.
Sur un parc de moins de cent rapports, dont une moitié n’a aucune consultation vérifiable sur douze mois, la reprise intégrale n’est pas le réflexe à retenir. La reconstruction d’un périmètre réduit coûte souvent moins de charge de validation que la conversion de chaque document. L’arbitrage s’inverse lorsque plusieurs centaines de rapports reposent sur des règles de gestion non documentées, notamment dans les univers et les formules Crystal Reports.
Le support SAP répond au produit. Il ne reconstitue pas la signification d’un indicateur métier ni l’historique des décisions prises dans un univers. C’est précisément cette séparation qui doit figurer dans votre dossier d’arbitrage.
Comment chiffrer une migration SAP BusinessObjects sans sous-estimer la recette
Une estimation de migration ne peut pas se limiter au nombre de rapports. Deux documents Web Intelligence de dix onglets peuvent demander des charges opposées. Le premier appelle un seul univers, sans variable complexe et avec des filtres explicites. Le second combine trois fournisseurs de données, des variables imbriquées, des ruptures, une alerte, des invites et des calculs portant sur des données agrégées.
Le chiffrage commence par une typologie vérifiable. Il faut séparer les Webi simples, les Webi complexes, les Crystal Reports, les univers, les planifications et les droits. Les ratios ne sont pas des engagements de durée. Ils servent à poser une première enveloppe, puis à identifier les objets qui doivent faire l’objet d’un atelier de reprise détaillé.
Un calcul complet sur un parc de 240 rapports
Le calcul suivant fournit un ordre de grandeur pour une reprise de rapports, hors construction de la cible technique. Il porte sur un parc de 240 documents après élimination des contenus sans usage démontré sur douze mois. Les ratios utilisés sont des hypothèses de cadrage : deux heures pour un Web Intelligence simple, six heures pour un Web Intelligence complexe et douze heures pour un Crystal Reports comportant formules et paramètres.
Le parc retenu contient 144 Webi simples, 72 Webi complexes et 24 Crystal Reports. La reprise documentaire représente 144 × 2 heures, soit 288 heures. Les Webi complexes représentent 72 × 6 heures, soit 432 heures. Les Crystal Reports représentent 24 × 12 heures, soit 288 heures. La charge de reconstruction ou de reprise atteint ainsi 1 008 heures, pour les rapports seuls.
Ce calcul exclut explicitement la recette métier, la reprise des droits, la formation, la conduite du changement, la mise en place de la cible, les interfaces de diffusion et la correction des écarts détectés. Ajouter 30 % à 50 % pour la recette et les corrections donne une enveloppe comprise entre 1 310 et 1 512 heures. Cette majoration est une hypothèse de pilotage, pas une donnée SAP. Elle doit être remplacée par vos propres historiques lorsque les charges de recette des précédents projets sont disponibles.
Le détail des postes à traiter est présenté dans l’article consacré au coût de migration de BusinessObjects vers Power BI. Le sujet des licences de cible doit rester séparé de la charge de chantier : une licence est une dépense récurrente, alors que la reprise des contenus constitue une charge projet ponctuelle.
Les univers doivent être chiffrés à part
Un univers ne se compte pas uniquement en nombre d’objets. Un univers de cinquante objets peut être plus coûteux à reprendre qu’un univers de trois cents objets si ses jointures sont ambiguës, si ses contextes sont mal documentés ou si les objets intègrent du SQL spécifique. Le bon relevé porte sur les objets appelés par les rapports actifs, les objets masqués, les conditions obligatoires et les règles de sécurité associées.
La reprise de l’univers vers un modèle sémantique ne doit pas être vendue comme une conversion automatique. Les outils peuvent accélérer l’extraction de métadonnées. Ils ne valident pas l’interprétation d’une mesure ni le périmètre fonctionnel d’un filtre. Le travail de comparaison est décrit dans ce guide sur les règles de gestion enfouies dans les univers BusinessObjects.
Une estimation basse est acceptable si elle est annoncée comme telle et si les exclusions sont écrites. Une estimation qui prétend absorber la recette, les écarts, les droits et les planifications sans détailler ces postes ne peut pas être portée devant une direction financière.
Comment vérifier les chiffres avant de quitter SAP BusinessObjects
Une migration BI ne produit pas spontanément des chiffres identiques à ceux du socle SAP BusinessObjects. Les écarts sont attendus. Ils peuvent provenir d’un filtre implicite, d’une date de chargement différente, d’une jointure, d’un comportement d’arrondi, d’un contexte d’univers ou d’une règle de sécurité. Le travail de recette consiste à identifier ces écarts, à les chiffrer et à faire accepter leur explication.
Le double run reste la méthode la plus défendable lorsque les rapports pilotent une clôture, une marge, des stocks ou un suivi commercial. L’ancien rapport et le rapport repris sont exécutés sur la même période de référence, avec des paramètres documentés. La comparaison porte d’abord sur les agrégats globaux, puis sur les axes de ventilation où l’écart apparaît.
Un protocole de réconciliation exploitable en projet
- Fixez une période clôturée, stable et suffisamment représentative des cas métier à contrôler.
- Conservez les paramètres exacts du document source, y compris les invites, filtres de rapport et restrictions héritées de l’univers.
- Comparez le total global, puis les ventilations par entité, période, produit, client ou statut selon la logique du rapport.
- Consignez chaque différence dans un registre qui indique le montant, le périmètre, la cause identifiée, la correction ou la décision d’acceptation.
- Faites valider les écarts résiduels par le propriétaire métier avant de désactiver la diffusion SAP BusinessObjects.
La tolérance ne doit pas être fixée de manière abstraite. Une différence de 0,2 % peut être acceptable sur un indicateur prévisionnel agrégé et inacceptable sur un état de facturation. Le seuil dépend de l’usage du rapport, de la période comparée et du niveau de détail. Il doit être validé avant les tests, non négocié au dernier moment devant un écart découvert la veille de la bascule.
Le guide consacré au protocole de recette pour une migration BI détaille les colonnes à prévoir dans ce registre. Les documents Web Intelligence doivent être testés avec leurs fournisseurs de données réels. Une comparaison de capture ou de mise en page ne démontre pas qu’une mesure reprend le même périmètre.
La décision de bascule repose sur des preuves, pas sur une date projet
Une bascule doit être refusée lorsque les écarts non expliqués touchent un rapport de pilotage critique. À l’inverse, un écart expliqué et accepté peut être documenté sans bloquer l’ensemble du périmètre. Cette distinction évite de poursuivre une équivalence impossible tout en conservant un niveau de preuve suffisant pour les décideurs.
Les droits demandent un contrôle distinct. Un utilisateur qui voit un total différent après migration n’est pas nécessairement face à une erreur de calcul. Il peut avoir perdu ou gagné une restriction. Les autorisations SAP BusinessObjects, les groupes, les profils et les restrictions appliquées au niveau de l’univers doivent être rapprochés des droits configurés dans la cible.
Avant d’arrêter un serveur ou de désactiver une planification, exportez les logs d’audit sur douze mois et relevez les instances programmées actives. Cette extraction détermine le périmètre réel à conserver, à reprendre ou à supprimer.
SAP BusinessObjects BI 4.2 est-il encore supporté ?
Non. SAP a indiqué une fin de support au 31 décembre 2024 pour SAP BusinessObjects BI 4.2. Les serveurs peuvent continuer à fonctionner, mais le cadre de maintenance et d’assistance doit être vérifié dans les notes SAP correspondant à votre niveau exact de version.
Faut-il migrer tous les rapports Web Intelligence ?
Non. Le périmètre doit être fondé sur les logs d’audit, les planifications actives et la validation des propriétaires métier. Un rapport sans consultation vérifiable sur douze mois peut être supprimé ou archivé après validation, plutôt que repris par défaut.
Les univers UNV peuvent-ils être repris automatiquement ?
Des outils peuvent aider à extraire les métadonnées, mais ils ne valident ni les contextes, ni les filtres d’objet, ni les règles SQL spécifiques. Les univers UNV doivent être analysés avant toute reprise vers une autre couche sémantique.
Pourquoi tester Crystal Reports séparément de Web Intelligence ?
Crystal Reports porte souvent une logique de pagination, de formules, de paramètres et de sous-rapports qui ne correspond pas au fonctionnement d’un document Web Intelligence. La recette doit donc inclure la sortie PDF ou imprimée et pas seulement les montants agrégés.
Le dossier complet Échéances éditeurs : les fins de support à surveiller
