Kanban : gérer le travail par le flux, pas par les sprints
Kanban est une méthode de gestion visuelle du travail : chaque tâche devient une carte sur un tableau à colonnes représentant les étapes du processus, et l'équipe limite volontairement le nombre de tâches en cours (limites WIP). Née du système de production Toyota conçu par Taiichi Ohno, elle a été adaptée au travail logiciel par David J. Anderson à la fin des années 2000.
Comment ça marche, étape par étape
1. Visualiser le flux de travail existant
On part du processus RÉEL, sans le réorganiser : chaque étape devient une colonne (par exemple « À faire », « Développement », « Relecture », « Terminé »), chaque demande devient une carte. Cette photographie honnête suffit souvent à révéler où le travail s'accumule — c'est le point de départ de la méthode, pas une réorganisation imposée.
2. Limiter le travail en cours (limites WIP)
Chaque colonne reçoit un plafond : par exemple, pas plus de trois cartes en « Développement » simultanément. Quand une colonne est pleine, personne ne démarre de nouvelle tâche — on aide à terminer celles qui bloquent. C'est LA règle centrale de Kanban : arrêter de commencer, commencer à terminer.
3. Gérer et mesurer le flux
L'équipe suit le temps de traversée d'une carte (lead time et temps de cycle) et observe le diagramme de flux cumulé pour repérer les goulots d'étranglement. Les décisions d'amélioration s'appuient sur ces mesures, pas sur des impressions.
4. Expliciter les règles et s'améliorer en continu
Les critères de passage d'une colonne à l'autre sont écrits et visibles (« une carte entre en Relecture quand les tests passent »). Des points de synchronisation réguliers servent à ajuster les limites WIP et les règles. Kanban est une méthode d'amélioration évolutive : on change le système par petites touches, jamais par big bang.
Quand l'utiliser
- Flux continu de demandes entrantes : maintenance applicative, support technique, tickets d'exploitation.
- Équipe qui subit trop de multitâche et veut réduire les changements de contexte sans tout réorganiser.
- Contexte où les priorités changent trop vite pour s'engager sur un périmètre de sprint figé.
Limites à connaître
- Sans discipline sur les limites WIP, un tableau Kanban n'est qu'une liste de tâches décorative : la visualisation seule n'améliore rien.
- Kanban ne fournit ni rôles ni cadence de livraison imposée : une équipe qui a besoin d'un rythme structurant (objectif d'itération, revue régulière) sera mieux servie par Scrum.
- La méthode optimise un flux existant ; si le processus lui-même est mauvais, elle le rendra visible mais ne le redessinera pas à votre place.
Exemple concret
Une équipe de quatre personnes maintient les applications internes d'une PME : correctifs, petites évolutions et demandes urgentes arrivent en continu, sans périmètre prévisible.
L'équipe matérialise son flux en cinq colonnes et fixe une limite WIP de trois en « Développement » et de deux en « Relecture ». Première découverte : huit tâches traînaient en relecture depuis des semaines, personne n'en avait la responsabilité. La règle devient « toute carte en relecture est traitée avant de tirer une nouvelle carte ». En mesurant le temps de cycle, l'équipe constate qu'une demande met en moyenne neuf jours à traverser le tableau ; deux mois plus tard, après resserrage des limites, ce délai tombe à quatre jours et les demandes urgentes passent par une voie dédiée limitée à une carte. Aucune réunion supplémentaire n'a été ajoutée : seules la visibilité et les limites ont changé le comportement.
Questions fréquentes
Quelle est la différence entre Kanban et un simple tableau de tâches ?
Les limites WIP. Un tableau de tâches classique visualise le travail sans contraindre la quantité en cours ; Kanban plafonne chaque colonne, ce qui force à terminer avant de commencer et fait remonter les goulots d'étranglement. Sans limites, on a l'outil mais pas la méthode.
D'où vient la méthode Kanban ?
Du système de production Toyota : Taiichi Ohno utilisait des cartes physiques (kanban signifie « panneau » ou « étiquette » en japonais) pour piloter la production en flux tiré. David J. Anderson a adapté ces principes au développement logiciel et au travail intellectuel, formalisés dans son ouvrage de 2010.
Peut-on combiner Kanban et Scrum ?
Oui — beaucoup d'équipes ajoutent des limites WIP et la mesure du flux à leur cadre Scrum (approche parfois appelée Scrumban). Scrum apporte la cadence et les rôles, Kanban la gestion du flux : les deux ne s'excluent pas.
Comment valoriser Kanban sur un CV ?
Par les résultats de flux, pas par le mot-clé : « mise en place de limites WIP et réduction du temps de cycle de 9 à 4 jours » est bien plus parlant que « Kanban » dans une liste. En entretien, attendez-vous à des questions sur les métriques que vous suiviez et sur un goulot d'étranglement que vous avez résolu concrètement.