Workspace Maturity Index — 3 axes pour scorer ta plateforme BI

Ce document te donne un index 0–100 pour mesurer objectivement la maturité de ta plateforme Power BI / Microsoft Fabric sur 3 axes : Architecture & Industrialisation, Gouvernance & Conformité, Valeur & Adoption. Un cas réel anonymisé (banque régionale, ~2 000 collaborateurs) illustre comment passer d'un score de 34/100 à 71/100 en 18 mois. Chaque niveau — Basic, Intermediate, Advanced, Best-in-class — est défini par des seuils chiffrés actionnables, pas des descriptions vagues. Tu repars avec une grille de scoring prête à remplir en atelier avec ton équipe.

Pourquoi ce document existe

La plupart des BI Managers pilotent leur plateforme Power BI à l'estime. Ils savent combien de rapports existent, parfois combien d'utilisateurs se connectent, mais ils ne peuvent pas répondre aux questions que leur posent le DSI ou le DAF : est-ce qu'on est conformes RGPD sur nos workspaces ? Quel est notre taux d'incidents liés aux refreshs ? Quelle part de nos rapports est réellement utilisée ? Sans cadre objectif, chaque décision d'investissement — licences Fabric, recrutement, refonte d'architecture — repose sur des impressions. Ce document corrige ça.

1. Pourquoi mesurer la maturité, et pas juste l'usage

Mesurer l'usage (nombre de vues, nombre d'utilisateurs actifs) dit ce que les gens font avec ta plateforme. Mesurer la maturité dit si ta plateforme est capable de tenir ses promesses dans la durée, sous contrainte réglementaire et opérationnelle. En banque-assurance, la différence est critique : l'ACPR attend une traçabilité des données utilisées dans les reportings prudentiels, le RGPD impose une maîtrise des accès et des durées de conservation, et DORA — applicable depuis janvier 2025 — introduit des exigences explicites sur la résilience des systèmes d'information, y compris les outils analytiques tiers (Digital Operational Resilience Act, RTS publiés au JOUE 2024). Une plateforme très utilisée mais non gouvernée est un passif réglementaire, pas un actif. C'est exactement ce que mesure cet index.

2. Les 3 axes × 4 niveaux : vue d'ensemble

Le score total est sur 100. Chaque axe est noté de 0 à 100, puis pondéré selon les poids ci-dessous, calibrés pour le contexte banque-assurance.

La pondération forte sur la gouvernance reflète le poids réglementaire spécifique au secteur. Gartner note dans son Magic Quadrant Analytics & BI 2024 que les organisations du secteur financier classent la gouvernance des données comme priorité n°1 devant la performance technique, un constat stable depuis trois éditions consécutives.

Tableau de maturité global — 4 niveaux par axe

3. Grille de scoring détaillée par axe

Axe 1 — Architecture & Industrialisation (35 pts sur 100 pondérés)

Cet axe mesure si ta plateforme peut livrer de façon fiable, reproductible et supervisée. En pratique, il répond à la question : est-ce qu'un incident de refresh à 7h du matin est détecté par ton équipe avant que le contrôleur de gestion t'appelle ?

Microsoft Fabric expose nativement des fonctions de workspace monitoring et d'analyse de logs qui permettent d'objectiver une grande partie de cet axe (Microsoft Fabric — What's new, documentation officielle).

Cas anonymisé — banque régionale (~2 000 collaborateurs) : Au démarrage de l'accompagnement, le score Axe 1 était de 8/35. Zéro Git, 47 workspaces créés sans pipeline, MTTR refresh moyen de 6 h (mesuré a posteriori sur les logs d'activité Fabric). Après 12 mois : Git sur 90 % des workspaces, pipelines DEV/TEST/PROD opérationnels, MTTR ramené à 1 h 20. Score Axe 1 : 22/35.

Axe 2 — Gouvernance & Conformité (40 pts sur 100 pondérés)

