Tableau kanban : colonnes, cartes et limite d’en-cours

Un tableau kanban affiche des tâches en colonnes, mais un seul mécanisme le fait vraiment fonctionner : la limite d’en-cours. Sans elle, il reste une liste organisée qui ne raccourcit aucun délai.

Qu’est-ce qu’un tableau kanban et d’où vient-il ?

Un tableau kanban est une représentation visuelle d’un flux de travail. Chaque étape du processus devient une colonne, chaque unité de travail (une tâche, un dossier, un ticket, une candidature) devient une carte, et la carte se déplace de colonne en colonne au fur et à mesure qu’elle progresse. L’idée centrale n’est pas de lister ce qu’il reste à faire, mais de rendre visible où se trouve chaque élément de travail à un instant donné, et surtout ce qui bloque son avancement.

Le mot kanban vient du japonais et désigne une étiquette ou une carte signal. L’outil trouve son origine dans l’industrie automobile, chez Toyota, où l’ingénieur Taiichi Ohno a conçu au milieu du vingtième siècle un système de production inspiré du fonctionnement des rayonnages de supermarché. Dans un supermarché, on ne réapprovisionne un rayon que lorsqu’un client a prélevé un produit : le réassort suit la consommation réelle, il ne l’anticipe pas. Ohno a transposé ce principe à la chaîne de production : un poste de travail ne fabrique une pièce que lorsque le poste suivant en a réellement besoin, signalé par une carte kanban physique. Ce fonctionnement s’oppose au système classique dit « poussé », où chaque poste produit selon un planning prévisionnel, sans savoir si l’aval est prêt à absorber la production. Le système kanban est un système « tiré » : le travail est appelé par la demande réelle, pas injecté par anticipation.

Ce principe s’est ensuite déplacé du sol d’usine vers le travail intellectuel. Dans les années 2000, des équipes informatiques ont adapté la logique du flux tiré à la gestion de projet logicielle, donnant naissance à ce que l’on appelle aujourd’hui la méthode kanban appliquée au travail de bureau. Le principe reste identique : visualiser le travail, limiter ce qui est en cours, et gérer le flux plutôt que les échéances individuelles. C’est cette version, adaptée à des équipes de commerciaux, de développeurs, de recruteurs ou de chargés de clientèle, qui a donné naissance aux tableaux kanban numériques que l’on trouve désormais dans la plupart des outils de gestion de projet, avec des modèles de colonnes prêts à l’emploi que l’on peut dupliquer en quelques clics.

Ce dernier point mérite d’être souligné dès l’introduction, car c’est le fil rouge de cet article : un modèle de colonnes prêt à l’emploi donne l’apparence d’un tableau kanban, mais il n’en reprend souvent que la moitié du principe. La visualisation est là, la limite ne l’est pas. Et sans cette limite, l’outil hérité de Toyota perd la propriété qui le rendait efficace : forcer l’équipe à finir avant de commencer autre chose.

Les trois éléments qui composent un tableau kanban : colonnes, cartes, limites

Un tableau kanban repose sur trois éléments constitutifs. Chacun répond à une question différente, et les trois doivent être présents pour que le tableau fonctionne comme un système de pilotage plutôt que comme un simple affichage.

Les colonnes et les cartes sont les éléments visibles, ceux que l’on configure en premier et que l’on remarque immédiatement en ouvrant un tableau. Ce sont aussi les deux éléments que la quasi-totalité des équipes mettent en place spontanément, souvent en dupliquant un modèle « à faire, en cours, fait » sans y réfléchir davantage. Ce triptyque suffit à obtenir un affichage clair, mais il ne suffit pas à obtenir un flux de travail maîtrisé.

