Je me souviens d’un tableau Kanban que j’ai vu un jour en prod.
Il était magnifique.
Couleurs propres, colonnes bien alignées, étiquettes nickel, tout le monde y mettait ses tickets. Le manager le montrait en réunion comme on montre une vitrine Apple.
Et pourtant… le chaos était total.
Les cartes restaient “En cours” pendant trois semaines.
Les urgences doublaient la file en douce.
Les “Done” n’étaient pas vraiment done (juste “dev fini”… sans test, sans déploiement, sans validation).
Et chaque jour, la même phrase revenait :
“On la passe où, celle-là ?”
Le problème n’était pas le tableau.
Le problème, c’est que le tableau n’avait pas de règles.
Ou plutôt : il avait des règles, mais dans la tête de chacun.
Et ça, c’est la meilleure façon de faire un système où :
- personne n’est d’accord,
- tout le monde a raison,
- et le travail n’avance pas.
Bienvenue dans le sujet du jour : les politiques explicites.
La question la plus simple et la plus puissante d’un bon tableau :
“Quand une carte peut passer en colonne suivante ?”
Un tableau Kanban, c’est un système. Pas un décor.
Un tableau, ce n’est pas une photo du travail.
C’est un contrat social :
- comment on démarre,
- comment on priorise,
- comment on bloque,
- comment on finit,
- comment on valide,
- comment on mesure.
Si ce contrat n’est pas écrit, il existe quand même… mais sous forme de :
- non-dits,
- habitudes,
- exceptions “juste cette fois”,
- arbitrages au feeling.
Et à la fin, le tableau devient un mensonge élégant.
“Politiques explicites” : c’est quoi exactement ?
Une politique explicite, c’est une règle visible, claire, partagée, qui dit :
- ce qu’on accepte d’entrer dans une colonne (critères d’entrée),
- ce qu’il faut pour en sortir (critères de sortie),
- qui décide en cas de doute,
- ce qu’on fait quand c’est bloqué,
- parfois combien on autorise (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.),
- parfois quel service on rend (SLESLEun engagement probabiliste basé sur l’historique :, urgence, etc.).
En clair : on remplace la négociation permanente par des règles simples.
Et la magie, c’est que ça fait deux choses en même temps :
- Ça réduit les frictions (“on la met où ?” disparaît)
- Ça rend les problèmes visibles (quand une carte ne passe pas, on sait pourquoi)
Pourquoi “Quand une carte peut passer ?” change tout
Parce que la plupart des dysfonctionnements viennent des transitions.
Ce n’est pas “faire le travail” qui coince.
C’est :
- quand on dit qu’il est prêt à démarrer,
- quand on dit qu’il est fini,
- quand on le donne à quelqu’un d’autre,
- quand on le considère “validé”.
Sans règles, chaque passage de colonne devient :
- une discussion,
- un rapport de force,
- ou un glissement silencieux.
Et le tableau cesse d’être un outil de pilotage.
Il devient une “to-do list décorée”.
Les 6 colonnes classiques… et ce qu’on oublie presque toujours d’écrire
Je te propose un tableau très standard (IT friendly) :
- Backlog
- Prêt
- En cours
- Revue / Test
- Prêt à livrer
- Terminé
Tu peux appeler ça autrement, mais l’idée est la même : chaque colonne doit avoir sa définition.
1) Backlog : la réserve, pas la poubelle
Erreur classique : tout mettre dans backlog, y compris les idées floues, les demandes pas qualifiées, les “on verra”.
Politique explicite utile :
- On met dans Backlog uniquement ce qui a un demandeur identifié et une valeur attendue.
- Si c’est flou : ça va dans une zone “Idées” (séparée) ou ça n’existe pas encore.
Question simple :
👉 “Si on fait ça, qui sera content ? et comment on le saura ?”
2) Prêt : la colonne la plus sous-estimée
C’est LA colonne qui évite de démarrer du travail bancal.
Politique de sortie (pour passer en En cours) :
- objectif clair (une phrase),
- critères d’acceptation (même simples),
- dépendances identifiées,
- taille raisonnable (sinon découpage),
- priorité assumée (quelque chose sort si autre chose entre).
Erreur classique : confondre “prêt” avec “prioritaire”.
Un ticket peut être prioritaire… et pas prêt. Et si tu le démarres quand même, tu fabriques une future carte bloquée.
3) En cours : la colonne qui ment le plus souvent
Parce qu’elle devient vite : “tout ce qu’on a touché une fois”.
Politique explicite indispensable :
- Une carte “En cours” = quelqu’un travaille dessus activement.
- Si personne ne la touche depuis X jours (ex : 2 jours ouvrés), elle doit être :
- soit bloquée avec raison,
- soit remise en Prêt,
- soit découpée.
Ajoute une règle d’âge :
👉 “Toute carte En cours doit avoir une trace d’avancement depuis 48h.”
(Ça pique un peu au début. Puis ça sauve la vie.)
4) Revue / Test : la fabrique des embouteillages
C’est souvent là que le flux se transforme en parking.
Politiques utiles :
- Une carte entre en Revue uniquement si :
- le travail est terminé selon 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é… dev”
- elle est testable (environnement, données, steps)
- La carte sort de Revue si :
- critères d’acceptation validés
- pas de bug bloquant
- le demandeur (ou représentant) a donné un GO si nécessaire
Erreur classique : “Revue” = “j’ai poussé une PR”.
Non : une PR, c’est une étape. La question c’est : qui l’a relue ? quand ? selon quel standard ?
5) Prêt à livrer : la zone “on attend le train”
Déploiement planifié, fenêtre de maintenance, validation finale…
Politique explicite :
- Une carte est “Prête à livrer” si :
- packaging OK
- rollback identifié si besoin
- communication prévue si impact utilisateur
- Elle sort de là quand :
- livrée en prod (ou livrée au client)
- monitoring minimal en place si risque
Erreur classique : “Done” sans livraison.
Si ton système dit “Done” mais que l’utilisateur ne voit rien, tu es en train de t’auto-hypnotiser.
6) Terminé : “Terminé” veut dire quoi ?
Écris-le. Vraiment.
Exemples de “Terminé” possibles :
- ✅ déployé + validé par demandeur
- ✅ mis en prod + observé 24h sans incident
- ✅ livré + doc mise à jour + communication faite
Erreur classique : Done = “plus mon problème”.
La méthode simple : définir la règle en une phrase par colonne
Si tu ne devais garder qu’un format, prends celui-ci :
“Une carte peut entrer ici quand… / Une carte peut sortir d’ici quand…”
Et tu l’écris directement sur le tableau :
- sous le titre de colonne,
- sur une “policy card” épinglée,
- ou dans la description du tableau si ton outil le permet.
Exemple (copier-coller)
Prêt → En cours
- Entrée : demande claire + critères d’acceptation + dépendances identifiées
- Sortie : quelqu’un s’engage dessus maintenant (pas “quand j’ai le temps”)
En cours → Revue/Test
- Entrée : implémentation terminée + tests unitaires/tech OK + comment tester
- Sortie : revue faite + critères d’acceptation validés
Revue/Test → Prêt à livrer
- Entrée : OK QA / OK fonctionnel
- Sortie : déploiement planifié / fenêtre validée
Prêt à livrer → Terminé
- Entrée : package prêt + rollback + comm prête
- Sortie : livré + vérifié + demandeur informé
Les erreurs classiques (et comment les corriger)
Erreur 1 — “On improvisera”
Traduction : “On va se battre au moment du passage.”
Correction : écris des règles minimales, puis améliore-les toutes les 2 semaines.
Erreur 2 — “Les règles sont trop rigides”
Souvent dit par quelqu’un qui aime bien les exceptions.
Correction : autorise l’exception, mais rends-la visible :
- carte “ExpediteExpediteclasse de service qui court-circuite (presque) tout.” (urgence) avec règle spéciale,
- ou politique : “une seule urgence à la fois”.
Le but n’est pas d’interdire la réalité.
Le but est d’empêcher la réalité de devenir un système.
Erreur 3 — “Done = dev terminé”
Classique en IT : le dev a fini, mais le travail n’a pas délivré de valeur.
Correction : distingue “Done dev” et “Done service”.
Ou ajoute “Prêt à livrer”.
Erreur 4 — “On a des colonnes par équipe”
Ex : “Dev”, “QA”, “Ops”, “Métier”.
Ça décrit ton organigramme, pas ton flux.
Et ça crée des files d’attente invisibles (“j’attends QA”).
Correction : colonnes = étapes de valeur.
Et les équipes se coordonnent via politiques + 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. + règles de pull.
Erreur 5 — “On n’a pas de colonne Bloqué”
Du coup, on laisse pourrir en En cours.
Correction : une règle simple :
- si bloqué > 1 journée : marque “Bloqué” + raison + date
- et ça devient un sujet de daily (pas un secret honteux)
Erreur 6 — “Le tableau est trop complexe”
Parfois on écrit 18 règles, 12 exceptions, 6 statuts, 5 tags obligatoires…
Correction : commence petit :
- 1 phrase par colonne
- 1 règle d’urgence
- 1 règle de 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…).
- 1 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”
Tu n’écris pas un code de la route complet.
Tu poses des panneaux là où il y a des accidents.
Exemples concrets selon le type de travail
Support / Incident
- “Prêt” = impact + priorité + reproduction + logs
- “Done” = correctif livré + communication utilisateur + post-mortem si nécessaire
- Urgence = 1 seule carte “ExpediteExpediteclasse de service qui court-circuite (presque) tout.” max
Dev produit
- “Prêt” = user story compréhensible + critères d’acceptation
- “Revue” = PR relue + tests verts + feature flag si besoin
- “Done” = en prod + métrique surveillée
Contenu / Marketing
- “Prêt” = brief + cible + angle + CTA
- “Revue” = relecture + SEO check + conformité
- “Done” = publié + partagé + suivi perf J+7
Administratif
- “Prêt” = documents complets + responsable identifié
- “En cours” = action en cours réelle (pas “je l’ai imprimé”)
- “Done” = validé / signé / archivé
Même logique, autres critères : le tableau devient un vrai système de travail.
Le bonus qui fait passer ton tableau de “bien” à “pilotable” : les politiques de priorité
Sans politique de priorité, tu as un backlog qui crie.
Ajoute une règle simple :
- qui décide la priorité (PO ? manager ? rotation ? triage ?)
- à quelle fréquence on re-priorise (hebdo ? daily triage support ?)
- ce qui rentre en premier quand tout est urgent
Exemple :
- Support : priorité = impact × urgence, triage 2 fois par jour
- Produit : priorité = objectif de sprint / engagement, revue hebdo
Checklist rapide : ton tableau est “politiques explicites ready” si…
- Chaque colonne a une définition visible
- Chaque transition importante a des critères de sortie
- Les urgences ont une règle dédiée
- Les blocages sont visibles (raison + date)
- “Done” est défini comme une valeur livrée, pas une intention
- Vous avez une règle pour éviter les cartes “En cours” fantômes
Conclusion : un bon tableau ne juge pas les gens. Il élimine les débats inutiles.
Les politiques explicites, ce n’est pas de la bureaucratie.
C’est l’inverse.
C’est ce qui permet à une équipe de ne plus perdre son énergie à discuter :
- “c’est prêt ou pas ?”
- “c’est fini ou pas ?”
- “on peut la passer ou pas ?”
Et de remettre cette énergie là où elle compte :
faire avancer le flux, livrer, apprendre, améliorer.
Si tu veux une phrase à coller au-dessus de ton tableau :
“Si on n’est pas d’accord sur ‘prêt’ et ‘fini’, on ne pilote rien.”
Et toi, sur ton tableau actuel :
c’est quoi la règle la plus floue ? (le “prêt”, le “done”, ou les urgences ?)
