[{"data":1,"prerenderedAt":498},["ShallowReactive",2],{"search-api":-1,"listing-tag-WIP-page-1":3},[4],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"id":11,"date":12,"listed":13,"nocomments":7,"hidden":7,"categories":14,"tags":15,"--cover":20,"readingTime":21,"body":26,"_type":492,"_id":493,"_source":494,"_file":495,"_stem":496,"_extension":497},"/fr/pratiques-agiles/reduire-work-in-progress-velocite","pratiques-agiles",false,"","Limiter le Work In Progress : le levier le plus sous-estimé","La loi de Little appliquée à l'engineering : réduire le WIP est plus efficace que d'accélérer les développeurs. La démonstration et le protocole de mise en œuvre.",32,"2026-03-18",true,[6],[16,17,18,19],"Work In Progress","WIP","Kanban","Flow","covers/articles/reduire-work-in-progress.jpg",{"text":22,"minutes":23,"time":24,"words":25},"9 min read",8.105,486300,1621,{"type":27,"children":28,"toc":483},"root",[29,37,43,48,53,58,63,67,74,79,88,93,98,115,132,149,154,157,163,168,178,188,198,224,237,240,246,256,266,271,291,301,311,321,324,330,340,358,368,371,377,382,387,392,395,401,416,429,442,455,468,471],{"type":30,"tag":31,"props":32,"children":34},"element","h1",{"id":33},"limiter-le-work-in-progress-le-levier-le-plus-sous-estimé",[35],{"type":36,"value":9},"text",{"type":30,"tag":38,"props":39,"children":40},"p",{},[41],{"type":36,"value":42},"J'accompagnais une équipe produit de 8 développeurs chez un client dans le secteur financier. Ils me demandaient comment livrer plus vite. Je leur ai demandé de compter le nombre de stories \"In Progress\" sur leur board.",{"type":30,"tag":38,"props":44,"children":45},{},[46],{"type":36,"value":47},"Il y en avait 22.",{"type":30,"tag":38,"props":49,"children":50},{},[51],{"type":36,"value":52},"22 stories pour 8 développeurs. Chaque développeur avait en moyenne 2,75 sujets en cours simultanément. Certains jonglaient entre 4 contextes différents dans la même journée.",{"type":30,"tag":38,"props":54,"children":55},{},[56],{"type":36,"value":57},"J'ai posé la question suivante : \"Quelle est la dernière fois qu'une story est allée de 'To Do' à 'Done' en moins de 3 jours ?\" Silence. L'un d'eux a vérifié Jira. La réponse était : 6 semaines auparavant.",{"type":30,"tag":38,"props":59,"children":60},{},[61],{"type":36,"value":62},"La solution que je leur ai proposée n'était pas d'embaucher, ni de changer de framework, ni d'adopter une nouvelle méthodologie. C'était de réduire le nombre de choses en cours simultanément. Ça semblait trop simple. C'était la bonne réponse.",{"type":30,"tag":64,"props":65,"children":66},"hr",{},[],{"type":30,"tag":68,"props":69,"children":71},"h2",{"id":70},"la-loi-de-little-la-démonstration-mathématique",[72],{"type":36,"value":73},"La loi de Little : la démonstration mathématique",{"type":30,"tag":38,"props":75,"children":76},{},[77],{"type":36,"value":78},"La loi de Little, formulée par le mathématicien John Dutton Converse Little en 1961, s'applique à tout système de flux (file d'attente bancaire, réseau logistique, ou équipe de développement logiciel).",{"type":30,"tag":38,"props":80,"children":81},{},[82],{"type":30,"tag":83,"props":84,"children":85},"strong",{},[86],{"type":36,"value":87},"Lead Time = Work In Progress / Throughput",{"type":30,"tag":38,"props":89,"children":90},{},[91],{"type":36,"value":92},"Traduction pour l'engineering : si votre équipe livre 10 stories par semaine (throughput) et a 30 stories en cours simultanément (WIP), le lead time moyen est de 3 semaines. Pour réduire le lead time à 1 semaine sans changer le throughput : réduire le WIP à 10 stories.",{"type":30,"tag":38,"props":94,"children":95},{},[96],{"type":36,"value":97},"La démonstration chiffrée est implacable.",{"type":30,"tag":38,"props":99,"children":100},{},[101,106,108,113],{"type":30,"tag":83,"props":102,"children":103},{},[104],{"type":36,"value":105},"Scénario A : WIP illimité",{"type":36,"value":107}," : équipe de 5 développeurs, 15 stories en cours (3 par développeur), throughput de 10 stories par semaine. Lead Time moyen : 15 / 10 = ",{"type":30,"tag":83,"props":109,"children":110},{},[111],{"type":36,"value":112},"1,5 semaine",{"type":36,"value":114},".",{"type":30,"tag":38,"props":116,"children":117},{},[118,123,125,130],{"type":30,"tag":83,"props":119,"children":120},{},[121],{"type":36,"value":122},"Scénario B : WIP limité à 8",{"type":36,"value":124}," : même équipe, même throughput, 8 stories en cours. Lead Time moyen : 8 / 10 = ",{"type":30,"tag":83,"props":126,"children":127},{},[128],{"type":36,"value":129},"0,8 semaine",{"type":36,"value":131}," (−47%).",{"type":30,"tag":38,"props":133,"children":134},{},[135,140,142,147],{"type":30,"tag":83,"props":136,"children":137},{},[138],{"type":36,"value":139},"Scénario C : WIP limité à 5",{"type":36,"value":141}," : 5 stories en cours (1 par développeur). Lead Time moyen : 5 / 10 = ",{"type":30,"tag":83,"props":143,"children":144},{},[145],{"type":36,"value":146},"0,5 semaine",{"type":36,"value":148}," (−67%).",{"type":30,"tag":38,"props":150,"children":151},{},[152],{"type":36,"value":153},"En réduisant le WIP de 15 à 5, le lead time est divisé par 3, sans changer une ligne de code, sans recruter, sans changer de framework. C'est contre-intuitif dans une culture qui valorise l'occupation maximale. C'est pourtant ce que la théorie des contraintes de Goldratt et les principes Kanban enseignent depuis des décennies.",{"type":30,"tag":64,"props":155,"children":156},{},[],{"type":30,"tag":68,"props":158,"children":160},{"id":159},"pourquoi-le-wip-augmente-naturellement",[161],{"type":36,"value":162},"Pourquoi le WIP augmente naturellement",{"type":30,"tag":38,"props":164,"children":165},{},[166],{"type":36,"value":167},"Dans la plupart des équipes, le WIP augmente sans décision consciente. Les mécanismes sont structurels.",{"type":30,"tag":38,"props":169,"children":170},{},[171,176],{"type":30,"tag":83,"props":172,"children":173},{},[174],{"type":36,"value":175},"Le multitâche comme norme.",{"type":36,"value":177}," Un développeur bloqué sur une story en attend le feedback, démarre une deuxième story, est interrompu pour une troisième urgence. Sans règle explicite, 3 stories en parallèle par développeur devient la norme, et personne ne la remet en question.",{"type":30,"tag":38,"props":179,"children":180},{},[181,186],{"type":30,"tag":83,"props":182,"children":183},{},[184],{"type":36,"value":185},"La peur du \"slack\".",{"type":36,"value":187}," Un développeur qui n'a rien en cours est perçu comme improductif. Résultat : chacun s'assigne une nouvelle story plutôt que d'aider un collègue à terminer. Le système optimise l'occupation individuelle au détriment du flux collectif.",{"type":30,"tag":38,"props":189,"children":190},{},[191,196],{"type":30,"tag":83,"props":192,"children":193},{},[194],{"type":36,"value":195},"Les dépendances non résolues.",{"type":36,"value":197}," Une story en attente d'une décision produit, d'une clarification métier, ou d'une PR de review contribue au WIP sans avancer. Elle bloque la colonne sans produire de valeur.",{"type":30,"tag":38,"props":199,"children":200},{},[201,214,216,222],{"type":30,"tag":83,"props":202,"children":203},{},[204,206,213],{"type":36,"value":205},"Le ",{"type":30,"tag":207,"props":208,"children":210},"a",{"href":209},"/fr/pratiques-agiles/anti-patterns-backlog",[211],{"type":36,"value":212},"backlog infini",{"type":36,"value":114},{"type":36,"value":215}," Si le backlog a 200 stories priorisées et qu'il n'y a pas de limite explicite, l'équipe accepte plus qu'elle ne peut faire. C'est le ",{"type":30,"tag":207,"props":217,"children":219},{"href":218},"/fr/pratiques-agiles/sprint-planning-efficace",[220],{"type":36,"value":221},"sprint planning",{"type":36,"value":223}," qui génère du WIP excessif.",{"type":30,"tag":225,"props":226,"children":231},"cta",{"cta":227,"href":228,"title":229,"type":230},"Réserver mon diagnostic gratuit →","https://app.kamanga.fr/forms/discovery-call","Votre lead time dépasse 3 semaines et vous cherchez les bons leviers pour le réduire ?","call",[232],{"type":30,"tag":38,"props":233,"children":234},{},[235],{"type":36,"value":236},"Identifier les bonnes limites de WIP pour votre équipe nécessite une analyse du flux actuel. En 30 minutes, je calcule votre lead time théorique, j'identifie les goulots d'étranglement, et je définis avec vous les limites de WIP adaptées à votre contexte.",{"type":30,"tag":64,"props":238,"children":239},{},[],{"type":30,"tag":68,"props":241,"children":243},{"id":242},"le-protocole-dimplémentation-en-5-étapes",[244],{"type":36,"value":245},"Le protocole d'implémentation en 5 étapes",{"type":30,"tag":38,"props":247,"children":248},{},[249,254],{"type":30,"tag":83,"props":250,"children":251},{},[252],{"type":36,"value":253},"Étape 1 : Mesurer le WIP actuel.",{"type":36,"value":255}," Avant d'imposer une limite, mesurer l'état réel. Pendant 2 semaines, poser ces questions en daily standup : combien de stories chaque développeur a-t-il en cours aujourd'hui ? Combien de stories sont en cours depuis plus de 5 jours ? Quel est le nombre total de stories \"In Progress\" sur le board ? Calculer la moyenne. C'est le WIP de départ.",{"type":30,"tag":38,"props":257,"children":258},{},[259,264],{"type":30,"tag":83,"props":260,"children":261},{},[262],{"type":36,"value":263},"Étape 2 : Définir les limites initiales.",{"type":36,"value":265}," Règle pratique de départ : limite WIP = nombre de développeurs × 1,5. Pour une équipe de 6 : limite WIP = 9. C'est plus restrictif que l'état naturel (souvent 2 à 3 fois le nombre de développeurs) mais pas encore au niveau optimal.",{"type":30,"tag":38,"props":267,"children":268},{},[269],{"type":36,"value":270},"La limite s'applique par colonne du board Kanban, pas au total :",{"type":30,"tag":272,"props":273,"children":274},"ul",{},[275,281,286],{"type":30,"tag":276,"props":277,"children":278},"li",{},[279],{"type":36,"value":280},"\"In Progress\" : limite = N développeurs",{"type":30,"tag":276,"props":282,"children":283},{},[284],{"type":36,"value":285},"\"In Review\" : limite = N/2",{"type":30,"tag":276,"props":287,"children":288},{},[289],{"type":36,"value":290},"\"In Testing\" : limite = N/3",{"type":30,"tag":38,"props":292,"children":293},{},[294,299],{"type":30,"tag":83,"props":295,"children":296},{},[297],{"type":36,"value":298},"Étape 3 : Rendre la limite visible et automatique.",{"type":36,"value":300}," Sur Jira, configurer le \"Work In Progress Limit\" sur chaque colonne du board. Jira affiche une alerte visuelle (colonne en rouge) quand la limite est atteinte. La règle doit être visible passivement, pas nécessiter une vérification active.",{"type":30,"tag":38,"props":302,"children":303},{},[304,309],{"type":30,"tag":83,"props":305,"children":306},{},[307],{"type":36,"value":308},"Étape 4 : Créer la règle \"finir avant de commencer\".",{"type":36,"value":310}," Quand la limite WIP est atteinte, avant d'ouvrir une nouvelle story : fermer une story en cours. Ce qui implique concrètement d'aider un collègue à débloquer sa story, de prioriser les code reviews en attente (qui bloquent les stories en review), ou de diviser une grande story bloquée en sous-stories terminables.",{"type":30,"tag":38,"props":312,"children":313},{},[314,319],{"type":30,"tag":83,"props":315,"children":316},{},[317],{"type":36,"value":318},"Étape 5 : Ajuster la limite après 4 sprints.",{"type":36,"value":320}," La limite initiale n'est pas la limite optimale. Si le board n'atteint jamais la limite : trop haute, la réduire de 20%. Si la limite bloque constamment le flux : peut-être trop basse, ou signal d'un goulot d'étranglement à résoudre autrement.",{"type":30,"tag":64,"props":322,"children":323},{},[],{"type":30,"tag":68,"props":325,"children":327},{"id":326},"les-résistances-et-comment-les-adresser",[328],{"type":36,"value":329},"Les résistances et comment les adresser",{"type":30,"tag":38,"props":331,"children":332},{},[333,338],{"type":30,"tag":83,"props":334,"children":335},{},[336],{"type":36,"value":337},"\"Je suis bloqué, je dois bien commencer autre chose.\"",{"type":36,"value":339}," Cette résistance est légitime. Ma réponse : le blocage est l'information importante, pas le contournement. Un développeur bloqué doit d'abord chercher à débloquer : escalader la dépendance, poser la question dans Slack, demander de l'aide. Ce n'est qu'après 2 heures de blocage sans perspective de résolution que commencer une autre story est acceptable. Et ce dépassement doit être visible sur le board.",{"type":30,"tag":38,"props":341,"children":342},{},[343,348,350,356],{"type":30,"tag":83,"props":344,"children":345},{},[346],{"type":36,"value":347},"\"Le business veut des estimations et une limite WIP les rend impossibles.\"",{"type":36,"value":349}," Faux. Avec une limite WIP et la loi de Little, les prédictions sont plus précises, pas moins. \"Nous avons X stories en cours et Y en backlog. Avec notre ",{"type":30,"tag":207,"props":351,"children":353},{"href":352},"/fr/pratiques-agiles/story-points-estimation-agile-alternative",[354],{"type":36,"value":355},"throughput",{"type":36,"value":357}," de 10 stories par semaine et une limite WIP de 8, la feature Z sera livrée dans cet intervalle de confiance.\" C'est plus précis qu'une vélocité en story points qui dérive avec le temps.",{"type":30,"tag":38,"props":359,"children":360},{},[361,366],{"type":30,"tag":83,"props":362,"children":363},{},[364],{"type":36,"value":365},"\"Mes développeurs vont s'ennuyer en attendant.\"",{"type":36,"value":367}," Les développeurs ne s'ennuient jamais : ils ont du backlog et de la dette technique. La vraie question est : qu'est-ce qui est plus précieux, commencer une nouvelle story ou aider à terminer les stories en cours ? La réponse est presque toujours la deuxième option. Finir une story livrée au client vaut plus que démarrer une story qui attendra 3 semaines dans la file.",{"type":30,"tag":64,"props":369,"children":370},{},[],{"type":30,"tag":68,"props":372,"children":374},{"id":373},"ce-que-ça-a-changé",[375],{"type":36,"value":376},"Ce que ça a changé",{"type":30,"tag":38,"props":378,"children":379},{},[380],{"type":36,"value":381},"Dans l'équipe de 8 développeurs mentionnée en introduction, le WIP moyen était de 22 stories simultanées. Après implémentation des limites WIP à 10 et de la règle \"finir avant de commencer\", le WIP a baissé à 9 en 6 semaines. Le lead time moyen est passé de 18 jours à 7 jours. Le nombre de stories livrées par sprint n'a pas changé, mais leur délai de livraison a été divisé par 2,5.",{"type":30,"tag":38,"props":383,"children":384},{},[385],{"type":36,"value":386},"Les métriques à suivre pour mesurer l'impact : WIP moyen hebdomadaire (la tendance doit baisser), age du WIP en jours (les stories vieilles de plus de 2 sprints sont des signaux d'alerte), et distribution du lead time par story (une distribution qui se resserre indique un flux qui se normalise).",{"type":30,"tag":38,"props":388,"children":389},{},[390],{"type":36,"value":391},"Ce n'était jamais un problème de personnes. C'était un problème de système, et le système a changé quand les règles ont changé.",{"type":30,"tag":64,"props":393,"children":394},{},[],{"type":30,"tag":68,"props":396,"children":398},{"id":397},"faq-sur-les-limites-de-wip",[399],{"type":36,"value":400},"FAQ sur les limites de WIP",{"type":30,"tag":402,"props":403,"children":404},"details",{},[405,411],{"type":30,"tag":406,"props":407,"children":408},"summary",{},[409],{"type":36,"value":410},"1. Les limites de WIP s'appliquent-elles en Scrum comme en Kanban ?",{"type":30,"tag":38,"props":412,"children":413},{},[414],{"type":36,"value":415},"Oui. En Kanban, les limites WIP sont un principe fondamental. En Scrum, elles s'appliquent au niveau du sprint board. La différence est que Scrum permet de remplir le sprint à 100% de la capacité théorique, ce qui crée du WIP élevé. En ajoutant une limite explicite (ex: max 2 stories par développeur simultanément), l'équipe Scrum bénéficie des mêmes avantages de flux que Kanban.",{"type":30,"tag":402,"props":417,"children":418},{},[419,424],{"type":30,"tag":406,"props":420,"children":421},{},[422],{"type":36,"value":423},"2. Comment gérer les urgences qui obligent à dépasser la limite WIP ?",{"type":30,"tag":38,"props":425,"children":426},{},[427],{"type":36,"value":428},"Les urgences existent et peuvent justifier de dépasser temporairement la limite. La règle : chaque dépassement est une décision consciente et visible, la colonne du board vire au rouge. Après chaque urgence, analyser en rétro : était-ce vraiment une urgence ? Aurait-on pu l'anticiper ? Les équipes qui dépassent la limite pour urgence chaque semaine ont un problème de priorisation, pas de WIP.",{"type":30,"tag":402,"props":430,"children":431},{},[432,437],{"type":30,"tag":406,"props":433,"children":434},{},[435],{"type":36,"value":436},"3. Quelle est la limite WIP optimale ?",{"type":30,"tag":38,"props":438,"children":439},{},[440],{"type":36,"value":441},"Il n'y a pas de réponse universelle : elle dépend de la taille d'équipe, de la complexité des stories, et du niveau d'interdépendances. La règle empirique est de commencer à 1,5 fois le nombre de développeurs et d'ajuster vers le bas jusqu'à trouver la valeur où le lead time se stabilise sans créer de goulot d'étranglement. En pratique, la plupart des équipes trouvent leur optimum entre 1 et 2 fois le nombre de développeurs.",{"type":30,"tag":402,"props":443,"children":444},{},[445,450],{"type":30,"tag":406,"props":446,"children":447},{},[448],{"type":36,"value":449},"4. Comment les limites WIP interagissent-elles avec les bugs urgents ?",{"type":30,"tag":38,"props":451,"children":452},{},[453],{"type":36,"value":454},"Les bugs urgents (P1/P0) sont traités comme des interruptions explicites. Un bug P1 peut entrer en cours sans respecter la limite WIP, mais il doit être la priorité absolue jusqu'à sa résolution. Le développeur qui prend un bug P1 stationne sa story en cours dans une colonne \"On Hold\". Le WIP réel ne dépasse pas la limite : il y a une substitution consciente et visible.",{"type":30,"tag":402,"props":456,"children":457},{},[458,463],{"type":30,"tag":406,"props":459,"children":460},{},[461],{"type":36,"value":462},"5. Comment convaincre le management que moins de WIP n'est pas moins de travail ?",{"type":30,"tag":38,"props":464,"children":465},{},[466],{"type":36,"value":467},"Par la démonstration chiffrée de la loi de Little. Montrer le calcul : avec un WIP de 20 et un throughput de 10 stories par semaine, le lead time est de 2 semaines. Avec un WIP de 10, le lead time est de 1 semaine. Même throughput, deux fois plus de réactivité pour le business. Le business valorise la rapidité de livraison : les limites WIP la produisent sans recruter.",{"type":30,"tag":64,"props":469,"children":470},{},[],{"type":30,"tag":225,"props":472,"children":477},{"cta":473,"href":474,"title":475,"type":476},"Télécharger le guide gratuit →","/mes-ressources","Ressource gratuite : Guide Lead Time -50% en 90 jours","resource",[478],{"type":30,"tag":38,"props":479,"children":480},{},[481],{"type":36,"value":482},"Le guide complet pour réduire votre lead time en 90 jours inclut un chapitre détaillé sur l'implémentation des limites WIP, les métriques de suivi, et les benchmarks par taille d'équipe, avec les données issues de mes accompagnements terrain.",{"title":8,"searchDepth":484,"depth":484,"links":485},2,[486,487,488,489,490,491],{"id":70,"depth":484,"text":73},{"id":159,"depth":484,"text":162},{"id":242,"depth":484,"text":245},{"id":326,"depth":484,"text":329},{"id":373,"depth":484,"text":376},{"id":397,"depth":484,"text":400},"markdown","content:fr:pratiques-agiles:reduire-work-in-progress-velocite.md","content","fr/pratiques-agiles/reduire-work-in-progress-velocite.md","fr/pratiques-agiles/reduire-work-in-progress-velocite","md",1775679738623]