Moderniser sa BI historique : que conserver, migrer ou reconstruire ?

Définir ce que la modernisation doit réellement améliorer

Une plateforme SQL Server, SSIS, SSAS et SSRS peut concentrer des années de connaissance métier. Ses limites sont parfois visibles : traitements nocturnes trop longs, dépendance à quelques experts, demandes de modification coûteuses, rapports difficilement accessibles. Pourtant, remplacer ses composants ne garantit ni de meilleurs indicateurs ni une réduction des coûts. Le premier travail consiste à relier chaque difficulté à une conséquence mesurable.

Retenez quelques résultats attendus : avancer l’heure de disponibilité des données, réduire les reprises manuelles, faciliter une nouvelle analyse ou sécuriser une clôture. Établissez un niveau de départ et une cible validée avec les utilisateurs. « Migrer cent rapports » décrit une production du projet ; « disposer des chiffres validés avant la réunion de production » décrit un service rendu.

La trajectoire dépend aussi des contraintes : données conservées sur site, disponibilité des équipes, versions utilisées, exigences de reprise et calendrier métier. Vérifiez le support de chaque version auprès de l’éditeur, sans déduire l’obsolescence d’un composant de son ancienneté. Un système stable peut rester utile pendant qu’un autre périmètre évolue. Le cadrage doit aboutir à une décision explicite : pourquoi changer, pour quels usages et avec quelles preuves de réussite.

Comprendre les rôles de SQL Server, SSIS, SSAS, SSRS et Fabric

La stack historique sépare généralement stockage, intégration, calcul métier et restitution. Cette séparation reste utile pour raisonner, même lorsqu’une plateforme réunit plusieurs fonctions. Power BI comprend une couche de modèles sémantiques et une couche de rapports ; ce n’est pas uniquement un outil de visualisation. Fabric est une plateforme plus large, qui inclut notamment intégration, ingénierie de données, entrepôt et Power BI autour de services partagés.

Le tableau permet de poser les premières questions d’architecture. Il ne constitue pas une correspondance automatique entre un ancien produit et son remplaçant. Par exemple, conserver l’entrepôt SQL Server tout en faisant évoluer certaines restitutions peut suffire à atteindre un objectif métier.

Inventorier les chaînes utilisées, y compris leurs dépendances cachées

Un inventaire de serveurs et de rapports est insuffisant. Reconstituez une chaîne complète : source, extraction, zone intermédiaire, traitement, table, cube ou modèle, rapport, export, destinataire et décision. Cherchez les traitements SQL Server Agent, procédures stockées, scripts PowerShell, macros Excel, fichiers déposés sur des partages et interfaces alimentées par des exports. Un rapport peu consulté peut produire un fichier indispensable à une application.

Combinez journaux d’exécution et entretiens. Un historique de trente jours ne révèle pas nécessairement un rapport trimestriel ou une clôture annuelle. Qualifiez les fréquences rares avec leurs propriétaires. Pour chaque objet, relevez l’usage réel, la criticité, les dépendances entrantes et sortantes, le propriétaire métier et le mainteneur technique.

Ajoutez les caractéristiques d’exploitation : durée médiane et maximale, volumes traités, croissance, créneau d’exécution, incidents, reprise après échec et niveau de fraîcheur attendu. Distinguez taille des tables, taille compressée du modèle et mémoire nécessaire pendant son actualisation. Ces dimensions ne se déduisent pas simplement les unes des autres.

Le livrable utile est une carte des dépendances accompagnée d’une liste d’incertitudes. Chaque dépendance inconnue doit avoir une action de vérification. Cette carte permet de découper les lots sans interrompre une chaîne voisine et d’identifier les données communes qui doivent rester cohérentes pendant la transition.

Arbitrer entre conserver, déplacer, adapter, reconstruire et retirer

Décidez au niveau des chaînes métier plutôt qu’avec une règle identique pour tous les composants. Un transfert d’hébergement peut répondre à une contrainte d’infrastructure sans changer les usages. Une reconstruction se justifie lorsque le besoin, les règles ou l’architecture doivent évoluer sensiblement. Confondre ces deux démarches produit des engagements difficiles à tenir.

Le coût complet inclut l’analyse, les développements, les recettes, les formations, les licences, les capacités de calcul, les connexions réseau, le support et la coexistence des environnements. Distinguez coût initial, coût récurrent et coût transitoire. Une licence déjà achetée n’est pas forcément un coût évitable ; son économie dépend de la résiliation effective et des engagements contractuels.

Chiffrez plusieurs scénarios avec des hypothèses identiques de volumétrie, de concurrence et de service. Faites confirmer les droits d’usage et les conditions de licences du scénario retenu. Une capacité cloud disponible ne prouve ni sa bonne taille ni la rentabilité de la migration.

Formaliser le contrat des indicateurs avant de réécrire les calculs

Le principal risque d’une migration sémantique est d’obtenir un chiffre plausible avec un sens différent. Pour chaque indicateur critique, consignez son grain, sa formule, ses exclusions, sa date de référence, son unité, ses conversions et sa règle d’agrégation. Précisez le traitement des données manquantes et des corrections tardives. Distinguez une valeur nulle, un zéro et une donnée non encore disponible.

