Dans beaucoup d’organisations, la productivité se mesure au taux d’occupation des équipes. Si tout le monde est occupé, le projet avance. Si quelqu’un attend, c’est du gaspillage. Cette logique, héritée de la production industrielle de masse, s’applique mal aux projets où la création de valeur dépend davantage de la rapidité de livraison que du volume de travail en cours.
Le piège de l’occupation maximale
Considérons une équipe qui doit livrer trois livrables nécessitant chacun un mois de travail, avec deux approches possibles. Dans la première, l’équipe travaille sur les trois livrables simultanément: après trois mois, les trois sont prêts. Dans la seconde, l’équipe se concentre sur un seul livrable à la fois: le premier est livré après un mois, le deuxième après deux mois, le troisième après trois mois. La durée totale est identique, mais la seconde approche livre de la valeur dès le premier mois.
Cette différence a des conséquences financières concrètes. Un livrable en production génère des revenus, réduit des coûts ou satisfait des utilisateurs. Plus il est livré tôt, plus la période pendant laquelle il produit de la valeur est longue. C’est le principe du cost of delay (coût du retard): chaque jour de retard dans la livraison d’un résultat utile représente une opportunité perdue.
La loi de Little: une formule, trois leviers
La relation entre travail en cours et délai de livraison n’est pas une intuition: c’est un théorème mathématique. La loi de Little, formulée par John Little en 1961, établit que le temps moyen de traversée d’un système (lead time) est égal au nombre d’éléments en cours de traitement (WIP, Work In Progress) divisé par le débit de sortie (throughput).
En termes concrets: si une équipe a 10 tâches en cours et en termine 2 par semaine, le lead time moyen est de 5 semaines. Réduire le WIP à 4 tâches, à débit constant, ramène le lead time à 2 semaines. Cette relation est mécanique et s’applique à tout système stable, qu’il s’agisse d’une file d’attente dans un supermarché ou d’un portefeuille de projets.
La méthode Kanban exploite directement cette loi en imposant des limites explicites au nombre de tâches autorisées à chaque étape du flux de travail. Ces limites WIP ne sont pas un objectif en soi: elles sont le mécanisme par lequel le système devient prédictible.
Pourquoi le multitâche coûte plus qu’il ne rapporte
L’argument le plus fréquent contre la limitation du WIP est le risque de sous-utilisation des ressources. Si un membre de l’équipe est bloqué sur une tâche et ne peut pas en prendre une autre, il reste inactif. Cette inactivité visible inquiète les managers habitués à mesurer la productivité par l’occupation.
Pourtant, le multitâche a un coût réel que l’on sous-estime systématiquement. Chaque changement de contexte (context switching) nécessite un temps de réorientation cognitive qui peut représenter 15 à 25% du temps de travail. Plus une personne jongle entre des tâches, plus elle commet d’erreurs et plus chaque tâche individuelle prend du temps à compléter.
Même en supposant que la limitation du WIP entraîne 25% de temps d’inactivité (une hypothèse volontairement pessimiste), l’approche séquentielle reste financièrement plus avantageuse grâce à la livraison anticipée de valeur. L’inactivité apparente d’une ressource coûte moins cher que le retard systématique dans la livraison de résultats utiles.
Appliquer les limites WIP hors du développement logiciel
Les limites WIP sont souvent associées aux équipes de développement logiciel, mais le principe s’applique à tout contexte où plusieurs initiatives sont menées en parallèle.
Un bureau de projets (PMO) qui gère quinze projets simultanément avec les mêmes ressources partagées observe les mêmes effets qu’une équipe sans limite WIP: des délais imprévisibles, des projets qui progressent par à-coups et une incapacité chronique à terminer quoi que ce soit dans les temps. Réduire le nombre de projets actifs, même si cela signifie reporter certaines initiatives, accélère mécaniquement la livraison des projets en cours.
Dans la gestion de portefeuille, la question se pose de manière similaire. Financer dix projets en même temps avec un budget limité revient à diluer les ressources au point où aucun projet n’avance à un rythme satisfaisant. Concentrer l’investissement sur les trois ou quatre projets à plus forte valeur attendue produit des résultats concrets plus rapidement.
Les conditions pour que les limites WIP fonctionnent
Limiter le WIP n’est pas un geste technique isolé, et plusieurs conditions doivent être réunies pour que la démarche produise ses effets.
La première est la visibilité du flux de travail. Si personne ne sait combien de tâches sont réellement en cours à chaque étape, imposer des limites n’a pas de sens. Un tableau Kanban (physique ou numérique) rend le WIP visible et les dépassements immédiatement détectables.
La seconde est la capacité à traiter les blocages rapidement. Lorsqu’une tâche est bloquée et que le WIP est limité, l’équipe ne peut pas simplement prendre une autre tâche pour rester occupée: elle doit résoudre le blocage, ce qui est exactement le comportement souhaité. Les problèmes sont traités immédiatement au lieu d’être contournés.
La troisième est l’adhésion du management. Si les managers continuent de mesurer la performance par le taux d’occupation et de pousser de nouvelles tâches dans le système malgré les limites, la démarche est vouée à l’échec. La limitation du WIP exige un changement de perspective: l’objectif n’est pas que tout le monde soit occupé, mais que la valeur soit livrée le plus rapidement possible.