Work Charts : Burndown, Burnup et Kanban pour la Gestion de Flux

Un burndown chart montre le travail qui reste à faire dans une période fixe. Un burnup chart montre le travail accompli face au périmètre total, qui peut bouger. Un tableau Kanban montre où se trouve chaque élément de travail à un instant donné et sert à piloter le flux en limitant le travail en cours.

Que mesurent un burndown, un burnup et un tableau Kanban ?

On regroupe ces trois outils sous le nom de work charts : des affichages visuels qui rendent l'avancement lisible par toute l'équipe et par les parties prenantes, sans rapport écrit. Ils ne répondent pas à la même question. Les deux burn charts racontent une histoire dans le temps (où en sommes-nous par rapport à hier, et à quel moment aurons-nous fini ?). Le tableau Kanban donne une photographie du système de travail (qu'est-ce qui avance, qu'est-ce qui bloque, où s'accumule le travail ?).

Le Scrum Guide de Ken Schwaber et Jeff Sutherland (version de novembre 2020) cite les burn-downs, les burn-ups et les diagrammes de flux cumulés parmi les pratiques qui servent à prévoir l'avancement. Il ajoute une réserve que l'on oublie souvent : ces outils ne remplacent pas l'empirisme, et seul ce qui s'est déjà produit doit guider les décisions sur la suite. Un graphique est une aide à la conversation, pas une promesse de date.

Le burndown chart. L'axe horizontal représente le temps de la période, l'axe vertical le travail restant (en points d'effort, en heures ou en nombre d'éléments). On trace souvent une ligne idéale qui part du total prévu et rejoint zéro à la fin de la période. Si la courbe réelle reste au-dessus de cette ligne, l'équipe est en retard sur son rythme ; si elle remonte, du travail a été ajouté ou réestimé. C'est sa faiblesse : un ajout de périmètre et un manque d'avancement produisent tous deux une courbe qui ne descend pas, et le graphique ne permet pas de distinguer les deux.

Le burnup chart. Il sépare ce que le burndown mélange. Une ligne représente le périmètre total, une autre le travail terminé, qui monte depuis zéro. L'écart entre les deux est le travail restant. Quand le client ajoute des fonctionnalités, la ligne de périmètre monte, et tout le monde le voit. Cette ligne n'est donc pas forcément une droite horizontale : elle reste plate seulement si le périmètre ne change pas. Pour comparer les deux graphiques en détail, consultez notre article sur les graphiques d'avancement agile : burndown, burnup et combiné.

Le tableau Kanban. Chaque colonne correspond à une étape du flux (par exemple À faire, En analyse, En développement, En test, Terminé) et chaque carte à un élément de travail. Le Kanban Guide de Kanban University décrit six pratiques générales : visualiser, limiter le travail en cours, gérer le flux, rendre les politiques explicites, mettre en place des boucles de rétroaction, et s'améliorer en collaborant et en expérimentant. Il définit la limite de WIP comme le nombre maximal d'éléments de travail autorisés en même temps et précise que ces limites sont la clé d'un système tiré. Le détail du fonctionnement des colonnes est traité dans notre article sur les tableaux Kanban et la limitation du travail en cours (WIP).

Burndown et Kanban : pourquoi le burnup convient mieux à une équipe sans sprint

Beaucoup de recherches portent sur le « burndown chart Kanban ». La difficulté est structurelle : un burndown a besoin d'un point d'arrivée fixe. Il mesure le travail restant jusqu'à la fin d'une période dont la durée est connue d'avance. Le Scrum Guide fixe ce cadre pour Scrum : les Sprints sont des événements de durée fixe, d'un mois ou moins. Une équipe Kanban, elle, tire le travail en continu. De nouveaux éléments arrivent dans la colonne À faire pendant que d'autres sortent dans Terminé. Il n'y a pas de moment où le « restant » doit tomber à zéro.

Une équipe Kanban peut tout de même tracer un burndown si elle se donne une échéance artificielle (une version à livrer pour une date). Dans ce cas, elle découpe un lot de travail et suit ce lot jusqu'à sa fin. C'est possible, mais le graphique ne dit plus rien sur le flux du reste du travail. Trois options conviennent mieux à un travail continu :

• Le burnup chart, sur une version ou un objectif : il montre en même temps l'avancement et la croissance du périmètre, ce qui correspond à la réalité d'un flux où les demandes arrivent sans cesse.
• Le diagramme de flux cumulé (CFD) : le Kanban Guide de Kanban University le présente comme un graphique qui contient des informations utiles sur le flux du travail à travers plusieurs activités. Chaque bande colorée correspond à une colonne du tableau ; une bande qui s'élargit signale une accumulation.
• Le graphique de suivi des délais (run chart) et la distribution des délais : le même guide décrit le run chart comme le tracé, sur une ligne de temps, des délais des éléments terminés. L'objectif est de resserrer la distribution (plus de prévisibilité) et de la décaler vers des délais plus courts.

Si votre équipe applique Scrum et veut ajouter les pratiques de flux sans renoncer aux Sprints, le burndown du Sprint et le tableau Kanban peuvent coexister : le premier pour l'objectif de la période, le second pour piloter le travail au quotidien. Notre article sur les diagrammes d'avancement et le suivi de travail itératif montre comment lire ces graphiques ensemble. Pour concevoir un système Kanban complet, colonnes, politiques et limites comprises, la formation Kanban System Design traite le sujet de bout en bout, et la formation Applying Professional Kanban (PK1) s'attache aux mesures du flux.

WIP, débit, âge des éléments et cycle time : les quatre mesures du flux, et ce qui les distingue du lead time

Un tableau Kanban ne produit pas de courbe, mais il produit des mesures. The Kanban Guide de John Coleman et Daniel Vacanti (version v2025.5, mise à jour le 1er mai 2025) en retient quatre, qu'il appelle les mesures du flux. Le tableau ci-dessous reprend ses définitions, complétées par le lead time tel que le décrit Kanban University.

Cycle time ou lead time ? La version précédente de cet article définissait le lead time comme le temps entre la mise d'une carte sur le tableau et la livraison au client. La définition de Kanban University est plus précise : le lead time part du point d'engagement, c'est-à-dire du moment où l'équipe accepte de faire le travail, et non du moment où une idée est notée dans une colonne d'attente. Le cycle time, lui, part du moment où le travail commence réellement. Dans les deux cas, ce qui compte est que l'équipe écrive noir sur blanc où commence et où finit chaque mesure : c'est une politique explicite, l'une des six pratiques Kanban. À l'examen, retenez l'ordre : le lead time englobe le cycle time, car il commence plus tôt.

Vélocité ou débit ? La vélocité mesure la quantité de travail terminée par itération, le plus souvent en points d'effort estimés. Le débit compte des éléments. The Kanban Guide insiste sur ce point : le débit est le compte exact des éléments de travail. Il n'a donc besoin ni d'estimation ni d'itération, ce qui en fait la mesure naturelle d'une équipe Kanban, alors que la vélocité suppose une période fixe et une échelle d'estimation commune.

Que faire quand une colonne atteint sa limite ? Le même guide demande aux membres d'un système Kanban de contrôler explicitement le nombre d'éléments présents entre le début et la fin du flux. Une limite atteinte n'est donc pas un simple voyant à ignorer : l'équipe arrête de commencer du travail nouveau dans cette étape et aide à terminer ce qui y est déjà. Cette mobilisation de plusieurs personnes sur les éléments qui ralentissent le flux porte souvent le nom de swarming. Si la limite est atteinte en permanence, c'est une information sur le système (un goulot d'étranglement, au sens de la théorie des contraintes), et la bonne réponse est d'en discuter, pas de relever la limite en silence. Pour voir comment le flux tiré s'inscrit dans la planification, lisez notre article sur la planification lean et le flux tiré.

