A2A-commerce : architecture pour les agents IA

Architecture commerciale A2A : concevoir une infrastructure pour l’interaction des agents IA

Le web moderne a été conçu pour les humains, avec des navigateurs. Mais lorsque le client devient un agent IA autonome, les solutions standard — parsing du DOM, intégration d’API basée sur OAuth et intégration manuelle — ne parviennent pas à évoluer. Dans un monde où chaque utilisateur dispose d’un agent personnel capable d’initier des milliers de transactions par seconde, des changements fondamentaux sont nécessaires en matière d’adressage, de routage, de confiance et de recherche. Il ne s’agit pas d’une évolution de REST ou de GraphQL — c’est une nouvelle sémantique réseau pour l’interaction machine à machine.

Adressage : des URL à l’identification en trois couches

Le web humain repose sur le DNS et les URL : domaine → IP → serveur. Pour les agents IA, ce modèle ne fonctionne pas. Un agent peut tourner sur un appareil mobile derrière un NAT, dans le cloud d’un fournisseur ou localement sur le PC d’un utilisateur ; il peut changer d’endpoint, se déconnecter et posséder une identité cryptographique indépendante de l’infrastructure.

La solution est un modèle en trois couches :

• Identifiant humain (alice#aigentix.org) — un identifiant lisible transmis via des codes QR et des messages ;
• DID (did:aip:aigentix.org:alice) — un identifiant décentralisé conforme à la norme W3C, contenant des clés publiques et non lié à un domaine ;
• Endpoint (https://hub.aigentix.org/relay/alice) — une voie de livraison physique qui peut changer dynamiquement sans perdre son identité.

Un détail technique clé : le symbole # dans l’identifiant entre en conflit avec l’identifiant de fragment dans HTTP. Dans l’API, l’identifiant est toujours encodé en URL : alice%23aigentix.org. Le serveur ne reçoit pas GET /api/v1/resolve/alice#aigentix.org, mais uniquement GET /api/v1/resolve/alice. Ce n’est pas anodin — c’est un exemple de la manière dont les conventions héritées du web créent de véritables obstacles lors de la conception de protocoles de nouvelle génération.

La résolution se fait séquentiellement : identifiant → consultation dans le registre → DID → Document DID (avec route_mode et clés publiques) → endpoint. La mise en cache des résultats au niveau du registre garantit les performances, tandis que la séparation des couches assure la stabilité à long terme des identifiants.

Routage : direct vs. relais et idempotence stricte

Disposer d’un endpoint seul ne résout pas le problème de livraison. Deux modes principaux — direct et relais — répondent à des catégories différentes de tâches :

• Direct : HTTP POST directement vers l’endpoint du destinataire. Convient aux agents d’entreprise disposant d’IP publiques et d’une disponibilité garantie.
• Relais : publication sur un flux durable (par exemple, NATS JetStream) et abonnement du destinataire via WebSocket. Assure la livraison même hors ligne mais ajoute de la latence.

Le choix du mode est déterminé par un algorithme :

• Résoudre le DID du destinataire ;
• Si route_mode == "direct" et l’endpoint est disponible — utiliser le direct ;
• Sinon — utiliser le relais.

Le relais implique une livraison au moins une fois. Ce n’est pas facultatif — c’est une exigence. Le destinataire doit mettre en œuvre un traitement idempotent basé sur message_id. Chaque message contient des champs obligatoires :

• id : UUID v4 ;
• created_at : timestamp au format RFC 3339 ;
• encrypted_body : charge chiffrée (échange de clé éphémère X25519) ;
• sig : signature Ed25519 sur l’enveloppe sérialisée.

La déduplication est mise en œuvre via une fenêtre glissante : les ID des messages des 10 dernières minutes sont stockés avec une tolérance horaire de ±300 secondes. Une simple cache LRU dans Redis ou une LSM-tree dans RocksDB suffit.

Confiance : certificats cryptographiques et graphes de confiance

Les humains font confiance aux marques, aux avis et aux notes. Les machines ne font confiance qu’aux affirmations vérifiables. Nous utilisons la norme W3C Verifiable Credentials (VC) comme base de notre modèle de confiance.

Exemple de VC pour vérifier une entité juridique :

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "OrganizationVerification"],
  "issuer": "did:aip:aigentix.org:trust-anchor",
  "credentialSubject": {
    "id": "did:aip:aigentix.org:etagi",
    "legalName": "Etazhi LLC",
    "inn": "7224052984",
    "verified": true
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:aip:aigentix.org:trust-anchor#key-1",
    "proofValue": "..."
  }
}

Un tel certificat est émis par un Trust Anchor — un centre de confiance dont le DID et les clés publiques sont connus de tous les participants du réseau. La vérification se fait localement, sans recourir à des tiers.

