En 2024-2025, deux protocoles ont émergé pour standardiser ce que chaque équipe réinventait : comment connecter un agent à ses outils, comment faire communiquer des agents de fournisseurs différents. Si vous construisez des agents IA, comprendre MCP et A2A n'est plus optionnel.
MCP — Model Context Protocol
MCP est un protocole open-source publié par Anthropic en novembre 2024. Son objectif : standardiser la façon dont les LLMs accèdent aux outils et aux données.
Le problème qu'il résout :
Avant MCP, connecter un agent à une source de données (base SQL, API REST, fichier, service métier) nécessitait d'écrire un connecteur spécifique pour chaque combinaison agent × source. N agents × M sources = N×M connecteurs à maintenir.
Avec MCP : N agents + M serveurs MCP = N+M composants. Chaque outil est exposé une fois, consommé par n'importe quel client compatible.
L'architecture :
flowchart TB
Agent["🤖 Agent — MCP Client\nClaude / GPT / votre agent .NET"]
Agent -->|MCP Protocol| S1["🗄️ MCP Server\nSQL DB"]
Agent -->|MCP Protocol| S2["🕸️ MCP Server\nGraphDB"]
Agent -->|MCP Protocol| S3["📡 MCP Server\nPricing API"]
style Agent fill:#2A3E6F,stroke:#4A90D9,color:#E8F0FA
style S1 fill:#1A2744,stroke:#4A6FA0,color:#B8CCE4
style S2 fill:#1A2744,stroke:#4A6FA0,color:#B8CCE4
style S3 fill:#1A2744,stroke:#4A6FA0,color:#B8CCE4
Un serveur MCP minimal en Python :
from mcp.server import Server
from mcp.server.models import InitializationOptions
import mcp.types as types
app = Server("mon-serveur-metier")
@app.list_tools()
async def list_tools() -> list[types.Tool]:
return [
types.Tool(
name="search_contracts",
description="Recherche dans la base de contrats",
inputSchema={
"type": "object",
"properties": {
"query": {"type": "string"},
"client_id": {"type": "string"},
"date_from": {"type": "string", "format": "date"}
},
"required": ["query"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[types.TextContent]:
if name == "search_contracts":
results = await db.search_contracts(
query=arguments["query"],
client_id=arguments.get("client_id"),
date_from=arguments.get("date_from")
)
return [types.TextContent(
type="text",
text=format_results(results)
)]
raise ValueError(f"Outil inconnu : {name}")
Ce serveur est maintenant accessible à n'importe quel agent compatible MCP — Claude, GPT-4, votre propre agent .NET — sans modifier une ligne de code.
A2A — Agent-to-Agent Protocol
MCP résout la connexion agent ↔ outil. A2A résout la connexion agent ↔ agent.
Publié par Google en avril 2025, A2A standardise comment des agents de systèmes différents se découvrent, se délèguent des tâches, et communiquent leurs résultats.
Le problème qu'il résout :
Un agent Claude ne sait pas "parler" à un agent GPT ou à un agent custom .NET. Chaque plateforme a ses propres conventions de communication. Sans standard, l'interopérabilité est impossible.
Les quatre concepts clés d'A2A :
1. Agent Card — La carte d'identité de l'agent, exposée via HTTP :
{
"name": "ElectricalEngineerAgent",
"description": "Spécialiste dimensionnement électrique",
"version": "1.2.0",
"capabilities": {
"streaming": true,
"pushNotifications": false
},
"skills": [
{
"id": "cable-sizing",
"name": "Dimensionnement de câble",
"description": "Calcule la section de câble selon IEC 60364",
"inputModes": ["text", "json"],
"outputModes": ["json"]
}
],
"url": "https://agents.mirakai.dev/electrical"
}
2. Task — L'unité de travail déléguée :
{
"id": "task-456",
"message": {
"role": "user",
"parts": [{
"type": "text",
"text": "Dimensionne le câble pour ce circuit : 63A, 25m, méthode B"
}]
}
}
3. Artifact — Le résultat produit par l'agent :
{
"name": "dimensionnement-cable",
"parts": [{
"type": "json",
"data": {
"section_mm2": 16,
"norme": "IEC 60364-5-52",
"methode": "B2",
"chute_tension_pct": 2.1
}
}]
}
4. Discovery — Les agents se trouvent et se délèguent dynamiquement, sans configuration statique.
MCP + A2A ensemble : l'architecture cible
flowchart TB
Orch["🎯 Orchestrateur Principal\ndécouvre et délègue via A2A"]
Orch -->|A2A| AE["⚡ Agent Élec"]
Orch -->|A2A| AF["💧 Agent Fluides"]
Orch -->|A2A| AM["⚙️ Agent Méca"]
AE -->|MCP| T1["Solveur électrique"]
AF -->|MCP| T2["OpenFOAM wrapper"]
AM -->|MCP| T3["Code Aster wrapper"]
style Orch fill:#3A4E7F,stroke:#E8C84A,color:#E8F0FA
style AE fill:#2A3E6F,stroke:#4A90D9,color:#E8F0FA
style AF fill:#2A3E6F,stroke:#4A90D9,color:#E8F0FA
style AM fill:#2A3E6F,stroke:#4A90D9,color:#E8F0FA
style T1 fill:#1A2744,stroke:#4A6FA0,color:#B8CCE4
style T2 fill:#1A2744,stroke:#4A6FA0,color:#B8CCE4
style T3 fill:#1A2744,stroke:#4A6FA0,color:#B8CCE4
- MCP connecte chaque agent à ses outils métier (solveurs, bases de données, APIs)
- A2A connecte les agents entre eux et avec l'orchestrateur
Les deux protocoles sont complémentaires. L'un sans l'autre ne couvre qu'une moitié du problème.
Pourquoi c'est structurant maintenant
Deux raisons concrètes :
1. L'écosystème converge rapidement. Les principaux fournisseurs (Anthropic, Google, Microsoft, OpenAI) soutiennent ou implémentent ces protocoles. Dans 18 mois, un projet qui ne les utilise pas sera en dette technique.
2. L'interopérabilité devient un actif. Un agent MCP-compatible peut être branché sur n'importe quel futur système compatible. Vous ne réécrivez pas vos connecteurs à chaque changement de fournisseur.
Si vous concevez une architecture d'agents aujourd'hui, intégrez MCP et A2A dès le départ. Les ajouter après coup est toujours possible — mais douloureux.
Olivier Alessandri — Architecte IA & .NET · Mirakai