La plupart des équipes projet souffrent du même mal: trop de choses en cours, pas assez de choses terminées. Les listes de tâches s’allongent, les délais glissent et chacun a le sentiment de travailler beaucoup sans que les livrables avancent. Le Kanban, méthode de gestion du flux née dans les usines Toyota et adaptée au travail intellectuel par David Anderson, offre un diagnostic précis de ce problème et un remède étonnamment simple: limiter le travail en cours.
Le paradoxe de la surcharge parallèle
L’intuition managériale courante veut qu’une personne “occupée” soit une personne productive. Si un membre de l’équipe termine une tâche et qu’aucune n’est immédiatement disponible en aval, on lui en assigne une nouvelle pour éviter qu’il ne “perde du temps”. Cette logique, appliquée systématiquement, conduit à une multiplication du travail en cours qui produit l’effet inverse de celui recherché.
La loi de Little, formulée en 1961 par le mathématicien John D.C. Little, établit une relation directe entre le nombre d’éléments dans un système, leur temps de traversée et le débit de sortie. En termes concrets: si une équipe de cinq personnes travaille simultanément sur vingt tâches, chaque tâche mettra en moyenne quatre fois plus de temps à être terminée que si l’équipe n’en traitait que cinq.
Ce phénomène s’explique par le coût du changement de contexte (context switching). Chaque interruption pour passer d’une tâche à une autre génère un temps de réamorçage cognitif que plusieurs études en psychologie du travail estiment entre 15 et 25 minutes. Sur une journée, un coordinateur qui jongle entre quatre dossiers peut perdre deux heures uniquement en transitions mentales.
Comment la limite WIP transforme le flux
La limite WIP (Work In Progress, ou travail en cours) est le mécanisme central du Kanban. Elle consiste à plafonner le nombre de tâches autorisées dans chaque étape du processus. Quand la limite est atteinte, aucun nouveau travail ne peut entrer dans cette étape tant qu’un élément n’en est pas sorti.
L’effet immédiat est contre-intuitif: des personnes se retrouvent momentanément sans tâche assignée. Plutôt que de démarrer du nouveau travail, elles sont incitées à aider les collègues en aval pour débloquer le flux. Un analyste en attente relit un livrable bloqué en validation. Un membre de l’équipe disponible aide à résoudre un blocage technique en aval. La limite WIP crée une pression naturelle vers la collaboration et la résolution des obstacles.
L’effet à moyen terme est une réduction significative du temps de cycle, c’est-à-dire la durée entre le démarrage et la fin d’une tâche. Les équipes qui adoptent des limites WIP rapportent généralement des réductions de l’ordre de 30 à 50% de leur temps de cycle dans les premières semaines, sans augmentation de la charge de travail.
Mettre en place des limites WIP dans son équipe
La mise en place de limites WIP commence par la visualisation du travail actuel sur un tableau Kanban. Ce tableau représente les étapes du processus en colonnes (par exemple “Backlog”, “Analyse”, “En cours”, “Revue”, “Terminé”) et chaque tâche par une carte qui se déplace de gauche à droite.
Pour définir les limites initiales, une règle simple fonctionne dans la majorité des cas: limiter chaque colonne à un nombre légèrement inférieur au nombre de personnes qui travaillent sur cette étape. Si trois personnes gèrent la phase d’analyse, fixer la limite WIP à deux ou trois. L’objectif n’est pas de trouver la limite parfaite du premier coup mais de rendre visible le moment où l’équipe commence à se surcharger.
Les premières semaines sont inconfortables. Les réflexes organisationnels poussent à contourner les limites (“cette tâche est urgente, on fait une exception”). Chaque exception érode la discipline et réduit les bénéfices du système. La rigueur dans l’application des limites distingue les équipes qui tirent un bénéfice durable du Kanban de celles qui reviennent progressivement à leurs anciennes pratiques.
Au-delà du WIP: piloter par les données du flux
Les limites WIP ne sont qu’un point d’entrée vers une gestion par le flux. Le Kanban propose plusieurs métriques complémentaires pour piloter l’amélioration continue: le temps de cycle mesure la durée de traitement d’un élément, le débit (throughput) compte le nombre d’éléments terminés par unité de temps et le diagramme de flux cumulé (cumulative flow diagram) représente graphiquement l’évolution du travail dans chaque étape.
Ces métriques ont un avantage décisif sur les estimations traditionnelles: elles se fondent sur des données réelles, pas sur des prévisions. Un chef de projet qui dispose de quatre semaines de données de temps de cycle peut fournir des prévisions de livraison bien plus fiables qu’avec n’importe quelle méthode d’estimation a priori.
Une application naturelle au portefeuille de projets
Le principe de limitation du travail en cours s’applique aussi au niveau du portefeuille de projets. Les organisations qui maintiennent dix projets actifs simultanément avec des ressources calibrées pour cinq projets observent exactement les mêmes symptômes qu’une équipe surchargée: des délais qui explosent, des livrables qui stagnent et un sentiment général d’inefficacité.
Un tableau Kanban de portefeuille, avec des limites WIP par catégorie de projet (stratégique, opérationnel, réglementaire), force les décisions de priorisation que les comités de pilotage repoussent indéfiniment. Quand la limite est atteinte, il faut terminer ou abandonner un projet avant d’en lancer un nouveau. Cette contrainte, aussi simple qu’elle soit, résout un problème que des années de réunions de gouvernance n’ont pas réussi à traiter.