Kanban applique : comment nous organisons la conception

Notre board a 5 colonnes et des limites strictes. Pas un board Trello avec 47 cartes eparpillees et un sentiment vague d'avancement. Un système ou chaque colonne a un nombre maximum de tâches, ou chaque plugin en cours a un état clair, et ou on ne prend jamais plus de 2 projets en parallèle.

Le Kanban vient du système de production Toyota. David Anderson l'a adapte au logiciel en 2010. L'étude Rubinstein, Meyer et Evans (APA, 2001) mesure une perte de productivité de 20 a 40% quand on bascule entre des tâches complexes. Gloria Mark, a l'UC Irvine, confirme : 23 minutes pour retrouver sa concentration après une interruption. Et McKinsey observe que l'état de flow multiplie la productivité par 5, mais qu'il exige une attention soutenue sans coupure. Le calcul est simple : chaque projet supplémentaire en parallèle coute plus qu'il ne rapporte.

Les 5 colonnes de notre Kanban

Notre board reflete les 5 phases du service PluginFactory. Chaque colonne correspond a une étape reelle du workflow, pas a une abstraction générique.

Audit (WIP : 2)

C'est la porte d'entrée. L'audit comprend la lecture du codebase client, les entretiens avec les devs, et l'analyse des workflows existants. Limite a 2 parce qu'un audit demande une immersion totale dans le contexte du client. Impossible de lire deux codebases en parallèle avec la même qualité d'attention. C'est le même principe que quand on construit un bon processus : la contrainte créé la qualité.

Conception (WIP : 2)

L'architecture du plugin prend forme ici. On definit les skills, hooks, agents ou serveurs MCP nécessaires. On choisit les patterns, on redige la spec technique. La limite de 2 protege la phase la plus exigeante cognitivement. La conception d'un plugin demande de garder en tête le contexte complet du client : sa stack, ses conventions, ses contraintes CI/CD. Basculer entre deux contextes clients est déjà un effort. Trois serait du sabotage.

Développement (WIP : 2)

L'implémentation proprement dite. On code les skills, on configure les hooks, on integre les MCP servers. La limite de 2 ici est stratégique : le dev d'un plugin touche directement au codebase du client. Les erreurs a ce stade sont couteuses. Mieux vaut deux projets bien exécutés qu'un troisième bacle.

Test (WIP : 3)

Les plugins passent en validation sur le vrai codebase du client. On mesure le temps economise, les erreurs detectees, le taux d'adoption par l'équipe. La limite monte a 3 parce que les tests sont partiellement asynchrones : on attend des retours d'équipe, des metriques qui s'accumulent, des cas d'usagé reels. Le WIP de 3 permet de tester un plugin pendant que deux autres finissent leur phase de mesure.

Déploiement (WIP : 2)

La livraison finale : documentation, formation de l'équipe, mise en production du plugin. La limite redescend a 2 parce que le déploiement demande de la coordination directe avec le client. Chaque déploiement inclut une session de training pour que l'équipe soit autonome.

Pourquoi 2 projets max en parallèle

Le plafond global est simple : jamais plus de 2 projets clients actifs en même temps. C'est peu. C'est voulu.

Anderson documente ce phénomène dans ses cas d'étude : les équipes qui limitent leur WIP livrent plus de résultats finis, pas moins. Un WIP de 2 signifie que chaque client recoit une attention complete. On ne répond pas "je reviens vers vous lundi" parce qu'on est submerge par un troisième projet. On livre dans les delais, et la qualité ne negocie pas.

C'est aussi un signal commercial. Quand un prospect nous contacte et que nos 2 slots sont pris, on le dit. Le client attend ou il revient plus tard. Cette rareté n'est pas artificielle : c'est la conséquence directe d'un système qui refuse de sacrifier la qualité pour le volume. Et quand on combiné ces limites avec des processus documentes, chaque projet suit exactement le même chemin, avec la même rigueur.