Il y a un moment, dans toutes les équipes IT, où la conversation déraille.
— “On a trop de tickets en cours.”
— “Oui mais le throughput est bon.”
— “Sauf que le lead time explose.”
— “Normal, on a un SLA.”
— “Non, un SLE.”
— “… Attends. On parle de quoi exactement ?”
Bienvenue dans le grand bingo des termes Kanban IT.
Le problème n’est pas que ces mots existent. Le problème, c’est qu’on les prononce comme des incantations, alors qu’ils sont censés être des outils de pilotage. Et comme tout outil, si on ne sait pas ce qu’on tient dans la main… on finit par se taper sur les doigts.
Je te propose donc un glossaire “terrain” : définitions simples, exemples concrets, et surtout ce que tu peux en faire lundi matin.
1) WIP — Work In Progress (travail en cours)
Définition : le 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.
Pourquoi c’est vital :
Parce que le WIP, c’est la tentation permanente du “on commence tout, on finira bien par finir”.
Exemple :
Ta colonne “En cours” contient 12 tickets. Ton équipe est 3. Ça veut dire : 4 choses “en cours” par personne. Donc : contexte cassé, interruptions, finitions lentes.
Conseil pratico-pratique :
Un WIP limit n’est pas une punition. C’est un pare-chocs : il empêche l’équipe de prendre de la vitesse… jusqu’au mur.
2) Lead Time — délai total (de la demande à la livraison)
Définition : le 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”.
Pourquoi c’est important :
Le lead time mesure ce que le client vit : l’attente.
Piège classique :
On croit que “le travail” commence quand on code. Mais le client, lui, a commencé à attendre dès qu’il a demandé.
Exemple :
Un ticket est créé le 1er février, livré le 20 février. Lead time = 19 jours.
3) Cycle Time — délai de réalisation (du début réel au “Done”)
Définition : le temps entre “on commence vraiment” et “c’est fini”.
Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”.
Différence simple :
- Lead time = attente + travail
- Cycle time = travail (et blocages) pendant l’exécution
Exemple :
Ticket créé le 1er, commencé le 10, terminé le 20.
- Lead time = 19 jours
- Cycle time = 10 jours
Usage :
Le cycle time est souvent la métrique préférée des équipes, parce qu’elle reflète mieux leur capacité de livraison quand le sujet est lancé.
4) Throughput — débit (combien on finit par unité de temps)
Définition : le nombre d’items terminés sur une période donnée.
Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine.
Pourquoi c’est utile :
Le throughput te dit si le système sort quelque chose, ou s’il accumule.
Attention :
Le throughput ne dit pas si tu livrais “vite” item par item. Tu peux livrer 30 petits tickets et laisser 2 gros bloqués depuis 2 mois. Le débit a l’air bon… le client pleure quand même.
5) Flow Efficiency — efficacité de flux (temps actif vs temps d’attente)
Définition : part du temps où l’item est vraiment travaillé vs le temps total où il stagne.
Formule (simple) :
Flow efficiency = (temps actif / lead time) × 100
Exemple :
Lead time 10 jours, temps actif 2 jours → flow efficiency = 20%
Ça veut dire : 80% du temps, le ticket attend (review, validation, dispo d’un expert, environnement, priorité, etc.).
Ce que ça révèle :
L’amélioration ne se trouve pas toujours dans “coder plus vite”, mais dans “attendre moins”.
6) Blocker / Blocked — blocage
Définition : un item “bloqué” ne peut pas avancer pour une raison externe ou interne (dépendance, attente de validation, accès, incident, manque d’info…).
Bon réflexe Kanban :
Un blocage doit être visible (tag, couleur, icône) et surtout discuté.
Un ticket bloqué invisible, c’est un mensonge poli.
7) Bottleneck — goulot d’étranglement
Définition : l’étape où le flux ralentit systématiquement (queue qui grossit, attente récurrente).
Souvent : revue de code, validation métier, tests, mise en production, sécurité…
Le signe simple :
Une colonne se remplit, la suivante reste vide.
Ce qu’on fait trop souvent :
On met “plus de pression” sur l’équipe… au lieu de traiter le goulot.
8) Queue — file d’attente
Définition : items en attente devant une étape.
Ex : “À valider”, “En review”, “À tester”.
Pourquoi c’est crucial :
Une queue, c’est du lead time qui s’accumule.
Et c’est souvent là que se cache l’essentiel de la latence.
9) Class of Service — classes de service (règles de priorité explicites)
Définition : des catégories qui définissent comment traiter un item (priorité, délai attendu, risque).
Ex :
- Expedite (urgent bloquant)
- Fixed Date (deadline)
- Standard
- Intangible (amélioration sans date, mais utile)
Pourquoi c’est sain :
Parce que ça évite le “tout est urgent”, ce grand classique des systèmes qui saturent.
10) CFD — Cumulative Flow Diagram (diagramme de flux cumulatif)
Définition : un graphe qui montre, au fil du temps, combien d’items se trouvent dans chaque état (To Do / In Progress / Done…).
Ce que tu lis dans un CFD :
- Largeur d’une bande “In Progress” qui augmente → WIP qui gonfle
- Bande “Done” qui monte régulièrement → throughput stable
- Une bande “Review” qui s’épaissit → goulot en review
Image mentale :
Le CFD, c’est une radiographie du flux. Tu ne vois pas les tickets, tu vois le système.
11) WIP Limit — limite de travail en cours
Définition : règle explicite : “dans cette colonne, pas plus de X items”.
Pourquoi ça marche :
Parce que ça force à finir avant de commencer.
Exemple simple :
“In Progress” limité à 3.
Si c’est plein : tu aides à débloquer, tu review, tu testes, tu termines. Tu ne “crées pas du futur travail”.
12) SLE — Service Level Expectation (attente de niveau de service)
Définition : un engagement probabiliste basé sur l’historique :
“Quand on prend un ticket de ce type, on le livre dans X jours dans 85% des cas.”
Pourquoi c’est puissant :
Parce que ça colle à la réalité : la variabilité existe. On la mesure, on l’assume, on la pilote.
Exemple :
Sur les 3 derniers mois :
- 85% des tickets “Standard” livrés en ≤ 8 jours → SLE = 8 jours (85%)
13) SLA — Service Level Agreement (accord contractuel)
Définition : un engagement formel (contrat / accord de service) avec conséquences éventuelles (pénalités, crédits…).
Différence simple :
- SLE : attente interne/produit, basée sur données
- SLA : engagement externe, souvent juridique/contractuel
Piège :
Avoir un SLA sans système capable de tenir un flux… c’est signer une promesse à crédit.
14) SLT — Service Level Target (objectif de niveau de service)
Définition : une cible interne : “on vise X jours” (souvent liée au SLE, mais plus volontariste).
Bon usage :
Tu peux avoir :
- SLE (réalité mesurée)
- SLT (objectif d’amélioration)
… et suivre l’écart.
15) Aging WIP — âge du WIP (depuis combien de temps c’est “en cours”)
Définition : pour chaque item en cours, combien de temps il a déjà passé dans le système (ou dans un état donné).
Pourquoi c’est un super signal :
Parce que ça te permet d’identifier les tickets qui deviennent “dangereux” (risque de dérive, oubli, complexité cachée).
Bonne pratique :
Mettre en évidence les items qui dépassent un seuil (ex : au-delà du SLE 85%).
16) Work Item — l’unité de travail
Définition : ce que tu fais circuler sur ton board. Un ticket, une user story, un bug, une demande, une tâche.
Rappel :
Si ton work item n’a pas une définition claire du “Done”, tu mesures du brouillard.
17) Definition of Done — définition de “fini”
Définition : conditions explicites pour considérer un item terminé.
Ex : tests passés, PR mergée, doc mise à jour, déployé, validé…
Pourquoi c’est indispensable :
Sans Definition of Done, le “Done” devient un état psychologique.
18) Pull System — système en tirage
Définition : on ne “pousse” pas du travail sur les gens. Le travail est “tiré” quand il y a de la capacité et que les règles le permettent.
Pourquoi c’est plus stable :
Parce que ça réduit le WIP, donc réduit le lead time.
19) Push vs Pull — la différence qui change tout
- Push : “Tiens, prends ce ticket en plus.”
- Pull : “J’ai fini, je tire le prochain selon les règles.”
Indice :
Si tu entends beaucoup “on te met ça dans les mains”, tu es en push.
20) Little’s Law — la loi de Little (le lien WIP / débit / délai)
Une relation simple (à condition que le système soit relativement stable) :
Lead Time ≈ WIP / Throughput
Interprétation :
Si ton throughput reste constant, plus tu as de WIP, plus ton lead time augmente.
Exemple :
WIP = 20 items, throughput = 10 items/semaine → lead time ≈ 2 semaines.
Ce n’est pas de la magie. C’est de la tuyauterie.
21) Forecasting — prévision (basée sur le débit)
Définition : estimer quand un ensemble de tickets sera terminé à partir du throughput historique (ou via simulation type Monte Carlo).
Bon sens Kanban :
On prévoit mieux avec du débit et de la variabilité mesurée, qu’avec des estimations au doigt mouillé.
22) Replenishment — réapprovisionnement
Définition : moment où l’on décide quoi entre dans le système “prêt à être tiré”.
Souvent une étape “Ready”.
Pourquoi ça compte :
Parce que si le “Ready” est rempli de tickets flous, l’équipe va perdre du temps à clarifier… en plein milieu du flux.
23) Ready — “prêt” (mais prêt à quoi ?)
Définition : état où l’item est suffisamment clair pour être commencé sans découvrir un manque critique au bout de 30 minutes.
Astuce :
“Ready” sans critères, c’est une salle d’attente.
24) Expedite — urgentissime
Définition : classe de service qui court-circuite (presque) tout.
Règle saine :
L’expedite doit être rare, et compensé : si tout est expedite, plus rien n’est expedite, et ton système devient un incendie permanent.
25) Cadence — le rythme des rituels
Définition : fréquence des moments de pilotage (replenishment, delivery review, ops review, risk review…).
Pourquoi c’est mieux que “des réunions” :
Parce que la cadence est une mécanique de contrôle, pas un calendrier de souffrance.
Le mini-guide “comment ne pas se tromper de mots”
Si tu veux retenir l’essentiel :
- Tu pilotes la charge avec le WIP (et ses limites)
- Tu pilotes la rapidité perçue avec le Lead time
- Tu pilotes l’exécution avec le Cycle time
- Tu pilotes la capacité de sortie avec le Throughput
- Tu pilotes la prédictibilité avec le SLE
- Tu diagnostiques le système avec le CFD (et l’âge du WIP)
Et surtout : tu n’améliores pas ce que tu caches. Un board Kanban n’est pas une déco. C’est une vitrine du flux.
Bonus : un exemple concret (ultra courant) en Kanban IT
Tu as une équipe Run + petits projets.
- Le board se remplit.
- Les tickets “In Progress” montent à 15.
- Les devs jurent qu’ils bossent.
- Le client jure qu’il attend.
Tu regardes :
- CFD : “Review” s’épaissit → goulot.
- Aging WIP : 3 tickets bloqués depuis 12 jours.
- Lead time : médiane qui monte.
- Throughput : stable mais fait surtout des petits items.
Action Kanban typique :
- WIP limit plus strict sur “In Progress” et “Review”
- Politique : “si Review est plein, on arrête de démarrer”
- Classe Expedite limitée à 1 item max
- SLE communiqué : “85% des standard en ≤ 8 jours”
- Revue hebdo des items qui dépassent le SLE (aging)
Résultat : moins de “commencés”, plus de “terminés”. Et un client qui arrête de relancer toutes les 4 heures.