Certaines mesures s’additionnent entre sites mais pas entre dates. Un stock de fin de mois ne doit pas être additionné sur douze mois pour produire un stock annuel. Un taux se recalcule généralement à partir de ses composants, plutôt qu’en faisant la moyenne des taux affichés. Un nombre distinct de fournisseurs n’est pas la somme des nombres distincts par famille lorsqu’un fournisseur appartient à plusieurs familles.

Examinez aussi les changements de périmètre : rattachement historique d’un établissement, organisation courante, devises, calendriers et versions budgétaires. La migration doit choisir quelle lecture conserver et documenter les éventuelles évolutions. Une correction métier acceptée peut créer un écart légitime avec l’ancien système ; elle exige alors une validation distincte.

Ce contrat devient le référentiel de recette. Il appartient au métier responsable de l’indicateur, avec une traduction technique maintenue par l’équipe data. Il évite de prendre le résultat historique comme une vérité absolue lorsque celui-ci contient une erreur connue.

SSIS : distinguer déplacement des packages et refonte des flux

Commencez par classer les packages : simples copies, transformations complexes, appels de procédures, scripts, composants tiers ou interactions avec le système de fichiers. Examinez les pilotes, configurations, secrets, paramètres, comptes de service et accès réseau. Une exécution réussie dans un environnement de développement ne démontre pas que les dépendances seront disponibles dans l’environnement cible.

Azure Data Factory propose un Azure-SSIS Integration Runtime pour exécuter des packages SSIS dans un environnement Azure géré. Cette possibilité doit être évaluée avec le stockage du catalogue, la connectivité, les composants installés et l’ordonnancement. Déplacer les packages ne remplace pas le travail sur les déclenchements, les reprises et la supervision.

Fabric propose également l’activité Invoke SSIS Package, indiquée en préversion dans la documentation consultée. Les limitations documentées concernent notamment les sources et destinations sur site, les réseaux privés et les composants personnalisés ou tiers. Les packages doivent être stockés dans OneLake. Vérifiez ces conditions au moment du choix : cette activité ne signifie pas que tout patrimoine SSIS devient immédiatement compatible avec Fabric.

Pour les flux reconstruits, testez les traitements incrémentaux, les suppressions, les données arrivées tardivement et la capacité à rejouer un lot sans doublonner. Définissez ce qui se passe lorsqu’une extraction réussit mais que le chargement suivant échoue. La robustesse d’une migration se mesure particulièrement dans ces chemins de reprise.

SSAS : traiter séparément les modèles multidimensionnels et tabulaires

Un cube SSAS multidimensionnel ne se déploie pas directement comme un modèle sémantique tabulaire Power BI. Le changement demande de repenser les relations et de traduire les règles utiles. Inventoriez les calculs MDX, affectations SCOPE, membres calculés, hiérarchies parent-enfant, membres par défaut et mécanismes de saisie éventuels. Une ressemblance visuelle entre deux rapports ne valide pas la traduction.

Une trajectoire intermédiaire consiste parfois à conserver le cube et à y connecter de nouveaux rapports Power BI en mode live. Microsoft documente cette connexion, avec des restrictions : les actions et ensembles nommés ne sont pas exposés ; la sécurité au niveau des cellules peut empêcher la connexion des utilisateurs concernés. Éprouvez les fonctions réellement utilisées avant de retenir cette coexistence.

Les modèles tabulaires partagent davantage de concepts avec les modèles Power BI, mais leur transfert nécessite encore de vérifier niveaux de compatibilité, sources, partitions, identités et ressources. Les mécanismes documentés pour migrer Azure Analysis Services vers Power BI ont leur propre périmètre ; ils ne constituent pas une procédure universelle pour tout serveur SSAS.

Construisez un prototype avec les calculs difficiles et les plus gros volumes, pas seulement avec quelques sommes simples. Faites aussi essayer les classeurs Excel connectés au modèle : les utilisateurs peuvent dépendre de noms de mesures, de hiérarchies ou de chemins de connexion absents du catalogue des rapports.

SSRS : préserver les documents et distributions qui servent aux opérations

Un tableau de bord interactif et un document paginé rendent des services différents. Un état de clôture, une liste exhaustive ou un document à imprimer doit parfois respecter un format précis, des sauts de page et un ordre stable. Préservez ces exigences lorsque vous faites évoluer les outils.

Microsoft documente la migration de fichiers RDL vers des rapports paginés Power BI. Elle comporte des contrôles de compatibilité et ne transforme pas ces fichiers en rapports interactifs classiques. Les sources partagées et jeux de données partagés au format SSRS, les rapports liés et les assemblies personnalisées font notamment partie des points à examiner.

Recettez les paramètres, les exports PDF et Excel, la pagination, les accents et les volumes maximaux. Traitez séparément les abonnements et distributions individualisées : destinataires, filtrage, calendrier, pièces jointes, reprise sur erreur et preuve d’envoi. Le simple affichage du rapport dans le navigateur ne démontre pas que la chaîne de diffusion fonctionne.

