La couche agentique

Les agents forment la troisième famille de trafic d’une plateforme, à côté des API et des événements. La page gateway dit pourquoi les trois se gouvernent ensemble. Celle-ci regarde l’aval : un agent appelle un outil, un autre agent, ou un modèle, et les trois ne posent pas le même problème.

Agent

Le consommateur

Ce qu’il appelle

Un outil

mcp

Un autre agent

a2a

Un modèle

llm

Ce qui mérite d’être su, protocole par protocole

MCP a été réécrit pour l’intermédiaire. Depuis sa révision du 28 juillet 2026, le protocole n’a plus de session. Chaque requête se décrit elle-même et porte ses credentials. Une gateway décide donc sur ce qu’elle voit, appel par appel, au lieu de faire confiance à un état qu’elle ne détient pas.

Un serveur peut même demander que certains paramètres d’outil soient recopiés en en-têtes HTTP. Le routage et les policies se font alors sans ouvrir le corps de la requête. Rien de sensible n’a sa place dans ces en-têtes, qui sont visibles de tous les intermédiaires.

Découvrir n’emporte pas le droit d’invoquer. Le catalogue est lu au début d’une tâche, l’invocation arrive des dizaines d’appels plus tard. Ce sont deux décisions, sur deux jeux de données. La liste se filtre selon l’identité qui la demande. L’appel s’autorise sur la donnée demandée, pas sur l’outil. Le détail est dans accès.

Deux identités voyagent, pas une. Un agent agit pour le compte de quelqu’un sans être ce quelqu’un. Faire suivre le jeton de l’utilisateur donne à l’agent toutes ses portées. Ne garder que l’identité de l’agent fait perdre l’utilisateur à l’audit. La mécanique correcte est le token exchange, décrit dans accès.

A2A ne se juge pas sur ses annonces. Le protocole est passé sous gouvernance Linux Foundation, en version 1.0, avec des Agent Cards signées et plus de cent cinquante organisations déclarées. Les chiffres de déploiement, eux, ne sont pas publiés, là où MCP se compte en milliers de serveurs. C’est à évaluer, pas à supposer.

Ce qu’A2A change vraiment, c’est le périmètre. Le chemin d’appel sort de chez vous, et un agent tiers exécute une tâche que vous n’observez plus. Deux exigences en découlent. L’audit doit porter la chaîne entière et pas le dernier saut. Et une opération irréversible ne peut pas dépendre d’un enchaînement décidé ailleurs.

L’appel de modèle change l’unité de compte. Deux appels de même méthode et de même chemin peuvent différer d’un facteur mille en coût. Un quota par appel ne dit plus rien. La limite utile se compte en jetons, et porte sur la tâche autant que sur l’appel, parce qu’une boucle d’agent respecte tous les quotas par appel.

Ce que le comptage en jetons demande vraiment

Le nombre de jetons d’une réponse n’est connu qu’à la fin, et les réponses de modèles arrivent en flux. Un compteur cohérent exige donc un état partagé entre toutes les instances de la gateway. C’est une question à poser à l’éditeur, pas une case à cocher dans une grille.

L’attribution vaut le comptage. Un budget sans propriétaire ne se défend pas en comité. Ce qui doit sortir : quelle équipe, quel agent, quel modèle, quel coût, à quelle date. Le reste de la mécanique est dans observabilité.

Deux décisions d’exploitation se prennent à froid, jamais pendant l’incident. Ce que fait la gateway quand le service de budget est indisponible, laisser passer ou refuser. Et ce qu’elle fait d’un modèle qu’elle ne connaît pas et dont elle ne sait pas le prix.

La gateway d’IA lit le corps

C’est la seule différence de fond avec une gateway d’API, et elle explique tout le reste. Une gateway d’API achemine sans lire le corps. Une gateway d’IA lit le prompt et la réponse. C’est ce qui rend possibles le comptage en jetons, le cache sémantique et le filtrage de contenu.

C’est aussi ce qui coûte. Le budget de temps propre d’une gateway se chiffre en quelques millisecondes, et l’inspection d’un corps volumineux n’y tient pas. Un cache sémantique ajoute en plus un calcul d’empreinte avant de répondre. La question à trancher est donc d’architecture, pas de configuration : ce trafic passe-t-il par la même chaîne de policies que vos API, ou par un chemin dédié ?

La réponse honnête dépend des volumes, et elle se mesure. Ce qui ne se discute pas, c’est le control plane : un catalogue, une identité de consommateur, des policies communes. Trois produits disjoints redonnent trois catalogues et trois systèmes d’identité.

Le piège commun

La frontière de confiance ne se décale pas d’un cran, elle change de côté. Un agent lit ce que l’API lui renvoie et le traite comme du contexte. La description d’un outil est vérifiée une fois, à la connexion. La réponse, elle, ne l’est jamais.

Un tiers qui écrit dans un champ libre de vos données place donc du texte dans le raisonnement d’un agent, sans avoir jamais touché à votre plateforme. Le contrôle d’accès de l’appelant, seul, ne voit pas passer cette attaque.

Trois mesures se posent à la gateway. Marquer les champs qui contiennent du texte non maîtrisé, pour qu’un agent puisse les traiter comme des données. Plafonner la taille et le nombre d’éléments retournés, parce qu’une exfiltration passe par des réponses volumineuses. Et exiger une confirmation humaine en amont de toute opération irréversible, parce que dans la gateway elle n’est pas facultative.

Les annotations du protocole, qui signalent qu’un outil est en lecture seule ou destructeur, ne remplacent pas cette confirmation. Ce sont des indications à destination du client, et la spécification demande elle-même de les tenir pour non fiables. Une frontière de sécurité se tient là où le trafic passe, pas là où on l’a annoncée.