Il y a un moment précis où tous les tableaux Kanban se ressemblent.
Tu sais, ce moment où tu crées ton projet, tu ajoutes trois colonnes, tu respires un grand coup et tu te dis :
“Voilà. C’est carré. On va enfin être organisés.”
À faire / En cours / Fait.
La trinité sacrée.
Et puis, une semaine plus tard, c’est déjà la foire :
- des cartes “En cours” depuis 12 jours (mais “ça avance, promis”)
- des cartes “Fait” qui ne sont pas déployées
- des cartes “À faire” qui ne sont pas prêtes
- des cartes “Bloquées” qui ne disent pas par quoi ni depuis quand
- des gens qui bossent… mais le tableau ne bouge pas
Et là tu comprends la vérité douloureuse :
un tableau simple peut être un mensonge très bien présenté.
Le but de cet article, c’est de transformer ton tableau en instrument de vérité.
Pas un tableau “joli”, pas un tableau “process”, mais un tableau qui dit :
- où est le travail
- ce qui attend
- ce qui est réellement en cours
- ce qui bloque
- ce qui est “presque fini” depuis 10 jours
Pourquoi “À faire / En cours / Fait” ne suffit (presque) jamais
Ce tableau a un énorme mérite : il marche quand l’activité est simple.
Mais dès que tu as :
- des validations,
- un QA,
- un client interne,
- une dépendance externe,
- une attente (infos, accès, budget, décision),
- un déploiement,
- ou juste… plus d’une personne,
Alors “En cours” devient un sac magique.
Et dans ce sac, tu mets tout :
- du dev
- une review
- des tests
- une attente de réponse
- un ticket “je dois relancer”
- un “j’ai fini mais je dois attendre jeudi”
- un “ça bloque mais je préfère pas l’écrire”
Résultat : tu perds la seule chose que Kanban doit te donner :
la visibilité sur le flux.
Le principe de base : un tableau est une carte du flux, pas une todo-list
Un bon tableau ne répond pas à “qui fait quoi”.
Il répond à :
- Quelles sont les étapes réelles entre l’idée et la valeur livrée ?
- Où le travail passe-t-il son temps ? (souvent : à attendre)
- Où est la contrainte ?
- Que signifie “terminé”, exactement ?
Ton tableau doit être une représentation de ton système, pas un décor.
Étape 1 — Décrire la réalité (pas la théorie)
Tu veux un tableau qui reflète la réalité ?
Alors première règle :
On ne commence pas par dessiner des colonnes.
On commence par suivre une carte.
Prends une carte “simple” (une vraie), et demande :
- Comment elle arrive chez nous ?
- Qu’est-ce qu’on fait en premier ?
- Qui valide ?
- Quand est-ce que ça part en test ?
- Qu’est-ce qui bloque souvent ?
- Où ça attend ?
- Quand est-ce que c’est vraiment livré ?
Tu peux faire cet exercice en 10 minutes avec l’équipe.
Et je te garantis un truc :
Personne ne dira “À faire / En cours / Fait”.
Ils diront :
- “d’abord on clarifie”
- “ensuite on attend que X réponde”
- “après on fait une review”
- “puis QA”
- “puis validation métier”
- “puis déploiement”
- “puis… parfois on attend le créneau”
Voilà ton tableau.
Étape 2 — Séparer “faire” et “attendre” (le hack le plus rentable)
La plupart des équipes sous-estiment un truc :
le travail passe plus de temps à attendre qu’à être fait.
Et si ton tableau ne montre pas l’attente, il te ment.
Solution simple : créer des colonnes “attente” explicites
Par exemple :
- En cours (dev)
- En attente de review
- En attente QA
- En attente validation métier
- En attente déploiement
Ce simple choix change tout :
- tu vois où ça s’accumule
- tu sais quoi débloquer
- tu arrêtes de confondre “j’ai travaillé dessus” et “ça avance”
Étape 3 — Dessiner les bonnes colonnes (et accepter qu’il n’y a pas de modèle universel)
Un tableau efficace ressemble rarement à un “process idéal”.
Il ressemble à un flux minimal, avec des étapes qui comptent.
Un bon squelette pour beaucoup de contextes IT
Entrée
- À qualifier (ou Triage)
- Prêt (ReadyReadyétat où l’item est suffisamment clair pour être commencé sans découvrir un manque critique au bout de 30 minutes. / Requis clairs)
Production
- En cours
- Review / Pairing / Validation technique
- Test / QA
Validation / Livraison
- Validation métier / UAT
- Déploiement / Mise en prod
- Terminé (valeur livrée)
Et tu ajoutes Attente là où ça coince vraiment.
Le point crucial : “Fait” doit avoir une définition (sinon c’est un placebo)
Le plus gros mensonge dans un tableau, c’est “Fait”.
Parce que “fait” peut vouloir dire :
- “j’ai codé”
- “j’ai pushé”
- “c’est mergé”
- “c’est testé”
- “c’est validé”
- “c’est déployé”
- “c’est utilisé”
- “on a le feedback”
Si tu ne choisis pas, tu te racontes des histoires.
Exemple de définitions utiles
- Terminé (technique) : tests passés + review OK + prêt à déployer
- Terminé (livré) : en prod + accessible + le métier peut l’utiliser
- Terminé (validé) : feedback obtenu / critères d’acceptation confirmés
Tu peux garder un seul “Fait”, mais dans ce cas il doit correspondre à la valeur livrée, pas au “travail fini pour moi”.
Les 8 erreurs classiques (celles qui ruinent un tableau sans qu’on s’en rende compte)
1) Une colonne “En cours” fourre-tout
Si tout est “en cours”, rien n’est visible.
Fix : découper en étapes qui changent réellement le statut (faire vs attendre, review, QA, validation).
2) Trop de colonnes = trop de théâtre
Parfois on construit un tableau comme un organigramme BPMN.
Résultat : personne ne l’utilise, ou chacun “interprète”.
Fix : garde uniquement les étapes où :
- une personne différente intervient,
- un type d’activité change (dev → test),
- ou l’attente est significative.
3) Confondre “workflow” et “spécialités”
Un grand classique :
colonnes “Dev / QA / Ops / Produit”.
Ça décrit des métiers, pas un flux.
Et ça crée du “ping-pong” plus qu’autre chose.
Fix : colonnes = états du travail, pas équipes.
4) Pas de politique d’entrée (“Prêt” n’existe pas)
Tu démarres des cartes floues, puis tu t’étonnes que ça traîne.
Fix : une colonne Prêt avec une mini check-list :
- objectif clair,
- critères d’acceptation,
- dépendances identifiées,
- taille raisonnable.
5) Le tableau ne montre pas les blocages
Soit on met “Bloqué” comme étiquette, soit on n’ose pas.
Fix :
- une règle simple : si bloqué > 24h, ça se voit sur le tableau.
- et une cause obligatoire (accès, décision, externe, info manquante…).
6) Trop de “En cours” = multitâche, délais, fatigue
C’est mathématique : plus tu ouvres de cartes, plus tu ralentis.
Fix : limites de 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. (oui, même petites) :
- 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”
- 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 “Review”
- 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 “QA”
Tu veux une équipe fluide ?
Alors protège la capacité de finir.
7) Les “attentes externes” disparaissent
Ticket chez un fournisseur, attente d’un retour utilisateur, validation juridique…
On le met où ? Souvent : “En cours”.
Fix : une colonne En attente externe (ou plusieurs si besoin) + règle de relance.
8) Le tableau est mis à jour “quand on a le temps”
Donc jamais. Ou le vendredi à 17h.
Fix : politque simple :
- déplacement de carte = partie du travail
- 2 minutes en daily pour nettoyer les états
- et tu acceptes que “tableau à jour” > “tableau beau”
Exemples concrets de tableaux “réalité”
Exemple 1 — Équipe produit / dev (avec QA)
- À qualifier
- Prêt
- Dev
- En attente review
- QA
- En attente validation métier
- Déploiement
- Terminé (livré)
Option : une colonne “Attente externe” si vous dépendez souvent d’autres équipes.
Exemple 2 — Support / incident / run
- Nouveau
- Triage
- Diagnostic
- En attente client
- En attente tiers (éditeur/fournisseur)
- Correction / action
- Validation
- Clos
Tu remarques ? Ici, l’attente est structurante.
Donc elle doit être visible.
Exemple 3 — Contenu / marketing (oui, Kanban marche aussi ici)
- Idées
- À cadrer
- Brief prêt
- Rédaction
- Relecture
- SEO / intégration
- Programmation
- Publié
Pareil : “En cours” unique = aveuglement garanti.
Comment faire évoluer ton tableau sans “révolution process”
Tu n’as pas besoin d’un big-bang.
La meilleure stratégie :
- Ajoute 1 ou 2 colonnes “attente” là où ça coince le plus.
- Clarifie la définition de “Fait”.
- Mets une limite de 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”.
- Observe 2 semaines.
- Ajuste.
Ton tableau n’est pas un schéma figé.
C’est un miroir. Et un miroir, ça se nettoie régulièrement.
La question qui valide tout : “Si je regarde le tableau, est-ce que je comprends ce qui bloque la livraison ?”
Si la réponse est oui : tu es sur un bon tableau.
Si la réponse est non : tu as probablement un tableau “cosmétique”.
Et tu sais quoi ? Ce n’est pas grave.
C’est même normal.
Parce que le vrai progrès, ce n’est pas de “bien faire Kanban”.
C’est de rendre visible ce qui te ralentit… pour enfin pouvoir agir dessus.
