Tasks : gérer les traitements longs sans exploser le timeout
L'extension Tasks passe en première classe dans MCP 2026-07-28. Comment gérer un traitement long sans timeout, sans double exécution et sans sortir l'utilisateur du chat.
L'extension Tasks passe en première classe dans la révision MCP 2026-07-28. Elle règle un problème que tous les serveurs qui font autre chose que de la lecture finissent par rencontrer : un appel d'outil qui dure trop longtemps.
Le problème
Un appel d'outil est une requête. Une requête a un timeout, souvent plusieurs, empilés : le client, ton reverse proxy, ton hébergeur, ton runtime.
Dès que ton outil dépasse la trentaine de secondes, tu entres dans une zone où le comportement dépend de la couche qui cède en premier. Le symptôme typique : ça marche en local, ça échoue en production, et l'agent réessaie, ce qui lance une deuxième fois un traitement coûteux qui tournait déjà.
Les cas concernés sont toujours les mêmes : export volumineux, génération de document ou d'image, traitement par lot, récupération depuis un service externe lent, calcul coûteux.
Les rustines qu'on voyait avant
Faire durer la requête. Ça tient jusqu'au premier timeout intermittent, et ça monopolise une connexion.
Renvoyer un lien de suivi. Ça sort l'utilisateur du chat, et c'est exactement ce que MCP était censé éviter.
Renvoyer un identifiant maison et demander à l'agent de repasser. Ça marche, mais chaque serveur invente sa convention, et l'agent doit deviner à quel rythme interroger.
Tasks standardise cette dernière approche.
Ce que ça change
L'opération longue devient un objet de première classe : elle est lancée, elle a un état, on peut la suivre, et son résultat est récupéré quand il est prêt. Le client sait gérer ce cycle sans convention maison.
Les bénéfices concrets pour toi :
- Plus de timeouts aléatoires sur les traitements lourds
- Plus de doubles exécutions causées par des retries d'agent
- Un endroit naturel pour la progression, si tu veux l'exposer
- Un traitement qui survit à la mort d'une instance, si tu l'as construit comme il faut
Ce dernier point est le lien avec le reste de la révision. Une tâche durable est du stockage partagé, pas de l'état de process. C'est exactement ce que la migration stateless demande par ailleurs.
Comment le concevoir
Une tâche est une entité de ton domaine. Elle a une table, un statut, un propriétaire, un horodatage, un résultat, une durée de rétention. Ne la garde pas en mémoire.
Rends le lancement idempotent. Si l'agent relance deux fois la même demande, tu ne veux pas deux exports. Une clé d'idempotence fournie par l'appelant, ou dérivée des paramètres, règle ça.
Vérifie le propriétaire à la lecture. Un identifiant de tâche circule dans une conversation. Il ne doit rien donner à quelqu'un d'autre.
Prévois l'expiration. Résultat conservé combien de temps, purgé comment. Sinon ta table devient une archive involontaire.
Soigne l'état d'échec. Une tâche qui échoue doit dire pourquoi, et dire si ça vaut la peine de réessayer. Une erreur ambiguë transforme un échec en boucle.
Quand ne pas s'en servir
Si ton opération dure deux secondes, un appel synchrone reste plus simple et plus agréable. Tasks ajoute des états à gérer, côté serveur et côté expérience.
La règle pratique : en dessous de dix secondes, synchrone. Au-dessus de trente, tâche. Entre les deux, regarde ta distribution réelle plutôt que ta moyenne, parce que c'est la queue de distribution qui casse.
FAQ
Est-ce que tous les clients gèrent Tasks ?
C'est une extension, elle évolue sur son propre calendrier. Prévois un comportement dégradation raisonnable pour les clients qui ne la gèrent pas.
Est-ce que ça remplace mes webhooks ?
Non. Tasks concerne le cycle de vie d'une opération demandée par un agent. Tes notifications sortantes vers d'autres systèmes restent un sujet distinct.
Et si j'ai déjà une file de traitement ?
Tant mieux, tu as déjà l'essentiel. Il reste à exposer le cycle de vie via l'extension au lieu de ta convention maison.
Faire concevoir tes traitements longs
C'est un des points qu'on regarde en audit, avec le stockage d'état et l'idempotence. La construction complète va de 4 500 à 7 500 € selon le périmètre.
Intéressé ? Parler de mon serveur MCP →
Lectures liées
Un serveur MCP à faire auditer ?
Cinq minutes pour le décrire. Je réponds sous 24 heures ouvrées avec un premier diagnostic écrit et gratuit.
Faire auditer mon serveur MCP