La limite d’en-cours, en anglais work in progress limit ou limite de WIP, est le troisième élément, et c’est celui que la grande majorité des tableaux kanban mis en place dans les TPE et PME françaises n’appliquent jamais. On lui donne une case dans les formations, un paragraphe dans les articles de référence, puis on l’oublie au moment de configurer l’outil, parce qu’elle demande une décision inconfortable : accepter de dire non à une tâche qui voudrait démarrer, tant qu’une autre n’est pas terminée. C’est précisément ce mécanisme qui distingue un tableau kanban d’une liste de tâches présentée en colonnes. La section suivante lui est entièrement consacrée, car c’est le cœur de cet article.

La limite d’en-cours : le mécanisme qui fait vraiment fonctionner un kanban

Un tableau sans limite d’en-cours autorise n’importe quel nombre de cartes dans chaque colonne. Une équipe peut ouvrir vingt tâches en même temps dans la colonne « en cours », les afficher proprement les unes sous les autres, et avoir malgré tout l’impression de piloter son activité, puisque tout est visible, classé, à jour. C’est exactement là que se situe le piège : la visibilité n’est pas le pilotage. Un tableau qui affiche vingt tâches en cours sans limite ne fait que documenter un embouteillage, il ne le résout pas. Le rythme auquel les tâches se terminent, lui, ne dépend pas de l’affichage, il dépend de la capacité réelle de l’équipe et du nombre de choses qu’elle essaie de faire avancer en parallèle.

La limite d’en-cours consiste à fixer, pour une colonne donnée, un nombre maximal de cartes qu’elle peut contenir à un instant donné. Dès que ce nombre est atteint, aucune nouvelle carte ne peut entrer dans la colonne : il faut d’abord qu’une carte en sorte. Cette contrainte, qui semble à première vue restrictive, produit l’effet inverse de ce que l’on redoute : elle ne ralentit pas le travail terminé, elle raccourcit le délai de chaque tâche individuelle, sans réduire le nombre total de tâches terminées sur une période donnée. C’est une conséquence directe d’une relation mathématique simple, connue sous le nom de loi de Little, qui relie trois grandeurs : le nombre d’éléments en cours, le débit (le nombre d’éléments terminés par unité de temps) et le délai de traversée moyen (le temps qui s’écoule entre le début et la fin du traitement d’un élément).

La relation s’écrit ainsi : le nombre d’éléments en cours est égal au débit multiplié par le délai de traversée moyen. On peut la réécrire pour isoler le délai : le délai de traversée moyen est égal au nombre d’éléments en cours divisé par le débit. Cette formule dit une chose très concrète : si le débit d’une équipe reste stable, alors plus il y a de tâches ouvertes en même temps, plus chaque tâche individuelle attend longtemps avant d’être terminée. Réduire le nombre de tâches ouvertes en parallèle, sans changer la capacité de l’équipe, réduit donc mécaniquement le délai moyen par tâche.

L’exemple chiffré : une équipe de 4 personnes, 12 tâches ouvertes en parallèle

Prenons une équipe de quatre personnes. Sa capacité totale de travail, en personnes-jours, est de quatre personnes-jours par jour ouvré. Cette équipe a ouvert douze tâches en même temps, sans aucune limite d’en-cours : chacune avance par à-coups, un peu chaque jour, au gré des priorités qui changent, des interruptions, et de l’attention qui se disperse sur douze fronts à la fois. Admettons que chaque tâche nécessite, une fois tout le travail effectif cumulé, deux personnes-jours d’effort pour être terminée.

Avec douze tâches ouvertes en même temps et une capacité de quatre personnes-jours par jour, chaque tâche ne reçoit en moyenne que quatre divisé par douze, soit un tiers de personne-jour d’attention par jour. Pour accumuler les deux personnes-jours d’effort nécessaires à son achèvement, il lui faut donc six jours ouvrés en moyenne (deux divisé par un tiers égale six). C’est le délai de traversée moyen dans cette configuration.

