MCP, A2A, function calling, RAG : architecture des agents IA expliquée

Vous évaluez la stack agents IA de votre organisation, et vous tombez sur quatre acronymes qui reviennent partout : MCP, A2A, function calling, RAG. Chacun est présenté par son éditeur comme la brique fondamentale qui résout LE problème. La vérité est plus nuancée : ces quatre protocoles et patterns ne sont pas en compétition. Ils résolvent quatre problèmes distincts dans la chaîne agent IA, et la maturité 2026 vient précisément de leur articulation cohérente. Ce pilier vous donne la vision systémique de l’architecture moderne des agents IA en entreprise, sans rentrer dans le détail d’implémentation outil par outil (chaque brique a son article dédié dans ce cluster).

Les 4 briques en une phrase chacune

• MCP (Model Context Protocol) : protocole standard pour connecter un agent IA à des outils et données externes : résout le problème N×M d’intégration.
• A2A (Agent2Agent) : protocole standard pour faire communiquer des agents IA entre eux : résout le problème de coordination multi-agents.
• Function calling : mécanique technique qui permet à un LLM d’invoquer des fonctions externes structurées : c’est la primitive sur laquelle tout repose.
• RAG (Retrieval-Augmented Generation) : pattern d’architecture qui ancre les réponses du LLM dans une base documentaire externe : résout le problème de connaissance et de fraîcheur.

Si vous voulez une lecture rapide, sautez directement à la section « Comment ces 4 briques s’imbriquent ».

Le problème central : pourquoi vos agents IA ont besoin d’une architecture

Un LLM seul ne fait rien. Il génère du texte à partir d’un prompt et s’arrête. Un agent IA, lui, agit dans le monde réel : il lit votre base CRM, écrit dans votre système de tickets, déclenche des workflows, échange avec d’autres agents. Cette capacité à agir ne sort pas magiquement du modèle. Elle vient d’une architecture qui orchestre quatre choses :

1. Donner au LLM la capacité technique de déclencher des actions (function calling)
2. Lui donner accès à vos outils et données métier de façon standardisée (MCP)
3. Le faire communiquer avec d’autres agents quand le problème est trop complexe pour un seul (A2A)
4. L’ancrer dans une base de connaissances fraîche pour éviter les hallucinations (RAG)

Avant 2024, chacun de ces points faisait l’objet de bricolages propriétaires. Chaque éditeur de framework, chaque modèle, chaque plateforme avait sa propre façon de faire. Le résultat : un problème dit N×M. Avec N modèles d’IA et M outils business, il fallait construire N × M intégrations sur mesure. Pour une organisation avec 5 modèles et 50 outils, ce sont 250 intégrations à maintenir.

Selon Anthropic Engineering (octobre 2025), « connecter des agents aux outils et aux données nécessitait traditionnellement une intégration sur mesure pour chaque paire, créant fragmentation et duplication d’efforts rendant difficile la mise à l’échelle de systèmes vraiment connectés ».

2025 a marqué la rupture. Anthropic a publié MCP en novembre 2024. Google a publié A2A en avril 2025. Ces deux protocoles ont été conçus pour s’articuler, pas pour se concurrencer. Et en décembre 2025, les deux ont été transférés à la Linux Foundation pour gouvernance neutre. C’est la fin du Far West et le début d’une vraie architecture de référence.

Brique 1 : Function calling, la primitive technique

Le function calling est la mécanique de base sur laquelle tout repose. Sans function calling, il n’y a pas d’agent IA, seulement un chatbot.

Comment ça marche

Quand vous interagissez avec ChatGPT, Claude ou Mistral, le modèle peut, en plus de générer du texte, structurer son output sous forme d’appels à des fonctions externes que votre application a déclarées. L’application exécute ces fonctions, renvoie le résultat au modèle, qui peut alors continuer son raisonnement.

Exemple simplifié : vous demandez à un agent « Quel est le prix de l’action Mistral en bourse ? ». Le LLM ne connaît pas cette information (donnée temps réel). Mais s’il a accès à une fonction getStockPrice(symbol) que vous avez déclarée, il génère un output structuré du type {"function": "getStockPrice", "arguments": {"symbol": "MISTR"}}. Votre code exécute la fonction, récupère la valeur (ex: 47,23 €), la renvoie au LLM, et celui-ci formule la réponse finale en langage naturel.

