Claude Code Agent View : le cockpit multi-agent est arrivé

Claude Code Agent View montre que les agents de codage quittent le stade des sessions terminal isolées pour devenir une opération d’ingénierie pilotable. La vraie question n’est plus « un agent peut-il écrire du code ? » mais « une équipe peut-elle voir l’état, les blocages, le coût et les critères de fin avant que des agents parallèles touchent au travail de production ? »

Anthropic a publié Claude Code v2.1.139 le 11 mai 2026. Le changelog officiel de Claude Code liste Agent View, la commande /goal, les overlays de tokens, les détails de coût des plugins, les arguments d’exécution des hooks et des améliorations autour de continueOnBlock. Le registre npm indique aussi @anthropic-ai/claude-code version 2.1.139 comme latest et next, publié le 2026-05-11T18:09:28Z.

Cet ensemble compte parce qu’il relie trois problèmes longtemps séparés : visibilité multi-agent, ligne d’arrivée explicite et contrôle des coûts. Pour les responsables engineering, Claude Code Agent View n’est pas seulement une interface agréable. C’est un aperçu du système d’exploitation dont les workflows sérieux de codage IA auront besoin.

Ce que Claude Code Agent View change

La documentation Agent View décrit une research preview ouverte avec claude agents, qui liste dans un seul écran les sessions Claude Code en arrière-plan. Elle montre les sessions en cours, celles qui attendent une entrée et celles qui sont terminées. L’opérateur peut regarder une session, répondre sans quitter la vue, s’y attacher pour la conversation complète, puis se détacher pendant que le travail continue.

Cette évolution semble modeste jusqu’à ce qu’on la compare à l’usage habituel des agents de codage. Un développeur ouvre plusieurs terminaux : un agent corrige un bug, un autre inspecte les logs, un troisième met les tests à jour. Après vingt minutes, le humain doit se souvenir de la tâche de chaque terminal, du blocage éventuel et du diff digne de confiance. Plus les agents vont vite, plus le humain devient gestionnaire de file d’attente.

Claude Code Agent View rend cette file visible. Le codage parallèle cesse d’être une archéologie de terminaux pour devenir une boucle d’opérateur : lancer, observer, interrompre, inspecter, attacher, fusionner. C’est le même principe que dans Reviewmaxxing : le protocole pour les PR d’agents : la production d’un agent n’aide que si la revue humaine est structurée.

Le choix de supervision locale est important. Les sessions en arrière-plan sont hébergées par un processus superviseur par utilisateur, continuent après détachement du terminal et stockent leur état dans le répertoire de configuration Claude. Les administrateurs peuvent désactiver la fonctionnalité via un paramètre géré. C’est la bonne posture initiale : assez puissante pour de vrais workflows, assez contrôlable pour les équipes soumises à des politiques.

Le cockpit expose l’état, les blocages et le travail en arrière-plan

Agent View est utile parce qu’il répond à trois questions : qu’est-ce qui tourne, qu’est-ce qui bloque, et où existe une preuve de fin ? Sans cela, le multi-agent coding devient une autonomie bruyante. Avec cela, les équipes peuvent traiter les agents comme des travailleurs dans une voie de livraison observable.

La documentation décrit des interactions concrètes. Une ligne montre l’état d’une session. Space ouvre un panneau d’aperçu. Enter attache la session. La flèche gauche détache sans arrêter le travail. claude --bg "prompt" lance une session arrière-plan directement depuis le shell. La documentation rappelle aussi que les limites d’usage restent applicables : dix sessions arrière-plan peuvent consommer environ dix fois le quota d’une seule session.

Cet avertissement n’est pas secondaire. C’est le coût opérationnel du parallélisme. Si cinq agents passent chacun trente minutes à explorer la même panne de dépendance, l’équipe n’a pas gagné cinq travailleurs. Elle a acheté cinq copies de la même confusion. Un cockpit n’aide que si l’équipe définit aussi la propriété : un agent lit les logs, un autre écrit le patch minimal, un autre met les tests à jour, un autre relit le diff.

Claude Code Agent View s’inscrit donc dans le mouvement plus large des plans de contrôle. Nous l’avons expliqué dans Hermes Web Dashboard : le prochain gain de productivité ne vient pas d’un état caché. Il vient d’un état suffisamment visible pour permettre une intervention humaine précoce.

