看板 — Enseigne
Kanban (看板) est japonais. Les caractères se décomposent comme suit : 看 (kan), regarder, voir, et 板 (ban) : tableau, planche, enseigne. Ensemble : un tableau de signalisation visuelle.
Le mot précède le système de gestion de plusieurs siècles. Chaque boutique du Japon de la période Edo avait un kanban : une enseigne en bois à l'extérieur annonçant ce qui était vendu à l'intérieur. Le signal visuel était la publicité, l'indicateur d'inventaire, et le déclencheur de réapprovisionnement tout à la fois.
L'intuition du supermarché de Taiichi Ohno
Dans les années 1950, l'ingénieur Toyota Taiichi Ohno a visité des supermarchés américains. Ce qu'il a vu a changé l'histoire de la fabrication.
Dans une usine traditionnelle, le modèle push (poussée), la production fonctionnait selon un calendrier. Une prévision disait « nous aurons besoin de 500 unités le mois prochain », donc l'usine fabriquez 500 unités et les envoyait à une étagère. Si la demande était mauvaise, l'étagère débordait. Si la demande dépassait la prévision, l'étagère était vide. Dans les deux cas, quelqu'un s'était trompé.
Les supermarchés fonctionnaient différemment. Les étagères tenaient une quantité fixe de chaque article. Quand un client prenait le dernier pot de beurre d'arachide, l'emplacement vide était lui-même le signal de réapprovisionnement. Les préposés au stock n'avaient pas besoin d'un gestionnaire pour leur dire de réapprovisionner : l'étagère le leur disait. C'est le modèle pull (tirage) : la demande en aval signale le réapprovisionnement en amont.
Ohno a ramené cette intuition chez Toyota. La carte physique (kanban) attachée à un bac de pièces est devenue le signal : « ce bac est vide : produisez davantage. » Aucune prévision nécessaire. Aucun planificateur central. Le travail s'est tiré lui-même vers l'avant.
Tirage vs Poussée
La distinction tirage/poussée est le fondement de tout ce qui suit.
Les colonnes comme états
Un tableau kanban rend le travail visible. Chaque unité de travail est une carte. Les cartes se déplacent de gauche à droite dans les colonnes qui représentent les états.
Les colonnes classiques sont : Arriéré → Sélectionné → En cours → Révision → Terminé
Mais les colonnes exactes ne sont pas importantes. Ce qui compte, c'est que chaque carte ait exactement un état courant, et que cet état soit visible à tous ceux qui travaillent dans ce système.
Ce qu'une carte représente
Une carte représente une unité de travail qui peut être complétée indépendamment. Pas un projet. Pas un objectif. Une chose spécifique, délimitée en champ avec une définition claire de « terminé ».
Bonne carte : Rotation des clés SSH sur les serveurs de production : terminée quand tous les serveurs affichent la nouvelle clé dans authorized_keys et l'ancienne clé est supprimée.
Mauvaise carte : Améliorer la sécurité. (C'est un projet, pas une tâche. Décomposez-la.)
Limites WIP
La colonne En cours du diagramme affiche une limite WIP : 3. Cela signifie que pas plus de trois cartes ne peuvent être En cours en même temps. Si vous voulez tirer une quatrième carte, vous devez en terminer une d'abord.
Cela semble une contrainte. C'en est une : par conception. Les limites WIP vous forcent à terminer ce que vous avez commencé avant de commencer quelque chose de nouveau. Plus à ce sujet dans une section ultérieure.
Délimiter les cartes de travail
La compétence la plus difficile en kanban n'est pas de dessiner le tableau. C'est de délimiter les cartes. Trop grande et une carte reste En cours pendant des semaines, bloquant d'autres travaux. Trop petite et le tableau se remplit de bruit.
Les silos fonctionnent bien
Toute opération multidisciplinaire a des centres de travail fonctionnels : une boulangerie a les pâtisseries, le pain, les savoureux, et le comptoir avant. Un studio de produits a le design, le contenu, la construction, et les ops. Un projet de construction a la charpente, la plomberie, l'électricité, et la finition. Ces centres existent pour de bonnes raisons : la spécialisation profonde exige une propriété focalisée.
Kanban ne dissout pas ces divisions. Il rend les transferts entre eux visibles et explicites.
La carte de transfert
Quand une unité de travail se déplace d'un centre de travail à un autre, disons, un actif de design qui a besoin de copie écrite avant que le constructeur ne puisse assembler la page, une carte de transfert voyage avec lui. Le centre aval voit la carte apparaître dans leur Arriéré. Ils la tirent quand ils ont de la capacité. Pas de courriel nécessaire. Pas de réunion pour coordonner. La carte est le signal.
Ce que le diagramme montre
Le billet ★ commence en Design (En cours : actifs visuels). Quand Design termine sa partie, une carte de transfert est créée et le billet ★ apparaît dans l'Arriéré du centre Build. Build le tire. Ensuite Ops le tire. Chaque centre a son propre tableau. Chaque tableau montre seulement le travail courant de ce centre. Mais le ★ voyage à travers tous, et tout le monde peut voir où il se trouve.
C'est l'intuition du supermarché appliquée aux organisations : chaque centre de travail est une étagère. Les cartes réapprovisionnent les étagères en aval seulement quand le travail en amont est tiré et consommé.
Concevoir un transfert
La carte de transfert est le contrat entre les centres de travail. Elle doit contenir suffisamment de contexte pour que l'équipe réceptrice agisse sans réunion.
Arrêtez de commencer. Commencez à terminer.
WIP signifie Travail en cours. Une limite WIP est un plafond sur le nombre de cartes qui peuvent se trouver dans une colonne donnée à la fois.
Cela semble une restriction. C'en est une. C'est le point.
Pourquoi les limites aident
Chaque fois que vous commencez une nouvelle tâche sans terminer la précédente, vous payez une taxe de changement de contexte. Votre cerveau charge le contexte de la nouvelle tâche et décharge partiellement l'ancienne. Quand vous revenez à l'ancienne tâche, vous la rechargez. Pour le travail de connaissance, l'écriture, le débogage, la conception, la révision, ce coût de rechargement se mesure en heures, pas en secondes.
Les limites WIP empêchent l'accumulation de travaux inachevés. Elles font aussi quelque chose de plus précieux : elles font surface les goulots d'étranglement.
Les goulots deviennent visibles
Si la colonne Révision a une limite WIP de 2 et qu'elle y est toujours, c'est un signal : la révision est plus lente que la production. Plus de travail se termine En cours que la Révision ne peut consommer. Sans une limite WIP, le tableau se remplit de cartes « terminée-mais-en-attente-de-révision » et le goulot est invisible. Avec une limite WIP, la colonne En cours ne peut pas accepter de nouvelles cartes, et toute l'équipe voit la contrainte.
Ce n'est pas un échec. C'est de l'information. Le système vous dit de corriger la Révision, d'embaucher, de faire du jumelage, de réduire la taille du lot, plutôt que de pousser aveuglément plus de travail à travers.
Loi de Little (informellement)
Le délai (combien de temps une carte prend du début à la fin) = Travail en cours ÷ Débit (cartes terminées par unité de temps). Si vous voulez des délais plus courts sans embaucher, réduisez le WIP. Moins de choses en vol signifie que chaque chose se termine plus vite.
R = (W × C) + T
Les limites WIP protègent trois variables. L'expert en efficacité Brian Tracy les a nommées en 1986.
R = (W × C) + T
- R : Résultat : le résultat que vous voulez
- W : Clarté de l'objectif : comment précisément vous savez ce que vous voulez (0–10)
- C : Concentration : intensité d'effort focalisé (0–10)
- T : Temps travaillé sans distractions (heures ininterrompues)
Pourquoi W et C se multiplient
La clarté et la concentration ne sont pas indépendantes. Une concentration élevée sur un objectif vague produit un mouvement rapide dans la mauvaise direction. Une clarté d'objectif parfaite sans concentration ne produit rien. Elles interagissent : c'est pourquoi Tracy les a écrites comme un produit, pas une somme. Un 9/10 sur chacun donne R = 81 + T. Un 3/10 sur chacun donne R = 9 + T. La différence n'est pas additive.
Pourquoi T s'additionne
Chaque heure sans distraction ajoute linéairement au résultat. T ne peut pas composer W et C : il ne peut que s'empiler sur le produit. Cela explique pourquoi le premier mouvement consiste toujours à améliorer W et C, pas à travailler plus longtemps. Plus de T sur un produit (W × C) faible est toujours un mauvais résultat.
Ce que le tableau kanban fait pour chaque variable
- W : Une carte bien délimitée (titre clair, critères d'acceptation mesurables, propriétaire unique) élève W avant que le travail ne commence. Les cartes vagues l'abaissent automatiquement.
- C : Les limites WIP forcent la concentration. Une carte en Actif signifie toute l'attention sur un problème. Trois cartes en Actif signifie que C est divisé en trois.
- T : Les blocs Pomodoro et la protection du calendrier créent les heures sans distraction que T mesure. Le minuteur du tableau n'est pas une décoration : il suit T en temps réel.
Tracy a affirmé que n'importe quel problème pouvait être résolu en 30 minutes quand W, C, et T sont tous optimisés. Le tableau kanban est l'instrument pour optimiser les trois simultanément.
Lire le tableau
Pratique la lecture des goulots d'étranglement à partir de l'état du tableau.
Ni Agile. Ni Cascade.
Agile est une méthodologie. Cascade est une méthodologie. Kanban est un système.
Les méthodologies prescrivent comment vous travaillez. Les systèmes décrivent ce qui est vrai du travail. Kanban ne vous dit pas d'avoir des sprints de deux semaines, des réunions debout quotidiennes, ou des rétrospectives. Il vous dit une chose : rendre le travail visible, limiter le WIP, et tirer.
Le problème avec les méthodologies
Agile fonctionne bien pour les équipes construisant des produits de manière itérative, le logiciel, surtout. Cascade fonctionne bien pour les projets avec des exigences fixes et des inconnues connues, la construction, la fabrication matérielle. Aucun ne s'adapte proprement au travail multidisciplinaire où une tâche de design et une tâche de traitement ont des cycles complètement différents et des définitions de « terminé ».
Forcer un centre de conception et un centre d'ops dans le même rythme de sprint est une erreur de catégorie. Un sprint de deux semaines qui fonctionne pour la création de contenu produit une urgence artificielle dans le travail logistique. Un rituel de réunion debout construit pour les équipes co-localisées crée des frais généraux pour les solos indépendants.
Trouvez un terrain d'entente sur le travail à faire
L'approche un : trouvez le travail qui doit être fait. Trouvez les personnes ou les partenaires les mieux positionnés pour le faire. N'imposez pas un processus sur cela : laissez le travail faire émerger son propre processus via un système de visibilité partagée.
Ce n'est pas l'absence de processus. C'est le bon montant de processus : assez pour coordonner, pas assez pour créer une surcharge de coordination qui dépasse la valeur du travail.
Ne construisez pas ce que vous pouvez acheter. N'achetez pas ce que vous pouvez cultiver.
Avant la création de toute carte de travail, demandez-vous : cela devrait-il exister du tout ? Chaque morceau de travail que vous construisez, vous le possédez à jamais. Chaque SaaS auquel vous vous abonnez, vous en dépendez à jamais. Chaque dépendance open-source que vous forkez, vous la maintenez à jamais.
L'arbre de décision : Pouvons-nous cultiver cela ? Un processus, une compétence, une relation qui produit la capacité de façon durable, préférez cela. Si cultiver n'est pas viable : Pouvons-nous acheter cela ? Un outil prêt à l'emploi qui résout 80 % du problème sans travail personnalisé, préférez cela. Si l'achat n'est pas viable : Construisez-le. Et construisez-le en sachant que vous en êtes maintenant propriétaire.
La plupart des organisations inversent cet ordre. Ils construisent une infrastructure personnalisée pour les problèmes que les outils de commodité résolvent bien, puis se démènent pour maintenir ce qu'ils ont construit. Kanban rend cela visible : chaque carte de votre Arriéré est une chose que vous avez choisie de construire. La question honnête est de savoir si elle devrait y être du tout.
Construire / Acheter / Cultiver
Appliquez le cadre de décision.
Concevoir un tableau
Assemblez-le. Vous allez concevoir un système kanban pour un scénario multidisciplinaire spécifique.
Scénario
Un petit studio relance son produit avec une nouvelle marque. Le travail implique quatre centres :
- Design : nouveau logo, identité visuelle, photographie de produit, mises en page
- Contenu : descriptions de produit réécrites, texte de page d'accueil, annonce par e-mail
- Build : site Web mis à jour, nouveau flux de paiement, redirections des anciennes URL
- Ops : paramètres de processeur de paiement mis à jour, briefing du partenaire de traitement, reconfiguration analytique
Le relancement a une date limite dure : un salon commercial dans 45 jours où la nouvelle marque est rendue publique.
Les solos restent silos
Dans la plupart des organisations, kanban existe pour rendre le travail visible à travers une hiérarchie de gestion. Les gestionnaires coordonnent entre les silos. Kanban réduit la surcharge de coordination.
Dans le modèle un, il n'y a pas de gestionnaires. Il y a des solos. Un solo dirige une entreprise indépendamment : un designer solo, un builder solo, un writer solo, un ops solo. Chaque solo est, par définition, un silo. Il n'y a pas d'organigramme les reliant. Aucune relation de rapport. Aucun gestionnaire pour forcer la coordination.
Kanban devient la couche de coordination. Non pas en aplatissant les silos, les solos restent complètement indépendants, mais en rendant les transferts entre eux visibles et explicites. Un solo n'envoie pas un e-mail ou ne programme pas une réunion pour remettre du travail. Il met une carte sur un tableau partagé. Le solo récepteur la tire quand il a de la capacité.
Cela explique pourquoi kanban s'adapte mieux au modèle un qu'agile ou cascade : cela ne nécessite pas de cadence partagée, pas de rétros conjointes, pas de planification synchronisée. Chaque solo définit ses propres limites WIP, son propre temps de cycle, sa propre définition de « terminé ». La coordination se fait au niveau de la carte, pas au niveau du processus.