Comment les questions d'examen PMI abordent les work charts

Les certifications du PMI qui couvrent les approches adaptatives, comme le PMP (Project Management Professional) et surtout le PMI-ACP (Agile Certified Practitioner), emploient ce vocabulaire dans des questions de mise en situation. Ces questions testent rarement une définition isolée. Elles décrivent un graphique ou un tableau, puis demandent ce que l'équipe ou le chef de projet devrait faire ensuite. Le format, la durée et le contenu exact de chaque examen sont publiés par le PMI dans le contenu d'examen de la certification : c'est ce document qui fait foi, pas un article de blog.

Pour répondre, posez-vous trois questions dans cet ordre :

1. Quel est le contexte ? Une itération à durée fixe oriente vers le burndown ; un travail continu oriente vers le tableau Kanban et ses mesures ; une version dont le périmètre change oriente vers le burnup.
2. Que montre réellement le graphique ? Une courbe de burndown qui stagne ne prouve pas que l'équipe est lente : le périmètre a peut-être augmenté. Seul un burnup permet de trancher.
3. Quelle action respecte les valeurs agiles ? Les bonnes réponses vont en général vers la transparence et l'équipe : discuter du constat avec l'équipe, rendre le problème visible, finir avant de commencer. Les mauvaises vont vers le contrôle unilatéral : retirer du travail sans consulter le Product Owner, relever une limite de WIP en silence, exiger des heures supplémentaires.

Voici un exemple de question rédigé pour cet article (ce n'est pas une question d'examen réelle) :

Une équipe suit une version à l'aide d'un burnup chart. Depuis trois semaines, la courbe du travail terminé progresse au même rythme, mais l'écart avec la ligne de périmètre ne diminue pas. Le sponsor s'inquiète de la productivité de l'équipe. Que devrait faire le chef de projet en premier ?A. Demander à l'équipe d'accélérer pour rattraper le retard B. Montrer au sponsor que la ligne de périmètre monte et examiner avec le Product Owner les ajouts récents C. Remplacer le burnup par un burndown, plus simple à lire D. Augmenter la limite de WIP de la colonne En cours

