Hier, mon assistant local IA a généré 920 appels de scoring qualité, traduit 590 prompts automatiquement, et consolidé 173 sessions d'agents éphémères.
Rien de tout ça n'était visible dans mon terminal.
Pourtant, chaque chiffre était capturé, persisté en base, et disponible en temps réel via une API REST.
Du coup, j'ai voulu documenter comment ça marche — parce que l'observabilité d'un système LLM en production, c'est un problème que personne ne résout vraiment bien.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Le problème : les LLM sont des boîtes noires de consommation
Quand vous utilisez Claude Code ou n'importe quel assistant IA au quotidien, vous voyez des réponses.
Ce que vous ne voyez pas :
- Combien de tokens ont été consommés (input vs output vs cache)
- Quels outils ont été appelés combien de fois
- Quel agent a été routé pour quelle requête
- Quelle est la latence réelle de chaque composant LLM
- Où se situe le «gaspillage» (lectures répétées, sorties non-redirigées)
Sans ces données, optimiser est impossible. Du coup, j'ai construit un système de métriques en 4 couches directement dans mon infrastructure Claude Code.
L'architecture en 4 couches
[Claude Code LLM]
│
▼
COUCHE 1 — COLLECTE (PostToolUse / Stop hooks)
Hooks HTTP (port 18766) + scripts Bun
Événements : tool_call, session_turn, gemini, skill
│
▼
COUCHE 2 — PERSISTANCE (PostgreSQL pgvector)
10+ tables + 2 vues matérialisées
rag_token_tracking, rag_tool_metrics, gemini_call_tracking…
│
▼
COUCHE 3 — CONSOLIDATION (SessionEnd + KPI functions)
session-end-metrics.ts, rag_capture_snapshot()
│
▼
COUCHE 4 — RESTITUTION (benchmark-server port 8765)
/api/pilot/v2/tokens, kpi-history, routing, ollama
Dashboard live localhost:8765
Chaque couche a une responsabilité unique. Aucune ne bloque le LLM.
Couche 1 : Collecter sans jamais ralentir le LLM
L'enjeu pour un CTO : chaque milliseconde de latence ajoutée par du monitoring, c'est de la friction sur la productivité de l'équipe. Un hook de collecte mal conçu peut rendre un assistant IA inutilisable.
La solution : les événements sont envoyés en fire-and-forget vers un daemon HTTP persistant (5ms de latence vs 230ms pour un process à froid). L'assistant IA ne s'arrête jamais d'attendre ses propres métriques.
Ce qui est mesuré à chaque action :
| Donnée | Utilité décisionnelle |
|---|---|
| Tokens consommés (input / output / cache) | Comprendre le vrai coût par opération |
| Catégorie de l'action (git, build, search…) | Identifier où va le budget IA |
| Flag "gaspillage" | Détecter les patterns inefficaces automatiquement |
| Cache hit / miss | Mesurer l'efficacité du prompt caching (jusqu'à 90% de réduction de coût) |
Le gaspillage détecté automatiquement : lectures de fichiers sans limite de lignes, lectures répétées du même fichier, sorties non-redirigées qui saturent le contexte. Chaque gaspillage est catégorisé avec sa cause, ce qui permet d'agir précisément — pas de chercher à l'aveugle.
L'accumulation intelligente regroupe les événements par lots de 25 avant d'écrire en base. Sur une journée à 300 sessions, cela représente une division par 25 des écritures PostgreSQL.
Couche 2 : Persister pour analyser, pas pour archiver
L'enjeu pour un CTO : la plupart des solutions de monitoring stockent des logs. Ce que vous voulez, c'est pouvoir répondre à "combien ça m'a coûté cette semaine et pourquoi" en 3 secondes — pas en 30 minutes d'exploration de logs.
Le schéma PostgreSQL est conçu pour les requêtes analytiques. Chaque table répond à une question business précise :
| Question | Table | 7 jours de données |
|---|---|---|
| Où va mon budget tokens ? | rag_token_tracking |
968 événements catégorisés |
| Mon IA locale est-elle efficace ? | rag_tool_metrics |
1 241 appels LLM mesurés |
| Combien ça coûte en Gemini/cloud ? | gemini_call_tracking |
2 544 appels trackés |
| Quels skills sont vraiment utilisés ? | rag_skill_usage |
1 554 invocations |
| Quelle est la tendance sur 50 jours ? | rag_kpi_snapshots |
50 snapshots quotidiens |
Le snapshot quotidien est la pièce maîtresse : une ligne par jour, ~50 métriques consolidées (consommation, santé, sécurité, compétences actives). C'est lui qui alimente les tableaux de bord — et il se met à jour automatiquement à chaque fin de session, sans intervention manuelle.
Couche 3 : Consolider automatiquement à chaque clôture de session
L'enjeu pour un CTO : les données brutes ne valent rien sans consolidation. Il faut transformer des milliers d'événements en indicateurs actionnables — et le faire sans que l'équipe ait à déclencher quoi que ce soit manuellement.
Cette couche s'exécute automatiquement à la fin de chaque session Claude Code. En quelques secondes, elle produit :
- Le bilan de session : tous les tokens consommés, les agents utilisés, les fichiers modifiés — regroupés par agent et par phase
- La mise à jour du snapshot KPI : le tableau de bord du lendemain matin est déjà prêt
- Le nettoyage préventif : les compétences IA non utilisées depuis 30 jours sont désactivées, les anciennes sessions (>90j, faible qualité) sont purgées
Du coup, le dashboard ne s'alimente pas quand vous le consultez — il est déjà à jour quand vous arrivez. C'est la différence entre un reporting réactif et un reporting proactif.
Ce qui se passe sous le capot : deux tâches parallèles — une légère (mise à jour des KPI) et une plus lourde (reconstruction des métriques d'exécution par agent). La tâche lourde tourne en arrière-plan sans bloquer la fermeture de session.
Couche 4 : Visualiser et piloter en temps réel
L'enjeu pour un CTO : les données en base ne servent à rien si votre équipe ne les consulte jamais. Il faut un dashboard qu'on ouvre naturellement, pas une requête SQL à mémoriser.
Un serveur REST léger (Node.js) expose toutes les métriques en une API unifiée. Le dashboard live (localhost:8765) se charge en temps réel, multi-providers :
Ce que vous pouvez voir en un coup d'œil :
| Vue | Ce qu'elle révèle |
|---|---|
| Consommation tokens | Coût réel par provider (Ollama local vs Gemini cloud) |
| KPI 50 jours | Tendances : est-ce que l'équipe devient plus efficace ? |
| Routing agents | Quels agents sont vraiment utilisés, avec quel taux de succès |
| Santé système | Les 18 paramètres d'optimisation du système IA autonome |
| Conscience/inconscient | Activité des 4 niveaux de crons autonomes (N1-N4) |
L'unification multi-providers est la vraie valeur : Ollama (local, 0€) et Gemini (cloud, payant) apparaissent dans la même vue, avec les mêmes métriques. Vous voyez instantanément si le modèle local suffit ou si le cloud est justifié.
Ce matin : 12 appels Gemini (11 768 tokens), 920 appels Ollama scoreQuality en 7 jours, 590 traductions automatiques. Tout visible, tout comparable.
Ce que révèlent 50 jours de métriques
Après 50 jours de collecte continue, voici les 4 décisions que les données ont permis de prendre :
1. Le modèle local couvre 95% des besoins. Scoring qualité (920 appels/semaine), traduction automatique (590 appels/semaine) — tout ça tourne sur un GPU local à 0€. Gemini n'intervient que pour les analyses complexes. Sans métriques, j'aurais routé bien plus de trafic vers le cloud.
2. Un composant consommait 3x plus de temps que les autres. La tâche mdkey-chunk prenait en moyenne 4,3 secondes par appel, contre 1,3 secondes pour les autres. Invisible sans monitoring. Identifiable en 10 secondes avec. Candidat prioritaire pour optimisation.
3. Le batching évite la saturation de la base. 300 sessions par jour = potentiellement des milliers d'écritures PostgreSQL. Avec l'accumulation par lots, c'est divisé par 25. Sur un serveur partagé, c'est la différence entre un système fluide et une base qui ralentit.
4. Le prompt cache génère jusqu'à 90% d'économies — mais seulement si vous le mesurez. Le cache_hit dans les métriques révèle précisément quels prompts profitent du cache et lesquels le manquent. Sans ça, vous optimisez le mauvais endroit.
Comparatif avec les solutions du marché
Une question légitime : pourquoi construire quelque chose de maison quand Langfuse, LangSmith ou Helicone existent ?
La réponse courte : parce que aucun outil du marché ne track le prompt caching Anthropic — et c'est là que se jouent 90% des économies réelles sur Claude.
| Critère | Langfuse | LangSmith | Helicone | Système maison |
|---|---|---|---|---|
| Modèle d'intégration | SDK manuel | Auto LangChain | Proxy Rust | Hooks natifs Claude Code |
| Latence collecte | < 5ms | < 10ms | 50-80ms (proxy sync) | < 5ms (HTTP local) |
| Token tracking | prompt + completion | prompt + completion | Tous providers | prompt + completion + cache read/write + waste |
| Cache Anthropic | Non natif | Non | Non | Oui (unique) |
| Routing agents | Traces multi-niveaux | Fort (LangGraph) | Partiel | Routing source + similarity + pipeline |
| OTel compatible | Oui (natif) | Partiel | Via plugin | Non |
| Coût | Gratuit self-hosted | $39/user/mois | $25/mois flat | $0 local |
| Confidentialité | Self-hosted ou cloud | Cloud | Cloud ou self-hosted | 100% local |
Ce que les outils du marché font mieux : Langfuse a des dashboards plus riches et une communauté active. LangSmith excelle pour visualiser les graphes d'agents LangGraph. Arize Phoenix (MIT, self-hosted, OTEL-natif) est le seul à offrir des évaluateurs LLM-as-judge + CI/CD eval pipelines + traces visuelles sans vendor lock-in. Helicone couvre tous les providers LLM sans toucher au code.
Ce que notre système fait de manière unique :
- Tracking du cache_read_tokens et cache_write_tokens Anthropic — aucune plateforme ne le fait nativement
- Détection automatique du gaspillage token (is_waste + waste_reason) — spécifique à Claude Code
- Métriques de routing d'agents (source, score de similarité, pipeline complet) — invisible dans les outils génériques
- Système d'analyse autonome N1→N4 qui produit des insights que même Langfuse ne génère pas
Du coup, ce n'est pas un choix idéologique. C'est pragmatique : les 10% d'économies supplémentaires liées au cache Anthropic sur 500M tokens/mois représentent un différentiel réel.
La meilleure architecture hybride en 2026 : hooks maison (routing + cache + spécificités Claude Code) + Arize Phoenix self-hosted pour les évaluations et les traces visuelles + export OTLP optionnel pour l'interopérabilité Grafana/Datadog. Effort total : 3-5 jours. Coût : 0€ (les deux composants sont open-source). Deux projets communautaires existent déjà pour connecter Claude Code à OTel : claude-code-hooks-multi-agent-observability et claude-code-otel.
Ce que vous pouvez reproduire
L'architecture entière repose sur des primitives disponibles dans Claude Code :
- Hooks PostToolUse : endpoint HTTP ou script Bun
- PostgreSQL + pgvector : n'importe quelle instance (Docker, local)
- Daemon HTTP : un serveur Bun/Node persistant remplace les cold-starts
- KPI snapshot SQL : une fonction UPSERT quotidienne suffit
Vous n'avez pas besoin de Datadog, de Grafana, ni d'un stack observabilité dédié.
Du coup, si vous utilisez Claude Code en production et que vous ne mesurez pas encore vos tokens, vos agents, et votre gaspillage — vous optimisez à l'aveugle.
Les 920 appels LLM d'hier étaient tous utiles. Je le sais parce que je les mesure.
Est-ce que vous avez déjà mis en place un système de monitoring sur vos usages LLM ? Dites-moi en commentaire quelle métrique vous manque le plus aujourd'hui.
Pour aller plus loin
- claude-code-hooks-multi-agent-observability — projet communautaire, hooks Claude Code → OTel
- claude-code-otel — instrumentation OpenTelemetry pour Claude Code
- Arize Phoenix — évaluations LLM open-source, self-hosted (MIT)
- Langfuse — observabilité LLM open-source, self-hosted ou cloud
Qui suis-je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA
920 appels LLM par jour à votre insu : l'architecture silencieuse qui mesure tout dans Claude Code