MCP et A2A : les deux protocoles qui structurent l'architecture multi-agent

Votre agent fonctionne : il raisonne, appelle des outils et retourne des résultats, avec une tâche et un contexte.

Mettez-en maintenant cinq ensemble. L'un trie les tickets de support. Un autre interroge votre base de données. Un troisième rédige une réponse. Ils doivent se découvrir, échanger des données structurées et se coordonner sans qu'un humain route chaque message.

Le modèle à agent unique casse à ce stade. Deux protocoles prennent le relais : MCP connecte les agents aux outils, A2A les connecte entre eux. Ensemble, ils forment le socle des systèmes multi-agent en 2026.

Le problème de l'agent qui fait tout

Un agent monolithique qui gère toutes les tâches semble séduisant, mais il atteint ses limites vite.

La fenêtre de contexte se remplit de descriptions d'outils inutiles. Les permissions deviennent impossibles à délimiter. Un changement de prompt pour un cas d'usage en casse un autre. Le debug tourne à la devinette parce que tout tourne dans la même boucle.

Les applications monolithiques ont rencontré les mêmes contraintes il y a dix ans. La réponse a été les microservices : des services spécialisés, de petite taille, qui communiquent via des interfaces bien définies.

Les systèmes multi-agent suivent la même trajectoire, avec des agents spécialisés, des frontières claires et une communication standardisée. Les microservices disposaient de HTTP, REST et gRPC. Les agents ont maintenant leurs propres protocoles.

MCP : la couche outils

Le Model Context Protocol est un standard ouvert, créé à l'origine par Anthropic et désormais gouverné par la Linux Foundation. Il définit comment un agent IA se connecte à des outils externes, des sources de données et des API.

Pensez à MCP comme l'axe vertical de votre architecture. Un agent descend pour interagir avec le monde extérieur : bases de données, systèmes de fichiers, services tiers. Avant MCP, chaque intégration était du code custom. Avec MCP, vous écrivez un serveur une fois et n'importe quel client compatible peut l'utiliser.

Comment ça fonctionne

Un serveur MCP expose trois types de capacités :

• Tools : des fonctions que l'agent peut appeler (interroger une base de données, envoyer un email, créer une issue GitHub)
• Resources : des données que l'agent peut lire (fichiers, documents, configuration)
• Prompts : des templates de prompts réutilisables que le serveur met à disposition des clients

Le client découvre ces capacités via un handshake, puis les appelle en JSON-RPC. Le serveur peut tourner en local (transport stdio) ou à distance (transport Streamable HTTP).

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "inventory-server",
  version: "1.0.0",
});

