Qu'est-ce que Kanban ?
Kanban est une méthode agile de gestion de projet qui rend le travail visible sur un tableau divisé en colonnes correspondant aux étapes d'un flux, de « à faire » à « terminé ». Chaque tâche est une carte qui avance d'une colonne à la suivante. La règle qui fait tout tenir : limiter le nombre de tâches en cours en même temps, pour que le travail circule, sans imposer d'itérations fixes.
Le mot « kanban » est japonais et signifie à peu près « panneau visuel » ou « étiquette ». La méthode vient des usines Toyota, où des cartes circulaient pour signaler qu'un poste avait besoin d'être réapprovisionné. Le développement logiciel, puis la gestion de projet, l'ont reprise en remplaçant les pièces par des tâches. La logique reste celle de l'usine : on ne produit que ce que le poste suivant est prêt à absorber.
Kanban repose sur trois idées fortes : visualiser le travail pour que chacun voie où en est chaque tâche, limiter le travail en cours pour éviter de tout commencer sans rien finir, et fluidifier le passage des tâches d'une étape à l'autre. C'est l'une des grandes déclinaisons concrètes de la méthode agile, aux côtés de Scrum, mais elle est bien plus légère : aucun rôle, aucune cérémonie imposée. On peut la poser sur un fonctionnement existant sans le bouleverser.
Le tableau Kanban et ses colonnes
Le tableau Kanban est un panneau divisé en colonnes verticales qui représentent les étapes du travail, le plus souvent « à faire », « en cours » et « terminé ». Chaque tâche est une carte que l'on déplace de gauche à droite au fur et à mesure de sa progression. D'un coup d'œil, toute l'équipe voit ce qui reste à faire, ce qui avance et ce qui est fini.
C'est le cœur visible de la méthode. Un tableau minimal tient en trois colonnes, mais rien n'oblige à s'y limiter : une équipe de développement ajoutera souvent des étapes intermédiaires comme « en revue », « en test » ou « prêt à déployer ». L'important est que les colonnes reflètent votre vrai processus, pas un modèle théorique. Si une tâche passe systématiquement par une validation, cette validation mérite sa colonne.
Chaque carte porte une unité de travail : une fonctionnalité, un ticket, une demande, avec la personne qui s'en occupe et parfois une échéance. Le mouvement des cartes raconte le projet en temps réel. Une carte qui stagne dans « en cours » saute aux yeux. Le tableau est fait pour ça : montrer ce qui coince avant que le retard ne s'installe.
| Colonne | Ce qu'elle contient |
|---|---|
| À faire | Les tâches priorisées, prêtes à être prises. Le haut de la colonne est ce qui compte le plus. |
| En cours | Les tâches sur lesquelles quelqu'un travaille réellement en ce moment. Colonne soumise à une limite. |
| Terminé | Les tâches finies selon un critère clair de « terminé », livrables et validées. |
La limite d'en-cours (WIP)
La limite d'en-cours, ou WIP pour « Work In Progress », est le nombre maximum de tâches autorisées dans une colonne à un instant donné. Quand la colonne est pleine, on ne peut plus y ajouter de tâche : il faut d'abord en terminer une. C'est le mécanisme qui empêche l'équipe de tout commencer sans rien finir et qui révèle les goulots d'étranglement.
C'est la règle la plus contre-intuitive de Kanban, et la plus puissante. Notre réflexe naturel est de démarrer beaucoup de choses en parallèle pour « avancer partout ». En réalité, plus on ouvre de tâches en même temps, plus chacune traîne, car l'attention se disperse et les tâches s'attendent les unes les autres. Limiter l'en-cours force l'équipe à finir avant de commencer.
On inscrit un chiffre en haut d'une colonne, par exemple « En cours (3) ». Si trois tâches y sont déjà, personne n'en tire une nouvelle depuis « à faire » tant qu'une n'est pas passée à l'étape suivante. Cette contrainte a un effet secondaire précieux : dès qu'une colonne bloque en amont parce que la suivante est saturée, le goulot d'étranglement devient visible. On sait alors où porter l'effort. D'après mon expérience, c'est souvent ce simple chiffre qui transforme un tableau décoratif en véritable outil de pilotage.
Un flux continu plutôt que des itérations
Kanban fonctionne en flux continu : chaque tâche est livrée dès qu'elle est prête, sans attendre la fin d'un cycle. Il n'y a pas de sprint à durée fixe. On peut ajouter, réordonner ou retirer une tâche à tout moment. C'est ce qui distingue le plus nettement Kanban des méthodes cadencées comme Scrum, qui travaillent par itérations.
Dans une méthode itérative, on planifie un lot de travail pour une durée fixe, on l'exécute, puis on livre à la fin. Kanban ne raisonne pas par lots mais par écoulement : une tâche entre, traverse le tableau, sort. Le rythme n'est pas imposé par un calendrier, il émerge de la capacité réelle de l'équipe à faire circuler les cartes.
Cette absence d'itérations rend Kanban très souple face au changement. Une priorité qui tombe le mardi passe en tête de la colonne « à faire » et sera prise dès qu'une place se libère, sans casser un engagement de sprint. En contrepartie, Kanban offre moins de rythme naturel : pas de revue ni de rétrospective imposée. Les équipes matures s'en donnent quand même, mais la méthode ne les prescrit pas. Pour mesurer la performance, on suit des indicateurs de flux comme le temps de cycle, le temps qu'une tâche met à traverser le tableau, plutôt qu'une vélocité par sprint.
Kanban ou Scrum : quelle différence ?
Scrum organise le travail en sprints à durée fixe, avec des rôles définis et un engagement par cycle. Kanban fonctionne en flux continu, sans sprints ni rôles imposés. Scrum convient à un produit qui se construit par lots planifiés ; Kanban à un flux de demandes qui arrive en permanence. La différence n'est pas de qualité mais de rythme de travail.
Les deux sont des cadres agiles, mais ils répondent à des situations différentes. Scrum apporte une cadence forte et un cérémonial complet : sprints, product owner, scrum master, revue, rétrospective. Cela structure très bien la construction d'un produit avec une feuille de route. Kanban, lui, se contente de visualiser un flux et d'en limiter l'en-cours. Il s'adapte à une réalité où les demandes tombent sans prévenir.
| Critère | Kanban | Scrum |
|---|---|---|
| Rythme | Flux continu, sans cycle fixe | Sprints à durée fixe |
| Rôles | Aucun rôle imposé | Product owner, scrum master, équipe |
| Changement | À tout moment | Entre deux sprints |
| Mesure | Temps de cycle, débit | Vélocité par sprint |
Aucun des deux n'est « meilleur ». Une équipe qui construit un produit neuf se sentira bien en sprints ; une équipe de support noyée sous les tickets étouffera dans Scrum et respirera en Kanban. Beaucoup de contextes hybrident d'ailleurs les deux. Si vous hésitez, je détaille le fonctionnement complet de l'autre cadre dans mon guide sur le framework Scrum, ce qui aide à trancher selon la nature réelle de votre travail.
Pour quels projets choisir Kanban
Kanban est adapté aux équipes qui absorbent un flux continu de demandes : support, maintenance, exploitation, marketing, ou toute activité où les priorités changent souvent. Il convient aussi à une équipe qui veut plus de visibilité sans adopter tout le cérémonial de Scrum. Un produit neuf avec une feuille de route claire se prête souvent mieux à des sprints.
Kanban brille dans ces situations :
- Une équipe de maintenance ou de support qui traite un flot imprévisible de tickets et ne peut pas figer un lot de travail à l'avance.
- Une activité aux priorités mouvantes, où l'urgence du jour doit pouvoir passer devant sans casser un engagement.
- Une équipe qui débute en agilité et veut un premier pas simple, sans rôles ni rituels à apprendre. Kanban se pose sur l'existant.
- Un besoin de rendre le travail visible à une direction ou à des parties prenantes, pour montrer sans réunion ce qui avance et ce qui bloque.
À l'inverse, si votre projet a une vision produit forte, une feuille de route et le besoin d'un rythme de livraison régulier avec des points d'étape, Scrum donnera souvent plus de traction. Le tableau Kanban peut alors compléter la démarche, sans en être le cœur. Et quand le pilotage devient trop lourd à porter en interne, il est parfois plus sain de le confier à un tiers, comme je l'explique à propos de l'externalisation du pilotage de projet.
Les outils pour faire du Kanban
Un simple tableau blanc avec des post-it suffit pour démarrer en Kanban. En numérique, des outils comme Trello, Jira, Asana ou GitHub Projects proposent des tableaux avec des colonnes et des cartes que l'on déplace. Le choix dépend de la taille de l'équipe et du besoin de suivi. L'outil compte moins que la discipline de respecter les limites d'en-cours.
Je le dis souvent : le meilleur outil Kanban est celui que l'équipe regarde vraiment tous les jours. Un tableau physique dans une salle a un avantage réel, il est sous les yeux de tous et personne ne peut l'ignorer. Il montre vite ses limites dès que l'équipe est distribuée ou que l'on veut mesurer le temps de cycle.
Côté numérique, Trello est le plus immédiat pour un tableau simple. Jira s'adresse à des équipes techniques qui veulent lier le tableau à leur suivi de développement. Asana et GitHub Projects couvrent d'autres contextes, gestion transverse pour l'une, projets liés au code pour l'autre. Tous partagent la même mécanique, des colonnes et des cartes à faire glisser, et permettent de poser une limite d'en-cours. Ne surinvestissez pas dans l'outil au départ : commencez simple, et faites-le évoluer une fois la méthode ancrée dans les habitudes.
Ce que je regarde en premier sur un tableau Kanban.
Quand j'arrive sur une équipe qui « fait du Kanban », je ne regarde pas les colonnes, je regarde les limites d'en-cours. Neuf fois sur dix, elles n'existent pas, et le tableau n'est qu'une jolie liste de tâches en cours qui grossit sans fin. Poser une limite est inconfortable au début, car il faut assumer de dire non à un nouveau démarrage. Mais c'est exactement là que Kanban devient un outil de pilotage et cesse d'être une décoration. Je préfère un tableau à trois colonnes qu'on respecte à un tableau à dix colonnes que personne ne tient.