C'est l'axe le plus lourd en banque-assurance, et le plus souvent sous-estimé. Il couvre trois périmètres distincts qu'il faut traiter séparément : la sécurité technique (qui accède à quoi), la conformité réglementaire (RGPD, ACPR, DORA), et l'auditabilité (capacité à prouver la maîtrise en cas de contrôle).

L'ACPR a publié des orientations sur le risque informatique qui s'appliquent directement aux outils analytiques utilisés dans les reportings prudentiels — la traçabilité du lineage de données et la séparation des environnements y sont explicitement attendues. DORA, applicable depuis le 17 janvier 2025, renforce ces exigences sur la résilience opérationnelle numérique pour l'ensemble des entités financières régulées (EBA — DORA RTS, 2024).

Cas anonymisé — banque régionale : Score Axe 2 initial : 11/40. Zéro sensitivity label, 3 workspaces PROD accessibles en Member à des prestataires externes sans revue d'accès depuis 14 mois, lineage non exploité. Après 18 mois : labels sur 85 % des actifs, revue d'accès trimestrielle opérationnelle, lineage documenté pour les 6 reportings prudentiels critiques. Score Axe 2 : 29/40.

Axe 3 — Valeur & Adoption (25 pts sur 100 pondérés)

Cet axe répond à la question que pose le DAF : est-ce qu'on en a pour notre argent ? Il ne s'agit pas de compter les rapports publiés, mais de mesurer si la plateforme crée réellement de la valeur opérationnelle et si les métiers s'en emparent durablement.

Une étude Gartner Magic Quadrant for Analytics and Business Intelligence Platforms 2024 indique que 60 % des projets BI échouent à démontrer un ROI mesurable dans les 24 mois suivant le déploiement, principalement par absence de mesure de l'adoption et de gouvernance du catalogue de contenus. Ce chiffre est cohérent avec ce qu'on observe sur le terrain en banque-assurance française.

Cas anonymisé — banque régionale : Score Axe 3 initial : 15/25. Taux d'utilisateurs actifs de 38 %, mais 0 modèle sémantique certifié, délai moyen de livraison de 18 jours, satisfaction jamais mesurée. Après 18 mois : 2 modèles sémantiques certifiés couvrant 60 % des rapports de gestion, délai moyen ramené à 8 jours, NPS mesuré à 34. Score Axe 3 : 20/25.

Score total — banque régionale : Initial 34/100 → Final 71/100 en 18 mois. La progression la plus forte est sur l'axe Gouvernance (+18 pts), ce qui reflète le point de départ très bas sur les contrôles d'accès et la classification des données.

Tableau de lecture des scores globaux

Dans la partie suivante, on traitera la roadmap concrète par niveau — les 5 à 8 actions prioritaires pour passer de Basic à Intermediate, d'Intermediate à Advanced, et d'Advanced à Best-in-class — avec les ressources Fabric natives à activer en premier et les pièges à éviter en contexte banque-assurance.

Cas concret : compagnie d'assurance vie — de 32/100 à 78/100 en 12 mois

Contexte

Compagnie d'assurance vie française, bilan total autour de 8 Md€, environ 420 collaborateurs, filiale d'un groupe mutualiste. La DSI compte 12 personnes, dont 2 dédiées à la BI. Avant la mission : Power BI déployé depuis 3 ans, mais sans gouvernance formalisée. Aucun pipeline CI/CD, 0 label de sensibilité appliqué, 47 workspaces actifs dont 31 sans propriétaire identifié.

Score initial : 32/100

Risque principal identifié : exposition RGPD directe sur les données assurés (données de santé dans plusieurs rapports de souscription), et dépendance totale à deux personnes clés pour les publications en production.

Actions conduites sur 12 mois

Mois 1–3 — Gouvernance en urgence