Le débit, lui, se calcule directement à partir de la loi de Little : douze tâches en cours divisées par six jours de délai moyen donnent un débit de deux tâches terminées par jour ouvré. On peut vérifier ce chiffre autrement : la capacité totale de l’équipe est de quatre personnes-jours par jour, et chaque tâche coûte deux personnes-jours, donc l’équipe termine mécaniquement quatre divisé par deux, soit deux tâches par jour, quel que soit le nombre de tâches ouvertes en parallèle, à condition que la capacité soit pleinement utilisée.

Fixons maintenant une limite d’en-cours de six tâches, deux fois moins que les douze de départ. La capacité de l’équipe n’a pas changé : toujours quatre personnes-jours par jour. L’effort nécessaire par tâche n’a pas changé non plus : toujours deux personnes-jours. Mais avec seulement six tâches ouvertes en même temps, chaque tâche reçoit désormais quatre divisé par six, soit deux tiers de personne-jour d’attention par jour, deux fois plus qu’avant. Le temps nécessaire pour accumuler les deux personnes-jours d’effort tombe donc à deux divisé par deux tiers, soit trois jours. Le délai de traversée moyen passe de six jours à trois jours, une réduction de moitié.

Et le débit ? Toujours quatre personnes-jours de capacité divisés par deux personnes-jours d’effort par tâche, soit deux tâches terminées par jour. Exactement le même débit qu’avec douze tâches ouvertes. On peut aussi le retrouver par la loi de Little : six tâches en cours divisées par trois jours de délai égale deux tâches par jour. Le nombre de tâches terminées chaque semaine ne change pas. Ce qui change, c’est le temps que chaque client, chaque projet, chaque demandeur doit attendre pour voir sa tâche aboutir.

Ce tableau contient l’intégralité de la démonstration : le débit ne bouge pas d’une unité, ligne par ligne, entre les deux colonnes, alors que le délai de traversée moyen est divisé par deux. Ce résultat n’a rien de contre-intuitif une fois qu’on l’a vu écrit : la capacité de l’équipe est une donnée physique, elle ne dépend pas du nombre de tâches qu’on lui assigne en même temps. Ce qui dépend du nombre de tâches ouvertes, c’est la part d’attention que chaque tâche reçoit chaque jour, et donc le temps qu’il lui faut pour accumuler l’effort nécessaire à son achèvement.

Dans la réalité d’une TPE ou d’une PME, l’écart serait probablement encore plus marqué que dans ce calcul, car le passage constant d’une tâche à une autre a un coût qui n’apparaît pas dans une comparaison purement arithmétique : reprendre le fil d’un dossier interrompu prend du temps, retrouver le contexte d’un client qu’on n’a pas traité depuis trois jours prend du temps, redémarrer une réflexion coupée en plein milieu prend du temps. Ce coût de changement de contexte n’a pas été intégré dans le calcul ci-dessus, précisément pour ne s’appuyer que sur une démonstration vérifiable et non sur une estimation. Il joue pourtant dans le même sens : il aggrave la situation à douze tâches ouvertes, et il s’atténue à six. La limite d’en-cours ne fait donc pas que raccourcir le délai par un effet mécanique de répartition de l’attention, elle réduit aussi, en pratique, le nombre de fois où l’on interrompt un travail pour en reprendre un autre.

C’est ce mécanisme, et lui seul, qui transforme un tableau en colonnes en un véritable système de flux. Sans lui, ajouter une colonne, une carte, ou un modèle de tableau plus joli ne change rien à la vitesse à laquelle le travail sort. Toutes les sections qui suivent reviennent, d’une manière ou d’une autre, à cette même idée : la limite d’en-cours est la seule décision qui a un effet mesurable sur les délais, tout le reste n’est que mise en forme.

Comment définir des colonnes qui reflètent le processus réel plutôt que le triptyque « à faire, en cours, fait »

