Comment des agents IA indépendants coopèrent : un pont A2A pour Hermes Agent

Ce que cela signifie pour votre entreprise

• Vos agents coopèrent sans réécriture. L'Agent2Agent Protocol (A2A) est un standard ouvert permettant aux agents IA de se découvrir, de se déléguer du travail et de se transmettre des résultats en flux continu. Un fin pont permet à un agent existant de parler ce standard sans changer son intérieur : vous conservez l'investissement déjà consenti.
• Aucune dépendance au fournisseur. Comme le pont se situe entre le standard et l'agent, vous pourrez plus tard remplacer le framework d'agent sous-jacent sans casser les intégrations bâties dessus. Les autres équipes continuent d'appeler le même point d'accès standard.
• Un seul système sert de nombreux clients ou unités métier, avec une séparation stricte des données. L'isolation entre locataires est appliquée au niveau de la base de données, et pas seulement dans le code applicatif ; une erreur de programmation ne peut donc pas divulguer les données d'un client à un autre. C'est la différence qui résiste à un audit de sécurité.
• Les humains gardent le contrôle des actions sensibles. Lorsqu'un agent a besoin d'une approbation — un achat, une décision d'accès aux données, la validation d'un devis — la demande apparaît sous la forme d'un état standard « en attente d'approbation » qui remonte jusqu'à la personne ou l'agent ayant initié la chaîne, même par-delà les frontières de frameworks.
• C'est réel et testé, pas une diapositive. L'ensemble est empaqueté sous forme de déploiement open source (docker-a2a-hermes-agent-gateway) avec une suite de tests automatisés qui prouve chaque capacité avant que vous n'en dépendiez.

Le problème : des agents qui ne peuvent pas se parler

La plupart des organisations n'adoptent pas « un agent IA ». Elles en accumulent plusieurs. Un agent de devis ici, un agent de consultation de catalogue là, un agent d'inventaire appartenant à une autre équipe — souvent construits sur des frameworks différents, parfois auprès de fournisseurs différents, à des moments différents. Individuellement, ils fonctionnent. Le goulot d'étranglement, c'est de les faire coopérer : confier du travail à un autre, attendre un résultat et rendre la main.

Résoudre cela en câblant à la main chaque agent à tous les autres est lent, fragile, et empire à chaque nouvel agent. Cela enferme aussi en silence : dès que les intégrations sont codées en dur sur l'interface d'un fournisseur, remplacer ce fournisseur impose de toutes les refaire.

L'Agent2Agent Protocol (A2A) est le standard ouvert qui supprime ce goulot. Il définit un langage commun permettant aux agents de se découvrir, de se déléguer des tâches, de transmettre leur progression et de signaler leur achèvement, quel que soit le socle de chacun. Adoptez le standard une fois, et chaque nouvel agent parle le même langage que les autres.

Le hic : vos agents existants ne parlent pas A2A nativement. Hermes Agent de Nous Research, par exemple, expose sa propre interface. Réécrire un agent qui fonctionne pour y ajouter un nouveau protocole est exactement le type de projet coûteux et risqué que les équipes veulent éviter.

La réponse est un pont — une petite couche de traduction qui parle A2A à l'extérieur et dialogue avec l'agent dans son propre langage à l'intérieur. L'agent ne change jamais. Le projet docker-a2a-hermes-agent-gateway est un exemple fonctionnel et open source de ce pont, empaqueté pour s'exécuter comme une unité déployable unique.

Comment les pièces s'emboîtent

Il y a trois pièces en mouvement, et une seule est exposée au monde extérieur :

1. La porte d'entrée (la passerelle). Tout entre par un unique point d'accès contrôlé. Elle décide qui peut entrer, à quel client appartient une requête, à quelle vitesse les appelants peuvent aller et comment la progression en direct est renvoyée. Rien d'autre n'est accessible directement.
2. Le traducteur (le pont). Il reçoit les requêtes dans le standard ouvert A2A et les traduit vers ce que votre agent comprend réellement, puis retraduit la réponse. C'est la seule pièce qui connaît quoi que ce soit de l'agent concret, ce qui est précisément la raison pour laquelle l'agent peut être remplacé plus tard.
3. L'agent et son registre de travail. Votre agent existant assure le raisonnement réel. Tout ce qu'il fait est consigné — chaque tâche et chaque message — en le maintenant strictement séparé par client.

