Protocoles d'agents IA : MCP, A2A, ACP et AG-UI

Réponse rapide

MCP, A2A, ACP et AG-UI ne se remplacent pas directement. Ils standardisent des frontières différentes dans un système d'agents.

Protocole	Problème principal	Frontière typique
MCP	Connecter une app IA à des outils, données, prompts et contexte	Agent/host vers serveur d'outils ou ressources
A2A	Déléguer du travail d'un agent à un autre	Tâches agent à agent
ACP	Exposer des agents comme services interopérables	Interopérabilité de services agents
AG-UI	Streamer état et actions vers une interface	Backend agent vers frontend

En production, la bonne question n'est pas "qui gagne ?", mais "quelle frontière voulons-nous standardiser ?".

Pourquoi c'est important

Les premiers systèmes d'agents codent souvent les appels outils, événements UI et délégations dans une seule app. Cela suffit pour un prototype, mais devient fragile avec plusieurs équipes, outils, fournisseurs et interfaces.

Les protocoles séparent les responsabilités :

Outils et sources de données peuvent être exposés sans réécrire l'agent.
Les agents délèguent sans exposer leurs détails internes.
Les frontends affichent progrès, appels outils et états intermédiaires de façon cohérente.
Les équipes sécurité raisonnent sur des frontières claires.

La clé est d'associer le protocole à la bonne frontière.

MCP : outils et contexte

MCP, Model Context Protocol, connecte les applications IA à des outils et contextes externes. Un host peut découvrir et appeler des outils, lire des ressources et utiliser des templates de prompt.

Utilisez MCP lorsque :

Une app IA doit interroger base de données, filesystem, API, repo ou outil interne.
Les outils doivent être réutilisables par plusieurs clients.
Ressources et prompts doivent être exposés proprement.
Les schémas et permissions doivent être explicites.

MCP est fort sur la frontière "agent appelle outil". Ce n'est pas un protocole complet d'orchestration multi-agents et il ne définit pas l'UI.

AI app / agent host
  -> MCP client
  -> MCP server
  -> database, file system, API, internal tool

Bonnes pratiques :

Outils étroits et bien décrits.
Éviter les écritures larges.
Logger appels et arguments.
Traiter les sorties comme non fiables.
Versionner les schémas.

A2A : collaboration agent à agent

A2A, Agent-to-Agent, traite la collaboration entre agents. Un agent peut annoncer ses capacités et accepter des tâches d'un autre agent ou orchestrateur.

Utilisez A2A lorsque :

Plusieurs agents spécialisés collaborent.
Un planner délègue à des spécialistes.
Les agents appartiennent à différents services ou équipes.
Les tâches longues ont besoin de statut, artefacts et progrès.

A2A est fort sur la frontière "un agent délègue à un agent". Il ne remplace pas MCP ; un agent A2A peut utiliser MCP en interne.

Orchestrator agent
  -> A2A task request
  -> Specialist agent
  -> status updates and artifacts

Bonnes pratiques :

Définir ce que chaque agent peut faire.
Valider les réponses.
Utiliser timeouts et budgets.
Enregistrer ownership et handoffs.
Éviter les boucles de délégation.

ACP : services agents interopérables

ACP, souvent présenté comme Agent Communication Protocol, vise à rendre les agents découvrables et interopérables comme services. Les implémentations diffèrent, mais l'objectif est d'exposer des capacités de façon prévisible.

Utilisez des approches ACP lorsque :

Les agents doivent se comporter comme services réseau.
La découverte de capacités compte.
Différents runtimes ou fournisseurs doivent interopérer.
Une frontière service est préférable à un appel bibliothèque.

ACP chevauche parfois A2A. Évaluez l'implémentation concrète : format, authentification, cycle de vie, streaming, SDK et gouvernance.

AG-UI : agent vers interface utilisateur

AG-UI concerne la frontière frontend. Il standardise comment un backend agent stream messages, appels outils, changements d'état, progrès et événements utiles à l'UI.

