Qu’est-ce que le protocole A2A ? Les cartes d’agent et les tâches expliquées

Le protocole A2A, sigle d’Agent2Agent Protocol, est une norme ouverte pour la communication entre des systèmes d’agents IA indépendants.

Cette phrase semble simple, mais elle implique quelque chose que la plupart des démonstrations d’agents IA ignorent complètement. La plupart des démos supposent encore un seul assistant, un seul runtime, une seule boucle d’outils et un seul propriétaire — l’agent peut rechercher, appeler des outils, écrire du code, interroger des API, peut-être utiliser des serveurs MCP, et retourner une réponse.

A2A est conçu pour un monde différent, où les agents peuvent être construits par différentes équipes, frameworks, fournisseurs, langages ou organisations. Il suppose qu’un agent peut avoir besoin de découvrir un autre agent, comprendre ce qu’il peut faire, lui envoyer du travail, échanger des messages, recevoir des fichiers ou des sorties structurées, et suivre une tâche jusqu’à sa complétion — ce qui en fait non pas juste un autre format d’appel d’outil, mais une tentative genuine de rendre les agents IA interopérables en tant que pairs.

Les concepts fondamentaux sont :

• Fiches d’agent (Agent Cards)
• Agents et clients
• Tâches
• Messages
• Parties (Parts)
• Artefacts
• États des tâches
• Diffusion en continu (streaming) et mises à jour asynchrones

Cet article explique ces concepts en termes d’ingénierie simples, avec suffisamment de détails pour comprendre où A2A s’insère dans les systèmes multi-agents réels.

La définition courte

A2A est un protocole de communication agent-à-agent.

Il permet à un agent ou à un client de communiquer avec un autre agent à travers un modèle commun. L’agent récepteur peut décrire ses capacités, accepter du travail, gérer le cycle de vie de ce travail, demander plus d’entrées, diffuser les progrès et retourner des sorties concrètes.

L’objectif n’est pas de standardiser la façon dont un agent pense en interne — il s’agit de standardiser la façon dont les agents communiquent à leurs frontières.

Un agent A2A pourrait utiliser en interne :

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• du code personnalisé
• des serveurs MCP
• des API privées
• des bases de données vectorielles
• des moteurs de workflow

L’appelant n’a pas besoin de connaître tout cela. Ce dont l’appelant a besoin est :

• Que peut faire cet agent ?
• Comment communiquer avec lui ?
• Quelles entrées accepte-t-il ?
• Quelles sorties peut-il produire ?
• Comment suivre le travail ?
• Comment recevoir le résultat ?

Ces six questions définissent la frontière du protocole que A2A tente d’établir entre des agents fonctionnant de manière indépendante.

Pourquoi A2A existe

Les systèmes IA passent d’assistants uniques à des réseaux d’agents spécialisés.

Une entreprise pourrait avoir :

• Un agent de support
• Un agent de facturation
• Un agent de révision juridique
• Un agent DevOps
• Un agent d’analyse de données
• Un agent de recherche
• Un agent de documentation
• Un agent de revue de code

Chaque agent peut avoir ses propres outils, permissions, connaissances de domaine, prompts, mémoire, système de récupération et règles d’audit.

Sans protocole partagé, chaque intégration devient sur mesure — l’agent de support a besoin d’un câblage spécifique vers l’agent de facturation, l’agent de facturation a besoin du sien vers l’agent juridique, et l’agent de recherche en a besoin d’un autre vers l’agent de documentation. Cette surcharge combinatoire ne scale pas bien au fur et à mesure que le réseau d’agents grandit.

A2A donne à ces agents un moyen commun d’interagir, réduisant le problème d’intégration N×M à un seul contrat partagé. La promesse n’est pas une autonomie magique ; la promesse est l’interopérabilité.

A2A n’est pas MCP

A2A est souvent comparé à MCP, mais ils résolvent des problèmes différents.

MCP, ou Model Context Protocol, concerne principalement la connexion d’une application ou d’un agent IA à des outils, ressources et prompts, tandis qu’A2A concerne principalement la connexion d’agents à d’autres agents.

Un modèle mental utile est :

MCP : agent vers outil
A2A : agent vers agent

Par exemple, un agent peut utiliser MCP pour accéder à :

• GitHub
• un système de fichiers
• une base de données
• Slack
• un système de recherche de documentation
• une API cloud