Le découpage en trois colonnes, « à faire », « en cours », « fait », est celui que la plupart des outils proposent par défaut à la création d’un tableau. Il a un mérite : il ne demande aucune réflexion préalable, on peut commencer à travailler immédiatement. Il a aussi une limite structurelle : la colonne « en cours » regroupe en réalité toutes les étapes intermédiaires du travail, quelles qu’elles soient, ce qui rend invisible la plus grande partie de ce qui se passe réellement entre le début et la fin d’une tâche.

Une tâche qui attend une validation, une tâche en train d’être rédigée, une tâche en relecture, et une tâche bloquée en attente d’une information client se retrouvent toutes dans la même colonne « en cours », alors qu’elles n’ont rien de comparable : l’une avance, l’une attend une décision extérieure, l’une est traitée activement, l’une est en pause. Or c’est exactement la distinction entre « on travaille dessus » et « ça attend quelque chose ou quelqu’un » qui permet de repérer les points de friction dans un processus. Fusionner ces états dans une colonne unique revient à effacer l’information la plus utile que le tableau pourrait fournir.

Définir des colonnes pertinentes consiste donc à reconstituer, avec l’équipe, le déroulement réel du travail, étape par étape, tel qu’il se passe effectivement, et non tel qu’on voudrait qu’il se passe. La méthode la plus fiable consiste à prendre cinq ou six tâches terminées récemment et à retracer, pour chacune, les étapes concrètes qu’elles ont traversées avant d’être closes : qui les a réceptionnées, à quel moment quelqu’un s’en est occupé, à quel moment elles ont attendu une réponse, à quel moment elles ont été vérifiées, à quel moment elles ont été livrées. Ce sont ces étapes, et non une liste théorique, qui doivent devenir les colonnes du tableau.

Deux règles pratiques aident à fiabiliser ce découpage. La première consiste à créer une colonne dédiée chaque fois qu’une tâche attend une action venant de l’extérieur de l’équipe, un retour client, une validation d’un tiers, une pièce manquante, plutôt que de la laisser dans la colonne « en cours » où elle donnera l’illusion trompeuse d’avancer. La seconde consiste à limiter le nombre total de colonnes à ce qui reste lisible d’un seul coup d’œil, soit en pratique cinq à huit colonnes pour un processus de travail courant : au delà, le tableau devient aussi difficile à lire qu’une liste de tâches non structurée, et le gain de clarté s’inverse.

Il est également utile de revoir ce découpage après quelques semaines d’utilisation. Un processus qui semblait simple sur le papier révèle souvent, une fois le tableau en usage réel, une étape qui mériterait sa propre colonne, ou au contraire deux colonnes qui ne sont jamais distinguées dans la pratique et qui peuvent être fusionnées. Le tableau doit suivre le processus, pas l’inverse : si une équipe modifie systématiquement sa façon de travailler pour « faire rentrer » ses tâches dans des colonnes qui ne correspondent plus à la réalité, c’est le signe que le découpage doit être révisé.

Ce qu’une carte doit porter pour être exploitable

Une carte kanban n’est pas qu’un titre affiché dans une colonne. C’est l’unité d’information sur laquelle repose toute décision prise en regardant le tableau : qui doit s’en occuper, quand elle doit être livrée, si elle est urgente, à quel projet ou quel client elle se rattache, et où elle en est réellement dans son avancement. Une carte pauvre en information oblige à ouvrir chaque tâche une par une pour comprendre la situation, ce qui annule l’un des principaux bénéfices du tableau : la lecture d’ensemble en un coup d’œil.

Il existe un équilibre à trouver entre une carte trop pauvre, qui n’apporte aucune information utile à la décision, et une carte surchargée de champs que personne ne remplit ni ne consulte. La règle la plus simple consiste à se demander, pour chaque champ envisagé, s’il permet de prendre une décision différente selon sa valeur. Une échéance permet de décider si une tâche doit passer devant une autre : elle est utile. Un champ « commentaire libre » que personne ne relit avant de décider quoi que ce soit finit par n’être qu’une case vide ou remplie au hasard : il alourdit la carte sans éclairer la décision.

