(Et comment passer d’un “board vitrine” à un système qui fait vraiment avancer le travail)
“On a mis nos tâches dans Trello/Jira/Notion, donc on fait du Kanban.”
C’est un raccourci hyper courant… et c’est là que commencent les frustrations : beaucoup de visibilité, mais peu de changement.
Parce qu’un tableau, même très joli, peut rester un simple outil de suivi.
Kanban, lui, sert à piloter un flux de travail : réduire les embouteillages, limiter le multitâche, rendre les délais plus prévisibles, et livrer plus régulièrement.
Le board n’est que l’affichage. Kanban, c’est le pilotage.
Le vrai cœur de Kanban : “arrêter de commencer, commencer à finir”
Quand “En cours” se remplit, on a l’impression de faire avancer beaucoup de choses… alors qu’on allonge les délais (et on augmente le stress).
Le principe Kanban le plus utile en pratique :
- On limite le travail en cours (WIP)
- On tire le travail (pull) : on ne prend une nouvelle carte que quand on a de la capacité
- On rend les règles explicites : “Quand est-ce qu’une carte peut avancer ?”
- On traite les blocages comme une urgence système (pas comme un détail)
Et c’est exactement là que “tableau de post-its” et “Kanban” se séparent.
Le même board, deux réalités
Version “post-its”
- “En cours” = 18 cartes
- chacun a 3–4 sujets ouverts
- les cartes bougent peu, ou d’un coup en fin de semaine
- les urgences écrasent tout
- on finit “quand on peut”
Version “Kanban”
- “En cours” = limité (WIP)
- priorité à terminer + débloquer plutôt qu’à démarrer
- règles claires de passage
- blocages visibles + action immédiate
- on peut répondre : “En général, ça prend ~X jours”
Exemples concrets : Dev, Support, Contenu, Administratif
L’objectif ici n’est pas d’avoir “le tableau parfait”, mais de montrer comment un board devient un système Kanban quand on y met : flux + règles + WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. + traitement des blocages.
1) Développement logiciel (dev)
Le flux typique (simple et réaliste)
- À qualifier (besoin flou, à préciser)
- Prêt (spécifié, testable)
- En dev
- Code review
- QA / validation
- Prêt à livrer
- Livré
Si tu n’as que “À faire / En cours / Fait”, tu caches souvent review et QA… qui sont justement les goulots.
Limites WIP (exemple concret)
- En dev : 3
- Code review : 2
- QA : 2
Effet immédiat :
si QA est plein, l’équipe arrête de démarrer du dev et se met à finir (aider à tester, réduire la taille des changements, améliorer la qualité en amont).
Politiques explicites (exemples qui changent tout)
- Pour passer en Prêt : critères d’acceptation + capture/maquette si besoin + cas limites identifiés
- Pour passer en Code review : tests unitaires OK + description claire de la PR
- Pour passer en Livré : QA OK + note de release (même mini) + feature flag si nécessaire
Blocages typiques à rendre visibles
- attente d’un accès / d’un secret / d’un environnement
- dépendance d’une autre équipe
- validation métier
- dette technique qui empêche un changement propre
Règle Kanban simple : une carte bloquée = raison + prochaine action + qui porte l’action.
Ce que tu mesures (sans usine à gaz)
- Lead timeLead Timele temps entre “c’est demandé” et “c’est livré”.En IT : de la création du ticket (ou engagement) à sa mise en prod / clôture “Done”. : du moment où c’est “Prêt” au moment où c’est “Livré”
- ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. : nombre d’items livrés par semaine
2) Support / Helpdesk (tickets)
Le support est parfait pour Kanban, parce que c’est du flux continu.
Le flux typique
- Nouveau
- Triage (catégorie, urgence, infos manquantes)
- En cours
- En attente client / tiers
- Résolu
- Clos (confirmé / délai passé)
Le piège classique : mettre “En attente” dans “En cours”, et perdre toute visibilité sur ce qui bloque vraiment.
Limites WIP + classes de service
- En cours : 5 (par agent, ou pour l’équipe)
- Ajouter des classes de serviceClass of Servicedes catégories qui définissent comment traiter un item (priorité, délai attendu, risque).Ex : :
- Urgent (incident prod) : très rare, règles strictes
- Standard : le quotidien
- Demande : non urgente (accès, info, petit service)
Règle anti-chaos : “Urgent” ne peut pas dépasser X tickets en parallèle. Sinon, tout devient urgent.
Politiques utiles
- Un ticket ne passe pas “En cours” sans info minimale (repro, contexte, impact)
- “En attente” doit indiquer qui attend quoi et une date de relance
- Un ticket “Résolu” doit contenir la solution + si possible un lien KB (base de connaissance)
Mesures qui parlent à tout le monde
- Temps de première réponse
- Temps de résolution
- % respect d’un délai cible (SLESLEun engagement probabiliste basé sur l’historique :) : ex. “80% des tickets standard résolus en < 2 jours”
3) Contenu (marketing, blog, social, vidéo)
Là aussi, beaucoup confondent “liste de tâches” et “flux”.
Le flux typique
- Idées
- À cadrer (angle, objectif, audience)
- Brief prêt
- Rédaction
- Relecture / édition
- Design / médias
- Validation
- Planifié
- Publié
- Recyclage / déclinaisons (optionnel)
Le goulot est souvent “Validation” (ou “Relecture”) — et si ce n’est pas visible, tu auras toujours l’impression que “ça n’avance pas”.
Limites WIP (exemple concret)
- Rédaction : 2
- Relecture : 2
- Validation : 1 (oui, 1 ! sinon ça s’empile)
Pourquoi “Validation : 1” marche bien : ça force à finir un contenu avant d’en empiler 6 “en attente de validation” (qui vieillissent et se périment).
Politiques qui évitent le flou
- “Brief prêt” = objectif + format + message clé + CTA + contraintes SEO (si concerné)
- “Publié” = lien + assets archivés + tags/catégories + date de réutilisation éventuelle
- “Validation” = qui valide + sous quel délai + quoi faire si pas de réponse
Mesures simples
- Lead timeLead Timele temps entre “c’est demandé” et “c’est livré”.En IT : de la création du ticket (ou engagement) à sa mise en prod / clôture “Done”. d’un contenu (brief → publié)
- ThroughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. (contenus publiés/semaine)
- % de contenus qui bloquent > X jours en validation (excellent révélateur)
4) Administratif (factures, RH, achats, dossiers)
C’est souvent le domaine où un board “post-it” devient le plus vite “magique” : parce qu’on découvre des attentes invisibles (signatures, pièces manquantes, validations).
Exemples de flux
Achats / fournisseurs
- Demande reçue
- À compléter (devis, budget, justificatifs)
- Validation manager
- Commande
- Réception
- Facture
- Paiement
- Clôturé
RH / dossiers
- Demande
- Pièces à fournir
- En traitement
- Validation
- Terminé
La colonne la plus importante en administratif : “En attente (de)”.
C’est souvent là que le travail “meurt”… si on ne le rend pas visible.
Limites WIP (oui, même ici)
- En traitement : 5 (par personne)
- Validation : 2
- À relancer : 10 max (sinon tu perds le contrôle)
Politiques anti-perte de temps
- Une carte “En attente” doit avoir : qui + quoi + date de relance
- Une carte ne passe pas “En traitement” sans pièces minimales
- Validation = délai cible + escalade si dépassement
Mesures utiles
- délai moyen demande → clôture
- nombre de dossiers “en attente” > 7 jours (ou 14)
Les anti-patterns communs (tous secteurs)
- “En cours” est un parking
➡️ Mets une limite WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. + une vraie colonne “En attente”. - “Tout est urgent”
➡️ Définis une règle d’urgence rare + limitée, sinon ton système n’a plus de flux. - Trop de colonnes… ou pas assez
➡️ Ton board doit refléter le flux réel (surtout les attentes/validations), sans devenir un labyrinthe. - On bouge les cartes mais on ne change rien
➡️ Ajoute des règles et une cadenceCadencefréquence des moments de pilotage (replenishmentReplenishmentmoment où l’on décide quoi entre dans le système “prêt à être tiré”.Souvent une étape “ReadyReadyétat où l’item est suffisamment clair pour être commencé sans découvrir un manque critique au bout de 30 minutes.”., delivery review, ops review, risk review…). : chaque semaine, un mini-ajustement basé sur ce que le board montre.
Comment passer de “post-its” à Kanban en 5 actions (universel)
- Ajoute une colonne “En attente / Bloqué” (et oblige la raison + prochaine action)
- Pose une limite WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. sur “En cours” (même si elle est “approximative” au départ)
- Écris 2–3 politiques explicites (“prêt”, “fini”, “validation”)
- Fais une mini-revue hebdo de flux (15 min) : où ça coince ? pourquoi ? quoi tester ?
- Suis une mesure simple : lead timeLead Timele temps entre “c’est demandé” et “c’est livré”.En IT : de la création du ticket (ou engagement) à sa mise en prod / clôture “Done”. ou throughputThroughputle nombre d’items terminés sur une période donnée.Ex : 18 tickets “Done” cette semaine → throughput = 18/semaine. (ou “temps de résolution” en support)
Conclusion
Un tableau de post-its te dit où est le travail.
Kanban te dit comment le travail circule, et te donne des leviers pour le faire circuler mieux.
Si tu veux que ton article déclenche un “ah ouais, ok”, la phrase finale qui marche bien est :
Le board n’est pas Kanban. Kanban, c’est ce que tu fais quand le board montre un embouteillage.
