Méthode Kanban et flux tiré
Définition
Kanban est une méthode agile de gestion visuelle du flux de travail basée sur le principe du flux tiré (pull system). Contrairement à Scrum, Kanban n'a pas de sprints fixes ni de rôles prescrits — il se concentre sur la limitation du travail en cours (WIP) et l'optimisation continue du flux.
| Aspect |
Kanban |
Scrum |
| Cadence |
Flux continu |
Sprints fixes (2-4 semaines) |
| Rôles prescrits |
Aucun |
PO, SM, Développeurs |
| Changement en cours |
Permis à tout moment |
En fin de sprint uniquement |
| Planification |
À la demande |
Sprint Planning |
| Métrique clé |
Lead time, cycle time |
Vélocité |
| WIP limits |
Obligatoire |
Non prescrit |
Contexte
Le CAPM teste la compréhension de Kanban comme alternative à Scrum, ses principes fondamentaux, et quand l'utiliser. Kanban vient du système de production Toyota (lean manufacturing) et a été adapté au développement logiciel et à la gestion de projet.
Détails techniques
Les 6 pratiques Kanban
| Pratique |
Description |
Pourquoi |
| Visualiser le flux |
Tableau avec colonnes = étapes du processus |
Transparence sur l'état du travail |
| Limiter le WIP |
Maximum d'items par colonne |
Éviter la surcharge, finir avant de commencer |
| Gérer le flux |
Surveiller et optimiser le mouvement des items |
Réduire les goulots d'étranglement |
| Rendre les politiques explicites |
Règles écrites pour chaque étape |
Cohérence et prévisibilité |
| Implémenter des boucles de feedback |
Réunions de revue régulières |
Amélioration continue |
| S'améliorer collaborativement |
Expérimenter des changements mesurés |
Évolution progressive (pas de révolution) |
Tableau Kanban
┌──────────┬───────────┬────────────┬──────────┬──────────┐
│ Backlog │ À faire │ En cours │ En revue │ Terminé │
│ │ WIP: 5 │ WIP: 3 │ WIP: 2 │ │
├──────────┼───────────┼────────────┼──────────┼──────────┤
│ [Item H] │ [Item E] │ [Item C] │ [Item A] │ [Item X] │
│ [Item I] │ [Item F] │ [Item D] │ [Item B] │ [Item Y] │
│ [Item J] │ [Item G] │ │ │ [Item Z] │
│ [Item K] │ │ │ │ │
│ [Item L] │ │ │ │ │
└──────────┴───────────┴────────────┴──────────┴──────────┘
FLUX TIRÉ ← ← ← ← ← ← ← ← ← ← ← ←
(on tire un nouvel item seulement quand une place se libère)
Métriques Kanban
| Métrique |
Définition |
Formule / Calcul |
| Lead time |
Temps total entre la demande et la livraison |
Date livraison − Date demande |
| Cycle time |
Temps entre le début du travail et la livraison |
Date livraison − Date début travail |
| Throughput |
Nombre d'items livrés par unité de temps |
Items terminés / période |
| WIP |
Nombre d'items en cours de traitement |
Comptage des items actifs |
Loi de Little
$$\text{Cycle Time} = \frac{\text{WIP}}{\text{Throughput}}$$
Implication : réduire le WIP réduit le cycle time (relation directe).
| WIP |
Throughput |
Cycle Time |
| 10 items |
5 items/semaine |
2 semaines |
| 5 items |
5 items/semaine |
1 semaine |
| 3 items |
5 items/semaine |
0.6 semaine |
Flux tiré vs flux poussé
| Flux poussé (push) |
Flux tiré (pull) |
| Le travail est assigné par le manager |
L'équipe tire le prochain item quand elle est disponible |
| Surcharge possible |
WIP limité = charge régulée |
| Files d'attente longues |
Files d'attente courtes |
| Multitâche fréquent |
Focus sur le travail en cours |
| Prédictif / traditionnel |
Agile / lean |
Quand utiliser Kanban
| Contexte |
Kanban approprié |
Scrum préférable |
| Travail de maintenance / support |
✅ Flux continu variable |
❌ Sprints artificiels |
| Projet avec périmètre défini |
❌ Pas de structure de sprint |
✅ Planification claire |
| Équipe opérations |
✅ Tickets arrivent en continu |
❌ Pas de backlog stable |
| Nouveau produit |
❌ Manque de cadence |
✅ Sprints + feedback |
| Demandes imprévisibles |
✅ Flexibilité maximale |
❌ Changement limité au sprint |
Exemple concret
Équipe support IT (6 personnes) utilisant Kanban :
- Avant Kanban : 25 tickets en cours simultanément, temps moyen de résolution = 8 jours, équipe surchargée et multitâche constant.
- Après implémentation : WIP limité à 8 (backlog illimité, à faire WIP=4, en cours WIP=3, en revue WIP=1).
- Résultat après 3 mois :
- Cycle time moyen passe de 8 à 3 jours
- Throughput augmente de 12 à 18 tickets/semaine
- Satisfaction client passe de 62% à 89%
- Goulot identifié : la phase « en revue » → ajout d'un reviewer dédié
