---
title: Claude Code Telemetry
url: https://blog.guigpap.com/fr/workflows/claude-code-telemetry/
url_md: https://blog.guigpap.com/fr/workflows/claude-code-telemetry.md
category: tooling
date: '2026-03-28'
maturite: production
techno:
  - claude
  - n8n
  - odoo
  - prometheus
  - github
application:
  - operations
  - monitoring
---

# Claude Code Telemetry

> Pipeline complet de suivi des sessions Claude Code avec metriques Prometheus et synchronisation Odoo

## 1. Quoi ? — Definition et contexte

Chaque fois qu'une session Claude Code demarre sur ce projet, un hook shell capture le contexte (branche, issue, repo) et le transmet a N8N. Quand la session se termine, un second hook collecte les metriques Prometheus (temps actif, cout, tokens, lignes de code), reconstruit les segments de branches parcourus, et synchronise le tout vers les taches Odoo correspondantes.

Le resultat : chaque tache Odoo affiche le temps Claude passe dessus, le cout API, le nombre de tokens, et les lignes modifiees — automatiquement, sans saisie manuelle.

> **Note - Hook Claude Code**
>
> Un **hook** est un script qui s'execute automatiquement a un moment precis. Ici, deux hooks shell (`session-start` et `session-end`) sont configures dans `~/.claude/settings.json` pour se declencher au debut et a la fin de chaque session Claude Code.

### Les workflows du systeme

| Workflow | Nodes | Declenchement | Role |
|----------|-------|---------------|------|
| **Session Start** | 4 | Webhook POST | Enregistre la session active |
| **Session End** (principal) | 30 | Webhook POST | Metriques + sync Odoo |
| **Orphan Detection** | ~20 | Schedule 12h | Recupere les sessions crashees |
| **Session Categorizer** | 17 | Dimanche 23h | Categorise les sessions non classees |
| **Session Metrics Updater** | 7 | Webhook POST | Mise a jour enrichie (backfill) |

### Architecture de bout en bout

```mermaid
flowchart TD
  Start["Claude Code · démarre"]
  HookStart["Hook SessionStart"]

  subgraph SS["Session Start · 4 nodes"]
    direction TB
    Dedup1["Dedup"]
    Register["Register Active Session"]
  end

  Work["travail · commits · changements de branche"]

  End["Claude Code · se termine"]
  HookEnd["Hook SessionEnd · git reflog + git log"]

  subgraph SE["Session End · 30 nodes"]
    direction TB
    Dedup2["Dedup"]
    PromQ["Prometheus Query"]
    Split["Split Metrics par segment"]
    SaveDT["Save Data Table"]
    LoopIssue["Loop par issue"]
    Odoo["Find/Create Odoo Task → Update"]
    Detail["Create Session Detail"]
    Cleanup["Cleanup Active Session"]
  end

  Orphan["Orphan Detection · scheduled"]

  Start --> HookStart --> Dedup1 --> Register --> Work --> End --> HookEnd --> Dedup2
  Dedup2 --> PromQ --> Split --> SaveDT --> LoopIssue --> Odoo --> Detail --> Cleanup
  Register -.-> Orphan
```

---

## 2. Pourquoi ? — Enjeux et motivations

Sans telemetrie, impossible de savoir combien de temps et d'argent Claude Code consomme par tache. On sait qu'on a utilise l'outil, mais pas sur quoi ni combien. Pour un freelance qui facture du temps, c'est un angle mort.

### Problemes resolus

| Probleme | Sans telemetrie | Avec telemetrie |
|----------|-----------------|-----------------|
| **Cout par tache** | Relever manuellement la console API | Cout USD par issue, par modele |
| **Temps passe** | Estimer de memoire | Temps actif Prometheus + timesheets Odoo |
| **Attribution** | "J'ai travaille sur le projet" | Segments par branche, par issue |
| **Sessions perdues** | Crash = donnees perdues | Orphan Detection recupere les metriques |
| **Categorisation** | Branches `dev` sans contexte | IA categorise en dev/docs/refactor/fix/test |

### Metriques collectees

| Metrique | Source | Precision |
|----------|--------|-----------|
| Temps actif (secondes) | Prometheus OTEL | Par session, par modele |
| Cout API (USD) | Prometheus OTEL | 4 decimales, par modele |
| Tokens (input/output/cache) | Prometheus OTEL | Par type, par modele |
| Lignes ajoutees/supprimees | git log | Par commit |

> **Tip - Requete Prometheus instantanee**
>
> Les metriques sont des compteurs monotones par session_id. Une seule requete instantanee suffit — la derniere valeur EST le total. Pas besoin de requete range.

---

## 3. Comment ? — Mise en oeuvre technique

### Le hook SessionEnd

C'est le hook le plus complexe. Au moment ou Claude Code se termine, il :

1. Lit le fichier d'etat cree au demarrage (issue_id gelee, timestamp)
2. Reconstruit les segments de branches via `git reflog --since`
3. Collecte les commits via `git log --since --all`
4. Enrichit chaque commit avec la branche et l'issue correspondante
5. Construit un TLDR (fichiers changes, insertions, deletions, type dominant)
6. Envoie le payload enrichi a N8N

Le point cle : l'issue_id est **gelee** au demarrage de la session. Meme si l'utilisateur change de branche en cours de route, le systeme sait a quelle tache attribuer le travail.