Utilisez AG-UI lorsque :

Vous construisez une UI de copilot ou assistant.
Le frontend doit afficher tool calls, étapes ou progrès.
Les utilisateurs doivent approuver des actions.
L'état agent doit se synchroniser avec React, Vue ou autre framework.

AG-UI est fort sur "backend agent vers UI". Il ne définit ni workflow interne ni hébergement des outils.

Agent backend
  -> event stream
  -> frontend UI
  -> user approval / input
  -> backend resumes

Bonnes pratiques :

Stabiliser les types d'événements.
Séparer état visible et secrets internes.
Gérer reconnexions et streams partiels.
Rendre les approbations explicites et auditables.
Ne jamais laisser l'UI contourner les permissions serveur.

Comment ils s'assemblent

Ils sont souvent complémentaires :

User interface
  <-> AG-UI events
Agent application / orchestrator
  <-> A2A or ACP for agent collaboration
Specialist agent
  <-> MCP for tools, resources, and prompts
Business systems

Un système support peut utiliser AG-UI pour le progrès, A2A pour déléguer à un agent finance, et MCP pour les outils de commandes, paiement et tickets.

Comparaison

Dimension	MCP	A2A	ACP	AG-UI
Frontière	Agent vers outils/contexte	Agent vers agent	Service agent	Agent vers UI
Objet	Tool, resource, prompt	Task, message, artifact	Capability, agent, message	Event, state, action
Idéal pour	Intégration outils	Délégation	Interopérabilité	Frontends interactifs
Remplace la logique app ?	Non	Non	Non	Non
Combinable ?	Oui	Oui	Oui	Oui
Risque	Outils trop puissants	Délégation sans limites	Implémentations divergentes	Fuite d'état ou sécurité

Guide de décision

Choisissez MCP si le problème principal est la connexion à des outils ou données.

Choisissez A2A si un agent doit déléguer des tâches.

Choisissez ACP si des agents doivent être exposés comme services avec découverte de capacités.

Choisissez AG-UI si vous construisez une UI interactive avec progrès, approbations et états intermédiaires.

Erreurs fréquentes

Traiter les protocoles comme frameworks

Les protocoles définissent des frontières de communication. Ils ne remplacent pas orchestration, évaluation, sécurité, déploiement ou produit.

Utiliser le multi-agent pour de simples outils

Si l'agent interroge seulement une base ou une API, MCP peut suffire. N'ajoutez pas de délégation sans besoin.

Exposer trop de pouvoir

Un serveur d'outils doit proposer des opérations étroites. "Exécuter SQL arbitraire" ou "exécuter shell" exige un environnement très contrôlé.

Faire confiance sans validation

La communication agent à agent demande validation. Les artefacts retournés sont des données à vérifier.

Transformer les événements UI en permissions

L'approbation frontend est un signal utilisateur, pas un contrôle de sécurité complet. Le backend doit appliquer les permissions.

Checklist production

Zone	Questions
Authentification	Qui peut appeler l'endpoint ?
Autorisation	Quels outils, agents, tâches ou actions UI sont permis ?
Audit	Peut-on reconstruire qui a demandé quoi ?
Timeouts	Que se passe-t-il si un outil ou agent bloque ?
Budgets	Les appels modèle, outils et profondeur sont-ils bornés ?
Validation	Inputs et outputs sont-ils contrôlés par schéma ?
Observabilité	Les traces lient-elles UI, agent, outil et tâche ?
Versioning	Peut-on changer les schémas sans casser les clients ?

Résumé

MCP, A2A, ACP et AG-UI sont des protocoles de frontière. MCP standardise outils et contexte, A2A la collaboration entre agents, ACP les services agents interopérables et AG-UI les événements frontend. Un système mature peut en combiner plusieurs, mais seulement là où chacun rend la frontière plus claire et plus sûre.