Kanban : du signal de production à la todo list dévoyée

Le kanban, né chez Toyota dans les années 1950 sous l’impulsion de Taiichi Ohno, n’était pas un outil de visualisation mais un signal : littéralement une carte ou une étiquette qui autorisait la production.

L’essence du flux tiré

Dans le système de production Toyota, un poste aval qui consomme une pièce renvoie le kanban au poste amont, signalant « j’ai besoin d’une unité de plus ». Sans ce signal, aucune production ne démarre.

C’est l’essence du flux tiré : la demande réelle du client, propagée de proche en proche, déclenche la production, par opposition au flux poussé où l’on produit selon des prévisions puis on tente d’écouler le stock.

Le kanban matérialise cette inversion fondamentale du déclencheur de production.

Flux tiré vs one-piece flow

Le flux tiré se distingue du one-piece flow, bien que les deux concepts soient complémentaires :

• Le one-piece flow désigne le traitement des pièces une par une, sans lots, réduisant les encours (le stock) et accélérant le temps de traversée
• Le flux tiré concerne le déclenchement de ce travail : qui donne le signal de commencer

On peut avoir un flux tiré avec des lots (kanban de conteneur), ou un one-piece flow déclenché par un flux poussé (ce qui crée rapidement des engorgements).

L’idéal toyotiste combine les deux : des pièces unitaires dont la production est tirée par la consommation aval. Le kanban est le mécanisme de synchronisation qui rend cette combinaison viable à grande échelle.

Rendre les problèmes visibles

Une vertu souvent négligée du kanban physique est sa capacité à rendre les problèmes visibles :

• Quand les cartes s’accumulent à un poste, le goulot d’étranglement devient littéralement tangible : on voit les kanbans s’empiler
• Quand un poste manque de cartes, la rupture d’approvisionnement est immédiatement apparente

Cette visualisation n’est pas décorative ; elle déclenche l’action. Le principe du jidoka (arrêt au défaut) s’appuie sur cette visibilité : un problème caché est un problème qui s’aggrave.

Le tableau kanban, dans sa forme authentique, est un système d’alerte distribué où chaque anomalie se manifeste par une perturbation visible du flux de cartes.

La transposition en informatique

La transposition du kanban en informatique, popularisée par David Anderson au milieu des années 2000, a retenu la visualisation mais souvent perdu le signal.

Un tableau avec des colonnes « À faire », « En cours », « Terminé » ressemble superficiellement à un kanban, mais sans limite de travail en cours strictement respectée, sans signal tiré depuis l’aval, c’est simplement une todo list spatialisée.

On pousse des tâches dans la colonne « À faire » selon les priorités du backlog, on les pousse vers « En cours » quand un développeur se libère. Le flux reste poussé ; la visualisation est là, mais le mécanisme de régulation a disparu.

Le véritable kanban en IT

Le véritable kanban en IT imposerait qu’une nouvelle tâche n’entre dans le système que lorsqu’une place se libère : quand une tâche sort de « En cours », un signal remonte pour tirer la suivante.

Les limites WIP (work in progress) incarnent cette contrainte : si la colonne « En cours » est pleine, personne n’y ajoute de tâche, forçant soit l’aide au déblocage, soit l’attente.

Cette friction délibérée :

• Révèle les goulots
• Expose les dépendances
• Rend le surchargement impossible à ignorer

Sans ces limites respectées, sans ce signal tiré, le « kanban » n’est qu’un tableau de Post-its glorifié : utile pour voir où en sont les choses, mais dépourvu du pouvoir régulateur qui faisait la force du système original.