Lundi matin, j'ouvre KittyClaw et le board est déjà en mouvement : trois agents en cours, un ticket qui vient de passer Done, un autre qui vient de se faire bloquer par le content-writer. Je n'ai rien déclenché. C'est ça qui a changé.
Voici une semaine de production. Pas une démo. Pas un article sur l'architecture — les précédents couvrent ça. Ce qui suit, c'est ce qui s'est vraiment passé, chiffres à l'appui.
Les chiffres
Depuis que KittyClaw pilote le projet ekioo.com, le board compte 20 tickets :
- 17 Done (85 %)
- 2 Todo (en attente)
- 1 InProgress (en cours — celui-ci)
Répartition par assigné :
| Agent | Tickets | Part |
|---|---|---|
| content-writer | 9 | 45 % |
| lain (direct) | 6 | 30 % |
| programmer | 4 | 20 % |
| owner | 1 | 5 % |
65 % des tickets ont été traités par des agents sans intervention directe. Je crée le ticket, je l'assigne, KittyClaw fait le reste dans les 30 secondes.
Mais ce chiffre ne raconte qu'une partie de l'histoire. Ce que ne montre pas cette table : chaque ticket génère jusqu'à 6 runs d'agents en cascade. Un article de blog typique déclenche successivement : content-writer, qa-tester, fact-checker, committer, evaluator — et parfois un groomer en amont. 20 tickets = bien plus de 60 runs d'agents.
Ce qui a bien marché
L'automation assignee-dispatch
C'est l'automation la plus simple du board, et de loin la plus précieuse : un ticket passe en Todo avec un assigné → 30 secondes plus tard, l'agent tourne. Pas de clic, pas de terminal à ouvrir, pas de commande à lancer. La friction entre "j'ai une idée" et "un agent travaille dessus" est descendue à zéro.
Sur une semaine, c'est le changement d'habitude le plus net : je note une tâche, je l'assigne, j'oublie. Le soir, c'est souvent Done.
Le pipeline qa-on-review
Chaque ticket qui passe en Review déclenche automatiquement le qa-tester. Sur les tickets de contenu, le fact-checker s'enchaîne. En pratique, ça a rattrapé plusieurs problèmes avant qu'ils n'arrivent en prod : liens cassés, images manquantes, pages qui ne rendaient pas.
L'automatisme "quelqu'un vérifie toujours avant de merger" est exactement ce que je cherchais. Ça coûte quelques minutes de compute, mais ça remplace une habitude de relecture manuelle que j'aurais souvent sautée.
owner-feedback
Quand je commente un ticket en blocage, l'agent reprend automatiquement. Pas besoin de relancer manuellement. Cette automation-là, je ne l'aurais pas prévue avant d'en avoir besoin — et depuis qu'elle tourne, elle m'a sauvé plusieurs allers-retours.
Ce qui a surpris (pas forcément dans le bon sens)
Le content-writer bloque trop souvent
Taux de blocage sur les tickets de contenu : ~33 %. Un article sur trois génère une phase de questions-réponses avant que l'écriture commence. Dans certains cas, c'est légitime — le ticket était sous-spécifié. Dans d'autres, l'agent demande des précisions sur des éléments qu'il aurait pu inférer du contexte.
Ce n'est pas un bug, c'est un calibrage. Le SKILL du content-writer est peut-être trop conservateur sur ce point. À revoir.
L'evaluator plafonne à 0.5
L'evaluator note chaque ticket terminé. Sur les 13 tickets évalués, le score de deliveryQuality est 0.5 dans 11 cas sur 13. Les deux exceptions (0.0) correspondent à des tickets lain sans commentaires, probablement hors périmètre du rubric. Pour tous les tickets traités par des agents, le plateau est absolu : personne ne passe la barre. Soit le barème est mal calibré, soit tous les agents ont un problème commun que je n'ai pas encore identifié.
Le symptôme est clair, le diagnostic l'est moins. C'est un sujet pour la semaine prochaine.
Le groomer s'est arrêté après 2 tickets
Le groomer est censé enrichir les tickets en Backlog avant qu'ils ne soient assignés. Il a tourné sur les tickets #22 et #23, puis plus rien. Raison : les tickets suivants ont été créés directement en Todo, sautant la colonne Backlog. L'automation ne se déclenche que si le ticket passe par Backlog avec l'assigné "groomer".
Résultat : 80 % des tickets arrivent au dispatcher sans avoir été enrichis. Certains étaient bien spécifiés de toute façon, mais c'est une faille dans le pipeline que je n'avais pas anticipée.
Le bruit généré par le lain sweep
L'agent lain tourne toutes les heures pour passer le board en revue — c'est l'automation ceo-board-review. Sur une semaine, ça représente des dizaines de runs, dont une majorité ne font rien d'observable. Le debug log est encombré de sessions lain à ticket # vide.
C'est utile pour les cas où quelque chose se coince. Mais l'intervalle d'une heure crée beaucoup de bruit pour assez peu de signal quand le board est en bonne santé.
Ce qu'on referait différemment
Forcer le passage par Backlog. Pas pour ralentir le flow, mais pour s'assurer que le groomer a le temps de travailler. Une automation qui détecte les tickets Todo sans passer par Backlog et les y replace — ou qui alerte — éviterait les tickets sous-spécifiés.
Calibrer l'evaluator. Un score plancher à 0.5 pour tout le monde ne donne aucune signal utile. Il faut soit affiner le rubric, soit donner à l'evaluator plus de contexte pour discriminer.
Augmenter l'intervalle du lain sweep. Passer à 4h ou même 8h réduirait le bruit sans perdre la capacité de détecter les situations bloquées.
Réviser le SKILL du content-writer pour réduire le taux de blocage sur les tickets bien spécifiés. L'heuristique "si le ticket a une structure complète, sauter les questions de clarification" est dans la mémoire, mais pas encore dans le SKILL. Elle devrait l'être.
Une semaine, c'est court
Ce qui frappe surtout au bout de sept jours : l'outil fonctionne, mais les calibrages sont loin d'être stabilisés. C'est exactement l'inverse d'un SaaS qu'on adopte — là, on hérite des calibrages d'une équipe produit. Ici, on les découvre nous-mêmes, par friction réelle.
L'avantage, c'est que chaque friction est directement actionnable. Le groomer ne tourne pas assez ? On change une règle dans automations.json. Le content-writer bloque trop ? On ajuste le SKILL. Pas de ticket dans un forum produit. Pas de "under consideration". Juste du code qu'on contrôle.
C'est pour ça que j'ai construit cet outil à la place d'en utiliser un existant. Pas pour les features — pour le cycle de feedback.