Aller au contenu

Temps de cycle et flux de travail

Le temps de cycle — la durée entre le début et la fin du travail sur un ticket — est la mesure que les outils de gestion de projet mettent le plus volontiers sous « carte de contrôle ». C'est aussi celle où la carte de contrôle est le plus souvent mal construite.

La « carte de contrôle » de Jira

Jira propose un rapport nommé Control Chart. D'après la documentation d'Atlassian, il affiche :

  • le temps de cycle de chaque ticket ;
  • la moyenne et une moyenne glissante sur 20 % des tickets affichés (nombre impair, minimum 5) ;
  • une bande bleue qui « représente l'écart-type ».

La documentation ne mentionne ni limites naturelles du processus, ni règles de détection. Ce n'est donc pas une carte de contrôle au sens de Shewhart : c'est un nuage de points avec une moyenne et une bande moyenne ± écart-type.

Erreur fréquente : écart-type global contre écart-type local

Une vraie carte de Shewhart estime la dispersion à partir des écarts entre points voisins (l'étendue mobile), pas à partir de l'écart-type de toutes les données. La différence est fondamentale : si le processus a changé en cours de route, l'écart-type global absorbe ce changement et élargit les limites, ce qui masque précisément le signal qu'on cherchait. Le chapitre Variation et cartes détaille ce point.

La critique de Vacanti

Daniel Vacanti, auteur de Actionable Agile Metrics for Predictability (2015, réédition 2025), est le praticien du Kanban qui a le plus écrit sur le sujet. Sa position a évolué en deux temps.

Premier temps : abandonner la carte, garder les percentiles

Dans le premier livre, le chapitre 4 sur les nuages de points de temps de cycle contient une section au titre explicite : Your Data is Not Normal (sommaire de la réédition). Sur un forum en 2018, il est plus direct :

Ce que Jira appelle une carte de contrôle […] est intrinsèquement nuisible.

Il recommande à la place un nuage de points avec des lignes de percentiles (50 %, 85 %, 95 %) — « pas des lignes d'écart-type ! » (source). L'intérêt du percentile est double : il ne suppose aucune forme de distribution, et il répond directement à la question du client (« dans 85 % des cas, un ticket de ce type est fini en 9 jours ou moins »).

Second temps : revenir aux vraies cartes XmR

Dans Actionable Agile Metrics Volume II (2023), Vacanti consacre une partie entière aux Process Behaviour Charts de Wheeler : construction, quantité de données nécessaire, détection des signaux, et application des cartes XmR aux quatre mesures de flux — encours, temps de cycle, âge des tickets, débit (sommaire).

L'évolution est cohérente : il ne rejetait pas le SPC, il rejetait le faux SPC de Jira.

Ce que coûte l'asymétrie, mesuré

Les temps de cycle sont typiquement asymétriques : beaucoup de tickets courts, quelques tickets très longs. Une loi log-normale est une approximation courante (l'ajustement exact varie selon les équipes ; Troy Magennis documente aussi des formes de Weibull).

Le script de vérification (§3) mesure ce qui se passe quand on applique une carte XmR et les règles de Western Electric à 200 000 points tirés d'une loi log-normale de paramètre σ = 1, sans aucun changement réel du processus :

Données Règle 1 seule Règles WE 1 à 4
Gaussiennes (référence) 0,29 % des points 1,86 % des points
Log-normales σ = 1 3,38 % 9,34 %
Logarithme des log-normales 0,26 % 1,83 %

Lecture : sur des temps de cycle bruts, même la règle 1 seule sonne douze fois trop souvent, et l'ensemble des quatre règles signale près d'un point sur dix alors que rien n'a changé. Passer au logarithme avant de tracer la carte restaure exactement le comportement de référence.

Pourquoi les règles de séquences souffrent plus que la règle 1

Dans une loi asymétrique à droite, la médiane est sous la moyenne. La majorité des points tombent donc sous la ligne centrale, et la règle 4 (« 8 points de suite du même côté ») se déclenche bien plus souvent que les 0,8 % (2 × 0,5⁸) de probabilité par point qu'elle a sur des données symétriques. Les règles de séquences supposent une symétrie que les durées n'ont pas.

À retenir

Pour un temps de cycle, trois options correctes :

  1. Percentiles sur un nuage de points — robuste, lisible, sans hypothèse ; ne détecte pas automatiquement les changements.
  2. Carte XmR sur le logarithme — retrouve les propriétés de la carte de Shewhart ; les limites se relisent en durées par exponentielle.
  3. Carte XmR brute avec la règle 1 seule, en acceptant quelques pourcents de fausses alarmes — à réserver aux distributions modérément asymétriques.

Option à proscrire : les quatre règles de Western Electric sur des durées brutes.

La limite de fond : les pièces uniques

Même sur une échelle logarithmique, il reste l'objection du chapitre précédent : deux tickets ne sont pas deux pièces d'une même série. Une « cause spéciale » sur une carte de temps de cycle est souvent un ticket simplement différent des autres.

La parade classique est la stratification : une carte par type de travail (anomalie, petite évolution, chantier). Elle réduit le problème sans le supprimer, et elle divise d'autant le nombre de points par carte — ce qui réduit la puissance de détection. Il n'y a pas de solution gratuite ici, et c'est une des raisons pour lesquelles les agents d'IA, qui traitent des tâches beaucoup plus nombreuses et plus homogènes qu'une équipe humaine, sont en fait un meilleur terrain pour le SPC que les équipes humaines elles-mêmes (voir Orchestrateurs).