Un dernier point mérite d’être noté : la carte n’a de valeur que si elle est tenue à jour au rythme du travail réel, et non lors d’une réunion hebdomadaire de mise à jour. Une carte dont l’échéance, la priorité ou l’avancement ne sont actualisés qu’une fois par semaine donne une image du tableau qui n’a plus grand rapport avec la situation du jour, et c’est précisément dans cet écart que se cachent les tâches oubliées.

Les signaux de dysfonctionnement qu’un tableau rend visibles

Un tableau kanban bien construit ne se contente pas d’afficher du travail : il rend visibles, presque malgré lui, les endroits où le processus dysfonctionne. Quatre signaux reviennent le plus fréquemment dans les tableaux d’équipes de TPE et PME, et chacun raconte un problème différent qui appelle une réponse différente.

Ces quatre signaux ont un point commun : ils ne sont visibles que si le tableau est regardé régulièrement, dans son ensemble, et pas seulement carte par carte au moment où l’on cherche une information précise. Une revue courte et régulière du tableau complet, colonne par colonne, permet de repérer une colonne qui gonfle avant qu’elle ne devienne un vrai problème de délai, et une carte vieillissante avant qu’elle ne soit complètement oubliée. C’est aussi là que la limite d’en-cours retrouve un rôle : une colonne qui atteint sa limite et qui bloque l’arrivée de nouvelles cartes est un signal en soi, beaucoup plus explicite qu’une colonne qui continue de grossir sans qu’aucune règle ne le remarque.

Le kanban hors informatique : cinq usages concrets en entreprise

Le tableau kanban n’a rien de spécifique au développement logiciel ou à la gestion de projet technique. Le principe, visualiser un flux de travail découpé en étapes et limiter ce qui avance en parallèle, s’applique à n’importe quel processus qui traite des éléments comparables les uns après les autres : des prospects, des candidatures, des tickets clients, des factures, des contenus à produire. Le tableau ci-dessous présente des colonnes types pour cinq usages courants en TPE et PME, à adapter au processus réel de chaque équipe, conformément au principe présenté plus haut.

Dans chacun de ces cas, la même règle décrite plus haut s’applique intégralement : sans limite d’en-cours, un tableau commercial avec cinquante prospects en négociation en même temps donne surtout l’illusion qu’un commercial peut suivre cinquante conversations avec la même qualité qu’il en suivrait dix. Un tableau de recrutement avec trente candidatures ouvertes en parallèle ne fait pas recruter plus vite, il disperse simplement l’attention du recruteur sur trente dossiers dont la moitié attendra des semaines une réponse. Un tableau de facturation où la colonne « en attente de paiement » grossit sans limite ne fait qu’afficher un problème de trésorerie sans le résoudre : c’est une fois que cette colonne atteint un seuil défini que l’on peut décider de bloquer l’émission de nouvelles factures à un client tant que les précédentes ne sont pas réglées, ou d’engager une relance systématique.

Le point commun à ces cinq usages est que le tableau ne remplace ni le savoir-faire commercial, ni l’entretien de recrutement, ni la compétence technique du service après-vente : il organise la manière dont le travail circule entre les personnes qui l’exécutent, et il rend visible l’endroit où ce travail s’accumule sans avancer.

Kanban et Scrum : ce qui les sépare vraiment

Kanban et Scrum sont souvent présentés comme deux variantes d’une même famille de méthodes agiles, ce qui n’est vrai qu’en partie. Les deux visent à organiser le travail d’équipe de façon plus visible et plus itérative que la gestion de projet traditionnelle, mais leurs mécaniques internes diffèrent sur des points structurants, qui déterminent lequel des deux convient mieux à une situation donnée.