server.tool(
  "checkStock",
  { productId: z.string(), warehouse: z.string() },
  async ({ productId, warehouse }) => {
    const stock = await db.inventory.check(productId, warehouse);
    return {
      content: [
        { type: "text", text: JSON.stringify(stock) },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

L'évolution du transport

La couche transport de MCP a connu trois générations :

Streamable HTTP est désormais le transport recommandé pour les serveurs distants. Un seul endpoint HTTP gère les requêtes et le streaming optionnel. Il fonctionne derrière un load balancer, scale horizontalement et supporte les déploiements stateless. Le transport stdio reste pertinent pour les outils locaux et les intégrations CLI.

Adoption et écosystème

Les chiffres début 2026 :

• 97 millions de téléchargements mensuels du SDK (Python + TypeScript combinés)
• Plus de 17 000 serveurs MCP indexés
• Supporté par Claude, ChatGPT, Gemini, Cursor, VS Code, les IDE JetBrains
• Serveurs officiels pour GitHub, Slack, Notion, Jira, PostgreSQL, Stripe, AWS

Si vous construisez un outil auquel des agents doivent accéder, exposez-le via MCP.

Ce que MCP ne résout pas

MCP gère la communication agent-vers-outil. Il ne dit rien sur la façon dont les agents communiquent entre eux. Un serveur MCP ne sait pas quel agent l'appelle ni si cet agent a été délégué par un autre agent. Il n'y a pas de cycle de vie de tâche, pas de découverte de capacités entre agents, pas de passation structurée. Le second protocole couvre ce manque.

A2A : la couche collaboration

Le protocole Agent-to-Agent a été créé par Google en avril 2025 et se trouve désormais sous la Linux Foundation. Il définit comment les agents se découvrent, échangent des messages et coordonnent des tâches.

Si MCP est l'axe vertical (l'agent descend vers les outils), A2A est l'axe horizontal (l'agent communique avec ses pairs). Les deux protocoles opèrent sur des plans différents et se complètent.

Agent Cards : le service discovery des agents

Chaque agent compatible A2A publie une Agent Card à une URL standardisée (/.well-known/agent-card.json). Ce document JSON décrit ce que l'agent sait faire, comment s'authentifier et quels formats d'entrée/sortie il supporte.

{
  "name": "Inventory Agent",
  "description": "Manages stock levels and warehouse operations",
  "version": "1.0.0",
  "url": "https://inventory.internal.company.com",
  "skills": [
    {
      "id": "check-availability",
      "name": "Check Product Availability",
      "description": "Returns real-time stock levels across warehouses",
      "tags": ["inventory", "stock", "warehouse"]
    },
    {
      "id": "reorder",
      "name": "Trigger Reorder",
      "description": "Places a reorder when stock drops below threshold",
      "tags": ["inventory", "procurement"]
    }
  ],
  "defaultInputModes": ["text", "data"],
  "defaultOutputModes": ["text", "data"],
  "authentication": {
    "schemes": ["oauth2"]
  }
}

Un agent orchestrateur peut récupérer les Agent Cards, matcher les skills à la tâche en cours et router le travail en conséquence. Aucun routage en dur et aucun fichier de configuration central ne liste les agents : la découverte est décentralisée, comme un DNS pour agents.

Cycle de vie des tâches

A2A structure la communication autour de tâches. Un agent client envoie un message, l'agent serveur crée une tâche et met à jour son état au fil du traitement :

WORKING → INPUT_REQUIRED → WORKING → COMPLETED

Ou : WORKING → FAILED

Ou : WORKING → CANCELED (initié par le client)

Cette machine à états donne à l'agent appelant une visibilité sur la progression. Il peut attendre la complétion, fournir des informations supplémentaires quand c'est demandé, ou annuler une tâche qui prend trop de temps. Comparez ça à un appel HTTP brut où vous obtenez une réponse ou un timeout, sans rien entre les deux.

Une implémentation TypeScript

import {
  AgentCard,
  AgentExecutor,
  ExecutionEventBus,
  RequestContext,
} from "@a2a-js/sdk";

const agentCard: AgentCard = {
  name: "Code Review Agent",
  description:
    "Reviews pull requests for security and performance issues",
  protocolVersion: "0.3.0",
  version: "1.0.0",
  url: "https://review-agent.internal.company.com",
  skills: [
    {
      id: "review-pr",
      name: "Review Pull Request",
      description:
        "Analyzes a PR diff for security vulnerabilities, performance regressions and code style",
    },
  ],
  defaultInputModes: ["text"],
  defaultOutputModes: ["text"],
};

class CodeReviewExecutor implements AgentExecutor {
  async execute(
    context: RequestContext,
    eventBus: ExecutionEventBus
  ) {
    const message = context.message;
    const prUrl = extractPrUrl(message);

    eventBus.publish({
      state: "WORKING",
      message: "Fetching PR diff...",
    });

    const diff = await fetchPrDiff(prUrl);
    const review = await analyzeWithLlm(diff);

    eventBus.publish({
      state: "COMPLETED",
      artifacts: [{ type: "text", text: review }],
    });
  }
}

L'agent appelant envoie un message avec l'URL de la PR. L'agent de review accuse réception, analyse le diff et retourne un résultat structuré. L'appelant connaît l'état de la tâche à chaque étape.

Comment les deux protocoles s'emboîtent

L'architecture émergente a trois couches :

Voici à quoi ressemble un système concret :

Requete utilisateur : "Analyse les tickets support de la semaine et rédige un rapport"
       │
       ▼
┌─────────────────────┐
│  Agent Orchestrateur │ ← recoit la tache
│  (client A2A)        │
└───────┬─────────┬───┘
        │ A2A     │ A2A
        ▼         ▼
┌──────────┐ ┌──────────┐
│  Agent   │ │  Agent   │
│  Analyse │ │  Redac-  │
│  Tickets │ │  tion    │
└────┬─────┘ └────┬─────┘
     │ MCP        │ MCP
     ▼            ▼
┌──────────┐ ┌──────────┐
│  Zendesk │ │  Google  │
│  Server  │ │  Docs    │
│  (MCP)   │ │  Server  │
└──────────┘ └──────────┘

L'orchestrateur découvre les agents spécialisés via leurs Agent Cards. Il délègue l'analyse des tickets à l'un et la rédaction du rapport à l'autre, via A2A. Chaque agent spécialisé se connecte à ses outils via MCP. L'orchestrateur n'a jamais besoin de connaître Zendesk ou Google Docs. Il a juste besoin de savoir quels agents ont les bonnes compétences.

Le modèle mental de l'équipe d'ingénierie de Cisco résume bien la situation : MCP est la couche 2 (visibilité directe, accès local) et A2A est la couche 3 (frontière de routage, agrégation de capacités). Si vous avez déjà construit des systèmes distribués, ça se mappe directement sur des concepts que vous connaissez.

Frameworks qui supportent les deux protocoles

L'écosystème TypeScript est déjà en mouvement.

Mastra est le plus avancé. Il supporte le MCP server authoring (exposer des agents et outils via MCP), la consommation de serveurs MCP externes et le support natif du protocole A2A pour la communication inter-agents. L'article sur Mastra 1.0 présente le framework en détail.

LangChain supporte les endpoints A2A via son Agent Server et l'intégration d'outils MCP, principalement en Python.

Google ADK fournit des quickstarts natifs A2A pour exposer des agents, avec le support MCP intégré.

Le pattern est le même partout : MCP pour l'intégration descendante avec les outils, A2A pour l'intégration latérale avec les agents pairs. Pour la mise en pratique dans un projet existant, voir le guide de conception d'un module agentique.

Considérations de production

Déployer un système multi-agent avec les deux protocoles introduit des contraintes spécifiques.

Sécurité

Les serveurs MCP sont souvent de fins wrappers autour de bases de données, d'API ou d'interpréteurs de code. Un serveur mal configuré est une surface d'attaque directe. Appliquez le moindre privilège : chaque agent ne doit accéder qu'aux serveurs MCP strictement nécessaires à sa tâche. Validez les paramètres des appels d'outils côté serveur. Utilisez OAuth 2.1 pour les connexions MCP distantes.

A2A ajoute une autre dimension. Les Agent Cards déclarent des exigences d'authentification, mais le protocole ne les impose pas. Les signatures numériques (JWS) pour les Agent Cards sont optionnelles. En production, vérifiez l'authenticité des Agent Cards avant de router des tâches vers des agents inconnus.

Observabilité

Les outils de monitoring traditionnels n'ont pas été conçus pour les architectures agentiques. Quand un orchestrateur délègue à trois agents, chacun appelant plusieurs outils MCP, une seule requête utilisateur peut traverser des dizaines d'opérations réparties sur plusieurs services.

Il faut du tracing distribué qui suit la chaîne complète : requête utilisateur → orchestrateur → délégation A2A → traitement agent → appels outils MCP → résultats. Sans ça, débugger une panne dans un pipeline multi-agent relève de la devinette.

33% des organisations n'ont actuellement aucune piste d'audit pour l'activité de leurs agents IA. C'est le premier écart à combler.

Les trous du côté enterprise

Les deux protocoles sont prêts pour la production sur leur spécification de base. La couche enterprise mûrit encore :

• MCP : l'intégration SSO remplace les secrets clients statiques. Les patterns de gateway pour l'application centralisée de politiques émergent mais ne sont pas standardisés. La portabilité de configuration entre environnements reste manuelle.
• A2A : les registres d'Agent Cards pour la découverte à l'échelle enterprise en sont aux prémices. L'allocation des coûts dans les workflows multi-agent n'est pas définie. La responsabilité dans les décisions d'agents chaînés est une question juridique ouverte.

Ces lacunes ne bloquent pas l'adoption, mais elles orientent par où commencer. Démarrez avec des agents internes derrière votre pare-feu, là où la confiance et les frontières réseau sont bien définies. La communication externe agent-vers-agent peut venir après, quand l'outillage de gouvernance aura rattrapé son retard.

Le parallèle avec les microservices

Chaque changement d'architecture dans notre industrie suit le même arc. Les monolithes deviennent inconfortables. Quelqu'un propose la décomposition. Des standards émergent pour la communication entre les morceaux. L'outillage mûrit. L'industrie se consolide autour de quelques patterns.

On est passés par là avec les services web (SOAP, puis REST, puis gRPC). On est passés par là avec les microservices (service meshes, API gateways, tracing distribué). On y passe maintenant avec les agents IA.

MCP est l'équivalent d'un driver de base de données ou d'un client API. A2A est l'équivalent de gRPC entre microservices. Les Agent Cards sont le service discovery. Les concepts se mappent directement.

Si vous avez déjà construit des systèmes distribués, vous avez déjà les modèles mentaux : les protocoles sont récents, l'architecture est la même. Un point de vigilance : décomposer n'implique pas de répartir les écritures, voir pourquoi un seul agent doit écrire.

MCP compte déjà 97 millions de téléchargements mensuels et 17 000 serveurs. A2A est soutenu par Google, Microsoft, AWS et Salesforce. Les équipes qui maîtrisent tôt l'architecture multi-agent sauront décomposer les problèmes en agents spécialisés, les connecter via des protocoles standards et les opérer en production.

Commencez par un serveur MCP pour un outil que vos agents utilisent déjà. Ajoutez un second agent avec une Agent Card. Faites-les collaborer. C'est le point de départ que je retiens sur une prestation d'agents et enchaînements pilotés par des modèles de langage quand le produit a besoin de plusieurs agents dès le premier jour.