Agents

Le mot « agent » recouvre deux objets différents dans le parc, et les confondre fait perdre des heures.

	Ce que c'est	Où il vit
L'exécutant	un programme qui reçoit une consigne, lit, réfléchit, rend un texte	une machine du parc — un claude -p non interactif, un service Python, un moteur de workflow
La définition	qui il est, quel modèle il a le droit d'appeler, ce qu'il a le droit de lire, ce qu'il coûte	le proxy LLM, dans son registre d'agents

La règle du parc depuis le 2026-09-13 : la définition est la référence, et elle est dans le proxy. Le dépôt d'un agent ne porte plus que son plan de secours — ce qui reste quand le proxy ne répond pas.

Pourquoi séparer les deux

Un exécutant est attaché à une machine : il lui faut le disque, le dépôt, la session authentifiée. Une définition, elle, doit être lisible par tout le monde — l'UI, un script, un autre agent, le tableau de dépense. Les garder ensemble oblige à cloner le fichier de configuration partout où quelqu'un veut savoir ce que fait l'agent.

A2A, en une page

A2A (Agent-to-Agent) est un protocole ouvert qui répond à une question précise : comment un programme parle-t-il à un agent qu'il n'a pas écrit ?

Il tient en trois pièces.

1. La carte d'agent

Un document JSON servi par l'agent lui-même, à une adresse conventionnelle : /.well-known/agent-card.json. Elle dit son nom, sa description, son URL, les compétences (skills) qu'il expose, les formats qu'il accepte et rend, et comment s'authentifier auprès de lui.

C'est l'équivalent d'un fichier OpenAPI pour une API REST : de quoi appeler sans avoir lu le code d'en face.

2. Un appel JSON-RPC

Une seule méthode suffit pour commencer : message/send. On poste un message fait de parts (du texte, une image, un fichier), l'agent répond.

{
  "jsonrpc": "2.0", "id": "1", "method": "message/send",
  "params": { "message": {
      "role": "user",
      "parts": [{ "kind": "text", "text": "vérifie la continuité de la scène 1" }],
      "messageId": "f1e2d3"
  }}
}

3. Une tâche qui a une vie

Un agent ne répond pas toujours en deux secondes. A2A modélise donc une tâche avec des états — submitted, working, completed — et des artefacts livrés au fil de l'eau. C'est ce qui distingue A2A d'un simple appel HTTP : le protocole prévoit que le travail dure.

Le piège de conception, et il est structurel

Un agent qui travaille plusieurs minutes s'appelle mal en synchrone. Si l'appelant attend la réponse sur la même connexion, tout ce qui est entre les deux — proxy, reverse proxy, client HTTP — a son propre délai d'expiration, et le premier qui expire gagne. Un agent lent se conçoit avec le cycle de vie de tâche, pas contre lui.

Ce que le proxy LLM ajoute

Le proxy du parc — celui qui sert déjà tous les alias de modèles — porte aussi un registre d'agents. Ce qu'il apporte n'est pas le protocole : c'est tout ce qu'on ne veut pas réécrire dans chaque agent.

flowchart LR
    subgraph consommateurs
        s["Script · cron"]
        w["Moteur de workflows"]
        c["Interface de chat"]
        a2["Un autre agent"]
    end

    p["Proxy LLM<br/>registre + identité + limites + dépense"]
    ag["Agent<br/>serveur A2A"]
    m["Modèles<br/>locaux · souverains · API"]

    s --> p
    w --> p
    c --> p
    a2 --> p
    p -->|"A2A : message/send"| ag
    p -->|"OpenAI : chat/completions"| m
    ag -->|"ses propres appels,<br/>avec SA clé"| p

Ce que le proxy apporte	Ce que ça évite
Un annuaire — la liste des agents, leur carte, leurs compétences	chacun tient sa propre liste, et elles divergent
Une identité — une clé virtuelle par agent	une seule clé partagée, donc une dépense qu'on ne sait imputer à personne
Des limites — débit par agent, liste blanche de modèles, budget	un agent qui part en boucle emporte le budget de tout le monde
La dépense — chaque appel écrit sa ligne	un coût qu'on répartit au prorata, donc un coût inventé
Deux façades — protocole A2A et API de chat classique	réécrire un client pour chaque agent

Les deux façades, et c'est le point important

Un agent enregistré est joignable de deux manières, sans rien changer côté agent :

• en A2A, à /a2a/<id>/message/send — c'est le protocole, avec sa carte et son cycle de tâche ;
• en API de chat, en demandant simplement le modèle a2a/<nom> sur /v1/chat/completions.

La deuxième est celle qui compte en pratique : toute application du parc qui sait parler à un modèle sait alors parler à l'agent, sans une ligne de code. L'interface de chat, le moteur de workflows, un script de trois lignes — ils voient un nom de modèle de plus dans la liste.

Le pont fonctionne aussi dans l'autre sens : un agent enregistré peut n'être qu'un modèle avec des limites, et le proxy lui fabrique une façade A2A.

Ce qui est vrai aujourd'hui, et ce qui ne l'est pas

Un registre d'agents externes

Le registre attend des agents qui écoutent déjà quelque part : un serveur A2A, ou une plateforme d'agents commerciale. Il n'existe aucun type « programme en ligne de commande ».

Conséquence directe pour le parc : un agent qui est un claude -p lancé sur une machine ne devient joignable par les autres que si on lui met un serveur A2A devant. Tant que ce serveur n'existe pas, le registre sert de référence de définition — ce qui est déjà beaucoup — mais pas de point d'appel, et l'URL annoncée sur sa carte ne répond pas.

Un registre qui oublie au redémarrage

La liste d'agents que sert le proxy vit en mémoire, et n'est pas relue depuis la base quand le processus repart. Après un redémarrage, les agents existent toujours mais la liste est vide — et la résolution de a2a/<nom>, qui lit ce même registre, s'arrête pour tous les consommateurs. Un contrôle périodique qui réapplique les définitions referme le trou ; sans lui, la panne est silencieuse et le service a l'air en pleine santé.

La suite du geste, champ par champ : Définir un agent et le consommer.

Dernière vérification de cette page : 2026-09-13