Que sont les A2A Extensions du 9 septembre ? Mécanisme d'extension et protocole JSON (2026)

Aperçu avant lecture

Aspect	Détail
Publication officielle	2025-09-09 Google Developers Blog « A2A Extensions: Empowering Custom Agent Functionality »
Livrable central	Extensions de protocole optionnelles identifiées par URI : nouvelles données, contraintes, RPC, machines à états
Support JSON	capabilities.extensions[] de l'Agent Card
Négociation	En-tête HTTP A2A-Extensions, inactif par défaut
Rôle en 2026	A2A gère l'interopérabilité des agents ; les Extensions, la personnalisation métier ; elles ne remplacent ni MCP ni Function Calling

Qu'est-ce qui a été publié le 9 septembre ?

A2A (Agent2Agent) fixe déjà comment les agents se découvrent, s'envoient des tâches et renvoient les résultats en flux. Le protocole central doit pourtant rester générique — latence vocale, traçage de bout en bout ou poignée de main zéro confiance n'ont pas leur place dans le noyau. Le 9 septembre 2025, les ingénieurs de Google ont donné la réponse dans le billet officiel : Extensions.

Ce jour-là, ce n'est pas une RPC isolée qui a été livrée, mais un mécanisme d'extension ouvert complet :

• Chacun peut définir, publier et implémenter une extension, identifiée par une URI unique (avec un numéro de version, par exemple https://example.com/ext/my-extension/v1).
• L'agent déclare dans l'Agent Card (un JSON qui décrit ses capacités) les extensions qu'il prend en charge.
• Le client les active à la demande via un en-tête HTTP sur une requête donnée ; un client qui ne les déclare pas reste sur le protocole central et n'est pas cassé.
• Un exemple d'introduction accompagnait la publication : horodater le metadata de Message et Artifact.

En 2026, la règle figure dans le dossier A2A Extensions ; un cadre de gouvernance existe (les extensions officielles utilisent le préfixe https://a2a-protocol.org/extensions/). Décomposons le mécanisme côté protocole JSON.

Protocole A2A et JSON Agent Card

On peut voir l'Agent Card comme la « carte de visite lisible par machine » d'un agent : nom, description, URL d'entrée, MIME d'entrée et de sortie, liste de compétences, ainsi que capabilities. Les Extensions s'accrochent à capabilities, elles n'occupent pas un second fichier.

Une Agent Card avec extension ressemble à ceci (structure tirée de l'exemple officiel, noms de champs selon la spécification actuelle) :

{
  "name": "Magic 8-ball",
  "description": "An agent that can tell your future... maybe.",
  "version": "0.1.0",
  "url": "https://example.com/agents/eightball",
  "capabilities": {
    "streaming": true,
    "extensions": [
      {
        "uri": "https://example.com/ext/konami-code/v1",
        "description": "Provide cheat codes to unlock new fortunes",
        "required": false,
        "params": {
          "hints": [
            "When your sims need extra cash fast"
          ]
        }
      }
    ]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "fortune",
      "name": "Fortune teller",
      "description": "Seek advice from the mystical magic 8-ball",
      "tags": ["mystical"]
    }
  ]
}

Pour déboguer ce JSON, commencez par le formateur JSONSort afin de vérifier parenthèses et virgules, puis confrontez le schéma pour voir si extensions[] omet des champs. L'Agent Card circule en clair sur le réseau : n'y placez jamais de secret dans params.

Mécanisme d'extension : déclarer, désactivé par défaut, activer par requête

Les Extensions visent à étendre A2A sans déchirer le standard central. La spécification pose plusieurs limites :

1. Inactif par défaut. Un client qui ignore une extension continue d'appeler les méthodes centrales et obtient l'expérience de base.
2. Le client s'inscrit explicitement. La requête HTTP porte A2A-Extensions, dont la valeur est une liste d'URI séparées par des virgules.
3. L'agent ignore les URI qu'il ne prend pas en charge et renvoie dans l'en-tête de réponse les extensions réellement activées.
4. required: true est une dépendance dure. Si le client n'active pas l'extension ou ne la respecte pas, l'agent doit refuser la requête. Une extension d'affichage de données ne doit pas être marquée required.

Une extension peut dépendre d'autres (obligatoires ou facultatives). La spécification exige de consigner ces dépendances dans le document de l'extension ; à l'activation, le client envoie aussi les URI dépendantes. Le numéro de version appartient à l'URI : un changement incompatible impose une nouvelle URI. L'agent ne doit pas basculer en silence vers une autre version.

Champs du JSON AgentExtension

La spécification trace aussi une ligne rouge pour que les extensions ne cassent pas la validation des types centraux : n'ajoutez ni ne retirez de champs obligatoires aux structures déjà définies — les attributs personnalisés vont dans la map metadata existante ; n'ajoutez pas de valeurs aux énumérations, la sémantique supplémentaire va également dans metadata. Ces deux règles déterminent la forme de votre JSON.

Négociation des requêtes : en-tête HTTP et message JSON-RPC

L'activation a lieu sur chaque requête HTTP, et non « une fois connecté, pour toujours ». Requête typique (dans le style de l'exemple d'introduction officiel) :

POST /agents/eightball HTTP/1.1
Host: example.com
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "method": "SendMessage",
  "id": "1",
  "params": {
    "message": {
      "messageId": "1",
      "role": "ROLE_USER",
      "parts": [{"text": "Oh magic 8-ball, will it rain today?"}]
    },
    "metadata": {
      "https://example.com/ext/konami-code/v1/code": "motherlode"
    }
  }
}

La réponse correspondante doit renvoyer l'extension effectivement activée :

HTTP/1.1 200 OK
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "message": {
      "messageId": "2",
      "role": "ROLE_AGENT",
      "parts": [{"text": "That's a bingo!"}]
    }
  }
}

