« Qu’est-ce que le protocole A2A ? Cartes d’agent et tâches expliquées »

Le protocole A2A, acronyme d’Agent2Agent Protocol (Protocole Agent à Agent), 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émos d’agents IA ignorent complètement. La plupart des démos supposent encore un seul assistant, un seul environnement d’exécution, une seule boucle d’outils et un seul propriétaire — l’agent peut rechercher, appeler des outils, écrire du code, interroger des API, utiliser éventuellement des serveurs MCP, et retourner une réponse.

L’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’à son achèvement — ce qui en fait non pas un simple autre format d’appel d’outil, mais une véritable tentative de rendre les agents IA interopérables en tant que pairs.

Les concepts de base sont :

• Fiches d’agent (Agent Cards)
• Agents et clients
• Tâches
• Messages
• Parties
• Artéfacts
• É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ù l’A2A s’insère dans les systèmes multi-agents réels.

La Définition Courte

L’A2A est un protocole de communication entre agents.

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 de saisie, diffuser la progression, 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 manière dont les agents communiquent à leurs frontières.

Un agent A2A peut 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 savoir tout cela. Ce dont l’appelant a besoin, c’est de savoir :

• Que peut faire cet agent ?
• Comment communiquer avec lui ?
• Quelle saisie accepte-t-il ?
• Quelle sortie peut-il produire ?
• Comment suivre le travail ?
• Comment recevoir le résultat ?

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

Pourquoi l’A2A Existe

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

Une entreprise peut 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 révision de code

