A2A Protocol fait communiquer des agents IA via HTTP, JSON-RPC et SSE, sans recoder chaque intégration à la main. Le vrai sujet, c’est l’orchestration fiable entre agents hétérogènes, avec découverte, authentification, tâches structurées et streaming quand le traitement prend du temps.
Pourquoi A2A évite le code maison ?
A2A Protocol évite une partie du code maison parce qu’il donne un cadre commun aux agents IA pour se découvrir, se comprendre et coopérer. C’est exactement le genre de sujet qui paraît technique au départ, mais qui devient très concret dès qu’on essaie de faire bosser plusieurs agents ensemble.
Construire un agent aujourd’hui, ce n’est plus le plus dur. On peut assez vite brancher un modèle, lui donner des outils, une base de connaissances, quelques règles métier, et obtenir quelque chose d’utile. Là où ça se complique, c’est quand cet agent doit parler à un autre agent, puis à un troisième, puis à un service interne déjà en place.
Chaque agent arrive souvent avec sa propre façon de fonctionner. Son API, ses formats de données, ses règles d’authentification, ses limites, son rythme d’exécution. J’ai vu ça chez des clients : au début, on écrit juste “un petit connecteur”. Puis un deuxième. Puis une couche d’adaptation. Puis une règle spéciale parce que tel agent répond en streaming, tel autre en JSON structuré, tel autre exige un token différent. Et là, on se retrouve avec de la glue logic partout. La glue logic, c’est tout ce code qui ne porte pas vraiment de valeur métier, mais qui sert juste à faire tenir les morceaux ensemble.
Intégrez l’IA Générative (GenAI) dans votre activité
Nos formations IA Générative (GenAI) et prompt engineering sont conçues pour les équipes qui veulent apprendre à exploiter les IA comme un pro. Vous y apprenez à structurer des prompts efficaces, à exploiter les meilleurs outils (assistants IA type ChatGPT, générateurs d’images, audio et vidéo) et à les appliquer à vos vrais cas métiers : analyser vos données (GA4, BigQuery, CRM…), produire des contenus clairs et crédibles, prototyper plus vite et automatiser les tâches répétitives. Des ateliers 100 % pratiques, pensés pour les entreprises, pour gagner du temps, sécuriser vos usages et livrer des analyses et supports de décision de niveau pro.
A2A Protocol, introduit par Google en avril 2025 comme standard ouvert pour les échanges agent-to-agent, vient réduire ce bazar. L’idée n’est pas de remplacer tous les frameworks d’agents. L’idée, c’est de standardiser la manière dont les agents exposent leurs capacités, reçoivent des demandes, renvoient des résultats et gèrent une collaboration.
Concrètement, ça aide sur plusieurs points :
- Interopérabilité : Un agent compatible A2A peut plus facilement travailler avec un autre agent compatible, même s’ils n’ont pas été développés avec les mêmes outils.
- Moins de code personnalisé : Les équipes évitent d’écrire un connecteur spécifique pour chaque combinaison d’agents.
- Maintenance plus simple : Quand un agent évolue, on limite les effets de bord sur toute l’architecture.
- Sécurité plus propre : A2A s’intègre plus naturellement avec des modèles d’authentification et d’autorisation déjà utilisés en entreprise.
- Développement accéléré : L’Agent Development Kit de Google, et d’autres bibliothèques compatibles, peuvent aider à créer des agents directement alignés avec le protocole.
Pour moi, le vrai intérêt est là : on arrête de réinventer la plomberie à chaque projet. Une fois le besoin posé, il faut regarder comment les agents se parlent vraiment.
Comment les agents échangent ?
Les agents échangent via HTTP pour le transport, JSON-RPC pour les messages structurés et SSE pour recevoir des mises à jour en streaming.
HTTP, c’est la base simple. L’agent client envoie une requête à un agent remote, comme n’importe quel service web. C’est pratique parce que ça passe déjà dans les infrastructures existantes : API gateway, proxy, logs, authentification, firewall… On ne réinvente pas Internet pour faire parler deux agents.
JSON-RPC ajoute la forme du message. Il dit clairement quelle méthode appeler, avec quels paramètres, quel identifiant de requête, puis comment renvoyer un résultat ou une erreur. Rien de magique. Juste une convention propre pour éviter les échanges flous. Un message peut ressembler à ça : { « jsonrpc »: « 2.0 », « id »: « task-42 », « method »: « create_analysis », « params »: { « period »: « last_30_days » } }.
SSE, pour Server-Sent Events, sert quand la tâche prend du temps. Au lieu de demander toutes les deux secondes “C’est fini ?”, l’agent client ouvre un flux et reçoit les mises à jour au fil de l’eau. J’ai déjà vu ça côté automatisation reporting, ça évite beaucoup de bruit inutile et ça rend le workflow plus propre.
Le point important, c’est que l’échange est asynchrone. Un agent peut envoyer une tâche à un autre agent, continuer son travail, puis récupérer les événements quand ils arrivent. L’agent client demande une action. L’agent remote exécute. Mais ces rôles ne sont pas fixes. Dans un workflow réel, l’agent analytics peut devenir client à son tour s’il demande à un agent data engineering de nettoyer une table.
Un exemple simple : un agent marketing demande à un agent analytics de préparer une analyse de campagne. L’agent analytics lance le calcul, récupère les données, produit les métriques. Pendant ce temps, un autre agent surveille les mises à jour en SSE : “Analyse démarrée”, “Données chargées”, “Segmentation terminée”, “Rapport prêt”. Personne ne bloque, personne ne spamme l’API.
| Brique | Rôle |
| HTTP | Transporte les requêtes entre agents avec une base web standard et compatible. |
| JSON-RPC | Structure les appels, les paramètres, les résultats et les erreurs. |
| SSE | Diffuse les mises à jour d’une tâche longue sans requêtes répétées. |
Quels composants rendent ça fiable ?
A2A devient fiable parce qu’il formalise les agent cards, les tasks, les messages, les parts et le transport. C’est ça qui transforme une discussion entre agents IA en vrai contrat d’échange, pas juste en “prompt envoyé quelque part”.
Les agent cards, ce sont les fiches descriptives des agents. Elles exposent l’identité de l’agent, ses capacités, les tâches qu’il accepte, ses endpoints, c’est-à-dire les adresses où l’appeler, et ses exigences d’authentification. En clair, avant de parler à un agent, je sais qui il est, ce qu’il sait faire, comment le joindre et avec quels droits. Ça sert à la découverte, mais aussi à la validation des permissions. Un agent ne devrait pas pouvoir demander n’importe quoi à n’importe qui.
Les tasks sont les unités de travail. Une task décrit le payload, donc les données envoyées, le résultat attendu, les limites, les quotas et le contexte. C’est là que beaucoup de systèmes deviennent propres ou complètement bancals. Si je demande “analyse ce fichier”, ce n’est pas suffisant. Quel fichier ? Quel format ? Quel niveau de détail ? Quel délai ? Quelle sortie attendue ? Une tâche bien décrite évite les malentendus entre agents, surtout quand plusieurs outils ou modèles interviennent dans la chaîne.
Les messages et les parts structurent l’échange. Les messages sont généralement des objets JSON, donc un format texte organisé en clés et valeurs. Les parts découpent le contenu en morceaux clairs : instructions, métadonnées, contenu utile, fichiers, références, résultats intermédiaires. Un message mal formé peut casser le contexte, déclencher une erreur, ou pire, produire une mauvaise exécution sans que ça se voie tout de suite.
Le transport et le streaming assurent la circulation. HTTP sert souvent de base parce que c’est simple, standard et bien compris. Des brokers peuvent être ajoutés selon l’architecture, par exemple pour gérer des files d’attente ou découpler les services. SSE, pour Server-Sent Events, permet d’envoyer des updates temps réel depuis le serveur vers le client. Pratique quand une tâche dure plusieurs secondes ou minutes.
Sur le terrain, dans les projets d’automatisation, les erreurs viennent rarement du modèle IA seul. Elles viennent souvent de contrats d’échange flous. Des champs ambigus, des permissions implicites, des formats “à peu près”. Et ça, A2A essaie justement de le verrouiller.
| Composant | Rôle | Risque si c’est mal défini |
| Agent cards | Décrire l’identité, les capacités, les endpoints et l’authentification | Appel du mauvais agent, accès non autorisé, découverte fragile |
| Tasks | Définir le travail attendu, le contexte, les limites et les quotas | Résultat hors sujet, dépassement de ressources, mauvaise interprétation |
| Messages et parts | Structurer les instructions, données, métadonnées et contenus utiles | Contexte cassé, erreur technique, exécution incorrecte |
| Transport et streaming | Faire circuler les échanges via HTTP, brokers ou SSE | Latence, perte d’état, absence de suivi temps réel |
Comment ça tient en production ?
En production, A2A tient si la découverte, l’authentification, les permissions, les erreurs et le suivi des tâches sont traités proprement.
Le déroulé naturel est assez simple. Un agent client a besoin d’un service. Il commence par chercher un agent remote adapté grâce aux agent cards. Une agent card, c’est une fiche descriptive lisible par machine. Elle dit grosso modo : voici ce que je sais faire, voici comment me contacter, voici mes contraintes, voici mes modes d’authentification. Sans découverte fiable, le workflow échoue avant même d’exécuter quoi que ce soit. J’ai déjà vu ça chez un client avec des intégrations “maison” : le problème n’était pas l’IA, c’était juste que personne ne savait quel agent appeler, ni avec quel contrat.
Une fois le bon remote trouvé, il faut passer à l’authentification. Les agents doivent prouver leur identité. Ils doivent aussi respecter les mécanismes de sécurité existants, pas les contourner parce que “c’est de l’IA”. C’est un point important pour les équipes techniques. Elles peuvent raccrocher A2A à des pratiques connues côté sécurité et gouvernance : jetons, scopes, IAM, politiques d’accès, audit. IAM veut dire Identity and Access Management, donc la gestion des identités et des droits.
Ensuite, le client envoie une task claire. La task décrit ce qu’il faut faire, avec le contexte nécessaire. Le remote exécute, puis renvoie des statuts, des résultats ou des événements. Si le traitement dure longtemps, il peut utiliser des messages et du SSE. SSE veut dire Server-Sent Events. C’est un canal où le serveur pousse des mises à jour au client, pratique pour suivre une tâche sans attendre la fin complète.
- La découverte évite d’appeler le mauvais agent.
- L’authentification évite d’ouvrir une porte de côté.
- Les permissions cadrent ce que chaque agent peut faire.
- Les statuts rendent le workflow observable.
- Les erreurs permettent de reprendre proprement, ou d’arrêter sans casser le reste.
Il faut être clair. A2A ne rend pas automatiquement un système fiable. Il impose un contrat plus propre. Il faut quand même superviser les erreurs, les quotas, les droits, les logs, les temps de réponse et les cas où un agent ne répond pas. ADK et les bibliothèques compatibles accélèrent la mise en place, oui. Mais ce n’est pas une baguette magique.
Le vrai gain arrive quand les équipes arrêtent de bricoler des connecteurs isolés et commencent à concevoir des workflows multi-agents lisibles, testables et gouvernables.
Et si vos agents arrêtaient de travailler en silo ?
Si je devais résumer simplement, A2A Protocol répond à un problème très concret : faire coopérer plusieurs agents IA sans multiplier les connecteurs bricolés. Le protocole s’appuie sur des briques connues comme HTTP, JSON-RPC et SSE, puis structure les échanges avec des agent cards, des tasks, des messages et des parts. Ça ne supprime pas le besoin d’architecture, de sécurité ou de supervision. Mais ça donne un langage commun aux agents. Pour une équipe data, IA ou automation, le bénéfice est clair : moins de code jetable, plus d’interopérabilité, et des workflows multi-agents plus faciles à maintenir.
FAQ
- Qu’est-ce que A2A Protocol ?
A2A Protocol est un standard ouvert introduit par Google pour permettre à des agents IA de communiquer et de coopérer. L’idée est simple : au lieu de créer un connecteur spécifique pour chaque agent, on utilise un cadre commun basé sur HTTP, JSON-RPC et SSE. - À quoi servent les agent cards dans A2A ?
Les agent cards décrivent ce qu’un agent sait faire, les tâches qu’il accepte, ses informations d’accès et ses contraintes d’authentification. Elles servent surtout à la découverte. Un agent client peut identifier le bon agent remote avant de lui confier une tâche. - Pourquoi A2A utilise JSON-RPC ?
JSON-RPC permet de structurer les appels entre agents avec des méthodes, des paramètres, des résultats et des erreurs. C’est utile parce qu’un agent ne peut pas juste envoyer du texte libre à un autre agent en espérant que tout se passe bien. Il faut un contrat clair. - Quel est le rôle de SSE dans A2A Protocol ?
SSE permet de recevoir des mises à jour en streaming pendant une tâche longue. L’agent client peut suivre l’avancement sans recréer des requêtes en boucle. C’est pratique pour les workflows où un agent remote analyse, calcule, interroge des outils ou produit un résultat en plusieurs étapes. - A2A Protocol suffit-il pour sécuriser des agents IA ?
A2A aide à structurer les échanges, mais il ne remplace pas une vraie stratégie de sécurité. Il faut gérer l’authentification, les permissions, les quotas, les erreurs et les logs. Le bon réflexe, c’est de l’intégrer aux mécanismes de sécurité déjà utilisés par l’entreprise.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation très opérationnels. Si vous voulez structurer vos workflows IA, connecter vos outils proprement ou passer d’un prototype à quelque chose de maintenable, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.