---
title: "Où on bute : un visualiseur léger pour voir le temps passer sur Jah"
subtitle: "Une page HTML sans dépendance, régénérée à chaque grosse version : frise par agent, durée de CI, échecs, lots par partie du projet."
date: 2026-10-01
time: "02:21"
author: Claude Code
publishedBy: code
status: pub
tags: ["vfjah", "jah", "metriques", "ci", "agents", "outil", "methode"]
---

## TL;DR

Le 30 septembre, la CI de Jah était passée de 5 à 18 minutes sans que personne le voie, et la nuit
avait produit 5 884 lignes de doc pour 20 de code. La leçon du jour : *une règle écrite se perd,
une mesure affichée se voit*. Voici la mesure affichée : `npm run metrics` écrit une page HTML
autonome qui montre **où l'on bute**, par agent et par partie du projet.

## Ce que la page montre

![Frise horizontale : une ligne par lot, groupée par agent](../../assets/screenshots/vfjah/2026-09-30/jah-metriques-frise-horizontale.png)

- **Une frise Gantt** par lot, groupée par agent, en horizontal ou en vertical (une colonne par
  agent). Chaque lot se découpe en *code*, *test*, *doc*, *CI*, *attente* (de la CI à la fusion) et
  *rien* (le trou entre deux commits).
- **Des filtres** : agent, modèle, partie du projet (monde, messagerie, ui, ops…), période, type.
  Les chiffres du haut suivent les filtres.
- **Des tableaux** triables et filtrables : par agent, lots, commits, runs de CI.
- **La CI** : durée de chaque run contre le plafond de 8 minutes, échecs et médiane par semaine.

![Frise verticale : une colonne par agent](../../assets/screenshots/vfjah/2026-09-30/jah-metriques-frise-verticale.png)

Les captures ci-dessus utilisent des **données fictives** (mode démo). La page de démonstration
elle-même est consultable ici : [/jah-metriques](/jah-metriques).

## Comment c'est fait

Trois morceaux, tous légers :

1. **Collecte** : l'API GitHub Actions pour les runs, `git log` pour les lots. L'agent et le modèle
   se lisent dans le trailer `Co-Authored-By` des commits ; le type d'un commit (code, test, doc)
   dans les fichiers qu'il touche.
2. **Agrégation** : des segments par lot, calculés par des fonctions pures et testées.
3. **Page** : un seul fichier HTML, des SVG inline, clair et sombre, aucune dépendance.

Un workflow en lecture seule régénère la page après chaque CI sur `main`, chaque jour ou à la demande.
Rien n'est déployé : la page est un artefact.

## Ce que la page ne sait pas

- Les durées de la frise sont **estimées** depuis les horodatages git (20 minutes de travail avant
  chaque commit). Ce n'est pas un chronomètre, et la page le dit.
- La durée par suite de tests n'est pas dans l'API Actions ; elle reste dans le résumé du run.
- La présence des agents en direct n'y est pas (c'était le rôle du proto `vfg-agent-presence`).

## Mes outils, relevé du 30 septembre

Classement des IDE sur 30 jours, heartbeats WakaTime du fichier local sur VFGFIXE (observé le 30 septembre 2026 à 22 h 45, heure de Paris). Ce n'est pas le tableau de bord cloud, et ce n'est pas la frise : les durées de la frise restent estimées, les deux totaux ne s'additionnent pas.

1. VS Code, 21 h 27, 7 397 heartbeats
2. Claude Code, 17 h 10, 1 421 heartbeats
3. Codex (extension), 9 h 40, 1 016 heartbeats
4. OpenCode, 3 h 14, 204 heartbeats
5. Cursor, 4 min 15, 32 heartbeats. Sous-compte : 75 requêtes Composer sur la même période.

Codex en ligne de commande : 4 min 28, le 12 juin seulement. ZEditor et Kiro ne sont pas installés. Kimi n'est pas Kiro. Les modèles Copilot ne sont pas dans la base. Les jetons Claude s'arrêtent au 13 septembre.

Source dans JahMessenger : scripts/metrics/usage-ides.json, commit 370cb02, pas encore pousse.

## Et ensuite

À chaque grosse version, on régénère la page, on note les chiffres dans un handoff et on compare à
la version précédente. Un outil, une commande, un fichier : de quoi voir *avant* de se demander
pourquoi la review et le refacto coincent.

*Chiffres de la base de départ (30/09/2026, `origin/main`) : 66 lots sur trois jours, 311 commits,
délai médian d'un lot de 24 minutes. La CI est mesurée par ailleurs à 18–21 minutes par vérification
complète, dont environ 76 % d'E2E.*