Pour une équipe de production, le cockpit devrait exposer au moins six champs avant merge : propriétaire de la tâche, dépôt ou worktree, état actuel, dernier blocage, dépense en tokens et preuve demandée. Claude Code fournit plusieurs primitives dans la CLI. Le reste doit vivre dans le modèle de pull request, les commentaires CI ou le tracker.

Les goals transforment les prompts en contrats de fin

La commande /goal est le deuxième élément majeur. La documentation Claude Code sur les goals indique que /goal définit une condition de fin et garde Claude au travail sur plusieurs tours jusqu’à ce que la condition soit remplie ou effacée. Elle fonctionne en mode interactif, en mode non interactif -p et via Remote Control.

Cela change la forme d’un prompt. Un prompt classique dit : « Corrige les tests auth. » Un goal utile dit : « npm test -- test/auth termine avec 0, aucun fichier hors src/auth et test/auth n’est modifié, et la réponse finale cite le test défaillant puis la commande qui passe, ou arrête après 12 tours. » La deuxième version définit résultat, preuve, frontière et règle d’arrêt.

La documentation précise une limite saine : l’évaluateur juge ce que Claude a rendu visible dans la conversation. Il n’exécute pas lui-même les commandes et ne lit pas les fichiers indépendamment. Cette contrainte force l’agent principal à montrer les preuves dans le transcript. La condition peut atteindre 4 000 caractères, assez pour encoder de vraies contraintes sans transformer chaque tâche en document de conformité.

C’est la différence entre théâtre d’autonomie et autonomie opérationnelle. L’agent ne doit pas continuer parce que le prompt semble ambitieux. Il doit continuer parce que l’équipe a défini une condition mesurable. Le même principe se trouve dans Exécuter Codex en sécurité : sandbox, approbations, règles réseau, secrets et télémétrie n’aident que si le système sait ce qu’il doit prouver.

Un bon contrat de fin comporte cinq pièces :

• Résultat : l’état final technique ou métier, comme un test vert ou un rapport de migration.
• Preuve : la commande, le diff, la capture ou la ligne de log qui démontre le résultat.
• Frontière : fichiers, systèmes, secrets ou services que l’agent ne doit pas toucher.
• Budget : limite de tokens, tours ou temps avant arrêt et demande d’aide.
• Revue : vérification humaine ou par second agent avant merge.

La commande /goal donne un endroit natif pour exprimer ce contrat. Sa valeur n’est pas une évaluation magique. Sa valeur est de rendre la ligne d’arrivée visible.

La télémétrie de coût rend le codage parallèle gouvernable

La version ajoute aussi l’affichage du temps écoulé, des tours et des tokens dans l’overlay des goals. Elle ajoute claude plugin details <name> pour montrer l’inventaire des composants et le coût de tokens projeté par session. Ces fonctions ne sont pas glamour. C’est précisément pour cela qu’elles comptent.

Le développement agentique échoue discrètement lorsque les coûts sont invisibles. Une équipe voit une PR fusionnée et célèbre l’heure humaine économisée. Elle ne voit pas les huit tentatives d’agent, les rechargements de contexte, les recherches dupliquées et le temps de revue nécessaire au nettoyage. La visibilité des tokens transforme cette dépense cachée en variable d’ingénierie.

Une équipe pratique devrait suivre trois ratios : tokens par ligne de diff acceptée, tours d’agent par test vert et minutes de revue humaine par changement fusionné. Ces chiffres n’ont pas besoin d’être parfaits. Ils donnent une direction. Si le coût en tokens double sans amélioration de qualité, le workflow a besoin d’un goal plus serré ou d’une tâche plus petite.

Agent View peut aussi empêcher de mauvais incentives. Si les managers ne comptent que le débit d’agents, ils créent plus de branches, plus de PR et plus de charge de revue. S’ils voient blocages et coûts, ils savent quand arrêter, redécouper ou réassigner une tâche. C’est aussi la leçon de Vercel deepsec : la sécurité vient de contrôles répétables, pas de la confiance affichée par l’agent.

Il existe une deuxième dimension de coût : plugins et hooks. Claude Code v2.1.139 expose le coût de tokens projeté des plugins et ajoute args: string[] pour les hooks, afin de lancer les commandes directement sans quoting shell. Pour les entreprises, cette combinaison compte. Les plugins ajoutent de la capacité, les hooks ajoutent du contrôle, et les deux doivent être budgétés.

Checklist de déploiement pour les équipes engineering

