Agilité

Swimlanes utiles vs swimlanes décoratives.

Tasko
📖 11 min de lecture 👁 6 vues

Je me souviens très bien de mon premier “tableau Kanban sérieux”.

On avait mis des colonnes propres, des couleurs, des étiquettes… et des swimlanes partout.
Le résultat ? Un tableau qui ressemblait à un tableau de bord d’avion. Impressionnant. Inutilisable.

Parce qu’une 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). n’est pas un élément de design.
C’est un choix de pilotage.

Si elle répond à une question importante (“où sont nos urgences ?”, “quel produit prend tout l’oxygène ?”), elle vaut de l’or.
Si elle ne répond à rien… c’est juste une grille de plus à scroller.

Une swimlane, c’est une question (pas une catégorie)

La règle la plus simple que je connaisse :

Si ta 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). ne répond pas à une question que tu te poses chaque jour, supprime-la.

Une bonne 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). te permet, en un coup d’œil, de voir quelque chose que les colonnes ne montrent pas bien.

  • Les colonnes racontent le flux (À faire → En cours → Fini)
  • Les swimlanes racontent une dimension de pilotage (produit, type de demande, urgence, etc.)

Si tu utilises les swimlanes pour “ranger” alors que le flux suffit… tu crées juste de la complexité.

Les swimlanes utiles (celles qui font gagner du temps)

1) Swimlanes par produit (quand tu gères plusieurs fronts)

Question à laquelle ça répond : “Quel produit nous mange la capacité ?”

Typiquement utile si :

  • tu as plusieurs produits/modules (Produit A / Produit B / Produit C)
  • tu partages une même équipe (dev, support N2, intégration, data…)
  • tu veux éviter l’illusion “on avance partout” alors qu’un seul produit absorbe tout

Bon usage :

  • 3 à 5 lanes max (au-delà, tu perds la lecture)
  • une lane “Autres” si nécessaire (sinon tu crées 12 produits et plus personne ne sait où mettre quoi)

Attention :

  • si une carte touche 2 produits, choisis le produit “impact client” (et note l’autre en tag/étiquette)
  • sinon tu vas ouvrir la porte au classique : “je ne sais pas où la mettre” → et le tableau devient un débat permanent

2) Swimlanes par type de demande (Run / Change / Projet)

Question : “Est-ce qu’on est en train de mourir sous le Run ?”

Souvent, en IT, tu as au moins 2 réalités :

  • le Run (incidents, correctifs, demandes récurrentes)
  • le Change/Projet (évolutions, refonte, nouvelles features)

Mettre ça en swimlanes, c’est rendre visible un problème fréquent :
le projet qui avance “quand on a le temps” (donc jamais).

Bon usage :

  • Lanes : Run / Projets (ou Support / Produit)
  • Et surtout : 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. explicite par lane (sinon Run déborde et dévore tout)

3) Swimlanes par urgence (classes de service)

Question : “Où sont les vraies urgences… et est-ce qu’on en abuse ?”

C’est LA 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). qui peut sauver une équipe… ou la détruire si elle est mal utilisée.

Le piège : faire une 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). “URGENT” et y mettre tout ce qui crie le plus fort.

La version utile consiste à définir une politique claire, par exemple :

  • ExpediteExpediteclasse de service qui court-circuite (presque) tout. : incident prod bloquant / risque majeur / engagement légal
  • Standard : le flux normal
  • Date fixe : échéance connue (mise en prod, audit, fin de contrat…)

Règle d’or :

  • la lane ExpediteExpediteclasse de service qui court-circuite (presque) tout. doit être rare
  • souvent limitée à 1 item à la fois
  • et doit déclencher un comportement (“on stoppe, on swarme, on finit”)

Sinon tu ne gères plus des urgences : tu gères une culture de la panique.

Les swimlanes décoratives (et les erreurs classiques)

❌ 1) “Swimlanes par personne”

Ça fait rassurant (on “voit qui fait quoi”).
Mais ça casse l’idée même de Kanban : le travail traverse un système, il n’appartient pas à quelqu’un.

