Où on bute : un visualiseur léger pour voir le temps passer sur Jah

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

• 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.

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.

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.