Claude Code : les appels MCP longs passent en arrière-plan, comment en profiter sans bloquer votre session

Tu lances un export CRM ou un audit de site depuis Claude Code, et la conversation se fige pendant quatre minutes. Depuis fin 2026, ce n'est plus une fatalité : un appel d'outil MCP qui s'éternise peut passer en tâche d'arrière-plan, et tu gardes la main sur ta session. Cet article explique ce qui se passe, comment le vérifier, comment concevoir un outil qui s'y prête, et quand ne pas s'en servir. Si tu démarres avec Claude, commence par apprendre Claude de zéro.

En bref :

• Un appel d'outil MCP encore en cours après 2 minutes (120 000 ms par défaut) passe en tâche d'arrière-plan, et Claude Code continue de répondre.
• Le résultat revient sous forme de notification quand l'appel se termine, avec un compteur du type « 1 MCP task » en pied de page.
• Les MCP tasks, où le serveur exécute lui-même le travail long, exigent Claude Code v2.1.304 ou plus et restent en bêta publique dans le CLI.
• Sans validation humaine, ne laisse jamais tourner seul un outil irréversible ou facturé à l'usage.

Que change le passage des appels MCP longs en arrière-plan dans Claude Code ?

Sans cette bascule, un outil MCP lent occupe la conversation jusqu'à sa fin. Avec elle, un appel qui dépasse 2 minutes bascule en tâche de fond : Claude reçoit tout de suite un identifiant de tâche, continue de travailler avec toi, et le résultat arrive en notification quand l'appel est terminé. Si Claude est inactif à ce moment, il s'y remet sans que tu le relances.

Prends un outil qui lance un export de 4 minutes. À la deuxième minute, la session se libère. Tu demandes autre chose pendant l'attente, tu vois « 1 MCP task » en bas de l'écran, et quand l'export finit, Claude te le signale. Pour savoir où en sont les tâches, ouvre /tasks : en sélectionnant une tâche et en appuyant sur x, tu demandes l'annulation au serveur (qui peut quand même terminer son travail). Échap, lui, n'arrête pas une tâche d'arrière-plan.

Deux mécanismes se ressemblent et il faut les distinguer. Le premier est la mise en arrière-plan automatique côté client : elle ne survit pas à la fermeture de la session. Le second, les « MCP tasks », repose sur une extension du protocole : le serveur exécute lui-même le travail long, l'appel revient dès qu'il l'accepte, et la tâche d'un serveur distant continue même après la sortie de Claude Code. Le changelog de la version 2.1.319 (6 novembre 2026) précise que Claude Code passe alors l'appel en arrière-plan et rapporte le résultat à Claude à la fin. La version minimale et les réglages sont détaillés dans la documentation officielle de Claude Code, à consulter avant d'écrire une ligne de configuration.

Quels types d'outils MCP profitent vraiment de l'arrière-plan ?

Les outils qui durent plus de quelques dizaines de secondes et dont le résultat n'est pas nécessaire à ta prochaine étape immédiate. Le critère est simple : si tu fixerais l'écran en attendant, l'arrière-plan te fait gagner. Pour un dirigeant, quatre cas reviennent souvent :

• génération d'un rapport de ventes à partir d'un CRM ;
• audit ou scraping d'un site entier ;
• traitement d'un lot de fichiers (conversion, extraction, renommage) ;
• build ou déploiement d'un projet.

À l'inverse, un outil rapide (lire un fichier, interroger une valeur) n'a aucun intérêt à passer en tâche de fond : il rend sa réponse avant même que la bascule ne se déclenche. Comme heuristique, et non comme règle officielle, vise les outils au-delà d'une minute : en dessous, l'attente reste supportable et la complexité ajoutée ne paie pas.

Un dernier critère, souvent oublié : la dépendance. Si l'étape suivante a besoin du résultat pour exister, tu n'as rien à faire en parallèle, et l'arrière-plan ne t'apporte rien. Il brille quand tu as deux ou trois chantiers indépendants à mener.

Comment activer et vérifier le mode arrière-plan sur vos serveurs MCP ?

Il n'y a pas d'interrupteur unique : tout dépend de la version de Claude Code et de la façon dont ton serveur déclare ses outils. La marche à suivre tient en cinq gestes, du plus simple au plus fin.

1. Mets Claude Code à jour (v2.1.304 minimum pour les MCP tasks).
2. Liste tes serveurs avec claude mcp list pour vérifier qu'ils sont bien connectés.
3. Choisis un outil que tu sais lent et lance-le depuis une session interactive.
4. Attends 2 minutes et observe : la session doit se libérer et le compteur « MCP task » apparaître.
5. Retrouve le résultat dans la notification, ou dans /tasks.

Les réglages passent par des variables d'environnement. Voici les trois utiles, à confronter à la documentation courante :

# Faire attendre Claude sur TOUS les appels MCP (défaut : 120000)
export CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=0

# Faire attendre le résultat dans l'appel quand le serveur exécute une tâche MCP
export CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND=1

# Couper la mise en arrière-plan automatique et les commandes en arrière-plan
export CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1

Si l'outil continue de bloquer, vérifie d'abord ces causes, qui expliquent l'essentiel des cas. Le serveur ne gère pas les tâches (c'est à lui de les implémenter, tous ne le font pas). Tu es dans un contexte exclu : sous-agent, extension VS Code, app desktop, ou un claude -p one-shot. Ta session ne récupère pas les feature flags (Bedrock ou autre fournisseur tiers, télémétrie désactivée). Côté délais, timeout se règle par serveur dans .mcp.json, et un délai d'inactivité de 5 minutes (HTTP, SSE) ou 30 minutes (stdio) coupe un appel sans progression. Si tu pilotes aussi Claude par programme, l'API Anthropic a sa propre logique, distincte de ce mécanisme du CLI.