Des guides pratiques pour construire ces serveurs MCP sont disponibles pour Go et [Python](https://www.glukhov.org/fr/ai-systems/mcp/mcp-server-in-python/ “Un guide complet pour l’implémentation de serveurs Model Context Protocol (MCP) en Python avec des exemples pratiques pour les capacités de recherche web et de scraping, permettant une intégration transparente des outils IA.

Le même agent peut utiliser A2A pour déléguer du travail à :

• un agent de revue de sécurité
• un agent de recherche
• une agent de planification
• un agent de conformité
• un agent de codage

Les deux protocoles peuvent et font souvent travailler ensemble. Une architecture propre est souvent :

A2A à l'extérieur de la frontière de l'agent.
MCP à l'intérieur de la frontière de l'agent.

Cela signifie que les autres agents communiquent avec votre agent en utilisant A2A, tandis que votre agent utilise MCP en interne pour accéder aux outils — une séparation claire des préoccupations qui maintient l’interface externe stable quel que soit ce qui change à l’intérieur. Pour une comparaison détaillée de la façon dont les deux protocoles divisent la responsabilité architecturale et de quand vous avez réellement besoin des deux, consultez A2A vs MCP : Les agents IA ont-ils vraiment besoin des deux protocoles ?

Rôles principaux dans A2A

A2A utilise un modèle de rôle simple construit autour de deux parties : un agent qui expose des capacités, et un client qui souhaite les utiliser.

Le client peut être :

• un autre agent
• un orchestrateur
• une application d’assistant
• un système de workflow
• un passerelle (gateway)
• un banc d’essai (test harness)
• une application face à l’utilisateur

L’agent peut être :

• un service IA spécialisé
• un assistant de domaine
• un agent propriétaire d’un workflow
• un agent de fournisseur distant
• un agent d’entreprise interne

Le point important est que l’agent n’est pas juste une fonction. Il possède une certaine capacité et l’expose à travers une interface d’agent.

Fiches d’agent (Agent Cards)

La Fiche d’agent est l’un des concepts les plus importants dans A2A.

Une Fiche d’agent décrit un agent — c’est le document de découverte qui indique aux clients ce qu’est l’agent, ce qu’il peut faire, comment communiquer avec lui et quelles contraintes s’appliquent.

Considérez une Fiche d’agent comme un mélange de :

• métadonnées de service
• déclaration de capacités
• document de découverte d’API
• profil d’agent
• surface de contrat

Une Fiche d’agent typique peut décrire des éléments tels que :

• nom de l’agent
• description
• point de terminaison du service (endpoint)
• fonctionnalités de protocole prises en charge
• modes d’entrée et de sortie pris en charge
• compétences disponibles
• exigences d’authentification
• informations sur le fournisseur
• informations de version
• liens de documentation
• métadonnées optionnelles

La Fiche d’agent est importante car les agents ne devraient pas avoir besoin d’une connaissance codée en dur de chaque autre agent.

Un client peut inspecter la fiche et décider :

• Est-ce le bon agent pour le travail ?
• Supporte-t-il le type de contenu dont j’ai besoin ?
• Supporte-t-il le streaming ?
• Exige-t-il une authentification ?
• Quelles compétences annonce-t-il ?
• Peut-il retourner le type d’artefact dont j’ai besoin ?

Dans les systèmes pratiques, les Fiches d’agent deviennent la fondation pour les registres d’agents, les portails développeurs et les catalogues d’agents internes — l’équivalent lisible par machine d’un annuaire de services où les clients peuvent rechercher ce qui est disponible avant de s’engager dans une intégration.

Les Fiches d’agent sont des frontières de capacités

Une Fiche d’agent ne devrait pas être traitée comme du texte marketing — c’est une frontière de capacités sur laquelle d’autres systèmes compteront à l’exécution.

Si votre fiche d’agent dit que votre agent peut effectuer une analyse financière, les clients commenceront à lui déléguer du travail d’analyse financière. Si elle dit que l’agent accepte des fichiers, les clients peuvent envoyer des fichiers. Si elle dit que l’agent prend en charge le streaming, les clients peuvent s’attendre à des événements de progression.

De mauvaises Fiches d’agent créent de mauvais systèmes car les décisions de routage et les hypothèses de capacités se propagent dans tout le réseau d’agents. Une Fiche d’agent utile devrait être :

• spécifique
• précise
• stable
• versionnée
• consciente de la sécurité
• honnête sur ses limitations

Une compétence vague comme “fait des tâches commerciales” n’est pas utile.

Une meilleure compétence est :

Analyser les données de facturation SaaS et produire un récapitulatif des dépenses mensuelles.

Encore mieux, inclure les modes d’entrée et de sortie attendus.

Entrée : Enregistrements de facturation CSV ou JSON.
Sortie : Résumé Markdown et totaux JSON structurés.

Plus la Fiche d’agent est précise, plus il est facile pour les autres agents de router les tâches correctement.

Découverte d’agents

La découverte d’agents est le processus de recherche d’une Fiche d’agent.

Dans les déploiements simples, la découverte peut être statique. Un client connaît déjà l’URL d’un agent spécifique.

Dans les déploiements plus larges, la découverte peut impliquer :

• un registre
• un portail développeur
• un catalogue interne
• une découverte basée sur le DNS
• la gestion de la configuration
• un routage spécifique à l’environnement
• des passerelles conscientes des locataires (tenants)

Le choix de conception important est de savoir si la découverte est publique, privée ou autorisée.

Tous les agents ne devraient pas être découverts par tout le monde — un agent de paie interne ne devrait pas exposer la même Fiche d’agent à chaque appelant, et un agent partenaire peut ne voir que des compétences sûres pour les partenaires. La découverte d’agents n’est pas juste une fonctionnalité de commodité ; elle fait partie de votre modèle de sécurité et de gouvernance, et le périmètre de visibilité est une décision de conception de premier ordre.

Tâches

Une Tâche représente un travail effectué par un agent.

C’est là que A2A devient plus intéressant que les simples API de demande et réponse.

Certaines interactions d’agent sont rapides. Un client envoie un message, et l’agent retourne une réponse directe.

Mais beaucoup de workflows d’agent réels ne sont pas instantanés.

Une tâche peut impliquer :

• la recherche dans plusieurs sources
• la demande de clarification
• l’appel d’outils
• la délégation de travail
• l’attente d’approbation
• la génération d’un rapport
• la production de fichiers
• la diffusion de la progression
• la gestion des retries
• le retour de plusieurs artefacts

A2A modélise ce type de travail comme une Tâche — donnant au travail une identité et un cycle de vie, ce qui est important car le travail d’agent de longue durée doit être suivi, inspecté et potentiellement annulé ou réessayé.

Cycle de vie d’une tâche

Une tâche peut passer par différents états.

Le modèle d’état exact dépend de la version du protocole et de l’implémentation, mais l’idée de base est simple :

• soumis
• en cours de travail
• entrée requise
• complété
• échoué
• annulé
• rejeté

Le point important est qu’une tâche n’est pas juste une charge utile de réponse — c’est une unité de travail en cours avec son propre état qu’un client peut interroger à tout moment. Un client peut utiliser l’état de la tâche pour comprendre ce qui se passe :

• L’agent a-t-il accepté la tâche ?
• Travaille-t-il encore ?
• A-t-il besoin de plus d’entrées ?
• A-t-il fini avec succès ?
• A-t-il échoué ?
• A-t-il été annulé ?
• Y a-t-il des artefacts disponibles ?

Cela est particulièrement utile pour les workflows qui prennent des secondes, des minutes ou plus.

Par exemple, un agent de recherche peut retourner une tâche immédiatement, puis continuer à travailler en arrière-plan tout en diffusant des événements de progression ou en rendant le résultat disponible plus tard.

Message sans état ou Tâche avec état

A2A prend en charge les interactions simples et complexes.

Pour une interaction simple, un agent peut retourner un Message direct ; pour une interaction complexe, il peut retourner une Tâche. Cette distinction est importante car tout n’a pas besoin d’un suivi de tâche, et sur-ingénierier de courtes interactions en workflows de tâches complets ajoute une surcharge inutile.

Si un client demande :

Résumez ce paragraphe.

Une réponse directe peut suffire.

Si un client demande :

Recherchez les cinq principales bases de données vectorielles open source, comparez-les et produisez une recommandation de migration.

Une tâche est plus appropriée.

La règle pratique est simple : utilisez un Message direct pour les interactions simples et immédiates, et utilisez une Tâche pour le travail de longue durée, avec état, auditable ou produisant des artefacts.

Messages

Les Messages sont les unités de communication échangées entre le client et l’agent.

Un message peut contenir une ou plusieurs parties.

Un message peut représenter :

• une demande utilisateur
• une réponse d’agent
• une question de clarification
• des entrées supplémentaires
• une communication liée à la tâche
• un contexte de progression
• des instructions structurées

Les messages ne sont pas juste des chaînes de caractères — la communication d’agent a souvent besoin de transporter beaucoup plus que du texte brut, et la structure du message est conçue pour s’adapter à cela.

Un message peut inclure :

• du texte
• des fichiers
• du JSON structuré
• des images
• des références
• des métadonnées

Le message est l’enveloppe ; les parties sont le contenu typé réel à l’intérieur.

Parties (Parts)

Une Partie est un morceau de contenu à l’intérieur d’un message ou d’un artefact.

C’est ainsi que A2A prend en charge la communication multimodale et structurée.

Une partie peut contenir différents types de contenu, tels que :

• du texte
• des données de fichier
• des données structurées
• du contenu binaire par référence
• des données de type JSON

Une partie peut également inclure des métadonnées telles que :

• type média
• nom de fichier
• contexte supplémentaire

Le type média est important car il indique à l’agent récepteur comment interpréter le contenu.

Par exemple :

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

C’est l’un des aspects sous-estimés de A2A. La communication d’agent ne devrait pas tout réduire en texte brut — si un agent en aval a besoin d’un tableur, d’une image, d’une charge JSON, d’un fichier journal ou d’un PDF, le protocole devrait préserver ce contenu comme contenu plutôt que de le déformer en un paragraphe. Les bons systèmes d’agent évitent ces goulots d’étranglement textuels inutiles en permettant à chaque partie de transporter son type média naturel jusqu’au consommateur.

Artefacts

Les Artefacts sont des sorties concrètes produites par un agent pendant le traitement d’une tâche.

Cela diffère d’un message général : un message est une communication entre agents, tandis qu’un artefact est un livrable concret que la tâche a produit.

Les exemples d’artefacts incluent :

• un rapport Markdown
• un résultat d’analyse JSON
• une exportation CSV
• une image générée
• un document PDF
• un patch de code
• un fichier de résultat de test
• un plan de déploiement
• un diagramme
• un extrait de données

Cette distinction est utile en pratique. Quand un agent de recherche dit « J’ai trouvé la réponse », c’est un message. Quand il retourne market-analysis.md, sources.json et risk-summary.csv, ce sont des artefacts — des sorties concrètes qui rendent le travail de la tâche inspectable, réutilisable et composable. L’artefact d’un agent devient l’entrée d’un autre agent sans perte de structure.

Messages vs Artefacts

Une façon simple de le concevoir :

Les Messages sont la conversation.
Les Artefacts sont la sortie.

Les messages aident les agents à coordonner ; les artefacts sont ce que la tâche a réellement produit.

Par exemple, dans un workflow de développement logiciel :

• Le client envoie un message demandant une correction de bug.
• L’agent de codage envoie des messages avec des questions de clarification.
• L’agent de codage travaille sur la tâche.
• L’agent retourne des artefacts tels qu’un fichier patch, une sortie de test et une explication.

Cette séparation est utile car elle évite de mélanger la coordination de tâche avec les livrables, rendant beaucoup plus facile la journalisation, l’audit et le passage des sorties aux consommateurs en aval.

Un exemple pratique

Imaginez qu’un assistant principal a besoin de l’aide d’un agent de documentation.

L’utilisateur demande :

Créez la documentation développeur pour notre nouvelle API webhook de facturation.

L’assistant principal vérifie un registre d’agents et trouve un agent de documentation.

L’agent de documentation a une Fiche d’agent qui dit qu’il peut :

• écrire de la documentation API
• accepter des spécifications OpenAPI
• accepter des guides de style Markdown
• produire des docs Markdown
• produire des exemples en Python et JavaScript
• supporter les tâches de longue durée
• retourner des artefacts

L’assistant principal envoie un message avec :

• une courte instruction
• un fichier OpenAPI
• un guide de style
• des métadonnées sur le public cible

L’agent de documentation crée une Tâche.

La tâche entre dans un état de travail.

L’agent de documentation peut envoyer des messages tels que :

J'extrais les descriptions des points de terminaison.

Puis :

J'ai besoin d'une clarification sur les exemples d'authentification.

L’assistant principal fournit les entrées manquantes.

La tâche continue.

Enfin, l’agent de documentation retourne des artefacts :

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

Voilà le modèle A2A en action : pas juste « appelez cette fonction » mais « déléguez cette tâche à un autre agent, communiquez si nécessaire et suivez le résultat jusqu’à complétion. »

Pourquoi les Tâches comptent pour les systèmes réels

Les Tâches sont ce qui rend A2A adapté aux workflows sérieux.

Un appel d’API HTTP normal est souvent trop mince pour le travail d’agent. Les tâches d’agent peuvent impliquer l’incertitude, plusieurs étapes, des résultats intermédiaires et des questions de suivi.

Une Tâche vous donne un endroit pour attacher :

• le statut
• l’historique
• les messages
• les artefacts
• les erreurs
• les métadonnées
• la progression
• l’annulation
• les informations d’audit

Cela est utile pour :

• les workflows de recherche
• la génération de code
• l’analyse de données
• la revue de conformité
• la production de documents
• l’investigation d’incidents
• la planification multi-étapes
• les workflows d’approbation humaine

Sans un modèle de tâche, les développeurs reconstruisent généralement cette logique eux-mêmes avec des IDs de travail personnalisés, des files d’attente, des points de terminaison de statut et des callbacks webhook — A2A tente de standardiser la version spécifique aux agents de ce modèle pour que vous n’ayez pas à la réinventer pour chaque nouvelle intégration d’agent.

Diffusion en continu et travail asynchrone

A2A prend en charge l’idée que le travail d’agent peut être diffusé en continu ou asynchrone.

Le streaming est utile lorsque le client souhaite des mises à jour en direct.

Par exemple :

• événements de progression
• résultats partiels
• statut intermédiaire
• texte généré
• mises à jour d’étape

Les workflows asynchrones sont utiles lorsque la tâche peut prendre beaucoup de temps ou que le client ne peut pas maintenir une connexion ouverte.

Par exemple :

• recherche en arrière-plan
• génération de gros documents
• revue multi-agent
• traitement de données
• approbation humaine
• analyse par lots

En pratique, un système A2A robuste devrait être conçu autour de trois modes : réponse immédiate pour le travail simple, streaming pour le travail interactif de longue durée, et asynchrone pour le travail de fond durable qui peut survivre à toute connexion unique. Pour SSE, webhooks push, réabonnement, HITL via input_required, gestion des erreurs et checklists de production, consultez A2A Streaming et Tâches Async pour les Workflows d’Agents de Longue Durée.

Fiches d’agent et support du streaming

Une Fiche d’agent peut annoncer si un agent prend en charge le streaming.

Cela est important car les clients ne peuvent pas supposer que chaque agent prend en charge le streaming — certains agents peuvent ne supporter que la simple demande et réponse, certains peuvent supporter le polling de tâches, et d’autres peuvent supporter les notifications push ou les événements envoyés par le serveur. Un bon client inspecte la Fiche d’agent avant de choisir un modèle d’interaction, c’est pourquoi les Fiches d’agent ne sont pas juste de la documentation : elles façonnent directement le comportement à l’exécution.

A2A et agents multimodaux

A2A est conçu pour supporter plus que du texte brut.

Cela est important car les systèmes d’agent réels traitent de plus en plus des entrées et sorties mixtes :

• texte
• images
• audio
• vidéo
• PDFs
• tableurs
• JSON structuré
• journaux
• code
• diagrammes

Si chaque frontière d’agent convertit tout en texte, des informations importantes peuvent être perdues.

Par exemple, un agent de dépannage visuel devrait recevoir une image comme une image, pas comme une description textuelle faible. Un agent financier devrait recevoir des données de tableur structurées, pas un paragraphe copié. Un agent de revue de code devrait recevoir des fichiers source ou des diffs, pas un résumé vague.

Les Parties et les types média sont la façon dont A2A préserve un contenu plus riche à travers les frontières d’agent — et c’est l’un des endroits où le protocole est plus important qu’il n’y paraît, car la perte d’information à la frontière se compense à chaque saut dans une chaîne multi-agents.

A2A n’est pas un framework d’agent

A2A ne vous dit pas comment construire un agent.

Il ne définit pas :

• la stratégie de raisonnement
• l’algorithme de planification
• le système de mémoire
• la base de données vectorielle
• le template de prompt
• le fournisseur de modèle
• le framework d’outils
• le runtime d’orchestration
• la méthode d’évaluation

C’est une fonctionnalité, pas un bug. A2A est un protocole de frontière qui permet à différentes implémentations d’agent de communiquer sans exiger qu’elles partagent la même architecture interne — tout comme HTTP ne vous dit pas comment construire une application web, il définit seulement comment les systèmes communiquent. A2A devrait être compris de la même manière.

A2A n’est pas un remplacement pour les API

A2A ne remplace pas non plus chaque API.

Si vous avez un service déterministe avec un contrat de demande et réponse stable, une API normale peut être meilleure.

Par exemple :

• conversion de devises
• validation d’adresse
• recherche de facture
• redimensionnement d’image
• point de terminaison de recherche
• recherche de drapeau de fonctionnalité
• service CRUD interne

Ceux-ci ne deviennent pas automatiquement des agents juste parce qu’ils sont appelés par un système IA. A2A a du sens lorsque le système distant se comporte réellement comme un agent :

• il possède une tâche
• il peut demander plus d’entrées
• il peut utiliser des outils en interne
• il peut prendre du temps
• il peut produire des artefacts
• il a des capacités qui valent la peine d’être découvertes
• il peut opérer en tant que pair dans un workflow plus large

N’utilisez pas A2A juste parce que c’est à la mode — utilisez-le lorsque l’abstraction correspond réellement au problème.

Où A2A s’insère dans l’architecture des systèmes IA

A2A s’insère le mieux à la frontière entre des agents déployés de manière indépendante.

Une architecture utile pourrait ressembler à ceci :

Utilisateur
  |
  v
Assistant principal
  |
  |-- A2A --> Agent de recherche
  |-- A2A --> Agent de codage
  |-- A2A --> Agent de conformité
  |-- A2A --> Agent de documentation

Chaque agent spécialisé peut utiliser des outils en interne :

Agent de recherche
  |
  |-- MCP --> recherche web
  |-- MCP --> magasin de documents
  |-- MCP --> base de données vectorielle

Cela vous donne des couches séparées :

Couche interface utilisateur
Couche de coordination d'agents
Couche d'intégration d'outils
Couche de données et d'exécution

A2A vit dans la couche de coordination d’agents, MCP vit souvent dans la couche d’intégration d’outils, et les API normales, les files d’attente, les bases de données et les systèmes de stockage vivent en dessous — chaque couche avec sa propre abstraction et ses propres modes de défaillance. Pour une carte transversale de la façon dont l’inférence LLM, la mémoire, le routage, les outils et l’observabilité s’assemblent à l’intérieur des assistants de production, consultez Architecture des Assistants IA : LLM, Mémoire, Outils, Routage, Observabilité.

Modèle d’architecture : Orchestrateur et Spécialistes

Le modèle A2A le plus courant est probablement l’orchestrateur plus les spécialistes.

Dans ce modèle, un agent primaire reçoit la demande utilisateur et délègue des morceaux de travail à des agents spécialisés.

Exemple :

Assistant principal
  |
  |-- A2A --> Agent juridique
  |-- A2A --> Agent financier
  |-- A2A --> Agent de recherche
  |-- A2A --> Agent d'écriture

Ce modèle est facile à comprendre : l’orchestrateur possède le workflow global, et les agents spécialisés possèdent le travail spécifique au domaine. Le revers est que l’orchestrateur peut devenir un goulot d’étranglement, et il a besoin d’une stratégie de routage solide pour déléguer efficacement — le modèle sous-jacent de sélection et les compromis d’orchestration sont couverts dans Conception de Système Multi-Modèle : Quand un seul modèle ne suffit pas. Tout de même, pour la plupart des équipes, c’est la meilleure première architecture multi-agent à viser avant d’explorer des topologies plus complexes.

Modèle d’architecture : Agents pairs

Dans un modèle pair-à-pair, les agents peuvent communiquer les uns avec les autres plus directement.

Par exemple :

Agent de recherche --> Agent de données --> Agent de graphiques --> Agent d'écriture

Cela peut être puissant, mais c’est plus difficile à contrôler.

Vous avez besoin de règles fortes pour :

• qui peut appeler qui
• quel contexte peut être partagé
• comment les boucles sont empêchées
• qui possède la sortie finale
• comment le coût est contrôlé
• comment la délégation est auditée

Les réseaux d’agents pairs sonnent élégants, mais ils peuvent devenir chaotiques rapidement — utilisez-les seulement lorsque vous avez des règles de gouvernance fortes et une propriété claire sur chaque arête du graphe.

Modèle d’architecture : Passerelle A2A

Un modèle plus amical pour la production est une passerelle A2A.

Au lieu que chaque agent appelle directement chaque autre agent, le trafic circule à travers une passerelle.

La passerelle peut gérer :

• l’authentification
• l’autorisation
• le routage
• le mappage des locataires
• la journalisation
• les limites de taux
• les vérifications de politique
• la gestion des versions de protocole
• l’observabilité
• les traces d’audit

C’est particulièrement utile dans les environnements d’entreprise, où la passerelle devient le plan de contrôle pour la communication d’agent — imposant la politique en un seul endroit plutôt que de la réimplémenter à travers chaque agent. Dans les petits systèmes, cela peut être excessif, mais dans les grands systèmes avec plusieurs équipes et fournisseurs, cela devient souvent nécessaire plus tôt qu’attendu.

Considérations de sécurité

La sécurité A2A mérite une attention sérieuse.

La communication agent-à-agent peut déplacer du contexte sensible à travers les frontières. Elle peut également déléguer du travail à des systèmes qui peuvent avoir leurs propres outils et permissions.

Les questions de sécurité fondamentales sont :

• Quels agents sont autorisés à découvrir cet agent ?
• Quels agents sont autorisés à lui envoyer des tâches ?
• Quelle authentification est requise ?
• Quelles permissions sont attachées à l’appelant ?
• Un agent peut-il déléguer l’autorité utilisateur à un autre ?
• Quelles données peuvent être incluses dans les messages ?
• Quels artefacts peuvent être retournés ?
• Comment la tâche est-elle auditée ?
• L’agent récepteur peut-il appeler des outils ou d’autres agents ?
• Comment les secrets sont-ils protégés ?

Les Fiches d’agent ne devraient pas contenir de secrets statiques, et les Fiches d’agent sensibles devraient être protégées derrière une authentification plutôt que publiées ouvertement. Différents clients ont souvent besoin de différentes vues du même agent — un appelant interne peut voir plus de compétences qu’un partenaire externe, tandis qu’un client public peut ne voir qu’un ensemble limité de capacités sûres.

La sécurité ne devrait pas être ajoutée après que le réseau d’agent est construit ; elle devrait façonner le réseau dès le début, car le rétrofit des frontières d’auth et de permission à travers une topologie d’agent en direct est significativement plus difficile que de les concevoir dès le départ. Pour le traitement complet — modèle de menace, couches d’identité, plan de contrôle de passerelle, périmètre de délégation et traces d’audit — consultez Sécurité des Agents A2A et MCP : Identité, Délégation et Traces d’Audit.

Considérations d’observabilité

Les systèmes A2A ont besoin d’une forte observabilité.

Quand une tâche traverse les frontières d’agent, le débogage devient substantiellement plus difficile car aucun système unique ne détient l’image complète. Vous devez savoir :

• quel agent a créé la tâche
• quel agent l’a acceptée
• quels messages ont été échangés
• quels changements d’état se sont produits
• quels artefacts ont été produits
• quelles erreurs se sont produites
• combien de temps chaque étape a pris
• quels outils ont été utilisés en interne
• si un autre agent a été appelé
• qui a approuvé les actions risquées

Une trace utile devrait suivre le travail à travers la chaîne complète.

Par exemple :

demande utilisateur
  -> tâche assistant principal
  -> tâche agent de recherche
  -> appel outil recherche de document
  -> artefact de résumation
  -> réponse finale

Sans cette trace bout-en-bout, les systèmes multi-agents deviennent très difficiles à faire confiance en production — vous ne pouvez pas répondre avec confiance pourquoi le système a produit une sortie donnée, sans parler d’identifier où il a mal tourné. Observabilité pour les Systèmes LLM : Métriques, Traces, Journaux et Tests en Production couvre l’instrumentation et l’outillage de ce problème en profondeur.

Erreurs courantes

Erreur 1 : Appeler chaque outil un agent

Tout outil n’est pas un agent.

Une calculatrice est un outil. Un lecteur de fichier est un outil. Un point de terminaison de requête de base de données est un outil.

S’il ne possède pas de tâche, ne demande pas d’entrée, ne produit pas d’artefacts ou ne se comporte pas comme un pair indépendant, il n’a probablement pas besoin de A2A.

Erreur 2 : Rendre les Fiches d’agent trop vagues

Une Fiche d’agent ne devrait pas dire :

Cet agent aide avec les tâches commerciales.

Cela est inutile pour tout agent essayant de router du travail intelligemment. Une bonne fiche devrait dire ce que l’agent fait réellement, ce qu’il accepte, ce qu’il retourne et quelles contraintes s’appliquent.

Erreur 3 : Ignorer l’état de la tâche

Si vous utilisez A2A mais traitez chaque interaction comme demande et réponse, vous manquez une grande partie de la valeur.

Le modèle de tâche est l’une des raisons principales d’utiliser A2A plutôt qu’une API simple — le sauter signifie reconstruire la même logique de suivi de cycle de vie dans chaque intégration.

Erreur 4 : Tout retourner en texte

A2A prend en charge le contenu structuré et multimodal. Utilisez-le.

Si la sortie est un rapport, retournez un artefact de rapport.

Si la sortie est JSON, retournez des données structurées.

Si la sortie est un fichier, retournez un fichier.

Ne aplatissez pas tout en texte brut sauf si le texte brut est la bonne sortie.

Erreur 5 : Aucun modèle de permission

Les réseaux d’agents sans frontières de permission sont risqués.

Chaque agent ne devrait pas être autorisé à appeler chaque autre agent avec chaque type de données — utilisez l’authentification, l’autorisation et les traces d’audit pour imposer le principe du moindre privilège à travers le réseau d’agents.

Quand devriez-vous utiliser A2A ?

Utilisez A2A lorsque vous avez de véritables frontières d’agent.

Les bonnes raisons incluent :

• les agents sont possédés par différentes équipes
• les agents sont déployés comme des services séparés
• les agents sont construits avec différents frameworks
• les agents ont besoin de se découvrir mutuellement
• les agents ont besoin de déléguer des tâches
• les tâches peuvent être de longue durée
• les résultats peuvent inclure des artefacts
• les clients ne devraient pas connaître les outils internes
• les métadonnées de capacités d’agent comptent

Les raisons faibles incluent :

• ça sonne moderne
• vous voulez appeler une seule fonction
• vous avez une application à agent unique
• une API normale fonctionnerait
• MCP résout déjà votre problème d’intégration d’outil

A2A est puissant lorsque le système est réellement multi-agent ; c’est une cérémonie inutile lorsque le système ne l’est pas, et le coût de cette cérémonie — concepts ajoutés, infrastructure, surface de débogage et exigences de sécurité — est réel.

Un modèle mental minimal

Si vous ne retenez qu’une chose, retenez ceci :

Fiche d'agent : ce que l'agent peut faire.
Message : ce que les agents se disent.
Partie : contenu typé à l'intérieur d'un message ou d'un artefact.
Tâche : le travail que l'agent possède.
Artefact : la sortie que la tâche a produite.

C’est le cœur de A2A — le reste est principalement de rendre ces cinq concepts fiables, observables et suffisamment sécurisés pour être utilisés dans de véritables systèmes de production.

Pensées finales

A2A n’est pas juste un autre acronyme IA — c’est une partie d’un changement plus large passant des assistants isolés aux systèmes d’agents interopérables. Ce changement ne se produira pas partout à la fois, et de nombreuses applications resteront des systèmes à agent unique avec un bon accès aux outils où MCP et les API normales sont entièrement suffisants.

Mais une fois que les agents deviennent des pairs déployés séparément, vous avez besoin de frontières plus fortes : découverte, propriété de tâche, messages qui transportent plus que du texte, artefacts comme sorties de première classe, et sécurité, état et observabilité qui s’étendent à travers les frontières d’agent. C’est l’espace que A2A essaie d’occuper, et c’est un problème véritablement différent du problème d’intégration d’outil que MCP résout.

Pour une prise pratique sur l’endroit où A2A a réellement de la traction en production en 2026 — y compris les niveaux d’adoption, les préoccupations de sécurité, le cas d’usage d’entreprise et un cadre de décision — consultez Protocole A2A de Google en 2026 : Adoption, Hype et Réalité.

Mon opinion : ne commencez pas avec A2A pour les petits projets. Commencez avec un agent utile, de bons outils et une architecture claire — le cluster Systèmes IA couvre les assistants auto-hébergés, les serveurs MCP et la mémoire d’agent comme un ensemble connecté si vous voulez le contexte plus large. Mais lorsque votre « outil » commence à ressembler à un autre spécialiste autonome avec son propre cycle de vie de tâche, ce n’est probablement plus juste un outil — et c’est là que A2A devient intéressant.

Sources

• Spécification du Protocole A2A : https://a2a-protocol.org/latest/specification/
• Concepts Clés A2A : https://a2a-protocol.org/latest/topics/key-concepts/
• Vie d’une Tâche A2A : https://a2a-protocol.org/latest/topics/life-of-a-task/
• Découverte d’Agents A2A : https://a2a-protocol.org/latest/topics/agent-discovery/
• Streaming et Opérations Async A2A : https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A et MCP : https://a2a-protocol.org/latest/topics/a2a-and-mcp/