Les VC individuels forment un DAG de confiance — un graphe acyclique dirigé où le poids de chaque arête dépend de l’autorité de l’émetteur. L’algorithme de calcul du Trust Score est conservateur :

• Le score augmente lentement : il faut de nombreuses interactions réussies ;
• Le score diminue rapidement : une révocation ou une erreur de validation le réduit immédiatement ;
• La fourchette finale est [0.0, 1.0].

Ce score est intégré à la recherche via Reciprocal Rank Fusion (RRF) :

final_score = RRF(semantic_rank, fts_rank) × (1 + 0.3 × trust_score)

Le paramètre trust_weight = 0.3 garantit que la confiance renforce la pertinence mais ne la remplace pas.

Recherche : classement hybride et réponses structurées pour les agents

La recherche pour les humains renvoie des pages HTML. La recherche pour les agents renvoie un objet structuré indiquant comment obtenir plus de données. La réponse doit inclure non seulement les données, mais aussi l’adresse de l’agent-fournisseur :

{
  "results": [
    {
      "id": "doc_123",
      "name": "Appartement 2 pièces, rue Tverskaya, 68 m²",
      "price": 79 000,
      "available": true,
      "relevance_score": 0.92,
      "trust_score": 0.94,
      "agent": {
        "handle": "etagi%23aigentix.org",
        "name": "Etaji",
        "endpoint": "https://api.etagi.ru/aip"
      }
    }
  ]
}

Le champ agent n’est pas un lien vers un site web — c’est une adresse pour de futures appels A2A. Après avoir résolu etagi%23aigentix.org, l’agent envoie un POST avec le type aip.commerce.offer.request et item_id, recevant des photos structurées, des plans d’étage et des coordonnées — sans aucun rendu HTML.

La recherche hybride est nécessaire car la recherche sémantique pure ne suffit pas :

• Les codes produits et les phrases exactes (par exemple, iPhone 15 Pro Max 256GB) nécessitent FTS ;
• Les nouvelles entités (marques, entreprises, produits) manquent de contexte sémantique suffisant dans les embeddings ;
• Les valeurs numériques (prix, superficie, étage) sont mal distinguées dans l’espace d’embedding.

RRF est mis en œuvre ainsi :

def rrf(semantic_rank, fts_rank, k=60):
    return 1/(k + semantic_rank) + 1/(k + fts_rank)

Cela permet de combiner deux classements sans normalisation, en préservant la sensibilité aux premières positions et en améliorant constamment la qualité sur des requêtes mixtes.

Protocole comme spécification : interopérabilité avant implémentation

Le principe clé est la séparation stricte du protocole et de l’implémentation. L’AIP (Agent Interaction Protocol) définit :

• Le format de l’enveloppe : champs obligatoires id, from, to, type, encrypted_body, sig ;
• Les règles de résolution de handle → DID → endpoint ;
• Le schéma des requêtes et des réponses de recherche ;
• Les algorithmes de vérification des VC et de calcul du Trust Score.

L’implémentation (Hub) peut utiliser n’importe quelle pile : Rust avec Actix, Go avec NATS, Python avec FastAPI — ce sont des détails de déploiement. Cette architecture garantit :

• L’interopérabilité entre agents de différents développeurs ;
• Pas de verrouillage vendor pour les entreprises ;
• Capacité de fédération : les Hubs sur des domaines différents peuvent router les messages entre eux.

L’analogie avec le courrier électronique est appropriée : SMTP est un protocole ouvert, Gmail et Yandex.Mail sont des implémentations indépendantes, et pourtant les emails circulent entre eux sans coordination.

Ce qui compte

• L’adressage des agents IA nécessite un modèle en trois couches (handle/DID/endpoint) pour séparer la lisibilité de l’identité cryptographique et du routage physique.
• Le routage en relais impose une idempotence stricte : chaque message doit avoir un UUID v4 et created_at, et le destinataire doit supporter la déduplication par fenêtre glissante.
• La confiance se construit sur les Verifiable Credentials de W3C, pas sur des notes centralisées : la vérification se fait localement, sans services externes.
• La recherche pour les agents renvoie non pas des URLs, mais des objets avec agent.handle et agent.endpoint — c’est la base du prochain niveau d’interaction A2A.
• La recherche hybride (RRF) combine FTS et classement sémantique parce que les embeddings ne remplacent pas les correspondances exactes pour les codes produits, les chiffres et les nouvelles entités.
• Le protocole doit être séparé de l’implémentation : c’est la condition pour l’interopérabilité, la fédération et la protection contre le verrouillage vendor.

— Editorial Team