Scrum organise le travail en cycles de durée fixe, appelés sprints, généralement de une à quatre semaines. Au début de chaque sprint, l’équipe définit un ensemble de tâches qu’elle s’engage à réaliser avant la fin du cycle. Ce fonctionnement suppose une équipe qui travaille sur un périmètre suffisamment stable pour planifier plusieurs semaines à l’avance, et il s’accompagne de rôles définis, un porteur de produit qui priorise le travail, un facilitateur qui veille au bon déroulement des rituels, et de rendez-vous récurrents, une réunion de planification en début de sprint, une réunion quotidienne courte, une revue en fin de sprint, une rétrospective pour ajuster le fonctionnement de l’équipe.

Kanban ne découpe pas le temps en cycles fixes. Le travail est traité en flux continu : une carte entre dans le système, avance colonne après colonne, sort une fois terminée, sans attendre la fin d’une période donnée. Il n’impose ni rôle prédéfini ni rituel obligatoire, et son seul mécanisme de régulation est la limite d’en-cours posée sur les colonnes. Une nouvelle carte peut être ajoutée à tout moment, dès qu’une place se libère dans la colonne d’entrée, sans attendre le début d’un nouveau cycle.

Le choix entre les deux dépend surtout de la nature du travail à organiser, plus que d’une préférence de méthode. Une équipe qui construit un produit selon un plan qu’elle peut découper en lots de quelques semaines, avec un périmètre relativement stable d’un cycle à l’autre, tire un bénéfice réel des sprints Scrum : ils créent un rythme, un engagement collectif, et un moment récurrent pour ajuster le fonctionnement de l’équipe. Une équipe qui traite des demandes qui arrivent en continu et de façon imprévisible, un service client, un service après-vente, une équipe support, une équipe opérationnelle qui répond à des sollicitations diverses, tire davantage bénéfice du kanban, car forcer ce type de travail dans des sprints de durée fixe crée surtout de la friction : les urgences n’attendent pas le sprint suivant, et le périmètre engagé en début de cycle est constamment remis en cause par de nouvelles demandes.

Rien n’empêche par ailleurs une équipe d’emprunter des éléments des deux approches, un rythme de revue régulier hérité de Scrum, appliqué à un tableau kanban en flux continu doté de limites d’en-cours. Ce qui importe n’est pas de rester fidèle à l’une ou l’autre méthode dans sa forme la plus stricte, mais de choisir le mécanisme de régulation, cycle fixe ou limite d’en-cours, qui correspond réellement à la façon dont le travail arrive dans l’équipe.

Ce qu’un tableau kanban ne résout pas

Présenter le tableau kanban comme un outil qui améliore la visibilité et, à condition d’y appliquer une limite d’en-cours, raccourcit les délais, ne doit pas laisser croire qu’il résout tous les problèmes d’organisation d’une équipe. Quatre limites reviennent régulièrement, et il est plus utile de les connaître à l’avance que de les découvrir après avoir attendu du tableau une réponse qu’il ne peut pas apporter.

Ces quatre limites partagent un point commun : elles relèvent de décisions humaines, de coordination ou d’arbitrage, que le tableau peut rendre plus visibles mais qu’il ne prend jamais à la place des personnes concernées. Un tableau bien construit rendra plus facile de repérer qu’une personne est surchargée ou qu’un projet client passe systématiquement après un autre, mais il ne fera jamais lui-même le choix de redistribuer la charge ou de fixer les priorités. Attendre cela d’un outil de visualisation, quel qu’il soit, conduit inévitablement à une déception qui n’a rien à voir avec la qualité du tableau lui-même.

Les erreurs qui vident un tableau de son intérêt

Un tableau kanban peut exister, être rempli, être consulté quotidiennement, et malgré tout n’apporter presque aucun bénéfice réel à l’équipe qui l’utilise. Certaines erreurs, très courantes, expliquent pourquoi.