Selon OpenAI officiel, c’est cette mécanique qui transforme un LLM passif en agent actif. Tous les modèles modernes la supportent : GPT-5.5, Claude Opus 4.7 et Sonnet 4.6, Gemini 3.1 Pro, Mistral Large 3, DeepSeek V4-Pro, Llama 4. La syntaxe diffère légèrement, mais le principe est identique.

Les enjeux 2026 du function calling

Trois enjeux majeurs structurent l’évolution actuelle :

Fiabilité du tool calling. Les premiers function callings (2023-2024) souffraient d’erreurs fréquentes : mauvais paramètres, hallucinations de noms de fonctions, échecs silencieux. En 2026, les modèles de pointe atteignent des taux d’erreur très bas. Selon Anthropic (avril 2026), « Opus 4.7 a divisé par trois les erreurs de tool calling par rapport à Opus 4.6 ».

Parallélisme. Un agent moderne ne fait pas un seul appel à la fois. Il peut invoquer 5 ou 10 fonctions en parallèle pour optimiser la latence. Tous les principaux fournisseurs supportent désormais le parallel function calling.

Saturation du contexte. Quand un agent a accès à 50 ou 100 outils, leurs définitions consomment beaucoup de tokens dans le contexte. Anthropic propose Tool Search pour charger dynamiquement uniquement les outils pertinents, une optimisation qui réduit la consommation de 150 000 tokens à 2 000 sur les agents très outillés (gain de 98,7%).

Pour le détail technique avec exemples de code, voir notre article dédié sur le function calling et tool use (à venir).

Brique 2 : MCP (Model Context Protocol), le standard d’intégration

MCP standardise la façon dont un agent IA accède aux outils et données externes.

L’origine et le contexte

MCP a été annoncé par Anthropic le 25 novembre 2024. Selon Anthropic officiel, « le Model Context Protocol est un standard ouvert qui permet aux développeurs de construire des connexions sécurisées et bidirectionnelles entre leurs sources de données et leurs outils alimentés par IA ».

Le protocole est souvent comparé à un « USB-C de l’IA » : une interface universelle qui remplace la multitude de connecteurs sur mesure. La comparaison vient des concepteurs eux-mêmes : David Soria Parra et Justin Spahr-Summers, ingénieurs Anthropic.

Selon Wikipédia (mise à jour mai 2026), « depuis son lancement, le MCP a reçu le soutien de plusieurs acteurs majeurs du domaine, notamment OpenAI et Google DeepMind, qui ont annoncé son adoption au sein de leurs plateformes respectives en 2025. En décembre 2025, Anthropic cède le standard MCP à la Agentic AI Foundation, une nouvelle entité dédiée au développement de projets IA open source et gérée par la Fondation Linux ».

Architecture client-serveur

Selon la spécification officielle MCP, l’architecture comporte trois rôles :

• Hôte (Host) : l’application IA qui consomme les capacités MCP. Exemple : Claude Desktop, ChatGPT, Cursor.
• Client MCP : composant dans l’hôte qui gère la connexion à un serveur MCP.
• Serveur MCP : service qui expose des outils, ressources et prompts à l’agent.

Le protocole expose trois primitives :

1. Tools (outils) : fonctions exécutables côté serveur (ex: créer un ticket Jira, envoyer un email)
2. Resources (ressources) : données accessibles côté serveur (ex: fichiers, bases de connaissances)
3. Prompts : modèles de requêtes prédéfinies

L’adoption en 2026

Selon Anthropic (octobre 2025), « depuis le lancement de MCP en novembre 2024, l’adoption a été rapide : la communauté a construit des milliers de serveurs MCP, les SDK sont disponibles dans tous les langages de programmation majeurs, et l’industrie a adopté MCP comme standard de fait pour connecter les agents aux outils et aux données ».

Quelques jalons majeurs :

• OpenAI annonce le support natif MCP dans son Agents SDK (2025)
• Microsoft intègre MCP dans Copilot Studio (2025)
• Google annonce le support MCP dans Gemini (avril 2025, parallèlement à A2A)
• Anthropic transfère le projet à la Linux Foundation (décembre 2025) via la Agentic AI Foundation

Pour le détail complet de MCP avec création d’un serveur, voir notre article dédié sur MCP, le standard universel des agents IA (à venir). Pour l’implémentation pratique chez un fournisseur d’outils, voir notre guide sur Zapier Agents et MCP qui détaille la passerelle Zapier vers 9 000 apps.

Brique 3 : A2A (Agent2Agent), la communication entre agents

A2A standardise comment les agents IA discutent entre eux, là où MCP standardise comment un agent discute avec des outils.

L’origine et le contexte

