Dans l'article sur Todo, je parlais d'un kanban léger conçu pour être piloté par des agents. Mais un kanban, même avec une bonne API, ça ne fait pas tourner une équipe tout seul. Il faut un chef d'orchestre — quelque chose qui regarde le board, décide qui fait quoi, lance les agents, et s'assure que le travail avance.
C'est le rôle du dispatcher.
L'idée
Quand je travaille sur Aekan: Call of Ruligon (un jeu d'exploration en monde ouvert procédural sous Unity), je ne lance pas les agents à la main. Je lance le dispatcher, et il s'occupe du reste.
Le dispatcher est un script Node.js qui tourne en boucle et orchestre 13 agents spécialisés — chacun avec son rôle, ses compétences, et sa mémoire. Il se connecte à l'API de Todo pour lire le board, et il dispatch le travail automatiquement.
Pas de cron job externe, pas de workflow GitHub Actions, pas de message queue. Un script, une boucle, un board. Simple.
Les agents
Chaque agent est une instance de Claude avec un skill file dédié — un document Markdown qui décrit son rôle, ses contraintes, et ses outils. Voici l'équipe :
- Producer — coordonne, priorise, découpe les features en tickets actionnables
- Game Designer — conçoit les mécaniques, les systèmes, les boucles de jeu
- Narrative Designer — écrit le lore, les dialogues, la direction narrative
- Programmer — implémente dans Unity (C#, ECS, shaders, systèmes)
- Technical Artist — pipelines visuels, matériaux, effets, HDRP
- 3D Artist — modélisation, UV, assets procéduraux
- QA Tester — teste, reproduit, rapporte les bugs
- Sound Designer — design sonore, ambiances, SFX
- Community Manager — rédige les devlogs, les annonces, la communication
- Et quelques rôles de support : Groomer, Documentalist, Code Janitor, Evaluator
Chaque agent a ses outils (lecture/écriture de fichiers, Git, API Todo, Bash) et ses limites (jamais de commit direct — seul l'owner push).
Le dispatch : qui fait quoi, et quand
Toutes les 30 secondes, le dispatcher interroge le board Todo et regarde les tickets en attente. La logique de routing est simple :
- Un ticket est assigné à un agent ? → il le lance
- L'agent est déjà en cours sur ce ticket ? → il attend
- L'owner a posté un commentaire ? → l'agent reprend sa session avec le nouveau contexte
La distinction clé : les agents sont répartis en deux catégories.
- Agents texte (producer, game-designer, narrative-designer, sound-designer, community-manager) — ils travaillent sur des documents, pas sur le code. Ils tournent en parallèle, sans risque de conflit.
- Agents code (programmer, technical-artist, 3d-artist, qa-tester) — ils touchent aux fichiers du projet Unity. Ils passent un à la fois, séquentiellement, pour éviter les conflits sur le filesystem.
Quand un agent est lancé, le dispatcher passe le ticket en "En cours". Quand il termine (ou crashe), le statut est restauré. Pas de ticket orphelin bloqué en "InProgress" pour l'éternité.
Les boucles secondaires
Le dispatcher ne fait pas que router des tickets. Il fait tourner plusieurs boucles en parallèle :
Le Groomer (toutes les 5 minutes)
Avant de dispatcher un ticket à un agent, il vérifie que la description est suffisante. Si elle fait moins de 50 caractères, le groomer passe d'abord pour l'enrichir — ajouter du contexte, des critères d'acceptation, des références. Un agent qui reçoit un ticket bien rédigé travaille mieux.
Le Documentalist (toutes les 60 secondes)
Il surveille les commits. Quand je push du code, le documentalist se réveille, analyse le diff, et met à jour les spécifications du projet. La documentation reste synchronisée avec le code sans effort manuel.
Le Code Janitor (quotidien)
Quand il n'y a aucun travail de code en attente, le janitor passe discrètement pour améliorer la santé du code — nettoyage, conventions, petits refactors sûrs. Il respecte le slot séquentiel des agents code.
L'Evaluator (toutes les 30 minutes)
Après chaque ticket terminé, l'evaluator calcule des KPI par agent :
- First-pass success rate — est-ce que le ticket passe en Done sans aller-retour ?
- Feedback compliance — est-ce que l'agent prend en compte les retours de l'owner ?
- Delivery quality — est-ce que le commentaire final décrit le travail et les tests ?
- Block rate — proportion de tickets qui finissent en Blocked
Ces scores sont écrits dans le fichier mémoire de chaque agent. Ils servent de feedback structuré pour améliorer les performances au fil du temps.
L'apprentissage
C'est la partie qui change tout. Quand un ticket passe en Done, le dispatcher déclenche une session d'apprentissage pour l'agent assigné.
L'agent relit le ticket, les commentaires de l'owner, les commits récents, et en tire des leçons. Ces leçons sont écrites dans son fichier memory.md — un journal de bord de 50 lignes max qui évolue en continu.
Si une leçon est confirmée par plusieurs expériences, elle peut être promue :
- Dans le skill file de l'agent (ses instructions permanentes)
- Dans la knowledge base partagée (accessible à tous les agents)
Résultat : les agents s'améliorent ticket après ticket. Le programmer qui s'est fait corriger sur une convention de nommage ne refera pas l'erreur. Le game designer qui a appris que l'owner préfère des descriptions courtes ajuste son style.
La session continue
Un détail qui fait une grosse différence : les agents reprennent leur session quand ils reviennent sur un ticket.
Si Claude a travaillé sur le ticket #42 hier, et que je poste un commentaire aujourd'hui, le dispatcher relance Claude avec le même session ID. Il a tout le contexte de ce qu'il avait fait — les fichiers lus, les modifications, les décisions. Pas besoin de tout redécouvrir.
C'est ce qui rend le workflow fluide. Poster un commentaire @agent:programmer peux-tu aussi ajouter un fallback pour le cas où le terrain n'est pas chargé ? suffit. L'agent reprend, lit le commentaire, ajuste, et livre.
Pourquoi un moteur custom
On pourrait orchestrer des agents avec LangChain, CrewAI, ou AutoGen. J'ai regardé. Le problème, c'est que ces frameworks imposent leurs abstractions — chaînes, graphes, mémoire vectorielle — et qu'ils deviennent vite opaques quand on veut un contrôle fin.
Mon dispatcher, c'est un fichier. Pas de dépendance magique, pas de framework, pas de base vectorielle. Un script Node.js qui appelle l'API Todo et spawn des sous-processus Claude. Je peux lire le code du début à la fin en une heure, et modifier n'importe quel comportement en cinq minutes.
Quand on construit un système agentique pour un vrai projet (pas une démo), la maintenabilité compte plus que l'élégance architecturale. Un fichier plat que je comprends battra toujours un framework que je dois debug.
Ce que ça donne au quotidien
Le matin, je lance le dispatcher et Todo. Je regarde le board, je crée quelques tickets ou j'ajuste les priorités. Puis je travaille sur autre chose — ou sur le même projet, en parallèle avec mes agents.
Les tickets avancent. Les agents commentent leur progression. Je review quand c'est prêt. Si un agent est bloqué, il mentionne @owner et le ticket apparaît dans ma file. Si je veux corriger une direction, je poste un commentaire et l'agent reprend.
C'est du management asynchrone. Le board est la source de vérité, les commentaires sont le canal de communication, et le dispatcher s'assure que personne ne reste inactif.
Suivez le développement
Le dispatcher n'est pas encore open source — il est très lié au projet Aekan pour l'instant. Mais si l'approche vous intéresse, Todo est disponible dès maintenant et c'est la brique de base sur laquelle tout repose.
Rejoignez-moi sur Discord pour suivre l'évolution du système et poser vos questions.