La réponse attendue est B. Le travail terminé progresse régulièrement : l'équipe n'est pas en cause. C'est le périmètre qui grandit au même rythme, et le burnup sert justement à le rendre visible. La question devient une décision de priorisation avec le Product Owner, en lien direct avec le processus de gestion du backlog et du périmètre agile. Pour vous entraîner sur ce type de raisonnement dans les conditions d'une épreuve, Atypix propose un simulateur d'examen PMP. Les candidats aux examens du PMI qui préparent à Dakar peuvent consulter la page du centre d'examen Pearson VUE 90280 d'Atypix à Dakar et celle des formations certifiantes à Dakar ; pour le Canada, les sessions figurent sur la page des formations certifiantes au Canada.

Les pièges classiques sur les work charts, et comment les corriger

• Confondre burnup et burndown. Le burnup monte (travail accompli), le burndown descend (travail restant). Moyen mnémotechnique : « BurnUP monte, BurnDOWN descend ».
• Croire que la ligne de périmètre d'un burnup est toujours horizontale. Elle ne l'est que si le périmètre ne change pas. Sa montée est l'information la plus utile du graphique.
• Lire un burndown qui stagne comme un manque de productivité. Du travail a peut-être été ajouté ou réestimé. Avant de conclure, regardez le périmètre.
• Traiter la limite de WIP comme une suggestion. Une limite atteinte appelle une réponse : arrêter de commencer et aider à finir. Une limite atteinte en permanence révèle un goulot d'étranglement dont l'équipe doit discuter.
• Mélanger cycle time et lead time. Le cycle time commence quand le travail commence ; le lead time commence au point d'engagement, plus tôt. Le lead time englobe donc le cycle time.
• Utiliser la vélocité pour comparer deux équipes. Les points d'effort sont propres à chaque équipe. Le débit, qui compte des éléments, se compare plus facilement dans le temps pour une même équipe, mais pas davantage entre équipes qui découpent le travail différemment.
• Penser que les burn charts relèvent des projets prédictifs. Ils sont nés dans les pratiques agiles et servent avant tout dans les approches adaptatives, à côté des contrôles visuels comme le tableau Kanban.

Pour réviser rapidement, essayez de répondre sans relire : quelle est la différence entre un burnup et un burndown ? Pourquoi un burndown s'applique-t-il mal à un flux continu ? Que mesure le débit, et en quoi diffère-t-il de la vélocité ? Que fait l'équipe quand une colonne atteint sa limite ? Où commence le lead time ?

Questions fréquentes

Quelle est la différence entre un burndown chart et un burnup chart ?

Le burndown chart montre le travail restant, qui descend vers zéro à la fin d'une période fixe. Le burnup chart montre deux lignes : le travail accompli, qui monte, et le périmètre total. L'écart entre elles est le travail restant. Le burnup a un avantage décisif : il montre séparément les ajouts de périmètre, que le burndown confond avec un manque d'avancement.

Peut-on utiliser un burndown chart avec un tableau Kanban ?

Oui, à condition de fixer une échéance, par exemple une version à livrer pour une date donnée, et de suivre ce lot jusqu'à sa fin. Mais le flux continu d'une équipe Kanban n'a pas de moment où le travail restant tombe à zéro. Le burnup, le diagramme de flux cumulé et le suivi des délais décrivent mieux ce type de travail.

Quelle est la différence entre cycle time et lead time ?

Le cycle time est le temps écoulé entre le début réel du travail sur un élément et sa fin. Le lead time commence plus tôt : selon Kanban University, au point d'engagement, quand l'équipe accepte de faire le travail. Le lead time englobe donc le cycle time. Chaque équipe doit écrire où commencent et finissent ses mesures, pour que tout le monde parle du même délai.

Que faire quand une colonne du tableau Kanban atteint sa limite de WIP ?

L'équipe arrête de faire entrer du travail nouveau dans cette colonne et se mobilise pour terminer les éléments qui s'y trouvent déjà, ce qu'on appelle souvent le swarming. Si la limite est atteinte en permanence, elle signale un goulot d'étranglement. La bonne réponse est d'en discuter en équipe et d'agir sur la cause, pas de relever la limite sans le dire.

La vélocité et le débit, est-ce la même chose ?

Non. La vélocité mesure le travail terminé par itération, généralement en points d'effort estimés par l'équipe. Le débit compte le nombre exact d'éléments terminés par unité de temps, sans estimation. Le débit convient donc à un flux continu sans itération, alors que la vélocité suppose une période fixe et une échelle d'estimation propre à chaque équipe.