Comment concevoir un outil MCP long pour qu'il se comporte bien en arrière-plan ?

Un bon outil long renvoie vite un accusé de réception, expose une progression lisible, et finit par un résultat compact. Le protocole prévoit les notifications de progression et l'annulation des requêtes, décrites sur le site officiel du Model Context Protocol. Trois principes suffisent pour démarrer.

Le premier : annonce tôt que le travail est accepté, puis signale l'avancement par paliers lisibles (« 30 % des fichiers traités ») plutôt qu'un silence de quatre minutes. Le deuxième : borne le résultat. Écris le détail dans un fichier et ne renvoie que le chemin et une synthèse, car un résultat volumineux déversé dans le contexte consomme la place de la session et dégrade la suite du travail. C'est l'effet de bord le moins visible, et le plus coûteux. Le troisième : gère l'annulation et les erreurs proprement, avec des messages explicites, parce qu'un échec silencieux passe inaperçu quand tu es concentré ailleurs.

Voici un squelette minimal en Python, illustratif, qui simule un traitement long et écrit son résultat dans un fichier :

import asyncio, json, pathlib
from mcp.server.fastmcp import FastMCP, Context

mcp = FastMCP("export-demo")

@mcp.tool()
async def export_ventes(ctx: Context, periode: str) -> str:
    """Exporte les ventes de la période (traitement long)."""
    total = 8
    for i in range(total):
        await asyncio.sleep(30)  # simule ~4 minutes de travail
        await ctx.report_progress(i + 1, total)
    chemin = pathlib.Path(f"/tmp/ventes-{periode}.json")
    chemin.write_text(json.dumps({"periode": periode, "lignes": 12480}))
    return f"Export terminé : {chemin} (12480 lignes, détail dans le fichier)"

if __name__ == "__main__":
    mcp.run()

Ce serveur reste un serveur ordinaire : pour qu'un appel devienne une vraie MCP task, il faut que le serveur implémente l'extension de tâches du protocole, ce que ce squelette ne fait pas à lui seul. Il montre en revanche les bons réflexes (progression, résultat compact). Pour aller plus loin sur la construction d'un serveur, lis aussi créer un serveur MCP pour Claude.

Quelles limites et quels pièges garder en tête avant de tout passer en tâche de fond ?

L'arrière-plan n'est pas la bonne réponse quand l'outil produit des effets que tu veux superviser. Garde cette règle de prudence : ce qui est irréversible ou coûteux reste sous validation humaine.

Quelques cas qui méritent la méfiance. Un outil qui écrit en base, envoie des e-mails ou déclenche un paiement ne doit pas tourner sans que tu le voies. Un outil lancé sans surveillance garde ses droits : relis ses permissions avant de le laisser seul. Un outil qui appelle des API facturées à l'usage peut faire grimper la note pendant que tu travailles sur autre chose. Et si deux étapes dépendent l'une de l'autre, les lancer en parallèle n'a aucun sens.

Il y a aussi des angles morts techniques à connaître. La mise en arrière-plan automatique ne s'applique ni aux appels de sous-agents, ni aux serveurs IDE, ni aux exécutions non interactives (sauf CLAUDE_AUTO_BACKGROUND_TASKS=1), ni à un appel qui attend une boîte de dialogue d'élicitation. Les MCP tasks ne sont pas disponibles dans l'extension VS Code ni dans l'app desktop. Côté reprise, après avoir quitté, les tâches de serveurs distants continuent, et claude --resume ou --continue peuvent les suivre à nouveau si le serveur les connaît encore et que son nom et ses réglages de connexion n'ont pas changé. Une nouvelle session ou --fork-session ne les suit pas. Enfin, aucune promesse de gain de temps chiffré n'est tenable : tout dépend de tes outils.

Pour borner ce que Claude peut écrire pendant qu'il travaille en autonomie, un réglage complémentaire existe : voir bloquer les écritures hors du projet.

Comment intégrer ça dans un workflow d'agent autonome pour un dirigeant ?

L'arrière-plan transforme Claude Code en orchestrateur : il lance plusieurs traitements lents, continue à travailler pendant l'attente, puis intègre les résultats à leur arrivée. C'est exactement la logique d'un agent, que le pilier construire des agents IA autonomes avec Claude développe en détail.

Voici un scénario de bout en bout, aux durées purement illustratives. Un lundi, tu demandes à Claude Code deux choses indépendantes : un audit technique de ton site (environ 5 minutes) et un export CRM des opportunités du trimestre (environ 3 minutes). Les deux appels MCP passent en tâche de fond. Pendant l'attente, tu lui fais rédiger la trame de ta note de synthèse. L'export finit en premier : Claude te le notifie et commence à croiser les chiffres. L'audit arrive ensuite, et il complète la note avec les points à corriger. Résultat : trois chantiers avancent dans la même session, au lieu de trois attentes l'une derrière l'autre.

Pour que ça tienne dans la durée, applique trois garde-fous : des outils à résultat borné, une validation humaine avant toute action sensible, et un suivi régulier de /tasks. Si tu veux passer de ces essais à des agents réellement pilotés au quotidien, ce parcours est celui de Piloter vos agents autonomes.

Questions fréquentes

Passer à la pratique

Commence petit : mets Claude Code à jour, repère l'outil le plus lent de tes serveurs MCP, et fais le test des deux minutes décrit plus haut. Les nouveautés de version sont annoncées sur le site d'Anthropic et dans le changelog de Claude Code. Quand tu seras à l'aise avec une tâche de fond, enchaîne sur un vrai workflow multi-outils, et si tu veux le faire avec un cadre et des projets concrets, c'est là que Piloter vos agents autonomes prend le relais.