Technique
Votre agent va sous-traiter à d’autres agents
Oui, et c’est déjà normalisé : plus de 150 organisations derrière A2A en un an. Un agent expert s’appelle comme un outil, à condition qu’il ne retienne rien de vous.
Oui, et le sujet est déjà sorti du laboratoire. Le protocole qui décrit comment un agent en appelle un autre est passé de cinquante à plus de cent cinquante organisations en un an, il est intégré chez Microsoft, AWS et Google, et il tourne en production dans la logistique, l’assurance et les services financiers.
Ce qui se met en place n’est pas une nouvelle catégorie de logiciel, c’est un marché de compétences appelables. Un agent qui a besoin d’un avis très pointu sur un sujet étroit n’aura pas à l’apprendre ni à intégrer l’outil de quelqu’un : il appellera l’agent qui sait, comme on passe aujourd’hui un coup de fil à un confrère.
Ce qui distingue un outil d’un agent qu’on appelle
La différence tient en une question, et elle est plus discriminante qu’elle n’en a l’air : est-ce que j’invoque une capacité, ou est-ce que je confie une exécution ?
MCP répond au premier cas. On appelle une fonction, elle fait une chose précise, elle rend un résultat dont la forme est connue à l’avance. C’est un raccordement, et c’est ce à quoi ressemblent aujourd’hui plus de huit déploiements en production sur dix : un agent, plusieurs serveurs d’outils.
A2A répond au second. On décrit un but à un autre agent, qui décide lui-même des étapes, peut demander des précisions en cours de route, et rend un résultat dont vous ne connaissiez pas la trajectoire. La découverte passe par une carte d’agent, un document qui déclare ce qu’il sait faire et comment le joindre, ce qui rend l’annuaire possible.
Cette différence n’est pas une subtilité de protocole, c’est le point où la responsabilité se déplace. Un outil qui échoue rend une erreur ; un agent à qui vous avez délégué une exécution rend une décision, et il l’a prise avec des informations que vous ne verrez jamais.
Pourquoi cela ne contredit pas « un agent, pas douze »
Nous avons écrit il y a peu qu’il valait mieux un agent bien outillé que douze qui ne se parlent pas, et un lecteur attentif pourrait y voir l’inverse de ce qui précède. La contradiction n’existe pas, et la lever demande de nommer précisément ce qui posait problème.
Ce que nous reprochons aux douze agents n’est pas leur nombre, c’est que chacun prétend connaître votre entreprise. Douze agents installés par douze éditeurs, ce sont douze copies de vos règles, de vos clients et de votre historique, qui vieillissent chacune à sa vitesse et divergent sans jamais le signaler.
Un agent expert externe est exactement le cas inverse. Il ne connaît pas votre entreprise, il ne cherche pas à la connaître, et c’est précisément ce qui le rend utilisable : il détient un domaine, pas une version de votre vérité. Il reçoit une question, rend une réponse, et ne retient rien.
Le critère se formule donc ainsi, et il tranche les deux situations avec la même phrase : un agent qui détient du contexte sur vous doit être unique, un agent qui détient une expertise peut être appelé autant qu’on veut. Le premier est un collègue, le second est un consultant qu’on paie à la question.
À quoi ça ressemble concrètement dans une ESN
Prenez la vérification d’identité et de références, sujet devenu sérieux depuis que la fraude candidat a changé d’échelle. Maintenir en interne la compétence nécessaire pour détecter une identité fabriquée n’a aucun sens pour une société de trente personnes, et l’acheter sous forme d’un logiciel de plus n’en a guère plus. L’appeler à la demande, sur les seuls dossiers qui vont jusqu’à la signature, est la forme qui correspond au besoin.
Prenez la conformité du détachement dans un pays où vous placez deux consultants par an. La règle change, vous ne la suivez pas, et personne chez vous ne peut raisonnablement la suivre. Un agent tenu à jour par quelqu’un dont c’est le métier répondra mieux que le vôtre, et il répondra à la question posée sans avoir besoin de connaître le reste de votre activité.
Prenez enfin la qualification technique très pointue, sur une pile que vous rencontrez rarement. Ce n’est pas de l’automatisation d’un travail existant, c’est l’accès à un avis que vous n’aviez pas les moyens de vous offrir, et c’est le cas d’usage le plus intéressant parce qu’il ne remplace personne chez vous.
Le point commun des trois mérite d’être retenu, parce qu’il donne la règle de sélection. Ce sont des expertises trop étroites pour être internalisées, trop mouvantes pour être figées dans un logiciel, et que vous achetiez déjà à des humains quand vous en aviez besoin.
Ce que les protocoles ne disent pas, et c’est l’essentiel
Une lecture attentive de la recherche récente sur ces protocoles donne une liste inconfortable. Ni MCP, ni A2A, ni leurs concurrents ne savent exprimer sept choses : la limite de la délégation, la responsabilité, la révocation d’un droit accordé, la provenance d’une information, le consentement, les contraintes de durée et la procédure d’escalade.
Autrement dit, ils décrivent parfaitement comment deux agents se parlent, et pas du tout ce qui se passe quand la conversation tourne mal. Un appel réussi est bien spécifié ; un appel dont le résultat est faux, tardif, ou fondé sur une donnée qu’il n’aurait pas dû utiliser ne l’est pas.
C’est exactement le raisonnement que nous tenions sur MCP, et il vaut la peine de le répéter parce que l’enthousiasme est le même. Un protocole commun est un critère de sortie, pas un critère d’achat : il rend le raccordement possible et il ne décide rien de ce qui compte. Le fait qu’un agent tiers parle votre langue ne vous dit pas s’il faut l’écouter.
Les quatre questions à poser avant d’appeler un agent tiers
Que voit-il ? Il voit ce que vous lui envoyez, ce qui fait de la formulation de l’appel une décision d’architecture et pas un détail d’implémentation. Envoyer une question fermée avec le strict nécessaire, ou envoyer le dossier entier pour qu’il ait le contexte, sont deux systèmes différents dont un seul se défend devant un client.
Que retient-il ? La bonne réponse est rien. Un agent tiers qui mémorise vos appels devient un endroit de plus où votre vérité existe, et vous connaissez le coût d’une mémoire que personne ne surveille. S’il retient, ce n’est plus un consultant, c’est un sous-traitant, avec le contrat et le registre qui vont avec.
Qui répond devant le client ? Vous, et la chaîne technique n’y change rien. Votre contrat de prestation ne connaît pas les fournisseurs de vos fournisseurs, et l’AI Act fait porter au déployeur des obligations réelles même quand il n’a rien construit.
Comment on coupe ? C’est la question qu’on oublie, et c’est la seule qui compte le jour d’un incident. Si la réponse suppose d’appeler un support ou de modifier une configuration que vous ne maîtrisez pas, vous n’avez pas de bouton d’arrêt, vous avez une intention d’arrêt.
Ce que ça fait au prix, et pourquoi c’est le point dur
Un agent tiers se facture à l’appel, et un appel qui échoue se facture aussi. Vous ajoutez donc à votre coût de revient une ligne dont le volume dépend de décisions prises par votre propre agent, qui est déjà le poste le plus difficile à prévoir.
Il faut reconnaître ici une tension avec ce que nous défendons par ailleurs. Nous écrivons que le prix doit porter sur le travail rendu plutôt que sur les unités consommées, et une chaîne d’agents facturés à l’appel pousse mécaniquement dans l’autre sens, parce que chaque maillon veut se faire payer ce qu’il consomme.
Notre lecture est que cette tension se résout par le périmètre plutôt que par le modèle de prix. Un agent tiers appelé sur les seuls dossiers qui vont jusqu’à la signature représente un volume prévisible et un coût qu’on peut annoncer ; le même agent appelé à chaque hésitation devient une ligne que personne ne sait budgéter. La discipline est chez l’appelant, elle ne viendra pas du protocole.
Ce que nous avons décidé pour Balt
Trois choses, et elles découlent toutes de ce qui précède plutôt que d’une intuition sur le marché.
Nous exigeons la compatibilité sans construire dessus tout de suite. Le protocole est prêt et la gouvernance ne l’est pas, donc la position raisonnable est de pouvoir brancher un expert le jour où il existe et vaut la peine, pas d’en brancher un pour l’annoncer.
Un agent tiers reçoit une question, jamais un dossier. C’est une contrainte que nous nous imposons à l’écriture de chaque appel, et elle a un coût réel en qualité de réponse que nous acceptons, parce que l’alternative revient à faire sortir de la matière client sans que personne l’ait décidé.
Enfin, rien de ce qu’un agent tiers produit ne part vers l’extérieur sans qu’une personne le libère. C’est la règle qui vaut déjà pour tout ce qui sort de l’entreprise, et le fait que la phrase ait été écrite par l’agent de quelqu’un d’autre est une raison de la maintenir, pas une raison de l’assouplir.
Ce qui vient ensuite est la question de la confiance entre agents : comment savoir que celui qu’on appelle est bien celui qu’il prétend être, et ce qu’on fait quand deux agents ont agi sur le même dossier sans se voir. Aucun protocole ne répond aujourd’hui, et c’est là que se jouera la prochaine génération d’incidents.
Questions fréquentes
Quelle différence entre MCP et A2A ?
MCP décrit comment un agent se raccorde à un outil : une fonction est appelée, elle rend un résultat prévisible. A2A décrit comment un agent confie une tâche à un autre agent, qui décide lui-même de la façon de la mener. La bonne question devant un tiers est donc : est-ce que j’invoque une capacité, ou est-ce que je délègue une exécution ?
Un agent tiers voit-il mes données ?
Il voit ce que vous lui envoyez, et rien d’autre, ce qui fait de la formulation de l’appel une décision de conception. Envoyer une question fermée avec le strict nécessaire et envoyer le dossier complet « pour qu’il ait le contexte » sont deux architectures différentes, dont une seule reste défendable devant un client.
Qui est responsable si l’agent d’un tiers se trompe ?
Vous, devant votre client, et c’est la réponse courte qui compte. L’AI Act fait peser sur le déployeur des obligations substantielles même lorsqu’il n’a rien construit, et votre contrat de prestation ne connaît pas les sous-traitants de votre fournisseur. La chaîne technique est distribuée, la responsabilité commerciale ne l’est pas.
Faut-il s’y mettre maintenant ?
Le protocole est prêt et la gouvernance ne l’est pas, donc la bonne posture est d’exiger la compatibilité sans construire dessus tout de suite. Traitez-la comme une garantie de sortie, exactement comme MCP : ce qui compte est de pouvoir brancher un expert le jour où il existe, pas d’en brancher un aujourd’hui.
Sources
- Linux Foundation, A2A protocol surpasses 150 organizations and sees enterprise production use in first year, avril 2026linuxfoundation.org
- arXiv, Governance gaps in agent interoperability protocols : what MCP, A2A and ACP cannot expressarxiv.org
- Linux Foundation, Launch of the Agent2Agent protocol projectlinuxfoundation.org
À lire ensuite
Vision
La fin des interfaces, pas la fin du logicielChez Supabase, 60 % des nouvelles bases sont lancées par un agent, et probablement 90 %. Ce qui meurt n’est pas le logiciel : c’est la couche d’accès.Produit
Douze agents qui ne se parlent pasUne entreprise fait tourner douze agents en moyenne et la moitié travaillent seuls. Le bon critère n’est pas leur nombre, c’est le nombre de contextes dupliqués.Produit
Faut-il exiger que votre agent IA parle MCP ?MCP est une vraie bonne nouvelle, mais ce n’est pas un critère d’achat. C’est un critère de sortie : ce qui compte est le jour où vous changez d’outil.