Une migration peut conserver un petit ensemble de rapports paginés tout en rationalisant les analyses interactives autour de modèles communs. L’objectif est une restitution adaptée au besoin, avec des règles partagées et une maintenance soutenable.

Tester les identités, les droits et la charge réelle

Établissez une matrice reliant profils utilisateurs, périmètres de données et actions autorisées : consulter, exporter, construire un rapport, administrer. Vérifiez les comptes techniques, les accès aux sources et l’identité effectivement transmise à chaque couche. Un filtre dans un visuel ne constitue pas un contrôle d’accès.

Dans Power BI, la sécurité au niveau des lignes, ou RLS, ne restreint pas les rôles d’espace de travail Admin, Member et Contributor. Les tests doivent donc utiliser des profils de consultation représentatifs. Avec une connexion live à Analysis Services, les règles se définissent dans le modèle source. Les exports et accès directs doivent également être inclus dans la recette.

Pour la performance, rejouez des requêtes et actualisations simultanées avec des volumes réalistes. Mesurez temps de réponse, files d’attente, consommation de ressources et impact sur les systèmes sources. Testez un démarrage sans cache puis un usage courant. Une moyenne satisfaisante peut masquer quelques rapports trop lents au moment de la clôture.

Choisissez le mode de stockage et d’accès selon ces résultats. Un mode connecté ne garantit pas une meilleure fraîcheur de bout en bout si les sources sont chargées tardivement. Une solution rapide en démonstration peut devenir coûteuse lorsque plusieurs équipes sollicitent les mêmes ressources.

Prouver la parité avec un jeu de données et des règles de comparaison

Comparez les deux solutions sur un même état des données, avec les mêmes paramètres, versions de référentiels, dates de clôture et règles de change. Sinon, les écarts de chargement risquent d’être interprétés comme des défauts de calcul. Conservez les données de test et les versions de code permettant de reproduire les résultats.

La recette doit couvrir totaux, détails et cas limites. Une égalité du total général peut masquer des écarts opposés entre établissements. Classez chaque différence : incident de données, défaut de traduction, correction métier acceptée ou variation expliquée par une règle d’arrondi. Aucune catégorie ne doit devenir un tiroir pour écarts inexpliqués.

Exemple fictif : moderniser un pilotage industriel par étapes

Considérons un groupe fictif de huit sites, avec 70 packages SSIS, trois cubes et 120 rapports SSRS. Ces nombres décrivent un scénario pédagogique, pas une mission réalisée par Juste Data. L’inventaire identifie 25 rapports sans usage confirmé, mais leur retrait attend la validation des propriétaires et le contrôle des traitements dépendants.

Le groupe choisit un premier périmètre de suivi des arrêts de production. L’entrepôt SQL Server et les extractions existantes restent en place. Un modèle tabulaire et deux rapports Power BI sont construits sur des tables validées. La clôture financière et ses documents paginés conservent leur fonctionnement pendant ce premier lot.

La recette détecte qu’un arrêt commencé avant minuit était entièrement affecté au jour de début dans le système historique. Les opérations souhaitent désormais répartir la durée sur les journées concernées. Ce changement est approuvé et versionné ; l’équipe produit un rapprochement expliquant l’écart plutôt que de forcer artificiellement l’égalité des résultats.

Après validation des droits, de la fraîcheur et des performances, une période de fonctionnement parallèle couvre les situations convenues. Le pilote sert à estimer les lots suivants avec des mesures réelles : effort de reprise des règles, temps de recette et charge d’exploitation. Le calendrier global est ajusté à partir de ces constats.

Préparer la bascule, le retour arrière et l’exploitation durable

Fixez avant la mise en production les critères de bascule : indicateurs approuvés, accès vérifiés, objectifs de service tenus, utilisateurs accompagnés et support mobilisé. La coexistence doit avoir une durée et une sortie prévues, adaptées aux cycles métier. Tout report de fermeture de l’ancien environnement doit avoir une cause, un responsable et une nouvelle décision.

Le plan de retour arrière décrit les versions à restaurer, les connexions à rétablir et la synchronisation des données. Précisez le délai pendant lequel le retour reste possible. Lorsque la nouvelle chaîne écrit des données ou produit des fichiers consommés ailleurs, revenir aux anciens rapports ne suffit pas : il faut aussi éviter omissions et doubles traitements.

Confiez chaque chaîne à un propriétaire métier et à un responsable d’exploitation. Documentez déploiement, supervision, alertes, reprises, rotation des secrets et escalade. Surveillez la fraîcheur et la qualité des données en plus du succès technique des traitements. Une tâche verte peut produire un indicateur incomplet.

Enfin, décommissionnez méthodiquement : archives nécessaires, suppression des accès inutiles, arrêt des traitements, fermeture des infrastructures et ajustement des contrats. Les économies attendues deviennent mesurables à ce stade. Chez Juste Data, nous cadrons ces trajectoires en reliant architecture, règles métiers, recette et capacité réelle des équipes à maintenir le service.

Questions fréquentes