OBIEE 12c a dépassé sa période d’Extended Support en août 2025. Rester en Sustaining Support maintient le droit d’utiliser le produit, mais ne donne plus accès aux nouveaux correctifs de sécurité ni aux mises à jour critiques. La décision porte désormais sur Oracle Analytics Server, Oracle Cloud ou une sortie complète d’Oracle.
En bref
- OBIEE 12c n’a pas de version 14c : Oracle Analytics Server constitue la continuité on-premise proposée par l’éditeur.
- Oracle Analytics Server 2026 conserve le modèle de licences perpétuelles, mais impose une migration technique vers Fusion Middleware 14c et JDK 21.
- Oracle Analytics Cloud remplace le support annuel par un abonnement, avec une exploitation gérée par Oracle et des évolutions publiées en avance sur la version serveur.
- La bascule ne garantit pas des chiffres identiques : les mesures, filtres RPD, variables de session et règles de sécurité doivent être réconciliés avant toute décision de mise en production.
- Un parc peu consulté et mal documenté justifie souvent une reconstruction sélective plutôt qu’une reprise exhaustive des tableaux de reporting.
Ce contenu s’adresse aux responsables BI, DSI et chefs de projet qui exploitent encore OBIEE 11g ou OBIEE 12c. Il traite la sortie d’un socle de business intelligence existant, pas la conception d’une architecture cloud générale, ni les clauses juridiques d’un contrat Oracle.
OBIEE en fin de vie : que change réellement le Sustaining Support ?
La fin de vie d’OBIEE ne signifie pas l’arrêt immédiat des tableaux de bord. Les analyses, les agents, le catalogue WebCatalog et le référentiel RPD continuent de fonctionner tant que l’infrastructure, les bases de données et les flux d’alimentation restent disponibles. Le problème se situe ailleurs : le produit sort du cycle de correction active.
Oracle décrit les trois niveaux de son cycle de support dans sa Lifetime Support Policy, consultée le 18 août 2026. Premier Support couvre les mises à jour et corrections prévues par l’éditeur. Extended Support prolonge partiellement cette couverture selon le produit. Sustaining Support maintient principalement l’accès aux correctifs déjà publiés et à l’assistance, sans nouveaux correctifs de sécurité ni nouvelles certifications.
Pour OBIEE 12c, la fermeture de l’Extended Support en août 2025 doit être lue composant par composant. Beaucoup d’équipes ont suivi la feuille de route générale de Fusion Middleware 12.2.1.4. Elles en ont déduit que l’ensemble du socle disposait du même calendrier. Cette lecture est risquée. La date pertinente est celle du composant Oracle Business Intelligence Enterprise Edition installé, avec son niveau de patch, et non celle d’une famille middleware prise globalement.
Le premier travail utile consiste à sortir une photographie exacte de l’environnement. Elle doit contenir la version d’OBIEE, la version de WebLogic, le JDK, les bases de données sources, les pilotes JDBC ou ODBC, le fournisseur LDAP ou SSO, ainsi que les extensions Java et scripts d’administration. Sans cet inventaire, un budget de migration ne repose que sur le nombre de rapports. Or un catalogue de reporting peut être réduit tout en dépendant d’intégrations difficiles à reprendre.
Pourquoi la continuité de service ne suffit pas à justifier l’attente
Un socle peut rester stable plusieurs mois sans incident visible. Cela ne prouve pas qu’il est maintenable. Une évolution de navigateur, une modification de politique SMTP, une mise à jour du fournisseur d’identité ou un changement de certificat peut créer un défaut pour lequel Oracle ne publiera plus de correctif. L’incident ne concerne alors pas seulement l’outil BI : il touche les processus de diffusion, les alertes et la confiance dans le reporting de gestion.
La documentation de support doit aussi être lue avec prudence au niveau des patch sets. Oracle précise, dans sa note Doc ID 1664916.1, que les échéances sont liées aux versions terminales et aux règles de maintenance associées. Une instance restée plusieurs correctifs derrière la version terminale peut donc rencontrer une limite de couverture avant la date globale retenue dans le calendrier interne.
Cette situation devient sensible lors d’un audit d’infrastructure. Un serveur BI non corrigé ne conduit pas automatiquement à une interdiction d’usage. En revanche, il impose de documenter le risque, les mesures de contournement et la date cible de sortie. La question du niveau de sécurité global relève de vos équipes sécurité ; l’analyse s’arrête ici au périmètre de maintenance décisionnelle et aux conséquences sur le projet de migration.
Le support annuel ne baisse pas mécaniquement au passage en Sustaining Support. Les conditions exactes dépendent du contrat signé, mais les grilles historiques d’Oracle illustrent le mécanisme. La grille publique Oracle de 2017, accessible via Oracle Technology Global Price List, affichait BI Foundation Suite à 324 000 dollars par Processor et 71 280 dollars de support annuel, soit 22 % du prix catalogue. Ce document est une référence historique, pas un tarif 2026 ni une proposition commerciale.
Sur vingt Processor facturés à ce tarif historique, le support représente environ 1 425 600 dollars par an avant toute remise contractuelle. Le calcul est direct : 20 × 71 280 dollars. Il ne permet pas de déduire votre facture, car votre contrat peut comporter une remise, un ULA, des produits groupés ou des indexations. Il montre toutefois pourquoi la décision ne doit pas être présentée comme une seule opération de modernisation : le coût annuel de maintien constitue déjà un poste à arbitrer.
Avant de comparer Oracle Analytics Server et Oracle Cloud, vérifiez donc quelles versions sont réellement déployées, quels patchs ont été appliqués et quelles lignes de support correspondent encore à un usage effectif. La date de fin de vie est moins un événement technique qu’un point de départ pour remettre à plat l’inventaire.
Oracle Analytics Server 2026 remplace-t-il OBIEE sans projet de migration ?
Oracle Analytics Server n’est pas une mise à jour mineure d’OBIEE. C’est la cible on-premise proposée par Oracle pour les organisations qui doivent conserver leurs serveurs de business intelligence sous leur propre administration. Oracle présente cette trajectoire dans son guide de destination OBIEE, consulté le 18 août 2026 : les clients peuvent évoluer vers Oracle Analytics Server ou vers Oracle Analytics Cloud selon leur modèle d’exploitation.
Oracle Analytics Server 2026, version 26.01.0.0.0, a été annoncé en mars 2026. Cette version s’appuie sur Fusion Middleware 14c et JDK 21. Ce changement a une conséquence nette : la reprise ne se limite pas à déplacer un RPD et un WebCatalog dans une nouvelle arborescence. Elle implique un nouveau domaine WebLogic, un environnement Java différent, des contrôles de compatibilité et une recette complète des interfaces qui entourent l’application.
La continuité fonctionnelle existe. Le RPD reste le point de départ logique du modèle sémantique. Les sujets, tables logiques, jointures, dimensions, mesures, variables de session et règles de sécurité peuvent être repris. Les analyses existantes, tableaux de bord, invites, agents et conditions d’affichage forment également un patrimoine exploitable. Mais exploitable ne veut pas dire transportable sans vérification.
Quels objets doivent être contrôlés avant la reprise vers Oracle Analytics Server ?
Le RPD doit être examiné à trois niveaux. Le Physical Layer révèle les connexions, pools de connexions, paramètres de base et éventuels scripts d’initialisation. Le Business Model and Mapping Layer porte les règles de jointure, les agrégations, les colonnes logiques et les content levels. Le Presentation Layer expose ce que les utilisateurs voient, mais masque souvent les règles qui expliquent un écart de chiffre.
Une mesure de chiffre d’affaires peut paraître élémentaire dans une analyse. Pourtant, elle peut exclure certaines lignes au niveau logique, s’appuyer sur une agrégation non standard ou dépendre d’une variable de session liée au profil de l’utilisateur. Reprendre uniquement les colonnes visibles dans les tableaux de reporting crée une dette de recette. La migration doit partir des objets du RPD, puis vérifier les requêtes réellement émises par les analyses sensibles.
Les agents méritent un traitement séparé. Ils constituent souvent un angle mort lors d’une modernisation. Un rapport consulté une fois par mois peut être peu visible dans les logs, tout en alimentant automatiquement une diffusion quotidienne ou hebdomadaire auprès d’équipes de direction. Il faut donc inventorier les agents, leurs destinataires, leurs conditions de déclenchement, les formats d’export et les serveurs SMTP utilisés.
Oracle met en avant, dans Oracle Analytics Server 2026, des fonctions de diffusion de classeurs et une interface d’administration modernisée. Ces apports peuvent résoudre des besoins précis, notamment la production récurrente de fichiers XLSX, PDF ou PNG. Ils ne dispensent pas de vérifier la reprise des diffusions historiques. Un agent OBIEE fondé sur une condition de données, une variable de session ou une liste de diffusion spécifique doit être testé dans le nouveau périmètre.
| Élément du socle OBIEE | Équivalent ou point de reprise dans Oracle Analytics Server | Contrôle de recette à prévoir | Risque si le contrôle est omis |
|---|---|---|---|
| RPD avec couches physique, logique et présentation | Référentiel sémantique repris et adapté | Jointures, agrégations, filtres d’objets et variables de session | Écart de calcul non visible dans les tableaux |
| WebCatalog et analyses | Catalogue Oracle Analytics Server | Prompts, actions, permissions, conditions d’affichage | Rapports accessibles mais comportement différent |
| Agents et distributions | Planification et diffusion dans la cible | Destinataires, calendrier, SMTP, pièces jointes | Interruption silencieuse du reporting récurrent |
| Authentification LDAP ou SSO | Domaine WebLogic et mécanismes d’identité de la cible | Groupes, rôles applicatifs et accès aux domaines | Surautorisation ou perte d’accès après bascule |
Ce tableau repose sur la documentation Oracle Analytics Server disponible dans le portail Oracle Analytics Server Documentation, consulté le 18 août 2026. Il ne remplace pas la matrice de compatibilité de votre version exacte, notamment pour les bases de données, les annuaires et les composants WebLogic.
La charge doit être budgétée comme un projet de plateforme. Sur un parc de 240 analyses, avec 60 % d’objets standards estimés à deux heures de reprise technique et 40 % d’objets complexes estimés à six heures, la reprise initiale représente 576 heures : 144 analyses × 2 heures, plus 96 analyses × 6 heures. Ce calcul exclut explicitement la recette métier, la reprise des habilitations, la formation, les environnements et les corrections après double run.
Le chiffre de 576 heures n’est pas un ratio universel. Il sert à rendre visible ce qui est souvent absent des estimations : la reprise du catalogue ne couvre pas la validation des résultats. Si le parc contient des règles de gestion peu documentées, un historique d’agents important ou des extensions spécifiques, la reconstruction technique devient une fraction seulement du calendrier réel.
Oracle Analytics Server est le bon choix lorsque l’exploitation on-premise reste une contrainte claire, que les licences perpétuelles sont encore cohérentes avec le parc et que la compatibilité des intégrations a été vérifiée. Il est moins adapté si l’organisation cherche avant tout à supprimer l’administration middleware ou si la majorité du reporting doit être reconstruite de toute façon.
Oracle Cloud ou Oracle Analytics Server : quel arbitrage pour votre reporting ?
Oracle Cloud, dans ce contexte, désigne principalement Oracle Analytics Cloud. Il s’agit d’une plateforme cloud gérée par Oracle, où l’éditeur exploite l’infrastructure et publie les évolutions du service. Le choix ne se réduit pas à opposer un serveur interne à un service distant. Il engage le modèle de licence, le rythme des mises à jour, le rôle de l’équipe middleware et le niveau de dépendance à l’abonnement.
Oracle indique dans son guide de destination OBIEE que les environnements dont les données et les usages se déplacent vers le cloud peuvent orienter leur analyse de données vers Oracle Analytics Cloud. Le même guide prévoit aussi un chemin hybride, par exemple lorsque les sources restent on-premise tandis que la couche de restitution évolue vers le service cloud. Cette possibilité doit être traitée comme une étape de transition, avec des flux, des latences et des responsabilités clairement documentés.
Oracle Analytics Server convient à une organisation qui veut garder la maîtrise des serveurs, des fenêtres de maintenance et du cycle de mise à niveau. Oracle Analytics Cloud déplace ces sujets vers le service géré. Cela peut réduire la charge d’administration du middleware, mais cela ne retire pas la charge de gouvernance du reporting. Les RPD, les règles de sécurité, les sources, les indicateurs de gestion et la recette restent à la charge du projet.
Pourquoi le choix cloud ne doit pas être piloté par une promesse fonctionnelle
Oracle Analytics Cloud reçoit certaines évolutions avant la version serveur. Oracle communique notamment sur des fonctions d’assistance et d’automatisation de l’analyse disponibles dans ses versions cloud. Ce différentiel ne doit pas décider seul de la cible. Une fonction incluse dans un abonnement n’est pas gratuite : son coût est intégré dans le modèle de souscription et doit être mis en regard d’un cas d’usage mesurable.
La question des fonctions d’intelligence artificielle générative, des agents ou des assistants sort du périmètre de cet article. Leur évaluation doit être conduite avec les responsables métier, sécurité et gouvernance concernés. Pour un socle décisionnel, le point contrôlable est plus concret : quelles analyses existantes doivent être reproduites, avec quels écarts acceptés, dans quel délai et avec quelle responsabilité opérationnelle.
Le modèle BYOL, ou Bring Your Own License, est souvent évoqué lors du passage à Oracle Cloud. Il peut permettre de valoriser certaines licences existantes dans une offre cloud, sous réserve des règles Oracle applicables à votre contrat, à vos produits et à votre métrique. Il ne faut jamais inscrire cette hypothèse dans un budget sans confirmation écrite d’Oracle. Les règles de conversion, les crédits, les limitations et la sortie ultérieure du service sont contractuels.
La question du stockage des données, des transferts entre environnements et de la localisation des traitements doit également être instruite. Elle relève de votre DPO, de vos responsables sécurité et des équipes juridiques. L’analyse présentée ici se limite à l’impact sur les flux décisionnels, les modèles sémantiques et le reporting.
Quels critères départagent les deux cibles ?
- Choisissez Oracle Analytics Server lorsque l’exploitation on-premise est imposée, que les dépendances WebLogic sont maîtrisées et que le maintien de licences perpétuelles reste justifié par votre contrat.
- Orientez-vous vers Oracle Analytics Cloud lorsque l’administration des serveurs BI doit sortir du périmètre interne et que le budget d’abonnement est chiffré sur plusieurs années.
- Retenez une trajectoire hybride seulement si les flux entre les sources internes et la plateforme cloud sont recensés, testés et suivis dans la recette de performance.
- Écartez les fonctions non utilisées du dossier de décision : un besoin de reporting mensuel ne justifie pas, à lui seul, une conversion complète de métrique de licence.
La comparaison doit être faite sur cinq ans, sans mélanger les postes. D’un côté figurent le support annuel, les serveurs, l’administration, les mises à niveau et le coût de migration vers Oracle Analytics Server. De l’autre figurent l’abonnement Oracle Cloud, les éventuels crédits BYOL, les flux d’intégration, la migration et les conditions de renouvellement. Une réduction de coût ne peut être affirmée qu’après avoir posé ces hypothèses, ligne par ligne.
Un point mérite une attention particulière : migrer vers Oracle Analytics Server ne diminue pas automatiquement la maintenance annuelle. Les licences perpétuelles restent en principe le socle de droits, tandis que le projet remet le produit sur une version supportée. Oracle Analytics Server est donc souvent un remède technique à la fin de vie d’OBIEE, pas une réponse commerciale à la hausse des coûts.
Le choix s’inverse lorsque le besoin principal est de sortir durablement du modèle de licences perpétuelles et du middleware interne. Dans ce cas, Oracle Cloud peut être cohérent, mais la décision doit intégrer les conditions de renouvellement et l’absence de repli immédiat vers un actif possédé. Une plateforme cloud résout l’exploitation de la plateforme ; elle ne résout pas automatiquement la dette accumulée dans le RPD et les tableaux historiques.
Comment mesurer la charge de migration OBIEE avant de choisir une cible ?
Le nombre de rapports exporté depuis le WebCatalog donne une première indication, mais il ne permet pas de chiffrer la migration. Deux analyses peuvent avoir le même volume d’affichage et demander des efforts très différents. L’une interroge une table logique unique avec une mesure standard. L’autre combine des niveaux d’agrégation, des prompts, des colonnes calculées, des variables de session et une sécurité dépendante du rôle applicatif.
La première étape consiste à séparer les objets consultés des objets seulement présents dans le catalogue. Les logs d’usage sont utiles, mais leur durée de conservation doit être vérifiée. Une rétention de 90 jours ne détecte pas correctement les campagnes trimestrielles, les arrêtés annuels ou les rapports de fin d’exercice. Un relevé sur douze mois est préférable lorsqu’il existe. À défaut, les listes de diffusion d’agents et les entretiens avec les responsables de domaine complètent le constat.
Un parc de 400 analyses n’est pas nécessairement un projet de 400 reprises. Une part importante peut être obsolète, redondante ou remplacée par un fichier diffusé hors de l’outil. À l’inverse, dix tableaux de bord financiers peuvent concentrer une grande part de la charge de recette parce qu’ils utilisent des filtres hérités, des calculs de période et des règles de restitution très contrôlées.
Une estimation chiffrée doit distinguer reprise et validation
Une méthode de chiffrage exploitable classe chaque objet selon sa difficulté. Les analyses standards couvrent les listes, tableaux croisés et graphiques sans logique particulière. Les objets intermédiaires intègrent des prompts, des vues multiples, des calculs et des règles de présentation. Les objets complexes incluent les analyses multi-domaines, les agents conditionnels, les actions, les calculs fortement dépendants du RPD ou des droits spécifiques.
Le calcul suivant fournit un exemple borné. Il concerne 300 objets recensés sur un environnement OBIEE 12c. L’audit d’usage retient 180 objets actifs. Parmi eux, 108 sont standards, 45 sont intermédiaires et 27 sont complexes. Les hypothèses de reprise sont respectivement de deux, quatre et huit heures par objet. Ces ratios sont des hypothèses de cadrage, à recalibrer après un échantillon de reprise ; ils ne comprennent pas la recette métier, la formation, la gestion de projet ni l’administration de l’infrastructure.
La reprise technique représente alors 612 heures : 108 × 2 heures donnent 216 heures ; 45 × 4 heures donnent 180 heures ; 27 × 8 heures donnent 216 heures. Si la recette est estimée séparément à une heure pour les analyses standards, trois heures pour les intermédiaires et six heures pour les complexes, elle ajoute 405 heures. Le périmètre total reprise plus recette atteint donc 1 017 heures, avant correction des anomalies et avant préparation du double run.
Ce type de calcul évite deux erreurs fréquentes. La première consiste à budgéter tous les objets au même ratio. La seconde consiste à annoncer une charge de migration en oubliant les tests métier. Or c’est la recette qui met au jour les écarts de périmètre, de jointure, de calendrier ou de droits. Une reprise technique terminée ne signifie pas que les chiffres sont acceptés.
| Catégorie d’objet | Volume retenu | Ratio de reprise | Charge de reprise | Charge de recette hypothétique |
|---|---|---|---|---|
| Analyse standard | 108 | 2 heures | 216 heures | 108 heures |
| Analyse intermédiaire | 45 | 4 heures | 180 heures | 135 heures |
| Analyse complexe | 27 | 8 heures | 216 heures | 162 heures |
| Total actif | 180 | Hypothèses de cadrage | 612 heures | 405 heures |
Le tableau est un modèle de chiffrage, pas une donnée éditeur. Son utilité réside dans les hypothèses visibles et dans les exclusions écrites. Il faut ensuite ajouter les habilitations, l’industrialisation, les environnements, les échanges avec les équipes sources, les tests de charge et la correction des écarts selon le contexte réel.
Pour un parc inférieur à cent objets dont une part importante n’est plus consultée, la reconstruction sélective est souvent préférable à la conversion à l’identique. Au-delà de 300 analyses actives, surtout si les règles de gestion sont enfouies dans le RPD, la reprise structurée redevient généralement plus rationnelle. L’arbitrage bascule selon l’usage réel et la documentation, pas selon le seul âge d’OBIEE.
Comment sécuriser les chiffres après une migration OBIEE vers Oracle Analytics ?
La recette ne cherche pas à démontrer que le nouveau socle produit toujours les mêmes chiffres que l’ancien. Cette promesse serait imprudente. Les écarts existent : une jointure peut corriger un doublon historique, une gestion de date peut être explicitée, un filtre appliqué dans une condition d’objet peut être déplacé dans une analyse. Le projet doit identifier ces écarts, les expliquer et obtenir une validation formelle de leur traitement.
Le double run reste la méthode la plus solide pour les domaines sensibles. Il consiste à exécuter, sur une période définie, les analyses OBIEE et leurs équivalents dans Oracle Analytics Server ou Oracle Cloud. Les résultats sont comparés à une même date d’extraction, sur le même périmètre de données et avec des filtres documentés. Comparer deux sorties produites à des horaires différents ne prouve rien si les sources sont alimentées en continu.
Les contrôles doivent être organisés par niveau. Le premier niveau compare les volumes : nombre de lignes, nombre de clients, nombre de commandes ou nombre d’écritures. Le deuxième compare les agrégats : chiffre d’affaires, quantités, montants de marge ou soldes. Le troisième traite les écarts unitaires. Il permet de remonter à la clé métier, à la date, au statut ou à la règle qui explique une différence.
Quels écarts doivent être acceptés et lesquels doivent bloquer la bascule ?
Une tolérance ne peut pas être définie une fois pour tout le programme. Sur un rapport de pilotage commercial arrondi à l’unité monétaire, un écart de quelques centimes peut être sans incidence. Sur une sortie de contrôle financier, un écart même faible peut signaler une ligne manquante ou un filtre de période incorrect. La tolérance doit être validée par le propriétaire métier du rapport, pas seulement par l’équipe technique.
Un écart de 0,4 % peut sembler faible sur un indicateur global. Sur 50 millions d’euros, il représente 200 000 euros. Il doit donc être investigué avant d’être qualifié d’acceptable. Les causes fréquentes sont connues : filtre de statut différent, prise en compte d’annulations, fusion de clés, problème de fuseau horaire, calendrier fiscal distinct ou jointure qui multiplie les lignes.
Le protocole de recette gagne à être tenu dans une matrice unique. Chaque ligne doit identifier l’analyse source, l’équivalent cible, le propriétaire métier, le jeu de données, la date de comparaison, l’indicateur testé, l’écart observé, son origine et la décision prise. Une anomalie corrigée sans trace devient un risque au moment où un utilisateur conteste le nouveau reporting plusieurs semaines après la bascule.
Les droits doivent être testés avec la même rigueur que les calculs. Un utilisateur peut obtenir un total juste tout en voyant un périmètre qu’il ne devait pas consulter. Les rôles applicatifs, groupes LDAP, variables de session, filtres de sécurité de ligne et droits de catalogue doivent être comparés. La sécurité des données elle-même relève de vos équipes compétentes ; le projet BI doit au minimum démontrer que les règles de visibilité prévues sont bien reproduites ou explicitement modifiées.
Les rapports de diffusion récurrente doivent enfin être inclus dans le double run. Une analyse consultée à l’écran reçoit souvent plus d’attention qu’un fichier PDF envoyé chaque lundi matin. Pourtant, ce fichier peut être la source utilisée par un processus opérationnel. Une migration réussie sur le portail ne suffit pas si les agents, exports et alertes échouent silencieusement après la bascule.
Oracle ne publie pas de protocole universel de réconciliation métier, car les règles reposent sur chaque modèle sémantique. La documentation produit, disponible dans le portail Oracle Analytics Server Documentation et consultée le 18 août 2026, décrit les fonctions d’administration et de contenu. La méthode de validation doit être construite autour de vos indicateurs réellement utilisés.
Avant de choisir définitivement Oracle Analytics Server ou Oracle Cloud, sortez les logs d’usage sur douze mois, inventoriez les agents, classez les objets actifs et établissez une première matrice de réconciliation. Le choix de cible sera alors fondé sur un périmètre observable, et non sur un catalogue de fonctionnalités.
OBIEE 12c est-il encore utilisable après août 2025 ?
Oui, l’application peut continuer de fonctionner en Sustaining Support. En revanche, Oracle ne fournit plus les nouveaux correctifs de sécurité, mises à jour critiques et certifications associés aux phases de support précédentes. La date doit être vérifiée pour votre composant et votre niveau de patch exacts.
Faut-il acheter de nouvelles licences pour passer à Oracle Analytics Server ?
Oracle présente Oracle Analytics Server comme la trajectoire on-premise des clients OBIEE. Les droits existants peuvent constituer la base de la cible, mais leur applicabilité dépend du produit acheté, de la métrique, du contrat et du dimensionnement des serveurs. Une vérification des entitlement documents est nécessaire avant tout engagement.
Oracle Analytics Cloud supprime-t-il le travail de migration ?
Non. Le service géré réduit l’administration de l’infrastructure BI, mais la reprise du modèle sémantique, des analyses, des habilitations, des agents et de la recette demeure un travail de projet. Les écarts de résultats doivent être mesurés et validés.
Peut-on migrer uniquement les rapports réellement utilisés ?
Oui, si les logs d’usage couvrent une période suffisante et s’ils sont complétés par l’inventaire des agents, diffusions planifiées et rapports périodiques. Un rapport peu ouvert peut rester critique s’il alimente une diffusion automatique ou un contrôle annuel.
Le dossier complet Échéances éditeurs : les fins de support à surveiller
