Tu as déjà vécu ça.
Quelqu’un dit :
“On a un problème de délais.”
Et la réponse naturelle de l’organisation, c’est… d’ouvrir le tableau.
On ajoute une colonne.
Puis une autre.
Puis une colonne “En validation”, une colonne “En attente”, une colonne “À relancer”, une colonne “En test”, une colonne “En UAT”, une colonne “En pré-prod”, une colonne “En prod mais pas vraiment”.
Le tableau devient magnifique. Très “process”. Très professionnel.
Et pourtant…
le problème est toujours là.
Parce que dans 80% des cas, ajouter des colonnes ne résout rien.
Ça décore.
Et si tu veux vraiment arrêter de subir, il faut comprendre une chose simple :
Les colonnes montrent le flux.
Les politiques font fonctionner le flux.
Le piège du tableau “vitrine”
Un tableau sans politiques, c’est comme :
- un codebase sans règles de merge,
- une route sans code de la route,
- un restaurant sans règles de service.
Ça a l’air organisé… jusqu’au premier pic de charge.
Tu peux avoir le plus beau Kanban du monde, si :
- n’importe qui peut déplacer une carte n’importe quand,
- “En cours” n’a pas de limite,
- “Urgent” est une zone de non-droit,
- “Terminé” signifie “j’ai poussé un commit”,
- personne ne sait ce qui fait entrer une carte dans une colonne…
Alors ton tableau ne pilote pas ton travail.
Il le raconte après coup.
Et souvent, il raconte une histoire fausse.
Colonnes : ce que tu vois. Politiques : ce qui décide.
Clarifions.
Une colonne sert à…
- visualiser un état,
- rendre un goulot visible,
- faciliter la coordination,
- mesurer (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”., cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”.).
Une colonne ne crée pas de décision.
Une politique sert à…
- décider quand on commence,
- décider quand on stoppe,
- décider qui fait quoi,
- décider ce qui est “terminé”,
- décider comment on gère une exception.
Une politique crée du comportement.
Et le Kanban, au fond, c’est ça :
designer un système qui influence le comportement sans hurler.
Exemple : “On est bloqués en validation”
Tu observes :
- une colonne “En validation” pleine à craquer,
- des cartes qui stagnent 5 jours,
- des livraisons qui s’étirent.
Le réflexe “colonne” :
- ajouter “En validation 1 / validation 2”
- ajouter “En attente validation”
- ajouter une couleur pour les bloqueurs
Ça peut aider à voir.
Mais ça ne change rien si derrière, il n’y a pas de politique.
La politique qui change tout, c’est par exemple :
- SLASLAun engagement formel (contrat / accord de service) avec conséquences éventuelles (pénalités, crédits…). de validation : 24h
- Règle : si validation > 24h, escalade automatique
- Règle : on ne peut pas commencer une nouvelle carte si 3 cartes attendent validation
Tu viens de faire un truc énorme :
tu as transformé une “zone d’attente” en engagement de service.
Sans ça, ta colonne “validation” est un parking.
Quand une colonne est utile (et quand elle est un cache-misère)
Une colonne est utile si :
- l’état est réel et observable,
- l’état demande une action différente,
- l’état correspond à une responsabilité ou un mode de travail spécifique,
- tu veux mesurer un temps précis (ex : attente de validation).
Une colonne est un cache-misère si :
- elle remplace une discussion de priorités,
- elle sert à “ranger” des cartes bloquées,
- elle évite de limiter 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.,
- elle fait croire à un processus alors qu’il n’y a pas de règles.
Le symptôme ultime :
“On a ajouté une colonne et rien n’a changé.”
Normal. Tu as mis un panneau “embouteillage”.
Tu n’as pas changé la circulation.
Le tableau qui “marche” a peu de colonnes… mais des règles claires
Si ton tableau a 12 colonnes, tu n’as pas un flux plus clair.
Tu as un flux plus compliqué.
Un tableau efficace, c’est souvent :
- 3 à 5 colonnes (À faire / En cours / En attente / Terminé)
- des 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. limits
- des politiques d’entrée/sortie
- une Definition of DoneDefinition of Doneconditions explicites pour considérer un item terminé.Ex : tests passés, PR mergée, doc mise à jour, déployé, validé…
- une voie d’urgence (expediteExpediteclasse de service qui court-circuite (presque) tout.) avec barrière
La maturité, ce n’est pas d’ajouter des cases.
C’est de rendre explicite ce qui était implicite.
Les 7 politiques qui valent mieux que 7 colonnes
Tu veux arrêter de décorer ?
Voici les politiques qui changent la vie.
1) Politique d’entrée (Definition of Ready)
Quand une carte a le droit d’entrer dans “À faire” ?
Ex :
- objectif clair,
- demandeur identifié,
- critères d’acceptation,
- taille raisonnable,
- dépendances listées.
Sans ça, tu fais entrer du flou.
Et le flou, c’est du 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. fantôme.
2) WIP limit (la vraie)
Pas “un jour on devrait”.
Un vrai chiffre.
- 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. = 3 (solo) / = équipe (voire moins)
Et surtout :
que se passe-t-il quand c’est plein ?
Ça, c’est une politique.
Ex :
- on termine,
- on débloque,
- on swarme,
- on ne “prend pas juste une petite carte”.
3) Politique de tirage (Pull)
Qui a le droit de tirer quoi, et quand ?
Ex :
- on tire uniquement depuis “Prêt”
- on tire le plus vieux item en premier (FIFO)
- exceptions documentées
Sans ça, tu fais du push déguisé.
4) Politique de blocage (Blocked)
Qu’est-ce qu’un 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…). ?
Et qu’est-ce qu’on fait quand c’est bloqué ?
Ex :
- carte marquée “bloquée” + raison écrite
- revue quotidienne des bloqueurs
- escalade si > 48h
Une colonne “Bloqué” sans politique = cimetière.
5) Politique d’urgence (Expedite)
Urgence = exception contrôlée.
Ex :
- 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. = 1 sur ExpediteExpediteclasse de service qui court-circuite (presque) tout.
- critères stricts (prod down, sécurité, paiement)
- décision par rôle (astreinte/lead)
- post-mortem léger obligatoire
Sinon “Urgent” devient une autoroute pour les plus bruyants.
6) Definition of Done
Le “Terminé” doit être incontestable.
Ex dev :
- testé, revu, déployé, communiqué
Ex support :
- résolu, vérifié, documenté, clôturé
Sans DoD :
tu te mens pour te soulager.
7) Politique de réapprovisionnement (Replenishment)
Quand et comment on remplit “À faire” ?
Ex :
- 2 fois par semaine, 30 min
- on choisit selon capacité et objectifs
- on garde un buffer d’imprévus
Sans ça, tu vis en réaction permanente.
Le moment où tu sais que tu as “décoré”
Tu as décoré un problème quand :
- ton tableau est plus beau qu’utile,
- les colonnes sont précises mais les règles sont floues,
- les cartes bougent… sans livrer plus vite,
- 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 haut mais “c’est normal”,
- tu ajoutes une colonne dès que ça coince.
C’est comme ajouter des étiquettes sur un placard en feu.
Le switch mental : d’un tableau “carte du monde” à un tableau “système”
Un tableau “carte du monde” décrit ce qui se passe.
Un tableau “système” influence ce qui se passe.
Et la bascule se fait avec une question simple :
“Quelle décision doit être prise ici ?”
Si une colonne n’entraîne aucune décision, elle est probablement de la déco.
Comment simplifier ton tableau dès demain
Tu veux un plan rapide ?
- Supprime une colonne (oui, vraiment)
- Remplace-la par une politique écrite en 1 phrase
- Ajoute un 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.-limit" target="_blank" rel="noopener" title="Voir la définition">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. limitWIPWIPle 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. Limitrègle explicite : “dans cette colonne, pas plus de X items”. sur “En cours”
- Ajoute une règle finish-first
- Clarifie “Terminé” (DoD)
- Mets une voie “Urgent” avec 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.=1
- Observe une semaine
Tu vas voir un truc surprenant :
moins de colonnes = plus de flow
(si, et seulement si, les politiques sont claires)
Conclusion : le vrai progrès, c’est l’explicite
Les colonnes, c’est ce que tu montres.
Les politiques, c’est ce que tu assumes.
Si ton tableau est un décor, il te rassure.
Si ton tableau est un système, il te confronte.
Et c’est exactement ce que tu veux.
Parce que l’objectif n’est pas d’avoir un tableau joli.
L’objectif, c’est de livrer plus vite, avec moins de stress, et moins de “on s’en occupe”.
Alors oui : garde des colonnes.
Mais arrête d’en faire un sapin de Noël.
Fais des politiques.
Et regarde ton organisation arrêter de hurler — sans que personne ait besoin de crier.