Effet secondaire :

  • chacun “gère sa lane”
  • plus personne ne swarme
  • tu as 4 lanes bloquées au lieu d’un flux collectif

Si tu veux visualiser l’assignation : utilise une étiquette, une photo, ou un champ responsable — pas une 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)..

❌ 2) “Swimlanes par priorité”

Priorité haute, moyenne, basse… et tout finit en “haute”.

Parce que la priorité est souvent une opinion (qui change), pas une politique.
Et ça n’aide pas à piloter le flux : ça crée juste un tableau qui dit “tout est important”.

Si tu as besoin de prioriser :

  • fais-le au point d’entrée (commitment point)
  • garde un “ReadyReadyétat où l’item est suffisamment clair pour être commencé sans découvrir un manque critique au bout de 30 minutes.” clair
  • 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.
  • et utilise une vraie lane “ExpediteExpediteclasse de service qui court-circuite (presque) tout.” avec des règles

❌ 3) “Swimlanes qui dupliquent les colonnes”

Exemple : lanes = “À faire / En cours / Terminé” et colonnes = pareil.

Tu viens d’inventer un tableau en 2D qui raconte deux fois la même chose… en moins lisible.

❌ 4) “Swimlanes pour faire joli (ou pour imiter un template)”

Classique sur Trello / Jira / Azure DevOps / ServiceNow :
tu trouves un template, tu copies les lanes… puis personne n’utilise les règles implicites.

Une 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). sans politique d’entrée = décoration.

Un test simple pour savoir si ta swimlane sert à quelque chose

Pose ces 3 questions :

  1. Quelle décision je prends grâce à cette 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). ?
    (Ex : “on a trop d’expediteExpediteclasse de service qui court-circuite (presque) tout.”, “produit B siphonne tout”, “le Run étouffe le projet”)
  2. Qu’est-ce que je ne voyais pas avant ?
    Si la réponse est “rien, mais c’est plus rangé”, c’est suspect.
  3. Quelle règle s’applique quand une carte est dans cette lane ?
    (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. spécifique, SLASLAun engagement formel (contrat / accord de service) avec conséquences éventuelles (pénalités, crédits…). différent, traitement prioritaire, etc.)

Si tu n’as pas une réponse claire à (3), ta 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). est probablement cosmétique.

Concevoir un bon tableau : la méthode qui évite 80% des erreurs

Étape 1 — Dessine le flux avant le tableau

Avant de parler lanes, clarifie :

  • où le travail arrive (source)
  • quand tu “t’engages” (commitment point)
  • ce que signifie “terminé” (vraiment)

Les swimlanes viennent après.

Étape 2 — Commence sans swimlanes (oui, vraiment)

Lance un tableau simple pendant 1 à 2 semaines.

Puis observe :

  • qu’est-ce qui se mélange et devient illisible ?
  • qu’est-ce qui crée des conflits de priorité ?
  • qu’est-ce qui mérite une vue séparée ?

Tu ajoutes des swimlanes pour résoudre un problème constaté, pas pour anticiper.

Étape 3 — Ajoute 1 seule dimension de swimlane

Une seule.
Deux au maximum si tu es très solide (sinon tu crées une matrice ingérable).

Si tu veux produit + urgence + type de demande :
tu es en train de fabriquer un outil de reporting, pas un système de flux.

Étape 4 — Écris les politiques directement sur le tableau

Exemples concrets :

  • “ExpediteExpediteclasse de service qui court-circuite (presque) tout. : max 1 item, doit être qualifié par X, swarm obligatoire”
  • “Run : 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. max 3”
  • “Produit A : 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. max 2 tant que le 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”. > 10 jours”

Sans règles visibles, les lanes dérivent.

Exemples “qui parlent à tout le monde”

Support / Helpdesk

  • Lanes : Expedite (prod down) / Standard
  • Objectif : protéger l’équipe contre l’urgence permanente
  • Indicateur : combien d’expediteExpediteclasse de service qui court-circuite (presque) tout. par semaine (si ça explose, c’est un problème de qualité/système)

