L’écosystème agentique se dote de protocoles ouverts pour éviter que chaque framework et fournisseur invente ses propres connecteurs. MCP, A2A et AGNTCY sont souvent cités ensemble, mais ils ne résolvent pas le même problème. MCP relie principalement une application IA à des outils et données. A2A organise les échanges entre applications agentiques. AGNTCY développe des briques d’infrastructure pour la découverte, l’identité, la messagerie et l’observabilité d’écosystèmes d’agents.
Les combiner peut être pertinent à grande échelle. Les empiler sur un simple assistant interne crée une complexité et une surface de sécurité inutiles.
A2A v1.0 est présenté par son projet comme une version stable prête pour la production ; MCP a publié la spécification 2026-07-28. La maturité et les interfaces AGNTCY doivent être vérifiées pour chaque composant.
Pourquoi l’interopérabilité devient un sujet
Une entreprise peut utiliser plusieurs modèles, frameworks et produits. Un agent commercial doit peut-être demander une analyse à un agent documentaire, puis utiliser un outil de CRM. Sans contrat commun, chaque interaction est une intégration spécifique.
L’interopérabilité vise :
- découverte de capacités ;
- description de tâches ;
- échange de messages et artefacts ;
- gestion de travaux longs ;
- identité ;
- sécurité ;
- observabilité ;
- portabilité entre fournisseurs.
Elle ne remplace pas le modèle de domaine, les règles d’autorisation ou la gouvernance des données.
MCP : connecter une application IA à des capacités
MCP standardise la manière dont un client découvre et utilise des outils, ressources et extensions exposés par un serveur. Il est adapté lorsqu’une application agentique doit consulter un dépôt, appeler une API métier ou lancer une capacité encadrée.
Le serveur peut rester une façade au-dessus d’un service existant. Les outils doivent être étroits, autorisés et observables. MCP ne transforme pas un service en agent autonome ; il rend ses capacités consommables de manière standardisée.
La spécification 2026-07-28 adopte un cœur stateless et un cadre d’extensions, ce qui facilite certains déploiements à l’échelle.
A2A : collaborer entre agents
A2A vise l’échange entre applications agentiques qui peuvent être construites avec des frameworks différents et garder leur fonctionnement interne opaque. Un agent publie une carte de capacités, reçoit une tâche, échange des messages et renvoie des artefacts ou un état.
Le protocole est pertinent lorsqu’un agent délègue une tâche à un autre acteur qui possède sa propre autonomie, son cycle de vie et éventuellement son organisation. Il gère mieux les travaux longs et les interactions que l’appel d’un simple outil.
A2A v1.0 marque une stabilisation du contrat. L’adoption n’exonère pas de vérifier identité, tenant, autorisation, confidentialité et résultat.
AGNTCY : infrastructure ouverte pour un Internet des agents
Le projet AGNTCY, accueilli par la Linux Foundation, développe des composants autour de la découverte, de l’identité, de la messagerie et de l’observabilité. Son Open Agentic Schema Framework propose une taxonomie pour décrire capacités, domaines et relations.
Ce niveau devient intéressant lorsque de nombreux agents doivent être trouvés, qualifiés et opérés à travers des équipes ou organisations. Il ne s’agit pas d’une obligation pour utiliser MCP ou A2A. Les composants et leur maturité doivent être évalués individuellement.
Quel protocole pour quel problème ?
| Besoin | Option minimale probable |
|---|---|
| Appeler une fonction métier stable | API classique |
| Exposer des outils à plusieurs clients IA | MCP |
| Déléguer une tâche à une application agentique | A2A |
| Découvrir et gouverner de nombreux agents | registre/infrastructure dédiée |
| Orchestrer quelques composants internes | framework ou workflow interne |
| Échanger avec un partenaire | API ou A2A selon autonomie et durée |
Outil local de cadrage
Atelier de cadrage
Structurez les décisions principales avant de lancer un atelier métier. Les réponses restent dans votre navigateur.
Comparaison des rôles de MCP, A2A et d’une infrastructure agentique de découverte et d’observabilité.
API classique ou protocole agentique
Une API reste préférable lorsque l’opération est déterministe, le contrat stable et les acteurs connus. Elle est plus simple à tester, sécuriser et exploiter.
Un protocole agentique apporte une valeur lorsque les capacités sont découvertes, les tâches évoluent, les échanges sont longs ou plusieurs fournisseurs doivent collaborer. Le critère n’est pas l’usage d’un LLM, mais la nature du contrat.
Une architecture combinée
Un scénario possible :
- un agent coordinateur reçoit un objectif ;
- il découvre un agent spécialisé via un registre ;
- il lui délègue une tâche avec A2A ;
- l’agent spécialisé utilise MCP pour accéder à des outils internes ;
- l’infrastructure collecte identité, traces et états ;
- une politique valide le résultat avant action.
Chaque couche doit avoir une responsabilité. Le même besoin ne doit pas être encapsulé dans plusieurs protocoles sans raison.
Découverte et confiance
Découvrir une carte d’agent ou un serveur ne signifie pas lui faire confiance. Le registre conserve propriétaire, version, provenance, certifications éventuelles, capacités, politiques et statut d’approbation.
L’identité doit fonctionner à travers les frontières. Une organisation peut exiger un contrat, une liste autorisée et une authentification mutuelle avant tout échange.
Les capacités annoncées sont vérifiées. Un agent ne reçoit pas davantage de données parce qu’il prétend posséder une compétence.
Autorisation et délégation
Lorsqu’un agent délègue, il ne doit pas transmettre un jeton général. La délégation précise :
- donneur d’ordre ;
- bénéficiaire ;
- tâche ;
- ressources ;
- durée ;
- budget ;
- actions ;
- possibilité de sous-délégation.
Le service final revérifie les droits. La chaîne de délégation est visible dans l’audit.
Tâches, messages et artefacts
Une tâche longue possède un état, des mises à jour, une annulation et un résultat. Les messages ne doivent pas être confondus avec des commandes autorisées. Les artefacts — document, rapport, code ou données — ont un type, une provenance et des droits.
L’orchestrateur doit pouvoir gérer un agent indisponible, un résultat partiel ou un délai. Il ne suppose pas qu’une réponse conversationnelle équivaut à un succès métier.
Sémantique des capacités
Deux agents peuvent tous deux déclarer « recherche » tout en produire des résultats incompatibles. Les schémas, taxonomies et contrats métier restent nécessaires. OASF peut aider à décrire des capacités, mais l’entreprise doit définir ses propres exigences de qualité et de données.
Les versions et extensions sont négociées. Un changement de capacité déclenche une nouvelle qualification.
Observabilité distribuée
Une tâche traverse plusieurs agents, protocoles et outils. L’identifiant de corrélation, les horodatages et les états doivent suivre le parcours sans exposer les prompts sensibles.
Les métriques incluent :
- délai total et par acteur ;
- délégations ;
- erreurs ;
- reprises ;
- coûts ;
- approbations ;
- résultats rejetés ;
- politiques appliquées.
Un système multi-agent sans trace de bout en bout est difficile à diagnostiquer et à facturer.
Sécurité
Les principaux risques sont :
- agent ou serveur malveillant ;
- carte de capacité trompeuse ;
- délégation excessive ;
- injection dans les messages ;
- exfiltration par un outil ;
- artefact dangereux ;
- boucle de délégation ;
- consommation incontrôlée ;
- confusion de tenant.
Les contrôles incluent listes autorisées, budgets, profondeur maximale, validation de schémas, sandbox, approbations, limites réseau et mécanisme de coupure.
Éviter les boucles et explosions de coût
Un agent peut déléguer à un autre qui délègue à son tour. L’orchestrateur fixe profondeur, nombre de tâches, durée, tokens, outils et budget. Les sous-délégations sont autorisées explicitement.
Une tâche doit pouvoir être annulée et les ressources libérées. Les retries sont idempotents et limités.
Gouvernance des versions
MCP, A2A et les composants AGNTCY évoluent. L’organisation conserve une matrice de compatibilité, des environnements de test et une politique de mise à jour. Les dépréciations sont traitées comme des changements d’API.
Les SDK simplifient l’implémentation mais ne doivent pas masquer la version réellement supportée.
Commencer par l’architecture minimale
Un premier agent interne peut utiliser des API existantes et quelques outils MCP. A2A devient pertinent lorsqu’un autre agent autonome, éventuellement externe, doit collaborer. Une infrastructure de découverte distribuée vient lorsque le nombre d’acteurs et les frontières l’exigent.
Cette progression évite de construire un « Internet des agents » pour automatiser un seul workflow.
Des standards au service d’une gouvernance
Les protocoles ouverts améliorent la portabilité et réduisent les intégrations spécifiques. Ils ne remplacent pas les choix de confiance, de qualité et de responsabilité.
Partitech peut concevoir une architecture minimale, développer des serveurs MCP, intégrer A2A et évaluer les briques d’infrastructure agentique. L’objectif est une interopérabilité utile, testable et sécurisée, non un empilement de standards.
Parlons de votre projet
Définir une architecture agentique interopérable et gouvernée avec Partitech. Contactez Partitech.