--- title: "KittyClaw dashboard : comment je produis et valorise mes KPI" description: "Un LLM écrit la tuile une fois, le refresh tourne sans token. Et l'output alimente à la fois l'humain et les agents. L'économie d'un dashboard agentique." created: 2026-06-04T10:00:00+02:00 updated: 2026-06-04T10:00:00+02:00 tags: ["KittyClaw", "IA", "Tooling", "Coulisses"] image: /images/blog/kittyclaw-dashboard-kpi-cover.webp card: /images/blog/kittyclaw-dashboard-kpi-card.webp --- Un dashboard, ça a deux coûts cachés : le créer et le maintenir. La plupart des outils résolvent le premier (un assistant génère les requêtes SQL), puis laissent tomber le second (les données vieillissent, personne ne rafraîchit). KittyClaw a une approche différente, et elle tient en trois phrases : Le LLM écrit la tuile **une fois**, en chat. Le refresh s'exécute **périodiquement sans aucun token LLM**, via un script shell ou PowerShell. Et l'`output.md` généré sert **à la fois à l'humain et aux agents** qui surveillent le projet. C'est cette triple économie (coût initial minimal, opération gratuite, boucle fermée) que je veux décrire ici. --- ## Le primitif `.dashboard//` Chaque tuile est un dossier dans le dépôt : ``` .dashboard/ ca-mensuel/ tile.yaml ← template, refresh, prompt, titre script.ps1 ← collecte les données (optionnel) output.json ← données rendues par le dashboard health/ tile.yaml script.ps1 ← collecte les métriques projet data.json ← produit par script.ps1 output.md ← généré par LLM à partir de data.json ``` Le `tile.yaml` déclare trois choses : ```yaml template: kpi # parmi : kpi, kpi-grid, donut, bar-chart, # sparkline, progress, heatmap, # status-grid, gauge, leaderboard, # table, timeline, markdown, mermaid, image title: CA mensuel refresh: 86400 # en secondes. 0 = jamais auto-rafraîchi ``` Quand le refresh se déclenche : 1. KittyClaw exécute `script.*` si présent → produit `data.json` 2. Si la tuile a un `prompt`, KittyClaw appelle le LLM avec `data.json` en contexte → écrit `output.json` ou `output.md` 3. Si la tuile n'a pas de prompt, `output.*` est lu directement tel quel La deuxième étape est la seule qui consomme des tokens, et seulement sur les tuiles `markdown` qui synthétisent de la donnée brute. Les tuiles `kpi`, `bar-chart`, `sparkline` et compagnie rendent `output.json` côté serveur : zéro LLM à l'exécution. --- ## Galerie de tuiles : projet BrewCo Pour illustrer l'étendue des templates sans screenshot d'un vrai projet en production (les chiffres réels ne sont pas publics), j'ai créé **BrewCo** : une chaîne fictive de 12 coffee shops. Onze tuiles, sept templates différents, toutes alimentées par du JSON réaliste. ![Dashboard BrewCo : 11 tuiles, 7 templates différents](/images/blog/kittyclaw-dashboard-kpi-demo.webp) **Première rangée : scan rapide.** Quatre tuiles `kpi` : CA mensuel, commandes/jour, ticket moyen, NPS. Chacune est un `output.json` de cinq champs (`value`, `label`, `unit`, `delta`, `trend`). Le delta et la flèche de tendance sont rendus automatiquement. **Deuxième rangée : lecture analytique.** Un `donut` (répartition canal : sur place 58 %, à emporter 31 %, livraison 11 %), un `bar-chart` (ventes par jour de la semaine, le samedi à 612 saute aux yeux instantanément), une `sparkline` (évolution du CA sur 12 semaines), et une `heatmap` de style GitHub Calendar montrant l'activité des 90 derniers jours. **Troisième rangée : état et contexte.** Un `status-grid` (6 systèmes avec statuts ok/warn/err, le Wi-Fi d'un magasin est en warn), des `progress` bars pour les objectifs T2, et une tuile `markdown` pour la note hebdomadaire de direction. Chaque template a son propre schéma JSON, documenté dans l'interface : le chat IA de création de tuile injecte automatiquement le bon schéma dans son prompt. --- ## La boucle fermée : Lain lit `output.md` Ce qui rend ce primitif particulièrement puissant, c'est que les `output.md` des tuiles analytiques deviennent naturellement un input pour d'autres agents. Sur le projet ekioo, la tuile `health` produit chaque jour un `output.md` qui croise métriques tickets (vélocité, blocages, tickets stagnants), données trafic Umami et signaux SEO Search Console. Ce fichier est lu par **Lain**, l'agent CEO qui passe en revue le board toutes les heures : ```yaml # .dashboard/health/tile.yaml template: markdown refresh: 86400 prompt: 'Read the JSON at .dashboard/health/data.json, which contains ticket metrics, roadmap goals, and optionally umami (traffic) and gsc (SEO) data. Cross-reference all signals. Format: Diagnostic (3 phrases), Risques (2 bullets), Action de la semaine (1 bullet). Be opinionated. Output ONLY the raw markdown.' ``` Lain ne poll pas l'API KittyClaw à 30 reprises pour reconstituer un état global. Il lit `health/output.md`, un document déjà synthétisé, à jour, en langage naturel, et décide sur cette base si un ticket doit être escaladé ou si un sujet SEO mérite une action immédiate. Un seul appel LLM consomme un contexte déjà traité. C'est la même logique que les systèmes de cache dans une architecture backend : on calcule une fois, on sert N fois. --- ## Le dashboard n'est pas réservé aux projets tech BrewCo n'est pas un projet de dev. C'est une chaîne de café. Et les tuiles fonctionnent exactement pareil : un script PowerShell qui lit un CSV d'export de caisse, produit un `data.json`, et le dashboard affiche les KPI du weekend. Le primitif (`tile.yaml` + `script.*` + `output.*`) est suffisamment générique pour monitorer des métriques business, des campagnes marketing, ou des opérations physiques. La seule contrainte est que les données soient lisibles par un script. Si elles le sont, le dashboard peut les afficher. C'est délibéré. KittyClaw est un outil de gestion de projet et d'orchestration d'agents, pas un outil BI SaaS. Le dashboard est une couche d'observabilité, pas une fin en soi. --- ## Observabilité entre humain et agents Ce qui m'intéresse dans cette architecture, c'est qu'elle résout un problème de coordination que les systèmes agentiques créent : l'humain et les agents ont besoin de voir la même réalité, mais à des granularités différentes. L'humain veut une vue d'ensemble : quelques chiffres, une tendance, une alerte. L'agent veut une entrée structurée qu'il peut raisonner. Le `output.md` de la tuile `health` est les deux à la fois : lisible par un humain en 30 secondes, parsable par un agent en un seul appel. Ce n'est pas une révolution d'infrastructure. C'est un fichier texte régénéré chaque nuit. Mais c'est exactement la bonne abstraction pour la couche entre l'humain qui pilote et les agents qui exécutent.