MCP a changé de forme, pas seulement de numéro de version

La révision 2026-07-28 du Model Context Protocol est passée sous le radar de beaucoup d'équipes françaises, et c'est dommage : c'est la modification la plus profonde depuis l'ajout de l'autorisation. Le cœur du protocole devient sans état. Chaque requête transporte désormais tout ce dont le serveur a besoin, au lieu de dépendre d'une connexion maintenue ouverte. S'y ajoutent le routage par en-têtes, les requêtes multi-allers-retours, les résultats de listes cachables et un cadre formel d'extensions. Concrètement : vous pouvez enfin répartir vos serveurs MCP derrière un load balancer banal, sans stockage partagé ni sessions collantes. Pour qui fait tourner une flotte d'agents, ce détail d'architecture vaut plus que n'importe quelle démo d'agent autonome.

L'identité d'agent : le vrai point de blocage du multi-agents

La feuille de route publiée le 22 août 2026 met le doigt sur ce qui casse réellement en production. De plus en plus d'appelants ne sont plus des humains derrière un client : ce sont des agents qui tournent comme des charges de travail cloud, avec leur propre identité, agissant pour un utilisateur absent, et déléguant une autorité plus étroite à des sous-agents. Or aujourd'hui, dans la plupart des stacks que je croise, tout le monde partage le même jeton OAuth ou le même PAT. Un sous-agent chargé de résumer des tickets hérite mécaniquement du droit de supprimer une base. Le chantier MCP couvre la finalisation de DPoP, la Workload Identity Federation, l'octroi ID-JAG derrière l'Enterprise-Managed Authorization et l'échange de jetons standard.

En attendant que les SDK suivent, voici ce qui se met en place sans attendre la spec :

  • Un credential distinct par agent dans n8n, jamais un credential maître partagé entre le superviseur et ses sous-agents.
  • Des scopes taillés au plus juste : lecture seule par défaut, écriture accordée outil par outil.
  • Un serveur MCP intermédiaire qui joue le rôle de proxy et refuse les appels hors périmètre, plutôt que de compter sur le prompt système pour discipliner l'agent.
  • Une journalisation de l'agent appelant sur chaque tool call, et pas seulement de l'utilisateur final : sans ça, l'audit post-incident est impossible.
  • Une rotation de jetons réellement testée, puisque les en-têtes personnalisés des remotes MCP survivent désormais au refresh OAuth côté n8n.

Tâches asynchrones : sortir du modèle requête/réponse

Deuxième priorité de la roadmap, et la plus structurante pour l'automatisation : les charges agentiques ont besoin de motifs de messagerie qui dépassent le simple aller-retour. Du travail qui dure des minutes, des serveurs qui poussent des événements, des résultats qui arrivent en flux, et surtout la possibilité de réorienter une exécution en cours. MCP consolide pour cela les Tasks, les souscriptions et les notifications de progression. Le signal marché va dans le même sens : Salesforce a placé son agent Hunter sur un runtime dit long-horizon, censé poursuivre un objectif sur plusieurs semaines plutôt que sur une session de chat. On peut sourire du packaging, l'unité de temps change vraiment.

Aujourd'hui, dans n8n ou Make, on simule tout cela à la main : un nœud Wait, un polling de webhook, un état stocké dans Redis ou Postgres, une reprise bricolée quand l'exécution meurt. Cette plomberie devient du protocole. Si vous démarrez une orchestration multi-agents ce trimestre, concevez-la d'emblée en asynchrone : déclencheur, file, état externalisé, idempotence sur chaque outil. Vous éviterez la réécriture intégrale quand les Tasks atterriront dans les SDK.

Ce que les mises à jour n8n de septembre rendent possible

Côté outillage, n8n a activé le module instance-ai par défaut, exposé l'exécution de test d'un agent via MCP, ouvert la recherche dans le registre MCP comme outil pour l'assistant, étendu n8n Connect aux tools du nœud Agent Builder, et persisté les timelines de session d'agent pendant l'exécution. Ce dernier point est le plus sous-estimé : sans trace persistée, déboguer un agent qui a pris une mauvaise décision au septième tour relève de la divination. Pouvoir déclencher un test d'agent depuis MCP change aussi la méthode de travail, puisqu'un superviseur externe peut piloter une campagne de tests au lieu de cliquer manuellement dans l'éditeur.

La méthode qui tient la route : un orchestrateur mince qui se contente de router et de tenir l'état, des agents spécialisés à trois ou quatre outils maximum, et des évaluations rejouables sur des cas réels gelés. Les architectures à douze agents qui se parlent librement produisent surtout des factures imprévisibles. La recherche récente sur la sécurité des systèmes multi-agents pointe le même angle mort : un orchestrateur mal contraint dissout les garde-fous de chaque agent pris isolément.