
La Méthode Kanban IT (Partie 1) – Initiation
Dans de nombreuses organisations, une légende urbaine laisse penser que la Méthode Kanban consiste juste à mettre en place un tableau, physique ou digital, comportant des colonnes remplies de post-it ou de tickets. Cette idée reçue ne représente qu’une infime partie de ce qu’est réellement la Méthode Kanban et ne permet pas de tirer toute l’essence de la valeur et de la performance opérationnelle que cette méthode peut apporter.
Mais comment mettre en place un système Kanban performant ? Quelles sont les étapes clés pour assurer une adoption réussie ?
Voici une série d’articles détaillés pour déployer Kanban au sein d’une équipe ou d’une organisation.
Note : Cette première partie est dédiée à toutes les équipes/personnes voulant mettre en place, de façon simple et efficace, un Système Kanban ou améliorer celui existant, sans élitisme et sans dogmatisme.
Introduction à la Méthode Kanban IT
La Kanban University définit la méthode Kanban comme une approche de gestion adaptée à tous les types de services professionnels, également appelée travail de la connaissance. Elle vise à améliorer les services en se concentrant sur les besoins des clients et en optimisant le flux de travail. En visualisant le travail et en limitant le travail en cours, Kanban permet de gérer efficacement les activités et de s’adapter aux variations des demandes des clients.
Les origines
Le Kanban a vue le jour dans les années 1950, au sein de l’entreprise Toyota (Japon), dans le monde de l’industrie automobile. La méthode a été créée par Taiichi Ohno, ingénieur chez Toyota, qui cherchait un moyen d’optimiser la production et de réduire les gaspillages en s’inspirant du modèle de réapprovisionnement des supermarchés.
Le Kanban fait partie du Toyota Production System (TPS), développé par Taiichi Ohno et Shigeo Shingo, reposant sur deux piliers fondamentaux :
- Jidoka (Autonomation) → Automatisation avec intervention humaine pour détecter et corriger les anomalies.
- Just-in-Time (JIT) → Production à la demande, en flux tiré, sans surplus de stock.
Le Just-in-Time est une des pratiques clés du Kanban. Il sert de système de signalisation permettant aux équipes de production de ne fabriquer et transporter que ce qui est nécessaire, au bon moment, et en juste quantité.
Le Kanban est aussi considéré comme faisant partie des pratiques et de la philosophie Lean.
Dans les années 2000, la méthode Kanban a été adaptée au monde de l’IT et du développement logiciel grâce à David J. Anderson, créateur de la Kanban University :
- 2004-2006 : David J. Anderson applique Kanban dans des équipes de développement logiciel, chez Microsoft et Corbis.
- 2010 : Il publie le livre « Kanban: Successful Evolutionary Change for Your Technology Business », qui structure la méthode Kanban pour les équipes IT.
- De nos jours : Kanban est utilisé dans le développement logiciel, la gestion de projet, l’IT Ops, le DevOps et les services support.


En France, l’un des précurseurs et l’un des meilleurs experts du Kanban IT est Laurent Morriseau, premier Français habilité à animer des certifications Kanban et auteur du livre « Kanban pour l’IT« . J’ai eu l’honneur d’être certifié lors d’une de ses formations lorsque le Kanban n’était encore qu’une méthode snobée par de nombreuses organisations ne jurant que par Scrum, mais ça c’est une autre histoire 🙂
La sémantique
Pour bien comprendre la philosophie et le fonctionnement de la Méthode Kanban, il faut commencer part connaitre sa sémantique.

