i

Description

Tableau de bord d’un petit avion, avec ses cadrans, ses manettes et ses rangées de commutateurs.

Source

U.S. Fish and Wildlife Service · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Métriques et reporting de projet

Vous saurez calculer et interpréter vélocité, burndown/burnup, diagramme de flux cumulé, lead time, cycle time, throughput, WIP, et leurs liens (loi de Little).

En bref

• Vous saurez calculer et interpréter vélocité, burndown/burnup, diagramme de flux cumulé, lead time, cycle time, throughput, WIP, et leurs liens (loi de Little).
• Vous connaîtrez les métriques DORA et leurs limites hors contexte logiciel pur.
• Vous saurez mesurer la qualité des estimations et la santé du backlog.
• Vous disposerez de métriques propres aux projets data : fraîcheur, incidents de données, taux de rejet, écarts de recette.
• Vous saurez ne pas vous faire piéger par la loi de Goodhart, et construire un tableau de bord Power BI sur Azure DevOps.

Contexte de notation : équipe de 5 à 15 personnes, data/BI. Les notes /5 sont des appréciations (voir NOTATION).

Sur cette page

1. 🟢 Novice — Pourquoi mesurer, et quoi
   1. 🟢 Définitions de base
2. 🟡 Pratique — Vélocité, burndown, burnup
   1. Vélocité
   2. Burndown de sprint
   3. Burnup (à privilégier)
3. 🟡 Pratique — Flux : CFD, lead/cycle time, throughput, WIP
   1. Diagramme de flux cumulé (CFD)
   2. Loi de Little
   3. Lead time et cycle time : percentiles, pas moyenne
   4. Âge des éléments en cours (aging WIP)
   5. Prévision probabiliste (Monte Carlo)
4. 🟡 Pratique — DORA et métriques de livraison
5. 🟡 Pratique — Qualité des estimations
6. 🟡 Pratique — Santé du backlog
7. 🔴 Expert — Métriques propres aux projets data
8. 🔴 Expert — Loi de Goodhart et usages pervers
9. 🔴 Expert — Tableaux de bord Power BI sur Azure DevOps
10. Métriques — quelles métriques valent leur coût ?
11. 🤖 Contribution de l'IA
12. Voir aussi

Niveau : 🟢→🔴

🟢 Novice — Pourquoi mesurer, et quoi#

Mesurer sert à décider et à apprendre, pas à surveiller. Une bonne métrique répond à une question que l'équipe se pose réellement : « livrons-nous de façon prévisible ? », « où le travail attend-il ? », « la qualité baisse-t-elle ? ». Avant de choisir un indicateur, écrivez la question et la décision que la réponse peut changer ; sans décision, ne mesurez pas.

Trois familles :

🟢 Définitions de base#

🟡 Pratique — Vélocité, burndown, burnup#

Vélocité#

Vélocité du sprint n = Σ points des stories « Done » à la clôture du sprint n
Vélocité de référence = moyenne (ou médiane) des 3 à 5 derniers sprints
Fourchette = [min ; max] des derniers sprints, plus parlante que la moyenne

La vélocité est un outil de planification locale de l'équipe, pas un indicateur de performance, ni un moyen de comparer deux équipes (les points n'ont pas la même unité d'une équipe à l'autre). Elle devient fiable après 4 à 6 sprints stables (même équipe, même durée).

Burndown de sprint#

Courbe du reste à faire (heures ou points) par jour du sprint, comparée à la droite idéale. Lire : une falaise en fin de sprint = travail non décomposé ou mises à jour tardives ; un plat prolongé = blocage ou tâches trop grosses ; une remontée = ajout de périmètre.

Burnup (à privilégier)#

Deux courbes : travail terminé cumulé et périmètre total. Contrairement au burndown, le périmètre est visible : une ligne de périmètre qui monte explique pourquoi la fin recule.

        Points
  200 ┤                          ·· périmètre (monte : ajout)
  150 ┤                    ····
  100 ┤            ·····  /──── terminé (cumul)
   50 ┤      /─────
    0 ┼──┴───────────────────────────→ sprints