Observez que la clé de params.metadata est l'URI d'extension plus un suffixe de chemin, et non un nom court inventé. Plusieurs extensions peuvent ainsi remplir le même JSON-RPC sans collision de noms. Si une extension « ne prend pas », vérifiez d'abord que l'en-tête de requête porte l'URI, puis comparez le JSON de la requête et de la réponse — le Diff JSON convient pour juxtaposer le metadata avant et après activation.

Quatre types d'extensions : données, Profile, méthodes, machine à états

La spécification laisse volontairement large « ce qu'une extension peut faire ». Les usages prévisibles en 2026 se regroupent en quatre types :

• Données (Data-only) : exposer seulement des informations structurées supplémentaires dans l'Agent Card, sans changer le flux requête-réponse. Exemple : champs de conformité RGPD. Ce type ne doit pas porter required: true.
• Profile : superposer aux messages centraux des contraintes de structure ou d'état plus strictes, comme un profil posé sur A2A. Exemple : tous les parts doivent être un DataPart conforme à un schéma ; ou, lorsque TaskStatus.state === "working", indiquer un sous-état via metadata["generating-image"].
• Méthodes (Extended Skills) : ajouter des RPC hors de l'ensemble central. L'extension task-history ajoute par exemple tasks/search et donne à l'agent la compétence « rechercher des tâches historiques ».
• Machine à états : ajouter des états ou des transitions à l'automate des tâches. C'est le type le plus exposé à la ligne rouge : la nouvelle sémantique doit aller dans metadata, pas dans l'énumération centrale.

Cas d'usage cités le jour de la publication

Le billet Google ne s'est pas limité au mécanisme abstrait : il a listé des extensions déjà en service, pour montrer ce que le JSON doit porter.

Traceability (traçabilité) : le message central est ResponseTrace — un journal structuré indépendant du protocole principal, qui consigne les étapes de l'agent. Chaque Step est soit un ToolInvocation (appel d'un outil ou d'une API), soit un AgentInvocation (appel d'un autre agent). Les étapes peuvent s'imbriquer : si l'agent aval prend aussi l'extension en charge, sa trace se rattache à l'étape amont et forme un arbre d'appels de bout en bout. C'est indispensable pour évaluer une collaboration multi-agents et localiser les erreurs, sans pour autant entrer dans le noyau A2A.

Twilio Latency Extension : un agent vocal (ConversationRelay) doit diffuser la latence pour choisir le modèle aval le plus adapté ou se dégrader proprement. La latence n'est pas un champ central de l'Agent Card ; Twilio la complète par une extension — l'exemple type de « données métier qui ne doivent pas polluer le protocole central ».

Identity Machines : une extension pour la poignée de main zéro confiance entre agents. Avant de déléguer une tâche, un filtre de politique vérifie l'objet, le budget, les capacités, le modèle, l'état PII et d'autres conditions propres. Le JSON porte ici un contexte de politique, pas du texte de conversation.

