Avant et pendant une migration vers Microsoft Fabric, mettez en place quatre éléments : un inventaire de vos rapports, une liste des rapports à retirer, un responsable désigné par rapport et une définition validée pour chaque KPI. La migration est le moment où cette démarche coûte le moins cher, puisque chaque rapport est de toute façon ouvert, reconstruit ou abandonné. Purview et Fabric prennent ensuite en charge la sécurité, les étiquettes et la traçabilité des données. Si vous attendez la mise en production, vous ne ferez que transférer la confusion existante sur une nouvelle plateforme.
Pourquoi la migration est le bon moment pour clarifier la gouvernance
La plupart des plans de projet prévoient la gouvernance après la mise en production, une fois la plateforme stabilisée. Cela semble logique. C'est aussi l'ordre qui coûte le plus cher.
Pendant une migration, quelqu'un ouvre chaque rapport pour décider s'il sera migré. C'est le moment tout indiqué pour poser trois questions : quelqu'un l'utilise-t-il encore, qui en est responsable et que signifient ses KPI ? Après la mise en production, personne n'ouvre un rapport qui fonctionne pour se poser ces questions. Elles ne ressurgissent que lorsque deux chiffres se contredisent en réunion.
Prenons un exemple : une équipe migre un rapport commercial qui présente le « chiffre d'affaires » d'une certaine manière, et un rapport financier qui le présente autrement. Les deux passent dans Fabric sans modification. Six mois plus tard, le directeur financier demande pourquoi le dossier destiné au conseil d'administration ne correspond pas au tableau de bord commercial. L'équipe doit alors démêler le problème sur une plateforme déjà en production.
La feuille de route de Microsoft pour l'adoption de Fabric, publiée sur Microsoft Learn, présente elle-même la responsabilité des contenus et la gouvernance comme des sujets à prévoir dès le départ, et non à ajouter après coup.
La checklist en quatre volets : inventorier, retirer, attribuer, définir
1. Inventorier
Répertoriez chaque rapport Power BI et chaque modèle sémantique concernés, avec leur espace de travail et leur fréquence d'utilisation.
- Ce mois-ci : exportez la liste des espaces de travail et des éléments, puis ajoutez les données d'utilisation provenant des métriques d'utilisation de Power BI ou de l'espace de travail de supervision des administrateurs Fabric.
- Livrable : une feuille de calcul regroupant tous les rapports, leur espace de travail, leur responsable technique et leurs consultations récentes.
2. Retirer
Décidez de ce qui ne sera pas migré. Les rapports que personne n'ouvre, les doublons et les analyses ponctuelles représentent un coût de migration sans bénéfice.
- Ce mois-ci : indiquez pour chaque rapport s'il faut le migrer, le fusionner ou le retirer. Convenez d'une règle, par exemple : « aucune consultation au cours du dernier trimestre entraîne le retrait, sauf objection ».
- Livrable : une liste des rapports à retirer validée par les métiers, et pas uniquement par l'IT.
3. Attribuer
Désignez un responsable métier pour chaque rapport à migrer. Une personne, pas une équipe ni le développeur qui l'a créé.
- Ce mois-ci : pour chaque rapport à migrer, demandez au responsable technique qui décide de ce que les chiffres doivent représenter. Consignez le nom de cette personne.
- Livrable : un responsable désigné par rapport, ainsi que par KPI lorsqu'un KPI figure dans plusieurs rapports.
4. Définir
Rédigez une définition validée pour chaque KPI repris dans un rapport destiné à la direction ou au conseil d'administration.
- Ce mois-ci : commencez par les KPI présents dans plusieurs rapports. Convenez de la définition de chacun avec son responsable, en une phrase simple.
- Livrable : une définition par KPI, utilisée par tous les rapports qui le présentent après la migration.
Ce que Purview et Fabric vous apportent déjà
Vous ne devez pas construire la gouvernance de la plateforme à partir de zéro. Selon la documentation de Microsoft, Fabric et Purview vous fournissent :
- Des domaines et des espaces de travail pour regrouper les contenus par domaine métier.
- Des rôles d'espace de travail pour contrôler qui peut consulter, créer et publier.
- L'approbation, qui permet d'attribuer à un rapport ou à un modèle sémantique le statut Promu ou Certifié.
- Des étiquettes de confidentialité et la prévention des pertes de données de Microsoft Purview, appliquées aux éléments Fabric.
- La traçabilité des données dans Fabric, ainsi que l'analyse par Purview Data Map des métadonnées et de la traçabilité à l'échelle du tenant.
- Un glossaire métier et des contrôles de qualité des données dans le catalogue unifié de Purview, à l'intention des gestionnaires de données.
Mettez également ces éléments en place pendant la migration. Mais regardez ce qui manque. Aucun ne décide quels rapports retirer, qui est responsable d'un KPI ou ce qu'il signifie. Ce sont des décisions métier, et la migration est le moment où vous pouvez les prendre.
Ce qui se passe quand vous faites l'impasse sur la gouvernance
Faire l'impasse sur la gouvernance ne ralentit pas la migration. Cela l'accélère. La facture arrive plus tard.
| Tâche | Pendant la migration | Après la mise en production |
|---|---|---|
| Retirer les rapports inutilisés | Ne pas les migrer | Les retrouver, vérifier que personne ne les utilise, puis les supprimer |
| Désigner un responsable | Poser la question au moment où le rapport est de toute façon ouvert | Relancer des personnes déjà passées à autre chose |
| Valider la définition d'un KPI | Trancher une fois, avant la reconstruction des rapports | Reconstruire des rapports déjà en production |
| Expliquer les chiffres aux utilisateurs | Fournir les définitions avec les nouveaux rapports | Répondre aux mêmes questions dans les tickets d'assistance |
En pratique, faire l'impasse revient à reproduire le désordre existant sur une nouvelle plateforme. Les utilisateurs constatent que rien n'a changé, et la confiance dans la nouvelle plateforme est faible dès le départ.
Le rôle de dScribe
Cette checklist repose avant tout sur des décisions prises par votre équipe. dScribe réduit une partie du travail manuel qu'elles impliquent et les garde visibles après la mise en production. Il lit uniquement les métadonnées : vos données ne sont donc pas déplacées.
- Inventorier : dScribe parcourt les métadonnées de vos anciens systèmes et en dresse l'inventaire. Vous partez ainsi d'une liste complète plutôt que d'un export manuel.
- Retirer : des suggestions intelligentes aident à détecter les doublons. Des propriétés flexibles vous permettent de marquer un rapport comme retiré et vous donnent une vue d'ensemble des rapports retirés à supprimer dans le système source.
- Attribuer : vous désignez le responsable de chaque rapport et de chaque KPI dans dScribe, afin que chacun puisse retrouver son nom.
- Définir : des suggestions intelligentes aident à définir les KPI et à les relier aux rapports et aux jeux de données dans lesquels ils figurent. La définition d'un KPI reste en partie manuelle, mais les suggestions allègent le travail. Vous pouvez aussi voir quels rapports utilisent une définition de mesure donnée.
- Naviguer : vous définissez la traçabilité des données dans dScribe, avec l'aide de suggestions intelligentes, pour permettre aux utilisateurs de remonter d'un rapport à ses sources.
Après la mise en production, l'extension de navigateur affiche la définition et le responsable sur les rapports Power BI que les utilisateurs ouvrent. Les décisions prises pendant la migration restent ainsi visibles, au lieu de finir dans une feuille de calcul du projet.
Pour conclure
Une migration vers Fabric est le seul moment où votre équipe ouvre volontairement chaque rapport. Profitez-en. Décidez de ce qu'il faut abandonner, de qui sera responsable des rapports conservés et de ce que signifie chaque KPI, avant de reconstruire les rapports. Purview et Fabric assureront la gouvernance de la plateforme. C'est à vous de clarifier le sens des chiffres, et cela ne coûtera jamais moins cher que maintenant.
Questions fréquentes
Que faut-il mettre en place pour la gouvernance des données pendant une migration vers Microsoft Fabric ?
Un inventaire des rapports, une liste des rapports à retirer, un responsable désigné par rapport et une définition par KPI. En parallèle, configurez les domaines Fabric, les rôles d'espace de travail, l'approbation et les étiquettes de confidentialité de Purview.
Faut-il prévoir la gouvernance avant ou après une migration vers Fabric ?
Pendant la migration. Chaque rapport est ouvert à cette occasion : c'est donc le moment où les décisions sur les responsabilités et les définitions coûtent le moins cher. Après la mise en production, personne ne réexamine un rapport qui fonctionne.
Microsoft Purview suffit-il pour la gouvernance lors d'une migration vers Fabric ?
Il couvre la gouvernance de la plateforme : étiquettes, prévention des pertes de données, audit, traçabilité des données et glossaire pour les équipes data. Il ne décide pas quels rapports retirer, qui est responsable d'un KPI ou ce qu'il signifie.
Quels rapports Power BI ne faut-il pas migrer vers Fabric ?
Les rapports que personne n'a ouverts récemment, les doublons d'autres rapports et les analyses ponctuelles. Utilisez les métriques d'utilisation pour les repérer et faites valider la liste des rapports à retirer par les métiers.
Qui doit être responsable d'un rapport Power BI après la migration ?
Une personne désignée côté métier, qui décide de ce que les chiffres doivent représenter. Pas une équipe, ni uniquement le développeur qui a créé le rapport.