Ça marchait en local.

Kanban et agents d'IA : ce que change le management visuel

Cet article s'adresse aux coachs, managers et équipes qui voient des agents d'IAProgramme piloté par un modèle d'IA qui agit seul dans les outils de l'équipe (messagerie, tickets, agenda) pour atteindre un objectif, au lieu de seulement répondre à une question. arriver sur leur tableau KanbanMéthode de gestion du flux de travail : on rend le travail visible sur un tableau, on limite ce qui est en cours et on améliore le flux en s'appuyant sur des mesures.. Il propose de relire le management visuelRendre le travail, l'attente et les blocages visibles pour tous, le plus souvent sur un tableau, afin de décider ensemble à partir de ce que l'on voit. à cette lumière : le tableau ne montre plus seulement qui fait quoi, il montre où l'attention humaine manque. Vous y trouverez des repères pour placer un agent dans le flux, régler les limites de travail en cours et choisir les bonnes mesures, ainsi qu'un schéma et un pense-bête.

Ce que le tableau apportait déjà

Un tableau Kanban rend visibles le travail, l'attente et les blocages. Le Guide Kanban (Vacanti et Coleman, édition de mai 2025, disponible en français)1 place au centre la définition du flux de travailDescription explicite et partagée du flux : ce qu'est un élément, où il commence et finit, ses états, comment le WIP est contrôlé, les règles de passage et l'attente de service.. Elle précise ce qu'est un élément, où il commence et où il finit, par quels états il passe, comment le WIPWork In Progress, travail en cours : tout élément démarré mais pas encore terminé. Plus il y en a, plus chaque élément attend longtemps. est contrôlé et quelles règles s'appliquent à chaque état. Elle comprend aussi une SLEAttente de niveau de service : une prévision de durée assortie d'une probabilité, par exemple « 85 % des éléments sont terminés en huit jours ou moins »..

Le guide demande quatre mesures de flux :

  • le WIP : les éléments démarrés mais non terminés ;
  • le débitNombre d'éléments terminés par unité de temps (par semaine, par exemple). C'est un simple comptage, pas une estimation. : les éléments terminés par unité de temps ;
  • l'âge des élémentsTemps écoulé depuis le démarrage d'un élément encore en cours. Il permet de repérer ce qui s'éternise avant que ce soit fini. : le temps écoulé depuis leur démarrage ;
  • le temps de cycleTemps écoulé entre le démarrage d'un élément et sa fin. Il se mesure sur des éléments terminés. : le temps entre le démarrage et la fin.

Rien de cela n'est propre à l'IA. Mais ce socle est exactement ce qui permet d'accueillir un agent sans perdre le fil.

Ce que l'IA déplace

Faire démarrer du travail est devenu facile. Le terminer, c'est-à-dire le relire, le tester et le valider, dépend toujours de personnes dont l'attention est limitée. Trois déplacements en découlent.

  • Le goulot d'étranglementÉtape qui limite le débit de tout le flux : le travail s'y accumule en amont, et l'aval attend. bouge. L'agent produit vite, la revue humaine non. Sans limite, la colonne « à relire » enfle.
  • Le WIP se compte autrement. Un élément reste un élément, même s'il mobilise plusieurs agents, des branches et des demandes de fusionProposition de modifier le code, soumise à relecture avant d'être intégrée au projet..
  • Les règles de passage deviennent une frontière. Elles disent ce qu'un agent peut faire seul, et ce qui exige une décision humaine (c'est l'approbation humaine« Human in the loop » : une personne valide une action avant que l'agent d'IA l'exécute, et reste responsable du résultat.).

Placer un agent dans le flux

Deux options existent. Un couloirLigne horizontale du tableau (swimlane) qui regroupe un type d'éléments ou un type d'acteur, par exemple les éléments confiés à un agent. dédié aux agents donne une vue d'ensemble de ce qui leur est confié. Une carte avec un avatar d'agent garde le flux unique et montre qui pilote. Dans les deux cas, l'important tient en trois points :

  • un humain nommé reste responsable de chaque élément, même confié à un agent ;
  • les critères de sortieRègle qui dit à quelles conditions un élément peut quitter une colonne pour passer à la suivante. Dans le Guide Kanban, on parle de politiques explicites. sont écrits pour chaque colonne : tests passés, périmètre respecté, sources citées. Le Guide Kanban parle de politiques explicites ;
  • la décision de démarrer reste collective et se prend au tableau, pas dans l'outil de l'agent.
Tableau Kanban avec un couloir d'agents, une colonne « à relire » qui déborde et une limite commune « en cours + à relire » À faireEn cours À relireEn relectureTerminé COULOIR AGENTSCOULOIR ÉQUIPE LIMITE COMMUNE : EN COURS + À RELIRE CarteAgentAgent AgentAgentAgent CarteCarte
Les agents remplissent la colonne « à relire » plus vite que les humains ne la vident. Une limite commune « en cours + à relire » (pointillés épais) oblige à arrêter de démarrer et à relire d'abord.

Limiter le WIP par l'attention humaine

