- Description
- Échiquier en bois vide, dont les cases forment une grille régulière.
- Source
- Paul Lloyd · page d’origine
- Licence
- CC0 Domaine public
Matrice de maturité — Développement d'un logiciel (code DL)
Cette matrice mesure l'ingénierie du code et de sa livraison : de l'architecture aux tests, de la chaîne d'intégration à l'exploitation, de la sécurité à l'expérience quotidienne du…
En bref
Cette matrice mesure l'ingénierie du code et de sa livraison : de l'architecture aux tests, de la chaîne d'intégration à l'exploitation, de la sécurité à l'expérience quotidienne du développeur. Pour chaque thème, cinq niveaux ; chaque niveau porte une promesse (un résultat observable) et des jalons vérifiables. Elle se distingue de la matrice conduite de projet informatique (pilotage, gouvernance, humain), de la matrice projet data (la donnée comme actif) et de la matrice développement BI (le produit BI).
Niveau : 🟢→🔴 · 12 thèmes · code matrice DL
Promesse du domaine#
Une équipe de niveau élevé sur cette matrice change son logiciel vite, souvent et sans peur, et sait en quelques minutes si un changement est sûr, en quelques heures s'il est en production, et en quelques jours comment le défaire. Elle prouve ses chiffres de qualité plutôt que de les affirmer. Le niveau 5 est, par principe, très difficile à atteindre complètement : il montre l'horizon pour inciter à progresser, même si les jalons ne sont atteints que partiellement.
Les repères chiffrés des pages (délais, taux, fréquences) sont des ordres de grandeur d'expert, pas des seuils normatifs ; les recherches de référence (Accelerate, rapports DORA) soutiennent la corrélation entre pratiques de livraison et performance, mais les valeurs exactes des classes de performance évoluent : à vérifier sur la source (état 2026-10).
Public et usage#
- Équipe de développement : auto-évaluation trimestrielle (une heure par thème), puis choix de 2 ou 3 jalons à viser. Voir auto-évaluation.
- Responsable technique ou d'équipe : lecture des profils, des dépendances entre thèmes et des signes de faux positifs.
- Formateur : chaque thème sert de support de discussion (« à quoi ressemble le niveau suivant ? »).
- Usage recommandé : comparer l'équipe à elle-même dans le temps. Éviter de comparer des équipes entre elles (contextes différents) et de lier le score à une évaluation individuelle (loi de Goodhart).
Périmètre#
Dans le champ : tout ce qui touche à la fabrication, la livraison et l'exploitation du code (applicatif, SQL, scripts, modèles déployables). Le fil rouge illustratif est un datamart SQL Server alimenté par une application terrain, avec rapports Power BI multilingues, versionné en TFVC et livré en kits d'installation.
Hors champ (traité ailleurs, avec renvois) :
| Sujet | Où le trouver |
|---|---|
| Pilotage, gouvernance, budget, parties prenantes | Matrice conduite de projet informatique |
| Qualité, gouvernance et conformité des données, RGPD | Matrice conduite de projet data |
| Modèle sémantique, DAX, RLS, accessibilité des rapports | Matrice développement BI |
| Choix d'un outil, comparatifs de systèmes de gestion de source | 02_Outils |
| Méthodes (Scrum, Kanban, cycles en V…) | 01_Conduite-de-projet |
Les douze thèmes#
| # | Code | Thème | En une phrase |
|---|---|---|---|
| 01 | ARC | Architecture et conception | Changer à coût borné : frontières claires, décisions tracées, règles vérifiées. |
| 02 | COD | Qualité du code | Défauts attrapés avant la fusion, revues utiles, qualité du code nouveau garantie. |
| 03 | TST | Tests | Une suite rapide, fiable et réellement détectrice (couverture, mutation, contrats). |
| 04 | GIT | Gestion de version et branches | Traçabilité complète, petits lots, correctifs reportés vers toutes les versions. |
| 05 | CIC | Intégration et livraison continues | Un artefact reproductible, promu tel quel, du commit à la production. |
| 06 | DEP | Déploiement et exploitation | Mise en service banale, réversible, sans interruption, migrations idempotentes. |
| 07 | SEC | Sécurité | Secrets, dépendances, menaces, SBOM et provenance maîtrisés. |
| 08 | OBS | Observabilité et fiabilité | Détecter avant les utilisateurs, diagnostiquer vite, piloter par SLO. |
| 09 | DTT | Dette technique et maintenabilité | La dette est un portefeuille chiffré, arbitré et remboursé. |
| 10 | DOC | Documentation et transmission du savoir | Facteur camion élevé, documentation vivante et adjacente au code. |
| 11 | PRF | Performance et scalabilité | Budgets de performance testés, croissance prévue, coût suivi. |
| 12 | DXF | Expérience développeur et flux | Boucles de retour courtes, WIP limité, obstacles supprimés. |
Les identifiants de jalons suivent le schéma DL-<CODE>-<niveau>.<n> (exemple : DL-TST-3.2 = matrice DL, thème tests, niveau 3, jalon 2).
Synthèse thèmes × niveaux#
| Thème | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| ARC | Émergente | Décrite | Délimitée | Gouvernée par règles vérifiées | Composants remplaçables sans arrêt |
| COD | Individuel | Conventions + revue | Vérifié par outils | Maîtrisé : code nouveau propre | Refactoring sans crainte |
| TST | Manuel | Chemins critiques rejouables | Suite < 15 min fiable | Calibré (mutation, contrats) | Défauts échappés → tests |
| GIT | Copies | Historisé | Relié, correctifs ≤ 1 j | Petits lots, branches < 2 j | Tronc toujours livrable |
| CIC | Artisanale | Scriptée | Pipeline automatique < 15 min | Un artefact promu partout | Changement → production < 1 j |
| DEP | Héroïque | Procédurée | Répétable, retour arrière testé | Sans interruption, progressif | Autonome, retour arrière auto |
| SEC | Confiante | Hygiène (secrets, droits) | Détectée en CI | Anticipée (menaces, SBOM) | Provenance prouvée |
| OBS | Aveugle | Pannes franches vues | Diagnostiquée (journaux corrélés) | Pilotée par SLO | Résiliente, exercices de panne |
| DTT | Subie | Reconnue | Arbitrée (coût d'intérêt) | Mesurée (délai de changement) | Soutenable, plafonnée |
| DOC | Oral | Écrit | Maintenu, propriétaire et date | Vivant, généré, revu | Facteur camion ≥ 3 |
| PRF | Subie | Mesurée | Budgétée, test de régression | Prévue (×3, capacité) | Élastique, coût unitaire suivi |
| DXF | Subi | Équipé | Rapide (boucles courtes) | Fluide (WIP, libre-service) | Obstacles résolus en continu |
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.
Thème « Tests » : niveaux 1 et 2 à 100 %, niveau 3 à 0,9 de moyenne (aucun jalon à 0). La moyenne des niveaux 1-3 est > 0,8 : niveau 3 acquis. Les jalons du niveau 4 sont en moyenne à 0,4 : score = 3 + 0,4 × 0,99 ≈ 3,4.
Un jalon à 0 bloque l'acquisition du niveau même si la moyenne est excellente. C'est voulu : un seul maillon absent (retour arrière jamais testé, par exemple) invalide la promesse.
Convention de preuve : un jalon n'est à 1 que si la preuve vérifiable indiquée a été effectivement constatée (pas déclarée). Voir aussi la notation de cette rubrique.
Lecture des scores#
| Score | Ce que cela dit | Ce que l'on peut attendre |
|---|---|---|
| 0 – 1 | Pratiques individuelles, peu partagées. | Résultats dépendants de personnes ; livraisons rares et tendues. |
| 1 – 2 | Pratiques décrites et répétables à la main. | Fonctionne tant que les personnes clés sont là ; peu d'automatisation. |
| 2 – 3 | Pratiques outillées sur les chemins principaux. | Livraisons régulières ; les défauts courants sont vus avant la production. |
| 3 – 4 | Pratiques mesurées et pilotées. | Équipe qui améliore sa capacité par les données ; incidents contenus. |
| 4 – 5 | Pratiques éprouvées et prédictives. | Capacité de changement élevée et stable ; exercices réguliers. |
Ces tranches décrivent, sans jugement moral, une situation : un produit de maintenance stable à 2,5 peut être parfaitement adapté ; un produit en forte évolution à 2,5 se heurte à ses limites.
Par où commencer et dépendances#
Portes d'entrée (rendement élevé, effort modéré) : 04 Gestion de version (tout dépend de la traçabilité), 03 Tests (la confiance conditionne la vitesse), 07 Sécurité niveau 2 (secrets et droits, coût faible et risque évité élevé).
Dépendances principales (A → B : progresser sur A facilite fortement B) :
04 GIT ─► 05 CIC ─► 06 DEP ─► 08 OBS
03 TST ─► 05 CIC │
02 COD ─► 03 TST ▼
01 ARC ─► 03 TST 11 PRF, 07 SEC
01 ARC ─► 09 DTT ◄─ 02 COD
10 DOC ◄► 12 DXF (transverses : touchent tous les autres)
- Tests avant livraison continue : sans suite fiable, automatiser la livraison automatise le risque.
- Gestion de version avant intégration continue : sans petits lots et traçabilité, la chaîne reste artisanale.
- Observabilité avant déploiement progressif : on ne déploie pas progressivement ce qu'on ne sait pas observer.
- Sécurité : le niveau 3 suppose la chaîne CI ; le niveau 5 suppose des constructions reproductibles (05).
Profils d'organisation types#
Scores plausibles à titre illustratif (contextes simplifiés, non normatifs) :
| Profil | Description | ARC | COD | TST | GIT | CIC | DEP | SEC | OBS | DTT | DOC | PRF | DXF | Moyenne |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A. Artisan solo | Un expert, un produit, livraisons rares | 1,3 | 1,0 | 0,8 | 2,0 | 1,0 | 1,2 | 1,0 | 0,6 | 0,8 | 0,5 | 1,5 | 1,5 | ≈ 1,1 |
| B. Équipe produit de 5-8 (datamart + rapports) | TFVC, kits, tests partiels | 2,3 | 2,2 | 2,0 | 2,8 | 2,3 | 2,4 | 1,8 | 1,6 | 1,8 | 2,0 | 2,3 | 2,0 | ≈ 2,1 |
| C. Équipe produit mature | Pipeline, mesures DORA, SLO | 3,5 | 3,4 | 3,6 | 3,9 | 3,8 | 3,5 | 3,0 | 3,3 | 3,0 | 3,2 | 3,2 | 3,3 | ≈ 3,4 |
| D. Organisation de plateforme (élite) | Retour arrière automatique, provenance signée | 4,2 | 4,0 | 4,3 | 4,4 | 4,6 | 4,3 | 4,0 | 4,2 | 3,8 | 3,8 | 4,0 | 4,1 | ≈ 4,1 |
Regardez le profil en dents de scie plutôt que la moyenne : une équipe à 4 en CI/CD et 1,5 en sécurité a un risque plus élevé qu'une équipe homogène à 2,5. La moyenne cache le maillon faible ; les jalons à 0 le révèlent.
Limites de la matrice#
- Contexte : un prototype jetable n'a pas besoin du niveau 4 en architecture ; viser le niveau qui correspond au coût de l'échec et à la durée de vie du produit.
- Mesure ≠ valeur : une équipe peut avoir un excellent score et livrer le mauvais produit. La matrice ne dit rien de l'adéquation au besoin (cadrage et vision).
- Goodhart : tout indicateur érigé en objectif est détourné. Chaque thème liste les détournements typiques ; auditez-les par échantillonnage.
- Subjectivité : les avancements 0/0,5/1 se jugent sur preuves ; faites-les valider par un tiers (pair d'une autre équipe).
- Plateformes et technologies : les jalons sont formulés en résultats ; leur incarnation varie (Git ou TFVC, pipeline hébergé ou sur site). Les moyens cités dans les pages sont facultatifs.
- Volatilité : certains repères (classes DORA, formats de SBOM, niveaux SLSA) évoluent ; vérifier à la source avant de les figer dans une politique (état 2026-10).
Voir aussi#
- Autres matrices : Conduite de projet informatique · Conduite de projet data · Développement BI · auto-évaluation · portail des matrices.
- Pratique : CI/CD · CI/CD pour la data · panorama des GDS · Git en profondeur · TFVC en profondeur · stratégies de branches · Azure DevOps / TFS · métriques et reporting · pièges et bonnes pratiques.
- Reporting Power BI : bonnes pratiques transverses.
- Glossaire · Notation · Parcours.
✻ Rédigé par Claude Sonnet 5.5