• Audit complet des 47 workspaces : 18 archivés, 29 rationalisés avec propriétaire nommé.
• Déploiement des sensitivity labels Microsoft Purview sur 100 % des datasets contenant des données assurés : passage de 0 % à 94 % de couverture en 8 semaines.
• Mise en place d'une revue d'accès trimestrielle outillée via les rapports d'audit Fabric.
• Séparation DEV / UAT / PROD formalisée avec des workspaces dédiés et des règles de promotion documentées.

Mois 3–7 — Industrialisation

• Intégration Git sur les 6 workspaces de production prioritaires (modèles de provisionnement, reporting ACPR).
• Déploiement des pipelines de déploiement Fabric natifs : 0 publication manuelle sur les périmètres critiques.
• Activation du workspace monitoring Fabric : tableau de bord de supervision des refresh, alertes sur échec, MTTR ramené de > 4 h à 38 min en moyenne.
• Formalisation de 3 SLO : disponibilité des rapports réglementaires à 99,5 %, délai de refresh < 30 min, MTTR < 1 h.

Mois 7–12 — Valeur et adoption

• Certification de 4 modèles sémantiques couvrant 68 % des rapports de gestion et des reportings Solvabilité II.
• Mise en place d'un catalogue de contenus certifiés dans le portail Power BI.
• Délai moyen de livraison ramené de 22 à 7 jours grâce aux templates et aux modèles réutilisables.
• Automatisation de 76 % des reportings récurrents (reporting mensuel direction, tableaux de bord sinistres, états ACPR).
• NPS mesuré pour la première fois à 38 auprès des 14 directions métier.

Score final : 78/100

ROI quantifié : économie estimée à 1,8 ETP/an sur la production des reportings récurrents (valorisée à 90 k€/an), réduction des incidents de production de 73 %, et zéro finding RGPD lors de l'audit interne du groupe en mois 11. Durée totale de la mission : 12 mois, dont 3 mois d'accompagnement intensif et 9 mois de suivi mensuel.

Roadmap d'évolution stade par stade

La logique est simple : ne pas brûler les étapes. Une plateforme qui saute directement à l'outillage avancé sans gouvernance de base accumule de la dette réglementaire, pas de la maturité. Voici les 5 à 8 actions prioritaires par palier, avec les seuils chiffrés à atteindre avant de passer au suivant.

Palier 1 → Palier 2 : de "Opportuniste" à "Fondations" (score 0–25 → 26–50)

Objectif : sécuriser le minimum viable pour ne pas être en risque immédiat de conformité ou d'incident majeur.

Actions prioritaires

1. Inventaire et nettoyage des workspaces : cartographier tous les workspaces existants, nommer un propriétaire pour chacun, archiver ceux sans usage depuis 90 jours. Cible : 100 % des workspaces actifs avec un propriétaire identifié.
2. Séparation DEV / PROD : créer a minima deux environnements distincts avec des règles de promotion documentées, même manuelles dans un premier temps. Cible : 0 publication directe en production sans validation.
3. Premiers labels de sensibilité : appliquer Microsoft Purview sensitivity labels sur les datasets contenant des données personnelles ou confidentielles. Cible : ≥ 60 % des datasets sensibles labellisés en 6 semaines.
4. Activation des logs d'audit Fabric : activer la journalisation des activités workspace et configurer une rétention minimale de 90 jours. Cible : 100 % des workspaces de production couverts.
5. Identification des dépendances critiques : lister les 5 rapports les plus utilisés et documenter leur chaîne de données. Cible : lineage documenté pour les 5 actifs critiques.

Seuils de passage au palier suivant

• ≥ 80 % des workspaces actifs avec propriétaire nommé
• ≥ 1 environnement DEV séparé de PROD
• ≥ 50 % des datasets sensibles avec sensitivity label
• Logs d'audit activés et rétention ≥ 90 jours

Piège à éviter : vouloir tout gouverner d'un coup. Commencer par les 20 % d'actifs qui représentent 80 % de l'usage réel. Le reste suivra.