Comme la porte d'entrée et le registre sont indépendants de l'agent lui-même, vous pouvez garder la passerelle dans votre propre cloud et la pointer vers un agent s'exécutant ailleurs, ou vers une base de données gérée de votre choix. Rien n'oblige les trois à se trouver au même endroit.

Adoptez le standard sans réécrire vos agents

La propriété la plus précieuse ici est que votre agent ne change jamais. Le traducteur assume tout le travail de parler le standard à sa place.

Cela a deux conséquences métier directes :

• Vous protégez l'investissement déjà consenti. L'équipe qui a construit l'agent de devis ne s'arrête pas pour le réusiner en vue d'un nouveau protocole. Elle ajoute un pont et poursuit.
• Vous évitez la dépendance dans les deux sens. Les appelants ne dépendent que du standard ouvert, pas de votre fournisseur d'agent. Si vous remplacez l'agent plus tard — un meilleur modèle, un fournisseur moins cher, une réalisation interne — vous changez le traducteur et toutes les intégrations bâties dessus continuent de fonctionner sans y toucher. Inversement, une seule passerelle peut être la façade de plusieurs agents différents à la fois : le travail à forte intensité de raisonnement routé vers l'un, les étapes de flux routinières vers l'autre, le tout paraissant identique à l'appelant. Le choix du moteur devient un détail de mise en œuvre que vous contrôlez, et non un engagement qui vous enferme.

Servez de nombreux clients ou unités métier, avec une séparation des données qui résiste à un audit

Le même déploiement peut servir de nombreux locataires — clients distincts, ou unités métier internes distinctes — depuis un seul système en fonctionnement. Chacun dispose de ses propres agents, de son propre historique de tâches et de son propre stockage de messages.

Ce qui rend cela sûr, et pas seulement commode, c'est où la séparation est appliquée. Chaque requête est étiquetée du client auquel elle appartient, et la base de données elle-même refuse de renvoyer les lignes d'un client à un autre — un contrôle appliqué dans la couche de données, sous le code applicatif. En pratique, cela signifie qu'un bogue ou un filtre oublié dans le logiciel ne peut pas divulguer de données entre clients, car le filet de sécurité est la base de données, non l'application. C'est la distinction que recherche un auditeur de sécurité ou de conformité, et celle qui vous permet de placer plusieurs clients sur une infrastructure partagée sans mettre leurs données en péril.

Gardez les humains aux commandes des actions sensibles

L'autonomie n'est acceptable que lorsqu'une personne peut intervenir aux moments qui comptent. Lorsqu'un agent atteint une étape nécessitant une validation — autoriser un achat, approuver un devis, libérer des données sensibles — il ne se contente pas de poursuivre. Il s'arrête et lève un état standard « en attente d'approbation ».

L'important est que cet état voyage. Une requête initiée plusieurs agents en amont — peut-être sur un framework totalement différent, appartenant à une autre équipe — reçoit ce même signal « entrée requise », inchangé. Une personne approuve (ou refuse) et le travail reprend. La gouvernance ne s'arrête pas à la frontière d'un agent ; le standard ouvert transporte le point d'approbation sur toute la chaîne. Pour tout flux touchant à l'argent, aux contrats ou à des données réglementées, ce contrôle de bout en bout est ce qui rend la délégation entre agents défendable plutôt qu'imprudente.

Exécutez-le là où vos données doivent résider

Le déploiement est un paquet unique et autonome qui peut s'exécuter groupé — agent, base de données et passerelle ensemble — pour un démarrage rapide, ou scindé pour la production. Vous pouvez garder la porte d'entrée contrôlée dans votre propre réseau et la pointer vers une base de données gérée (de sorte que sauvegardes, chiffrement et conformité soient assurés par votre fournisseur cloud) et vers un agent s'exécutant sur un matériel séparé.

Pour les entreprises soumises à des exigences de résidence ou de souveraineté des données, cela compte : le registre de chaque interaction d'agent peut être conservé à l'intérieur de la frontière qu'imposent vos politiques, plutôt que dans le cloud d'un tiers que vous ne contrôlez pas.

Éprouvé avant que vous n'en dépendiez

