Kanban

Kanban est une méthode de gestion du travail née dans les usines Toyota dans les années 1950, puis adaptée au développement logiciel par David Anderson en 2007. Le mot japonais signifie « étiquette visuelle », et c’est exactement le principe : rendre le travail visible pour mieux le gérer. Chaque tâche est représentée par une carte qui se déplace sur un tableau, de la colonne « à faire » jusqu’à la colonne « terminé ». Tout le monde voit en un coup d’œil ce qui est en cours, ce qui attend et ce qui bloque.

Ce qui distingue Kanban des autres méthodes agiles, c’est l’absence de cycles fixes. Là où Scrum organise le travail en sprints de durée déterminée, Kanban fonctionne en flux continu : les tâches entrent dans le système au fur et à mesure et en sortent dès qu’elles sont terminées. Cette souplesse en fait une méthode particulièrement adaptée aux équipes qui gèrent un flux de travail imprévisible — support client, maintenance, opérations.

Les principes fondamentaux

Le premier principe est la visualisation du flux de travail. Un tableau Kanban comporte au minimum trois colonnes — « à faire », « en cours », « terminé » — mais la plupart des équipes ajoutent des étapes intermédiaires qui reflètent leur processus réel : relecture, test, déploiement. L’intérêt de cette visualisation est double. Elle permet à chaque membre de l’équipe de comprendre l’état d’avancement global sans poser de questions. Et elle rend les blocages immédiatement visibles : quand des cartes s’accumulent dans une colonne, c’est le signe d’un goulot d’étranglement qui mérite attention.

Le deuxième principe est la limitation du travail en cours. C’est l’idée la plus contre-intuitive de Kanban, et aussi la plus puissante. Chaque colonne du tableau a un nombre maximum de cartes autorisées. Si la colonne « en cours » est limitée à trois tâches, personne ne peut en démarrer une quatrième tant qu’une des trois n’est pas terminée. Cette contrainte force l’équipe à finir ce qui est commencé avant d’entamer quelque chose de nouveau. Le résultat est paradoxal : en limitant ce qu’on fait en parallèle, on livre plus vite, parce que chaque tâche reçoit l’attention qu’elle mérite au lieu d’être diluée entre dix chantiers simultanés.

Le troisième principe est la gestion du flux. L’objectif n’est pas de remplir le tableau de cartes, mais de faire circuler les cartes le plus fluidement possible d’un bout à l’autre. La mesure clé est le temps de cycle : combien de jours s’écoulent entre le moment où une tâche passe en « en cours » et le moment où elle est terminée. Réduire ce temps de cycle est l’objectif permanent d’une équipe Kanban.

La différence avec Scrum

Scrum et Kanban sont deux implémentations de la philosophie agile, mais elles répondent à des contextes différents.

Scrum structure le travail en sprints — des cycles de une à quatre semaines pendant lesquels l’équipe s’engage sur un ensemble de tâches définies à l’avance. Cette structure apporte de la prévisibilité et un rythme régulier de livraison. Elle convient bien au développement de fonctionnalités nouvelles, où il est possible de planifier le travail à court terme.

Kanban ne découpe pas le temps en cycles. Le travail arrive en continu, est traité en continu et livré en continu. Cette approche convient aux activités où le flux de travail est imprévisible : les tickets de support arrivent à n’importe quel moment, les correctifs urgents ne peuvent pas attendre la fin d’un sprint, la maintenance ne se planifie pas en itérations.

En pratique, beaucoup d’équipes combinent les deux approches. Elles utilisent les sprints de Scrum pour le développement de nouvelles fonctionnalités et un tableau Kanban pour le support et la maintenance. Cette combinaison permet de bénéficier de la structure de Scrum et de la flexibilité de Kanban.

Ce que Kanban change dans le quotidien d’une équipe

L’effet le plus immédiat est la réduction du nombre de sujets ouverts simultanément. Dans une équipe sans discipline Kanban, il est fréquent de voir chaque développeur jongler entre quatre ou cinq tâches en parallèle. Le résultat est que chaque tâche avance lentement, que les changements de contexte consomment une énergie considérable et que les livraisons s’éternisent. Avec des limites de travail en cours, l’équipe se concentre et les tâches traversent le système plus rapidement.

Le deuxième effet est la transparence sur les blocages. Quand une carte reste immobile dans la colonne « en attente de relecture » pendant trois jours, tout le monde le voit. Cette visibilité crée une pression naturelle pour résoudre les problèmes au lieu de les ignorer. Le point quotidien de l’équipe se transforme : au lieu de demander « qu’as-tu fait hier ? », on demande « qu’est-ce qui bloque le flux ? ».

Le troisième effet est l’amélioration continue. En mesurant régulièrement le temps de cycle et le débit (le nombre de tâches terminées par semaine), l’équipe dispose de KPI objectifs pour évaluer ses progrès. Une hausse du temps de cycle signale un problème — trop de travail en cours, des dépendances externes, un processus de relecture trop lent — et l’équipe peut agir avant que la situation ne se dégrade.

Les erreurs courantes

La première est de mettre en place un tableau sans limiter le travail en cours. Un tableau Kanban sans limites n’est qu’une liste de tâches visuelle — utile, mais qui ne produit pas les effets de flux que Kanban est censé apporter. C’est la limitation du travail en cours qui est le mécanisme actif de la méthode.

La deuxième est de multiplier les colonnes. Un tableau avec douze colonnes est plus difficile à lire qu’un tableau avec cinq. Chaque colonne supplémentaire ajoute un point de transfert potentiel, ce qui ralentit le flux au lieu de l’accélérer. Le bon nombre de colonnes reflète les étapes réelles du processus — ni plus, ni moins.

La troisième est de ne pas mesurer le temps de cycle. Sans cette mesure, l’équipe n’a aucun moyen de savoir si ses ajustements améliorent réellement la situation. Kanban sans données, c’est de l’intuition habillée en méthode.

Comment Polara Studio utilise Kanban

Chez Polara Studio, nous utilisons Kanban pour les activités à flux continu — le support, la maintenance et les corrections — et Scrum pour le développement de fonctionnalités structurées. Cette distinction nous permet d’avoir le meilleur des deux approches : la prévisibilité des sprints pour les développements planifiés et la réactivité de Kanban pour tout ce qui ne peut pas attendre.

Nos tableaux Kanban sont volontairement simples : cinq colonnes, des limites strictes par colonne, et une revue hebdomadaire du temps de cycle. Quand le temps de cycle augmente, nous cherchons la cause — souvent un goulot d’étranglement dans la relecture de code ou une dépendance externe non résolue — et nous ajustons le processus. Cette discipline permet à nos équipes de maintenir un rythme de livraison soutenu sans sacrifier la qualité.