A2A a été annoncé par Google le 9 avril 2025 au Google Cloud Next. Selon Google Developers Blog (avril 2025), « A2A est un protocole ouvert qui complète le Model Context Protocol d’Anthropic, lequel fournit des outils et du contexte aux agents. En s’appuyant sur l’expertise interne de Google dans la mise à l’échelle de systèmes agentiques, nous avons conçu le protocole A2A pour répondre aux défis identifiés dans le déploiement de systèmes multi-agents à grande échelle pour nos clients ».

Le positionnement est explicite. Selon InfoQ (avril 2025), « la documentation de Google souligne que A2A résout un problème différent de MCP : il permet aux agents de communiquer comme agents (ou comme utilisateurs) plutôt que comme outils. La différence entre un outil et un agent est qu’un outil a une I/O et un comportement structurés, tandis qu’un agent est autonome et peut résoudre de nouvelles tâches via du raisonnement ».

Selon Atlan (avril 2026), « A2A a été lancé en avril 2025 avec plus de 50 partenaires technologiques. En avril 2026, ce nombre est passé à plus de 150 organisations. Le dépôt GitHub A2A a dépassé les 22 000 étoiles, et l’écosystème SDK est passé d’une seule implémentation Python à cinq langages production-ready : Python, JavaScript, Java, Go et .NET ».

En juin 2025, selon Wikipédia (mai 2026), « Google a transféré le protocole, sa spécification, et les SDK associés à la Linux Foundation. La Linux Foundation a établi le projet Agent2Agent pour fournir une gouvernance neutre vis-à-vis des fournisseurs ».

Architecture client-remote

Selon Galileo (janvier 2026), « A2A utilise des mécanismes de découverte standardisés via des Agent Cards, un système de gestion de tâches structuré avec des états de cycle de vie définis, et une sécurité enterprise incluant le support OAuth 2.0, des API Keys, et mTLS, le tout construit sur des technologies web familières (HTTP/HTTPS, JSON-RPC 2.0) ».

Concrètement, le protocole fonctionne avec :

• Agent Cards : documents de métadonnées qui décrivent les capacités d’un agent et comment y accéder
• Client agent : agent qui identifie une tâche à déléguer
• Remote agent : agent qui exécute la tâche pour le compte du client
• Tâches avec états de cycle de vie : pending, in-progress, completed, failed

Aucun agent n’a besoin d’exposer sa logique interne, sa mémoire ou ses détails d’implémentation pour collaborer avec un autre.

Cas d’usage typiques

L’utilité d’A2A apparaît dès que votre organisation déploie des agents de plusieurs fournisseurs ou frameworks. Exemples :

• Salesforce : agents commerciaux qui collaborent avec des agents marketing d’un autre fournisseur
• ServiceNow : agents IT operations qui coordonnent avec des agents d’autres équipes (interopérabilité standard)
• Workday : agents RH et finance qui collaborent sur des workflows transverses

Pour le détail complet d’A2A avec architecture et code, voir notre article dédié A2A : comment les agents IA communiquent entre eux (à venir).

Brique 4 : RAG (Retrieval-Augmented Generation), l’ancrage documentaire

RAG est différent des 3 briques précédentes : ce n’est pas un protocole, c’est un pattern d’architecture. Il consiste à enrichir le contexte d’un LLM avec des documents pertinents extraits d’une base de connaissances externe, juste avant de générer la réponse.

Le problème que résout RAG

Un LLM a deux limitations structurelles sur la connaissance :

1. Connaissance figée à la date de cutoff de l’entraînement (mai 2026 pour les modèles les plus récents)
2. Ne connaît pas vos données propriétaires (procédures internes, base client, documentation produit privée)

Sans RAG, ces limitations conduisent à des hallucinations : le modèle invente des informations plausibles mais fausses. RAG corrige cela en injectant les documents factuels pertinents dans le contexte.

Architecture RAG en 4 étapes

Le pattern standard fonctionne en 4 étapes :

Étape 1 : Indexation (préalable, une fois). Vos documents sont découpés en chunks (typiquement 500-1 500 tokens), convertis en embeddings vectoriels par un modèle d’embedding (ex: Mistral Embed, OpenAI text-embedding-3, Cohere embed-v3), et stockés dans une base vectorielle (Qdrant, Weaviate, Pinecone, pgvector).

Étape 2 : Recherche (à chaque requête). La requête de l’utilisateur est convertie en embedding via le même modèle, puis comparée à tous les embeddings de la base pour trouver les chunks sémantiquement les plus proches (typiquement top 3 à 10).

