Project Timeline | Baptiste SAVE

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

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.

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.