Claude Code Agent View est une research preview. Les équipes ne devraient donc pas l’activer partout sans garde-fous. Le meilleur départ est un pilote contrôlé avec des voies explicites.

Commencez par du travail non chevauchant : investigation de logs, réparation de tests, documentation, analyse d’impact de dépendances et bugs isolés. Les mauvais premiers cas sont les changements d’architecture transverses, les migrations sans rollback, le paiement, les règles d’authentification et tout ce qui touche aux secrets de production.

Définissez une voie de revue avant de lancer les agents. Chaque session arrière-plan doit avoir un propriétaire, une branche ou un worktree, un contrôle d’acceptation et une frontière « ne pas toucher ». L’opérateur inspecte les blocages depuis Agent View, mais le merge final exige encore tests et code review. Si l’équipe a déjà un protocole de revue, Agent View devient le tableau de statut qui l’alimente.

Utilisez les goals pour les tâches prouvables, pas pour l’exploration vague. « Trouve trois causes probables et cite les lignes de log » est un goal utile. « Améliore la performance » ne l’est pas. Pour l’exploration, demandez d’abord un court rapport, puis créez un second goal pour le patch. Cette séparation rend le coût lisible.

Définissez enfin un kill switch. La documentation mentionne disableAgentView et une variable d’environnement pour couper les agents arrière-plan. Les entreprises doivent documenter qui peut activer Agent View, quels dépôts sont autorisés, quelles données sont exclues et quels journaux d’audit sont requis.

Pour les acheteurs de partenaires de développement IA, c’est le vrai signal. Les équipes mûres ne demandent pas si les agents produisent du code. Elles demandent si le système de livraison peut gouverner plusieurs tentatives, rejeter les sorties faibles et rendre les preuves visibles. Context Studios construit des systèmes logiciels AI-native avec gouvernance d’agents, gates de revue et télémétrie de livraison intégrées dès le départ.

La conclusion est simple : les agents de codage parallèles ont besoin de moins de bruit et de plus de cockpit. Claude Code Agent View donne un aperçu natif de ce cockpit, et /goal donne une ligne d’arrivée. Les organisations gagnantes instrumenteront état, coût, preuve et revue humaine avant d’agrandir leur flotte d’agents.

FAQ

Qu’est-ce que Claude Code Agent View ?

Claude Code Agent View est un cockpit en research preview pour gérer plusieurs sessions Claude Code en arrière-plan depuis un seul écran. Il s’ouvre avec claude agents et montre les sessions en cours, bloquées ou terminées.

La fonction sert à piloter plusieurs tâches de codage indépendantes. Elle permet de lancer, observer, répondre, attacher et détacher des sessions pendant que le travail continue.

Qu’a changé Claude Code v2.1.139 ?

Claude Code v2.1.139 a ajouté Agent View, la commande /goal, les overlays de tokens pour les goals, les détails de composants et de coût des plugins, la navigation dans les transcripts et des arguments de hook plus sûrs. Anthropic date cette version du 11 mai 2026.

Le registre npm montre la version 2.1.139 comme latest et next pour @anthropic-ai/claude-code, avec une publication à 2026-05-11T18:09:28Z.

En quoi /goal diffère-t-il d’un prompt normal ?

Un prompt normal demande du travail ; /goal définit une condition de fin et garde Claude au travail jusqu’à ce qu’elle soit remplie ou effacée. La vue de statut montre temps écoulé, tours évalués, tokens consommés et dernière raison de l’évaluateur.

Les bons goals incluent un état final mesurable, une preuve, des frontières et une règle d’arrêt. Ce sont des contrats de fin, pas des slogans.

Pourquoi les overlays de tokens comptent-ils pour les équipes ?

Les overlays de tokens rendent le coût du travail d’agent visible pendant l’exécution. Les équipes peuvent arrêter l’exploration dupliquée, découper les tâches trop grandes et comparer coût et qualité du code accepté.

Sans visibilité des tokens, le codage parallèle peut sembler productif tout en multipliant quota, charge de revue et lectures de contexte répétées.

Les entreprises doivent-elles activer Agent View immédiatement ?

Les entreprises devraient piloter Agent View dans des dépôts contrôlés avant un déploiement large. Les premiers cas adaptés sont les corrections isolées, l’analyse de logs, la réparation de tests et la documentation avec critères d’acceptation clairs.

Évitez paiement, auth, secrets et migrations multi-dépôts au départ. Les dépôts autorisés, gates de revue, exclusions de données et kill switch doivent être définis avant l’usage large.