Il y a deux métriques qui reviennent tout le temps quand on parle de Kanban et de flux : le 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”. et le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”..
Et pourtant, dans beaucoup d’équipes, on les confond.
Résultat :
- on annonce des délais irréalistes,
- on “améliore” des chiffres sans améliorer la vie,
- et on se dispute sur des mots alors qu’on parle juste… d’attente.
On va faire simple, concret, et surtout avec des exemples du quotidien.
1) La différence en une phrase
- 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”. = le temps du point de vue du client : “J’ai demandé → j’ai reçu.”
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. = le temps du point de vue de l’équipe : “On a commencé → on a fini.”
La clé est là :
👉 le 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”. inclut l’attente avant de démarrer.
👉 le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. commence quand on démarre réellement le travail.
2) Une image mentale très simple
Imagine un restaurant.
- Tu arrives, tu fais la queueQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”., tu commandes, tu attends, on te sert.
- 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”. = du moment où tu entres (demande) au moment où tu manges (livraison).
- En cuisine, le chef prend ta commande, prépare, dresse, envoie.
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. = du moment où la commande est prise en charge en cuisine au moment où l’assiette sort.
La différence, c’est souvent… la file d’attenteQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”..
3) Exemples du quotidien (sans jargon)
Exemple A — Acheter un colis en ligne
- Tu commandes un lundi.
- Le vendeur le prépare mercredi.
- Tu le reçois vendredi.
- 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”. : lundi → vendredi = 5 jours
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. : mercredi → vendredi = 3 jours
Ce que tu ressens en tant que client, c’est 5 jours.
Ce que l’équipe logistique “voit”, c’est 3 jours de travail effectif (et 2 jours d’attente avant prise en charge).
Exemple B — “Je dois appeler la banque”
Tu notes la tâche dans ta todo le lundi : “appeler la banque”.
Tu l’appelles… le jeudi (parce que tu repousses, réunions, énergie, etc.).
L’appel dure 10 minutes, tu règles le sujet.
- 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”. : lundi → jeudi = 4 jours
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. : démarrage de l’appel → fin = 10 minutes
Et c’est précisément pour ça que le Kanban est utile : il révèle que le problème n’est pas l’exécution (10 minutes), mais l’attente avant exécution (4 jours).
Exemple C — Une demande au support IT
Un utilisateur ouvre un ticket mardi 9h.
Le ticket est pris en charge mercredi 15h.
Résolu jeudi 10h.
- 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”. : mardi 9h → jeudi 10h
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. : mercredi 15h → jeudi 10h
Si ton support se félicite d’un “cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. correct” mais que le 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”. reste long, c’est souvent le signe d’un stock de tickets (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. implicite) ou d’une priorisation floue.
4) Pourquoi on a besoin des deux (sinon on se trompe de combat)
Lead time : la métrique “promesse client”
- C’est celle qui répond à : “en combien de temps tu me livres ?”
- Elle intègre les vraies frictions : files d’attente, arbitrages, blocages, “pas le temps”, etc.
Si tu veux améliorer l’expérience “client” (utilisateur, métier, externe), tu regardes en priorité le 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”..
Cycle time : la métrique “performance d’exécution”
- C’est celle qui répond à : “quand on bosse dessus, ça prend combien de temps ?”
- Elle aide à voir la qualité du process de production : interruptions, rework, dépendances, validations, etc.
Si tu veux améliorer la mécanique interne (comment tu produis), tu regardes en priorité le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”..
5) Le piège classique : “On est rapides” (oui… quand on démarre)
Beaucoup d’équipes ont ce profil :
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. assez bon : “Une fois qu’on s’y met, ça va vite.”
- 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”. catastrophique : “Mais ça met une éternité avant de démarrer.”
C’est le profil typique des équipes en surcharge.
Et c’est là que Kanban te met un miroir devant le visage :
- trop de choses en cours,
- trop de demandes “en attente” dans un backlog infini,
- trop de dépendances / validations,
- trop de “urgent” qui casse le flux.
Bref : le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. raconte l’atelier, le 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”. raconte la file.
6) Comment les mesurer sans te faire une thèse
Mesurer le lead time
Choisis un point “demande” clair :
- ticket créé,
- demande validée,
- carte entrée dans “À faire” (si c’est vraiment l’entrée du système),
- email reçu, etc.
Puis un point “livré” clair :
- ticket clos,
- déployé,
- livré au client,
- “Done” réellement consommable.
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”. = date livrée – date demandée.
Mesurer le cycle time
Point “début de travail réel” :
- la carte passe en “En cours”
- ou quand quelqu’un la prend effectivement.
Point “fin” :
- terminé (et pas “dev fini mais en attente QA depuis 5 jours”… ça dépend de ton workflow).
Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. = date fin – date début.
Astuce : si ton workflow a des colonnes “attente”, “validation”, “QA”, tu peux décider :
- soit que ça fait partie du cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. (souvent pertinent),
- soit de découper en sous-cycles (dev, QA, validation) pour comprendre où ça bloque.
7) À quoi ça sert concrètement (sans bullshit)
- Pour faire des prévisions : “La majorité des items similaires sortent en X jours de 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”..”
- Pour détecter un engorgement : cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. stable mais 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”. qui grimpe = file qui grossit.
- Pour justifier un 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.-limit" target="_blank" rel="noopener" title="Voir la définition">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. limitWIPWIPle 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. Limitrègle explicite : “dans cette colonne, pas plus de X items”. : “On ne ralentit pas, on réduit l’attente.”
- Pour arrêter de mentir avec un backlog : si le 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”. moyen est 20 jours, “on te le fait cette semaine” est une fiction.
8) Mini conclusion (celle qui fait mal mais qui aide)
Si tu devais ne retenir qu’une chose :
Le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. mesure la vitesse quand on travaille.
Le 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”. mesure la réalité vécue par le client.
Et dans 80% des organisations, le plus gros gain n’est pas “travailler plus vite”…
c’est attendre moins.
Donc souvent, améliorer le 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”., ce n’est pas “optimiser les devs”.
C’est :
- limiter 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.,
- clarifier les priorités,
- réduire les handoffs,
- simplifier les validations,
- rendre les blocages visibles.
Bref : remettre le flux au centre.
Bonus 1 — L’expliquer à un manager en 2 minutes (script prêt à copier)
Aujourd’hui, on a deux vitesses.
Notre cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”., c’est le temps “quand on travaille vraiment”. Ça, on le maîtrise plutôt bien.
Notre 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”., c’est le temps “vu par le client” : il inclut l’attente avant qu’on démarre.
Et c’est souvent là que le délai explose : pas parce qu’on est lents, mais parce qu’on a une file d’attenteQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”. invisible.
Donc si on veut réduire les délais perçus, le meilleur levier n’est pas “aller plus vite”, c’est attendre moins :
- limiter le nombre de sujets en cours (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.),
- clarifier ce qui est “prêt à démarrer”,
- rendre visibles les blocages et les validations.
Objectif : réduire le 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”., et donc améliorer la satisfaction + la prévisibilité.
Petit punchline qui marche bien :
“On est rapides… le jour où on commence. Le problème, c’est le temps avant de commencer.”
Bonus 2 — Check-list pour instrumenter Lead time & Cycle time dans VulTask
L’idée : définir 2 points de départ (demande vs démarrage) et 1 point d’arrivée (livré). Le reste est optionnel.
1) Choisir tes points de mesure (et les écrire noir sur blanc)
- 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”. – départ (demande) : ex. carte créée ou carte entrée dans “À traiter”
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. – départ (travail commencé) : ex. carte entrée dans “En cours”
- Arrivée (livré) : ex. carte entrée dans “Terminé” (mais “terminé = consommable”, pas “dev fini”)
Règle d’or : si vous débattez 20 minutes sur “c’est quand que ça commence”, c’est que votre process est flou… et la métrique va le révéler 😄
2) Structurer un workflow minimal (qui rend l’attente visible)
Un exemple simple (adaptable) :
- Demandes (arrivée du besoin)
- Prêt (priorisé, clair, faisable)
- En cours (cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. démarre ici)
- Validation / QA (si applicable)
- Bloqué / En attente (très utile)
- Terminé (livré)
Pourquoi “Prêt” est important : c’est souvent là que tu vois l’embouteillage se former.
3) Mettre des politiques explicites (sinon les chiffres mentent)
- Quand une carte a le droit de passer en En cours ? (ex. “acceptance criteria OK”)
- Quand une carte est Terminé ? (ex. “déployé + vérifié”)
- Quand utilise-t-on Bloqué / En attente ? (et comment on en sort)
4) Décider si “Validation / QA” est dans le cycle time
Deux options valides :
- Option A (souvent meilleure) : QA/validation fait partie du cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. (car c’est du temps système réel)
- Option B : tu mesures un cycle “dev only” + un cycle “end-to-end” (plus fin, mais plus de discipline)
Si tu vulgarises pour un public large : garde Option A.
5) Mesurer sans se noyer : commence avec 2 chiffres
Au départ, ne cherche pas 12 graphes.
- 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”. médian (la “normale”)
- 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”. 85% (un repère “promesse” : “dans 85% des cas, c’est livré en ≤ X jours”)
Idem pour le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. si tu veux comparer atelier vs file d’attenteQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”..
6) Lire les signaux (diagnostic rapide)
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. stable + 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”. qui monte = la file grossit → surcharge / trop de 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. / trop de demandes “prêtes”
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. qui explose = interruptions, rework, dépendances, validations mal gérées
- Beaucoup de “Bloqué” = problème systémique (dépendances, validation, accès, décisions)
7) Le “starter pack” d’amélioration (simple et efficace)
- Mets un 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.-limit" target="_blank" rel="noopener" title="Voir la définition">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. limitWIPWIPle 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. Limitrègle explicite : “dans cette colonne, pas plus de X items”. sur “En cours” (même grossier au début)
- Réduis le nombre de cartes en “Prêt” (sinon c’est un backlog déguisé)
- Fais une micro-règle : “On finit avant de commencer”
La file d’attente invisible (et pourquoi ton tableau la rend enfin visible)
Si tu as lu jusqu’ici, tu as sûrement compris le twist :
- Le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. te raconte comment tu travailles quand tu travailles.
- Le 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”. te raconte ce que vit l’autre personne pendant qu’elle attend.
Et dans la vraie vie, la frustration ne vient presque jamais du “temps de cuisson”…
Elle vient du temps passé à regarder la casserole.
Dans une équipe IT, c’est pareil :
- “On a corrigé le bug en 2 heures” (cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”.)
- “Oui, mais j’ai attendu 8 jours avant que quelqu’un s’en occupe” (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”.)
Donc quand tu veux améliorer “la vitesse”, la question utile n’est pas :
“Comment aller plus vite ?”
Mais plutôt :
“Pourquoi ça attend autant avant de démarrer ?”
Ce que tu peux faire dès demain (sans révolutionner ton organisation)
- Rends l’attente visible
Ajoute une colonne du style “Prêt” (priorisé, clair, faisable) entre la demande et le travail réel.
Tu verras immédiatement si ton système fabrique une file. - Limite le nombre de cartes “En cours”
Un 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.-limit" target="_blank" rel="noopener" title="Voir la définition">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. limitWIPWIPle 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. Limitrègle explicite : “dans cette colonne, pas plus de X items”., même simple, fait souvent baisser le 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”. plus vite que n’importe quel “plan d’optimisation”. - Traite “Bloqué / En attente” comme une alarme, pas comme une poubelle
Une carte bloquée n’est pas “une carte qui dort”.
C’est un délai qui grandit en silence.
À emporter
- 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”. = promesse (ce que le client ressent)
- Cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. = exécution (ce que l’équipe maîtrise)
- Si le 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”. est long alors que le cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. est bon : tu n’as pas un problème de vitesse, tu as un problème de file.
Si tu utilises VulTask, commence simple :
définis clairement quand une demande “entre”, quand le travail “démarre”, et quand c’est réellement “livré”.
Après une ou deux semaines, tu auras déjà des chiffres qui parlent.
👉 Et si tu veux aller plus loin, le prochain bon pas est souvent : 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. limits + une visualisation type CFDCFDun graphe qui montre, au fil du temps, combien d’items se trouvent dans chaque état (To Do / In Progress / Done…). (diagramme de flux cumulatif) pour voir où le système s’engorge.