Palier 2 → Palier 3 : de "Fondations" à "Standardisation" (score 26–50 → 51–75)

Objectif : industrialiser la livraison, formaliser les contrôles, mesurer l'usage pour la première fois.

Actions prioritaires

1. Intégration Git sur les workspaces critiques : connecter les workspaces de production à un dépôt Git (Azure DevOps ou GitHub). Cible : 100 % des workspaces de production sous contrôle de version.
2. Pipelines de déploiement Fabric natifs : remplacer les publications manuelles par des pipelines DEV → UAT → PROD avec validation obligatoire. Cible : 0 déploiement manuel sur les périmètres réglementaires.
3. Monitoring des refresh et alerting : activer le workspace monitoring Fabric, configurer des alertes sur les échecs de refresh. Cible : MTTR moyen < 1 h, 100 % des échecs détectés avant signalement métier.
4. Certification des premiers modèles sémantiques : identifier les 3 à 5 modèles les plus réutilisés, les certifier formellement. Cible : ≥ 30 % des rapports actifs consommant un modèle certifié.
5. Première mesure de satisfaction métier : lancer un NPS ou un score de satisfaction simple auprès des directions clientes. Cible : mesure réalisée, baseline établie.
6. Revue d'accès semestrielle : formaliser et conduire une première revue des droits sur les workspaces de production. Cible : 100 % des workspaces de production revus, droits non justifiés supprimés.

Seuils de passage au palier suivant

• ≥ 80 % des workspaces de production sous Git
• MTTR refresh moyen < 1 h
• ≥ 30 % des rapports actifs sur modèle certifié
• Taux d'utilisateurs actifs mensuels ≥ 40 %
• ≥ 1 revue d'accès formalisée et documentée

Piège à éviter : certifier des modèles sans processus de maintenance. Un modèle certifié non maintenu devient un passif réglementaire. La certification doit s'accompagner d'un propriétaire et d'un SLA de mise à jour.

Palier 3 → Palier 4 : de "Standardisation" à "Maîtrise" (score 51–75 → 76–90)

Objectif : passer d'une plateforme qui fonctionne à une plateforme qui se pilote et qui démontre sa valeur en comité de direction.

Actions prioritaires

