- Description
- Un compas
- Source
- Slashme · page d’origine
- Licence
- CC0 Domaine public
Comprendre les matrices de maturité
Un outil pour situer où l'on en est, décider où aller, et dans quel ordre.
En bref
- Niveaux ordonnés + dimensions + critères observables.
- Servent à diagnostiquer, prioriser, planifier et suivre.
- Pièges : courir après le niveau, auto-évaluation optimiste, cible universelle.
- Choisir sa matrice →
Cette section décrit des matrices qui situent le niveau d'une organisation. Pour la maturité d'un produit (outil, solution) et en quoi elle aide ses utilisateurs, voir La maturité d'un produit.
Définition#
Une matrice de maturité (ou modèle de maturité) décrit, pour un domaine donné, une suite de niveaux ordonnés, du plus rudimentaire au plus abouti, et les critères observables qui permettent de situer une organisation sur chacun. Elle sert à poser un diagnostic partagé, à fixer une cible et à planifier la progression.
Origine#
Le principe vient de l'ingénierie logicielle : le Capability Maturity Model (CMM) a été développé à partir de la fin des années 1980 au Software Engineering Institute de l'université Carnegie Mellon pour évaluer la capacité des fournisseurs de logiciels. Il a donné naissance au CMMI (Capability Maturity Model Integration), aujourd'hui maintenu par l'ISACA, qui a repris le CMMI Institute en 2016. La version par étapes la plus citée distingue cinq niveaux : Initial, Géré, Défini, Géré quantitativement, Optimisé.
Depuis, le format s'est répandu : gestion des données, analytique, sécurité, tests, cloud, DevOps, adoption d'outils.
Anatomie d'une matrice#
- Des niveaux : une échelle ordonnée (souvent 3 à 6 niveaux), chacun décrit par des caractéristiques.
- Des dimensions (ou domaines, capacités, thèmes) : les aspects évalués séparément.
- Des critères et des preuves : ce qui, concrètement, permet d'affirmer qu'un niveau est atteint.
- Une méthode d'évaluation : questionnaire, entretiens, revue de documents, audit.
| Niveau 1 | Niveau 2 | Niveau 3 | |
|---|---|---|---|
| Dimension A | critères / preuves | critères / preuves | critères / preuves |
| Dimension B | critères / preuves | critères / preuves | critères / preuves |
| Dimension C | critères / preuves | critères / preuves | critères / preuves |
La grille ci-dessus est schématique : chaque cellule contient des critères propres au modèle.
Deux familles de modèles#
| Famille | Principe | Exemples ici |
|---|---|---|
| Par étapes (staged) | Un niveau global ; on n'accède à un niveau qu'une fois les exigences des niveaux précédents satisfaites. | TMMi, TDWI |
| Continus (par dimension) | Chaque dimension, pratique ou capacité a son propre niveau ; la progression est inégale par construction. | DAMA-DMBOK, OWASP SAMM, FinOps, Fabric / Power BI |
Pourquoi c'est important#
- Un langage commun : technique, métier et direction parlent du même niveau, avec les mêmes mots.
- Un diagnostic honnête : on sait où l'on est, sans se comparer à une cible hors de portée.
- Une priorisation : on traite d'abord la dimension qui limite les autres.
- Une trajectoire par paliers : des étapes réalistes plutôt qu'un grand soir.
- Un suivi dans le temps : réévaluer permet de mesurer le progrès.
- Un levier de décision : justifier un investissement par un écart à une cible argumentée.
- Un support de roadmap produit : les écarts de maturité éclairent l'ordre des chantiers, en complément des demandes des utilisateurs.
Comment les utiliser#
- Cadrer le périmètre : un produit, une équipe, un département ?
- Choisir une matrice reconnue plutôt qu'en inventer une ; l'adapter si nécessaire en le disant.
- Évaluer avec des preuves, de préférence à plusieurs et avec un regard extérieur.
- Fixer des cibles par dimension, justifiées par un enjeu ou un risque.
- Traduire les écarts en actions datées, avec un responsable.
- Réévaluer à intervalle régulier et ajuster.
Limites et pièges#
- Courir après le niveau : quand le niveau devient un objectif, on optimise l'indicateur plutôt que le résultat (loi de Goodhart : « quand une mesure devient un objectif, elle cesse d'être une bonne mesure »).
- Un niveau n'est pas une valeur : un haut niveau de maturité ne garantit pas un bon produit ni un bon résultat financier.
- L'auto-évaluation est optimiste : sans preuves, les niveaux déclarés sont trop hauts (voir l'effet Dunning-Kruger).
- Le « bon » niveau dépend du contexte : viser le maximum partout est rarement pertinent (le cadre FinOps l'écrit explicitement).
- Un modèle simplifie : il peut ignorer des spécificités sectorielles ou de taille.
- Bureaucratie : un modèle appliqué à la lettre peut alourdir de petites équipes ; l'adapter.
- Un modèle vieillit : citer la version et la date de consultation.
Mon niveau d'atteinte : comment ça marche#
Chaque page de matrice comporte un interrupteur « Mon niveau d'atteinte ». Activé, il surligne sur l'échelle le niveau que j'ai renseigné, et indique le niveau par dimension quand il est connu. Les données sont saisies à la main dans un fichier de configuration unique : niveau global, niveau par dimension, date d'évaluation et commentaire. Tant qu'une valeur n'est pas saisie, la page affiche « non renseigné ».
Sources et vérification#
- CMMI Institute / ISACA — site officiel — modèle CMMI
- Carnegie Mellon University, SEI — Capability Maturity Model Integration — origine du CMM / CMMI
- Microsoft Learn — Fabric adoption roadmap : maturity levels — rappelle l'alignement sur les cinq niveaux du CMM
- FinOps Foundation — maturity model — maturité par capacité, ne pas viser « Run » partout