Les Principes
La Méthode Kanban s’appuie sur 4 principes, définis par la Kanban University, dont l’objectif est de mettre en oeuvre une gestion du changement guidant la mise en œuvre et l’amélioration continue du système :
- Commencer la ou vous en êtes
- Avec la Méthode Kanban, l’objectif n’est pas de bousculer toute l’organisation et les processus, sans d’abord en comprendre le fonctionnement. il s’agit ici d’allumer la lumière sur l’organisation et les processus en cours, afin d’avoir un état des lieux factuels de la situation
- Respecter les processus, les rôles et les responsabilités actuels
- Contrairement à d’autres méthodes agiles (Scrum, SAFe, …), La Méthode Kanban n’a pas pour objectif de d’inventer ou de redéfinir les rôles et les responsabilités existants dans l’organisation, dès le départ. Les structures organisationnelles en place sont respectées, sans perturbation brutale.
- Accepter de poursuivre l’amélioration grâce à un changement évolutif
- Kanban est une approche souple et adaptable aux différentes configurations d’équipes. Les ajustements doivent se faire naturellement avec le temps en fonction des besoins identifiés.
- L’objectif est de détecter et résoudre les problèmes petit à petit, au lieu de transformer complètement le processus.
- Chaque amélioration est basée sur des observations et des données (Lead Time, Cycle Time, WIP…).
- Les ajustements sont faits de manière continue et empirique, en fonction des besoins de l’équipe.
- Encourager les actes de leadership à tous les niveaux
- La Méthode Kanban encoure le leadership, pas seulement au niveau des Managers, mais au sein de l’ensemble des acteurs de l’organisation. Chaque membre de l’équipe doit prendre des initiatives pour améliorer le processus.
- Tout les acteurs sont encouragés à être force de proposition sur les axes d’améliorations possibles.
- La Méthode Kanban a pour objectif de favoriser un environnement sécurisé où les décisions sont prises de manière collaborative. L’engagement de chaque membre de l’équipe étant essentiel à la réussite la transformation.
Les Valeurs
Comme tout cadre Agile, La Méthode Kanban repose sur un ensemble de valeurs nécessaires à la bonne mise en oeuvre des pratiques et de la cohésion d’équipe.
- Transparence
- Le travail est visible par tous, ce qui permet de partager une compréhension commune du processus et des priorités.
- Collaboration
- Kanban favorise le travail en équipe pour résoudre les bottlenecks (goulets d’étranglement) et optimiser les flux de production.
- Engagement envers l’amélioration continue
- L’équipe s’efforce de s’améliorer constamment, en utilisant les données et les retours d’expérience.
- Focus sur la livraison de valeur
- L’objectif est d’accélérer la mise à disposition des fonctionnalités ou des services en minimisant les blocages.
- Respect des processus et des personnes
- Kanban ne bouleverse pas immédiatement les structures existantes. Il s’adapte progressivement aux processus en place et respecte le rythme des équipes.
Les Pratiques
La Méthode Kanban est composé de 6 pratiques
Pratique 1 – Visualiser le Flux
Utiliser un tableau Kanban (physique ou numérique) pour afficher l’ensemble des tâches et leur statut.

Pratique 2 – Limiter le travail en cours (Work In Progress – WIP)
Fixer un nombre maximal de tâches actives pour éviter la surcharge.

Pourquoi limiter le Flux ?


Pratique 3 – Mesurer et gérer le lfux
Observer et optimiser le flux, via des Flow Metrices, afin d’assurer une fluidité constante du système.