1. SLO/SLA formalisés et reportés : définir des SLO mesurables pour les actifs critiques (disponibilité, fraîcheur des données, MTTR). Cible : ≥ 5 SLO documentés, reportés mensuellement au CODIR ou au comité IT.
2. Automatisation ≥ 80 % des reportings récurrents : identifier les reportings encore produits manuellement, les automatiser via Fabric pipelines ou Power Automate. Cible : économie ETP quantifiée et présentée en revue budgétaire.
3. Lineage exploité pour l'audit : utiliser le lineage Fabric pour produire des preuves d'audit sur les données réglementaires (ACPR, Solvabilité II, COREP/FINREP selon le cas). Cible : lineage complet documenté pour 100 % des reportings réglementaires.
4. Tests automatiques sur les modèles critiques : mettre en place des tests de non-régression sur les KPI clés (valeurs de référence, seuils d'alerte). Cible : ≥ 3 modèles couverts par des tests automatiques.
5. Catalogue de contenus actif : publier un catalogue des rapports certifiés accessible aux métiers, avec description, propriétaire et fréquence de mise à jour. Cible : ≥ 70 % des rapports actifs référencés dans le catalogue.
6. Benchmark interne par BU : produire un score de maturité par domaine métier ou par BU pour identifier les zones de progrès. Cible : tableau de bord de maturité interne présenté trimestriellement.

Seuils de passage au palier suivant

• ≥ 5 SLO formalisés et reportés
• ≥ 80 % des reportings récurrents automatisés
• Lineage complet sur 100 % des reportings réglementaires
• NPS ≥ 35
• ≥ 60 % des rapports actifs sur modèle certifié

Piège à éviter : confondre automatisation et fiabilité. Un pipeline automatisé sans test ni alerting peut produire des données fausses pendant 48 h sans que personne ne le détecte. L'automatisation sans observabilité est un risque opérationnel, pas une solution.

Palier 4 → Palier 5 : de "Maîtrise" à "Excellence opérationnelle" (score 76–90 → 91–100)

Objectif : faire de la plateforme BI un actif stratégique piloté comme un produit, avec une conformité continue et une capacité d'adaptation aux évolutions réglementaires (DORA, RGPD, évolutions ACPR).

Actions prioritaires

1. Gouvernance des changements mature : intégrer la plateforme BI dans le processus de change management IT global, avec impact assessment systématique avant toute évolution majeure. Cible : 0 incident de production lié à un changement non planifié sur les 12 derniers mois.
2. Contrôle continu de la conformité : automatiser les revues d'accès, les contrôles de labellisation et les vérifications de lineage via des scripts ou des politiques Purview. Cible : ≥ 90 % des contrôles de conformité exécutés automatiquement, sans intervention manuelle.
3. Capacity planning et rightsizing Fabric : analyser les métriques de capacité Fabric pour optimiser les SKU et anticiper les besoins. Cible : coût par utilisateur actif mesuré et optimisé trimestriellement, sans dégradation de SLO.
4. Plateforme produit avec backlog piloté par la valeur : formaliser un backlog BI priorisé par la valeur métier mesurée (gain ETP, réduction du risque, accélération des décisions). Cible : 100 % des développements BI tracés dans un backlog avec critère de valeur explicite.
5. Veille réglementaire intégrée : mettre en place une veille structurée sur les évolutions DORA RTS, ACPR guidance IT risk, et RGPD pour anticiper les impacts sur la plateforme. Cible : revue d'impact réglementaire semestrielle documentée et présentée au RSSI et au DPO.

Piège à éviter : considérer que le palier 5 est un état stable. Les exigences DORA applicables aux entités financières françaises à partir de janvier 2025 introduisent de nouvelles obligations sur la résilience des systèmes d'information, y compris les outils de reporting et d'analyse. Une plateforme "Best-in-class" en 2024 doit intégrer ces évolutions dans son cycle de vie, pas les traiter comme des projets séparés. https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act-dora

Synthèse des seuils chiffrés par palier

3 prochaines actions concrètes — à faire dans la journée

Ces trois actions sont faisables en moins d'une journée chacune, sans budget supplémentaire, et produisent une valeur immédiate mesurable.

1. Exporter le rapport d'activité Fabric de vos 30 derniers jours

Dans le portail d'administration Power BI / Fabric, exportez le journal d'activité des 30 derniers jours (Admin portal → Activity log ou via l'API REST). Filtrez sur les événements de type ViewReport, ExportReport, RefreshDataset. Vous obtenez en 2 heures une liste des rapports réellement utilisés, des utilisateurs actifs réels, et des datasets qui n'ont pas été consultés depuis plus de 30 jours. C'est la base factuelle pour prioriser votre plan de gouvernance. https://learn.microsoft.com/en-us/fabric/admin/track-user-activities

2. Lancer un inventaire des sensitivity labels en 30 minutes

Dans Microsoft Purview ou via PowerShell (Get-PowerBIDataset combiné aux APIs Fabric), extrayez la liste de vos datasets avec leur label de sensibilité actuel. Calculez le ratio : nombre de datasets avec label / nombre total de datasets. Si ce ratio est inférieur à 50 %, vous avez une exposition RGPD documentée et un argument budgétaire concret pour votre prochain CODIR. Ce chiffre seul justifie souvent un plan d'action. https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels-overview

3. Identifier vos 5 rapports critiques sans propriétaire nommé

Dans le portail d'administration Fabric, filtrez les workspaces par nombre de vues mensuelles décroissant. Pour les 5 rapports les plus consultés, vérifiez si un propriétaire est formellement identifié (pas seulement un créateur technique, mais un responsable métier ou IT nomm