Il y a un moment (souvent discret) où une équipe bascule.
Au début, on “gère le travail” avec des unités d’effort : jours-hommes, complexité, story points, “ça vaut un 8”, “ça vaut un 3”…
Ça rassure. Ça donne l’impression qu’on maîtrise.
Et puis un jour, un manager pose une question bête — donc excellente :
“Ok… mais on livre combien, là, concrètement ?”
Silence gêné. Parce qu’on sait exactement combien on a estimé, mais beaucoup moins combien on a terminé.
C’est là que le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. (le débitThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine.) devient ton meilleur ami.
Le throughput, c’est quoi (version sans jargon) ?
Le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. = le nombre d’éléments de travail “terminés” par unité de temps (par jour, par semaine, par mois…).
Pas “en cours”. Pas “presque fini”. Pas “validé par moi mais pas encore déployé”.
Fini, selon une ligne d’arrivée que l’équipe définit clairement.
C’est littéralement une réponse à :
“Qu’est-ce qui sort réellement du système ?”
Cette définition est celle utilisée dans The Kanban Guide : “number of work items finished per unit of time”.
Pourquoi “compter l’effort” te ment (souvent) sur la réalité
Compter l’effort n’est pas “mal”. Ça peut aider à discuter capacité, complexité, apprentissage.
Le problème, c’est quand on confond :
- effort dépensé (input)
- valeur livrée (output)
1) L’effort récompense le “démarrage”, pas la “fin”
Tu peux “consommer” beaucoup d’effort sur plein de sujets… et livrer très peu.
Résultat classique : plein de cartes en “En cours”, peu de cartes en “Terminé”.
2) L’effort est une monnaie interne, le throughput est une réalité observable
Deux équipes peuvent faire “40 points” dans un sprint… et avoir des niveaux de livraison très différents.
Le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine., lui, ne négocie pas : soit c’est sorti, soit non.
3) L’effort masque les embouteillages
Le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. te force à regarder les blocages : validation, QA, attente métier, déploiement, dépendances…
Et c’est précisément là que le Kanban devient intéressant.
Throughput vs Velocity : la confusion fréquente
- Velocity (souvent) : somme de points “terminés” par sprint.
- ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. : compte d’items terminés par période.
Le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. ne “corrige” pas la taille des items. Il compte des unités finies.
C’est une différence majeure et assumée : “exact count… without compensation for item size”.
👉 Traduction terrain : si tes items sont gigantesques et hétérogènes, ton throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. sera chaotique… et ce sera un signal utile.
Le throughput te donne trois super-pouvoirs
1) Voir si ton système livre vraiment
Tu peux avoir une équipe “très occupée” et un throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. qui baisse.
C’est brutal, mais c’est sain : tu ne pilotes plus “l’occupation”, tu pilotes la livraison.
2) Relier livraison, WIP et délais (le trio magique)
Dans une approche flux, on travaille souvent avec WIP, cycle time / lead time, et throughput (les métriques de base).
Et surtout, tu peux te rappeler une loi simple en file d’attenteQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”. :
WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. = ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. × Lead TimeLead Timele temps entre “c’est demandé” et “c’est livré”.En IT : de la création du ticket (ou engagement) à sa mise en prod / clôture “Done”. (forme courante de la loi de Little)
Tu veux réduire les délais ?
En gros, tu as deux leviers :
- baisser le WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. (arrêter de tout commencer)
- augmenter le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. (fluidifier ce qui bloque)
3) Répondre à “Quand ce sera fini ?” sans théâtre
Avec un historique de throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine., tu peux faire des prévisions simples :
- “On livre souvent entre 6 et 10 items par semaine”
- “On a 28 items : ça fait probablement 3–5 semaines (selon la variabilité)”
C’est exactement l’esprit “métriques actionnables” : comprendre le flux et améliorer la prédictibilité.
Comment mesurer le throughput sans se tirer une balle dans le pied
Étape 1 — Définis ce que tu comptes (et où est “fini”)
Tu dois répondre à deux questions :
- C’est quoi un “item” ?
Un ticket support ? une user story ? une demande RH ? un article de blog ?
Choisis une unité compréhensible par ton contexte. - C’est où la ligne d’arrivée ?
Exemples :
- “Déployé en prod”
- “Validé QA + prêt release”
- “Publié”
- “Clôturé et confirmé par le demandeur”
Sans ça, tu vas compter du “presque”, et ton throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. deviendra un chiffre décoratif.
Étape 2 — Choisis une période fixe (souvent la semaine)
La semaine marche bien parce qu’elle lisse les aléas du quotidien :
- incidents
- absences
- validations tardives
- jours fériés
Étape 3 — Fais un graphe simple (run chart)
Tu notes, semaine par semaine : combien d’items ont franchi la ligne d’arrivée.
Tu obtiens vite :
- une moyenne
- une variabilité (semaines hautes / semaines basses)
- des signaux de stabilité ou de chaos
Étape 4 — Ne cherche pas “le bon chiffre”, cherche la tendance et les causes
Le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. sert à poser de meilleures questions, par exemple :
- “Pourquoi on est passés de 9 à 4 cette semaine ?”
- “Qu’est-ce qui a coincé ?”
- “Quelle étape sature ?”
- “Qu’est-ce qu’on a commencé qu’on n’arrive pas à finir ?”
Exemples concrets (IT, support, contenu… la vraie vie)
Support / Helpdesk
- Item = ticket
- “Fini” = résolu + confirmé par l’utilisateur
- ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. hebdo = nombre de tickets réellement clos
Tu peux même faire deux classes :
- incidents
- demandes de service
Parce que ce ne sont pas les mêmes bêtes.
Équipe dev
- Item = user story “right-sized”
- “Fini” = en prod (ou au moins “done” avec une définition stricte)
- ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. = stories livrées / semaine
Si tu bosses en gros lots (épics), ton throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. va s’effondrer… et ce sera une invitation à découper.
Contenu / marketing
- Item = article / landing page
- “Fini” = publié
- ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. = contenus publiés / semaine
Et soudain, tu ne débat plus 3h sur “l’effort”, tu regardes le pipeline éditorial réel.
Admin / demandes internes
- Item = demande (achat, contrat, accès, RH)
- “Fini” = demande traitée + notifiée
- ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. = demandes traitées / semaine
Ça marche partout où il y a un flux.
Les pièges classiques (et comment les éviter)
Piège 1 — “On va booster le throughput en découpant n’importe comment”
Oui, si tu triches sur la définition d’item, le chiffre grimpe.
Mais tu détruis l’intérêt du signal.
✅ Solution : découper pour réduire la taille des lots tout en gardant une unité de valeur cohérente (une demande compréhensible, testable, livrable).
Piège 2 — “On compare les personnes”
Le throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. est une mesure de système, pas un classement individuel.
✅ Solution : ne jamais l’utiliser pour juger une personne. Utilise-le pour parler du workflow (attentes, goulots, WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement., politiques).
Piège 3 — “On oublie la variabilité”
Une moyenne seule ment.
✅ Solution : regarde la dispersion (semaines basses/hautes). C’est la variabilité qui t’explique la prédictibilité.
Et dans un outil Kanban, concrètement ?
Que tu sois sur VulTask, Trello ou Jira, l’idée est la même :
- Tu choisis une colonne “Done” (ou l’événement “déployé”) comme finish line
- Tu comptes les items qui y entrent par semaine
- Tu observes :
- la stabilité
- les chutes
- les pics
- Tu changes le système (WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement., politiques, goulots) et tu vois l’effet sur la sortie
C’est la différence entre “on a beaucoup travaillé” et “on a beaucoup livré”.
Sources
- The Kanban Guide — définition des 4 flow metrics (WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement., throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine., cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”., work itemWork Itemce que tu fais circuler sur ton board. Un ticket, une user story, un bug, une demande, une tâche. age) et définition du throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine..
- Actionable Agile Metrics for Predictability — throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. comme “work completes per unit of time” + liens entre cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”., WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement., prédictibilité.
- Article ProKanban “What is Throughput and Why Should You Care?” — clarification pratique (compte exact, nécessité de définir ce qu’on mesure).
- Scrum.org — mise en perspective des flow metrics et usage complémentaire à d’autres métriques.
- Loi de Little (formulation L = λW) — base théorique reliant WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement., débitThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. et temps dans le système.