Équipe produit / dev

  • Lanes : Produit A / Produit B / Tech (dette)
  • Objectif : éviter que “la dette” soit toujours repoussée, ou qu’un produit monopolise tout

Contenu / marketing

  • Lanes : Demandes internes / Calendrier éditorial
  • Objectif : empêcher les “tu peux me faire un truc vite fait ?” de détruire la production planifiée

Administratif / gestion

  • Lanes : Échéance fixe / Standard
  • Objectif : sécuriser les deadlines (URSSAF, paie, audits, renouvellements) sans basculer en stress permanent

La conclusion (un peu piquante, mais utile)

Un bon tableau Kanban n’est pas celui qui a le plus de lignes et de couleurs.
C’est celui qui te permet de dire :

  • “Voilà où ça bloque.”
  • “Voilà ce qu’on traite en priorité (avec une règle, pas un ressenti).”
  • “Voilà ce qui est en train de bouffer notre capacité.”
  • “Voilà pourquoi on n’avance plus.”

Les swimlanes sont un amplificateur :
elles amplifient soit ta clarté… soit ton chaos.

Mini-checklist avant de valider tes swimlanes

  • Chaque 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). répond à une question quotidienne
  • Chaque lane a une politique d’entrée (et idéalement 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.)
  • Tu as 3 à 5 lanes max
  • Tu peux expliquer en 30 secondes à un nouveau “à quoi ça sert”
  • Si tu les enlèves, tu perds une info de pilotage (pas juste du “rangement”)

3 exemples de tableaux prêts à recopier

(parce qu’on est franchement des gens bien)

1) Tableau Support / Helpdesk (anti-panique)

Colonnes (flux)

  1. À qualifier (triage)
  2. Prêt (readyReadyétat où l’item est suffisamment clair pour être commencé sans découvrir un manque critique au bout de 30 minutes. / engagé)
  3. En cours
  4. En validation (retour user / test / confirmation)
  5. Terminé
  6. (Optionnel) Bloqué (ou tag “Bloqué”)

WIP conseillé

  • En cours : 3 (pour une petite équipe)
  • En validation : 3
  • ExpediteExpediteclasse de service qui court-circuite (presque) tout. : 1 (voir 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).)

Swimlanes (2 lanes max)

  • ExpediteExpediteclasse de service qui court-circuite (presque) tout. (Prod down / critique)
  • Standard

Politiques (simples, visibles)

  • Une carte n’entre en “ExpediteExpediteclasse de service qui court-circuite (presque) tout.” que si :
    • service indisponible / incident majeur / risque sécurité immédiat
    • ou engagement contractuel qui saute aujourd’hui
  • ExpediteExpediteclasse de service qui court-circuite (presque) tout. = max 1 carte et swarm obligatoire (on stoppe le reste sauf urgence équivalente)
  • “À qualifier” = pas 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. strict, mais revue 2x/jour (sinon ça devient un cimetière)

Définition de “Prêt”

  • Impact décrit + reproduction (si bug)
  • Priorité confirmée (Standard ou ExpediteExpediteclasse de service qui court-circuite (presque) tout.)
  • Interlocuteur identifié (qui valide la fin)

Exemples de cartes réalistes

  • “Erreur 500 sur page de login (repro + logs)”
  • “Accès VPN impossible pour 12 agents”
  • “Ajout d’un compte + droits pour nouvel arrivant”
  • “Demande export RGPD (échéance J+7)”

✅ Ce que tu gagnes : tu rends visible la vraie urgence sans laisser l’urgence devenir une catégorie fourre-tout.

2) Tableau Produit / Dev (éviter le “tout est important”)

Colonnes (flux)

  1. Discovery (besoin / cadrage)
  2. Prêt dev (DoR OK)
  3. Dev
  4. Code review
  5. Test / QA
  6. Prêt prod
  7. En prod
  8. Terminé (valeur confirmée)

