L'Outil Monitor de Claude Code

Problème : Jusqu'à ce mois-ci, tout ce qui tournait en arrière-plan était opaque pour Claude Code. Une commande lancée avec run_in_background renvoyait exactement un ping à la fin. Rien entre les deux. Le contournement, c'était /loop ou une tâche planifiée, ce qui revenait à déclencher un nouveau prompt toutes les quelques minutes et payer un appel API complet juste pour demander si quelque chose avait bougé.

Victoire rapide : Pointe Claude vers ton serveur de dev et laisse-le écouter. Une phrase suffit :

Start my dev server and monitor it for errors

Claude démarre le serveur, enveloppe sa sortie dans un observateur en arrière-plan, et reste silencieux jusqu'à ce que quelque chose casse vraiment. Zéro token brûlé pendant qu'il ne se passe rien.

Ce Qui a Changé

Anthropic a livré l'outil Monitor le 9 avril 2026. Claude Code PM Noah Zweben l'a annoncé ainsi : "Claude peut maintenant suivre les logs pour les erreurs, poller les PRs via script, et plus encore. Gros économiseur de tokens et excellente façon de s'éloigner du polling dans la boucle d'agent."

Le basculement sous-jacent va d'un déclencheur horloge à un déclencheur événement. L'ancien modèle avait Claude qui jetait un coup d'œil à l'état sur un timer. Le nouveau modèle a Claude assis avec la sortie, réagissant quand quelque chose apparaît. C'est le même saut que tu fais quand tu arrêtes de taper une base de données toutes les quelques secondes et que tu commences à t'abonner à son flux de changements. Le modèle timer brûle des ressources sur rien. Le modèle stream réagit à l'instant où un changement arrive.

Mécaniquement, l'outil est simple. Claude lance une commande shell et traite sa sortie standard comme un flux d'événements. Chaque ligne réveille la session principale. Une commande silencieuse ne coûte rien. Dès que ton filtre correspond à une ligne, cette ligne tombe dans la conversation et Claude commence à travailler dessus. Le processus sous-jacent continue de tourner en parallèle.

Comment Ça Fonctionne

Chaque monitor prend quatre paramètres :

command contient la logique. Une ligne de sortie standard égale une notification. Si plusieurs lignes arrivent dans une fenêtre de 200 millisecondes, elles sont groupées en une seule alerte, pour que la sortie multi-lignes d'un vrai événement se lise encore comme une seule chose. Stderr est redirigé vers un fichier que tu peux lire plus tard et ne réveille pas Claude.

Utilise persistent: true quand le monitor est censé vivre aussi longtemps que ta session. Les observateurs de serveur de dev, les tailers de logs, les monitors de PR. Pour tout ce qui est borné, comme un seul déploiement ou une seule exécution de tests, passe timeout_ms et le monitor meurt quand la fenêtre se ferme.

Deux Formes de Monitors

Les filtres de flux surveillent une sortie continue et remontent les lignes correspondantes :

# Watch application logs for errors
tail -f /var/log/app.log | grep --line-buffered "ERROR"
 
# Watch file system changes
inotifywait -m --format '%e %f' /watched/dir
 
# Node script that emits events from a WebSocket
node watch-for-events.js

Les filtres poll-et-si vérifient une source à intervalle régulier et émettent quand les conditions changent :

# Poll GitHub PR for new comments every 30 seconds
last=$(date -u +%Y-%m-%dT%H:%M:%SZ)
while true; do
  now=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  gh api "repos/owner/repo/issues/123/comments?since=$last" \
    --jq '.[] | "\(.user.login): \(.body)"'
  last=$now; sleep 30
done

Les deux formes suivent le même contrat. Stdout est un flux d'événements. Le silence ne signifie rien à signaler. Claude continue à travailler sur ce que tu lui as demandé pendant que le monitor tourne en arrière-plan.

Le Calcul des Tokens

Imagine /loop qui vérifie une suite de tests toutes les 2 minutes pendant une exécution de 10 minutes. Ça fait 5 appels API complets. Rechargement du contexte, traitement du prompt, génération de la réponse, à chaque fois. Tu paies 5 allers-retours et 4 d'entre eux ne renvoient rien d'utile.

Un monitor inverse cette équation. Claude suit la sortie filtrée du test runner. Quand le test n°23 échoue à la minute 4, la ligne d'échec arrive dans la session immédiatement. Claude peut commencer à travailler sur le correctif pendant que les tests 24 à 47 continuent de tourner. Rien de gaspillé. Rien de retardé. Plus le workflow est long, plus l'économie est grande. Tout ce qui dure longtemps en bénéficie, y compris les exécutions CI qui durent des heures, les jobs de déploiement, et les builds de nuit.

