- Description
- Un centre d'impression de presse
- Source
- Asanagi · page d’origine
- Licence
- CC0 Domaine public
Matrice de maturité — Développement d'un outil / application BI
Cette matrice mesure la maturité d'une équipe qui construit et fait vivre un produit BI : modèle sémantique, calculs DAX, couche de données, restitution, sécurité, industrialisation…
En bref
- Cette matrice mesure la maturité d'une équipe qui construit et fait vivre un produit BI : modèle sémantique, calculs DAX, couche de données, restitution, sécurité, industrialisation, exploitation.
- Elle compte 12 thèmes et 5 niveaux par thème. Chaque niveau décrit un résultat observable (la promesse), vérifié par des jalons précis.
- Elle se distingue de la matrice projet data (cycle de vie de la donnée comme actif) et de la matrice développement logiciel (ingénierie générique) : ici, on juge le produit BI lui-même.
- Elle s'utilise en auto-évaluation (voir l'auto-évaluation) ou comme feuille de route d'équipe.
Niveau : 🟢→🔴 · Code matrice : BI
Promesse du domaine#
Un produit BI mature dit vrai, vite, à la bonne personne, dans sa langue, et se livre sans peur.
Concrètement, une équipe de niveau 5 sur toute la matrice produit des rapports dont : (1) les chiffres sont réconciliés avec la source et les tests le prouvent à chaque livraison ; (2) le temps de réponse reste sous la seconde ou deux à l'usage ; (3) chaque utilisateur ne voit que ce qu'il a le droit de voir ; (4) le code (modèle, mesures, requêtes) est versionné, relu, déployé par pipeline ; (5) la plateforme est supervisée et son coût est maîtrisé ; (6) le rapport est accessible et multilingue sans fork. Rares sont les équipes qui atteignent cela partout ; le niveau 5 est une boussole, pas un dû (NOTATION).
Public et usage#
- Développeurs BI / datamart : situer leurs pratiques, repérer le prochain palier rentable.
- Responsables d'équipe, architectes : arbitrer les investissements (tests, pipelines, capacité) avec des repères communs.
- Juniors : comprendre ce que « bien faire » veut dire, thème par thème, avec des jalons vérifiables.
- Usage type : une session de 2 h par trimestre, chacun note les jalons (0 / 0,5 / 1) avec une preuve, on confronte, on retient 2 à 3 jalons à conquérir.
Fil rouge illustratif (anonyme) : un datamart SQL Server alimenté par une application de force de vente (SFA) terrain, avec des rapports Power BI multilingues, versionné en TFVC, livré en kits d'installation. Voir aussi le dossier Reporting Power BI.
Périmètre#
| Dans le champ | Hors champ (renvoi) |
|---|---|
| Modèle sémantique (étoile, relations, hiérarchies), DAX, Power Query/M | Modélisation dimensionnelle du datamart SQL en amont : PD — modélisation |
| Mise en forme des rapports (visuels, navigation, UX) | Conduite de projet, cérémonies : matrice PI |
| RLS/OLS, droits d'accès aux modèles et rapports | Conformité réglementaire globale : PD — sécurité et conformité |
| Versionnement PBIP/TMDL, pipelines de déploiement, tests de mesures | Principes généraux de CI/CD : DL — intégration et livraison continues |
| Supervision de la capacité, coûts, licences | Gouvernance des données d'entreprise (catalogue global) : PD — gouvernance |
On étudie le fond (pratiques, artefacts, preuves), pas l'ergonomie réelle d'une interface.
Les 12 thèmes et leurs codes#
| N° | Code | Thème | En une phrase |
|---|---|---|---|
| 01 | MOD | Modèle sémantique | Étoile, relations, cardinalités, direction de filtre, rôle des dimensions et du calendrier. |
| 02 | ETL | Couche données et ETL | Alimentation du modèle : vues sources, Power Query, folding, dataflows, contrats de colonnes. |
| 03 | PRF | Performance et volumétrie | Cardinalité, agrégations, modes de stockage, temps de réponse et de rafraîchissement. |
| 04 | VIZ | Visualisation et UX | Choix des visuels, navigation, lisibilité, charge cognitive, cohérence du thème. |
| 05 | DAX | Mesures et calculs DAX | Mesures plutôt que colonnes, contexte, time intelligence, groupes de calcul, conventions. |
| 06 | RLS | Sécurité RLS et accès | RLS statique/dynamique, OLS, partage, tests de rôles. |
| 07 | IND | Versionnement et industrialisation | PBIP/TMDL, Git/TFVC, pipelines de déploiement, environnements. |
| 08 | TST | Tests et fiabilité des chiffres | Requêtes DAX de test, réconciliation, BPA, non-régression. |
| 09 | GOV | Gouvernance, catalogue et self-service | Modèles certifiés, endorsement, espaces de travail, libre-service encadré. |
| 10 | OPS | Exploitation, supervision et capacité | Rafraîchissements, alertes, Capacity Metrics, logs, support. |
| 11 | ACC | Accessibilité et multilingue | Contrastes, navigation clavier, texte alternatif, traductions, formats régionaux. |
| 12 | CST | Coût, licences et capacité | Pro, PPU, capacités Premium (P-SKU, en cours de retrait), F-SKU : dimensionnement, coût par usage, optimisation. |
Tableau de synthèse thèmes × niveaux#
| Thème | N1 | N2 | N3 | N4 | N5 |
|---|---|---|---|---|---|
| MOD | Tables à plat, relations automatiques | Étoile lisible, relations contrôlées | Étoile stricte documentée, calendrier dédié | Modèle contractuel, rôles de dimensions maîtrisés | Modèle composable, évolutif sans casser les rapports |
| ETL | Requêtes copiées-collées | Vues SQL sources, M simple | Folding vérifié, paramètres | Contrats de colonnes, rejeu idempotent | Alimentation incrémentale outillée, auto-réparante |
| PRF | « Ça rame » subi | Mesure du temps, premiers réglages | Cardinalité et agrégats pilotés | Budgets de performance en pipeline | Sous la seconde à charge nominale, prouvé |
| VIZ | Visuels par défaut | Gabarit commun | Parcours et hiérarchie visuelle | Design system, tests d'usage | Expérience adaptative, mesurée en continu |
| DAX | Colonnes calculées, copier-coller | Mesures nommées | Time intelligence, VAR, conventions | Groupes de calcul, mesures de base réutilisées | Bibliothèque de mesures testée et versionnée |
| RLS | Partage ouvert | Rôles statiques | Dynamique sur table de sécurité | Rôles testés, OLS, journalisés | Sécurité prouvée, audit continu |
| IND | Fichier .pbix sur un partage | .pbix en dépôt | PBIP/TMDL en Git ou TFVC | Pipeline dev-test-prod, revue de PR | Déploiement continu, retour arrière en minutes |
| TST | Contrôle visuel | Contrôles manuels notés | Requêtes DAX de test rejouables | Tests en pipeline + BPA | Non-régression automatique, seuils d'alerte |
| GOV | Rapports orphelins | Propriétaires connus | Modèles certifiés, espaces structurés | Catalogue vivant, cycle de vie | Self-service sûr, mesuré, auto-régulé |
| OPS | Pas de supervision | Alertes d'échec | Tableau de bord d'exploitation | SLO, capacité surveillée, runbooks | Auto-dimensionnement, incidents anticipés |
| ACC | Ignorée | Contrastes vérifiés | Ordre de tabulation, textes alternatifs | Traductions de métadonnées outillées | Rapport accessible et multilingue sans fork |
| CST | Licences subies | Coût connu | Coût par usage suivi | Dimensionnement optimisé | Coût rapporté à la valeur, arbitrage continu |
Règle de notation#
Règle commune (identique dans toutes les matrices) :
chaque jalon a un avancement 0 / 0,5 / 1. Un niveau N est acquis si la moyenne des avancements de tous les jalons des niveaux 1 à N est ≥ 0,8 et qu'aucun jalon n'est à 0. Score du thème = N_acquis + moyenne des avancements des jalons du niveau N_acquis+1 × 0,99 (ex. 2,4). Score de la matrice = moyenne pondérée des thèmes (poids par défaut 1, modifiable). Un score entier de 5,0 est exceptionnel et peut n'être jamais atteint : ce n'est pas un échec.
Convention d'identifiants : BI-<THÈME>-<niveau>.<n>, par exemple BI-DAX-3.2 (thème DAX, niveau 3, jalon 2). Chaque jalon s'accompagne d'une preuve (capture, requête, fichier, commit) : sans preuve, l'avancement ne dépasse pas 0,5.
Lecture des scores#
| Score | Ce que cela dit (sans jugement moral) |
|---|---|
| 0 – 1 | Le produit repose sur des individus et des fichiers locaux ; il fonctionne tant que ses auteurs sont là. |
| 1 – 2 | Les bases existent (modèle lisible, mesures nommées) mais rien n'est reproductible ni testé. |
| 2 – 3 | Pratiques communes dans l'équipe, livraisons répétables, premiers contrôles ; la qualité dépend encore de la vigilance. |
| 3 – 4 | Le produit s'industrialise : code versionné, tests rejouables, supervision ; les incidents sont rares et compris. |
| 4 – 5 | Les garanties sont automatisées et mesurées ; l'équipe améliore le système plus qu'elle ne le répare. |
Un score très hétérogène (un 4 en DAX, un 1 en tests) est une information plus utile que la moyenne.
Portes d'entrée et dépendances#
Par où commencer : MOD (tout repose dessus), puis DAX et TST. Un modèle faux ou un chiffre non vérifié ruine la confiance, quelle que soit la beauté du rapport.
Dépendances principales :
ETL ──► MOD ──► DAX ──► TST ──► IND ──► OPS
│ │ │ │
├──► PRF ◄──┘ └──► GOV └──► CST
└──► RLS VIZ ──► ACC
- TST avant IND : on n'automatise pas un déploiement dont on ne sait pas vérifier le résultat.
- MOD avant PRF et RLS : cardinalités et filtres propagés conditionnent vitesse et sécurité.
- OPS avant CST : on n'optimise pas ce qu'on ne mesure pas.
- GOV (modèles certifiés) réduit la duplication, donc le coût de PRF et CST.
Profils d'organisation types#
| Profil | Description | Scores plausibles |
|---|---|---|
| Atelier de fichiers | 1 à 2 personnes, .pbix partagés par mail, import de classeurs. | MOD 1,3 · DAX 1,5 · TST 0,5 · IND 0,8 · RLS 1 · OPS 0,3 · CST 1,2 |
| Équipe BI naissante | 3 à 5 personnes, étoile correcte, vues SQL, dépôt de .pbix, tests visuels. | MOD 2,5 · DAX 2,3 · TST 1,5 · IND 1,8 · RLS 2,2 · OPS 1,5 · CST 2 |
| Équipe produit BI | PBIP/TMDL en dépôt, tests DAX rejouables, pipelines, supervision de base. | MOD 3,6 · DAX 3,5 · TST 3,2 · IND 3,5 · RLS 3,3 · OPS 3 · CST 2,8 |
| Plateforme BI mature | Modèles certifiés, CI/CD complet, SLO, coût par usage, accessibilité outillée. | Majorité entre 4 et 4,7 ; PRF et ACC souvent plus bas |
Ces profils sont illustratifs (appréciations d'expert, contextuelles) et ne sont issus d'aucune enquête.
Limites de la matrice#
- Elle mesure des pratiques, pas la valeur métier du rapport : un produit parfaitement industrialisé peut être inutile (voir PD — pilotage coût et valeur).
- Les technologies évoluent vite (Fabric, Direct Lake, Copilot, licences) : les faits volatils sont datés « (état 2026-10) » et à revérifier avant décision.
- La loi de Goodhart s'applique : un indicateur devenu cible cesse d'être bon. Chaque thème liste ses détournements possibles.
- Les niveaux supposent un volume et une criticité moyens ; un rapport interne de 5 utilisateurs n'a pas à viser le niveau 5 partout.
- Les notes /5 de difficulté et d'effort sont des appréciations d'expert.
Voir aussi#
- Autres matrices : Conduite de projet informatique · Développement logiciel · Conduite de projet data · Auto-évaluation · Portail des matrices
- Outils : Gestion de source et données SQL/BI · Git en profondeur · TFVC en profondeur
- Reporting : Bonnes pratiques Power BI transverses · Checklist de projet reporting · Comparatif OneLake vs SQL Server
- Glossaire · Notation · Parcours
✻ Rédigé par Claude Sonnet 5.5
