Pourquoi ce sujet est important
Les agents ont besoin d’accéder à des données, d’appeler des outils et parfois de déléguer une tâche à un autre agent. MCP et A2A standardisent des frontières différentes. Les confondre conduit à des architectures trop complexes ou à des droits mal appliqués.
MCP connecte une application à des capacités
Model Context Protocol permet à un client de découvrir et utiliser outils, ressources et prompts exposés par un serveur. Un serveur MCP peut encapsuler une base, une API métier ou un système de fichiers contrôlé. Il ne transforme pas automatiquement cette capacité en agent autonome.
A2A organise une délégation entre agents
Agent2Agent décrit la découverte d’un agent, l’échange de messages, le cycle de tâches et les artefacts. Il convient lorsqu’un système indépendant reçoit un objectif, travaille potentiellement longtemps et retourne un résultat. L’agent distant garde sa propre orchestration.
ACP n’est plus un troisième choix équivalent
L’Agent Communication Protocol du projet BeeAI a rejoint l’effort A2A. Pour une nouvelle architecture, ne présentez pas ACP comme un concurrent actif à sélectionner sans examiner la migration officielle. Vérifiez toujours les versions actuelles des spécifications.
Choisir la bonne frontière
Exposez une opération déterministe ou une source via MCP. Utilisez A2A pour déléguer une tâche à un agent responsable de son cycle. Gardez une API classique lorsque schéma, clients et flux sont déjà bien définis : un protocole agentique n’apporte pas toujours de valeur.
Sécuriser la découverte et l’appel
Une liste d’outils ou une Agent Card n’accorde aucun droit. Authentifiez le client, autorisez chaque opération, validez les arguments et limitez ressources. Propagez l’identité sans transmettre les credentials bruts au modèle. Journalisez appels observables, pas secrets ni raisonnement privé.
Versionner et tester
Épinglez version de protocole, SDK et schémas. Testez timeouts, annulation, erreurs partielles, reprise et compatibilité. Un serveur doit pouvoir refuser une fonctionnalité non supportée. Ajoutez des tests de contrat indépendants du LLM.
Combiner MCP et A2A
Un agent exposé via A2A peut lui-même utiliser plusieurs serveurs MCP pour travailler. Le superviseur délègue une tâche ; l’agent distant appelle des outils autorisés. Les politiques d’identité et de budget doivent traverser les deux couches explicitement.
Exemple concret
Un agent d’achat reçoit via A2A une demande de comparaison de fournisseurs. Il utilise un serveur MCP catalogue en lecture et un serveur MCP ERP limité aux devis. La création de commande reste un outil distinct nécessitant validation humaine. Chaque frontière possède son authentification.
Les erreurs fréquentes
- utiliser A2A pour une simple fonction
- exposer toute une API interne comme outils non bornés
- considérer la découverte comme une autorisation
- partager un token administrateur avec le modèle
- ignorer versions et capacités négociées
- ajouter plusieurs protocoles sans besoin
Checklist
- [ ] Frontière outil ou agent définie
- [ ] Version de spécification épinglée
- [ ] Authentification et autorisation séparées
- [ ] Schémas et limites validés
- [ ] Timeout et annulation testés
- [ ] Identité et budgets propagés
- [ ] Tests de contrat automatisés
FAQ
MCP permet-il de parler à un agent ?
Une capacité agentique peut être exposée comme outil, mais A2A décrit mieux une délégation avec cycle de tâche et artefacts.
Peut-on combiner MCP et A2A ?
Oui. Un agent A2A peut utiliser des serveurs MCP pour accéder à ses capacités.
Faut-il migrer ACP ?
Pour un projet actif, suivez les indications officielles vers A2A et vérifiez la compatibilité.
Une API REST suffit-elle ?
Souvent oui. Utilisez ces protocoles lorsqu’ils améliorent réellement découverte, interopérabilité ou délégation.