Sur ces sept erreurs, la première domine largement les autres par son impact : une équipe peut commettre toutes les autres erreurs de cette liste et conserver malgré tout un tableau qui reste globalement utile, tant qu’une limite d’en-cours réelle et respectée l’accompagne. À l’inverse, une équipe qui évite toutes les autres erreurs mais n’applique aucune limite d’en-cours obtient un tableau propre, à jour, bien découpé, et malgré tout incapable de raccourcir un seul délai. C’est la raison pour laquelle cet article y revient à chaque section : ce n’est pas une erreur parmi d’autres, c’est la condition sans laquelle toutes les autres bonnes pratiques restent cosmétiques.

Comment mettre un premier tableau kanban en place en une semaine

La mise en place d’un premier tableau kanban n’exige pas un projet de plusieurs mois ni une réorganisation complète de l’équipe. Une semaine suffit pour passer d’une gestion informelle du travail à un tableau opérationnel, doté d’une première limite d’en-cours, à condition de suivre un enchaînement structuré plutôt que de configurer un outil au hasard.

Un modèle de tableau prêt à l’emploi, disponible dans la plupart des outils, peut accélérer la première mise en place en évitant de partir d’une page blanche, à condition de ne pas s’y arrêter : le modèle donne un point de départ pour les colonnes et les cartes, mais la limite d’en-cours, elle, ne fait jamais partie d’un modèle générique, car elle dépend de la capacité réelle de chaque équipe. C’est la seule étape de cette semaine qui ne peut pas être importée depuis un modèle, elle doit être fixée à partir de la charge observée dans l’équipe elle-même, puis ajustée dans les semaines suivantes en fonction de ce que révèle le tableau.

Il est également conseillé de considérer la limite posée le jour 5 comme une hypothèse de départ plutôt que comme un chiffre définitif. Une limite trop basse se traduira rapidement par des membres de l’équipe inactifs faute de nouvelles cartes autorisées à entrer, un signal facile à repérer, qui invite à relever légèrement la limite. Une limite trop haute, en revanche, ne donnera aucun signal aussi net : c’est justement l’absence de contrainte visible qui doit alerter, si les délais observés après quelques semaines ne se sont pas raccourcis.

Comment Djaboo met le kanban au service de votre activité

Djaboo est une solution de gestion tout-en-un pour TPE et PME. Il propose des vues kanban sur les prospects, les tâches, les jalons de projet, les devis, les bons de commande, les bons de livraison, les candidats au recrutement et les campagnes courriel. Les cartes se déplacent par glisser-déposer.

Les colonnes du tableau des prospects sont personnalisables, celles du tableau des tâches sont fixes et comptent cinq états : Non démarré, En cours, En test, Attente de retour et Achevée. Une carte de tâche porte sa priorité sous forme de bande de couleur, le projet auquel elle est rattachée, une liste de contrôle avec son pourcentage d’avancement, son échéance affichée en rouge si elle est dépassée, ses étiquettes, les avatars des personnes assignées et un minuteur.

Djaboo ne permet pas de fixer une limite d’en-cours par colonne, les colonnes du tableau des tâches ne sont pas modifiables, et Djaboo ne calcule aucune métrique kanban, ni temps de cycle, ni délai de traversée, ni diagramme de flux cumulé. Ces mesures restent à faire hors de l’outil.

À lire aussi

• Plan de charge : construire une vision fiable de la capacité
• Gestion de projet agile : méthodes, rituels et mise en pratique
• Suivi du temps : pourquoi le faire et comment l’imposer sans friction
• Planning d’équipe : méthode, outils et arbitrages

Foire aux questions sur le tableau kanban

Qu’est-ce qu’une limite d’en-cours, concrètement ?

C’est un nombre maximal de cartes autorisées simultanément dans une colonne donnée. Une fois ce nombre atteint, aucune nouvelle carte ne peut entrer dans la colonne tant qu’une carte n’en est pas sortie. C’est le seul mécanisme d’un tableau kanban qui a un effet direct sur les délais, comme le montre l’exemple chiffré développé plus haut dans cet article.

Combien de colonnes faut-il sur un tableau kanban ?

Il n’existe pas de nombre universellement valable, car le nombre de colonnes dépend du nombre d’étapes réellement distinctes dans le processus de travail concerné. En pratique, un découpage entre cinq et huit colonnes reste lisible en un coup d’œil pour des processus de TPE et PME, tout en distinguant les étapes de travail actif des étapes d’attente.

Le kanban convient-il à une équipe de deux ou trois personnes ?

Oui, le principe de visualisation et de limite d’en-cours s’applique quelle que soit la taille de l’équipe. Dans une très petite équipe, la limite d’en-cours a souvent un effet encore plus visible, car chaque personne porte une part importante de la charge totale, et disperser son attention sur trop de tâches en parallèle se ressent immédiatement sur les délais.

Faut-il un logiciel pour faire du kanban, ou un tableau blanc suffit-il ?

Un tableau blanc avec des cartes en papier suffit à appliquer les principes du kanban, colonnes, cartes, limite d’en-cours. Un outil numérique apporte surtout un intérêt pour les équipes réparties sur plusieurs sites, pour l’historique des cartes, et pour le rattachement des tâches à d’autres informations comme les projets ou les clients.

Kanban peut-il coexister avec des sprints Scrum ?

Oui, certaines équipes combinent un rythme de revue périodique hérité de Scrum avec un tableau en flux continu doté de limites d’en-cours, plutôt que d’engager un périmètre figé pour toute la durée du cycle. Ce qui distingue vraiment les deux approches n’est pas le rituel en lui-même, mais le mécanisme de régulation choisi : engagement de périmètre par cycle pour Scrum, limite d’en-cours par colonne pour kanban.

Comment calculer le temps de traversée sans outil dédié ?

Le temps de traversée d’une tâche se mesure en notant la date à laquelle elle entre dans le tableau et la date à laquelle elle en sort, terminée. En faisant la moyenne de cet écart sur un ensemble de tâches comparables, on obtient un délai de traversée moyen exploitable, même sans outil calculant automatiquement cette métrique.

Que faire quand une colonne dépasse sa limite malgré tout ?

Un dépassement doit être traité comme un signal prioritaire, pas comme une exception à ignorer. Il indique généralement que la colonne suivante manque de capacité pour absorber le flux, ou qu’une urgence a été insérée sans respecter la règle. Traiter ce dépassement passe par aider la colonne à se vider avant d’accepter une nouvelle carte, plutôt que par relever systématiquement la limite chaque fois qu’elle est franchie.

Le kanban remplace-t-il un planning ou un rétroplanning ?

Non, un tableau kanban organise le flux de travail au jour le jour, il ne remplace pas un planning qui fixe des échéances contractuelles ou des jalons de projet engagés vis-à-vis d’un client. Les deux peuvent coexister : le planning fixe les dates à tenir, le tableau kanban organise la façon dont le travail circule pour tenir ces dates.

Comment gérer les urgences sur un tableau à limite d’en-cours ?

Une urgence réelle peut justifier de dépasser temporairement une limite, à condition que ce dépassement reste visible et exceptionnel, et non une pratique systématique qui viderait la limite de son sens. Certaines équipes réservent une place dédiée aux urgences dans leur limite d’en-cours, plutôt que de dépasser la limite chaque fois qu’une tâche urgente se présente.

Un tableau kanban convient-il à la gestion de plusieurs projets clients en parallèle ?

Un tableau kanban peut regrouper des tâches issues de plusieurs projets clients à condition que chaque carte indique clairement le projet auquel elle se rattache. Il ne décide toutefois pas lequel de ces projets doit être prioritaire quand la capacité de l’équipe ne permet pas de tous les avancer au même rythme : cette décision de priorisation entre projets reste une décision à prendre en amont du tableau, comme évoqué plus haut dans cet article.