Insights
Migration BI en fin de support : la question n'est pas si vous devez migrer, mais quand et dans quel ordre. Ce que le calendrier SAP implique concrètement pour une ETI.
Ce que couvre cet article
- Ce que la fin de maintenance SAP BO 4.3 signifie concrètement, et ce qu'elle ne signifie pas
- Pourquoi attendre accumule une dette de migration qui rend la transition plus difficile chaque mois
- Les nouvelles options SAP on-premise et les arbitrages qu'elles impliquent
- Trois questions à trancher avant de fixer un calendrier de migration
La date est connue depuis plusieurs années. La maintenance courante (Mainstream Maintenance) de SAP BusinessObjects 4.3 s'arrête le 31 décembre 2026. La plateforme entre alors en Customer-Specific Maintenance (CSM) : pendant les douze premiers mois de cette phase, SAP publie encore des correctifs pour les vulnérabilités de sécurité critiques et très élevées (seuil CVSS ≥ 7). Au-delà du 31 décembre 2027, cette couverture s'arrête. Aucune mise à jour de compatibilité avec les nouvelles versions des systèmes d'exploitation et des bases de données n'est incluse dans la CSM.
Dans les ETI qui utilisent SAP BusinessObjects depuis dix ou quinze ans, ce calendrier génère deux types de réaction. Certaines ont déjà engagé leur migration et cherchent à en maîtriser le rythme. D'autres attendent, soit parce qu'elles espèrent que SAP reviendra sur sa position, soit parce qu'elles sous-estiment le temps que prend une migration réelle sur un parc existant.
Le calendrier de migration d'un projet BI dépend de la taille du patrimoine à migrer, des composants dont l'organisation dépend, et de sa capacité à mener le projet en parallèle de l'exploitation courante, et non de la date de fin de support éditeur. C'est ce que cet article documente.
Ce que "fin de support" signifie concrètement, et ce que cela ne signifie pas
Une fin de maintenance SAP n'est pas une coupure de service. BusinessObjects 4.3 continuera de fonctionner après le 31 décembre 2026. Les rapports s'exécuteront et les utilisateurs se connecteront. Ce n'est pas là que le risque se situe.
Ce qui change : la plateforme entre en Customer-Specific Maintenance (CSM). Pendant les douze premiers mois de cette phase (soit jusqu'au 31 décembre 2027), SAP publie encore des correctifs pour les vulnérabilités de sécurité critiques et très élevées (seuil CVSS ≥ 7). Au-delà, cette couverture s'arrête également. La CSM n'inclut ni correctifs fonctionnels, ni mises à jour de compatibilité avec les nouvelles versions des systèmes d'exploitation, des bases de données ou des navigateurs. Chaque évolution de l'infrastructure sous-jacente devient un risque que l'organisation devra gérer seule.
Le risque prend la forme d'une dégradation progressive : chaque évolution de l'infrastructure sous-jacente non couverte par un correctif devient un point de fragilité supplémentaire. Selon le Baromètre EY/OpinionWay "Future Ready" des ETI 2024 (150 dirigeants et 1 000 collaborateurs d'ETI françaises), 45% des ETI ont subi une cyberattaque en 2023, et 76% des dirigeants en font leur priorité d'investissement. Maintenir une plateforme sans correctifs fonctionnels ni mises à jour de compatibilité dans ce contexte n'est pas une position neutre.
Question fréquente
Peut-on continuer à utiliser SAP BusinessObjects après la fin de maintenance en 2026 ?
Techniquement, la plateforme continue de fonctionner après la fin de la Mainstream Maintenance. À partir de janvier 2027, elle entre en Customer-Specific Maintenance (CSM) : SAP publie encore des correctifs pour les vulnérabilités CVSS ≥ 7 pendant douze mois. Au-delà de fin 2027, plus aucun correctif ni mise à jour de compatibilité OS/base de données n'est fourni. La plateforme tourne, mais chaque évolution de l'infrastructure autour d'elle devient un risque non couvert.
Attendre n'est pas une décision neutre
L'argument le plus fréquent pour reporter la migration est que l'outil fonctionne encore. C'est exact, mais reporter la décision augmente le coût et la complexité du projet.
Un parc BusinessObjects n'est pas statique. Chaque année, de nouveaux rapports s'ajoutent, de nouveaux univers sont créés, de nouvelles connexions sont configurées. Les développeurs qui connaissaient l'architecture d'origine partent sans toujours transmettre ce qu'ils avaient documenté. Les rapports qui semblent identiques dans la liste dissimulent des dépendances différentes sur les sources, les univers, les variables et les flux ETL associés.
Il n'existe pas de benchmark indépendant et représentatif permettant d'établir une durée moyenne de migration BusinessObjects. Ce qui est documenté : les durées varient considérablement selon la taille du parc, les composants impliqués et la capacité à mobiliser les équipes métier pour valider les livrables. Le risque n'est pas seulement d'avoir davantage de rapports à migrer : c'est de devoir reconstruire des dépendances dont la connaissance s'est progressivement dispersée. Les développeurs qui connaissaient l'architecture d'origine sont partis, et les règles de gestion implicites dans les univers n'ont pas toujours été documentées. Ce que l'audit révèle dans la pratique dépasse régulièrement ce que le décompte initial laissait prévoir.
"Le calendrier d'une migration BI est déterminé par la taille du patrimoine à migrer, pas par la date de fin de support éditeur."
Chaque mois supplémentaire passé sans cartographier le parc est un mois pendant lequel des rapports s'ajoutent, des dépendances s'accumulent et des compétences internes sur la plateforme historique se raréfient. Sur les migrations suivies par les consultants DeciVision, les organisations qui ont commencé leur diagnostic tôt ont davantage de marge pour décider de leur trajectoire. Celles qui commencent la cartographie sous contrainte de délai n'ont plus le temps d'arbitrer : elles migrent ce qui peut l'être et conservent en maintenance étendue ce qui ne peut pas.
Ce que SAP a changé en 2025 : des options, pas un sursis
En 2025, SAP a publié une révision de sa trajectoire on-premise pour BusinessObjects. Après avoir orienté ses clients vers SAP Analytics Cloud comme seule destination, l'éditeur a annoncé un nouveau cycle de releases : BI 2025 est disponible depuis le 12 mars 2025, BI 2027 est prévu au premier trimestre 2027, BI 2029 est planifié. Chaque release bénéficie de trois ans de Mainstream Maintenance suivie d'une CSM avec un an de security fixes CVSS ≥ 7. La Mainstream Maintenance est garantie jusqu'à au moins fin 2031, selon la documentation officielle SAP publiée sur la communauté SAP. Les deux options de déploiement on-premise et Private Cloud Edition sont maintenues.
Cette annonce a été interprétée par certains comme un sursis sur le plan du calendrier. Sur le fond, la décision de trajectoire reste entière.
Rester sur BI 4.3 jusqu'à fin 2026 puis upgrader vers BI 2025 n'est pas une migration nulle. BI 2025 ne fournit plus plusieurs composants historiques de la suite : Universe Design Tool et les univers .unv, Live Office, Crystal Reports for Enterprise, et Lumira Discovery. Une organisation qui utilise ces composants doit reconstruire ce qui en dépend, que ce soit vers SAC, vers Power BI, ou vers un autre outil. La fenêtre de support s'est élargie ; le travail de transition, lui, ne disparaît pas.
La vraie question que pose la nouvelle trajectoire SAP n'est pas "est-ce qu'on doit migrer" mais "vers quoi, et dans quel ordre". SAP Analytics Cloud reste l'option recommandée par SAP pour les nouveaux projets d'analytics et de planification. BI 2025 couvre le reporting opérationnel et les univers sémantiques établis. Power BI est pertinent pour les organisations déjà ancrées dans l'écosystème Microsoft. Ces destinations ne sont pas mutuellement exclusives : un grand nombre de migrations BusinessObjects aboutissent à une coexistence de plusieurs outils selon les usages, pas à un remplacement intégral.
Trois questions à trancher avant de fixer un calendrier
Il n'y a pas de calendrier de migration universel. Mais trois questions permettent de dimensionner le projet et de choisir un rythme cohérent avec les ressources disponibles.
Quelle est la taille réelle du parc actif ?
Le nombre de rapports listés dans le CMC (Central Management Console) de BusinessObjects ne reflète pas la charge de migration réelle. Ce qui compte : les rapports effectivement consultés au cours des douze derniers mois, les univers sur lesquels ils s'appuient, et les flux ETL qui alimentent ces univers. Sur des parcs matures, les rapports actifs représentent souvent une fraction du total déclaré, mais ils concentrent la complexité.
Le retour d'expérience du Conseil Départemental de Seine-et-Marne (CD77), documenté par DeciVision, illustre concrètement ce que représente la rationalisation d'un parc de cette nature. Périmètre audité : 20 000 documents, 2 000 requêtes actives, 690 planifications hebdomadaires. Sur ces 2 000 requêtes, plus de 70% sont des rapports opérationnels quotidiens. L'objectif fixé est de décommissionner 60 à 80% du parc d'ici juin 2027, avec un horizon cible d'environ 18 mois, et une méthode organisée en itérations d'une à deux semaines. Ce projet n'est pas une référence universelle : chaque parc a ses propres dépendances et sa propre destination de migration. Mais il donne un ordre de grandeur que peu d'estimations initiales anticipent.
Quels composants ne sont plus fournis dans BI 2025 ?
Les composants supprimés de BI 2025 (univers .unv, Live Office, Crystal Reports for Enterprise, Lumira Discovery) ne sont pas marginaux dans tous les parcs. Certaines organisations ont construit leur couche sémantique entière sur les univers .unv et leurs rapports Web Intelligence associés. D'autres ont des cristaux Crystal Reports intégrés dans des processus métier (états de facturation, documents réglementaires, rapports de gestion) qui ne se migrent pas automatiquement vers une autre technologie.
La réponse à cette question détermine si la migration vers BI 2025 suffit ou si une partie du parc doit être reconstruite sur une autre plateforme. Lorsqu'une organisation choisit SAC ou Power BI comme destination, une partie des contenus doit être reconstruite ou repensée : il n'existe pas de mécanisme de conversion automatique couvrant l'ensemble des objets BusinessObjects. SAP documente précisément ces transitions : les univers au format .unv doivent par exemple être convertis vers .unx avant la migration vers BI 2025, et certaines conversions ne sont plus possibles une fois la nouvelle version installée.
Qui pilote le projet en interne, et avec quel mandat ?
Une migration BusinessObjects est un projet long qui mobilise des compétences rares : connaissance de l'architecture existante, capacité à dialoguer avec les métiers sur leurs usages réels, et aptitude à arbitrer sur ce qui est migré, reconstruit ou abandonné. Cette fonction ne peut pas être assurée à temps partiel par quelqu'un dont la mission principale est ailleurs.
Sans pilote interne identifié avec un mandat clair sur les arbitrages, les migrations s'enlisent au moment des décisions difficiles : quel rapport retire-t-on de la liste ? Quel métier accepte de changer son outil de travail quotidien ? Ces décisions ne sont pas techniques. Elles sont organisationnelles, et elles prennent du temps si la gouvernance n'est pas préparée.
Qui pilote le projet en interne, et avec quel mandat ?
Une migration BusinessObjects est un projet long qui mobilise des compétences rares : connaissance de l'architecture existante, capacité à dialoguer avec les métiers sur leurs usages réels, et aptitude à arbitrer sur ce qui est migré, reconstruit ou abandonné. Cette fonction ne peut pas être assurée à temps partiel par quelqu'un dont la mission principale est ailleurs.
Sans pilote interne identifié avec un mandat clair sur les arbitrages, les migrations s'enlisent au moment des décisions difficiles : quel rapport retire-t-on de la liste ? Quel métier accepte de changer son outil de travail quotidien ? Ces décisions ne sont pas techniques. Elles sont organisationnelles, et elles prennent du temps si la gouvernance n'est pas préparée.
Cette question ne s'arrête pas à la migration. Dans la première année suivant le go-live, l'absence d'un owner BI interne avec un mandat clair est l'une des causes les plus fréquentes de stagnation de l'adoption, quel que soit l'outil choisi.
| Votre situation | Niveau d'urgence |
|---|---|
| Parc peu utilisé, peu de dépendances aux composants dépréciés, ressource interne disponible | Faible : diagnostic utile pour confirmer |
| Parc important, dépendances mal documentées, pas de cartographie récente | Modéré : lancer le diagnostic sans attendre |
| Usages métier critiques + composants supprimés de BI 2025 (univers .unv, Crystal, Live Office) | Élevé : trajectoire à définir sans attendre |
| BI 4.3 sans trajectoire définie + ressources internes limitées + aucun pilote identifié | Prioritaire : trajectoire à définir rapidement |
Comment une ETI organise une migration sans interrompre l'activité
Aucune ETI ne peut se permettre d'interrompre son reporting pendant une migration. La continuité de service pendant la transition est une contrainte de départ, pas un objectif secondaire.
Les migrations qui réussissent sur ce type de parc partagent une même logique de phasage. Le parc existant est cartographié et classifié par priorité d'usage, complexité technique et dépendance aux composants supprimés de BI 2025. Les rapports les plus critiques et les plus simples à migrer sont traités en premier : cela produit de la valeur visible rapidement et permet d'ajuster la méthode avant d'aborder les cas complexes. Les deux plateformes coexistent pendant toute la durée de la transition, avec une TMA active sur l'existant pour éviter que les incidents sur la plateforme historique ne viennent perturber le calendrier.
Cette coexistence mobilise des ressources sur deux environnements simultanément, ce qui a un coût. Elle évite cependant le scénario inverse : une bascule précipitée qui laisse des usages métier sans couverture et oblige à des retours en arrière coûteux.
Les consultants DeciVision accompagnent ce type de transition de bout en bout : cartographie du parc avec BI Smart Repository, choix de la cible, phasage de la migration par itérations, TMA sur l'environnement source pendant la transition, et formation des équipes sur la nouvelle plateforme. L'expérience acquise sur des parcs de taille et de complexité variées, dont le projet CD77 documenté publiquement, permet d'anticiper les blocages qui n'apparaissent pas dans les phases initiales d'estimation.
À retenir
- La maintenance courante de SAP BusinessObjects 4.3 s'arrête le 31 décembre 2026. Les correctifs de sécurité restent disponibles jusqu'au 31 décembre 2027. Au-dela, les vulnérabilités non corrigées et les incompatibilités d'infrastructure sont à la charge de l'organisation.
- SAP a relance une trajectoire on-premise avec BI 2025 (disponible depuis mars 2025) et BI 2027 (prévu au premier trimestre 2027), Mainstream Maintenance garantie jusqu'à au moins fin 2031. Ce n'est pas un sursis sans travail : plusieurs composants historiques ne sont plus fournis dans BI 2025 et doivent être reconstruits ou remplacés.
- Il n'existe pas de durée moyenne de migration BusinessObjects. Les cas documentés montrent des écarts considérables selon la taille du patrimoine et la complexité des dépendances. Le retour d'expérience du CD77 (Seine-et-Marne), documenté par DeciVision, illustre concrètement ce niveau d'effort : 20 000 documents, 2 000 requêtes actives, objectif 60 à 80% de décommissionnement à juin 2027, horizon d'environ 18 mois d'itérations.
- Trois questions déterminent le calendrier : quelle est la taille réelle du parc actif, quels composants ne sont plus fournis dans BI 2025, et qui pilote le projet avec un mandat clair sur les arbitrages.
Vous ne savez pas si votre parc justifie une migration immédiate ?
Avant de choisir une cible, commencez par mesurer ce qui doit réellement être migré. Un audit du parc permet d'identifier les contenus actifs, les dépendances critiques et les composants concernés par la trajectoire SAP.