Cas d'Usage Pratiques

Capture d'erreurs du serveur de dev. Surveille un serveur de dev Next.js ou Vite et reçois un ping à l'instant où une erreur de build ou une boucle de crash apparaît. Fini de faire défiler les anciens terminaux pour trouver le point de rupture.

Triage de suite de tests. Un test qui échoue remonte à l'instant où il échoue. Claude peut ouvrir un correctif pendant que le reste de la suite tourne encore.

Surveillance du pipeline de déploiement. Attache un filtre à ton flux CI/CD et réveille Claude sur les échecs, les avertissements, ou quand une étape de déploiement donnée se termine.

Polling de revue de PR. Reste sur une pull request GitHub et réagit aux nouveaux commentaires, demandes de revue, ou vérifications de statut au fur et à mesure qu'ils arrivent. Chaque nouveau commentaire devient quelque chose sur lequel Claude peut travailler immédiatement.

Surveillance des logs. Pointe un filtre vers tes logs de production ou de staging. Dès qu'une ligne correspond au pattern, elle atterrit dans la session comme un événement et Claude peut répondre immédiatement.

Trois Règles pour de Bons Monitors

1. Ne jamais piper via grep sans --line-buffered. Sans ce flag, le buffering du pipe peut retenir des événements pendant des minutes. De loin le problème le plus fréquent.

2. Avaler les échecs transitoires dans les boucles de polling. Ajoute || true à chaque appel API pour qu'un mauvais aller-retour réseau ne fasse pas tomber tout le monitor avec lui.

3. Garder stdout serré. Chaque ligne que tu émets devient un message dans la conversation. Un observateur qui émet trop d'événements est arrêté automatiquement par Claude Code. Filtre toujours les logs bruts avant de les piper. Ne jamais déverser un flux complet non filtré.

# Good: selective filter
tail -f app.log | grep --line-buffered "ERROR\|WARN\|FATAL"
 
# Bad: firehose that will auto-stop
tail -f app.log

Les intervalles de polling comptent aussi. 30 secondes ou plus pour tout ce qui est distant, parce que les limites de taux s'appliquent. 0,5 à 1 seconde fonctionne bien pour les vérifications locales.

Monitor vs. Hooks vs. Tâches Planifiées

Il y a maintenant trois couches d'automatisation dans Claude Code, et chacune écoute un type différent de déclencheur.

Les hooks se réveillent sur les propres actions de Claude, comme une modification de fichier ou un commit. Les tâches planifiées se réveillent sur l'horloge. Monitor se réveille sur le monde extérieur. Les configurations les plus solides combinent les trois. Les garde-fous sont sur les hooks, la maintenance périodique est sur les tâches planifiées, et l'observabilité en direct de tout le reste est sur monitor.

Monitor vs. run_in_background

Les gens les confondent. Les deux lancent des choses en arrière-plan. La différence, c'est le modèle de feedback.

run_in_background est de type fire-and-forget. Tu reçois exactement une notification quand la commande se termine. Rien entre les deux. Bien pour "lance ce build et dis-moi quand c'est terminé."

Un monitor est un flux en direct à la place. Une notification se déclenche pour chaque événement correspondant en chemin. Bien pour "lance ce build et dis-moi à l'instant où quelque chose cloche." Claude reste réactif pendant que le processus tourne encore, pas seulement après sa sortie.

Prochaines Étapes

• Apprends comment les hooks complètent les monitors en validant les propres actions de Claude
• Explore les boucles d'agent autonomes où les monitors fournissent le signal de feedback
• Lis sur la gestion du contexte pour garder les longues sessions monitorées efficaces
• Voir les tâches planifiées pour l'automatisation basée sur le temps qui se couple avec la surveillance orientée événements
• Essaie les boucles de feedback pour resserrer le cycle entre l'écriture de code et la détection de problèmes

L'outil Monitor occupe le slot manquant entre "Claude exécute des choses" et "Claude observe des choses." Le travail en arrière-plan était avant une boîte scellée qui ne s'ouvrait qu'à la toute fin. Aujourd'hui Claude est aux côtés du processus, réagissant à ce qui mérite attention et restant les mains libres sur ce qui ne le mérite pas. Une forme de programmation en binôme vraiment différente.