Tu connais la scène.
Un tableau flambant neuf. Des colonnes propres. Des cartes colorées.
Et pourtant… dans la vraie vie : ça court partout, ça râle, ça “relance”, et les tickets vieillissent comme du bon fromage.
Le tableau n’est pas censé être une vitrine.
C’est un modèle de ton système de travail. Il doit te dire la vérité — même quand elle pique.
Aujourd’hui, je te propose trois anti-patterns ultra fréquents (et excellents sujets de blog), avec :
- comment les reconnaître (symptômes),
- pourquoi ils apparaissent (cause réelle),
- comment les corriger (pratique, pas théorique),
- et des exemples qui parlent aussi bien à une équipe dev, support, contenu ou administratif.
Un bon tableau, ce n’est pas “beau”. C’est “utile”.
Un tableau Kanban sert à piloter le flux, pas à “ranger” les tâches.
Un tableau utile :
- Visualise le vrai workflow (pas celui de la procédure Word jamais lue).
- Rend les règles explicites (qui décide ? quand ? selon quels critères ?).
- Force les choix grâce aux 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. (Work In ProgressWIPle 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.).
- Aide à détecter les blocages au lieu de les masquer.
- Donne des signaux actionnables : “on a trop commencé”, “on attend un avis”, “on traite trop d’urgences”, etc.
Avec ça en tête… passons aux trois pièges.
Anti-pattern #1 — “Tout est urgent”
À quoi ça ressemble
- Chaque carte a un tag “urgent”, “ASAP”, “prio 1”.
- Le canal Slack/Teams sert de sirène : “Tu peux prendre ça ? c’est très urgent.”
- Le backlog est un cimetière, mais tout ce qui arrive aujourd’hui devient “top priorité”.
- Le tableau ressemble à une file d’attenteQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”. chez le médecin un lundi matin : tout le monde a “très mal”.
Le vrai problème derrière
Quand tout est urgent, ça veut dire une chose : il n’y a pas de politique de priorité stable.
L’urgent devient un mode de contournement :
- Contournement du tri,
- Contournement de la file,
- Contournement des engagements existants,
- Contournement du “non” (ou du “pas maintenant”).
Résultat : tu crées un système où crier plus fort est une stratégie gagnante.
Comment corriger (sans déclencher une révolution)
1) Crée une voie “ExpediteExpediteclasse de service qui court-circuite (presque) tout.” ultra limitée
Une seule carte max. Pas deux. Pas “exceptionnellement”.
- Si la voie est pleine : soit tu finis l’expediteExpediteclasse de service qui court-circuite (presque) tout. actuel, soit tu assumes que le nouveau n’est pas vraiment expediteExpediteclasse de service qui court-circuite (presque) tout..
- Ça oblige les gens à payer le coût de l’urgence (interruption + décalage des autres engagements).
2) Distingue “urgent” et “important”
- Urgent = coût immédiat si on ne fait pas maintenant (incident, prod down, échéance légale).
- Important = apporte de la valeur, mais peut être planifié (amélioration, dette tech, optimisation).
Sans ce distinguo, “important” se fait toujours écraser.
3) Mets en place des “classes de serviceClass of Servicedes catégories qui définissent comment traiter un item (priorité, délai attendu, risque).Ex :” simples
Tu n’as pas besoin d’un modèle académique. Commence avec 3 catégories :
- ExpediteExpediteclasse de service qui court-circuite (presque) tout. (rare)
- Standard
- Date fixe (une deadline réelle, pas “ce serait bien”)
Et tu fixes des règles :
- Qui peut déclarer “ExpediteExpediteclasse de service qui court-circuite (presque) tout.” ?
- Qu’est-ce qui justifie “Date fixe” ?
- Quel engagement de délai tu assumes pour “Standard” ?
4) Installe un rituel de triage
Un point court et régulier (quotidien ou 3x/sem) où tu réponds à une seule question :
“Qu’est-ce qu’on fait entrer maintenant dans le système, compte tenu de notre capacité ?”
Là, tu reprends la main sur le flux.
Exemple concret (qui parle à tout le monde)
- Support : tout devient urgent parce que “le client attend”. Résultat : tu fais du zapping et tu rallonges tous les délais.
✅ Correctif : 1 voie incident critique + une file triée + des engagements de délai par type. - Dev : “petit fix rapide” 10 fois par jour = plus aucun sujet ne finit.
✅ Correctif : voie expediteExpediteclasse de service qui court-circuite (presque) tout. + règle “on ne coupe pas une carte en review/test sauf prod down”. - Contenu : “il faut ce post pour hier” = tu sors du moyen, souvent.
✅ Correctif : classe “date fixe” réservée aux deadlines éditoriales réelles. - Administratif : “ça dépend du directeur” = urgence permanente quand l’approbation arrive tard.
✅ Correctif : politique d’escalade + limite d’expediteExpediteclasse de service qui court-circuite (presque) tout. + suivi du temps d’attente.
Article bonus : “Comment définir une urgence sans devenir une organisation qui hurle”.
Anti-pattern #2 — “La colonne En cours est un parking”
À quoi ça ressemble
- Ta colonne En cours contient… 17 cartes.
- Certaines sont là depuis “un moment” (personne ne sait combien).
- Beaucoup de “presque fini”, “en attente”, “je dois revoir”, “bloqué”.
- Le tableau donne l’impression d’activité, mais pas de livraison.
C’est le syndrome du parking : on “range” les cartes quelque part pour ne plus les voir, sans que ça avance.
Le vrai problème derrière
Souvent, c’est un mix de trois choses :
- On commence trop (pas de limite, donc on ouvre 12 sujets à la fois).
- Le workflow n’est pas explicite (tout est “en cours”, donc on ne voit pas où ça coince).
- La définition de “fini” est floue (donc les cartes traînent en mode zombie).
Comment corriger
1) 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”
Même un chiffre brut change la culture.
- Exemple : En cours max = 4 pour une équipe de 3–5 personnes.
- Oui, ça fait peur la première semaine. Puis ça libère.
2) Découpe “En cours” en étapes réelles
Pas besoin de 15 colonnes. Juste celles qui correspondent à des transitions de vérité.
Exemples selon contexte :
- Dev : Analyse → Dev → Review → Test → Déploiement
- Support : Diagnostic → Action → Attente client → Résolu
- Contenu : Brief → Rédaction → Relecture → Publication
- Administratif : Préparation → Validation → Exécution → Archivage
Et la règle d’or :
Une colonne existe si elle permet une décision (et pas juste un “rangement”).
3) Rends le “bloqué” visible
Tu peux faire une sous-règle :
- un tag “Bloqué” obligatoire + raison (dépendance, attente validation, attente client, manque info),
- et une politique : “un bloqué déclenche une action dans la journée” (sinon tu regardes la vérité en face : tu acceptes le blocageBlocker / Blockedun item “bloqué” ne peut pas avancer pour une raison externe ou interne (dépendance, attente de validation, accès, incident, manque d’info…).).
4) Swarm au lieu de répartir
Quand le 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. est plein, tu ne “prends pas une nouvelle carte”.
Tu aides à faire sortir une carte : review ensemble, test ensemble, relance ensemble, etc.
Le but n’est pas d’avoir tout le monde occupé.
Le but est de finir.
Mini check-list “parking”
Si tu coches 3 points, tu es en plein dedans :
- On a plus de cartes “En cours” que de personnes.
- On ne sait pas expliquer pourquoi une carte est là depuis 10 jours.
- “Presque fini” est un état stable.
- Les blocages ne sont pas suivis.
- On démarre en réunion, on ne finit pas en réunion.
Article bonus : “Pourquoi ‘commencer’ est gratifiant et ‘finir’ est difficile (et comment le tableau te reprogramme).”
Anti-pattern #3 — “On ajoute des colonnes au lieu de résoudre la cause”
À quoi ça ressemble
- Chaque nouveau problème crée une nouvelle colonne :
- “En cours”
- “En cours (urgent)”
- “En cours (en attente)”
- “En cours (en attente validation)”
- “En cours (en attente validation mais c’est urgent)”
- Le tableau devient une frise chronologique de toutes tes douleurs.
- Et malgré 14 colonnes… ça n’avance pas mieux.
Le vrai problème derrière
Ajouter des colonnes, c’est parfois une fuite élégante :
- Ça donne l’impression de “structurer”.
- Ça évite de traiter le vrai goulot.
Or, un tableau n’est pas une collection de cases.
C’est une hypothèse de fonctionnement.
Si tu ajoutes une colonne sans changer une règle, tu n’as pas amélioré le système.
Tu as juste mis une étiquette sur un problème.
Comment corriger (sans jeter le tableau)
Avant d’ajouter une colonne, pose 3 questions :
- Est-ce que cette colonne représente une transition importante ?
- Est-ce qu’on va y mettre une limite ou une politique ?
- Est-ce qu’on va agir différemment grâce à elle ?
Si tu réponds “non” à l’une des trois :
➡️ probablement pas une colonne, mais :
- un tag,
- une policy écrite,
- une voie (swimlaneSwimlanelignes horizontales divisant un tableau Kanban ou Scrum pour catégoriser les éléments de travail selon des critères spécifiques (type de demande, niveau d’urgence, client ou équipe).),
- ou un problème de process à traiter à la source.
Exemples de “vraies causes” déguisées en colonnes
- “Validation” qui bloque partout → le problème est le temps de décision, pas le tableau.
- “Attente client” énorme → le problème est l’info manquante à l’entrée (Definition of ReadyReadyétat où l’item est suffisamment clair pour être commencé sans découvrir un manque critique au bout de 30 minutes.).
- “Rework” fréquent → le problème est la qualité en amont, pas une colonne “Rework”.
Fais-en un experiment Kanban
Au lieu de “refaire le tableau”, fais un pari :
- “On garde le tableau simple”
- “On limite le 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.”
- “On mesure l’âge des cartes”
- “On attaque le goulot pendant 2 semaines”
- puis on ajuste.
Un tableau qui change tous les 3 jours est un tableau qui n’a pas le temps d’enseigner quoi que ce soit.
Article bonus : “Colonnes vs politiques : comment arrêter de décorer un problème.”
Un modèle simple de “bon tableau” (qui marche dans 80% des cas)
Si tu veux une base solide (sans te perdre dans la théorie), fais ça :
- Cartographie ton flux réel
De “demande” à “livré”. Pas de fiction. - Choisis 4 à 7 colonnes max
Assez pour voir où ça coince, pas assez pour camoufler. - Écris les règles (2 lignes par colonne)
- Qu’est-ce qui entre ici ?
- Qu’est-ce qui doit être vrai pour en sortir ?
- Pose des 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.
Même si elles sont imparfaites au départ. - Crée une voie “ExpediteExpediteclasse de service qui court-circuite (presque) tout.” limitée
Et protège-la. - Installe deux rituels
- Triage / 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.”. (entrée)
- Revue de flux (amélioration)
- Observe un indicateur simple
L’âge des cartes (si tu ne mesures qu’un truc, mesure ça).
Et si tu utilises un outil type VulTask : l’important n’est pas la fonctionnalité magique.
C’est de rendre visibles les règles, les limites, et les blocages — et de t’obliger à décider.
Conclusion : le tableau n’est pas une solution. C’est un révélateur.
Un mauvais tableau cache le chaos.
Un bon tableau le rend impossible à ignorer.
