- Description
- Un compas
- Source
- Slashme · page d’origine
- Licence
- CC0 Domaine public
Matrices de maturité — principe, anatomie et comparaison
Une matrice de maturité décrit un domaine par des thèmes, et chaque thème par cinq niveaux ; chaque niveau est une promesse (un résultat observable, jamais un moyen) étayée par des jalons…
En bref
- Une matrice de maturité décrit un domaine par des thèmes, et chaque thème par cinq niveaux ; chaque niveau est une promesse (un résultat observable, jamais un moyen) étayée par des jalons vérifiables.
- Cette rubrique propose quatre matrices qui se complètent sans se dupliquer : projet informatique (PI), développement logiciel (DL), conduite de projet data (PD), développement BI (BI) — 47 thèmes au total.
- Vous saurez : expliquer le principe à un junior avec l'exemple d'une porte, lire l'anatomie d'un thème, appliquer la règle de notation commune, choisir la bonne matrice, et vous servir des renvois croisés quand deux thèmes se recouvrent.
- La méthode pratique (grille, atelier, calibrage, plan de progression) est dans 05 — Auto-évaluation.
Sur cette page
- Le principe, par l'exemple d'une porte
- Anatomie d'un thème : promesse et jalons
- La règle de notation commune
- Les quatre matrices en un coup d'œil
- Comparaison détaillée
- Recouvrements et renvois croisés
- Quelle matrice pour quelle question
- Les thèmes de chaque matrice
- Bonnes pratiques et pièges
- Contribution de l'IA
- Voir aussi
Niveau : 🟢→🔴
Le principe, par l'exemple d'une porte#
🟢 Novice. Imaginez que l'on veuille mesurer la maturité d'une organisation pour ouvrir une porte. On ne décrit pas comment (clé, badge, biométrie) : on décrit ce que l'on obtient, sur plusieurs axes indépendants, les thèmes.
| Thème | Niveau 1 | Niveau 3 | Niveau 5 |
|---|---|---|---|
| Performance | Ouvrir prend moins d'une heure | Ouvrir prend moins d'une minute | Ouvrir prend moins d'une seconde |
| Bruit | Très bruyant | Audible dans la pièce voisine | Silencieux |
| Verrouillage | Néant (la porte reste ouverte) | Verrouillée | Remise dans l'état initial après usage |
Trois enseignements, qui valent pour toutes les matrices de cette rubrique :
- Les thèmes sont des axes distincts. Une porte peut être silencieuse mais lente. On ne fait pas la moyenne avant d'avoir regardé chaque axe : le profil « en dents de scie » est plus instructif que la moyenne.
- La promesse décrit un résultat, pas un moyen. « Moins d'une seconde » est une promesse ; « installer un lecteur de badge » est un moyen. Un moyen peut être remplacé, la promesse reste. C'est ce qui permet d'utiliser la même matrice pour un entrepôt SQL Server et pour un lakehouse (matrice PD, « La matrice ignore volontairement l'outillage »).
- Le niveau 5 est, par principe, très difficile à atteindre complètement. Une porte qui s'ouvre en moins d'une seconde, sans bruit, et se remet seule dans son état initial est un horizon. Il est là pour montrer la promesse et inciter à progresser, même si les jalons ne sont atteints que partiellement. On étudie le fond (pratiques, artefacts, preuves), jamais une interface réelle.
🟡 Pratique. Transposé à un datamart SQL Server alimenté par une application de force de vente (SFA) terrain, le thème « Livraison » donne : niveau 1 — « on livre quand c'est prêt, en espérant » ; niveau 3 — « on livre à rythme régulier avec retour arrière prévu » ; niveau 5 — « un changement validé est en production le jour même, sans événement ». Même structure, autre domaine : c'est la force de la méthode.
La même équipe peut être à 3,4 sur « modèle sémantique » et à 1,2 sur « tests » dans la matrice BI. La moyenne (≈ 2,3) cache que le maillon faible (tests) limite la fiabilité des chiffres livrés : c'est lui qu'il faut traiter en premier.
Anatomie d'un thème : promesse et jalons#
🟡 Pratique. Chaque page de thème, dans les quatre matrices, suit la même structure : pourquoi ce thème, ce qu'il mesure, tableau des cinq niveaux, jalons, lecture détaillée par niveau, atteinte partielle, passage au niveau suivant, voir aussi. Les deux éléments qui portent la matrice sont la promesse et les jalons.
| Élément | Question à laquelle il répond | Forme | Exemple (thème « Tests ») |
|---|---|---|---|
| Promesse (par niveau) | Qu'obtient le bénéficiaire ? | Phrase au présent, du point de vue du bénéficiaire, avec repère chiffré quand c'est possible | « Un défaut introduit est vu avant la fusion, en moins de 15 minutes » |
| Jalon (3 à 5 par niveau) | Comment vérifier que la promesse est tenue ? | Énoncé précis + preuve vérifiable | « La suite complète tourne à chaque fusion » — preuve : historique du pipeline sur 30 jours |
| Indicateur type | Quel ordre de grandeur ? | Délai, taux, fréquence | « < 15 min », « < 5 % de tests instables » |
| Moyen possible (facultatif) | Par quoi y arriver ? | Levier, jamais obligatoire | « Tests de mutation, tests de contrat » |
Les identifiants de jalon sont stables et lisibles : <MATRICE>-<THÈME>-<niveau>.<n>, par exemple PI-RSK-3.2 (matrice projet informatique, thème risques, niveau 3, deuxième jalon). Le préfixe de matrice évite toute ambiguïté, car plusieurs codes de thème existent dans plusieurs matrices (TST, PRF, MOD, GOV, QUA, SEC, VAL) : DL-TST-3.1 et BI-TST-3.1 sont deux jalons différents.
🔴 Expert. Pourquoi séparer promesse et jalons ? Parce qu'ils ne jouent pas le même rôle épistémique.
- La promesse est la validité de construit : elle dit ce que le niveau signifie. On peut la discuter avec un sponsor non technicien.
- Les jalons sont la mesurabilité : ils rendent la promesse falsifiable par une preuve. Sans jalons, la matrice devient une échelle d'opinions ; sans promesse, elle devient une liste de contrôle sans sens, que l'on coche sans comprendre (loi de Goodhart : voir Bonnes pratiques et pièges).
- La règle « 3 à 5 jalons par niveau » est un compromis : moins de trois, un seul jalon à 0 fait tomber tout le niveau (voir la règle de notation) ; plus de cinq, l'évaluation devient lourde et la moyenne dilue chaque jalon.
Exigez une preuve par jalon : un document, un tableau de bord, un ticket, un historique de pipeline, un enregistrement de test. Une déclaration orale plafonne l'avancement à 0,5.
La règle de notation commune#
La règle est identique dans les quatre matrices ; elle est citée ici à l'identique :
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.
🟡 Pratique — lecture de la règle.
- Trois valeurs seulement (0, 0,5, 1) pour empêcher la fausse précision : on ne distingue pas 0,6 de 0,7, mais « absent », « partiel ou non constant », « constaté et constant ».
- Cumulatif : le niveau N suppose les niveaux inférieurs. C'est pourquoi la moyenne porte sur tous les jalons de 1 à N, pas seulement ceux du niveau N.
- Seuil de 0,8 et jalon à 0 bloquant : le seuil tolère de petites lacunes (quelques 0,5), mais un jalon absent invalide la promesse (un retour arrière jamais testé n'est pas un retour arrière).
- Facteur 0,99 : il garantit qu'un score ne vaut jamais N+1 sans que N+1 soit acquis (le maximum partiel est N + 0,99).
Thème de 3 niveaux de 4 jalons chacun. Niveau 1 : 1, 1, 1, 1. Niveau 2 : 1, 1, 0,5, 1. Niveau 3 : 1, 0, 0,5, 1. Moyenne des niveaux 1 à 3 = (4 + 3,5 + 2,5) / 12 = 0,833 : supérieure à 0,8, mais un jalon est à 0 : le niveau 3 n'est pas acquis. Niveaux 1 et 2 : moyenne 7,5 / 8 = 0,94, aucun zéro : niveau 2 acquis. Score = 2 + (2,5 / 4) × 0,99 = 2 + 0,619 ≈ 2,6. Le calcul complet sur une équipe fictive est dans l'auto-évaluation.
Les matrices de domaine utilisent la règle tolérante ci-dessus (moyenne cumulée ≥ 0,8, aucun jalon à 0) : elle sert à situer une organisation et à décider où agir. Le modèle produit utilise la règle stricte : un niveau n'est acquis que si tous ses critères applicables sont « en place », et le niveau garanti est le minimum des dimensions. Les deux résultats ne sont pas comparables : un score de 2,6 sur un thème de domaine et un niveau garanti de 2 sur un produit ne mesurent pas la même chose. Choisissez la règle selon la question : où en sommes-nous ? (tolérante) ou que pouvons-nous garantir ? (stricte).
Voir aussi NOTATION (notes /5 des autres dossiers : appréciations d'expert, à ne pas confondre avec les scores de maturité) et le glossaire.
Les quatre matrices en un coup d'œil#
| PI — Projet informatique | DL — Développement logiciel | PD — Projet data | BI — Développement BI | |
|---|---|---|---|---|
| Domaine | Pilotage d'un projet ou produit informatique de bout en bout | Ingénierie du code et de sa livraison | La donnée comme actif et comme projet | Le produit BI (modèle, DAX, restitution) |
| Question centrale | « Livre-t-on ce qui a de la valeur, au coût et au rythme annoncés ? » | « Change-t-on le logiciel vite, souvent et sans peur ? » | « Les chiffres sont-ils utiles, justes, explicables, protégés, durables ? » | « Le produit BI dit-il vrai, vite, à la bonne personne, dans sa langue ? » |
| Thèmes | 11 | 12 | 12 | 12 |
| Dominante | Gouvernance, humain | Technique, flux | Valeur, qualité, conformité | Sémantique, restitution |
| Lecteur typique | Chef de projet, sponsor, PMO | Équipe de développement, responsable technique | Data owner, architecte, responsable data | Développeur BI, responsable d'équipe BI |
| README | PI | DL | PD | BI |
Comparaison détaillée#
🟡 Pratique. Les matrices diffèrent par ce qu'elles regardent, pas seulement par leur titre.
| Critère | PI | DL | PD | BI |
|---|---|---|---|---|
| Objet évalué | Le projet, l'équipe, les décisions | Le code et la chaîne de livraison | Le jeu de données comme actif, ses sources, sa qualité | Le modèle sémantique, les mesures, les rapports |
| Résultat qu'elle sert | Aucune mauvaise surprise pour le sponsor | Changements fréquents, sûrs, réversibles | Chiffres de confiance qui survivent aux départs | Chiffres justes, rapides, sécurisés, multilingues |
| Preuves typiques | Registres, comptes rendus, tableaux de bord de pilotage | Historiques de pipeline, rapports de tests, journaux | Rapports de recette, contrats de source, dictionnaire, lineage | Requêtes DAX de test, projets PBIP/TMDL, journaux de rafraîchissement |
| Indicateurs récurrents | Écart de planning, dérive de périmètre, valeur obtenue | Fréquence de déploiement, délai de changement, taux d'échec | Taux de qualité, délai de correction, usage réel | Temps de réponse, écarts de réconciliation, coût par usage |
| Niveau 5 typique | Portefeuille arbitré, zéro surprise | Changement → production en moins d'un jour | Réconciliation continue, métadonnées actives | Déploiement continu, retour arrière en minutes |
| Risque d'usage typique | Théâtre de gouvernance (documents sans décisions) | Course aux métriques de livraison sans qualité | Conformité de façade, catalogue non vivant | Rapports industrialisés mais inutiles |
| Dimension volatile | Cadres de méthode | Classes DORA, formats de SBOM | Réglementation, plateformes de données | Fabric, licences, Copilot (état 2026-10) |
Choisissez la matrice selon la question que vous voulez trancher, pas selon votre métier. Un développeur BI a autant à gagner de la matrice PD (pourquoi les chiffres sont-ils contestés ?) que de la matrice BI (pourquoi le rapport rame-t-il ?).
Recouvrements et renvois croisés#
Les quatre matrices partagent des frontières. Pour ne pas dupliquer, chaque page de thème renvoie vers le thème voisin. Voici la carte des recouvrements principaux ; la règle est : évaluer chaque jalon une seule fois, dans la matrice qui en est propriétaire (colonne « Propriétaire »), et utiliser l'autre comme éclairage.
| Sujet | Thèmes concernés | Propriétaire | Ce que fait l'autre matrice |
|---|---|---|---|
| Livraison / mise en production | PI — Livraison, DL — Déploiement, DL — CI/CD, PD — DataOps, BI — Industrialisation | DL pour la mécanique ; PI pour la décision de mise en production | PI : critères et gestion du changement ; PD : spécificités données (rejeu, idempotence) ; BI : artefacts PBIP/TMDL |
| Tests et recette | PI — Qualité et recette, DL — Tests, PD — Recette métier, BI — Tests et fiabilité | DL (code), PD (chiffres métier), BI (mesures) | PI ne couvre que les critères d'acceptation et la décision |
| Sécurité | DL — Sécurité, PD — Sécurité et conformité, BI — RLS et accès | DL (chaîne et secrets), PD (données personnelles), BI (filtrage par rôle) | Trois angles du même risque, aucun jalon commun |
| Modèle / architecture | DL — Architecture, PD — Modélisation, BI — Modèle sémantique | PD pour le modèle de données en amont ; BI pour le modèle sémantique ; DL pour l'architecture applicative | Le modèle sémantique consomme le modèle du datamart |
| Gouvernance | PI — Gouvernance et pilotage, PD — Gouvernance des données, BI — Gouvernance et self-service | Chacune sur son objet : décisions de projet (PI), données (PD), modèles et espaces (BI) | Pas de recouvrement de jalons, mais un même vocabulaire |
| Coût et valeur | PI — Budget, valeur, PD — Coût et valeur, BI — Coût, licences | PI pour le projet ; PD pour le produit de données ; BI pour la capacité et les licences | Chaîne : le coût BI alimente le coût du produit de données, qui alimente le coût du projet |
| Exploitation | DL — Observabilité, PD — Exploitation et support, BI — Exploitation et capacité | DL (applicatif), PD (incidents de données), BI (rafraîchissements, capacité) | Trois niveaux d'une même supervision |
| Documentation et métadonnées | DL — Documentation, PD — Métadonnées et lineage | DL (code), PD (données) | BI s'appuie sur PD pour le lineage |
| Performance | DL — Performance, BI — Performance et volumétrie | DL (applicatif), BI (modèle, requêtes, rafraîchissement) | Même vocabulaire de budget de performance |
| Sources et alimentation | PD — Sources et contrats, BI — Couche données et ETL | PD (contrat de la source) ; BI (consommation dans le modèle) | Un contrat PD de niveau 3 facilite un ETL BI de niveau 4 |
| Adoption et communication | PI — Parties prenantes, PD — Adoption, BI — Visualisation et UX | PI (communication projet), PD (usage des chiffres), BI (ergonomie) | — |
| Équipe et flux | PI — Équipe, DL — Expérience développeur, PI — Amélioration continue | PI pour l'humain ; DL pour les boucles techniques | — |
Symptôme : le même défaut (par exemple « pas de retour arrière testé ») est compté trois fois, dans PI, DL et PD, et fait chuter artificiellement le score global. Cause : on a évalué le même fait dans plusieurs matrices au lieu d'une seule. Remède : appliquez la colonne « Propriétaire » ; dans les autres matrices, notez le jalon comme « couvert par » et ne le comptez pas.
🔴 Expert — enchaînements de dépendances inter-matrices. Les dépendances ne s'arrêtent pas aux frontières d'une matrice. Trois chaînes reviennent régulièrement :
Qualité des chiffres : PD-GOV ─► PD-QUA ─► PD-REC ─► BI-TST ─► BI-IND
Livraison sans peur : DL-GIT ─► DL-TST ─► DL-CIC ─► DL-DEP ─► PI-LIV
Coût maîtrisé : BI-OPS ─► BI-CST ─► PD-FIN ─► PI-VAL
Lecture : un score de BI-IND au niveau 4 (pipeline de déploiement) n'a de valeur que si BI-TST est au moins au niveau 3 ; sinon on automatise la livraison de chiffres non vérifiés. De même, une PI-LIV à 4 sans DL-TST à 3 est un score de façade.
Quelle matrice pour quelle question#
| Votre question | Matrice(s) à ouvrir | Thème d'entrée |
|---|---|---|
| « Nos projets dérapent en délai et en budget » | PI | Planification, Périmètre |
| « Nos déploiements font peur » | DL, puis PD si ce sont des données | Déploiement |
| « Les utilisateurs contestent nos chiffres » | PD, puis BI | Qualité des données, Recette métier |
| « Le rapport rame » | BI | Performance et volumétrie |
| « Le départ d'une personne nous paralyserait » | PI, DL | Équipe, Documentation |
| « Nous voulons un langage commun pour toute l'équipe » | Les quatre, une session chacune | Auto-évaluation |
Les thèmes de chaque matrice#
Codes à trois lettres (déclarés dans chaque README de matrice). Les identifiants de jalons ajoutent le préfixe de la matrice.
| Matrice | Thèmes (code) |
|---|---|
| PI | CAD cadrage · GOU gouvernance · PLA planification · PER périmètre · RSK risques · EQU équipe · PAR parties prenantes · QUA qualité et recette · LIV livraison · AMC amélioration continue · VAL budget et valeur |
| DL | ARC architecture · COD qualité du code · TST tests · GIT version et branches · CIC intégration et livraison continues · DEP déploiement · SEC sécurité · OBS observabilité · DTT dette technique · DOC documentation · PRF performance · DXF expérience développeur |
| PD | VAL valeur · GOV gouvernance · QUA qualité · CTR contrats · MOD modèle · DOP DataOps · REC recette · SEC sécurité et conformité · ADO adoption · EXP exploitation · FIN coût et valeur · MET métadonnées |
| BI | MOD modèle sémantique · ETL couche données · PRF performance · VIZ visualisation · DAX mesures · RLS sécurité · IND industrialisation · TST tests · GOV gouvernance · OPS exploitation · ACC accessibilité et multilingue · CST coût et licences |
Bonnes pratiques et pièges#
Commencez par une seule matrice, sur un périmètre précis (une équipe, un produit). Faites l'évaluation en équipe, avec preuves, puis choisissez deux ou trois jalons à conquérir avant la prochaine évaluation (6 à 12 mois). Détail dans l'auto-évaluation.
Fixez une cible par thème, proportionnée au risque et à la taille. Un projet de trois mois à deux personnes n'a aucune raison de viser 4 en gouvernance : viser le niveau suffisant est un signe de maturité.
Symptôme : le score progresse, mais les incidents ne diminuent pas. Cause : loi de Goodhart — dès qu'un jalon devient un objectif, on l'optimise sans atteindre la promesse (par exemple : couverture de tests gonflée par des tests sans assertion). Remède : croiser les preuves (documents et entretiens et échantillons), changer d'échantillon à chaque évaluation, ne jamais lier le score à une évaluation individuelle.
Symptôme : on compare le score de deux équipes pour les classer. Cause : contextes, tailles et criticités différents. Remède : on compare une équipe à elle-même dans le temps.
Symptôme : on prend le niveau 5 pour un objectif à atteindre partout. Cause : confusion entre boussole et cible. Remède : le niveau 5 est exceptionnel par construction ; un 3 homogène est souvent un excellent résultat pour une équipe de moins de dix personnes.
Regardez les jalons à 0 avant les moyennes : ils indiquent les maillons absents, qui bloquent l'acquisition d'un niveau et signalent souvent un risque réel.
Limites communes aux quatre matrices : elles mesurent des pratiques observables, pas la réussite d'un projet ; les seuils chiffrés sont des repères ; la subjectivité résiduelle est d'environ un demi-point sur un jalon (d'où le calibrage) ; certains repères externes évoluent (classes DORA, formats de SBOM, fonctionnalités Fabric, licences Power BI) et sont à revérifier à la source (état 2026-10).
Contribution de l'IA#
L'IA peut préparer une auto-évaluation (rassembler des preuves, proposer un premier avancement par jalon à partir d'extraits, rédiger le plan de progression, comparer deux évaluations) mais ne la remplace pas : l'avancement est un jugement partagé de l'équipe, fondé sur des preuves que l'on a vues. Un modèle de langage peut aussi « trouver » une preuve qui n'existe pas. Voir le cadre de gouvernance dans la synthèse transverse de l'IA et les sections IA de conduite de projet, des outils et du reporting Power BI.
| Cas d'usage | Gain /5 | Risque /5 | Maturité /5 | Garde-fou |
|---|---|---|---|---|
| Synthétiser les preuves d'un thème avant l'atelier | 4/5 | 2/5 | 4/5 | Vérifier chaque preuve citée dans la source |
| Proposer un avancement 0 / 0,5 / 1 par jalon | 3/5 | 4/5 | 3/5 | Avancement toujours décidé par l'équipe ; l'IA ne note pas seule |
| Rédiger le plan de progression à partir des écarts | 4/5 | 2/5 | 4/5 | Relecture, arbitrage par le responsable d'équipe |
Détecter des incohérences entre scores (ex. LIV haut, TST bas) |
3/5 | 2/5 | 3/5 | Règles de dépendance explicites dans la consigne |
Appréciations d'expert, contexte : équipe de 5 à 10 personnes, usage ponctuel avec relecture.
Voir aussi#
- Matrices : PI · DL · PD · BI · Auto-évaluation.
- Méthodes qui enseignent les pratiques : Fondamentaux · Comparatif des méthodes · Choisir et hybrider · CI/CD · CI/CD pour la data.
- Outils : Panorama des GDS · Azure DevOps / TFS · Métriques et reporting de projet.
- Reporting : Bonnes pratiques Power BI · Checklist de projet reporting.
- Cadre : NOTATION · Glossaire · Parcours · Bibliographie.
Suivant : 05 — Auto-évaluation →
✻ Rédigé par Claude Sonnet 5.5
