La méthode Kanban est une méthode de management du flux de travail : elle rend visible un processus existant, puis limite le nombre de tâches menées simultanément à chaque étape, afin que le travail avance plus vite et plus régulièrement. Le tableau kanban n’en est que la partie visible.
C’est de cette partie visible que naît l’essentiel du malentendu. Beaucoup d’équipes installent trois colonnes — à faire, en cours, terminé —, considèrent la méthode adoptée, et ne constatent aucun changement. Il manque la mécanique : un système de flux tiré dont la capacité est explicitement plafonnée. Cet article y consacre l’essentiel, en commençant par la seule règle qui produise un effet, la limite de WIP.
Mon article en bref
Kanban n’est pas un tableau à colonnes, c’est un système de flux à capacité limitée. Le tableau ne fait que montrer le travail ; ce qui change quelque chose, c’est le plafond posé sur le nombre d’éléments en cours. Et c’est précisément la règle que la plupart des équipes retirent au premier embouteillage.
Voici les points essentiels à retenir :
- Définition : une méthode de management du flux de travail, qui visualise un processus existant et plafonne le nombre d’éléments traités en même temps.
- Le tableau n’est pas la méthode : sans limite inscrite sur les colonnes ni conditions de passage écrites, c’est un tableau d’affichage.
- Le flux tiré : on ne pousse pas le travail vers l’étape suivante, on le tire quand une place s’y libère.
- La limite de WIP : elle raccourcit les délais par arithmétique, via la loi de Little, et elle révèle le goulot d’étranglement en arrêtant le tableau.
- Sur l’existant, pas à la place : Kanban se pose sur la manière de travailler en place, sans nouveau rôle ni nouveau découpage du temps.
Sommaire
Méthode Kanban : définition d’un système de flux à capacité limitée
Le Kanban Guide, référence commune de la communauté, définit Kanban comme une stratégie d’optimisation du flux de valeur à travers un processus. Trois pratiques la composent : définir et visualiser un flux de travail, gérer activement les éléments qui s’y trouvent, améliorer ce flux. Rien, dans cette définition, ne parle de colonnes.
Le mot flux y désigne le mouvement de la valeur potentielle à travers un système. Or un système a un nombre de places fini : à un instant donné, une équipe ne peut avoir que N choses réellement en cours, comme un bac à glaçons n’a qu’un nombre déterminé de cases. Kanban rend ce nombre explicite au lieu de le laisser flotter. C’est toute la différence entre un système et un affichage.
L’origine japonaise du kanban, de Toyota au travail intellectuel
En japonais, kanban désigne un panneau, une enseigne ou une carte de signalisation. Le terme vient du système de production Toyota : quand un poste avait consommé son lot de pièces, une carte remontait vers l’amont pour autoriser le réapprovisionnement — ni plus tôt, ni en plus grande quantité. C’est la logique historique de la méthode kanban en gestion de production et de stock.
Le passage au travail intellectuel est bien plus récent. Le Kanban Guide, qui rattache la méthode aux travaux de Taiichi Ohno et de W. Edwards Deming, situe la formalisation des pratiques pour le travail de la connaissance dans une équipe de l’entreprise Corbis, en 2006 ; David J. Anderson les a publiées en 2010.
Le tableau kanban : ce qu’il montre, ce qu’il ne fait pas
Un tableau kanban est la représentation visuelle d’un flux de travail. Ses colonnes ne sortent d’aucun modèle standard : elles décrivent les étapes réellement traversées par le travail dans l’équipe, entre le point de départ et le point d’arrivée qu’elle a définis. Chaque carte représente un élément de travail, et le Kanban Guide ne prescrit aucune règle de mise en forme.
Ce que le tableau doit rendre explicite — ce que la référence appelle la Definition of Workflow, l’accord partagé sur ce qu’est le flux — tient en quelques éléments :
- Les éléments de travail : ce qui circule dans le flux, et ce qui n’y entre pas.
- Le début et la fin : à partir de quand un élément est réputé commencé, et jusqu’où il va.
- Les états traversés : les colonnes, autrement dit les étapes réelles du processus.
- Le contrôle du travail en cours : comment le nombre d’éléments simultanés est plafonné.
- Les politiques explicites : les conditions à remplir pour passer d’un état au suivant.
- L’attente de niveau de service : une prévision de délai assortie d’une probabilité, du type « 85 % des éléments terminés en huit jours ou moins ».
Le support est indifférent : un tableau blanc au mur, un tableur, ou un outil comme Jira ou Trello. Ce sont les quatrième et cinquième points de cette liste qui font la méthode — et ce sont précisément ceux que la plupart des tableaux n’affichent pas.
Sur ce que Kanban partage ou non avec le cadre le plus répandu en développement produit, l’article consacré aux différences entre Scrum et Kanban traite la question en détail, et elle n’est pas reprise ici. Une précision de vocabulaire suffit à ce stade : Kanban n’est ni une méthodologie, ni un framework agile, mais une méthode de management appliquée à un processus déjà en place.
En vidéo : « Méthode Kanban explication avec exemple » (chaîne StrategeMarketing), une présentation en français du principe et de son tableau.
Le flux tiré : on ne pousse pas le travail, on le tire
Deux régimes de fonctionnement s’opposent. Dans un flux poussé, le travail est affecté dès qu’il est décidé : la demande arrive, elle est transmise à l’étape suivante, sans que personne ne vérifie si cette étape a de la place. Dans un flux tiré, un élément n’entre dans une étape que lorsqu’une place s’y libère.
Le Kanban Guide présente ce mécanisme comme une conséquence, non comme une pratique séparée : contrôler le travail en cours crée un système tiré, dans lequel un élément n’est sélectionné que lorsqu’un signal clair indique qu’il existe de la capacité pour le traiter. Le signal, ici, c’est le travail en cours qui redescend sous la limite.
Dans l’atelier de Toyota, ce signal était une carte qui remontait physiquement le flux. En travail intellectuel, il n’a aucune matérialité : c’est une place vide dans une colonne. La logique reste celle du cordon tiré depuis l’aval — rien ne part de l’amont avant que l’aval n’ait sonné.
Le réapprovisionnement : ce qui entre sur le tableau, et quand
Un système tiré déplace la question : la difficulté n’est plus d’affecter le travail, mais de décider ce que l’on tire lorsqu’une place se libère. La file d’attente en amont du tableau est le backlog produit, et l’ordre dans lequel on y puise relève d’une méthode de priorisation — MoSCoW, une matrice de valeur, ou tout autre critère assumé.
Kanban demande que cette décision devienne une politique explicite, écrite à côté du tableau : quand réapprovisionne-t-on, en quelle quantité, et qui décide.
Pourquoi le flux poussé fabrique des files d’attente invisibles
Pousser le travail ne le fait pas avancer : cela le déplace dans une file d’attente entre deux étapes. En production, ce stock intermédiaire se voit, puisqu’il occupe de la place. En travail intellectuel, il est intangible, et rien ne signale qu’il s’accumule. Dix sujets affichés « en cours de développement » dont sept attendent une relecture ne sont pas dix sujets en cours, mais trois — une différence qu’aucun tableau à trois colonnes ne peut montrer.
La limite de WIP : la règle qui produit un effet
Le WIP, pour Work In Progress, ou travail en cours, est le nombre d’éléments commencés et non terminés. La limite de WIP est le nombre maximal d’éléments autorisés simultanément : dans une colonne, dans une portion du flux, ou dans le système entier. Elle s’écrit sur le tableau, et elle s’applique.
Son intérêt n’a rien de moral. La documentation de la méthode le formule par une analogie routière : quand les ressources sont pleinement utilisées, il n’y a plus de jeu dans le système et le flux devient très mauvais, comme aux heures de pointe sur une autoroute. Le taux d’occupation est maximal, le débit minimal. S’y ajoute le coût des changements de contexte.
La loi de Little : pourquoi limiter le travail en cours raccourcit les délais
Ce point n’est pas une opinion, c’est un théorème. La loi de Little, établie par John D. C. Little en 1961, énonce que dans un système stationnaire le nombre moyen d’éléments présents (L) est égal au taux d’arrivée moyen (λ) multiplié par le temps moyen passé dans le système (W), soit L = λ × W.
Transposée à un flux de travail, la relation se lit dans l’autre sens : temps de cycle moyen = travail en cours moyen ÷ débit moyen. À débit constant, diviser par deux le travail en cours divise par deux le délai de traversée. Imaginons une équipe dont le débit reste stable à cinq éléments terminés par semaine :
| Travail en cours moyen | Débit moyen | Temps de cycle moyen |
|---|---|---|
| 5 éléments | 5 par semaine | 1 semaine |
| 10 éléments | 5 par semaine | 2 semaines |
| 20 éléments | 5 par semaine | 4 semaines |
Deux précautions d’usage, puisqu’il s’agit d’un théorème et non d’une promesse. La relation porte sur des moyennes, sur une période où le système est stable. Et elle ne dit pas que réduire le travail en cours augmente le débit : elle dit qu’à débit égal, moins de travail en cours donne un délai plus court.
Sur l’effet propre au débit — moins de changements de contexte, moins de reprises —, aucune donnée chiffrée n’est ici défendable. Les gains de productivité qui circulent abondamment sur le sujet ne remontent à aucune source primaire consultable : ils ne figurent donc pas dans cet article, et l’argument reste qualitatif.
Les quatre indicateurs de flux à suivre
Le Kanban Guide impose un socle de quatre mesures, minimum pour piloter un système :
- Le travail en cours : le nombre d’éléments commencés mais non terminés.
- Le débit : le nombre d’éléments terminés par unité de temps, compté en éléments.
- L’âge de l’élément : le temps écoulé depuis qu’un élément a été commencé.
- Le temps de cycle : le temps écoulé entre le début et la fin d’un élément.
Aucun de ces indicateurs ne se compte en points. Une équipe qui pratique la méthode Scrum estime souvent en story points et suit une vélocité ; un système Kanban compte des éléments terminés et mesure des durées. Les deux familles de mesures ne se convertissent pas l’une dans l’autre.
Le goulot d’étranglement : ce que la limite révèle
Sans limite, le travail continue d’entrer et le goulot d’étranglement reste caché : la file qui s’accumule devant l’étape saturée passe pour de l’activité. Avec une limite, la colonne se remplit, plus rien n’y entre, et le tableau s’arrête. Cet arrêt est l’information — l’étape qui sature est la contrainte réelle, et c’est elle qui fixe le débit de l’ensemble.
Imaginons une équipe où une seule personne est habilitée à valider les relectures de code. Tant que le travail est poussé, chacun ouvre de nouveaux sujets et la file devant la relecture grossit sans devenir un problème pour personne. Avec une limite atteinte, la question est impossible à contourner. Une dette technique installée entretient de la même façon un goulot durable, sur un composant que plus personne ne veut toucher.
La réaction correcte n’est pas d’élargir la limite, mais d’aller travailler là où ça bloque. C’est le sens de la formule stop starting, start finishing — arrêter de commencer, commencer à finir.
Quelle limite choisir, et pourquoi elle finit par sauter
Il n’existe pas de nombre universel, et la méthode ne prétend pas en fournir. Le procédé consiste à partir de l’existant : compter le travail réellement en cours aujourd’hui, poser la limite légèrement en dessous, observer, puis rerégler. La révision 2025 du Kanban Guide a d’ailleurs assoupli la façon de contrôler le travail en cours, pour laisser ce réglage au contexte.
Le mode de défaillance, lui, est constant. Au premier embouteillage, quelqu’un relève la limite ou fait passer une carte « urgente » à côté : elle cesse alors d’exister et le tableau redevient un affichage. La seule parade est d’en faire une politique convenue collectivement, dont les dérogations acceptables sont elles aussi écrites — le Kanban Guide le demande explicitement.
Kanban se pose sur le processus existant, il ne le remplace pas
Kanban University est catégorique : Kanban n’est ni une méthodologie, ni un framework de processus, mais une méthode de management qui s’applique à une manière de travailler déjà en place. Sa formule est nette — Kanban est un moyen d’améliorer ce que vous faites déjà et la façon dont vous le faites, pas un remplacement de ce que vous faites.
Trois principes de conduite du changement en découlent, communs à toutes les mises en œuvre :
- Commencer par ce que vous faites aujourd’hui, sans redéfinir le processus au préalable.
- S’accorder sur une amélioration par changement évolutif, plutôt que par bascule d’un état à un autre.
- Encourager les actes de leadership à tous les niveaux, y compris en dehors des rôles hiérarchiques.
C’est ce qui distingue Kanban d’une transformation agile : pas de nouveau rôle, pas de nouveau découpage du temps, pas de réorganisation le premier jour. On garde le processus tel qu’il est, on l’affiche, on plafonne le travail en cours, on observe. Pour situer les filiations, Kanban vient du lean manufacturing et non du manifeste agile, même si les deux se rejoignent sur le fond.
Les six pratiques générales de la méthode Kanban
- Visualiser le travail et son cheminement.
- Limiter le travail en cours, ce qui établit un système tiré.
- Gérer le flux : le rendre régulier et prévisible, à un rythme soutenable.
- Rendre les politiques explicites : critères de passage, limites, classes de service.
- Mettre en place des boucles de retour : le tableau, les indicateurs, des revues.
- S’améliorer collaborativement et évoluer par l’expérimentation.
Les boucles de retour n’exigent aucun rituel nouveau : elles peuvent réutiliser ce qui existe — un point quotidien, une revue hebdomadaire, ou les cérémonies Scrum si l’équipe en tient déjà. Le Kanban Guide, de son côté, condense ces six pratiques en trois : les deux références décrivent la même chose à des niveaux de détail différents.
Régler la limite par petits crans, comme une molette
L’amélioration continue fonctionne par expériences réversibles : on formule une hypothèse, on modifie un paramètre — le plus souvent une limite —, on observe les indicateurs, puis on conserve ou on revient en arrière. La boucle est celle de la roue de Deming, et ce n’est pas un hasard : le Kanban Guide cite W. Edwards Deming parmi les sources de la méthode.
Une équipe qui tient déjà des sprints et ajoute des limites de WIP à son tableau pratique ce que certains appellent le scrumban. L’étiquette importe peu ; ce qui compte, c’est que la limite soit réellement opposable, y compris à celui qui la trouve gênante.
Pour situer les termes, la distinction entre méthode agile et Scrum vaut aussi pour Kanban : l’agilité désigne un ensemble de principes, dont Scrum et Kanban sont des mises en œuvre de natures différentes. Si je ne devais retenir qu’une pratique de Kanban, ce serait la limite de WIP : c’est la seule qui contraigne vraiment une décision, et la première qu’on abandonne. Un tableau sans limite reste utile pour voir qui fait quoi, mais il ne raccourcit aucun délai.
FAQ — Tout savoir sur la méthode Kanban
Que veut dire « kanban » et d’où vient la méthode ?
En japonais, kanban désigne un panneau, une enseigne ou une carte de signalisation. Le terme vient du système de production Toyota, où une carte physique autorisait le réapprovisionnement d’un poste. Son application au travail intellectuel est plus récente : les pratiques ont été formalisées dans une équipe de l’entreprise Corbis en 2006, puis publiées en 2010.
Comment fonctionne un tableau kanban ?
Ses colonnes reprennent les étapes réelles du processus de l’équipe, entre le point de départ et le point d’arrivée qu’elle a définis ; chaque carte est un élément de travail qui les traverse. Ce qui le rend opérant, ce sont les deux mentions le plus souvent absentes : une limite du nombre de cartes par colonne, et les conditions écrites pour passer à l’étape suivante.
Qu’est-ce que la limite de WIP en Kanban ?
C’est le nombre maximal d’éléments de travail autorisés simultanément dans une colonne, dans une portion du flux ou dans tout le système. Elle transforme le tableau en système tiré : un nouvel élément n’entre que lorsqu’une place se libère. La loi de Little garantit qu’à débit constant, moins de travail en cours donne un délai plus court.
La méthode Kanban est-elle une méthode agile ?
Kanban partage l’esprit de l’agilité — flux régulier, amélioration continue, décisions fondées sur des données — mais ses racines sont dans le lean manufacturing et non dans le manifeste agile. Kanban University précise que ce n’est ni une méthodologie ni un framework de processus, mais une méthode de management appliquée à un processus existant.
La méthode Kanban sert-elle à la gestion de stock ?
C’est son usage d’origine : en gestion de production, la carte kanban déclenche le réapprovisionnement d’un poste uniquement lorsque celui-ci a consommé ses pièces, ce qui plafonne mécaniquement les stocks intermédiaires. La version appliquée au travail intellectuel garde le mécanisme de tirage, mais ce qu’elle plafonne est un nombre de dossiers en cours, pas des pièces.
Quels sont les inconvénients de la méthode Kanban ?
Elle ne prescrit ni rôle, ni rendez-vous, ni découpage du temps : une équipe qui manque de discipline collective obtient un tableau et rien d’autre. Elle offre peu de prise sur un engagement à date fixe, puisqu’elle raisonne en délai probable plutôt qu’en périmètre daté. Et sa règle centrale, la limite de WIP, se contourne très facilement.
