Quand on travaille avec un agent IA, il devient étonnamment difficile de répondre à une question pourtant très simple : combien de temps ai-je réellement travaillé sur ce projet ? Project Timeline est une extension VS Code que j’ai écrite pour y répondre, projet par projet, en local, sans qu’aucune donnée ne quitte la machine.

Le problème

Les agents IA rendent beaucoup plus difficile l’estimation du temps réellement passé sur un projet. Le temps « actif » ne se limite plus aux frappes clavier : il y a le temps où l’agent tourne seul, le temps de relecture d’un diff, les phases d’attente. Et il y a une question très concrète, projet par projet : combien de temps, de tokens et de sessions représente réellement ce projet ?

Aucun outil ne répondait à cette question à l’échelle d’un projet précis, sans envoyer de données ailleurs que sur ma propre machine. J’ai donc écrit le mien.

Ce projet est né directement de ce que je raconte dans un article sur la façon dont l’IA a changé ma pratique : une fois qu’une partie du code est produite par un agent, la question « combien de temps j’ai travaillé » cesse d’avoir une réponse évidente. Les métriques traditionnelles — lignes tapées, commits par jour — ne correspondaient plus à rien.

Ce que ça donne, en vrai

Sur ce site (bs-studio-frontend), le tableau de bord de Project Timeline affiche, à date : environ 104h de temps total sur le projet, dont 8h46 passées avec un agent actif seul rien que sur les 7 derniers jours — soit 44 % du temps de cette semaine-là. Sur l’historique complet, les deux agents combinés ont traité environ 2,8 millions de tokens hors cache. La majorité des échanges s’appuie ensuite sur le cache de contexte (99 % côté Claude), ce qui réduit fortement le coût réel des sessions.

C’est exactement le genre de répartition qui n’apparaît nulle part dans un git log classique : sans cet outil, je saurais combien de commits j’ai faits, mais pas combien de temps un agent a tourné pendant que je relisais autre chose, ni ce que ça a réellement coûté.

Ce que fait l’extension

Project Timeline tourne en arrière-plan dans VS Code et construit, pour chaque projet ouvert, un tableau de bord complet :

une grille d’activité façon GitHub, une case par jour ;
une heatmap des horaires de travail (jour de la semaine × heure) ;
le temps passé par jour, découpé entre interaction éditeur, agent actif seul, et temps idle ;
les tokens consommés par jour (Claude / Codex) et leur coût estimé ;
la composition du projet (langages travaillés, par lignes) ;
un détail par agent IA : sessions, tours, ratio de cache, coût, avec une ventilation par modèle ;
les fichiers les plus travaillés sur les 7 derniers jours.

Reconstruction de l’historique

La fonctionnalité qui a demandé le plus de travail : à la première ouverture d’un projet, l’extension ne part pas d’une page blanche. Elle relit toutes les sessions Claude Code et Codex CLI passées (tours, tokens, coût, modèle), l’historique Git complet, et estime le temps de travail par jour à partir de la répartition de ces signaux. Ces sessions reconstruites sont marquées comme telles et jamais confondues avec du temps réellement mesuré en direct. Des identifiants d’événements déterministes garantissent qu’aucun double comptage ne se produit quand le suivi en direct reprend derrière la reconstruction.

Résultat concret : installer l’extension sur un projet vieux d’un an donne tout de suite une estimation historique complète, sans avoir eu besoin de la faire tourner depuis le premier jour. C’est d’ailleurs comme ça que les 104h citées plus haut existent — la quasi-totalité de ce temps vient de cette reconstruction, pas d’un suivi en direct que j’aurais démarré dès la création du projet.

Une contrainte de conception : rien ne sort de la machine

C’est le principe qui a guidé toutes les décisions techniques du projet :

aucune requête réseau — le tableau de bord est un webview qui dessine ses graphiques en SVG inline, avec une politique de sécurité stricte ;
aucun processus externe lancé — les commits passent exclusivement par l’API de l’extension Git intégrée de VS Code, jamais par un appel direct à git ;
écriture confinée au dossier de stockage propre à l’extension — rien n’est jamais écrit dans .git, dans les dossiers de sessions Claude ou Codex, ni dans le dépôt suivi ;
un modèle de données en JSONL append-only : chaque ligne est un événement, jamais modifié, tous les indicateurs sont recalculés par agrégation. Une récupération après crash reste volontairement conservatrice — l’extension n’invente jamais de minutes de travail qui n’ont pas eu lieu.

Pourquoi ouvrir le code

L’objectif n’est pas de noter la productivité d’un développeur, mais de lui redonner une vision fidèle de son propre travail. Je pense que cette façon de mesurer le développement avec des agents IA ne devrait pas dépendre d’un service cloud — d’où le choix de tout garder en local, et de rendre le code public.

Code disponible publiquement sous licence MIT complétée d’une Commons Clause : utilisable, modifiable et redistribuable librement, à l’exception de la revente du logiciel ou d’un service dont la valeur dérive substantiellement de lui. J’en garde les droits d’exploitation.