Tu lances un refactor sur 40 fichiers. Claude Code mouline. Tu regardes le curseur clignoter. Tu peux pas ouvrir un autre terminal parce que t'as besoin du contexte déjà chargé dans cette session. Tu attends. Sept minutes, quinze minutes, parfois plus quand l'agent enchaîne les lectures de fichiers.
Cet article couvre les trois primitives qui règlent ça : /background pour détacher la session courante, /fork pour la dupliquer et explorer une branche alternative, et claude --resume pour reprendre une session fermée. On assume que t'as déjà installé Claude Code et lancé au moins une session, sinon commence par le guide complet pour apprendre Claude avant de continuer.
Précision importante avant d'entrer dans le détail : les sessions en arrière-plan existent dans Claude Code depuis mai 2026. Ce qu'on décrit ici intègre les changements de la version 2.1.212 sortie le 17 juillet 2026, qui a notamment redéfini ce que fait /fork et ajouté des garde-fous sur les boucles d'agents. Si t'es sur une version antérieure, /fork peut se comporter comme l'actuel /subtask.
Le problème que résolvent les sessions en arrière-plan
Sans sessions parallèles, ton workflow ressemble à ça : une tâche à la fois, terminal bloqué, tu switches sur autre chose (mail, Slack, café) le temps que ça tourne. Le contexte que tu as accumulé dans la session, les fichiers lus, l'archi expliquée, les décisions prises, ne peut pas être utilisé ailleurs sans tout recharger.
Avec les sessions parallèles, tu peux avoir un agent qui refactor le module d'auth pendant qu'un deuxième debug un bug en prod pendant qu'un troisième prépare un PR de migration. Trois contextes distincts, trois threads d'exécution, un seul cerveau (le tien) qui orchestre.
Les trois commandes qu'on va couvrir :
/background: détache la session courante, elle continue à tourner sans bloquer ton terminal./fork: copie la conversation en cours dans une nouvelle session en arrière-plan, la session mère continue.claude --resume(et/resume) : reprend une session fermée ou une session background listée dansclaude agents.
/background : envoyer la session courante en tâche de fond
Cas typique : tu lances un refactor gros volume, ou une génération de doc sur un repo de 200 fichiers. Tu sais que ça va prendre 10-20 minutes. Tu tapes /background, la session est détachée, tu récupères ton prompt.
Concrètement :
> refactor tous les handlers du dossier api/ pour utiliser le nouveau logger structuré
[Claude commence à lire les fichiers...]
/background
[Session detached: agent_a3f9 running in background]
$ claude agents
ID STATUS STARTED LAST_ACTIVITY TOKENS_USED
agent_a3f9 running 14:22 14:31 47.2kTu peux vérifier l'état avec claude agents. Pour rattacher la session et voir où elle en est, claude --resume agent_a3f9. La contrepartie : tant qu'elle est en background, tu ne vois pas le streaming en direct. Si l'agent a besoin d'une permission (écriture d'un fichier hors du sandbox par exemple), il attend, il ne devine pas ta réponse.
Depuis la 2.1.212, les appels d'outils MCP qui dépassent 2 minutes basculent automatiquement en arrière-plan pour ne pas geler la session. Le seuil se règle via CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS. Pratique quand t'as un MCP qui interroge une base lente ou une API externe capricieuse. Pour la configuration d'ensemble, voir configurer Claude Code correctement.
/fork : dupliquer le contexte pour explorer une branche
La différence clé avec /background : /fork ne détache pas ta session, il la copie. La copie part en background comme une session à part (tu la vois dans claude agents), la session mère continue au premier plan avec exactement le même état de conversation.
Cas d'usage type : tu as passé 20 minutes à faire lire à Claude l'archi de ton monorepo, les conventions de code, les 3 fichiers pivots. Tu veux tester deux implémentations d'une même feature. Tu tapes /fork dans la session mère, tu envoies à la copie « implémente l'option A », tu bascules mentalement sur la mère et tu tapes « implémente l'option B ». Deux branches d'exploration, un seul contexte payé une seule fois côté briefing.
Depuis la 2.1.212, attention à la nouvelle sémantique : /fork = copie en session background séparée. L'ancien comportement de /fork (lancer un sous-agent dans la même session) s'appelle maintenant /subtask. Si ton habitude était /fork pour spawner un sous-agent, remplace-le par /subtask.
Ce que fork préserve : l'historique de conversation, les fichiers déjà lus, les décisions actées. Ce qu'il ne préserve pas : l'état du système de fichiers si tu modifies les mêmes fichiers depuis les deux branches. C'est là que les git worktrees deviennent obligatoires, on y revient.
claude --resume : reprendre une session interrompue
Trois façons de récupérer une session :
claude --resumedepuis le shell : ouvre un sélecteur listant tes sessions récentes.claude --resume <session_id>: reprend directement si tu connais l'ID./resumedepuis la vueclaude agents: depuis la 2.1.212, ouvre un sélecteur incluant même les sessions supprimées de la liste, et reprend le choix en session background.
Ce qui est restauré : l'historique de conversation, les fichiers que Claude avait lus, les décisions prises. Ce qui ne l'est pas : l'état de ton file system si t'as bougé entre-temps. Si tu as reset ta branche git ou stashé des modifs, Claude va tenter de rejouer par-dessus un état qui n'existe plus. Vérifie toujours l'état du repo avant de reprendre.
Astuce pratique : commit avec un message reconnaissable avant de fermer une session longue. git log --oneline | grep claude-session retrouve le point de reprise en 2 secondes. Ça évite le classique « laquelle des 7 sessions était sur le module de paiement ? ».
Workflow type : trois agents en parallèle sur un même projet
Scénario réel, exécutable de bout en bout. T'as un repo Next.js avec un module d'auth à refactor, une migration Prisma à tester, et un bug client à débugger. Voici comment on enchaîne :
# 1. Préparer trois worktrees pour éviter les conflits
git worktree add ../proj-auth refactor/auth-logger
git worktree add ../proj-prisma migration/prisma-6
cd ./ # repo principal pour le bug client
# 2. Agent 1 : refactor auth en background
cd ../proj-auth
claude
> refactor tous les handlers api/auth pour utiliser pino
/background
# 3. Agent 2 : migration Prisma, fork depuis une session déjà briefée
cd ../proj-prisma
claude --resume prisma_brief_session
/fork
> applique la migration schema.prisma vers Prisma 6, regenère le client
# 4. Agent 3 : debug interactif au premier plan
cd ./
claude
> ticket #4821 : le webhook Stripe renvoie 500 sur les refunds partiels
Les agents 1 et 2 tournent en arrière-plan, tu bosses en interactif sur le bug. Toutes les 10 minutes, claude agents pour vérifier l'état. Quand un agent finit, claude --resume <id> pour valider les modifs, review, commit, merger le worktree.
Le point clé : trois worktrees, trois dossiers physiques, zéro chance que deux agents écrivent dans le même fichier au même moment. Pour aller plus loin sur l'orchestration de plusieurs agents, on couvre ça en détail dans multi-agents Claude et sur la fiche outil Claude Code.
Pièges à éviter et bonnes pratiques
Ce qui casse en pratique, dans l'ordre de fréquence :
| Piège | Symptôme | Fix |
|---|---|---|
| Deux agents, même fichier | Conflits git, réécriture croisée | Un git worktree par agent long |
| Session background oubliée | Tokens qui tournent dans le vide | claude agents avant chaque fin de journée |
| 5 forks empilés | Tu ne sais plus qui a fait quoi | Max 3 sessions actives, nomme-les |
Kill du terminal au lieu de /exit | Session zombie, contexte perdu | Toujours /exit pour fermer proprement |
| Boucle WebSearch d'un agent background | 200+ recherches, quota consommé | Plafond par défaut à 200, réglable via CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION |
La 2.1.212 a ajouté deux plafonds de sécurité par session : 200 appels WebSearch et 200 sous-agents lancés, tous deux réglables via variables d'environnement. Ces valeurs sont des défauts modifiables, pas des limites universelles. Un /clear réinitialise le compteur sous-agents. Utile quand tu débugges une chaîne d'agents qui s'auto-appellent et que tu veux couper court sans tuer la session.
Sur la facturation : si t'es en mode API pur (pas abonnement Claude.ai), chaque session background consomme des tokens tant qu'elle tourne, même à vide. À partir de 10 $ par million de tokens en entrée pour Fable 5, une session oubliée qui reste à idle sur un gros contexte, ça se sent en fin de mois. Un claude agents avant de fermer le laptop, ça prend 3 secondes. Pour choisir entre les modèles selon le coût, voir Claude Pro ou Max.
Dernier point pratique : le mode plan a été corrigé dans la 2.1.212. Avant, certaines commandes Bash modifiant des fichiers (touch, rm) pouvaient s'exécuter automatiquement sans prompt de permission ni callback SDK. C'est réglé. Si t'utilises Claude Code en mode plan pour de la revue avant exécution, mets à jour.
Passer à la pratique
Ces trois primitives, tu ne les intègres pas en lisant, tu les intègres en les utilisant. Lance une session, fais lire à Claude l'archi de ton projet en cours, tape /fork, envoie deux implémentations différentes de la même feature en parallèle. En une matinée tu sauras si ton workflow tient la route.
Si tu bosses sur un produit et que tu veux passer de « je teste Claude Code » à « j'expédie un MVP avec agents en parallèle », on couvre l'archi complète (worktrees, agents spécialisés, orchestration MCP, déploiement) dans le programme Construire votre produit IA en 5 semaines. C'est fait pour les gens qui veulent shipper, pas pour ceux qui veulent regarder shipper.