Communication inter-agents IA : protocoles, architectures et enjeux

Le 9 décembre 2025, Anthropic a confié le Model Context Protocol à la Linux Foundation et posé, avec OpenAI et Block, la première pierre d'une Agentic AI Foundation soutenue par Google, Microsoft, AWS, Cloudflare et Bloomberg. Six mois plus tôt, le 23 juin 2025, Google avait fait exactement le même geste avec son protocole Agent2Agent. En l'espace d'un an, les deux briques logicielles qui décrivent comment les agents d'intelligence artificielle se parlent sont passées d'initiatives d'entreprise à des standards ouverts, gouvernés collectivement. Cette convergence dit l'essentiel : la question n'est plus de savoir si les agents IA collaborent, mais selon quels protocoles, quelles architectures et quelles règles de transparence.

Cet article propose une plongée technique dans les mécanismes de communication inter-agents IA tels qu'ils fonctionnent au milieu de 2026. Nous allons décortiquer les trois grands protocoles de la pile — MCP d'Anthropic, A2A de Google et le function calling popularisé par OpenAI —, explorer les architectures d'orchestration multi-agents, comprendre le rôle des embeddings comme représentation partagée, examiner des cas d'usage concrets, puis aborder l'observabilité et le cadre réglementaire européen. L'objectif est de fournir une cartographie complète et vérifiable de cet écosystème, loin des raccourcis sur un hypothétique « langage secret » entre machines.

Un mot de méthode d'abord. Chaque chiffre avancé ici renvoie à une source publique : spécifications officielles, annonces des éditeurs, articles de recherche. Là où la donnée est incertaine ou en mouvement, nous le signalons plutôt que de trancher. C'est la ligne éditoriale d'un média sur l'IA écrit par l'IA : on élève le propos, on ne l'invente pas.

Pourquoi les agents IA ont besoin de protocoles

Un agent IA isolé, aussi capable soit-il, atteint vite ses limites. Il raisonne, génère du texte, appelle une interface de programmation. Mais dès qu'une mission enchaîne plusieurs compétences — analyser un jeu de données, interroger une base de connaissances, rédiger un rapport, puis l'expédier — un seul agent ne suffit plus. Il faut plusieurs agents spécialisés qui se répartissent le travail. Et pour se répartir le travail, il faut un langage commun : un ensemble de conventions techniques qui permettent à un agent A d'adresser une requête à un agent B, de recevoir une réponse structurée et de poursuivre son raisonnement.

Des microservices aux systèmes multi-agents

L'évolution des systèmes d'IA rejoue une trajectoire déjà connue des architectes logiciels. Dans les années 2000, les applications monolithiques dominaient : un seul programme gérait tout. Puis les microservices ont imposé des composants indépendants, spécialisés, communiquant via des interfaces standardisées comme REST ou gRPC. Résultat : des systèmes plus résilients, plus faciles à faire évoluer. Les agents IA suivent le même chemin. Entre 2022 et 2024, le paradigme dominant était le chatbot monolithique : un modèle, une conversation, une capacité. En 2025, le paradigme agentique s'est imposé : un modèle augmenté d'outils, capable d'appeler des fonctions et d'exécuter du code. En 2026, l'ère des systèmes multi-agents est bien installée, avec des équipes d'agents qui convergent vers un objectif commun.

L'analogie avec l'histoire des réseaux est éclairante. Dans les années 1970, chaque constructeur imposait son protocole : IBM avec SNA, DEC avec DECnet, Xerox avec XNS. L'interopérabilité relevait du casse-tête. L'adoption de TCP/IP comme standard ouvert a unifié l'écosystème et rendu possible l'émergence d'Internet. Les protocoles de communication inter-agents IA traversent la même transition, mais à une vitesse remarquable : ce qui a pris une décennie aux réseaux se joue ici en deux ans.

Le verrou de l'interopérabilité

Le marché des agents IA connaît une croissance soutenue, et les frameworks se multiplient : CrewAI, AutoGen puis AG2, LangGraph, l'Agents SDK d'OpenAI, Semantic Kernel de Microsoft, l'Agent Development Kit de Google. Chacun propose ses conventions de communication, ses formats de messages, ses mécanismes de coordination. Le problème classique de l'interopérabilité refait alors surface : un agent construit avec CrewAI ne sait pas nativement parler à un agent AutoGen, et un outil exposé selon les conventions d'un éditeur n'est pas directement consommable par un modèle d'un autre. Les équipes se retrouvent à écrire du code d'intégration spécifique pour chaque combinaison — précisément le travail que les standards ouverts avaient supprimé côté logiciel il y a vingt ans.

C'est pour lever ce verrou que trois familles de protocoles se sont structurées entre 2023 et 2026 :

• MCP (Model Context Protocol) d'Anthropic — standardise la connexion entre un modèle et ses outils ou ressources externes ;
• A2A (Agent2Agent) de Google — standardise la communication directe entre agents autonomes ;
• Function calling / tool use popularisé par OpenAI — standardise l'invocation de fonctions par un modèle au sein d'un même système.

Ces trois familles ne se concurrencent pas : elles opèrent à des niveaux distincts de la pile. Comprendre leurs différences et leurs complémentarités, c'est comprendre comment les agents IA communiquent aujourd'hui.

Ce qui frappe, c'est la vitesse de maturation. En un an, deux protocoles portés par des concurrents directs sont passés sous gouvernance ouverte de la Linux Foundation. C'est un signal fort d'un écosystème qui choisit l'interopérabilité plutôt que le verrouillage.

Les trois protocoles de la pile de communication

Pour comprendre les échanges entre agents, il faut distinguer trois couches. La couche outil, où un modèle appelle une fonction. La couche contexte, où un modèle accède à des ressources externes structurées. Et la couche agent, où deux agents autonomes collaborent. Chaque protocole adresse une ou plusieurs de ces couches.

MCP : le connecteur universel des outils

Lancé par Anthropic en novembre 2024, le Model Context Protocol est un standard ouvert qui définit comment un modèle de langage — le « client » — se connecte à des sources de données et des outils externes — les « serveurs ». L'analogie la plus parlante est celle d'un port universel : un seul connecteur normalisé pour brancher n'importe quel périphérique, au lieu d'un câble propriétaire par appareil. L'architecture repose sur trois composants :

• MCP Host : l'application qui héberge le modèle — un assistant de bureau, un environnement de développement comme Cursor, ou toute application intégrant un modèle ;
• MCP Client : le composant du host qui gère la connexion et maintient une session dédiée avec chaque serveur ;
• MCP Server : un programme léger qui expose des tools (fonctions invocables), des resources (données consultables) et des prompts (modèles de requêtes) via le protocole.

Techniquement, MCP s'appuie sur JSON-RPC 2.0 comme format de messages, transporté par deux mécanismes : stdio (entrée-sortie standard, pour les serveurs locaux) et HTTP streamable, avec des Server-Sent Events pour la diffusion progressive. La spécification a mûri par vagues successives. La révision du 18 juin 2025 a introduit les structured outputs (une sortie d'outil peut désormais suivre un schéma JSON déclaré via un champ structuredContent), l'elicitation (un serveur peut demander une information à l'utilisateur en cours de session, avec un schéma décrivant la donnée attendue), et un durcissement de l'authentification : les clients doivent inclure un paramètre resource conforme au RFC 8707, qui lie chaque jeton d'accès à un serveur précis. Les serveurs distants s'appuient sur OAuth 2.1 et se déclarent comme serveurs de ressources OAuth via des points d'accès .well-known. La version du 25 novembre 2025 a consolidé l'ensemble.

Concrètement, un serveur MCP publie un manifeste listant ses capacités. Quand un agent se connecte, il découvre automatiquement les outils disponibles — noms, paramètres, descriptions — puis les invoque de manière structurée. C'est un mécanisme de découverte dynamique qui élimine le câblage figé. Un aspect souvent sous-estimé est le sampling : au-delà des outils et des ressources, MCP permet à un serveur de demander au client de générer du texte, inversant le flux habituel. Un serveur peut ainsi « consulter » le modèle pour une tâche intermédiaire — résumer un document avant de le stocker, traduire une question en requête de base de données. Le serveur devient un collaborateur actif, pas seulement un fournisseur de données passif.

Les forces de MCP sont désormais bien documentées :

• Écosystème massif : le registre officiel comptait 9 652 serveurs de dernière version au 24 mai 2026, et Anthropic évoquait plus de 10 000 serveurs publics actifs fin 2025 ; les recensements indépendants dépassent 17 000 serveurs indexés au premier trimestre 2026 ;
• Vélocité d'adoption : selon Anthropic, les téléchargements des SDK ont atteint plus de 97 millions par mois dès décembre 2025, un an seulement après le lancement du protocole ;
• Agnosticisme modèle : bien que créé par Anthropic, MCP fonctionne avec des modèles variés dès lors qu'ils implémentent le protocole ;
• Adoption transversale : Anthropic, OpenAI, Google, Microsoft, GitHub, Vercel, VS Code et Cursor disposent tous d'une prise en charge documentée.

Un exemple rend la chose tangible. Imaginons un agent d'analyse financière qui doit accéder à une base PostgreSQL pour l'historique, à une interface de cours pour le temps réel, à un tableur pour les rapports et à une messagerie d'équipe pour les alertes. Sans standard, le développeur écrit quatre intégrations, avec quatre formats d'authentification et quatre gestions d'erreurs à maintenir. Avec MCP, il installe quatre serveurs — un par service — et l'agent les découvre puis les utilise via une interface unifiée. Le coût d'intégration passe de semaines à quelques heures.

La limite à connaître est nette : MCP standardise la connexion modèle vers outil, pas la communication agent vers agent. Un serveur MCP est passif, il attend qu'un client initie la connexion. Pour la coordination directe entre agents autonomes — où chaque agent peut ouvrir un échange — il faut un protocole de niveau supérieur. C'est le rôle d'A2A.

A2A : la collaboration directe entre agents

Annoncé par Google le 9 avril 2025 au salon Cloud Next, le protocole Agent2Agent s'attaque au problème complémentaire de MCP : permettre à des agents opaques de collaborer sans partager leur implémentation interne. Là où MCP connecte un modèle à ses outils, A2A connecte des agents entre eux. Le concept central est l'Agent Card : un document JSON publié à une adresse standardisée (/.well-known/agent.json) qui décrit les compétences de l'agent, ses modalités d'entrée et de sortie, ses protocoles de communication et ses mécanismes d'authentification. C'est l'équivalent d'une carte de visite lisible par machine : chaque agent publie ce qu'il sait faire, et les autres le découvrent automatiquement.

Le protocole s'appuie sur HTTP, les Server-Sent Events et JSON-RPC 2.0. L'authentification mobilise les standards du web (OAuth 2.0, clés d'interface, mTLS). Le cycle de vie s'organise autour de la notion de Task :

• Découverte : l'agent client récupère l'Agent Card du serveur pour connaître ses compétences ;
• Création de tâche : le client envoie un message structuré décrivant ce qu'il attend ;
• Exécution : le serveur traite la tâche, avec diffusion progressive possible des résultats ;
• Réponse : le serveur retourne un ou plusieurs Artifacts (résultats structurés) avec leur type MIME ;
• Suivi : le client peut vérifier le statut à tout moment (soumis, en cours, information requise, terminé, échoué).

A2A respecte l'opacité des agents — ils n'exposent que leurs capacités et leurs résultats, jamais leur logique interne, ce qui convient aux agents propriétaires en entreprise. Il gère la négociation de contenu (chaque agent déclare les formats qu'il accepte), les notifications proactives (le serveur signale la progression sans que le client ait à interroger en boucle) et les échanges multi-tours (une collaboration peut s'étendre sur plusieurs allers-retours avec clarifications). Sa gestion des tâches longues est particulièrement soignée : dans le monde réel, un agent ne répond pas toujours immédiatement. La vérification d'un contrat peut prendre plusieurs heures, consultation humaine incluse. A2A gère nativement ce cas avec ses statuts de tâche et ses notifications : le client dépose sa requête, continue son travail, et sera averti quand le résultat sera prêt. C'est un modèle asynchrone natif, essentiel pour les processus d'entreprise.

L'événement structurant de 2025 est la mise sous gouvernance ouverte. Le 23 juin 2025, Google a confié A2A à la Linux Foundation, sous licence Apache 2.0, avec pour membres fondateurs AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow. En avril 2026, plus de 150 organisations soutenaient le protocole, dont Workday et IBM. Le positionnement est clair : là où MCP dit « voici les outils que tu peux utiliser », A2A dit « voici un agent avec qui tu peux collaborer ». Les deux sont conçus pour coexister.

Un scénario concret : une entreprise dispose d'un agent ressources humaines, d'un agent juridique et d'un agent intégration. Quand une candidature est retenue, l'agent RH crée une Task auprès de l'agent juridique pour préparer le contrat. L'agent juridique traite la demande, retourne le contrat sous forme d'Artifact, et l'agent RH transmet le résultat à l'agent intégration pour planifier l'accueil. Chaque agent est un service indépendant, potentiellement développé par une équipe différente sur une pile technique différente — mais tous collaborent via un protocole commun.

Function calling : la brique élémentaire

Le function calling, introduit par OpenAI en juin 2023 avec GPT-3.5 et GPT-4, est le plus ancien des trois mécanismes. Son principe : permettre au modèle de décider d'appeler une fonction définie par le développeur, en produisant un JSON structuré avec les arguments appropriés. Le développeur exécute ensuite la fonction et renvoie le résultat au modèle. Le développeur déclare une liste de fonctions avec leurs schémas JSON — nom, description, paramètres — et le modèle choisit, selon le contexte, d'en appeler une ou plusieurs, ou de répondre en texte.

Le mécanisme s'est raffiné : appels parallèles (plusieurs fonctions invoquées dans une seule réponse), puis garanties de conformité au schéma déclaré, qui suppriment les erreurs d'analyse. Surtout, le function calling est devenu un standard de fait : la quasi-totalité des fournisseurs l'implémentent, sous une forme ou une autre, y compris les modèles ouverts via des moteurs d'exécution comme vLLM, Text Generation Inference ou Ollama. Cette ubiquité en fait le plus petit dénominateur commun de la communication modèle vers outil. Sa force tient à sa simplicité : un schéma JSON pour décrire la fonction, le modèle décide quand l'appeler, le développeur exécute. Pas de serveur à déployer, pas de découverte dynamique — juste un contrat d'interface.

Sa limite est symétrique à sa force : il vise la communication modèle vers fonction au sein d'un même système, de façon largement unidirectionnelle et synchrone. Pour la coordination entre agents distribués, avec découverte, négociation de capacités et échanges asynchrones, il faut passer à MCP ou A2A. Le function calling est la brique élémentaire ; MCP et A2A sont les protocoles d'architecture. C'est d'ailleurs pourquoi OpenAI a adopté MCP dans son Agents SDK dès mars 2025, avant d'étendre le support à ChatGPT dans les mois suivants : le standard de connexion aux outils s'est imposé au-delà de son créateur.

Comparatif : MCP, A2A et function calling

Pour visualiser les différences et les complémentarités, voici un comparatif synthétique des trois approches.

Critère	MCP (Anthropic)	A2A (Google)	Function calling (OpenAI)
Couche	Modèle → outils / ressources	Agent → agent	Modèle → fonctions
Lancement	Novembre 2024	Avril 2025	Juin 2023
Format des messages	JSON-RPC 2.0	HTTP + JSON-RPC 2.0 + SSE	JSON (interface de complétion)
Transport	stdio, HTTP streamable	HTTP, SSE, notifications	HTTPS
Découverte	Manifeste serveur	Agent Card (/.well-known/agent.json)	Déclaration statique (liste de tools)
Authentification	OAuth 2.1 (distant)	OAuth 2.0, clés, mTLS	Clé d'interface
Multi-agents	Non natif (1 client → N serveurs)	Oui (N agents → N agents)	Via SDK (handoffs)
Gouvernance	Linux Foundation (déc. 2025)	Linux Foundation (juin 2025)	Spécification publique de l'éditeur

Le point clé : ces trois approches forment une pile cohérente, pas des alternatives exclusives. Un système multi-agents en production utilise typiquement le function calling pour les interactions internes, MCP pour connecter chaque agent à ses outils et ressources, et A2A pour la coordination entre agents. C'est l'équivalent de TCP/IP, HTTP et REST : trois couches qui s'empilent pour former le web tel qu'on le connaît.

Architectures multi-agents : comment les IA s'organisent

Avoir des protocoles ne suffit pas. Il faut définir comment les agents s'organisent pour collaborer. Trois grands schémas d'architecture dominent en 2026, chacun avec ses forces et ses cas d'usage optimaux. Le choix influence directement la performance, la résilience et la maintenabilité du système.

Orchestration centralisée : un chef d'orchestre

L'orchestration centralisée est le schéma le plus courant et le plus intuitif. Un agent orchestrateur — souvent un modèle puissant — reçoit une mission complexe, la décompose en sous-tâches, les distribue à des agents spécialisés, collecte les résultats et les synthétise. C'est le modèle en étoile : un centre de coordination parle à tous les agents, mais les agents ne se parlent pas directement. La majorité des frameworks l'implémentent. CrewAI propose un processus séquentiel ou hiérarchique où un agent gestionnaire délègue aux membres de l'équipe. LangGraph modélise l'orchestration comme un graphe orienté, avec des nœuds (agents) et des arêtes (transitions), autorisant cycles, branches conditionnelles et points de contrôle humain. L'Agents SDK d'OpenAI s'appuie sur les handoffs : un agent « passe la main » à un autre agent spécialisé, avec transfert du contexte.

La communication suit un schéma en étoile. L'orchestrateur envoie un message structuré à chaque agent — la sous-tâche, le contexte, les contraintes de format —, l'agent traite et retourne un résultat structuré, et l'orchestrateur agrège puis décide de l'étape suivante. Une avancée clé de 2025-2026 est la replanification dynamique : l'orchestrateur n'exécute pas un plan figé, il adapte sa stratégie en fonction des résultats obtenus à chaque étape. Les avantages sont réels : visibilité totale sur le déroulé, facilité de mise au point, prévisibilité, traçabilité complète. Les limites aussi : l'orchestrateur devient un point de passage unique, le système monte difficilement en charge au-delà de quelques dizaines d'agents, et la consommation de jetons peut grimper puisque chaque échange traverse le même nœud.

Chorégraphie décentralisée : agents autonomes en réseau

La chorégraphie décentralisée est l'approche inverse : aucun agent central ne coordonne. Chaque agent est autonome, publie ses capacités et réagit aux messages des autres selon ses propres règles. C'est le modèle pair-à-pair, inspiré des architectures événementielles du monde logiciel. Chaque agent s'abonne aux événements qui le concernent, traite les messages entrants et publie ses résultats. La coordination émerge de la somme des interactions locales, sans pilotage global. A2A convient particulièrement à ce schéma : chaque agent publie son Agent Card, les autres le découvrent, et la collaboration se fait par échanges directs de tâches. AutoGen, poursuivi par la communauté sous le nom AG2, implémente une variante avec ses conversations de groupe : plusieurs agents participent à un échange partagé, un mécanisme de sélection déterminant qui prend la parole à chaque tour.

Les atouts sont la résilience (si un agent s'arrête, les autres continuent), la montée en charge horizontale (ajouter un agent ne surcharge aucun coordinateur) et la souplesse d'évolution (chaque agent se met à jour indépendamment). Les limites sont le reflet des atouts : la mise au point est plus délicate faute de vue globale, le risque de boucles existe (deux agents qui se relancent mutuellement), et la gestion des erreurs distribuées demande de la rigueur. Pour l'encadrer, les implémentations en production ajoutent des disjoncteurs (un agent qui échoue plusieurs fois est temporairement désactivé), des délais d'expiration et des files d'attente de messages non traités pour analyse ultérieure.

Délégation hiérarchique : du manager aux spécialistes

La délégation hiérarchique combine les deux approches. Un agent manager de haut niveau reçoit une mission complexe et la décompose, mais au lieu de tout exécuter ou de confier directement chaque sous-tâche, il délègue à un sous-manager qui, à son tour, coordonne une équipe de spécialistes. C'est un modèle en arbre : chaque niveau a une portée de coordination limitée. Ce schéma est optimal pour les systèmes à grande échelle, au-delà de plusieurs dizaines d'agents, où un seul orchestrateur ne peut pas tout coordonner. CrewAI le propose en mode hiérarchique, avec un agent gestionnaire qui décide dynamiquement quel agent exécute quelle tâche, et la possibilité de créer des sous-équipes pour les missions complexes. La force du schéma : il combine la visibilité de l'orchestration centralisée avec la scalabilité de la chorégraphie. La difficulté réside dans la conception de la hiérarchie — trop de niveaux ralentissent, trop peu recréent le goulot d'étranglement.

En pratique, le choix dépend de trois facteurs :

• Nombre d'agents : orchestration centralisée pour de petites équipes, hiérarchie pour les ensembles intermédiaires, chorégraphie pour les grands nombres ;
• Couplage des tâches : si les agents échangent fréquemment des résultats intermédiaires, l'orchestration centralisée simplifie ; s'ils sont relativement indépendants, la chorégraphie est plus efficace ;
• Exigences de traçabilité : les secteurs réglementés préfèrent l'orchestration centralisée ou hiérarchique, plus faciles à auditer.

Les embeddings : une représentation partagée

Au-delà des protocoles explicites, les agents partagent un autre mécanisme de compréhension mutuelle : les embeddings. Ce ne sont pas des messages au sens classique, mais des représentations mathématiques de l'information qui jouent le rôle d'une lingua franca implicite entre modèles.

Espaces vectoriels et alignement sémantique

Un embedding est un vecteur numérique — une liste de nombres, typiquement de quelques centaines à quelques milliers de dimensions — qui situe un concept, un mot ou un document dans un espace mathématique. Deux éléments proches sémantiquement (« chat » et « félin ») se retrouvent proches dans cet espace ; deux éléments éloignés (« chat » et « comptabilité ») sont distants. Ce qui rend les embeddings pertinents pour la communication inter-agents, c'est la propriété d'alignement sémantique. Les modèles d'embeddings modernes produisent des vecteurs qui capturent le sens de manière relativement stable. Quand un agent A encode un concept et le range dans une base vectorielle, un agent B utilisant un modèle compatible peut retrouver ce concept par similarité, même si les deux agents s'appuient sur des modèles de langage différents.

Précisons un point souvent mal compris : les embeddings ne constituent pas un « langage secret » entre IA. Ce sont des représentations mathématiques documentées, auditables, dont les propriétés sont étudiées par des milliers de chercheurs. Parler de langage secret à leur propos reviendrait à dire qu'une base de données relationnelle en possède un parce qu'elle stocke des données en binaire. C'est un format technique, pas un mystère.

Mémoire vectorielle partagée et RAG multi-agents

Le schéma de génération augmentée par récupération, ou RAG, est devenu le standard pour connecter les modèles à des connaissances externes. En version multi-agents, une base vectorielle partagée devient la mémoire collective de l'équipe. Voici comment cela fonctionne en pratique :

• Un agent d'ingestion collecte et indexe des documents dans une base vectorielle ;
• Un agent d'analyse interroge cette base en langage naturel pour retrouver les informations utiles à sa tâche ;
• Un agent de rédaction produit un livrable à partir des résultats de l'analyse ;
• Un agent de contrôle vérifie le livrable en croisant les affirmations avec les sources indexées.

La base vectorielle joue ici le rôle d'un canal asynchrone : les agents ne se parlent pas directement, ils lisent et écrivent dans un espace de connaissance commun. Les frameworks comme LangGraph vont plus loin avec un state partagé entre tous les nœuds du graphe : messages, résultats intermédiaires, décisions et métadonnées circulent dans une mémoire de travail collective qui s'enrichit à chaque étape. Un schéma qui gagne du terrain en 2026 est le RAG sur graphe de connaissances : au lieu de stocker les informations en vecteurs isolés, le système modélise explicitement les entités et leurs relations, ce qui permet à un agent de naviguer d'un contrat à un produit puis à sa documentation, plutôt que de chercher par simple similarité. La combinaison embeddings, graphe de connaissances et mémoire conversationnelle constitue une couche de communication implicite qui complète les protocoles explicites : les agents partagent un espace de compréhension commune qui rend leur collaboration plus cohérente.

Le « langage entre agents » : mythe et réalité

Une inquiétude revient régulièrement dans le débat public : les agents IA développeraient-ils un langage propre, opaque aux humains ? La question mérite une réponse factuelle, car elle mêle un phénomène réel de recherche et beaucoup d'interprétations hâtives.

La recherche sur la communication émergente

La communication émergente est un domaine d'étude établi : quand on laisse des agents apprendre à coopérer sur une tâche sans leur imposer de langage, ils tendent à développer des conventions de signalisation efficaces, parfois compressées. C'est un objet d'expérimentation contrôlée, étudié pour comprendre comment naissent les protocoles de coordination — un sujet passionnant pour la linguistique computationnelle. Une démonstration a marqué 2025 : lors d'un hackathon organisé par ElevenLabs, Boris Starkov et Anton Pidkuiko ont présenté Gibberlink, un mode où deux assistants vocaux, une fois qu'ils se reconnaissent mutuellement comme des IA, basculent d'une conversation parlée vers un protocole acoustique nommé GGWave. Ce dernier encode l'information dans un spectre de fréquences avec correction d'erreurs, transmettant des données par tonalités plutôt que par voix synthétique. L'intérêt est purement d'efficacité : éviter la couche coûteuse de la synthèse et de la reconnaissance vocales quand deux machines se parlent.

Le « langage secret des IA » est un raccourci trompeur. La réalité est un ensemble de formats d'ingénierie transparents et auditables. Un échange entre agents ressemble bien plus à une requête HTTP qu'à un message chiffré : structuré, journalisé, inspectable.

Pourquoi les standards ouverts l'emportent en production

En pratique, les systèmes déployés en entreprise n'utilisent pas de langage improvisé : ils s'appuient sur des protocoles documentés — JSON-RPC, HTTP, Agent Cards, schémas JSON — précisément parce que la traçabilité est une exigence, pas une option. Un langage émergent, aussi efficace soit-il, serait ingérable dès qu'il faut auditer une décision, corriger une erreur ou prouver la conformité à un régulateur. La recherche sur la communication émergente éclaire la conception des protocoles ; elle ne les remplace pas. La prolifération réelle concerne au contraire les protocoles ouverts : outre MCP et A2A, la littérature recense des initiatives comme ACP (Agent Communication Protocol) et ANP (Agent Network Protocol). Les travaux de synthèse récents — notamment l'article « Beyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent Systems » et « Multi-Agent Collaboration Mechanisms: A Survey of LLMs » — cartographient cet écosystème et pointent les vrais chantiers : efficacité de la communication, robustesse, évaluation et montée en charge. Un signe de maturité : le débat s'est déplacé de la crainte d'un langage opaque vers la question, bien plus concrète, de la convergence des standards ouverts.

Cas d'usage : la communication inter-IA en production

La théorie est utile, la production l'est davantage. Voici trois domaines où les systèmes multi-agents collaborent au quotidien, avec des architectures et des protocoles concrets.

DevOps : orchestrer le cycle de déploiement

L'un des cas d'usage les plus matures est l'automatisation des chaînes DevOps. Un flux typique mobilise plusieurs agents spécialisés :

• Un agent de revue de code analyse les propositions de modification et suggère des améliorations ;
• Un agent de test génère et exécute des tests, repère les cas limites non couverts ;
• Un agent de sécurité examine les dépendances et détecte les vulnérabilités connues ;
• Un agent de déploiement pilote le déploiement progressif (canari, bleu-vert, drapeaux de fonctionnalité) ;
• Un agent d'observabilité surveille les métriques après déploiement et déclenche un retour arrière si les seuils de service sont franchis.

Ces agents communiquent via une combinaison de MCP — chaque agent accède à ses outils, gestion de code, suivi de tickets, supervision, via des serveurs MCP — et d'orchestration centralisée : un agent gestionnaire coordonne la séquence revue → test → sécurité → déploiement → supervision. La communication suit un schéma caractéristique : le pipeline en cascade avec portes de validation. Chaque agent produit un verdict, et l'étape suivante ne démarre que si la porte précédente est au vert. Chaque transition est un message structuré qui transporte le contexte accumulé — identifiant de version, résultats des étapes antérieures, indices de confiance. C'est un modèle de consensus séquentiel qui garantit la qualité sans figer le flux.

Chaîne logistique : coordination entre spécialistes

La gestion de la chaîne d'approvisionnement est un terrain naturel pour les systèmes multi-agents : la complexité — fournisseurs multiples, délais variables, demande fluctuante, contraintes réglementaires — dépasse les capacités d'un agent unique. Un système typique comprend un agent de prévision de la demande, un agent d'approvisionnement qui optimise les commandes, un agent logistique qui organise les itinéraires, un agent de conformité qui vérifie les réglementations, et un agent financier qui surveille la trésorerie. La communication passe souvent par une chorégraphie événementielle : chaque agent publie ses décisions — commande passée, livraison planifiée, alerte de stock — sur un bus d'événements, et les agents concernés réagissent. Un point technique clé est la gestion de la cohérence : quand l'agent de prévision revoit ses estimations, l'agent d'approvisionnement ajuste ses commandes, ce qui impacte l'agent logistique. Cette cascade se gère par propagation d'événements avec versionnage : chaque décision porte un numéro de version, et les agents ne traitent que les événements plus récents que leur dernier état connu, ce qui évite les incohérences temporelles.

Création de contenu : l'équipe éditoriale multi-agents

Le dernier cas mérite une mention parce qu'il est directement observable sur ce site. blog-ia.fr fonctionne avec une architecture multi-agents où une orchestratrice coordonne des agents spécialisés : rédacteurs (chacun avec son avatar, son ton et sa spécialité), analystes SEO, agents de maillage interne, agents de conformité. Une orchestration centralisée coordonne le pipeline éditorial — idéation, rédaction, relecture, publication — et un humain, le directeur de publication, valide chaque parution. Ce qui compte ici, ce n'est pas tant la technologie que le modèle d'organisation. Un système éditorial fonctionne bien quand trois conditions sont réunies :

• Périmètres clairs : chaque agent a un rôle défini et non chevauchant ; aucun ne fait le travail d'un autre ;
• Canaux structurés : chaque agent produit une sortie normée qu'un autre peut consommer sans ambiguïté — des artefacts typés, pas du texte libre ;
• Validation humaine ciblée : l'humain ne valide pas chaque étape, mais les points de décision clés — publication, modification, suppression.

Ce modèle de séparation des responsabilités, de communication structurée et de validation ciblée s'applique bien au-delà de l'édition. C'est le plan de base de tout système multi-agents en production, quel que soit le domaine.

Observabilité et transparence : garder le contrôle

Un système multi-agents en production, c'est parfois des centaines d'échanges pour une seule requête utilisateur. Comment s'assurer qu'il fait ce qu'on attend, diagnostiquer un comportement inattendu, prouver à un auditeur que le processus est maîtrisé ? La réponse tient en un mot : observabilité.

Les trois piliers de l'observabilité

L'observabilité des systèmes multi-agents hérite des bonnes pratiques des systèmes distribués et repose sur trois piliers. Les logs structurés : chaque agent journalise ses actions, ses décisions et leurs justifications au format JSON, avec horodatage, source, entrées et sorties, temps d'exécution. Les traces distribuées, inspirées d'OpenTelemetry, suivent une requête de bout en bout à travers tous les agents ; chaque segment montre quel agent a été invoqué, combien de temps il a pris, quels outils il a utilisés et quel résultat il a produit — l'équivalent des traces de microservices appliqué aux agents. Les métriques et tableaux de bord : nombre d'appels par agent, latence, taux de succès, coût en jetons, nombre d'interventions humaines. L'écosystème dédié a mûri : des outils spécialisés couvrent le suivi des interactions, l'évaluation des chaînes de récupération et le pilotage des coûts. Le schéma le plus efficace en production est le traçage hiérarchique : une trace de niveau 1 pour la requête, des sous-traces pour chaque agent, des sous-sous-traces pour chaque appel d'outil. On zoome ainsi de la vue globale au détail fin. Le suivi des coûts en temps réel est particulièrement précieux : chaque segment porte le nombre de jetons consommés, ce qui permet de repérer les agents trop gourmands et d'optimiser les invites.

Régulation : ce que le règlement européen attend

Le règlement européen sur l'intelligence artificielle (Règlement UE 2024/1689), en application progressive depuis 2025, comporte des exigences de transparence qui concernent directement les systèmes multi-agents. L'article 50 impose d'informer les personnes lorsqu'elles interagissent avec un système d'IA et d'apposer un marquage lisible par machine sur les contenus synthétiques ; ces obligations de transparence deviennent applicables le 2 août 2026. Pour les systèmes à haut risque, la documentation technique doit détailler les processus de décision — le calendrier a été assoupli : selon l'accord politique provisoire de l'Omnibus du 7 mai 2026, l'échéance principale des systèmes de l'annexe III est repoussée à décembre 2027, sous réserve d'adoption formelle. Pour les systèmes multi-agents, cela se traduit par des obligations concrètes :

• Traçabilité des décisions : chaque décision doit pouvoir être retracée jusqu'à ses entrées, son raisonnement et ses sources — ce que les logs et traces couvrent ;
• Explicabilité : un humain doit pouvoir comprendre pourquoi un agent a décidé, donc les agents produisent des justifications en langage naturel ;
• Supervision humaine : les systèmes à haut risque intègrent des points de contrôle humain, le schéma « humain dans la boucle » étant la réponse standard ;
• Documentation technique : architecture, protocoles de communication et mécanismes de repli documentés et maintenus à jour.

La bonne nouvelle : MCP et A2A ont été pensés avec la transparence en tête. MCP journalise chaque appel d'outil avec ses paramètres et ses résultats. A2A structure chaque interaction en Task dotée d'un cycle de vie documenté. Le function calling restitue le détail de chaque appel dans l'historique de la conversation. L'observabilité n'est pas un ajout tardif, elle est intégrée dans l'architecture — ce qui facilite la mise en conformité.

Les frameworks multi-agents en 2026

Les protocoles définissent le « comment communiquer », les frameworks le « comment organiser ». Voici les principaux, avec leurs traits distinctifs. CrewAI est le plus accessible pour démarrer : agents dotés d'un rôle et d'un objectif, tâches, équipes, processus séquentiel ou hiérarchique. Une équipe de quelques agents se configure en quelques dizaines de lignes, avec prise en charge native de MCP. AutoGen, poursuivi par la communauté sous le nom AG2 après la réécriture de Microsoft, excelle dans les conversations multi-agents : agents conversationnels, discussions de groupe avec sélection dynamique de l'orateur, sous-conversations imbriquées. C'est le terrain des scénarios où les agents doivent débattre et converger. LangGraph est le plus flexible pour les flux complexes : un état partagé, des nœuds, des transitions conditionnelles et des points de sauvegarde ; il modélise les flux comme des graphes orientés avec cycles possibles, et affiche l'empreinte de production la plus large en 2026. L'Agents SDK d'OpenAI, optimisé pour son écosystème, se distingue par sa gestion native des handoffs. Semantic Kernel de Microsoft vise l'intégration dans des applications d'entreprise existantes. À côté de ces frameworks, Google a stabilisé son Agent Development Kit et intègre A2A pour la collaboration entre agents.

Les plateformes cloud proposent leurs propres couches d'orchestration, qui simplifient le déploiement mais peuvent créer une dépendance : un système bâti entièrement sur l'une d'elles n'est pas portable sans réécriture. C'est précisément pour éviter cette dépendance que les protocoles ouverts sont stratégiques. Un agent qui expose ses capacités via un Agent Card et ses outils via un serveur MCP est portable par conception : hébergeable sur n'importe quel cloud, invocable par n'importe quel framework. La tendance forte de 2026 est la convergence vers MCP pour la couche outils et A2A pour la couche inter-agents — CrewAI, LangGraph et AG2 prennent en charge MCP nativement. Un dernier point mérite attention : le coût. Un système à plusieurs agents peut consommer bien davantage de jetons qu'un agent unique. Les stratégies d'optimisation incluent la compression de contexte, le routage intelligent (un modèle léger pour aiguiller, un modèle puissant pour raisonner) et la mise en cache des résultats. Ces schémas de sobriété comptent autant que les protocoles pour rendre les systèmes viables en production.

Perspectives 2026-2028 : vers un standard universel ?

L'écosystème évolue vite. Trois tendances majeures se dessinent. Première tendance, la convergence MCP + A2A. Les deux protocoles sont complémentaires par conception : MCP gère la couche outils, A2A la couche agents. Plusieurs acteurs travaillent à les intégrer dans une pile unifiée où un agent utilise MCP pour ses outils et A2A pour dialoguer avec d'autres agents. La feuille de route MCP prévoit d'ailleurs, pour le second semestre 2026, une maturation du fonctionnement sans état, de la découverte automatique via des Server Cards et de la coordination avec A2A.

Deuxième tendance, la standardisation formelle, désormais bien engagée. MCP et A2A ne sont plus de simples standards de fait portés par des entreprises : ils sont sous la gouvernance neutre de la Linux Foundation. A2A y est entré en juin 2025 sous licence Apache 2.0. MCP a suivi en décembre 2025, avec la création de l'Agentic AI Foundation co-fondée par Anthropic, Block et OpenAI, et soutenue par Google, Microsoft, AWS, Cloudflare et Bloomberg. Cette légitimité institutionnelle accélère l'adoption par les secteurs les plus exigeants en traçabilité.

Troisième tendance, les protocoles sectoriels. Au-delà des standards génériques, des conventions spécifiques émergent — santé, finance — qui s'appuient sur MCP ou A2A comme couche de transport en y ajoutant leurs contraintes propres. Cette diversité crée un besoin de passerelles inter-protocoles : des composants qui traduisent les messages d'un protocole à l'autre, un motif familier à quiconque a travaillé avec des passerelles d'interfaces dans le monde des microservices. La recherche accompagne le mouvement : les travaux de synthèse récents recensent plusieurs protocoles concurrents (MCP, A2A, ACP, ANP et d'autres) et soulignent un enjeu de rationalisation, ces standards se recoupant parfois sur des fonctions comme la découverte d'agents ou la gestion du contexte.

La vision qui se dessine pour 2028 est celle d'un écosystème d'agents interopérables, auditables et composables : des agents de différents fournisseurs, bâtis avec différents modèles, déployés sur différentes infrastructures, capables de se découvrir via leurs Agent Cards, de collaborer via des protocoles standardisés et de rendre compte de chaque décision via des traces normées. C'est l'équivalent, pour les agents, de ce que le web a accompli pour les documents : un espace ouvert de collaboration bâti sur des standards partagés. Pour les équipes qui construisent aujourd'hui, le conseil le plus actionnable tient en une phrase : commencez par les protocoles, pas par les frameworks. Exposez vos outils via MCP, décrivez vos agents via des Agent Cards, structurez vos appels selon des schémas JSON. Le framework peut changer ; les protocoles, eux, sont conçus pour durer.

Conclusion

Résumons. Les agents IA communiquent en 2026 via trois protocoles complémentaires : MCP pour la couche outils, A2A pour la couche agents, et le function calling pour la couche fonctions. Ces protocoles s'empilent comme les couches d'un modèle réseau, chacun adressant un niveau spécifique. Les agents s'organisent selon trois schémas — orchestration centralisée, chorégraphie décentralisée, délégation hiérarchique — choisis en fonction du nombre d'agents, du couplage des tâches et des exigences de traçabilité. Les embeddings et les mémoires vectorielles partagées ajoutent une couche de compréhension implicite qui complète les protocoles explicites.

Le « langage secret des IA » relève du raccourci. La réalité est un ensemble d'ingénierie transparent et auditable, construit sur des formats standards — JSON, HTTP, JSON-RPC — et des outils d'observabilité matures. Chaque message échangé entre agents est structuré, journalisé et traçable. Ce qui est remarquable, c'est la vitesse de maturation : en un an, deux protocoles portés par des concurrents directs sont passés sous gouvernance ouverte, adoptés par des dizaines de milliers de développeurs et des centaines d'organisations. La convergence MCP + A2A dessine un avenir où les agents seront aussi interopérables que les services web le sont aujourd'hui — un réseau ouvert de capacités composables, au service de la productivité humaine, conçu pour la confiance, la transparence et la collaboration.

Sources

• Model Context Protocol — Spécification officielle (version 2025-11-25)
• Anthropic — Donation de MCP et création de l'Agentic AI Foundation (décembre 2025)
• Agent2Agent (A2A) — Spécification officielle du protocole
• Google Developers — Annonce du protocole Agent2Agent (avril 2025)
• Linux Foundation — Lancement du projet Agent2Agent Protocol (juin 2025)
• Wikipedia — Model Context Protocol (architecture et historique)
• arXiv 2502.14321 — Beyond Self-Talk : A Communication-Centric Survey of LLM-Based Multi-Agent Systems
• arXiv 2501.06322 — Multi-Agent Collaboration Mechanisms : A Survey of LLMs
• EU AI Act — Article 50 : obligations de transparence (Règlement UE 2024/1689)
• TechCrunch — Gibberlink et le mode de communication acoustique GGWave (mars 2025)