🟡 Pratique — Flux : CFD, lead/cycle time, throughput, WIP#

Diagramme de flux cumulé (CFD)#

Chaque bande représente un état (Backlog, En cours, En recette, Terminé) ; la hauteur d'une bande à une date = nombre d'éléments dans cet état. Lecture :

Loi de Little#

Lead time moyen = WIP moyen / Throughput moyen        (régime stable)
Exemple : WIP = 12 éléments, throughput = 3 éléments/semaine → lead time moyen = 4 semaines
Pour diviser le lead time par 2 à débit constant : diviser le WIP par 2.

C'est l'argument fondamental en faveur des limites de WIP : réduire le travail en cours accélère la livraison sans que personne ne travaille plus vite. Voir méthodes agiles et Lean.

Lead time et cycle time : percentiles, pas moyenne#

Les durées sont asymétriques (queue lourde) ; la moyenne trompe. Utiliser les percentiles :

Le diagramme de dispersion (scatterplot, un point par élément terminé) rend ces seuils visibles.

Âge des éléments en cours (aging WIP)#

Pour chaque élément en cours : âge = aujourd'hui − date de début. Comparer à la plage 85 % : tout ce qui dépasse mérite une action maintenant (plus utile que le lead time, qui n'existe qu'après coup).

Prévision probabiliste (Monte Carlo)#

Plutôt que d'extrapoler une moyenne, rééchantillonner le débit historique pour estimer une plage de dates. Mini-script PowerShell pour illustrer :

# Prévision : combien de semaines pour terminer 40 éléments ? (débit historique par semaine)
$debits = 3,5,2,4,6,3,2,5,4,3          # éléments terminés par semaine, 10 semaines
$reste = 40; $essais = 10000; $res = @()
$rnd = New-Object System.Random 42
1..$essais | ForEach-Object {
    $faits = 0; $sem = 0
    while ($faits -lt $reste) { $faits += $debits[$rnd.Next(0,$debits.Count)]; $sem++ }
    $res += $sem
}
$tri = $res | Sort-Object
"P50 = {0} sem ; P85 = {1} sem ; P95 = {2} sem" -f $tri[[int]($essais*0.50)], $tri[[int]($essais*0.85)], $tri[[int]($essais*0.95)]

🟡 Pratique — DORA et métriques de livraison#

Les métriques DORA (programme de recherche DevOps Research and Assessment, popularisées par le livre Accelerate de Nicole Forsgren, Jez Humble et Gene Kim, 2018) mesurent la performance de livraison logicielle. Les quatre métriques historiques :

DORA a depuis fait évoluer le jeu d'indicateurs : en 2023, le temps de rétablissement a été redéfini (rétablissement après un déploiement en échec, et non après toute panne) ; depuis le rapport 2024, DORA compte cinq métriques, avec le taux de reprise des déploiements (deployment rework rate : part des déploiements non planifiés consécutifs à un incident de production), réparties en débit (délai, fréquence, rétablissement) et instabilité (taux d'échec, taux de reprise). DORA met aussi en garde contre l'usage de ces métriques comme objectifs et contre les comparaisons entre applications très différentes.

🟡 Pratique — Qualité des estimations#

Une estimation est un pari avec une marge. Mesurer sa qualité aide à l'améliorer sans en faire une vérité.

🟡 Pratique — Santé du backlog#

🔴 Expert — Métriques propres aux projets data#

Un projet de datamart ou de reporting a des objets de mesure que les métriques logicielles ignorent. Voir aussi conduite de projet data (matrice).

Exemple T-SQL de mesure de fraîcheur et de taux de rejet à partir d'une table de journal (conventionnelle, adapter aux noms réels) :