Chaque agent peut avoir ses propres outils, permissions, connaissances du domaine, invites (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 pour l’agent de facturation, l’agent de facturation a besoin du sien pour l’agent juridique, et l’agent de recherche en a besoin d’un autre pour l’agent de documentation. Cette surcharge combinatoire ne passe pas bien à l’échelle lorsque le réseau d’agents grandit.

L’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 l’autonomie magique ; la promesse est l’interopérabilité.

L’A2A N’est Pas MCP

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

Le MCP, ou Model Context Protocol (Protocole de Contexte de Modèle), concerne principalement la connexion d’une application ou d’un agent IA à des outils, ressources et invites, tandis que l’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 le 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.

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

• un agent de révision de sécurité
• un agent de recherche
• un 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 d’autres agents communiquent avec votre agent en utilisant l’A2A, tandis que votre agent utilise en interne le MCP pour accéder aux outils — une séparation claire des préoccupations qui maintient l’interface externe stable indépendamment des changements internes. Pour une comparaison détaillée de la manière dont les deux protocoles divisent la responsabilité architecturale et de quand vous avez réellement besoin des deux, voir A2A vs MCP : Les agents IA ont-ils vraiment besoin des deux protocoles ?

Rôles Principaux dans l’A2A

L’A2A utilise un modèle de rôles 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
• une passerelle
• un harnais de test
• une application pour humains

L’agent peut être :

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

L’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 l’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é
• 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
• fonctionnalités du protocole supportées
• modes d’entrée et de sortie supportés
• compétences disponibles
• exigences d’authentification
• informations du 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 carte 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 ?
• Requiert-il une authentification ?
• Quelles compétences publie-t-il ?
• Peut-il retourner le type d’artéfact dont j’ai besoin ?

Dans les systèmes pratiques, les Fiches d’Agent deviennent la base des registres d’agents, des portails développeurs et des catalogues internes d’agents — 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é

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

Si votre fiche d’agent indique que votre agent peut effectuer une analyse financière, les clients commenceront à lui déléguer du travail d’analyse financière. Si elle indique que l’agent accepte des fichiers, les clients peuvent envoyer des fichiers. Si elle indique que l’agent supporte 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é 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 quant aux limitations

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

Une meilleure compétence serait :

Analyser les données de facturation SaaS et produire un résumé 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’Agent

La découverte d’agent 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 importants, 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 configuration
• le routage spécifique à l’environnement
• des passerelles conscientes du locataire

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

Tout agent ne devrait pas être découvrable 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 voir uniquement les compétences sûres pour les partenaires. La découverte d’agent n’est pas juste une fonctionnalité pratique ; elle fait partie de votre modèle de sécurité et de gouvernance, et le cadrage de la visibilité est une décision de conception de premier ordre.

Tâches

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

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

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

Mais de nombreux workflows d’agents 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
• le streaming de progression
• la gestion des nouvelles tentatives
• le retour de plusieurs artéfacts

L’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 relancé.

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 :

• soumise
• en cours
• saisie requise
• terminée
• échouée
• annulée
• rejetée

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 ?
• Est-il toujours en train de travailler ?
• A-t-il besoin de plus de saisie ?
• A-t-il fini avec succès ?
• A-t-il échoué ?
• A-t-il été annulé ?
• Des artéfacts sont-ils disponibles ?

Ceci 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

L’A2A supporte à la fois 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 de suivi de tâche, et la sur-ingénierie des interactions courtes en workflows de tâches complets ajoute une surcharge inutile.

Si un client demande :

Résume ce seul 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 artéfacts.

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 d’utilisateur
• une réponse d’agent
• une question de clarification
• une saisie supplémentaire
• une communication liée à une tâche
• un contexte de progression
• des instructions structurées

Les messages ne sont pas juste des chaînes de caractères — la communication entre agents a souvent besoin de transporter bien plus que du texte brut, et la structure du message est conçue pour accommoder 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

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

C’est ainsi que l’A2A supporte la communication multimodale et structurée.

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

• texte
• données de fichier
• données structurées
• contenu binaire par référence
• données semblables à JSON

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

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

Le type de 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

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

Artéfacts

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

Ceci est différent d’un message général : un message est une communication entre agents, tandis qu’un artéfact est un livrable concret que la tâche a produit.

Les exemples d’artéfacts 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 artéfacts — des sorties concrètes qui rendent le travail de la tâche inspectable, réutilisable et composable. L’artéfact d’un agent devient l’entrée d’un autre agent sans perte de structure.

Messages vs Artéfacts

Une façon simple de penser à cela :

Les Messages sont la conversation.
Les Artéfacts sont la sortie.

Les messages aident les agents à coordonner ; les artéfacts 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 artéfacts tels qu’un fichier de patch, la 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 de 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 indique 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 artéfacts

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 de clarification sur les exemples d'authentification.

L’assistant principal fournit la saisie manquante.

La tâche continue.

Enfin, l’agent de documentation retourne des artéfacts :

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

C’est le modèle A2A en action : non pas juste “appeler cette fonction” mais “déléguer cette tâche à un autre agent, communiquer si nécessaire, et suivre le résultat jusqu’à l’achèvement.”

Pourquoi les Tâches Importent Pour les Réels Systèmes

Les Tâches sont ce qui rend l’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 de l’incertitude, plusieurs étapes, des résultats intermédiaires et des questions de suivi.

Une Tâche vous donne un endroit pour attacher :

• statut
• historique
• messages
• artéfacts
• erreurs
• métadonnées
• progression
• annulation
• informations d’audit

Ceci est utile pour :

• les workflows de recherche
• la génération de code
• l’analyse de données
• la révision 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 ID de travail personnalisés, des files d’attente, des points de terminaison de statut et des rappels webhook — l’A2A tente de standardiser la version spécifique aux agents de ce modèle afin que vous n’ayez pas à le réinventer pour chaque nouvelle intégration d’agent.

Streaming et Travail Asynchrone

L’A2A supporte l’idée que le travail d’agent peut être en streaming 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 grands documents
• révision 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.

Fiches d’Agent et Support du Streaming

Une Fiche d’Agent peut annoncer si un agent supporte le streaming.

Ceci est important car les clients ne peuvent pas supposer que chaque agent supporte le streaming — certains agents peuvent ne supporter que des demandes et réponses simples, certains peuvent supporter le sondage de tâches, et d’autres peuvent supporter les notifications push ou les événements servis 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 lors de l’exécution.

A2A et Agents Multimodaux

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

Ceci est important car les systèmes d’agents 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 révision de code devrait recevoir des fichiers source ou des diffs, pas un résumé vague.

Les Parties et les types de média sont la manière dont l’A2A préserve un contenu plus riche à travers les frontières des agents — 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 cumule à chaque saut dans une chaîne multi-agent.

L’A2A N’est Pas un Framework d’Agent

L’A2A ne vous dit pas comment construire un agent.

Il ne définit pas :

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

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

L’A2A N’est Pas un Remplacement pour les API

L’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 d’IA. L’A2A a du sens lorsque le système distant se comporte véritablement comme un agent :

• il possède une tâche
• il peut demander plus de saisie
• il peut utiliser des outils en interne
• il peut prendre du temps
• il peut produire des artéfacts
• il a des capacités dignes d’être découvertes
• il peut opérer en tant que pair dans un workflow plus large

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

Où l’A2A S’insère dans l’Architecture des Systèmes IA

L’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 d'interface utilisateur
Couche de coordination d'agents
Couche d'intégration d'outils
Couche de données et d'exécution

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

Patron d’Architecture : Orchestrateur et Spécialistes

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

Dans ce patron, un agent principal reçoit la demande de l’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 patron est facile à comprendre : l’orchestrateur possède le workflow global, et les agents spécialisés possèdent le travail spécifique au domaine. L’inconvénient 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 — les compromis de sélection de modèle et d’orchestration sous-jacents sont couverts dans Conception de Système Multi-Modèle : Quand Un Seul Modèle Ne Suffit Pas. Cependant, pour la plupart des équipes, c’est la meilleure première architecture multi-agent à laquelle se tourner avant d’explorer des topologies plus complexes.

Patron d’Architecture : Agents Pairs

Dans un patron pair-à-pair, les agents peuvent communiquer entre eux 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 uniquement lorsque vous avez des règles de gouvernance fortes et une propriété claire sur chaque arête du graphique.

Patron d’Architecture : Passerelle A2A

Un patron plus adapté à la production est une passerelle A2A.

Au lieu que chaque agent appelle directement chaque autre agent, le trafic passe par une passerelle.

La passerelle peut gérer :

• authentification
• autorisation
• routage
• mappage de locataire
• journalisation
• limites de taux
• vérifications de politique
• gestion des versions de protocole
• observabilité
• trails d’audit

Ceci est particulièrement utile dans les environnements d’entreprise, où la passerelle devient le plan de contrôle pour la communication des agents — imposant la politique à 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 que prévu.

Considérations de Sécurité

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

La communication agent-à-agent peut déplacer un 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é centrales 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 artéfacts 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 voir uniquement un ensemble limité de capacités sûres.

La sécurité ne devrait pas être ajoutée après que le réseau d’agents est construit ; elle devrait façonner le réseau dès le début, car rétro-adapter les frontières d’authentification et de permission à travers une topologie d’agents en direct est significativement plus difficile que de les concevoir dès le départ.

Considérations d’Observabilité

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

Quand une tâche traverse les frontières des agents, le débogage devient substantiellement plus difficile car aucun système unique ne détient le tableau complet. 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 artéfacts 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 toute la chaîne.

Par exemple :

demande utilisateur
  -> tâche assistant principal
  -> tâche agent de recherche
  -> appel outil de recherche de document
  -> artéfact de résumé
  -> 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, encore moins 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 fichiers est un outil. Un point de terminaison de requête de base de données est un outil.

S’il ne possède pas une tâche, ne demande pas de saisie, ne produit pas d’artéfacts, ou ne se comporte pas comme un pair indépendant, il n’a probablement pas besoin de l’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.

Ceci est inutile pour tout agent essayant de router le travail intelligemment. Une bonne carte 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 l’A2A mais traitez chaque interaction comme une 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 l’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 : Retourner Tout en Texte

L’A2A supporte le contenu structuré et multimodal. Utilisez-le.

Si la sortie est un rapport, retournez un artéfact de rapport.

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

Si la sortie est un fichier, retournez un fichier.

Ne platez pas tout en texte brut sauf si le texte brut est la sortie correcte.

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 trails d’audit pour imposer le principe du privilège minimum à travers le réseau d’agents.

Quand Devriez-vous Utiliser l’A2A ?

Utilisez l’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
• 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 artéfacts
• les clients ne devraient pas connaître les outils internes
• les métadonnées de capacité des agents sont importantes

Les raisons faibles incluent :

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

L’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 artéfact.
Tâche : le travail que l'agent possède.
Artéfact : la sortie que la tâche a produite.

C’est le cœur de l’A2A — le reste concerne principalement le rendu de ces cinq concepts fiables, observables et assez sécurisés pour être utilisés dans de vrais systèmes de production.

Pensées Finales

L’A2A n’est pas juste un autre acronyme IA — c’est partie d’un changement plus large passant des assistants isolés aux systèmes d’agents interopérables. Ce changement n’arrivera pas partout à la fois, et de nombreuses applications resteront des systèmes mono-agents avec un bon accès aux outils où le 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, artéfacts comme sorties de première classe, et sécurité, état et observabilité qui traversent les frontières des agents. C’est l’espace que l’A2A essaie d’occuper, et c’est un problème véritablement différent du problème d’intégration d’outils que le MCP résout.

Pour une prise pratique sur l’endroit où l’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’utilisation d’entreprise et un cadre de décision — voir Protocole A2A de Google en 2026 : Adoption, Hype et Réalité.

Mon opinion : ne commencez pas avec l’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 quand 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 l’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’Agent A2A : https://a2a-protocol.org/latest/topics/agent-discovery/
• A2A Streaming et Opérations Async : https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A et MCP : https://a2a-protocol.org/latest/topics/a2a-and-mcp/