Pratique 4 – Rendre les politiques de processus explicites
L’un des principes fondamentaux de Kanban est de rendre les politiques de processus explicites afin d’assurer une compréhension commune et une meilleure gestion du flux de travail. Une politique de processus définit les règles, les critères et les pratiques qui régissent le fonctionnement du système Kanban.
Voici un exemple de règles pouvant être mises en oeuvre :
- Documenter les étapes du flux de travail (Workflow)
- Définir les colonnes du tableau Kanban (ex. : « Backlog », « À faire », « En cours », « Test », « Terminé »).
- Préciser les règles de transition entre chaque étape (ex. : une tâche ne peut passer en « Test » que si elle a été revue par un pair).
- Afficher ces étapes de manière claire et visible pour toute l’équipe (ex. : sur le tableau physique ou numérique).
- Définir les critères d’entrée et de sortie des tâches (DoR – Definition of Ready & DoD – Definition of Done)
- Definition of Ready (DoR) → Exigences minimales pour qu’une tâche passe en « À faire » (ex. : description claire, estimation de charge, critères d’acceptation définis).
- Definition of Done (DoD) → Conditions pour considérer une tâche comme terminée (ex. : code revu, testé, validé par le Product Owner, documentation mise à jour).
- Mettre ces critères en évidence sur le tableau Kanban ou dans un document partagé.
- Mettre en place des limites de travail en cours (WIP Limits)
- Déterminer une limite WIP réaliste pour chaque colonne (ex. : max 3 tâches en cours par développeur).
- Afficher ces limites directement sur le tableau Kanban.Mettre en place une règle : si une colonne atteint sa limite, l’équipe doit terminer une tâche avant d’en commencer une nouvelle.
- Formaliser la gestion des tâches bloquées
- Ajouter un indicateur visuel (ex. : label, post-it spécifique, flag) pour signaler les tâches bloquées.
- Définir un processus de gestion des blocages (ex. : si une tâche est bloquée plus de 24h, elle doit être discutée en Daily Kanban).
- Attribuer un responsable pour chaque tâche bloquée afin de chercher une solution rapidement.
- Rendre les politiques de gestion des urgences explicites
- Mettre en place une swimlane (couloir) spécifique pour les tâches urgentes.
- Définir une politique de priorisation (ex. : les incidents critiques doivent être traités en priorité, mais ne doivent pas dépasser 20% du flux total).
- S’assurer que tout le monde connaît les règles d’escalade et la personne responsable des décisions d’urgence.
- Afficher les métriques et objectifs de performance
- Suivre des métriques clés comme Lead Time, Cycle Time, Throughput.
- Rendre ces données visibles pour toute l’équipe (ex. : un tableau de bord Kanban avec des graphiques).
- Définir des objectifs d’amélioration en fonction des résultats observés.
- Standardiser et documenter les politiques de gestion du flux
- Documenter toutes les règles du système Kanban dans un document partagé ou un wiki d’équipe.
- Former les nouveaux membres de l’équipe sur ces règles dès leur arrivée.
- Organiser des revues régulières (toutes les 2-4 semaines) pour ajuster ces règles en fonction des retours d’expérience.
Pratique 5 – Implémenter des boucles de feedback
Organiser des rétrospectives régulières pour ajuster le système en fonction des performances mesurés et des événements survenus durant la cadence précédente.

Note : Le PDCA (Plan – Do -Check -Act), ou encore nommé « Roue de Deming » est un outil d’amélioration continue, créé par W. Edwards Deming, largement utilisé en gestion de projet, Lean et Kanban. Elle est au cœur de la pratique « Mettre en place des boucles de feedback », qui permet d’adapter et d’optimiser le système Kanban en fonction des résultats observés.
Pratique 6 – S’améliorer de manière collaborative
L’un des fondamentaux de la culture Kanban est d’améliorer continuellement le système, en impliquant toute l’équipe et en adoptant une approche évolutive et empirique.
Plutôt que d’imposer des changements radicaux, Kanban encourage l’expérimentation et l’amélioration progressive du processus, en impliquant tous les acteurs.

- Encourager la participation de toute l’équipe
- Adopter une approche d’amélioration progressive (Kaizen)
- Collecter et analyser les données pour guider l’amélioration
- Utiliser les boucles de feedback pour ajuster le système
- Intégrer les changements de manière évolutive et non imposée
Les étapes de mise en oeuvre d’un Système Kanban
Dans la partie 2 nous verrons les différentes étapes de mises en oeuvre d’un Système Kanban, en nous inspirant de la démarche proposée par Laurent Morisseau, dans son ouvrage « Kanban pour l’IT » et de l’approche STATIK, proposée par la Kanban University.
Ouvrages & Liens utiles
Kanban pour l’IT – Laurent Morisseau
Kanban: Successful Evolutionary Change for Your Technology Business (version Française) de David J. Anderson
Kanban University – Organisation mondiale dédiée à la diffusion et à l’enseignement de la méthode Kanban. Fondée en 2010 par David J. Anderson, créateur de la méthode Kanban pour l’IT
ProKanban – Organisation dédiée à la promotion et à l’enseignement du Kanban professionnel.