Mardi matin, 9h. Lain fait sa ronde horaire. Il ouvre les quatre boards KittyClaw — Bloomii, Kalceo, VizMail, Ekioo — évalue les tickets en Todo avec un assignee, et dispatche. Un content-writer part sur un article Bloomii pendant qu'un programmer referme un bug VizMail. Simultanément, un qa-tester sur Kalceo lance une suite de tests. Je n'ai rien déclenché manuellement. Je bois mon café.
C'est l'état actuel du système. Voici comment c'est construit, ce que ça change vraiment, et ce qui casse encore.
La structure : 4 projets, 1 CEO
Quatre projets actifs, chacun avec sa propre fleet d'agents spécialisés :
- Bloomii — site de contenu Green Tech. Fleet : content-writer, fact-checker, evaluator, committer.
- Kalceo — SaaS BTP pour artisans. Fleet : programmer, qa-tester, committer, content-writer.
- VizMail — client mail desktop à tri sémantique. Fleet : programmer, qa-tester, committer.
- KittyClaw — le kanban lui-même. Fleet : programmer, qa-tester, committer, evaluator.
Lain n'est pas dans la fleet de ces projets. Il est au-dessus. Son rôle : board review horaire, dispatch des agents, escalade vers l'owner quand un ticket est bloqué depuis trop longtemps. Un CEO qui tourne en cron, pas un agent qui code.
Chaque fleet fonctionne en isolement complet — worktrees git séparés, mémoire persistante par agent et par projet. Un content-writer Bloomii ne sait pas que VizMail existe.
Ce que ça change
Pas de context-switching manuel. C'est le changement le plus concret. Avant, passer de Bloomii à Kalceo demandait de recharger le contexte : où en était-on, quelles étaient les priorités, qui devait faire quoi. Maintenant c'est la description du ticket qui porte le contexte. Lain le lit, dispatche l'agent approprié, l'agent le lit à son tour. Le context-switching existe toujours — il est délégué.
Les projets avancent en parallèle. Pendant qu'un article Bloomii est en rédaction, VizMail peut intégrer 30 nouveaux tests, Kalceo peut fermer 3 bugs de facturation, et Ekioo peut publier un post X. Ce n'est pas séquentiel, c'est concurrent.
Le goulot d'étranglement se déplace. Il ne s'agit plus de capacité de développement mais de validation. Je suis le seul humain dans la boucle. Chaque PR passe par moi. Quand cinq tickets arrivent en Review simultanément — ce qui arrive — je suis le bottleneck, pas les agents.
Les chiffres réels (au 2026-05-13)
Ce système tourne depuis plusieurs mois. État actuel par projet :
| Projet | Métrique |
|---|---|
| Bloomii | 40+ articles publiés, 5 piliers éditoriaux équilibrés |
| KittyClaw | ~500 tickets traités, 12 automations actives |
| VizMail | 642 tests automatisés, 150+ endpoints API |
| Kalceo | MVP en production, compatible e-facturation 2026 |
Ces chiffres ne proviennent pas d'un sprint boosté. Ils s'accumulent ticket après ticket, run après run, sur plusieurs mois de cadence régulière.
Ce qui casse encore
Honnêteté s'impose — le système n'est pas parfait.
Boucles infinies. Certaines automations resume se redéclenchent sans garde-fou. Un agent en Blocked peut être relancé indéfiniment si la condition de sortie n'est pas correctement câblée dans automations.json. Ça arrive encore. Chaque nouvelle automation demande une vérification explicite du chemin de sortie.
Charge cognitive résiduelle sur Lain. Lain fait du context-switching entre projets à chaque ronde. Même si chaque décision de dispatch est simple, l'accumulation de projets et de tickets à évaluer crée une charge non nulle. Avec 4 projets actifs c'est gérable. Avec 8, ça deviendra un problème d'architecture.
Latence de la mémoire. Chaque agent commence son run en lisant sa memory.md. Sur un agent avec une mémoire dense — le content-writer en est à ~100 lignes — ça représente une fraction de contexte en début de session. La mémoire est précieuse, mais elle a un coût de lecture qu'on ne mesure pas encore correctement.
Ce que ça prouve
Ce n'est pas la technologie la plus impressionnante. Ce sont des agents Claude qui lisent des tickets et commitent du code. L'architecture sous-jacente — KittyClaw comme orchestrateur, automations.json comme pipeline, memory.md comme apprentissage persistant — n'est pas révolutionnaire. Elle est reproductible.
Ce qui est difficile à construire, c'est la discipline opérationnelle : ticket bien rédigé, contexte clair, workflow git cohérent, mémoire maintenue. Un agent ne compense pas un ticket vague. La qualité de l'orchestration dépend directement de la qualité du backlog.
Si vous construisez quelque chose de similaire, commencez par un seul projet, une seule fleet, un seul cycle complet : ticket → agent → PR → review. Quand ce cycle tient sans vous, ajoutez le deuxième projet.
Lain n'est pas magique. C'est un agent bien configuré qui tourne sur une infrastructure bien pensée. La différence entre un setup qui tient et un setup qui déraille, c'est la rigueur des règles dans preamble.md — pas la sophistication du modèle.