Étape 3 : Augmentation (à chaque requête). Les chunks pertinents sont injectés dans le prompt envoyé au LLM, accompagnés de la requête originale.

Étape 4 : Génération (à chaque requête). Le LLM génère sa réponse en s’appuyant sur les chunks fournis, et non plus uniquement sur sa connaissance interne.

Les enjeux 2026 du RAG

Le RAG classique de 2023-2024 atteint ses limites sur plusieurs dimensions, et 2026 voit émerger des patterns plus matures :

Hybrid search : combiner recherche vectorielle (sémantique) et recherche lexicale (BM25) pour ne pas rater les correspondances exactes (noms propres, références techniques, codes produits).

Re-ranking : après la recherche initiale, repasser les résultats dans un modèle de re-ranking spécialisé (ex: Cohere Rerank) pour affiner la pertinence avant injection dans le prompt.

Query expansion : reformuler la requête utilisateur en plusieurs variations avant de rechercher, pour augmenter le rappel.

GraphRAG : remplacer la base vectorielle par un graphe de connaissances pour gérer les questions multi-hop (qui nécessitent plusieurs sauts entre entités). Voir notre comparatif GraphRAG vs RAG classique (à venir).

Contextual Retrieval : pattern Anthropic qui ajoute du contexte à chaque chunk avant indexation, améliorant le rappel de 49% selon les benchmarks éditeur.

Pour le détail complet du RAG avec patterns avancés et métriques d’évaluation, voir notre article dédié RAG expliqué simplement (à venir).

Comment ces 4 briques s’imbriquent dans une architecture complète

Voilà où la vision systémique fait la différence. Un agent IA mature en production combine les 4 briques.

Lisons l’architecture de haut en bas avec un cas concret : un agent commercial qui prépare un appel client en autonomie.

Couche A2A, Coordination : votre agent commercial reçoit la demande « Préparer le RDV avec ACME demain à 14h ». Il identifie deux sous-tâches qu’il délègue à d’autres agents via A2A : un agent recherche concurrence (autre fournisseur, autre framework) et un agent analyse historique relation client (interne, framework différent).

Couche Agent (function calling) : votre agent principal, propulsé par Claude Sonnet 4.6 ou GPT-5.5, raisonne sur la séquence d’actions à mener. Il utilise le function calling pour déclencher des appels structurés vers les outils nécessaires.

Couche MCP, Outils et données : pour récupérer les informations CRM sur ACME, l’agent ne dialogue pas directement avec Salesforce via une intégration sur mesure. Il appelle un serveur MCP Salesforce qui expose des outils standardisés (getAccount, getOpportunities, getRecentActivity). Le serveur MCP fait l’intermédiaire et masque la complexité de l’API Salesforce.

Couche RAG, Connaissance : pour récupérer le contexte produit utile (caractéristiques techniques, cas d’usage, références similaires), l’agent interroge votre base de connaissances vectorielle. Les 5 chunks les plus proches sont retrouvés, re-classés par un modèle de re-ranking, puis injectés dans le prompt final pour générer la fiche de préparation.

Couche infrastructure : Salesforce, Jira, Slack, Google Drive, Qdrant, Weaviate, votre data warehouse. Cette couche n’a pas changé fondamentalement avec les agents IA. Ce qui a changé, c’est la façon dont l’agent y accède : protocole standardisé (MCP) au lieu d’intégrations sur mesure.

Pourquoi cette architecture compte pour votre stratégie agents IA

Trois implications business directes de cette architecture en 4 couches.

Implication 1 : la portabilité change vos arbitrages fournisseurs

Avant 2025, choisir un agent IA, c’était choisir un écosystème verrouillé. Si vous démarriez avec OpenAI Agents SDK, migrer vers Claude ou Mistral demandait de tout réécrire. Avec MCP et A2A standardisés, les outils et les agents deviennent portables. Vous pouvez démarrer avec un fournisseur, basculer sur un autre, faire cohabiter plusieurs, sans réécrire votre couche MCP.

Conséquence : la stratégie multi-modèles devient économiquement et techniquement viable pour les grands groupes. Vous gardez la même couche d’outils MCP et de bases RAG, et vous routez les requêtes vers le LLM optimal selon le cas d’usage. C’est précisément le sujet de notre pilier sur le choix d’un LLM pour vos agents IA.

Implication 2 : la gouvernance se centralise sur la couche MCP