Dans un billet du 22 juillet 2026, Yuval Yeret2 défend que les limites doivent refléter la capacité d'attention humaine, pas le nombre d'agents. Les agents ne sont pas surchargés : les personnes le sont. Chaque fonctionnalité ajoutée augmente aussi le coût de changement de contexte pour l'humain qui la guide. Voici ce que l'on peut en retenir.

  • Compter l'élément une seule fois. Sous-tâches, branches et demandes de fusion sont des signaux de flux, pas des éléments en plus.
  • Ne pas multiplier par le nombre d'agents. Yeret propose de partir d'une fonctionnalité activement guidée par équipe de bout en bout, et de n'en ajouter une deuxième que sur de bonnes raisons.
  • Plafonner ensemble « en cours » et « à relire ». Une limite commune évite que la file de revue serve de réservoir.
  • Ne jamais démarrer « parce qu'un agent est libre ». Une limite n'a de valeur que par la règle appliquée quand elle est atteinte : on relit, on aide, on débloque.
  • Expérimenter. Yeret suggère des essais de deux à quatre semaines, en resserrant si l'âge des éléments ou les retours en arrière augmentent. Ses valeurs chiffrées viennent de son exemple, pas d'une règle générale.

La loi de LittleRelation entre le travail en cours, le débit et le temps de cycle : plus il y a de travail en cours pour un même débit, plus les éléments mettent de temps à sortir. sert de contrôle de cohérence : un WIP très supérieur au débit multiplié par le temps de cycle souhaité mérite un examen. C'est un repère, pas un outil de précision.

Les mesures qui disent la vérité

La vitesse de l'agent flatte, mais elle ne dit rien du flux. Regardons plutôt :

  • l'âge des éléments en attente de relecture : c'est le premier signal d'alerte ;
  • le temps de cycle de bout en bout, du démarrage à la mise à disposition ;
  • le débit d'éléments réellement terminés, pas de propositions produites ;
  • le WIP total, pour vérifier que la limite tient.

Une lecture systémique

Sans limite, une boucle de renforcementBoucle de rétroaction qui amplifie un phénomène : plus il y en a, plus il y en aura. Elle accélère une dynamique, bonne ou mauvaise. s'installe : plus d'agents, plus de choses à relire, moins d'attention par élément, plus d'erreurs qui passent, donc plus de reprises et encore moins d'attention. Chaque étape paraît raisonnable, et l'effet différéConséquence qui apparaît longtemps après l'action, ailleurs ou chez quelqu'un d'autre. Ce décalage empêche de relier la cause à l'effet. masque le tout : les erreurs apparaissent plus tard, ailleurs. L'article sur les boucles cachées de l'IA dans une équipe décrit cette dynamique.

Pour la casser, il suffit d'agir sur le point où l'attention se joue : la limite commune, la règle « on relit avant de démarrer » et la visibilité de l'âge des éléments. Le rôle du coach ou du Scrum MasterRôle de l'équipe Scrum qui l'aide à appliquer Scrum, à lever ses obstacles et à progresser. Il facilite et coache, il ne commande pas. est de rendre cela discutable en équipe. Comme dans l'article sur le travail caché du Scrum Master, la coordination est un travail à ne pas laisser implicite. Pour les agents dans le développement, voir aussi BMAD expliqué aux coachs agiles.

Regard critique

  • Forces : le tableau est un outil déjà connu, qui ne demande pas de nouvelle méthode. Il rend l'attention humaine visible et décidable collectivement.
  • Limites : les repères de Yeret viennent d'un praticien et d'un exemple, pas d'une étude contrôlée. Un tableau ne dit rien de la qualité d'une relecture : on peut vider « à relire » en validant sans lire.
  • Vigilance : les outils Kanban ajoutent des agents qui déplacent ou créent des cartes. Il faut garder la décision de démarrer et de clore aux humains, sinon le tableau devient un tableau de bord de machines.

Le pense-bête

Pratique En une ligne
Humain responsable Un nom par élément, même confié à un agent
Critères de sortie Écrits pour chaque colonne, y compris pour les agents
Couloir ou avatar Rendre les agents visibles sur le tableau
Un élément, un compte Branches et demandes de fusion ne comptent pas en plus
Limite par l'attention Pas de multiplication par le nombre d'agents
Limite commune « En cours + à relire » sous un même plafond
Pas de démarrage opportuniste Un agent libre n'est pas une raison de démarrer
Revue de la limite Essai de deux à quatre semaines, puis ajustement
Mesure Ce qu'elle dit
WIP Combien d'éléments sont ouverts
Débit Combien sont vraiment terminés
Âge des éléments Ce qui s'éternise, surtout avant relecture
Temps de cycle La durée de bout en bout

Sources

  1. Le Guide Kanban, édition 2025.5, Daniel Vacanti et John Coleman, mai 2025. Le texte de référence, court et disponible en français : la définition du flux de travail, les trois pratiques et les quatre mesures de flux (WIP, débit, âge des éléments, temps de cycle). ↑

  2. Do WIP Limits Still Make Sense When Agents Write the Code?, Yuval Yeret, 22 juillet 2026, en anglais. Un praticien explique pourquoi les limites WIP doivent suivre l'attention humaine quand des agents écrivent le code, avec des repères concrets pour les fixer. ↑

← Tous les articles