Le tableau Kanban souffre d’un malentendu tenace: beaucoup de chefs de projet l’associent exclusivement au développement logiciel et aux méthodes agiles. Cette perception est compréhensible, puisque c’est dans le monde IT que l’outil s’est diffusé le plus rapidement à partir des années 2000, mais elle passe à côté de l’essentiel. Le tableau Kanban est un dispositif de régulation du flux de travail, et tout processus composé de tâches qui avancent par étapes peut en bénéficier.
Un outil né dans l’industrie, pas dans l’informatique
Le terme “kanban” signifie “carte visible” en japonais. Dans les années 1950, Taiichi Ohno a conçu chez Toyota un système de cartes physiques pour piloter la production en flux tiré (pull system): chaque poste signalait ses besoins à l’amont, déclenchant la production uniquement à la demande. L’objectif était d’éliminer la surproduction, l’un des gaspillages fondamentaux du Lean.
David J. Anderson a transposé ces principes au travail intellectuel entre 2005 et 2007. Sa “méthode Kanban” repose sur les mêmes fondamentaux: visualiser le flux, limiter le travail en cours et améliorer le processus de manière continue. Rien dans cette méthode ne la réserve à un secteur particulier.
La structure du tableau: trois éléments à adapter
Un tableau Kanban repose sur des colonnes (les étapes du processus), des cartes (les tâches individuelles) et des limites WIP (Work In Progress), c’est-à-dire le nombre maximum de tâches autorisées simultanément dans chaque colonne.
Les colonnes doivent refléter le processus réel de l’équipe, pas un modèle théorique. La configuration minimale (À faire, En cours, Terminé) convient rarement telle quelle: chaque métier a des étapes intermédiaires qui méritent d’être rendues visibles. L’exercice de définition des colonnes est en lui-même révélateur, car il oblige l’équipe à expliciter un flux de travail souvent implicite.
Les limites WIP sont le mécanisme central. Lorsqu’une colonne atteint sa limite, la règle veut qu’on ne commence aucune nouvelle tâche tant qu’une carte n’a pas avancé. Cette contrainte rend les goulots d’étranglement immédiatement visibles et empêche l’accumulation de travail inachevé, un problème chronique dans les équipes qui démarrent beaucoup de choses sans en terminer aucune.
Trois contextes concrets hors informatique
Recrutement
Un service RH qui gère plusieurs recrutements simultanés peut structurer son tableau avec les colonnes suivantes: Candidatures reçues, Présélection, Entretien RH, Entretien manager, Offre, Intégration. Une limite WIP de trois sur la colonne “Entretien manager” garantit que les responsables opérationnels ne sont pas sollicités pour cinq entretiens la même semaine, un problème classique qui rallonge les délais de recrutement pour tous les postes.
Marketing et communication
Une équipe éditoriale peut suivre ses contenus à travers les étapes Idéation, Briefing, Création, Révision, Publication, Analyse. Limiter à deux le nombre de contenus en révision simultanée évite que des articles s’accumulent dans l’attente d’un relecteur, tandis que les rédacteurs continuent à produire des textes que personne ne relira avant des semaines.
Achats et approvisionnement
Un processus d’achat se prête naturellement à la visualisation en colonnes: Demande interne, Consultation fournisseurs, Analyse des offres, Commande, Réception, Clôture. Le tableau met en lumière les demandes bloquées en consultation depuis trop longtemps et permet de prioriser les relances fournisseurs au lieu de traiter les demandes dans l’ordre d’arrivée.
Dans ces trois cas, la valeur du tableau ne réside pas dans la visualisation seule (un tableur partagé pourrait suffire) mais dans la combinaison de la visualisation avec les limites WIP, qui force l’équipe à terminer le travail en cours avant d’en accepter de nouveau.
Ce qui ne change pas d’un contexte à l’autre
Quel que soit le domaine d’application, les mêmes principes restent valables. Chaque carte doit représenter un élément de travail suffisamment petit pour traverser le tableau en quelques jours: une carte intitulée “Réorganisation du service” désigne un programme entier, non une tâche réalisable en quelques jours. Les colonnes doivent correspondre à des états vérifiables, pas à des intentions. Le tableau nécessite une revue régulière, au minimum hebdomadaire, pour identifier les cartes bloquées et ajuster les limites WIP si le débit réel l’exige.
La loi de Little, qui établit que le temps de traversée est proportionnel au volume de travail en cours divisé par le débit, s’applique aussi bien à un processus de recrutement qu’à un pipeline de développement. Réduire le nombre de tâches en parallèle accélère mécaniquement la complétion de chacune, un résultat contre-intuitif mais systématiquement vérifié.
Physique d’abord, numérique ensuite
Le choix entre un tableau mural et un outil numérique (Trello, Jira, Notion, entre autres) dépend de la configuration de l’équipe, mais une approche a fait ses preuves dans la plupart des contextes. Commencer avec un tableau physique permet de tester rapidement différentes structures de colonnes, car déplacer un post-it ou ajouter une colonne ne prend que quelques secondes. Les conversations autour du tableau mural sont aussi plus spontanées que devant un écran partagé.
Une fois le flux stabilisé (généralement après trois à quatre semaines), la migration vers un outil numérique apporte la traçabilité, les métriques automatiques et l’accessibilité à distance. L’erreur la plus courante est de commencer directement par l’outil numérique, ce qui rigidifie prématurément un processus encore en rodage et décourage les ajustements que les premières semaines rendent pourtant indispensables.