IBM Planning Analytics est la continuité fonctionnelle de TM1, avec le même moteur multidimensionnel et des interfaces modernisées pour la planification, l’analyse des données et la gestion financière. La migration ne consiste toutefois pas à déplacer des fichiers. Elle impose de vérifier les cubes OLAP, les règles, les droits, les processus TurboIntegrator et les usages Excel.
- Le moteur TM1 reste au centre de Planning Analytics, mais les interfaces, les composants d’administration et les modalités de licence changent selon l’édition retenue.
- Planning Analytics Workspace et Planning Analytics for Excel remplacent progressivement les usages de Perspectives, sans reprendre automatiquement chaque bouton d’action ni chaque macro VBA.
- Une reprise technique peut être courte sur un modèle stable, mais la recette des règles, de la sécurité et des chiffres de gestion financière représente souvent la charge déterminante.
- Un parc peu consulté ne mérite pas toujours d’être repris objet pour objet : les logs d’usage doivent précéder toute estimation de migration.
Ce dossier s’adresse aux responsables décisionnels qui exploitent encore IBM Cognos TM1, TM1 10.2.2 ou Cognos Express et qui envisagent Planning Analytics Local ou SaaS. Il traite des modules, de la reprise applicative et de la recette ; les négociations contractuelles, la sécurité d’infrastructure et la protection des données personnelles relèvent des équipes compétentes.
IBM Planning Analytics remplace-t-il réellement TM1 ?
IBM Planning Analytics ne remplace pas le moteur TM1 par un autre moteur. Il reprend la base multidimensionnelle qui a fait fonctionner les applications de budget, de prévision et de simulation pendant des années. Le changement porte d’abord sur le nom commercial, puis sur les interfaces disponibles autour du serveur.
IBM a lancé Planning Analytics en mode SaaS à la fin de 2015, puis a proposé une édition locale en décembre 2016. La documentation IBM continue de présenter Planning Analytics comme une plateforme de planification reposant sur TM1. Ce point compte lors d’un arbitrage : les cubes, dimensions, règles et processus existants ne deviennent pas inutilisables parce que l’étiquette TM1 disparaît.
La confusion vient souvent d’un raccourci. Un utilisateur qui travaille depuis longtemps avec Perspectives peut croire qu’il doit reconstruire son application parce que Planning Analytics Workspace propose une interface navigateur. Ce n’est pas le bon diagnostic. Le serveur TM1 continue à exécuter les règles, à gérer les consolidations et à répondre aux requêtes issues des différents clients.
Le moteur TM1 demeure le socle de la planification
Dans un environnement de gestion financière, un cube peut croiser une entité, un compte, une période, une version budgétaire et un scénario. Les règles TM1 calculent ensuite les agrégats et les allocations. Une application de planification peut ainsi contenir des dizaines de cubes OLAP, des dimensions partagées et des processus TurboIntegrator chargés depuis un ERP, un fichier plat ou une base relationnelle.
Planning Analytics conserve cette logique. La modélisation des données reste donc un sujet de migration, mais pas nécessairement de refonte immédiate. Une dimension Produit avec ses hiérarchies, un cube de marge et une règle de conversion de devise peuvent être repris dans le serveur cible. Il faut pourtant contrôler les dépendances avant de promettre un calendrier.
Le premier inventaire porte sur les objets réellement actifs. Il doit recenser les serveurs TM1, les applications web, les fichiers Excel, les processus, les chores planifiées, les groupes de sécurité et les connexions externes. Un modèle contenant trois cubes peut dissimuler quarante processus d’alimentation. C’est là que les charges sont sous-estimées.
La page consacrée aux usages d’IBM Cognos TM1 aide à distinguer les applications de saisie budgétaire, les restitutions financières et les modèles de simulation. Cette distinction doit figurer dans votre inventaire, car les objets de saisie ne se testent pas comme des tableaux de consultation.
Le nom du produit ne règle pas les écarts de conception
Une migration vers IBM Planning Analytics ne corrige pas spontanément un modèle construit autour de règles peu lisibles ou de dimensions dupliquées. Un cube lent le restera si la cause se situe dans les feeders, dans un ordre de dimensions inadapté ou dans une alimentation répétée. La nouvelle interface peut rendre le défaut plus visible, sans le supprimer.
IBM documente les composants de Planning Analytics Local et leurs prérequis dans sa documentation produit, consultée le 18 juin 2026 : documentation IBM Planning Analytics. Les versions de serveur, de Workspace et de clients Excel doivent être relevées séparément. Une application TM1 ne se résume jamais au numéro de version inscrit sur le serveur.
La décision la plus prudente consiste à séparer deux questions. La première porte sur la compatibilité technique du modèle avec le moteur disponible. La seconde porte sur le maintien ou la reconstruction des interfaces utilisateur. Les confondre conduit à chiffrer une mise à niveau comme si elle incluait déjà une refonte des écrans, des tableaux et du workflow.
Quels modules IBM Planning Analytics faut-il distinguer avant la migration ?
Le mot Planning Analytics recouvre plusieurs modules. Cette diversité explique pourquoi deux projets portant le même nom peuvent avoir des charges très différentes. Un passage du serveur TM1 10.2.2 vers une version récente, sans modification des usages Excel, n’a pas le même périmètre qu’une bascule vers Planning Analytics Workspace avec de nouveaux tableaux de bord.
Le serveur TM1 constitue le noyau. Il héberge les cubes OLAP, dimensions, hiérarchies, règles, feeders, processus TurboIntegrator et droits. Planning Analytics Local installe ce noyau dans l’environnement maîtrisé par l’organisation. L’édition SaaS place l’exploitation de la plateforme sous la responsabilité d’IBM, selon les conditions de l’offre souscrite.
Planning Analytics Workspace change surtout les usages navigateur
Planning Analytics Workspace, souvent désigné par l’acronyme PAW, fournit une interface navigateur pour composer des vues, saisir des données, construire des tableaux de bord et consulter des analyses. Il peut aussi participer à certaines opérations d’administration. Son intérêt dépend du profil des utilisateurs. Un contrôleur de gestion qui travaille principalement dans Excel ne basculera pas forcément vers Workspace à la première version disponible.
PAW introduit des livres, des pages, des tuiles de visualisation et des explorations. Ces objets doivent être recensés comme des composants à part entière. Une feuille TM1 Web ancienne peut rester utilisable, mais elle ne devient pas automatiquement une page Workspace. Les mises en forme, les actions et les chemins de navigation demandent une recette dédiée.
Les fonctions collaboratives sont également à examiner avec précision. Commentaires, annotations et mécanismes de suivi peuvent améliorer le processus de planification. Ils ne remplacent pas automatiquement les validations métier déjà organisées dans un workflow externe. Si un circuit de budget passe par des fichiers Excel, des droits TM1 et des échanges par courriel, la migration doit documenter chaque étape avant de la déplacer.
Planning Analytics for Excel ne reprend pas mécaniquement Perspectives
Planning Analytics for Excel, ou PAX, est l’interface Excel destinée à remplacer progressivement les pratiques historiques associées à Perspectives. Elle permet des explorations, des rapports actifs et des rapports personnalisés. Elle est particulièrement importante dans les applications où la gestion financière est pilotée à partir de modèles Excel établis depuis longtemps.
Le problème concret porte sur la coexistence. Perspectives et PAX ne sont pas conçus pour fonctionner simultanément sur le même poste client. Ce point doit apparaître dans le plan de déploiement. Un pilote sur quelques postes identifie les compléments installés, les macros appelées par les classeurs et les procédures de distribution.
| Composant | Rôle dans l’application | Objet à contrôler lors de la migration | Risque si le contrôle manque |
|---|---|---|---|
| TM1 Server | Calcul, stockage multidimensionnel et sécurité | Cubes, règles, feeders, processus et chores | Écart de calcul ou alimentation incomplète |
| Planning Analytics Workspace | Saisie, analyse et restitution dans le navigateur | Pages, livres, vues, droits et navigation | Interface inutilisable malgré un serveur disponible |
| Planning Analytics for Excel | Rapports et analyses dans Excel | Rapports actifs, boutons d’action et macros VBA | Classeur ouvert mais fonctions métier absentes |
| TM1 Web | Publication de feuilles et saisie web | Websheets, paramètres et accès utilisateurs | Rupture des parcours de saisie existants |
| TurboIntegrator | Chargement et transformation des données | Connexions, fichiers, variables et planifications | Cube techniquement repris mais non alimenté |
Ce tableau croise les composants, leur rôle, les objets à vérifier et le risque opérationnel. Il est construit à partir de la documentation IBM Planning Analytics consultée le 18 juin 2026 et des objets habituellement exposés dans une application TM1. Il ne remplace pas la matrice de dépendances propre à votre environnement.
Une démonstration vidéo peut être utile pour distinguer l’interface Workspace du moteur TM1. Elle ne remplace pas la recette sur vos propres cubes, règles et droits.
La sélection des modules doit partir des usages mesurés. Si les rapports Excel sont ouverts chaque mois par cent utilisateurs et que Workspace reste absent des pratiques, le premier budget doit couvrir PAX, la compatibilité des classeurs et la formation ciblée. À l’inverse, une application de saisie distribuée peut justifier un chantier Workspace plus large.
Comment choisir entre Planning Analytics Local et SaaS ?
Le choix entre IBM Planning Analytics Local et SaaS ne se tranche pas sur la seule préférence pour le cloud ou l’installation interne. Il se tranche à partir des interfaces existantes, du niveau de personnalisation, des contraintes d’intégration et de la capacité à exploiter la plateforme. Les deux modes reposent sur le moteur TM1, mais la répartition des responsabilités diffère.
Planning Analytics Local convient aux organisations qui maintiennent déjà des serveurs TM1, des flux d’intégration et des connexions spécifiques. L’équipe garde la maîtrise du calendrier de mise à niveau, de l’installation des composants et de l’articulation avec les systèmes sources. Cette maîtrise implique aussi de prévoir les ressources d’administration et les procédures de sauvegarde.
Le SaaS réduit la charge d’exploitation de l’infrastructure du produit, puisque l’environnement est fourni dans le cadre de l’offre IBM. Il ne dispense ni de la recette métier ni de l’inventaire des intégrations. Une alimentation qui dépend d’un partage de fichiers, d’un pilote spécifique ou d’une connexion base de données doit être vérifiée de bout en bout avant toute bascule.
Les interfaces existantes orientent le choix plus sûrement que les présentations commerciales
Un environnement composé d’un serveur TM1, de Perspectives, de processus TurboIntegrator nocturnes et de rapports Excel n’est pas immédiatement prêt pour une bascule d’interface. Les flux de planification peuvent être conservés dans un premier temps, puis les usages navigateur peuvent être repris par étapes. Cette approche limite le nombre de variables modifiées durant une même recette.
Le cas s’inverse lorsqu’une application est principalement consultée dans un navigateur, avec des besoins de restitution et de collaboration. PAW devient alors un composant central. Les équipes doivent toutefois tester les temps de réponse, les droits sur les pages et les comportements de saisie sur les périodes de charge. Une démonstration sur un cube d’exemple ne prouve rien sur votre modèle de production.
La documentation IBM décrit les options d’installation et de configuration de Planning Analytics Local, dont les composants déployés sur l’infrastructure de l’organisation. Cette documentation, consultée le 18 juin 2026, doit être relue pour la version exacte envisagée : préparation d’une installation Planning Analytics Local.
Le coût de licence ne doit pas masquer le coût de reprise
Les tarifs, les métriques de licence et les droits inclus varient selon le contrat IBM, l’édition, les profils d’utilisateurs et les options retenues. Aucun prix public stable n’est présenté ici, car un montant non rattaché à une unité de facturation et à une date de relevé ne peut pas servir à arbitrer un budget. Votre contrat, votre devis IBM et vos droits de support restent les pièces à rapprocher.
La charge de migration, elle, peut être estimée avant même le choix définitif d’hébergement. Prenons un parc de 80 classeurs Excel. Si 50 classeurs sont des rapports de consultation nécessitant deux à quatre heures de vérification chacun, et 30 sont des modèles de saisie nécessitant six à douze heures de reprise et de test, le calcul donne une fourchette de 280 à 560 heures.
Cette estimation couvre la vérification des formules, objets TM1, boutons et droits. Elle exclut la recette financière complète, la formation, le nettoyage du modèle et la reprise des interfaces externes. Les ratios sont une hypothèse de cadrage, non une donnée IBM. Ils doivent être remplacés par des mesures sur un échantillon représentatif de vos fichiers.
Un projet de migration échoue souvent lorsque le comité finance une installation et découvre ensuite que la production des états mensuels reste dépendante de vingt macros non recensées. Le choix Local ou SaaS vient après cet inventaire, pas avant.
La question de l’hébergement des données, des transferts internationaux et des obligations contractuelles dépasse le périmètre de l’audit décisionnel. Votre DPO, votre RSSI et votre direction juridique doivent vérifier ces points à partir des documents contractuels applicables.
Quelle méthode de migration TM1 vers IBM Planning Analytics limite les écarts ?
Une migration TM1 vers IBM Planning Analytics commence par une photographie exploitable du parc. Les fichiers de sauvegarde ne suffisent pas. Il faut connaître les cubes utilisés, les dimensions modifiées, les processus exécutés, les droits actifs, les classeurs diffusés et les chiffres qui font référence lors des clôtures.
Le premier travail consiste à extraire les journaux d’accès sur une période couvrant au moins un cycle budgétaire complet et une clôture annuelle. Sans cette durée, un rapport utilisé seulement en fin d’exercice peut être classé à tort comme inactif. Les logs doivent ensuite être rapprochés des listes de diffusion, des dossiers partagés et des processus planifiés.
La recette doit porter sur des scénarios métier et non sur une liste de serveurs
Un serveur démarré ne prouve pas qu’une application fonctionne. La recette doit partir de scénarios concrets : chargement d’un référentiel, saisie d’une prévision, recalcul d’une marge, consolidation d’un périmètre, publication d’un état et extraction vers Excel. Chaque scénario doit indiquer son propriétaire métier, sa source de données, son cube cible et le résultat attendu.
Les écarts sont inévitables. Un total peut différer parce qu’un membre consolidé, une règle de sécurité, un zéro supprimé dans l’affichage ou une version budgétaire ne se comporte pas comme dans l’ancien écran. L’objectif n’est pas de promettre des chiffres identiques. Il est de définir une tolérance, d’expliquer chaque écart et de faire valider les différences acceptables.
Un double run est utile sur une période de référence. L’ancien environnement et la cible produisent alors les mêmes indicateurs à partir d’extractions figées. Le rapprochement doit isoler les différences par cube, par période, par entité et par règle. Un écart de 0,3 % sur une marge consolidée ne se traite pas comme un écart de 0,3 % sur une donnée de saisie individuelle.
Les dépendances invisibles doivent être testées avant le déploiement
Les éléments les plus risqués sont rarement les cubes les plus visibles. Un processus TurboIntegrator peut appeler un fichier sur un partage réseau. Un bouton d’action dans un classeur peut lancer un script. Une macro VBA peut modifier un filtre, rafraîchir une vue et exporter un résultat destiné à la direction financière. Ces dépendances ne figurent pas toujours dans l’inventaire du serveur.
Planning Analytics for Excel reprend de nombreux usages de Perspectives, mais les boutons d’action et les routines VBA exigent une vérification spécifique. Le bon niveau de contrôle n’est pas « le classeur s’ouvre ». Le contrôle porte sur la séquence complète : ouverture, authentification, sélection de période, saisie, enregistrement, calcul et diffusion.
- Gelez une copie de référence des cubes, règles, dimensions, processus et fichiers utilisateurs avant la reprise.
- Classez les objets selon leur usage réel, leur fréquence, leur criticité de gestion financière et leur dépendance technique.
- Testez un échantillon représentatif avant de reprendre l’ensemble du parc, avec des données de clôture et de planification.
- Consignez les écarts dans un registre indiquant la source, la cause, la décision métier et la date de validation.
- Préparez la bascule seulement lorsque les scénarios critiques ont un résultat validé ou un écart explicitement accepté.
Le guide consacré aux applications TM1 de planification et de pilotage peut servir de grille pour classifier les usages avant l’échantillonnage. Cette classification évite de traiter un rapport annuel comme un tableau de saisie quotidien.
Aucun environnement Planning Analytics propre à votre organisation n’a été ouvert pour cet article. La méthode présentée s’appuie donc sur la documentation IBM consultée le 18 juin 2026 et sur les objets techniques documentés par l’éditeur. Les scripts, règles et droits de votre parc doivent être inspectés dans votre environnement avant toute décision de bascule.
Quand faut-il reconstruire une application TM1 plutôt que la reprendre ?
La reprise n’est pas toujours la décision la moins coûteuse. Une application TM1 peut accumuler des dimensions obsolètes, des règles sans documentation, des processus de chargement doublonnés et des écrans Excel dont personne ne connaît le propriétaire. Copier cet ensemble dans IBM Planning Analytics prolonge parfois un problème qui aurait dû être arrêté.
La reconstruction devient défendable lorsque l’usage a fortement diminué, que les règles de gestion ont changé ou que le modèle ne sert plus qu’à produire quelques états. Elle demande cependant une décision explicite. Reconstruire n’est pas moderniser une présentation. C’est redéfinir les cubes, les indicateurs, les droits et les processus de planification.
Le seuil dépend du volume réellement utilisé et de la dette de modèle
Un petit parc de dix à vingt rapports très utilisés peut justifier une reprise complète si les règles restent maîtrisées et si les fichiers Excel ont un rôle de saisie reconnu. À l’inverse, cent classeurs peu ouverts, reposant sur des macros non maintenues, peuvent constituer un candidat à la reconstruction progressive.
La décision ne doit pas s’appuyer sur le nombre de fichiers seul. Il faut mesurer le nombre de processus actifs, la complexité des règles, la quantité de droits spécifiques et la criticité des cycles couverts. Un unique classeur de prévision de trésorerie peut être plus risqué que cinquante tableaux de consultation mensuelle.
Le tableau suivant ne donne pas une règle automatique. Il sert à rendre l’arbitrage visible devant les responsables métier, l’équipe IT et la direction financière.
| Situation observée | Indicateur de reprise | Indicateur de reconstruction | Décision à instruire |
|---|---|---|---|
| Modèle de budget encore utilisé chaque mois | Règles connues, cubes stables, responsables identifiés | Faible | Reprendre le moteur et moderniser les interfaces par étapes |
| Parc de classeurs Excel très ancien | Quelques rapports critiques seulement | Macros absentes de la documentation, propriétaires inconnus | Mesurer l’usage et reconstruire les objets réellement nécessaires |
| Application de saisie multi-entités | Workflow métier encore valide | Dimensions et droits incohérents entre entités | Reprendre le noyau puis traiter les droits et hiérarchies en chantier séparé |
| Rapports de pilotage peu ouverts | Résultats encore utilisés pour une obligation précise | Doublons, indicateurs non expliqués, faible fréquence d’accès | Ne pas migrer avant validation de l’utilité métier |
Ce croisement s’appuie sur les objets présents dans TM1 et Planning Analytics, ainsi que sur les principes de recette décrits par IBM dans sa documentation produit consultée le 18 juin 2026. Il ne remplace pas un relevé d’usage. Sans logs fiables, aucune ligne ne peut être classée sans risque.
La bascule doit être arrêtée si les preuves de recette manquent
Une bascule doit être reportée si les règles de calcul critiques ne sont pas rapprochées, si les droits n’ont pas été testés par des utilisateurs réels ou si les alimentations ne sont pas stabilisées. Ce report a un coût, mais il reste préférable à la découverte d’un écart de consolidation pendant une clôture.
À l’inverse, maintenir une version ancienne peut être raisonnable pendant quelques mois si le modèle fonctionne, si le support contractuel est confirmé et si le projet de cible n’est pas encore cadré. Cette décision doit inclure une date de revue et un inventaire mis à jour. Rester ne doit jamais signifier ne rien documenter.
Avant d’engager une reprise globale, exportez les accès sur douze mois, listez les processus TurboIntegrator exécutés en production et faites valider par les métiers les dix objets qui produisent les chiffres de référence. Le dimensionnement du chantier dépend de cette liste, pas du nombre de dossiers présents sur un serveur.
IBM Planning Analytics est-il un nouveau produit distinct de TM1 ?
Planning Analytics reprend le moteur TM1 et ajoute ou modernise les interfaces autour de ce moteur. La reprise des cubes, dimensions, règles et processus reste donc possible, sous réserve des versions, des dépendances et de la recette.
Peut-on conserver des rapports Perspectives après une migration ?
Des usages Perspectives peuvent être conservés pendant une période de transition selon la version et le support applicables. La trajectoire doit néanmoins prévoir l’examen de Planning Analytics for Excel, car Perspectives n’est pas l’interface appelée à recevoir les mêmes évolutions.
Pourquoi les macros VBA demandent-elles une recette spécifique ?
Une macro peut piloter des vues TM1, appliquer des filtres, lancer des rafraîchissements ou déclencher des exports. Le fait qu’un classeur s’ouvre dans Excel ne prouve pas que cette chaîne fonctionne avec PAX ou avec les droits de la cible.
Faut-il migrer tous les cubes et tous les rapports TM1 ?
Non. Les logs d’usage, la criticité métier et les dépendances doivent permettre d’écarter les objets abandonnés. Reprendre un rapport non consulté augmente la charge de recette sans améliorer le pilotage.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