Pour un grand groupe avec 1 000+ collaborateurs et des dizaines d’agents en production, la couche MCP devient le point de gouvernance unique : qui accède à quels outils, avec quelles permissions, avec quel audit. Au lieu de gouverner 250 intégrations (problème N×M), vous gouvernez 50 serveurs MCP. C’est un changement structurel pour les DSI.

Selon la spécification MCP elle-même : « Le MCP permet des capacités puissantes via un accès arbitraire aux données et des chemins d’exécution de code. Avec cette puissance viennent d’importantes considérations de sécurité et de confiance que tous les implémenteurs doivent traiter avec soin ». Les hôtes doivent obtenir le consentement explicite de l’utilisateur avant d’invoquer tout outil. La primitive de sécurité est intégrée au protocole.

Implication 3 : le RAG devient une infrastructure stratégique, pas un projet ponctuel

Avant 2025, beaucoup d’organisations ont fait du RAG comme un POC : une base vectorielle dédiée à un cas d’usage particulier. En 2026, le RAG devient une plateforme transverse : une seule base vectorielle qui sert tous les agents de l’organisation, avec gouvernance des accès, mises à jour automatisées, monitoring de la qualité.

Pour les grands groupes, cela implique des investissements infrastructure significatifs : choisir sa base vectorielle de référence (Qdrant Enterprise, Weaviate Cloud, ou self-host pgvector), structurer ses pipelines d’indexation, mesurer la qualité (taux de rappel, précision, hallucinations résiduelles).

Comment démarrer : 5 étapes pour structurer votre architecture agents IA

Pour un grand groupe qui veut industrialiser ses agents IA en 2026, voici la séquence de mise en place rationnelle.

Étape 1 : Cartographier vos outils métier candidats à l’agentification. Listez les 10-20 outils que vos agents IA devront manipuler en priorité (CRM, ERP, ITSM, communications internes, gestion documentaire). Pour chacun, identifier s’il existe déjà un serveur MCP officiel ou communautaire. Le registre MCP officiel recense les serveurs disponibles.

Étape 2 : Définir votre stratégie LLM multi-modèles. Quel(s) LLM pour quels cas d’usage ? Notre matrice de décision LLM pour agents IA vous donne le cadre. La portabilité MCP vous permet de changer d’avis dans 6 mois sans réécrire votre stack.

Étape 3 : Construire votre couche RAG transverse. Choisissez votre base vectorielle, votre modèle d’embedding, votre pattern (RAG simple, hybrid search, GraphRAG selon vos cas). Commencez par 2-3 bases documentaires prioritaires (procédures internes, base produit, base client) avant d’étendre.

Étape 4 : Implémenter les serveurs MCP manquants. Pour vos outils internes qui n’ont pas de serveur MCP officiel, développez-les ou faites-les développer. C’est une compétence à internaliser sur la durée. La spec officielle MCP et les SDK officiels en Python, TypeScript, Java, C#, Go, Rust facilitent ce développement.

Étape 5 : Penser A2A pour la coordination multi-agents. Pour les workflows transverses qui impliquent plusieurs domaines fonctionnels (commerce + marketing + finance), envisagez A2A pour orchestrer la collaboration sans coupler fortement vos agents.

Pour structurer cette démarche dans votre organisation, accompagner votre transformation par les agents IA avec Proactive Academy permet d’aller de la vision aux premières mises en production. Notre parcours couvre les 5 étapes ci-dessus avec adaptation à votre contexte sectoriel et votre maturité actuelle.

FAQ : architecture des agents IA en 2026

L’architecture moderne des agents IA en 2026 repose sur quatre briques articulées, pas concurrentes : function calling comme primitive technique, MCP pour les outils, A2A pour les agents entre eux, RAG pour la connaissance. La maturité 2026 vient de leur standardisation sous gouvernance neutre (Linux Foundation pour MCP et A2A), qui transforme ce qui était il y a 18 mois un Far West technologique en architecture stable et portable. Pour les grands groupes qui industrialisent leurs agents IA, comprendre comment ces 4 couches s’imbriquent est désormais une compétence DSI de premier rang, celle qui sépare les organisations qui scalent leur IA des autres. Si vous voulez aller plus profondément sur chaque brique, les 5 articles enfants de ce cluster détaillent MCP, A2A, function calling, RAG et GraphRAG avec rigueur technique. Et si vous voulez structurer cette démarche dans votre propre organisation avec accompagnement, notre formation pour décideurs IT sur les agents IA inclut la construction de votre architecture cible avec un parcours Qualiopi mobilisable sur votre plan de formation.