LinkedIn CV
Use case 06

Agent
Monitor

Un agent audite tous les agents en production : analyse statique du code par Claude, tests API live, scoring F/P/S/C. Rapport HTML généré à chaque run. Corrections validées O/N avant application.

90–91%
Scores certifiés
Spotify · Veille PM
4
Critères
F/P/S/C
HTML
Rapport généré
à chaque run
Veille PM · Spotify · Monitor
3
agents en production à auditer en permanence
01
Ops · Fiabilité · Production

Un agent en prod
peut dégrader sans bruit

Quand un agent tourne en production, comment détecter qu’il dégrade ? Sans monitoring, on découvre les bugs quand l’output est mauvais, souvent une semaine après la régression. L’Agent Monitor audite en amont, à la demande.

01 Lancer check-agents dans le terminal
02 Analyse statique du code de chaque agent par Claude (bugs, optimisations, score)
03 Tests API live : Anthropic, Spotify, Last.fm, Notion, en lecture seule, call minimal
04 Score F/P/S/C calculé + delta vs dernier run (Δ +3% / ∇ −2% / stable)
05 Rapport HTML généré automatiquement, onglets par agent, accordéons bugs/optimisations
06 Validation O/N pour chaque correction proposée : l’agent ne modifie rien sans confirmation
Ce que ça révèle
Penser « production » dès la conception, c’est anticiper la maintenance. Le monitoring n’est pas une étape après, c’est une contrainte de design. Un agent sans audit régulier est un agent dont on ignore l’état réel.
Python · Anthropic · Spotipy · Requests
6
étapes d’audit pour chaque agent monitoré
02
Analyse · Tests live · Rapport

6 étapes
d’audit

Pour chaque agent monitoré, le script exécute six vérifications dans l’ordre. L’analyse statique et les tests live sont complémentaires : ils ne détectent pas les mêmes problèmes.

Step 1
Check fichiers & config
Credentials .env présents, historique JSON valide, fichier code .py trouvé, paths réels vérifiés sur le filesystem. Arrêt immédiat si un prérequis est bloquant.
Step 2
Tests API live
Connexion Anthropic, Spotify, Last.fm, Notion, en lecture seule, call minimal. Détecte les tokens expirés et les changements d’API avant qu’ils impactent la production.
Step 3
Analyse Claude du code
Claude lit le code source et identifie les bugs (critique / important / mineur), les optimisations possibles, et génère un score F/P/S/C avec justification.
Step 4
Delta vs dernier run
Score actuel comparé au dernier rapport (quelle que soit la date). Delta affiché : Δ +3% si progression, ∇ −2% si régression, stable si inchangé.
Step 5
Rapport HTML
Généré dans reports/ et ouvert automatiquement dans le navigateur. Onglets par agent, accordéons bugs/optimisations, prompts Claude Code prêts à copier pour les corrections.
Step 6
Validation O/N
Chaque correction proposée est affichée avec un diff coloré (rouge = avant, vert = après). Validation explicite avant toute application. Les décisions sont tracées dans le rapport.
Ce que ça révèle
L’analyse statique et les tests live ne se remplacent pas, ils se complètent. Claude détecte les bugs logiques dans le code. Les tests live détectent les décalages avec l’état réel des APIs. Les deux sont nécessaires.
F · P · S · C · Seuils explicités
4
critères pondérés : « ça tourne » n’est pas suffisant
03
F/P/S/C · Pondération · Seuils

Un score sans seuils
ne sert à rien

La grille F/P/S/C distingue « ça tourne » (Fonctionnel) de « ça retourne les bons résultats » (Précis). Un agent peut scorer 100% en F et 60% en P : ce n’est pas la même chose.

F · 40%
Fonctionnel
Chaque outil répond sans erreur en production ? Critère le plus pondéré : un agent qui plante n’a pas de score.
P · 30%
Précis
Les résultats sont corrects et vérifiables ? Un agent peut fonctionner sans erreur et retourner des résultats faux : c’est le cas le plus dangereux.
S · 20%
Stable
Comportement cohérent sur plusieurs sessions ? Un agent qui fonctionne une fois sur deux n’est pas en production.
C · 10%
Couvrant
% des features prévues qui fonctionnent ? Un agent partiel peut être validé s’il est fonctionnel, précis et stable sur son périmètre réel.
<60% Ne pas utiliser en production
60–79% Supervision requise à chaque run
80–89% Usage régulier, corrections ponctuelles
≥ 90% Production-ready
Scores mesurés en production
Veille PM v5.3 : F 95% · P 85% · S 90% · C 100% → 91%. Spotify v6 : F 92% · P 82% · S 90% · C 85% → 90%. Le Monitor s’auto-audite, baseline en cours.
Statique vs live · O/N humain · Fail fast
3
arbitrages, chacun avec son rejet et sa conséquence
04
Arbitrages · Trade-offs · Conséquences documentées

Ce qui a été
arbitré

01
Limite documentée vs Fausse exhaustivité
L’analyse statique ne détecte pas les paths hardcodés incorrects ni les décalages avec l’état externe. Plutôt que de prétendre à une couverture totale, cette limite est documentée explicitement dans le CLAUDE.md. Un outil qui connaît ses angles morts est plus fiable qu’un outil qui les ignore.
Sans ce choix : des faux négatifs non documentés génèrent une fausse confiance dans les scores.
02
Validation O/N humaine vs Correction automatique
L’agent propose, l’humain décide. Chaque correction est affichée avec un diff coloré et une explication avant toute application, même pour des corrections triviales. Le Monitor ne modifie jamais rien sans confirmation explicite.
Sans ce choix : des corrections automatiques sur des faux positifs dégradent les agents au lieu de les améliorer.
03
Fail fast si analyse impossible vs Rapport partiel
Si l’API Anthropic ne répond pas ou si un fichier agent est introuvable, arrêt immédiat. Aucun rapport généré, les scores du run précédent restent la référence. Un rapport partiel avec des scores incomplets est plus dangereux qu’aucun rapport.
Sans ce choix : des scores faux génèrent des corrections fictives qui peuvent dégrader les agents si appliquées.
Ce que ça révèle
Un outil de monitoring qui manque de rigueur sur lui-même invalide tous ses résultats. Les mêmes principes qu’on applique aux agents monitorés s’appliquent au Monitor : documenter les limites, ne rien automatiser sans validation, arrêter proprement plutôt que continuer à moitié.