Anthropic a sorti Agent View dans Claude Code le 11 mai 2026. Le Big Data a parlé d’une “armée d’agents IA en une vue” — c’est la promesse, et le dashboard fait effectivement ça. Le process supervisor existe, il garde tes sessions actives même quand tu fermes le terminal, l’architecture tient debout.
Mais une semaine, c’est suffisant pour voir les craquements. La doc officielle contient une phrase que personne ne répète à voix haute : dix agents tournant en parallèle bouffent ton quota à peu près dix fois plus vite qu’une seule session. La communauté trouve les autres fissures — crashes du supervisor quand /bg et l’appli desktop sont sur la même session, agents qui s’emballent en boucles de reasoning interminables en cramant des tokens en silence, le mur de “thread limit reached” qui tape plus tôt que prévu, et le comportement worktree par défaut qui règle les conflits de fichiers mais te coupe de l’état réel de ton environnement de dev.
Voici le rapport de terrain honnête. Ce qui marche, ce qui pète, et les calculs de coût que t’as intérêt à faire avant de balancer six tâches et aller te faire un café. Particulièrement pertinent si tu es freelance ou dans une petite équipe française où le passage du plan Pro à $20 au plan Max à $100/mois représente un saut de 5x — calcul que les devs US font pas forcément avec la même attention.
Ce qu’est concrètement Agent View
Agent View, c’est un dashboard CLI que tu ouvres avec claude agents depuis n’importe quel terminal. Il liste toutes tes sessions Claude Code en arrière-plan — à travers tous tes projets, peu importe le dossier d’où tu l’as ouvert — et te laisse jeter un œil au dernier output de chaque session, répondre sans t’attacher, ou prendre le contrôle complet d’une conversation avec la flèche droite. Les sessions sont groupées par état : épinglées en haut, puis “Ready for review”, “Needs input”, “Working”, “Completed”.
Trois commandes couvrent l’essentiel :
claude agents— ouvre le dashboard/bg— envoie la session de premier plan vers l’arrière-plan (et dans Agent View)claude --bg "<tâche>"— lance une session directement en arrière-plan depuis ton shell, sans passer par le premier plan
Plus --name "fix-test-flaky" pour des labels lisibles, et --agent code-reviewer pour un sub-agent spécifique comme agent principal. Et les commandes shell de management : claude attach <id>, claude logs <id>, claude stop <id>, claude respawn --all. Rien de compliqué à retenir.
Agent View demande Claude Code v2.1.139 ou plus récent. Vérifie avec claude --version ; si t’es sur une version plus vieille, claude update te met à jour.
Le supervisor process et pourquoi il change le modèle mental
Ce qui fait fonctionner Agent View, c’est le supervisor process par utilisateur — un process séparé de ton terminal et d’Agent View lui-même. Il démarre automatiquement à la première mise en arrière-plan d’une session, héberge toutes les sessions en background, et survit à la fermeture du terminal, à la fermeture d’Agent View, et aux auto-updates de Claude Code. Tu le gères pas directement.
Avant Agent View, une session Claude Code vivait dans le terminal qui l’avait lancée. Tu fermes le terminal, la session meurt. Après Agent View, une session en background vit dans le supervisor, un process séparé et détaché. Tu fermes le terminal, la session continue. L’auto-updater remplace le binaire en plein milieu d’une tâche, le supervisor se reconnecte à tes sessions in-flight quand il remonte.
L’état est stocké à trois endroits sur le disque :
~/.claude/daemon.log— log du supervisor ; là où regarder quand quelque chose part en sucette~/.claude/daemon/roster.json— liste des sessions en background, utilisée pour reconnect après restart du supervisor~/.claude/jobs/<id>/state.json— état par session, un fichier par session
Quelques limites honnêtes : les sessions en background sont locales, donc elles s’arrêtent si ton Mac entre en veille ou ton Linux s’éteint. Après environ une heure d’idle sans attachement, le supervisor stoppe le process pour libérer des ressources — peek ou attach le redémarre depuis le point d’arrêt. Et les modes de permission bypassPermissions / auto sont refusés au dispatch tant que tu les as pas acceptés interactivement une fois dans ce répertoire.
La maths de coût que tout le monde évite
Citation textuelle de la section Limitations de la doc officielle : “Les rate limits s’appliquent : les sessions en background consomment ton quota d’abonnement comme les sessions interactives, donc faire tourner dix agents en parallèle consomme du quota à peu près dix fois plus vite que d’en faire tourner un.”
Cette phrase fait beaucoup de boulot. Elle veut dire que la fenêtre d’usage de 5 heures du plan Max ne s’étire pas quand tu travailles en parallèle. Elle se compresse. Si une session interactive seule épuise ton budget Max en cinq heures, dix sessions parallèles l’épuisent en environ trente minutes. Le supervisor ne partage pas la dépense de tokens entre sessions. Chaque session est sa propre conversation indépendante qui tape la model API.
Trois chiffres pour le contexte. Un développeur a documenté 781 000 tokens dans une seule session Claude Code Max cette semaine — une session, un terminal, un projet. Un autre rapport mentionnait qu’Uber a brûlé son budget IA 2026 entier en quatre mois sur Claude Code. Et un take très partagé d’un utilisateur agacé cette semaine décrivait “gâcher 80 000 à 200 000 tokens pour fixer de petits bugs” — c’est le coût d’une feature sur une session, avant de paralléliser quoi que ce soit.
Pour le contexte freelance/PME français : le plan Pro à $20/mois est accessible pour un dev solo. Le plan Max à $100/mois représente un 5x du coût opérationnel. Si la lecture d’Agent View est “j’ai lancé dix agents en parallèle et ça me libère l’après-midi”, la lecture réelle, c’est “j’ai compressé cinq heures de boulot d’un agent en trente minutes, en dépensant la même chose.” La productivité monte, oui. La dépense aussi.
Les cinq modes de panne de la première semaine
Un pattern émerge de la première semaine publique. Les pannes se groupent en cinq catégories, et seule une (les conflits de fichiers) est résolue par l’architecture par défaut d’Anthropic. Le reste, c’est encore du brut.
1. Le crash /bg + Agent View + Desktop. Un utilisateur a posté le 16 mai des screenshots de Claude Code qui plante avec Claude Code process exited with code 1 quand /bg est utilisé pendant que l’appli desktop est attachée à la même session. Contournement : détacher la desktop d’abord, ensuite /bg, ensuite ouvrir Agent View. Si tu utilises pas la desktop, ce bug te concerne pas.
2. Sessions qui pendouillent et deadlocks au switching. Un utilisateur le 12 mai : le supervisor pendouille au démarrage et le switch entre agents en background “pendouille genre une minute, on dirait un deadlock.” Pattern : tu dispatch trois ou quatre sessions, la première finit, tu fais flèche pour passer à la deuxième, et le dashboard se fige 30-60 secondes. Anecdotiquement ça se détend si tu laisses au dashboard une minute pour respirer après le dispatch.
3. Le mur “thread limit reached”. Un utilisateur le 17 mai s’est cogné à One QA/accessibility reviewer did not spawn because the thread limit is reached. C’est pas le rate-limit de quota — c’est un plafond de concurrence sur le dispatch lui-même. La doc officielle ne nomme pas de chiffre, mais les rapports de communauté le placent constamment entre 5 et 7 sessions actives simultanées sur les plans consumer. Si tu vois cette erreur, arrête de dispatcher, attends que les in-flight finissent ou passent à Needs input, puis reprends.
4. Le pattern “s’est envolé et a cramé les tokens”. Plusieurs rapports cette semaine de sessions qui sortent du rail et consomment du budget en silence. Un dev chinois : “Quand je fais tourner 4 subs en parallèle, souvent un s’envole — la liste te laisse juste regarder cramer les tokens.” Un autre rapport documentait cinq pannes silencieuses en neuf jours, dont un agent avec DELETE SQL qui a effacé 24 000 lignes en prod. Mitigation : pas dispatcher de travail destructif en mode auto ou bypassPermissions.
5. La limite de 2 agents par host (rare, réelle). Un utilisateur le 13 mai : “j’arrive pas à faire tourner plus de 2 claude agents sur le même host sans qu’ils s’entrecassent.” Semble lié à des environnements locaux spécifiques — probablement des limites Mac sur les file watchers ou le compte de process. Si tu tapes ce mur à 2 agents, tu fais rien de mal — t’as juste tapé un plafond spécifique à ton environnement.
Le default git worktrees — régler les conflits à la sauce Anthropic
La décision architecturale intéressante d’Agent View, c’est ce qui se passe quand deux sessions touchent au même fichier. La réponse est dans un paragraphe de la doc : “Avant d’éditer des fichiers, Claude déplace la session dans un git worktree isolé sous .claude/worktrees/, comme ça les sessions parallèles peuvent lire le même checkout mais chacune écrit dans le sien.”
Traduction : chaque session en background qui touche des fichiers dans un repo git a son propre worktree sous .claude/worktrees/<session-id>/. Lecture depuis le repo partagé, écriture isolée. Quand tu supprimes la session, le worktree est nettoyé — mais les changements non commités partent avec. Push ou commit avant de supprimer.
Ça règle proprement le problème de “deux agents qui éditent le même fichier” pour toute session qui tourne dans un repo git. Ça a deux conséquences pratiques à connaître.
D’abord : les sessions hors d’un repo git tombent direct dans le répertoire de travail, sans isolation. Si tu dispatch du travail parallèle sur un projet non-git, tu peux clairement générer des collisions. git init coûte rien et élimine toute une classe de bugs.
Ensuite : une session dans son propre worktree perd la conscience de ton environnement de dev actif. Un dev l’a signalé le 13 mai : “Agent View dispatche les sessions vers des git worktrees isolés. C’est super pour éviter les collisions de fichiers, mais il y a un trade-off — l’agent perd la conscience de ton vrai environnement de dev.” Fix : commit (ou stash sur le checkout principal) avant de dispatcher du travail qui a besoin de voir l’état actuel.
Ce que ça veut dire pour toi
Solo dev / freelance sur plan Pro. Pense pas à Agent View comme un feature de 10 agents parallèles. Pense à ça comme “une tâche courte en background pendant que je finis cette modif.” Une tâche, la laisser tourner, peek quand tu changes de contexte. Tu vas cramer du quota plus vite qu’en restant purement interactif, mais le boost de productivité est réel parce que tu te bloques plus sur la tâche longue. Plafond réaliste sur Pro : deux sessions parallèles.
Plan Max ou petite équipe dev. Trois à cinq sessions parallèles, c’est le plafond de travail réaliste. Au-dessus, tu tapes le thread limit, le deadlock de switching du dashboard, et les fenêtres de pause du supervisor. Chaque session scopée à une préoccupation — “fix le test flaky X”, pas “investigue la suite de tests.” Dispatch avec --name pour la retrouver plus tard. Commit avant de dispatcher quoi que ce soit qui touche à ta branche de dev. Toujours defaultMode au dispatch, jamais auto.
Plus grosse équipe / plan Enterprise. Là, Agent View gagne sa place. Le quota tolère 5-10 sessions parallèles. Les babysitters de PR, les updaters de dashboard, les jobs en boucle /loop s’installent dans le dashboard et laissent un dev triage ce qui serait sinon douze changements de contexte séparés. Avec --cwd, scope Agent View à un projet par terminal. Et CLAUDE_CODE_DISABLE_AGENT_VIEW=true sur les environnements CI où tu veux pas que des sessions s’accumulent en silence.
Ce qu’Agent View ne sait pas (encore) faire
- Pas survivre à la mise en veille. Les sessions background s’arrêtent quand ton Mac dort ou ton Linux s’éteint. Elles apparaissent en Failed quand tu réveilles.
claude respawn --allles récupère, mais si tu comptais sur un agent qui tourne pendant la nuit avec le laptop fermé, c’est mort. - Pas partager le quota entre sessions. Dix sessions = dix fois la vitesse de burn. Pas de remise parallèle.
- Pas bloquer les actions destructrices. Si tu dispatch en
autoet l’agent supprime 24 000 lignes de BDD, Agent View te montre la ligne passer au vert. Le supervisor n’interrompt pas les appels tool destructifs. - Pas unifier la liste de sessions entre machines. Agent View est local. Dispatch depuis le laptop de boulot et regarder depuis le Mac de la maison : pas possible. Pour ça, il y a la version web de Claude Code.
- C’est encore Research Preview. Le flag
disableAgentViewexiste pas par hasard. Interface et raccourcis peuvent changer.
Le bilan final
Agent View, c’est un vrai déblocage de productivité pour le travail parallèle, et l’architecture du supervisor est la bonne réponse à “qu’est-ce qui se passe quand je ferme le terminal.” Le titre des 10 agents parallèles est techniquement possible, occasionnellement utile, et une catastrophe de quota si tu l’attaques en default. Trois à cinq sessions parallèles, c’est le sweet spot pour la plupart. Commit avant de dispatch. Reste en defaultMode. Traite chaque session comme une tâche scopée avec une préoccupation claire.
Si les sessions parallèles, c’est la partie de Claude Code que tu veux pousser le plus fort, notre cours Claude Code Maîtrise traverse les patterns de dispatch, la gestion des worktrees, et les habitudes de budget de quota qui transforment Agent View en multiplicateur de productivité qu’il promet. Pour le contexte plus large des agents IA, Agents IA couvre la conception et l’orchestration de systèmes multi-agents.
Sources
- Gérer plusieurs agents avec la vue agent — Doc officielle FR
- Agent view in Claude Code — Anthropic Blog
- Agent View débarque sur Claude Code : votre armée d’agents IA en une vue — Le Big Data
- Que peut-on faire avec Claude Code ? Guide 2026 — Plateya
- Claude Code : pourquoi cet agent IA fait-il le buzz en 2026 ? — Jedha
- Agent View arrives in Claude Code for multitasking — AIN
