Dans bien des équipes, le tableau kanban couvre un mur entier. La colonne « En cours » déborde de post-it pendant que celle du « Terminé » se remplit au compte-gouttes. Chaque matin, l'équipe fait le tour du tableau et chacun dit où il en est. En fin de semaine, peu de cartes ont franchi la dernière colonne.
Le tableau dit pourtant vrai. Il montre une équipe qui commence plus de travail qu'elle n'en termine. Ce qui lui manque tient en une règle, celle qui faisait fonctionner le kanban chez Toyota avant de passer dans les équipes de développement logiciel. David J. Anderson, consultant en management, l'y a transposée. Une tâche n'entre que si une autre sort.
Cette règle relie le kanban à l'amélioration continue. Elle rend visible ce qui coince puis donne à l'équipe un levier simple pour le traiter. Le kanban figure parmi les pratiques que rassemble le kaizen, cette amélioration continue faite de petits pas.
Qu'est-ce que le kanban ?
Le kanban est un système de pilotage qui plafonne le travail en cours pour que les tâches circulent. Une nouvelle tâche n'entre dans le circuit que lorsqu'une place se libère. Le mot désigne deux objets voisins, une carte d'atelier chez Toyota et une méthode de travail dans les équipes de bureau.
À l'usine, le kanban est une carte. Taiichi Ohno, ingénieur industriel, la décrit comme une feuille de papier glissée dans une pochette en vinyle. Elle accompagne les pièces. Elle indique à l'atelier précédent ce qu'il doit produire, en quelle quantité, à quel moment. Sans carte, rien ne se prélève ni ne se fabrique.
Dans les équipes de bureau, le kanban désigne une méthode. Anderson rend le mot japonais par « signal card », une carte de signal. Sur son tableau, la carte représente en fait une tâche. Le signal qui autorise à tirer la suivante vient de l'écart entre le nombre de cartes en cours et la limite écrite au-dessus de la colonne. Anderson parle pour cette raison de kanban virtuel.
Pourquoi un tableau ne suffit-il pas à faire un kanban ?
Anderson pose la distinction dès le deuxième chapitre de son livre. Les murs de cartes répandus dans les équipes agiles permettent de voir le travail en cours et de s'organiser seul, sans attendre les consignes d'un responsable. Ils restent selon lui de simples outils de contrôle visuel tant qu'ils n'ont ni limite explicite du travail en cours ni signal pour tirer le travail suivant. Sans plafond, le kanban n'existe pas encore.
Comment le kanban est-il né chez Toyota ?
Il est né d'un rayon de supermarché. Ohno raconte qu'à la fin des années 1940, l'atelier d'usinage qu'il dirigeait étudiait déjà les supermarchés américains. Le client y prend ce dont il a besoin, au moment voulu et dans la quantité voulue, puis le magasin regarnit le rayon de ce qui a été pris. Ohno transpose le principe à l'usine. L'étape suivante vient se servir chez la précédente. Celle-ci refabrique seulement la quantité prélevée.
Le système entre en 1953 à l'atelier d'usinage de l'usine principale. Ohno ne visite son premier supermarché américain qu'en 1956. Le kanban ne gagne toute l'entreprise qu'en 1962, peu à peu, à mesure que les personnes concernées le comprennent. Ohno estime qu'il a fallu près de vingt ans pour l'étendre aux pièces commandées à l'extérieur, un chantier ouvert en 1963.
Quelles règles font fonctionner le kanban de Toyota ?
Ohno en énonce six. L'étape suivante vient prélever chez la précédente. Celle-ci ne produit que la quantité prélevée. Rien ne se prélève ni ne se fabrique sans kanban. La carte reste attachée aux pièces. Rien de défectueux ne part vers l'étape suivante. La sixième règle demande de réduire le nombre de kanbans.
Cette dernière règle parle le plus à une équipe de bureau. Moins de cartes en circulation, c'est moins de travail qui attend entre deux étapes. Ohno range ses règles sous un intertitre qui dit leur effet, le kanban accélère les améliorations. Son usage montre aussitôt ce qui relève du gaspillage, écrit-il. Le glossaire de son livre ajoute qu'une ligne de production qui ne s'arrête pas est soit parfaite, soit porteuse de gros problèmes qui ne remontent pas.
Le kanban suffit-il à organiser le travail ?
Ohno répond par la négative. Il observe que hors de Toyota on prend volontiers le kanban pour le système de production lui-même. Le système est la méthode de production, le kanban la façon de la gérer. Sa première tentative sur la chaîne d'assemblage final a échoué parce que le flux n'existait pas encore en amont. Il précise que l'atelier d'usinage n'y était pour rien.
Un kanban posé sur un travail désorganisé ne l'organise pas. Il en montre le désordre. Une introduction faite à moitié apporte selon Ohno « a hundred harms and not a single gain », cent maux sans le moindre gain.
Comment le kanban est-il passé de l'usine aux équipes de bureau ?
Par un manager qui cherchait à faire évoluer ses équipes sans leur imposer de méthode. Au début des années 2000, Anderson dirige des équipes de développement logiciel chez Sprint PCS puis chez Motorola. Il tire de cette expérience un constat. Une méthode agile imposée par la hiérarchie obtient au mieux un consentement de façade. Pour lui, demander aux gens de changer de comportement crée de la peur et abîme l'estime de soi, parce que cela leur signifie que leurs compétences ne comptent plus.
Le premier système kanban virtuel naît en 2004 chez Microsoft, dans une équipe de maintenance logicielle installée en Inde. Au printemps 2005, Anderson visite les jardins est du palais impérial de Tokyo. À l'entrée, un vieux monsieur remet à chaque visiteur une carte en plastique. À la sortie, chacun la rend au guichet sans rien payer. Quand toutes les cartes sont distribuées, les nouveaux venus attendent qu'un visiteur ressorte. Le nombre de cartes limite la foule et protège le jardin. Anderson y voit la preuve que le kanban peut sortir de l'usine.
Que garde la méthode d'Anderson du kanban de Toyota ?
Elle garde le flux tiré et la limite. Elle abandonne la carte qui circule entre deux ateliers. Son livre de 2010 la résume en cinq propriétés de base :
- visualiser le flux de travail ;
- limiter le travail en cours ;
- mesurer et piloter le flux ;
- rendre explicites les règles du processus ;
- s'appuyer sur des modèles pour repérer les occasions d'amélioration.
La méthode a évolué depuis. Les supports publiés en 2021 par Kanban University, organisme de formation à la méthode, parlent de six pratiques générales, avec les boucles de rétroaction en plus. Le cœur n'a pas bougé.
Anderson insiste surtout sur le point de départ. Le kanban part de l'existant et cherche à changer le moins de choses possible. Les rôles, les intitulés de poste et les pratiques restent en place, avec tout ce dont chacun tire sa fierté professionnelle. Seuls changent la quantité de travail en cours et la façon d'échanger avec ceux qui envoient le travail à l'équipe ou le reçoivent d'elle.
| Question | Kanban de Toyota (Ohno) | Kanban d'équipe (Anderson) |
|---|---|---|
| Premier terrain | Atelier d'usinage de l'usine principale, 1953 | Équipe de maintenance logicielle de Microsoft, 2004 |
| Ce que porte la carte | Ce qu'il faut produire, en quelle quantité et à quel moment | Une tâche à livrer, avec de quoi décider seul de la tirer |
| D'où vient le signal | La carte qui revient vers l'atelier précédent | L'écart entre les cartes en cours et la limite écrite |
| Ce qui plafonne le travail en cours | Le nombre de cartes en circulation | Une limite par colonne ou pour tout le tableau |
| Condition préalable | Un flux établi, une production nivelée, un travail standardisé | Le processus réel, dessiné tel qu'il se pratique |
| Ce qui change au départ | L'organisation de la production, étape par étape | Le moins de choses possible |
Comment installer un kanban dans une équipe ?
En cinq gestes, dans un ordre qui part du travail tel qu'il se fait. La séquence ci-dessous assemble des pratiques décrites par Anderson, dans un ordre propre à cet article. Elle vaut pour une équipe de projet comme pour un service qui traite des demandes.
- Dessiner le processus réel. L'équipe trace les étapes que traverse vraiment une demande, de son acceptation à sa livraison. Anderson prévient que les équipes redessinent volontiers le processus officiel. Il faut insister pour obtenir celui qu'elles pratiquent, faute de quoi le tableau restera au mur sans servir. Une question aide à y parvenir. Par où est passée la dernière demande livrée ?
- Couper chaque étape en deux. Une colonne d'activité se divise en « en cours » et « terminé ». Sans cette coupure, le tableau cache le travail fini qui attend que l'étape suivante le prenne. Ces attentes pèsent lourd. Dans l'équipe de Microsoft, Anderson relève onze jours de travail effectif en moyenne pour des délais de 125 à 155 jours.
- Poser une limite par colonne. Un chiffre en haut de chaque colonne dit combien de cartes elle peut contenir. Une fois ce chiffre atteint, une carte n'entre qu'après la sortie d'une autre. La section suivante dit comment le choisir.
- Écrire les règles sur le tableau. Pour Anderson, un processus est un ensemble de règles qui gouvernent les comportements. La plupart relèvent du management. Les écrire permet de les discuter. Que veut dire « terminé » à chaque étape ? Qui peut faire entrer une urgence ? Anderson réserve aux urgences une classe à part, limitée à un seul élément à la fois.
- Tenir le point quotidien devant le tableau. Le tableau rend inutile le tour de table où chacun raconte ce qu'il a fait la veille. L'animateur parcourt les cartes de droite à gauche, dans le sens où le travail est tiré. Il s'arrête sur ce qui bloque ou ne bouge plus depuis plusieurs jours.
Un premier tableau se redessine en général après quelques semaines, quand l'équipe a vu où le travail s'accumule. Mieux vaut le tracer au feutre effaçable qu'à la règle.
Marquez d'un point chaque journée qu'une carte passe au même endroit. Anderson rapporte cette astuce, relevée chez un constructeur italien de voitures de sport. Au bout d'une semaine, les cartes immobiles se voient de loin.
Comment choisir la limite de travail en cours ?
Par un chiffre simple, ajusté à l'usage. Anderson recommande un élément en cours par personne, par binôme ou par petite équipe. Si l'équipe résiste, deux par personne restent raisonnables, trois parfois. « There is no magic formula for your choice », écrit-il. Le chiffre se règle par l'expérience, vers le haut ou vers le bas.
Le point de départ dépend de la maturité de l'équipe. Une limite trop serrée dans une organisation chaotique fait surgir tous les problèmes en même temps. Anderson appelle ce creux l'effet J. Le kanban risque alors d'être accusé d'avoir créé les difficultés qu'il révèle. Il conseille dans ce cas une limite plus lâche, à resserrer ensuite.
Se passer de limite reste à ses yeux une erreur. Des équipes de Yahoo! avaient choisi d'attendre, jugeant leur organisation trop chaotique pour la supporter. Plusieurs ont abandonné le kanban sans avoir vu de vrai progrès. Pour Anderson, la tension que crée la limite est saine. Elle oblige l'équipe à parler de ce qui empêche le travail d'avancer.
Avec qui négocier la limite ?
Avec ceux qui envoient le travail à l'équipe et avec la direction. Anderson recommande de fixer les limites par consensus avec eux, pour pouvoir s'appuyer sur cet accord le jour où la pression monte. Il cite un responsable de développement danois dont les développeurs menaient en moyenne sept tâches et demie en parallèle. À sa place, Anderson ouvrirait la discussion par ce chiffre, dirait ce qu'il coûte en délai et en prévisibilité, puis laisserait les autres proposer mieux. Les propositions devraient tomber entre une et trois tâches par personne.
L'accord change la réponse à la demande urgente suivante. L'équipe peut alors poser une question qu'Anderson formule presque mot pour mot. Laquelle des tâches en cours faut-il mettre de côté pour commencer celle-ci ?
Faut-il baisser la limite une fois le flux installé ?
Oui, par petits pas. La sixième règle d'Ohno invite à réduire le nombre de cartes. Chaque baisse d'un cran resserre le flux et fait apparaître un problème que le travail en attente amortissait, une validation qui tarde, une compétence que seule une personne détient, une dépendance à une autre équipe. L'équipe le traite, observe l'effet pendant quelques semaines, puis décide d'une nouvelle baisse ou d'un retour en arrière. La démarche tient de l'hypothèse mise à l'épreuve, comme dans le PDCA passé au rasoir d'Ockham.
Une limite basse va de pair avec des lots de travail plus petits. Une tâche découpée finement traverse le tableau plus vite et revient plus tôt vers l'équipe si elle était mal comprise. L'article sur la boucle de travail courte que les agents IA rendent obligatoire développe ce lien entre taille du lot et apprentissage.
Qu'est-ce qui transforme un tableau kanban en simple liste de tâches ?
L'absence de limite d'abord, puis quatre habitudes qui retirent au tableau son rôle de pilotage. Chacune se repère en quelques minutes devant le mur.
La colonne « En cours » n'a pas de plafond. Tout ce qui a été commencé y reste. Le tableau grossit pendant que le délai s'allonge, sans que rien ne le signale. Le premier geste consiste à compter les cartes en cours puis à rapporter ce nombre à celui des personnes qui les portent.
Le tableau montre le processus officiel. Les colonnes reprennent la procédure écrite pendant que le travail suit un autre chemin, par messages ou par échanges de couloir. Le tableau prend du retard sur la réalité. L'équipe cesse peu à peu de le mettre à jour.
Le point quotidien reste un tour de table. Chacun raconte sa journée sans regarder les cartes, de sorte que ce qui bloque passe inaperçu. Parcourir le tableau en partant de la colonne la plus proche de la livraison ramène l'attention sur ce qui doit sortir. Le geste rejoint le gemba, l'habitude d'aller voir le travail là où il se fait.
Les règles restent dans les têtes. L'équipe ignore qui peut ajouter une carte ou ce que « terminé » veut dire. Les urgences entrent par la porte de côté. La limite devient une suggestion.
Le kanban est imposé à l'équipe. Anderson a construit sa méthode contre ce travers. Ohno raconte lui aussi les plaintes que recevait son supérieur quand il pressait les contremaîtres d'adopter le kanban, avec une insistance qu'il reconnaît. Un tableau dessiné par un responsable pour son équipe risque de mesurer la docilité de l'équipe plus que son travail. Le kanban relève lui aussi du principe selon lequel le lean management commence par le respect des personnes.
Le kanban sert-il aussi à limiter les chantiers d'IA ?
Oui. La limite vaut pour tout ce qu'une personne ou une équipe suit en même temps, chantiers d'IA compris. Un assistant ou un agent se lance en quelques secondes. Les travaux commencés puis laissés en plan se multiplient d'autant plus vite.
En 2025, très gros utilisateur d'IA, je me suis donné des garde-fous pour rester ancré dans le réel. L'un d'eux est une limite de chantiers IA ouverts en même temps, à la manière du Kanban. Je la propose aux équipes que j'accompagne.
Le plafond par personne et la façon de l'ajuster au bout de deux semaines sont détaillés dans l'article sur la fatigue cognitive qui guette les utilisateurs les plus engagés de l'IA. Quand la question porte sur plusieurs projets à la fois, la méthode des places décide quel projet mène la semaine. Elle applique la même limite au niveau du portefeuille.
Questions fréquentes
Scrum découpe le temps en itérations de durée fixe et répartit trois responsabilités dans l'équipe. Le kanban n'impose ni itération ni rôle. Il part du processus existant et limite directement le travail en cours à chaque étape. Les deux se combinent dans bien des équipes. Comme le rappelle le Modern Agile avec ses quatre principes, ces méthodes organisent le travail sans en fixer la finalité.
Un mur, des post-it et un feutre suffisent pour commencer quand l'équipe travaille au même endroit. Une équipe répartie sur plusieurs sites a besoin d'un outil partagé. Le premier système kanban d'Anderson, chez Microsoft, tournait déjà sur un outil électronique de suivi. L'essentiel reste la limite écrite et tenue, quel que soit l'outil.
Oui. Il est né dans un atelier d'usinage avant qu'Anderson l'applique à des équipes informatiques. Ses principes valent pour tout travail qui passe par des étapes, un service juridique qui traite des contrats, une équipe RH qui mène des recrutements, un service communication qui publie des contenus. L'exemple qui a convaincu Anderson est un jardin public.
Autant que d'étapes réellement distinctes, chacune coupée en « en cours » et « terminé ». Une colonne qui ne correspond à aucun changement de main ni de compétence peut disparaître. Le tableau doit rester lisible de loin.
La faire passer par une classe de service dédiée. Anderson n'autorise qu'une urgence à la fois. Elle peut dépasser la limite ordinaire. Chez Corbis, l'entreprise où il appliquait la méthode, on n'a compté que cinq demandes urgentes sur toute l'année 2007. Des urgences qui se chassent l'une l'autre signalent en général un problème de priorités, à traiter avec ceux qui les envoient.
Par un comptage. Combien de sujets sont commencés sans être terminés et combien de personnes les portent ? Ce rapport ouvre souvent la discussion sur la limite. Pour regarder ensemble comment le travail circule dans votre équipe, réservons un échange de 30 minutes.
Votre équipe commence-t-elle plus de travail qu'elle n'en termine ?
Que vous soyez dirigeant, manager ou DRH, un premier échange permet de regarder comment le travail circule dans votre équipe et de choisir par où commencer.
Réserver un échange découverte (30 min)Allez plus loin
- Toyota Production System, Beyond Large-Scale Production La logique du système de production de Toyota racontée par son architecte, avec la naissance du kanban, ses six règles et la condition qu'il pose, un flux établi avant la carte. Voir le livre →
- Kanban Le kanban comme méthode pour visualiser et limiter le travail en cours dans le développement logiciel, ajouté aux processus existants pour catalyser un changement culturel plutôt que pour les remplacer. Voir le livre →
Liens affiliés
