Il y a un moment, dans presque toutes les équipes, où quelqu’un prononce cette phrase :
“Ok… mais si 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.… je vais être bloqué, non ?
Et si je suis bloqué… je vais attendre ?”
Et là, tu vois deux choses dans les yeux :
- la peur très rationnelle de perdre du temps
- la peur beaucoup moins avouable de paraître inutile
C’est exactement pour ça que les limites 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. (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.) sont le levier le plus rentable… et aussi celui qui déclenche le plus de réactions “humaines” (défense, anxiété, contournement).
Dans cet article, on va traiter le sujet sans langue de bois : oui, tu vas parfois “attendre”.
Mais si tu mets ça en place correctement, tu vas surtout arrêter de perdre du temps sans t’en rendre compte.
Et tu vas le faire sans transformer ton tableau en camp militaire.
Pourquoi le WIP est un multiplicateur de souffrance (et pas de productivité)
Quand tu n’as pas de 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., tu as l’impression d’être efficace parce que :
- tu démarres plein de trucs
- tu “avances” partout un peu
- tu réponds vite à tout le monde
Mais ton système, lui, fait autre chose :
- il empile du travail
- il crée de l’attente entre les étapes
- il augmente le temps pour finir quoi que ce soit
Le Kanban University résume bien l’esprit : 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 sont une politique explicite (un “enabling constraint”) qui sert à installer un système tiré (pull) et à développer des comportements de focus et de coopération.
Et ce n’est pas qu’une opinion “agile”. C’est aussi un effet mécanique de files d’attente.
La loi la plus simple (et la plus impitoyable) : Little
Si ton équipe a un débitThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. relativement stable, tu peux relier trois grandeurs :
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”.
Donc, à débitThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. donné :
➡️ si tu augmentes 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 augmentes mécaniquement 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”..
C’est précisément ce que formalise Little’s LawLittle’s LawUne relation simple (à condition que le système soit relativement stable) : (voir le document “Little’s Law” de J.D.C. Little, utilisé en cours d’ingénierie/queueing).
Exemple “qui pique”, mais qui parle
- Ton équipe sort 5 items/semaine (throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine.).
- Tu as 20 items “en cours quelque part” (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. global).
- 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 ≈ 20 / 5 = 4 semaines
Tu ne livrais pas “lentement”.
Tu livrais à la vitesse de ton 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..
Alors pourquoi ça crispe autant : “je vais être bloqué ?”
Parce qu’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”. crée volontairement un inconfort. Et cet inconfort révèle tout ce que tu cachais sous le tapis :
- dépendances
- goulots
- validations tardives
- relectures en attente
- “je finis après”
- multitâche
- sur-engagement chronique
David J. Anderson parle explicitement du 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 d’un “stressor” (stresseur) : un mécanisme qui met le système sous tension pour rendre les problèmes visibles et traitables.
Et ça, humainement, ça fait réagir.
Les 2 peurs derrière “je vais attendre”
Peur n°1 : “Je vais perdre du temps”
Ce que ton cerveau entend, c’est : “On va m’empêcher d’être productif.”
Sauf que “être productif” est souvent confondu avec “être occupé”.
Et le multitâche, lui, a un coût cognitif réel : basculer entre tâches impose des coûts de reconfiguration mentale, mesurés expérimentalement dans la littérature en psychologie cognitive (task switching).
Donc 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”. ne “vole” pas du temps : il réduit le temps perdu en fragmentation.
Peur n°2 : “Je vais paraître inutile”
Celle-là est plus sournoise, surtout dans les cultures où :
- l’héroïsme est valorisé
- “être busy” est un statut
- l’attente est vécue comme une faute
C’est pour ça que, si tu ne changes que le tableau, tu obtiens :
- contournements (“je le mets en ‘en cours’ mais je n’y touche pas”)
- micro-optimisation individuelle
- cynisme (“c’est un truc de coach”)
Le bon 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”. est un contrat social, pas un chiffre.
La phrase qui désamorce 80% des tensions
Quand quelqu’un dit :
“Mais si je suis bloqué, je fais quoi ?”
La réponse la plus saine est :
“Tu ne ‘fais pas rien’. Tu aides le système à finir.”
Et ça, ça se décline en actions très concrètes (pas des posters LinkedIn).
Que faire quand tu “attends” : la checklist anti-panique
Voici ce qu’une équipe mature met dans ses politiques explicites quand un item est bloqué et 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. est plein.
1) D’abord : débloquer, pas démarrer
- ping actif (pas “relance dans 3 jours”)
- clarification immédiate
- pairing 15 min pour lever une ambiguïté
- escalade si dépendance externe
Dans Microsoft Azure DevOps, la logique est la même : quand une colonne dépasse la limite, c’est un signal visuel pour traiter le problème, pas pour “faire comme si”.
2) “Swarm” : terminer ensemble
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 plein, tu bascules d’une logique “chacun son ticket” à :
- on termine le plus prioritaire
- à plusieurs
- maintenant
C’est souvent le changement culturel le plus rentable.
3) Renforcer la qualité là où ça bloque
Si 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…). est souvent :
- en review
- en test
- en validation
Alors tu investis dans :
- Definition of DoneDefinition of Doneconditions explicites pour considérer un item terminé.Ex : tests passés, PR mergée, doc mise à jour, déployé, validé… plus stricte
- automatisation tests
- checklists de review
- critères d’entrée/sortie clairs
4) Faire du travail “non-feature” qui réduit le WIP futur
Oui, tu peux profiter d’un “creux” pour :
- réduire dette technique qui casse le flow
- améliorer observabilité
- automatiser un déploiement
- documenter un runbook support
Mais attention : ça ne doit pas devenir un prétexte pour ignorer le goulot principal.
Le piège classique : confondre “attente” et “pause”
Il y a deux types d’attente :
Attente stérile
- personne ne sait quoi faire
- personne ne sait qui relancer
- le ticket est bloqué mais invisible
- on démarre autre chose “pour ne pas perdre de temps”
➡️ Résultat : 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. qui gonfle, 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 explose.
Attente utile
- 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…). explicite (tag “Blocked”, raison, propriétaire du déblocage)
- politique claire : “si bloqué > 24h, on escalate”
- swarm / aide transversale
- apprentissage : on réduit la probabilité du 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…).
C’est pour ça 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. sans rendre le “blocked” explicite est une demi-mesure.
“Ok, mais est-ce que chaque colonne doit avoir une limite ?”
C’est une excellente question, et la réponse est : pas forcément.
ProKanban explique que :
- un chiffre sur une colonne n’est pas “la gestion du 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 peux gérer 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. par des politiques et des habitudes d’équipe
- et toutes les colonnes n’ont pas besoin d’une limite stricte selon le contexte
Traduction terrain :
- Mets des limites là où ça sature (dev, review, test, validation…)
- Mets une limite globale si nécessaire (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 de l’équipe)
- Et surtout : définis quoi faire quand c’est plein
Le vrai ROI du WIP limit : moins de “travail invisible”
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”. fait remonter 3 coûts cachés :
- Le coût du contexte : tu payes la bascule mentale, les reprises, les oublis.
- Le coût de file d’attente : plus tu empiles, plus tu attends (Little).
- Le coût de délai business : finir plus tard, c’est souvent coûter plus cher (priorités qui vieillissent, incidents qui durent, valeur qui arrive tard).
Sur ce point, les travaux popularisés par Donald Reinertsen insistent sur les effets systémiques d’une utilisation trop élevée et des files d’attente sur le flow (et donc le coût global).
Comment annoncer les WIP limits sans déclencher la révolte
Script simple (et efficace)
“On ne met pas 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”. pour ralentir les gens.
On le met pour réduire le temps entre ‘on commence’ et ‘c’est fini’.
Et quand c’est plein, on ne ‘bloque’ pas les personnes : on bloque les démarrages pour finir ce qui est déjà entamé.”
Ensuite, tu poses 3 règles.
Les 3 règles qui rendent ça humain
Règle 1 — Un WIP limit n’est pas une punition, c’est un signal
Si on dépasse :
- on ne cherche pas un coupable
- on cherche le goulot
Règle 2 — “Plein” = on aide, on termine, on débloque
Pas de nouvel item “juste pour s’occuper”.
Règle 3 — On ajuste comme une expérience
- on part petit
- on mesure cycle/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”.
- on adapte le chiffre
Même Atlassian présente 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 comme un mécanisme pour favoriser la complétion et réduire la surcharge, avec des objectifs liés au flux et à la qualité.
Le mode d’emploi concret pour démarrer (sans casser l’équipe)
- Choisis 1 endroit où ça bloque (souvent review/test/validation).
- Mets une limite légèrement sous la douleur actuelle (ex : “au lieu de 12 en review, on met 6”).
- Ajoute une politique visible :
- “Si Review est plein : on swarm sur review”
- “Si un ticket est bloqué : raison + owner + délai max avant escalade”
- Observe 2 semaines, puis ajuste.
Tu verras un phénomène magique :
- moins d’items “presque finis”
- plus de “Done”
- et surtout… moins de stress, parce que le système devient prévisible
Et si quelqu’un insiste : “donc oui, je vais attendre”
Réponds franchement :
Oui. Parfois.
Mais c’est comme une salle d’attente chez le médecin :
- si tu fais entrer tout le monde dans le cabinet en même temps, personne n’est soigné plus vite
- si tu limites, tu soignes mieux et plus vite
L’objectif n’est pas “zéro attente”.
L’objectif, c’est zéro attente inutile.
Conclusion : le WIP limit ne te bloque pas, il te protège
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”., c’est un garde-fou contre le réflexe le plus naturel en organisation :
“On va commencer encore un truc, comme ça on aura l’impression d’avancer.”
Sauf que “avancer” n’est pas “finir”.
Et tant que tu n’as pas rendu cette distinction visible, tu peux optimiser tout le reste… tu resteras une organisation qui court partout et livre tard.
Si tu veux un levier qui améliore à la fois :
- la vitesse réelle
- la qualité
- la sérénité
- la prévisibilité
… tu viens de le trouver.