### Repartition proportionnelle

Quand une session traverse plusieurs branches (par exemple `feature/176-fix` pendant 40 minutes puis `dev` pendant 20 minutes), les metriques sont reparties proportionnellement :

```text
Session totale : 60 minutes
  Branch feature/176 : 40 min → 66% des metriques
  Branch dev : 20 min → 33% des metriques

Si cout total = 0.15 USD :
  Issue #176 → 0.10 USD
  Branche dev → 0.05 USD (tache generique)
```

### Taches generiques

Les sessions sans issue (travail sur `dev`, `main`, ou branches sans numero) sont redirigees vers des **taches generiques** : une par combinaison (repo + categorie). La categorie est determinee par le type dominant des commits :

| Commits dominant | Categorie | Tache generique |
|-----------------|-----------|-----------------|
| feat, chore | dev | "Dev sans issue (features & chores)" |
| docs | docs | "Maintenance documentation" |
| refactor | refactor | "Refactoring" |
| fix | fix | "Corrections (sans issue)" |
| test | test | "Testing" |

### Champs Odoo synchronises

Chaque tache Odoo recoit 11 champs enrichis automatiquement :

| Champ | Type | Description |
|-------|------|-------------|
| `x_claude_time_total` | Float | Heures actives cumulees |
| `x_claude_cost_total` | Float | Cout USD cumule |
| `x_claude_token_total` | Integer | Tokens cumules |
| `x_claude_sessions` | Integer | Nombre de sessions |
| `x_claude_lines_added` | Integer | Lignes ajoutees |
| `x_claude_lines_removed` | Integer | Lignes supprimees |
| `x_claude_cost_by_model` | JSON | Ventilation par modele |
| `x_claude_tokens_input` | Integer | Tokens d'entree |
| `x_claude_tokens_output` | Integer | Tokens de sortie |
| `x_claude_tokens_cache` | Integer | Tokens cache |
| `x_claude_last_session` | Datetime | Derniere session |

Les champs sont cumulatifs : chaque session ajoute ses metriques a celles deja presentes sur la tache.

### Orphan Detection

Toutes les 12 heures, un workflow verifie si des sessions sont restees bloquees dans la table des sessions actives (signe d'un crash Claude Code). Les sessions datant de plus de 6 heures sont considerees orphelines.

Le workflow recupere les metriques Prometheus (si encore disponibles — retention 15 jours), les sauvegarde avec le statut `orphaned`, et met a jour la tache Odoo correspondante. Rien n'est perdu.

> **Caution - Retention Prometheus**
>
> Si les metriques Prometheus ont expire (plus de 15 jours), l'Orphan Detection sauvegarde des zeros. Les commits ne sont pas non plus recuperables (le hook n'a jamais tourne). C'est un filet de securite, pas une garantie.

### Categorisation hebdomadaire

Chaque dimanche a 23h, le Session Categorizer utilise Claude pour analyser les sessions non categoriees. L'IA recoit un batch de sessions avec leur "topic" (premier message utilisateur) et peut :

- Attribuer une categorie (dev, docs, refactor, fix, test)
- Renommer la tache Odoo de maniere descriptive
- Relinkquer une session vers une tache issue si elle a ete mal attribuee

---

## 4. Et si ? — Perspectives et limites

### Limites actuelles

| Limite | Impact | Mitigation |
|--------|--------|------------|
| **Prometheus 15j retention** | Metriques perdues apres 15j | Sauvegardees dans Data Table des la fin de session |
| **Pas de metriques par branche** | Prometheus n'a que le session_id | Split proportionnel par duree de segment |
| **Hook shell uniquement** | Depend de bash et git | Scripts testes et deployes via `scripts/claude-hooks/` |

### Scenarios d'evolution

**Si besoin de dashboard temps reel** :
- Les metriques Prometheus sont deja disponibles dans Grafana
- Ajouter un dashboard "Claude Code Sessions" avec cout, tokens, et sessions actives
- Alerter si le cout depasse un seuil quotidien

**Si multi-utilisateurs** :
- Ajouter un champ `user_id` dans le payload
- Repartir les couts par developpeur
- Dashboard comparatif dans Odoo

**Si besoin d'analyse fine** :
- Stocker les transcripts complets (actuellement seul le "topic" est garde)
- Analyser les patterns d'utilisation : quels prompts coutent le plus cher
- Optimiser les caches et le choix de modele

---

## Pages liees

### Infrastructure
- [Monitoring Stack](/fr/infrastructure/monitoring-stack/) — Prometheus et Grafana
- [AI Stack](/fr/infrastructure/ai-stack/) — CLI Ollama

### Workflows
- [GitHub-Odoo Sync](/fr/workflows/github-odoo-sync/) — Taches Odoo synchronisees depuis GitHub
- [Global Error Handler](/fr/workflows/error-handler/) — Error Workflow du pipeline telemetrie

### Reference
- [Glossaire](/fr/reference/glossary/) — OTEL, Prometheus, Hook

## Metadonnees agent

- Cet article est issu du blog GuiGPaP Lab.
- Contexte global du blog: https://blog.guigpap.com/llms.txt
- Contact auteur: https://odoo.guigpap.com/mon-cv
- Licence: CC-BY-SA 4.0