Lean et Kanban: ce qu'ils apportent au chef de projet

Le Lean ne se limite pas au Kanban: limites WIP, cartographie du flux de valeur et élimination des gaspillages sont des leviers concrets pour tout chef de projet.

Beaucoup de chefs de projet utilisent un tableau Kanban sans se considérer comme des praticiens du Lean. Ils y voient un outil pratique pour visualiser le travail de l’équipe, repérer les blocages et suivre l’avancement. Ce qu’ils ne réalisent pas toujours, c’est que ce simple tableau repose sur un ensemble de principes de gestion qui vont bien au-delà de la visualisation. Le Lean, né dans les usines Toyota, précède et inspire les frameworks agiles, mais s’applique à tout type de projet indépendamment de la méthode choisie: ses concepts éclairent aussi bien un chantier de construction qu’un projet informatique ou une réorganisation interne.

Un tableau, quatre principes

Le tableau Kanban (du japonais “signal visuel”) est l’application la plus répandue d’un concept central du Lean: le flux tiré, ou pull system. Dans un système tiré, le travail n’est lancé que lorsque la capacité de le traiter existe en aval, à l’inverse d’un système poussé où le travail est assigné en fonction de ce qui est prêt en amont, sans tenir compte de la charge réelle de l’équipe.

Cette distinction parait technique, mais ses conséquences sont très concrètes. Un chef de projet qui gère son équipe en mode poussé attribue des tâches dès qu’elles sont définies, ce qui conduit inévitablement à l’accumulation de travail en cours. Les membres de l’équipe jonglent entre cinq, huit, parfois dix sujets simultanés, chacun avançant au ralenti. Un chef de projet qui gère en mode tiré pose une question différente: “quelle est la prochaine tâche que l’équipe a la capacité de traiter maintenant?” Le résultat est un flux plus régulier et des délais de livraison plus courts.

Les limites WIP: le mécanisme que beaucoup ignorent

La plupart des tableaux Kanban utilisés en gestion de projet n’ont pas de limites WIP (work in progress, c’est-à-dire le nombre maximum de tâches autorisées simultanément dans une étape du processus). Les tâches s’accumulent dans les colonnes intermédiaires, “En cours” contient quinze éléments, “En validation” en contient huit et le tableau ressemble davantage à un inventaire qu’à un outil de pilotage.

Poser des limites WIP signifie fixer un nombre maximum de tâches par colonne. Quand la limite est atteinte, aucune nouvelle tâche ne peut entrer dans cette colonne tant qu’une autre n’en est pas sortie. Ce mécanisme, qui semble contraignant, est en réalité le levier le plus puissant du tableau: il rend les blocages visibles immédiatement. Si la colonne “Validation” est pleine, c’est que le processus de validation est le goulot d’étranglement du projet, et toute l’équipe le voit. Sans limite WIP, ce même goulot reste masqué derrière l’illusion que “tout avance”. Le Lean Enterprise Institute identifie la réduction du travail en cours comme l’un des piliers de la pensée Lean, précisément parce qu’elle force l’organisation à traiter ses contraintes plutôt qu’à les contourner en empilant du travail.

Remonter au flux de valeur

Si le tableau Kanban montre ce qui se passe à l’intérieur de l’équipe, la cartographie du flux de valeur (value stream mapping) montre ce qui se passe entre les équipes et les étapes du projet. Le flux de valeur désigne la séquence complète des activités qui transforment un besoin en résultat exploitable par le commanditaire.

Cartographier ce flux, c’est dessiner le parcours réel d’un livrable, de la demande initiale à sa mise en service, en mesurant le temps passé à chaque étape. L’exercice révèle presque toujours la même chose: la majorité du temps n’est pas consommée par le travail lui-même, mais par les transferts et les attentes entre étapes. Un document technique peut être produit en trois jours mais mettre quatre semaines à traverser le circuit de relecture, validation et approbation. Un chef de projet qui réalise cette cartographie pour la première fois découvre souvent que le ratio entre temps productif et temps total est de l’ordre de 10 à 20%.

Les gaspillages à traquer en priorité

Le Lean appelle ces pertes du muda (terme japonais pour gaspillage) et en identifie huit catégories. En gestion de projet, quatre d’entre elles méritent une attention particulière. L’attente est la plus répandue: un livrable qui stagne trois jours dans la boite mail d’un validateur, une équipe bloquée par une décision en suspens, un fournisseur qui attend un retour pour poursuivre. La surproduction se manifeste sous forme de rapports que personne ne lit, de documentations exhaustives produites “au cas où” ou de fonctionnalités ajoutées sans validation du commanditaire. Le surtraitement apparait quand le niveau de formalisme dépasse ce que la situation exige, comme un circuit de validation à cinq niveaux hiérarchiques pour une décision opérationnelle courante. Les défauts, enfin, couvrent tout ce qui doit être repris ou refait, souvent parce que les exigences ont été mal comprises ou que les informations de départ étaient obsolètes.

Ce constat, loin d’être décourageant, constitue le point de départ de l’amélioration: on ne peut réduire que ce qu’on a rendu visible.

Du constat à l’amélioration continue

Le Lean ne propose pas de résoudre tous les problèmes d’un coup. Le principe du kaizen (littéralement “changement vers le mieux”) repose sur des améliorations petites, fréquentes et cumulatives. En pratique, cela signifie qu’une équipe projet qui identifie un gaspillage dans son flux n’a pas besoin de lancer un chantier d’optimisation: elle peut ajuster son processus dès la semaine suivante, observer le résultat, puis ajuster à nouveau.

Cette approche incrémentale convient particulièrement bien à la gestion de projet, où les marges de manoeuvre pour des réformes structurelles sont souvent limitées. Un chef de projet ne peut pas toujours raccourcir le circuit de validation imposé par sa hiérarchie, mais il peut identifier les validations qui n’ajoutent pas de valeur et négocier leur simplification au cas par cas. Concrètement, une équipe qui consacre trente minutes toutes les deux semaines à examiner son tableau Kanban, repérer la colonne où les tâches s’accumulent le plus et convenir d’une action corrective progresse davantage, sur six mois, qu’une équipe qui attend un audit de processus pour agir. Le PMI souligne que l’application du Lean en gestion de projet passe précisément par cette capacité à agir sur les processus locaux plutôt que d’attendre une transformation globale.

Le passage du tableau Kanban aux principes Lean est un chemin naturel pour le chef de projet: commencer par visualiser le travail, puis poser des limites WIP, puis cartographier le flux de valeur au-delà de l’équipe, puis instaurer une discipline d’amélioration continue. Chaque étape approfondit la compréhension du fonctionnement réel du projet et ouvre de nouveaux leviers d’action.