Exécuter & améliorer · Méthode + outil interactif
Kanban : visualiser le travail et améliorer les flux opérationnels
Quand tout le monde est débordé et que les projets n'avancent pas, le réflexe est de pousser plus fort. Le Kanban propose l'inverse : rendre le travail visible, commencer moins, et finir davantage.
12 sujets ouverts en même temps
Tout avance, rien ne sort
4 sujets ouverts, limite respectée
Moins commencé, plus terminé
À quoi sert le Kanban ?
Dans une PME qui mène plusieurs projets clients à la fois, le travail en cours est souvent invisible. Il est dispersé dans les boîtes mail, les têtes et les fichiers de suivi. Chacun a l'impression d'être occupé à 120 %, les délais s'allongent, et personne ne sait dire où le travail bloque.
Le Kanban répond à trois questions simples : qu'est-ce qui est en cours, où est-ce que ça coince, et combien de temps faut-il pour qu'un sujet aille du début à la fin. La méthode vient du système de production de Toyota, où Taiichi Ohno utilisait des cartes pour ne produire que ce que l'étape suivante demandait. David J. Anderson l'a adaptée au travail de bureau et aux projets dans Kanban (2010).
Les principes, en clair
Visualiser le flux
Chaque colonne correspond à une étape réelle du travail, telle qu'elle se passe aujourd'hui, pas telle qu'elle devrait se passer. Chaque carte est un élément de travail livrable : un dossier, une commande, un livrable client.
Limiter le travail en cours
Chaque colonne a une limite, dite limite WIP. Quand elle est atteinte, on ne fait plus entrer de carte : on aide à terminer celles qui y sont. C'est la règle qui change tout, et celle qu'on abandonne le plus vite.
Tirer plutôt que pousser
En flux poussé, chacun transmet son travail dès qu'il a fini, que l'étape suivante soit prête ou non. En flux tiré, c'est l'étape suivante qui prend une carte quand elle a de la place. Les files d'attente cachées disparaissent.
Repérer les goulots
Le goulot d'étranglement est l'étape qui limite la vitesse de tout le flux. Sur un tableau, il se voit : sa colonne est pleine, celle d'après est vide. Accélérer ailleurs ne sert à rien tant qu'il n'est pas traité.
Kanban ou simple liste de tâches ?
| Liste de tâches | Kanban | |
|---|---|---|
| Ce qu'on voit | Ce qu'il reste à faire | Où en est chaque sujet |
| Encours | Illimité, souvent invisible | Plafonné par étape |
| Blocages | Découverts en retard | Visibles dès qu'une colonne sature |
| Question posée | Qu'est-ce que je fais ensuite ? | Qu'est-ce qu'on peut finir ensemble ? |
Débit, temps de cycle et encours
Encours
Nombre de cartes démarrées et non terminées à un instant donné.
Débit
Nombre de cartes terminées par période, par exemple par semaine.
Temps de cycle
Temps entre le démarrage d'une carte et sa fin. C'est le délai réel vu par le client.
Les trois sont liés par la loi de Little, issue de la théorie des files d'attente (John Little, 1961) : en régime stable, temps de cycle moyen = encours moyen / débit. Avec 12 dossiers en cours et 3 dossiers terminés par semaine, chaque dossier met en moyenne 4 semaines. Ramener l'encours à 6 sans changer l'équipe ramène le délai vers 2 semaines. C'est une moyenne, pas une promesse : elle suppose un flux à peu près régulier.
Mettre en place un Kanban en quatre temps
Cartographier les étapes réelles.
Avec l'équipe, suivez deux ou trois dossiers récents du début à la fin. Gardez 4 à 6 colonnes, pas plus.
Mettre tout le travail en cours sur le tableau.
Tout, y compris les petites demandes urgentes. Le premier choc est souvent de voir le volume réel.
Poser des limites, puis les tenir.
Commencez par une limite proche du nombre de personnes par étape. La règle : quand une colonne est pleine, on aide en aval au lieu de commencer autre chose.
Faire un point court devant le tableau.
Quinze minutes, de droite à gauche : qu'est-ce qui est presque fini, qu'est-ce qui bloque, qui a besoin d'aide. Une fois par mois, on regarde les indicateurs et on ajuste.
Exemple : une agence qui mène plusieurs projets clients
Exemple fictif, construit pour illustrer la méthode. C'est celui préchargé dans l'outil.
Une agence de 12 personnes produit des livrables pour six clients en parallèle : catalogues, tableaux de bord, supports de formation. Le dirigeant constate que les projets traînent alors que l'équipe est surchargée. Il pose un tableau en cinq colonnes : à faire, cadrage, réalisation, validation client, terminé.
Le tableau montre tout de suite que la colonne « Validation client » contient trois livrables pour une limite de deux, certains depuis plus de dix jours, alors que l'équipe continue d'en lancer de nouveaux. Le goulot n'est pas la production : ce sont les retours clients. Plutôt que de recruter, l'agence fixe une date de validation dès le lancement de chaque livrable et désigne un responsable de la relance. La colonne « Réalisation » se vide, l'équipe arrête de jongler entre six sujets.
Tableau Kanban interactif
Déplacez les cartes, dépassez une limite, regardez le goulot et les indicateurs réagir. Volontairement simple : c'est un outil pour comprendre et démarrer, pas un logiciel de gestion de projet.
Déplacez les cartes avec les flèches ou par glisser-déposer
- Encours
- 7
- cartes démarrées, non terminées
- Débit
- 3
- cartes terminées sur 7 jours
- Temps de cycle moyen
- 8 j
- du démarrage à la fin
- Goulot probable
- Validation client
- colonne la plus saturée
À faire
2File d'attente, sans limite
Refonte du catalogue produits
Client A
Campagne salon professionnel
Client D
Cadrage
1 / 21 place libre
Audit des processus achats
Client B · 4 j en cours
Réalisation
3 / 3Pleine : finir avant d'entrer
Tableau de bord commercial
Client C · 9 j en cours
Site de recrutement
Client A · 6 j en cours
Migration des données CRM
Client E · 3 j en cours
Validation client
3 / 2Goulot probable
Supports de formation
Client B · 12 j en cours
Charte éditoriale
Client C · 10 j en cours
Note de cadrage stratégique
Client F · 8 j en cours
Terminé
3Sortie du flux
Fiches produits
Client D
Plan d'intégration
Client E
Kit de présentation
Client A
Une carte démarre quand elle quitte la première colonne et se termine en entrant dans la dernière. Le tableau reste dans ce navigateur uniquement.
Les erreurs à éviter
- Un tableau sans limites. Sans limite WIP, c'est une liste de tâches en colonnes. Utile pour voir, inutile pour améliorer.
- Contourner la limite « juste cette fois ». Une exception par semaine suffit à revenir au point de départ. Si la limite gêne tout le temps, changez-la, ne l'ignorez pas.
- Des colonnes idéales. Un tableau qui décrit le processus souhaité plutôt que le réel masque précisément les blocages qu'on cherche.
- Des cartes trop grosses. « Projet client A » ne bouge pas pendant trois mois. Découpez en livrables qui avancent en quelques jours.
- Surveiller les personnes. Le Kanban rend le flux visible, pas la productivité individuelle. Utilisé comme outil de contrôle, il est vite contourné.
- Oublier les demandes cachées. Les petites urgences hors tableau consomment la capacité sans apparaître. Elles doivent avoir leur carte, ou leur couloir dédié.
Limites de la méthode
Le Kanban améliore un flux existant ; il ne dit pas quoi prioriser ni quelle stratégie suivre. Il convient mal aux travaux uniques et très longs sans étapes répétables. Il demande enfin une discipline collective : sans point régulier devant le tableau, il se périme en quelques semaines.
Le regard Odessia
Le tableau ne sert à rien si la direction ne tient pas la limite
La première personne à contourner une limite WIP est souvent le dirigeant lui-même : un client important appelle, un sujet urgent arrive, et on le glisse en cours « en plus ». Le tableau perd alors sa crédibilité en une semaine.
La bonne réponse n'est pas l'interdiction, c'est l'arbitrage visible : si ce sujet entre, lequel sort ou attend ? Poser cette question à voix haute, devant le tableau, est probablement l'effet le plus utile du Kanban pour une équipe de direction.
Pour aller plus loin
- Méthode des 4D : décider ce qui entre dans le flux
- Matrice RACI : qui valide à chaque étape
- CODIR efficace : arbitrer les priorités entre équipes
- COO à temps partagé : fluidifier l'exécution
- Toutes les ressources pour dirigeants
Références : Taiichi Ohno, Toyota Production System, 1978 (trad. anglaise 1988) ; David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, 2010 ; John D. C. Little, « A Proof for the Queuing Formula: L = λW », Operations Research, 1961.
Vos équipes sont débordées et les projets n'avancent pas ? Regardons ensemble où le flux bloque.
Réserver un échange