Le billet évoque aussi la direction ERC-8004 d'Ethereum : registres d'identité, de réputation et de vérification on-chain pour une couche de confiance entre organisations. Cela n'apparaît pas forcément sous forme d'A2A Extension, mais illustre la même séparation — le protocole central règle « comment on parle », les extensions et normes externes règlent « pourquoi on fait confiance ».

Quel rapport avec MCP et Function Calling ?

Les trois produisent du JSON, mais à des niveaux différents ; en 2026, ils ne doivent pas se remplacer :

L'architecture habituelle est en couches : un serveur MCP fournit les outils → l'hôte les projette en Function Calling du modèle → plusieurs agents se répartissent les tâches via A2A et portent, grâce aux Extensions, le traçage, la latence et l'identité d'un agent à l'autre. Pour le comparatif JSON des deux premières couches, voir l'article précédent MCP Tool Schema vs Function Calling.

Contraindre les données d'extension avec JSON Schema

Une spécification d'extension doit au moins préciser : la liste des URI, le schéma de params, les structures supplémentaires entre client et agent, les nouveaux flux requête-réponse. En mise en œuvre :

• Maintenir un JSON Schema pour AgentExtension.params et un autre pour les clés de metadata.
• Valider des charges d'exemple en CI ; traiter l'Agent Card comme un contrat d'API public.
• Considérer toute entrée liée à une extension comme non fiable : d'abord analyser, ensuite valider.

Pour la rédaction de JSON Schema, voir le tutoriel JSON Schema complet de ce site. Formatage local, contrôle de syntaxe et Diff entre versions se font avec JSONSort, sans envoyer une Card contenant politique ou identité vers un site tiers.

Pièges courants

• Prendre une Extension pour un droit d'ajouter n'importe quel champ. La structure centrale ne change pas ; les données nouvelles vont dans metadata.
• Marquer required une extension de type données. Cela refuse inutilement une foule de clients.
• URI sans version. Un changement incompatible n'a plus d'issue, et la négociation se dérègle.
• Revenir à l'ancienne implémentation en cas d'écart de version. La spécification demande d'ignorer cette activation, pas de compatibiliser en silence.
• Contourner l'authentification existante avec une nouvelle RPC. Les méthodes d'extension suivent la même authentification et les mêmes autorisations que les méthodes centrales.
• Confondre avec la liste d'outils MCP. MCP répond à « quels outils existent » ; une A2A Extension répond à « comment deux agents parlent selon les règles du métier ».

Questions fréquentes (FAQ)

Les A2A Extensions ont-elles été publiées le 9 septembre 2026 ?

La date du billet officiel est le 9 septembre 2025. En 2026, on continue de chercher « ce qui a été publié » sous cette date ; le mécanisme figure dans la spécification A2A actuelle, avec une gouvernance et des extensions d'exemple (Traceability, Timestamp, Secure Passport, etc.).

Faut-il implémenter des extensions pour utiliser A2A ?

Non. Les extensions sont désactivées par défaut. Ce n'est que si l'Agent Card de l'autre partie marque une extension required que vous devez l'activer et la respecter selon la spécification.

Le JSON d'extension va-t-il dans le corps du message ou dans l'en-tête HTTP ?

La liste d'activation est dans l'en-tête A2A-Extensions ; les données métier portées par l'extension sont dans le JSON-RPC params.metadata (ou à un autre emplacement indiqué par la spécification). L'en-tête négocie, le JSON porte la charge.

Comment déboguer une Agent Card et le metadata d'extension ?

En local, formatez la Card avec JSONSort, validez le schéma et comparez deux versions du tableau extensions. N'envoyez pas de JSON contenant identité ou politique dans un outil en ligne.

Conclusion

Le 9 septembre n'a pas livré une API propriétaire de plus, mais la couche d'extension ouverte d'A2A : nommer les capacités par URI, les déclarer dans le JSON Agent Card, les activer par requête avec A2A-Extensions, porter les données métier dans metadata. Pour un système multi-agents en 2026 : le dialogue central passe par A2A, l'offre d'outils par MCP, l'intention du modèle par Function Calling, les besoins verticaux par les Extensions — chacun sa couche, JSON Schema comme source unique de vérité pour les paramètres et les données d'extension.

Pour aller plus loin

• Google : billet de publication A2A Extensions Texte original et cas du 2025-09-09
• Dossier de spécification A2A Extensions Déclaration, activation, gouvernance et limites
• MCP Tool Schema vs Function Calling Comparatif JSON de la couche outils
• Boîte à outils JSON locale JSONSort Formatage, validation de syntaxe, Diff

Journal des mises à jour : 2026-08-28 première publication