Le dojo — la théorie en 10 minutes

La méthode Kanban, expliquée simplement

Kanban (看板, « panneau visuel » en japonais) est une méthode de gestion du flux de travail née dans les ateliers de Toyota dans les années 1950, formalisée pour les équipes de la connaissance à la fin des années 2000. Son pari : on n'améliore pas ce qu'on ne voit pas. Cette page vous donne l'essentiel — et le Sushi Kanban Game vous le fait vivre en 30 minutes.

1. D'où vient Kanban ?

Chez Toyota, Taiichi Ohno cherchait à produire juste ce qu'il faut, juste à temps : chaque poste de l'usine signalait au poste amont, par une simple carte, qu'il était prêt à recevoir du travail. Le stock fondait, les problèmes devenaient visibles, l'amélioration devenait quotidienne. Deux idées structurent cette pensée lean : réduire le muri (la surcharge des personnes) et le mura (l'irrégularité du flux) — car c'est d'eux que naît le muda, le gaspillage.

Dans les années 2000, la communauté agile a transposé ce système aux travaux intellectuels : le développement logiciel d'abord, puis tout travail qui traverse des étapes — support, recrutement, juridique, marketing. La méthode a été formalisée par David J. Anderson autour de 2010.

2. Les 3 piliers

1. Commencer par ce que vous faites aujourd'hui. Kanban ne remplace pas votre façon de travailler : il la rend visible. Moins de résistance, moins de stress, un point de départ honnête.
2. Respecter les rôles et le processus actuels. Pas de grand soir : la méthode s'applique à l'existant, elle ne l'écrase pas.
3. S'engager à évoluer par petits pas. Le changement incrémental, guidé par les faits, bat la réorganisation brutale — presque toujours.

3. Les 5 pratiques

• Visualiser le travail : un tableau, des colonnes qui représentent les étapes réelles, une carte par élément de travail. La prise de conscience est collective et immédiate.
• Limiter le travail en cours (WIP) : le cœur de la méthode — voir ci-dessous.
• Gérer le flux : piloter avec les mesures du système (débit, temps de traversée) plutôt qu'au périmètre ou à la date promise.
• Rendre les règles explicites : qu'est-ce qu'une carte « finie » ? Qui peut tirer quoi, quand ? Une règle écrite se discute ; une règle implicite se subit.
• S'améliorer ensemble : le système est l'affaire de l'équipe, pas d'un chef de projet. Les blocages sont des informations, pas des fautes.

4. Flux poussé vs flux tiré

Pousser, c'est produire puis transmettre dès qu'on a terminé — que l'aval soit prêt ou non. Chacun optimise son poste, les files d'attente gonflent entre les étapes, et le stock cache les problèmes.

Tirer, c'est l'inverse : c'est la demande réelle de l'aval qui déclenche le travail de l'amont. On ne spécifie que ce qu'on peut construire, on ne construit que ce qu'on peut vérifier, on ne vérifie que ce qu'on peut livrer. Produire plus que ce que l'étape suivante peut absorber n'est pas de l'avance : c'est du gaspillage.

5. Les limites WIP

Une limite WIP (work in progress) plafonne le nombre de cartes autorisées dans une colonne. Une colonne pleine n'accepte plus rien : l'amont doit s'arrêter… ou venir aider. C'est ce blocage volontaire qui crée le flux tiré et qui déclenche les bonnes conversations.

• Trop hautes, les limites ne contraignent rien : on retombe dans le flux poussé et personne n'apprend rien.
• Trop basses, le flux avance par à-coups et se bloque sans cesse — utile seulement pour des équipes déjà mûres.
• Point de départ pragmatique : observez votre système quelques jours et posez une limite proche du nombre de personnes par étape (par exemple entre n + 1 et 2n − 1 pour n personnes), puis ajustez par l'expérience.

Le bénéfice contre-intuitif : en commençant moins de choses, on en termine plus. « Stop starting, start finishing. » Le multitâche coûte cher : chaque changement de contexte détruit de la concentration et allonge tout le monde.

6. Le goulot d'étranglement

Dans tout flux, une étape est plus lente que les autres : le goulot. C'est lui qui fixe le débit de l'ensemble — accélérer ailleurs ne sert à rien, cela ne fait qu'empiler du stock devant lui. Les bons réflexes :

1. l'identifier (la file d'attente la plus grosse, le cycle time le plus long) ;
2. le protéger (qu'il ne manque jamais de travail prêt, jamais de travail inutile) ;
3. l'aider (y déplacer des bras, simplifier ce qui y passe) ;
4. seulement ensuite, investir pour l'élargir.

7. Les métriques de flux

Ces mesures sont liées par une intuition simple : à débit constant, plus il y a de travail en cours, plus le temps de traversée s'allonge. Réduire le WIP est donc le levier le plus direct pour raccourcir le lead time — sans embaucher personne.

8. Lire un diagramme de flux cumulé (CFD)

Le CFD empile, dans le temps, le nombre cumulé d'éléments arrivés à chaque étape. Trois lectures immédiates :

• l'écart vertical entre deux courbes = le travail en cours entre ces étapes ;
• l'écart horizontal ≈ le temps de traversée ;
• une bande qui gonfle = un bouchon qui se forme — le goulot se voit avant de se vivre.

Des bandes fines et parallèles signent un flux sain et prévisible.

9. Les classes de service

Tout le travail n'a pas la même urgence. Plutôt que de laisser le stress décider, Kanban propose des classes de service explicites : standard, date contrainte, expedite (urgence vraie, rare, qui coupe la file), et coût d'opportunité invisible. La règle est connue de tous avant la crise : c'est elle qui absorbe l'urgence, pas les nerfs de l'équipe.

10. L'amélioration continue

Un système kanban n'est jamais « fini ». Le cycle est toujours le même — concevoir, mettre en œuvre, étudier, améliorer — hérité de la roue de Deming (PDCA) : formuler une hypothèse, l'essayer, mesurer, ajuster. La réunion quotidienne devant le tableau en est le battement de cœur : le tableau est-il à jour ? les règles sont-elles suivies ? qu'est-ce qui est bloqué, et qu'est-ce qu'on fait aujourd'hui pour le débloquer ?

Et régulièrement, on prend du recul : c'est exactement ce que fait le débrief entre les manches du jeu — mesurer, comparer, décider d'un changement, rejouer.