- Description
- Murs de casiers numérotés en bois dans un couloir : une grille où chaque case a sa place
- Source
- Stacalusa · page d’origine
- Licence
- CC0 Domaine public
Matrice de maturité — Conduite de projet data (PD)
Cette matrice mesure la maturité avec laquelle une organisation conduit ses projets et ses produits de données : de l'idée d'un indicateur jusqu'au chiffre qu'un décideur utilise, en…
En bref
Cette matrice mesure la maturité avec laquelle une organisation conduit ses projets et ses produits de données : de l'idée d'un indicateur jusqu'au chiffre qu'un décideur utilise, en passant par les sources, la qualité, la recette, la sécurité, l'adoption et le coût. Elle porte sur le fond (ce qui est obtenu), jamais sur un outil ou une interface. Elle compte 12 thèmes, 5 niveaux par thème et 4 jalons vérifiables par niveau. Après lecture, vous saurez situer votre équipe, choisir par où commencer et éviter de confondre « avoir un outil » et « avoir un résultat ».
Niveau : 🟢→🔴
Promesse du domaine#
Chaque chiffre publié est utile (il répond à une décision identifiée), juste (il est recetté et son écart est expliqué), explicable (on remonte à sa source en minutes), protégé (il n'expose que ce qui doit l'être) et durable (il survit aux départs, aux changements de source et aux montées de version).
Un projet data diffère d'un projet logiciel sur un point : le livrable est un actif qui vit après le projet et dont la justesse dépend de systèmes que l'équipe ne maîtrise pas (sources, saisie terrain, définitions métier). La matrice PD traite donc la donnée comme un produit et un patrimoine, avec ses propriétaires, son contrat, sa qualité mesurée et sa trajectoire de coût.
Public et usage#
- Responsables de projet data, architectes, développeurs BI/datamart : situer l'état réel d'un projet ou d'un produit de données.
- Référents métier et data owners : comprendre ce qu'on peut exiger de l'équipe technique, et ce qu'on leur doit.
- Managers : prioriser un plan de progression sur 6 à 18 mois, sans viser le niveau 5 partout.
Usage conseillé : une auto-évaluation par thème, en équipe, avec les preuves de la colonne « Preuve vérifiable » (auto-évaluation). On commence par 90 minutes, on notera large, puis on affine thème par thème.
Périmètre#
| Dans le champ | Hors champ (traité ailleurs) |
|---|---|
| Valeur, gouvernance, qualité, contrats, modèle, DataOps, recette, conformité, adoption, exploitation, coût, métadonnées | Le pilotage de projet générique (planning, risques, budget) : matrice projet informatique |
| Le cycle de vie de la donnée comme actif | L'ingénierie du code et de la livraison : matrice développement logiciel |
| Les exigences posées sur le modèle et les rapports | Le modèle sémantique, le DAX, la RLS, l'UX : matrice développement BI |
| Les décisions de conduite de projet data | L'architecture détaillée d'un reporting Power BI : dossier Reporting |
Quand deux thèmes se recouvrent, chaque page renvoie à l'autre et ne duplique pas (ex. tests de rapport côté BI, recette sur chiffres côté PD).
Les 12 thèmes et leurs codes#
Les identifiants de jalons ont la forme PD-<THÈME>-<niveau>.<n> (ex. PD-QUA-3.2).
| N° | Code | Thème | En une phrase |
|---|---|---|---|
| 01 | VAL | Cadrage, valeur et cas d'usage | Chaque produit de données répond à une décision nommée et se juge sur un bénéfice mesuré. |
| 02 | GOV | Gouvernance et organisation des données | Chaque donnée a un propriétaire, des définitions arbitrées et des règles qui s'appliquent. |
| 03 | QUA | Qualité des données | La qualité est mesurée par dimension, engagée par des seuils et corrigée à la source. |
| 04 | CTR | Sources et contrats de données | Les changements de source sont annoncés, versionnés et ne cassent plus les consommateurs. |
| 05 | MOD | Modélisation et architecture | Le modèle de données exprime le métier, absorbe le changement et reste explicable. |
| 06 | DOP | Délais et industrialisation (DataOps) | Un changement de données arrive en production vite, de façon rejouable et réversible. |
| 07 | REC | Recette et validation métier | Les chiffres sont validés contre une référence indépendante, avec des écarts expliqués et signés. |
| 08 | SEC | Sécurité, confidentialité, conformité | Les données personnelles et sensibles sont connues, minimisées, protégées et effaçables. |
| 09 | ADO | Adoption et conduite du changement | Les utilisateurs se servent réellement des chiffres et leurs décisions en témoignent. |
| 10 | EXP | Exploitation et support | Les incidents de données sont détectés avant les utilisateurs et résolus dans un délai engagé. |
| 11 | FIN | Pilotage du coût et de la valeur | Le coût de chaque produit de données est connu, attribué et rapporté à sa valeur. |
| 12 | MET | Métadonnées, lineage et documentation | Tout chiffre se retrace jusqu'à sa source et tout objet se comprend sans son auteur. |
Synthèse thèmes × niveaux#
Promesse résumée de chaque case ; le détail (et les seuils) est dans la page du thème.
| Thème | 1 — Initial | 2 — Reproductible | 3 — Défini | 4 — Maîtrisé | 5 — Optimisé |
|---|---|---|---|---|---|
| VAL Valeur | La demande est une liste de rapports | Une question métier par livrable | Hypothèse de valeur et critère de succès | Bénéfice mesuré après livraison | Portefeuille arbitré, produits retirés |
| GOV Gouvernance | Chacun sa définition | Propriétaires connus pour les données clés | Glossaire arbitré, comité actif | Règles appliquées et auditées | Gouvernance fluide, au plus près des domaines |
| QUA Qualité | Erreurs découvertes par l'utilisateur | Contrôles de base à chaque chargement | Dimensions, seuils et SLA de données | Qualité pilotée, causes racines traitées à la source | Qualité prédictive, dette de qualité nulle |
| CTR Contrats | La source change sans prévenir | Interlocuteurs et calendrier connus | Contrat écrit par source | Contrat testé, changements versionnés | Contrats pilotés par les producteurs |
| MOD Modèle | Modèle de fait, par rapport | Modèle commun documenté | Modélisation par domaine et conventions | Modèle absorbant changement et historique | Modèle évolutif sans rupture |
| DOP DataOps | Livraison à la main, en jours | Scripts et kits reproductibles | Pipeline versionné avec tests | Livraison continue sûre, retour arrière | Déploiement à la demande, mesuré par DORA |
| REC Recette | « Ça me paraît bon » | Recette manuelle sur échantillon | Plan de recette sur chiffres de référence | Recette automatisée et non-régression | Réconciliation continue en production |
| SEC Sécurité/RGPD | Données personnelles ignorées | Inventaire des données sensibles | Registre, minimisation, droits | Protection prouvée, effacement testé | Confidentialité par conception, auditée |
| ADO Adoption | Rapport livré, silence | Formation à la livraison | Plan de changement et référents | Usage mesuré et corrigé | Culture de la décision par la donnée |
| EXP Exploitation | Pompiers à la demande | Supervision basique, support par mail | Incidents catégorisés, délais cibles | SLA de données tenus, alerte proactive | Auto-réparation, problèmes éliminés |
| FIN Coût/valeur | Coût inconnu | Coût global estimé | Coût par produit de données | Coût unitaire piloté et optimisé | Arbitrage valeur/coût en continu |
| MET Métadonnées | Savoir dans la tête de l'auteur | Documentation manuelle partielle | Dictionnaire et lineage de référence | Lineage extrait automatiquement | Métadonnées actives pilotant la plateforme |
Règle de notation#
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.
Voir aussi la notation générale et l'auto-évaluation.
Lecture des scores#
| Tranche | Ce qu'elle décrit | Posture utile |
|---|---|---|
| 0–1 | Les chiffres existent, leur fiabilité repose sur des personnes | Sécuriser l'essentiel : propriétaires, contrôles de base, recette minimale |
| 1–2 | Des pratiques locales fonctionnent, mais ne se transmettent pas | Écrire, répéter, rendre reproductible |
| 2–3 | Des standards existent et sont appliqués par une partie des équipes | Généraliser et vérifier par des preuves, pas par des déclarations |
| 3–4 | Les pratiques sont mesurées, les écarts visibles et traités | Piloter par les indicateurs, traiter les causes à la source |
| 4–5 | Le système s'améliore et s'adapte presque seul | Ne viser que les thèmes où l'écart de valeur le justifie |
Un score moyen de 3 est déjà excellent pour une équipe de moins de dix personnes. Ces tranches décrivent, elles ne jugent pas.
Par où commencer et dépendances#
Portes d'entrée (rapport effort/gain le plus favorable dans la plupart des contextes) : QUA, REC et GOV. Une équipe qui ne sait pas dire si ses chiffres sont justes (REC), ni mesurer leurs défauts (QUA), ni qui tranche une définition (GOV), ne tirera rien des autres thèmes.
VAL ──► GOV ──► MET
│ │ ▲
│ ▼ │
│ CTR ──► MOD ──► DOP ──► EXP ──► FIN
│ │ │ │ │
│ ▼ ▼ ▼ ▼
└─────► QUA ──► REC ──► ADO SEC (transverse)
- GOV avant QUA : sans propriétaire, une anomalie n'a pas de destinataire (GOV, QUA).
- CTR avant DOP : on ne livre pas vite sur des sources qui bougent sans préavis.
- QUA et REC avant DOP niveau 4 : une livraison continue sans contrôle automatique accélère les erreurs.
- MET et SEC sont transverses : à relever dès le niveau 2 sur tous les autres thèmes.
- VAL conditionne FIN : un coût n'a de sens que rapporté à un bénéfice.
Profils d'organisation types#
Scores plausibles (échelle 0–5), donnés comme repères d'ordre de grandeur.
| Profil | VAL | GOV | QUA | CTR | MOD | DOP | REC | SEC | ADO | EXP | FIN | MET | Moyenne |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Petite équipe BI, héros isolé (2–3 personnes) | 1,5 | 1,0 | 1,8 | 1,0 | 2,5 | 2,0 | 2,0 | 1,5 | 1,5 | 1,5 | 0,5 | 1,0 | ~1,5 |
| Équipe datamart outillée, kits versionnés (5–8 pers.) | 2,0 | 2,0 | 2,5 | 2,0 | 3,2 | 3,0 | 2,8 | 2,5 | 2,0 | 2,3 | 1,0 | 2,2 | ~2,3 |
| Plateforme data d'entreprise, gouvernance formelle | 3,0 | 3,5 | 3,2 | 3,0 | 3,5 | 3,5 | 3,0 | 3,5 | 2,8 | 3,2 | 2,5 | 3,3 | ~3,2 |
| Organisation « data product » mûre | 4,0 | 3,8 | 4,0 | 4,2 | 3,8 | 4,2 | 3,8 | 4,0 | 3,5 | 4,0 | 3,5 | 4,0 | ~3,9 |
Fixez une cible par thème, pas une cible globale. Une équipe de cinq personnes n'a aucune raison de viser le niveau 4 en FIN si son coût mensuel tient sur une ligne.
Limites de la matrice#
- Les notes sont des appréciations d'expert, contextuelles ; deux équipes honnêtes obtiennent des scores voisins, pas identiques.
- Les seuils chiffrés (délais, taux) sont des repères ; adaptez-les à la criticité (un chiffre réglementaire n'a pas la tolérance d'un tableau de bord interne).
- La matrice ignore volontairement l'outillage : un entrepôt SQL Server et une plateforme lakehouse se jugent aux mêmes promesses.
- Loi de Goodhart : un jalon devenu cible cesse d'être un bon indicateur. Chaque page de thème indique ses détournements probables.
- Elle ne dit rien de la culture ni des personnes au-delà de ce qui s'observe dans les pratiques ; voir la matrice PI.
Voir aussi#
- Autres matrices : projet informatique · développement logiciel · développement BI · auto-évaluation
- Méthodes : méthodes spécifiques data · CI/CD pour la data · Scrum et data · pièges et bonnes pratiques
- Outils : GDS et données SQL/BI · métriques et reporting de projet
- Reporting : checklist de projet reporting · bonnes pratiques Power BI
- Glossaire · Notation
Thème 01 : Cadrage et valeur →
✻ Rédigé par Claude Sonnet 5.5