-- Fraîcheur par table cible (en heures) et dépassement du seuil
SELECT  j.Table_Cible,
        MAX(j.Date_Fin_Chargement)                                   AS Dernier_Chargement,
        DATEDIFF(HOUR, MAX(j.Date_Fin_Chargement), SYSDATETIME())    AS Age_Heures,
        CASE WHEN DATEDIFF(HOUR, MAX(j.Date_Fin_Chargement), SYSDATETIME()) > s.Seuil_Heures
             THEN 1 ELSE 0 END                                        AS Hors_Seuil
FROM    [dbo].[Journal_Chargement]  AS j WITH (NOLOCK)
JOIN    [dbo].[Seuil_Fraicheur]     AS s WITH (NOLOCK) ON s.Table_Cible = j.Table_Cible
WHERE   j.Statut = 'OK'
GROUP BY j.Table_Cible, s.Seuil_Heures;

-- Taux de rejet par source et par jour
SELECT  CAST(j.Date_Debut AS date)                         AS Jour,
        j.Source,
        SUM(j.Lignes_Rejetees) * 1.0 / NULLIF(SUM(j.Lignes_Lues), 0) AS Taux_Rejet
FROM    [dbo].[Journal_Chargement] AS j WITH (NOLOCK)
GROUP BY CAST(j.Date_Debut AS date), j.Source;

🔴 Expert — Loi de Goodhart et usages pervers#

Règles de défense : (1) mesurer en paires (vitesse + qualité), (2) afficher la tendance, (3) garder les métriques pour l'équipe d'abord, (4) revoir régulièrement : retirez toute métrique qui ne nourrit plus de décision, (5) distinguer métriques de diagnostic (explorées) et objectifs (rares, peu nombreux).

🔴 Expert — Tableaux de bord Power BI sur Azure DevOps#

Source : flux OData Analytics (voir Azure DevOps en profondeur). Modèle recommandé : WorkItemSnapshot (fait de flux quotidien), WorkItem (courant), Iteration, Area, User, Date.

Pages utiles : (1) Sprint en cours (burndown, capacité, bloqués), (2) Flux (CFD, WIP, âge des éléments, scatterplot de cycle time), (3) Qualité (bugs ouverts, vieillissement, défauts échappés, cas de test), (4) Release / burnup (périmètre vs terminé), (5) Santé du backlog.

Mesures DAX typiques :

WIP actuel =
CALCULATE ( DISTINCTCOUNT ( WorkItem[WorkItemId] ),
            WorkItem[State] IN { "Active", "In Progress", "Committed" } )

Throughput hebdo =
CALCULATE ( DISTINCTCOUNT ( WorkItem[WorkItemId] ),
            WorkItem[CompletedDate] <> BLANK(),
            DATESINPERIOD ( 'Date'[Date], MAX ( 'Date'[Date] ), -7, DAY ) )

Cycle time P85 (jours) =
PERCENTILEX.INC ( FILTER ( WorkItem, NOT ISBLANK ( WorkItem[CycleTimeDays] ) ),
                  WorkItem[CycleTimeDays], 0.85 )

Taux d'engagement tenu =
DIVIDE ( [Points terminés du sprint], [Points engagés au démarrage] )

Bonnes pratiques de conception, détaillées dans bonnes pratiques Power BI transverses : un modèle en étoile, pas d'import de toutes les révisions, mesures explicites, un thème sobre, annotations des événements (changement d'équipe, vacances) pour expliquer les ruptures.

Métriques — quelles métriques valent leur coût ?#

🤖 Contribution de l'IA#

Voir 11 — IA et outils.

Voir aussi#

• Panorama · Azure DevOps en profondeur · Jira et alternatives · Comparatif
• Scrum en pratique · Scrum et data · CI/CD
• Qualité des données (matrice) · Gouvernance et pilotage (matrice) · Glossaire

✻ Rédigé par Claude Sonnet 5.5