Une capacité que vous ne pouvez pas vérifier est un passif. Ce déploiement est livré avec une suite de tests automatisés qui exerce le système réel en fonctionnement de bout en bout — confirmant que les agents peuvent être découverts, que les requêtes aboutissent, que la progression en direct est correctement diffusée, qu'un client ayant manqué une mise à jour en direct peut tout de même récupérer le résultat complet, et que les échecs et annulations se comportent comme prévu. Les tests rapportent un résultat clair de réussite ou d'échec à chaque vérification et sont conçus pour s'exécuter comme une barrière automatisée, si bien qu'un changement défectueux est détecté avant d'atteindre la production, et non après.

La valeur pratique est la réduction du risque : vous ne vous fiez à la parole de personne quant au fonctionnement de l'intégration. Elle est démontrée, de façon reproductible, à chaque changement.

Ce qu'exige réellement son exécution en production

Être honnête sur le coût d'exploitation fait partie de l'argument métier. Quelques réalités à anticiper :

• Il est conçu pour tourner léger, puis monter en charge délibérément. Le réglage par défaut est un déploiement unique et simple. Servir un volume très élevé sur plusieurs copies est pris en charge, mais c'est une étape délibérée, non un accident : cela nécessite une infrastructure partagée pour que les copies restent cohérentes. Planifiez la montée en charge ; ne la supposez pas gratuite.
• Rester à jour est une routine, non une réécriture. Les composants sont récupérés depuis leurs sources open source ; se tenir à jour est donc une opération de mise à jour standard que votre équipe exécute selon un calendrier.
• La posture de sécurité vous revient. Le paquet est livré avec des mots de passe fictifs et des valeurs par défaut permissives pour démarrer facilement clés en main — ils sont censés être remplacés avant toute exposition à Internet. L'agent optionnel fourni est puissant et ne devrait s'exécuter que sur une infrastructure de confiance. Rien de tout cela n'est exotique ; c'est le durcissement normal qu'exige tout système en production, et cela doit figurer sur la liste de vérification de mise en service.

Aucun de ces points n'est bloquant. Ce sont les responsabilités ordinaires de l'exploitation d'un vrai système, et les nommer d'emblée est la façon d'éviter les surprises après le lancement.

Ce que cela permet

Mis bout à bout, le modèle de pont apporte trois choses véritablement difficiles à assembler soi-même :

1. Une coopération fondée sur des standards, sans réécriture. Tout agent parlant A2A peut travailler immédiatement avec votre agent existant — en le découvrant, en lui déléguant et en suivant sa progression — sans que cet agent soit modifié. Vous adoptez un standard ouvert tout en conservant ce qui fonctionne déjà.

2. Un service multilocataire avec une isolation réelle. Un seul déploiement sert de nombreux clients ou unités métier, la séparation des données étant appliquée au niveau de la base de données. C'est ce qui vous permet de consolider sur une infrastructure partagée sans affaiblir la sécurité.

3. Une autonomie gouvernée par-delà les frontières. Les points d'approbation humaine voyagent avec le travail, si bien que les actions sensibles bénéficient d'un humain dans la boucle, peu importe le nombre d'agents — ou de frameworks — traversés par la requête.

La mise en œuvre fonctionnelle est open source et entièrement documentée : le pont et son guide d'intégration se trouvent dans le dépôt a2a_daemon_engine (voir le guide d'intégration Hermes), et la porte d'entrée contrôlée est documentée dans le dépôt SilvaEngine Gateway. Le déploiement complet est empaqueté dans docker-a2a-hermes-agent-gateway.

Lectures associées

• MCP + A2A : les deux protocoles derrière tout système d'IA agentique en production — comment les deux standards ouverts se répartissent le travail : MCP relie les agents aux outils, A2A relie les agents entre eux
• Intégrer A2A à des frameworks d'agents existants : une démonstration avec Hermes Agent — le modèle de pont général et son application au-delà de Hermes
• Standard de code des modules MCP — la discipline qui maintient les intégrations d'agents prêtes pour la production à mesure qu'elles se multiplient

---

Un distributeur de taille moyenne a besoin d'agents de devis qui parlent à des agents de catalogue qui parlent à des agents d'inventaire, chacun construit par une équipe différente, chacun possiblement sur un framework différent. Un standard ouvert donne à ces agents un langage commun. Un pont permet aux agents que vous exécutez déjà de s'y joindre sans être reconstruits. Le résultat est un système où les agents coopèrent, où les données de chaque client restent séparées et où une personne garde le contrôle des décisions qui comptent.

Demander un développement cadré

Une semaine de découverte. Vous obtenez un inventaire du système, une carte des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.