Il y a un moment très précis où tu sais que ton système est malade.
Ce n’est pas quand “ça va mal”.
C’est quand tout le monde a l’air occupé, que les colonnes “En cours” débordent… et que pourtant rien ne sort.
Les tickets bougent, les cartes changent de colonne, les messages Slack fusent, les “je m’en occupe” pleuvent.
Et côté client (ou métier), la sensation est toujours la même :
“On a l’impression que vous travaillez… mais on n’a jamais rien.”
C’est là que les 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 deviennent le levier le plus rentable que tu puisses actionner. Pas le plus sexy. Pas le plus “innovant”.
Mais celui qui a le meilleur retour sur investissement : moins de travail lancé = plus de travail terminé.
Le WIP, c’est ton stock. Et le stock, ça pourrit.
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. = Work In ProgressWIPle 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. = travail en cours.
Dans l’industrie, un stock trop élevé coûte cher : immobilisation, défauts cachés, gestion, retours, re-travail.
En IT, c’est la même chose, mais en plus vicieux : ton “stock” est invisible.
C’est des branches à moitié finies, des tickets “presque prêts”, des tests “à faire”, des validations “en attente”, des échanges “en cours”.
Et comme ce stock n’est pas sur palette mais dans des cerveaux, il déclenche un impôt permanent :
- context switching (recharger le sujet à chaque reprise),
- attentes (review, validation, info manquante),
- re-travail (spécification qui bouge, bug découvert tard),
- multi-départs (tout le monde commence, peu finissent),
- bouchons masqués (la QA devient l’ennemi, le métier “traîne”, etc.).
Tu payes ce stock en temps, tous les jours. Et tu t’y habitues.
“Mais si on limite le WIP, on va aller moins vite !”
C’est la réaction la plus fréquente. Et elle est logique.
Parce que 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., au début, casse une illusion :
l’illusion que “être occupé” = “avancer”.
Quand tu poses 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”., tu déclenches trois choses immédiatement visibles :
- Certaines personnes “n’ont plus rien à commencer” (donc elles semblent ralentir).
- Les blocages sautent aux yeux (donc le système a l’air pire qu’avant).
- Tu dois te coordonner (donc tu as l’impression de perdre du temps).
Et pourtant… c’est exactement ce qui te fait gagner.
Parce que ton objectif n’est pas de maximiser l’occupation.
Ton objectif est de maximiser le flux de valeur livré.
La vérité désagréable : le débit (throughput) ne dépend pas de “combien on commence”, mais de “combien on finit”
Un système de travail ressemble beaucoup plus à une route qu’à une salle de sport.
- Ajouter des voitures sur une route déjà saturée n’augmente pas la vitesse moyenne.
- Ça crée des bouchons, des freinages, des accidents, des réactions en chaîne.
En Kanban, c’est pareil.
Si tu as trop de cartes en cours, tu crées :
- des files d’attente (invisibles),
- des goulots (qui se déplacent),
- une variabilité énorme (certaines cartes sortent vite, d’autres pourrissent),
- et une prédictibilité nulle.
Limite 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. et tu réduis la taille des bouchons.
Pourquoi ça augmente la vitesse réelle : 4 effets mécaniques
1) Tu réduis les files d’attente (et c’est là que le temps se cache)
Le temps d’une carte n’est pas “le temps où quelqu’un travaille dessus”.
C’est surtout :
- le temps où elle attend,
- le temps où elle dort,
- le temps où elle est bloquée,
- le temps où elle est reprise.
Quand tu limites 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., tu réduis la longueur des files.
Donc tu réduis massivement 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”. (temps entre “demandé” et “livré”).
2) Tu forces la finition (swarming) au lieu de l’empilement
Avec 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”., une équipe apprend une nouvelle règle implicite :
“Si on ne peut pas commencer, on aide à finir.”
Et soudain, des comportements “anti-bouchons” apparaissent :
- un dev aide à tester,
- quelqu’un fait la review tout de suite,
- on pair-programme sur la tâche la plus proche de “Done”,
- on débloque une dépendance au lieu d’ouvrir un nouveau ticket.
Au début, ça donne l’impression d’être “moins efficace” (parce que ce n’est pas “son job”).
Mais en réalité, c’est exactement ce qui accélère la livraison.
3) Tu fais remonter les vrais goulots
Quand tout est “en cours”, tu ne sais pas où est le frein.
Quand 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. est limité, le frein devient évident :
- “On sature en validation métier”
- “On manque de capacité de test”
- “Les reviews prennent 48h”
- “On attend toujours des infos du support N2”
- “Le déploiement est un rituel pénible donc on batch”
Sans 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”., ces problèmes sont dilués dans le bruit.
Avec, ils deviennent impossibles à ignorer. Et donc enfin solvables.
4) Tu stabilises le système (moins de variabilité, plus de prévisibilité)
Un flux stable n’est pas seulement “plus rapide”.
Il est surtout prévisible.
C’est là que 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.-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”. devient rentable : tu passes de
- “ça sort quand ça sort”
à - “on peut annoncer une date avec confiance”.
Exemple concret : l’équipe qui “tourne à fond” mais livre lentement
Imagine une équipe de 6 personnes.
Sans limite :
- 18 cartes en cours (3 par personne en moyenne),
- beaucoup de “j’attends une réponse”, “je reviens dessus”, “presque fini”.
Résultat vécu :
- tout le monde est occupé,
- mais la plupart des cartes mettent 2 à 6 semaines à sortir,
- les urgences passent devant, donc tout le reste vieillit.
On met une limite :
- 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. total = 6 (une carte max par personne)
- ou encore mieux : limite par colonne (ex : Dev=4, Review=3, Test=2)
Semaine 1 :
- sensation de chaos (“on ne peut plus rien commencer !”)
- impression de ralentissement (“je suis bloqué car la colonne est pleine”)
Semaine 3 :
- la colonne Review cesse d’être un cimetière,
- les tests se font au fil de l’eau,
- les cartes ne vieillissent plus,
- les urgences sont traitées sans détruire le reste.
La “vitesse” ressentie au clavier peut sembler identique.
Mais la vitesse réelle de sortie (cartes terminées / semaine) et la fiabilité explosent.
Le point clé : un WIP limit n’est pas une contrainte. C’est une politique d’équipe.
Si tu poses un chiffre comme un panneau “interdit”, tu vas créer de la frustration.
Si tu poses 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”. comme une règle de fonctionnement collectif, tu changes la culture :
- Quand c’est plein, on finit avant de commencer.
- Quand c’est bloqué, on traite le blocageBlocker / Blockedun item “bloqué” ne peut pas avancer pour une raison externe ou interne (dépendance, attente de validation, accès, incident, manque d’info…). avant d’ajouter du travail.
- Quand on hésite, on optimise le flux, pas l’occupation.
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.-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”. n’est pas là pour “empêcher”.
Il est là pour forcer les bonnes conversations.
Comment le mettre en place sans te tirer une balle dans le pied
1) Commence là où ça s’accumule
Ne limite pas tout d’un coup.
Regarde où ça gonfle :
- Review ?
- Test ?
- Validation ?
- “Prêt à déployer” ?
Mets une limite à l’endroit où ça bloque, pas là où ça arrange.
2) Choisis une limite “un peu inconfortable”
Si c’est confortable, ça ne changera rien.
Tu veux un chiffre qui déclenche parfois :
“Ok, on ne commence pas. On aide à finir.”
3) Définis la règle “quand c’est plein, on fait quoi ?”
Sinon, tu obtiens juste : “c’est plein” → “bah… j’attends”.
Exemples de politiques simples :
- aider à tester / reviewer,
- débloquer les dépendances,
- découper une carte trop grosse,
- réduire le scope,
- terminer une carte la plus proche de Done.
4) Gère l’exception “urgent” explicitement
Sinon, l’urgence détruit tout.
Tu peux prévoir :
- une classe de service ExpediteExpediteclasse de service qui court-circuite (presque) tout. (très limitée),
- une règle “1 expediteExpediteclasse de service qui court-circuite (presque) tout. max”,
- ou un couloir dédié mais ultra contraint.
Les anti-patterns à éviter (ceux qui font croire que “les WIP limits ne marchent pas”)
- On augmente la limite dès que ça coince
→ tu viens de supprimer l’alarme incendie parce qu’elle sonnait. - On garde des cartes énormes
→ une carte de 10 jours monopolise ta limite et fausse tout. Découpe. - On confond “bloqué” et “en cours”
→ un ticket bloqué doit être visible, traité, ou sorti du flux. - On mesure “occupation” au lieu de “sorties”
→ regarde 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”., âge des cartes, taux de blocageBlocker / Blockedun item “bloqué” ne peut pas avancer pour une raison externe ou interne (dépendance, attente de validation, accès, incident, manque d’info…)..
La conclusion que personne n’aime entendre (mais tout le monde finit par constater)
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., c’est accepter un truc contre-intuitif :
Tu vas sembler ralentir… parce que tu arrêtes de tricher.
Tu arrêtes d’avoir 25 sujets entamés qui donnent l’illusion de progrès.
Et tu construis un système qui termine, régulièrement, proprement, prévisiblement.
C’est pour ça que c’est le levier le plus rentable :
- peu coûteux à mettre en place (un chiffre + une règle),
- énorme impact sur la fluidité,
- améliore vitesse et qualité,
- réduit le stress (moins de “tout est urgent”),
- rend la livraison fiable (et ça, ça vaut de l’or).
Si tu dois améliorer un flux sans budget, sans recrutement, sans refonte…
commence par là.
