Qu’est-ce que Kanban ?
Kanban est une méthode de gestion du travail fondée sur deux règles : rendre le flux visible et limiter le nombre de tâches en cours. Chaque demande devient une carte qui progresse de colonne en colonne, et une équipe ne démarre une nouvelle tâche que lorsqu’une place se libère.
Le mot vient du japonais et désigne une carte ou un panneau de signalisation. Le système a été mis au point chez Toyota par Taiichi Ohno, qui s’est inspiré du réapprovisionnement des supermarchés : on ne produit pas à l’avance, on réapprovisionne ce qui vient d’être consommé. C’est un fonctionnement en flux tiré.
La transposition au travail intellectuel est plus récente. David J. Anderson en a formalisé la méthode dans les années 2000, en l’appliquant à des équipes informatiques plutôt qu’à des lignes de production.
Les six pratiques de la méthode Kanban
- Visualiser le flux de travail, y compris les étapes d’attente que personne ne mesure d’habitude.
- Limiter le travail en cours en fixant un plafond par colonne. C’est la pratique la plus efficace et la plus souvent abandonnée.
- Gérer le flux : surveiller les temps d’attente et les blocages plutôt que l’occupation des personnes.
- Expliciter les règles : écrire ce que signifie « terminé » pour chaque colonne, plutôt que de le laisser à l’appréciation de chacun.
- Mettre en place des boucles de rétroaction : points quotidiens sur le tableau, revues de livraison, revues du système à intervalle régulier.
- S’améliorer de façon collaborative et expérimentale, en testant un changement à la fois et en observant son effet sur le flux.
La méthode se veut évolutive plutôt que prescriptive : elle démarre sur l’organisation existante, avec les rôles et les titres en place, et la fait évoluer par petits pas. C’est ce qui explique qu’elle rencontre moins de résistance qu’une bascule vers Scrum.
À quoi sert Kanban ?
Kanban sert d’abord à voir ce qui bloque. Sur un tableau tenu à jour, un regard suffit pour repérer la colonne où les cartes s’accumulent, et il s’agit presque toujours d’une étape d’attente : une validation, une relecture, un retour client.
La deuxième utilité est moins confortable. La méthode rend visible le nombre de sujets commencés et jamais terminés. Beaucoup d’équipes découvrent en posant leurs premières cartes qu’elles ont une trentaine de dossiers ouverts pour six personnes.
Le champ d’application est large parce que la méthode ne présuppose rien du contenu du travail. Elle fonctionne sur un flux de tickets d’incident comme sur des dossiers administratifs, des contenus éditoriaux ou des recrutements.
Là où elle apporte le moins, c’est sur un travail réellement séquentiel et prévisible, aux étapes figées et sans concurrence entre les demandes. Le tableau devient alors un affichage, sans effet mesurable sur les délais.
Comment fonctionne Kanban ?
La méthode utilise un tableau divisé en colonnes. Chaque colonne représente une étape du processus : « à faire », « en cours », « terminé ». Les équipes matures en ajoutent une pour chaque attente réelle, relecture ou validation comprise.
Le réglage déterminant est la limite de travail en cours, ou WIP pour work in progress. Fixer un plafond de trois tâches dans la colonne « en cours » pour quatre développeurs paraît contre-intuitif ; c’est pourtant ce qui force à terminer avant de commencer et fait chuter les délais.
Quand une colonne est pleine, personne ne tire de nouvelle carte. L’équipe va aider là où ça bloque. Sans cette limite, un tableau Kanban n’est qu’une liste de tâches colorée, et la plupart des équipes qui déclarent « faire du Kanban » s’arrêtent à ce stade.
Les points quotidiens se tiennent devant le tableau et se lisent de droite à gauche, en partant de ce qui est le plus proche de la livraison. On y parle des cartes bloquées, pas de ce que chacun a fait la veille.
Quels indicateurs suivre ?
- Cycle time : durée entre le début effectif du travail sur une tâche et sa livraison.
- Lead time : durée vue par le demandeur, depuis l’arrivée de la demande. C’est celui qui intéresse le client, et il est presque toujours plus long qu’on ne l’imagine.
- Débit : nombre de tâches terminées par semaine. Plus fiable qu’une estimation en points pour prévoir une date.
- Diagramme de flux cumulé : il rend visibles les goulots d’étranglement, une bande qui s’élargit signalant une accumulation.
La loi de Little relie ces mesures : à débit constant, plus il y a de travail en cours, plus le délai de traitement s’allonge. C’est l’argument chiffré à opposer à une direction qui demande de tout lancer en parallèle.
Kanban ou Scrum : quelle différence ?
Scrum découpe le temps en sprints de durée fixe, définit trois responsabilités (product owner, scrum master, développeurs) et un jeu d’événements obligatoires. Kanban n’impose ni itérations, ni rôles, ni cérémonies : le travail circule en continu.
Le critère de choix le plus opérationnel tient à la nature de la demande. Un travail planifiable sur deux semaines s’accommode bien de Scrum. Une activité faite d’arrivées imprévisibles, comme le support, la production ou une équipe infrastructure, supporte mal l’engagement de sprint et fonctionne mieux en Kanban.
Le format hybride, souvent appelé Scrumban, conserve les rituels de Scrum et remplace l’engagement de sprint par des limites de travail en cours. C’est fréquemment le point d’arrivée réel des équipes qui se disent agiles.
Exemples ou cas d’usage concrets
Une équipe de développement traite ses tickets de bug avec un plafond de deux cartes en cours d’analyse. Quand la colonne est pleine, personne ne prend un nouveau ticket : on va aider là où ça coince. Le nombre de corrections par semaine bouge peu, le délai moyen de correction s’effondre.
Une équipe éditoriale suit ses articles de la commande à la publication. La colonne « en relecture » contient en permanence une dizaine de cartes, ce qui explique un délai de publication de six semaines pour un travail de rédaction de deux jours.
Un service support fait cohabiter deux flux sur le même tableau, dans des couloirs distincts : les incidents urgents d’un côté, les demandes de fond de l’autre, chacun avec sa propre limite. Sans cette séparation, l’urgent consomme toute la capacité et le fond n’avance jamais.
Un cabinet de conseil visualise ses missions et découvre que le goulet ne se situe pas chez les consultants, mais à la relecture : une seule associée relit toutes les livraisons. Le constat était impossible à formuler tant que le travail n’était visible nulle part.
Kanban appliqué au recrutement
Un processus de recrutement se prête bien à ce format, parce qu’il s’agit d’un flux : candidatures reçues, préqualification, entretien opérationnel, entretien final, offre. La plupart des ATS proposent d’ailleurs cette vue par défaut.
Deux mesures y sont plus utiles que le nombre de candidatures reçues. Le temps passé dans chaque colonne révèle où les candidats attendent, généralement entre l’entretien technique et le retour du manager. Le nombre de processus ouverts en parallèle par recruteur explique une bonne part des délais : un recruteur qui suit vingt postes rend un feedback en une semaine, le même qui en suit huit répond en deux jours.
Sur un marché où les meilleurs profils reçoivent plusieurs propositions, ce délai de réponse pèse davantage que le contenu de l’annonce.