WIP conseillé

  • Dev : 4
  • Code review : 3 (sinon tu crées un bouchon caché)
  • Test/QA : 3
  • Prêt prod : 5 (si ça monte, tu as un problème de déploiement)

Swimlanes possibles (choisir 1 dimension)

Option A — par produit (si multi-produit)

  • Produit A
  • Produit B
  • Tech / dette (lane dédiée, sinon elle meurt)

Option B — par type de demande

  • Bugs
  • Features
  • Dette technique

(N’essaie pas de faire A + B : tu vas fabriquer une matrice illisible.)

Politiques utiles

  • Lane “Tech/dette” protégée : 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. mini (ex : 1) obligatoire sinon la dette ne passe jamais
  • Bugs : si “P1” (impact prod), passent en ExpediteExpediteclasse de service qui court-circuite (presque) tout. uniquement si règle respectée
  • Prêt dev : histoire découpée (≤ 2-3 jours), critères d’acceptation écrits

Exemples de cartes

  • “Paiement : gérer le cas ‘carte expirée’ (critères)”
  • “Refacto : supprimer endpoint legacy /v1”
  • “Bug : doublon de notification sur iOS”
  • “Perf : réduire temps de chargement tableau < 1,5s”

✅ Ce que tu gagnes : le tableau te dit où passe la capacité (produit ? bugs ? dette ?) sans débat permanent.

3) Tableau Équipe transverse / Intégration (projets + run mélangés)

C’est le cas typique “on fait du projet, du support, des demandes métiers, de la data… tout”.

Colonnes (flux)

  1. Entrée (demande reçue)
  2. Analyse (qualification)
  3. Prêt (engagé)
  4. Build / Config
  5. Test
  6. Livraison / Déploiement
  7. Terminé

WIP conseillé

  • Analyse : 2 (sinon tu analyses tout, tu ne livres rien)
  • Build/Config : 3
  • Test : 2
  • Livraison : 2

Swimlanes (classes de service — très efficaces ici)

  • Date fixe (deadline non négociable)
  • Standard
  • Amélioration continue (petites optimisations / dette / automatisation)

Politiques

  • Date fixe : une carte doit afficher la date dans le titre + critère “go/no-go”
  • Amélioration continue : 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. mini garanti (ex : 1 carte en permanence)
  • Entrée → Analyse : pas automatique ; revue quotidienne de l’entrée (sinon l’entrée devient un backlog infini)

Exemples de cartes

  • “Interface : mapper champ X → Y pour l’appli métier (avec exemples)”
  • “Automatiser export CSV quotidien (cron + logs)”
  • “Demande métier : ajout d’un filtre + droits”
  • “Mise en conformité : purge données (deadline 31/03)”

✅ Ce que tu gagnes : tu protèges les deadlines sans transformer tout en urgence, et tu évites que l’amélioration continue disparaisse.

Règles universelles (qui rendent n’importe quel tableau “bon”)

  • Swimlanes = 1 question de pilotage. Si tu ne sais pas la formuler, supprime.
  • 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. visible là où ça bloque (souvent Dev/Test/Review).
  • Politiques écrites : “quand une carte a le droit d’entrer ici ?”
  • Un point d’engagement clair : la colonne “Prêt” est ton garde-fou.

Implémentation rapide dans VulTask (sans te compliquer la vie)

  • Swimlanes : produit / classe de service (Date fixe, Standard…)
  • Tags : Bloqué, Incident, Dette, P1/P2
  • Champs utiles : “Date fixe”, “Responsable validation”, “Service impacté”
  • Automatisation simple : quand “Terminé” → demander “validation client ?” ou déplacer en “En validation”

Tags #Concevoir un bon tableau Kanban (et les erreurs classiques)

📚 Articles similaires

Comment définir une urgence sans devenir une organisation qui hurle

13 février 2026

Agilité : passer de l’intention à l’action (avec un tableau Kanban… et Vultask.fr)

15 février 2026

Arrêter de commencer, commencer à finir

18 février 2026

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *