Bienvenue dans cette nouvelle pépite de connaissants. Imaginez que vous dirigez une entreprise et que vous embauchez une équipe de brillants spécialistes, un organisateur de voyage hors pair, un expert en intégration de personnel et un technicien de support informatique. Mais aucun d'entre eux ne se parle. Chaque fois qu'une tâche nécessite l'intervention de deux d'entre eux, vous devez faire des allers-retours entre les bureaux pour transmettre l'information vous-même. C'est exactement ainsi que fonctionnent la plupart des agents et actuels. Ils travaillent de manière isolée, même lorsque le problème nécessite clairement un travail d'équipe. Aujourd'hui, nous allons donc voir comment les agents peuvent communiquer, se déléguer du travail et agir comme de véritables équipes. Je suis Mircopeter. Il ne s'agit pas d'un concept furiste. L'orchestration multi-agents est déjà une réalité. Et elle est propulsée par un protocole appelé A2A.

Nous commencerons par le problème, nous analyserons ce protocole pièce par pièce et nous verrons comment Microsoft l'utilise dans Copilot Studio et Azure AI. Prenez votre café et plongeons dans le sujet. Alors quel est le vrai problème ? Les agents IA d'aujourd'hui sont exactement comme ces spécialistes isolés. Chacun possède ses propres connaissances, ses outils et ses objectifs. Un agent météo connaît les prévisions. Un agent hôtelier connaît la disponibilité des chambres, mais il ne partage rien. Imaginez maintenant un utilisateur qui demande un voyage à Seattle la semaine prochaine avec un hôtel près du bureau. Un seul agent devrait être à la fois expert en météo, expert en voyage et expert en commerce locaux. Cela implique des promes gigantesques et complexes qui entassent toutes les capacités possibles dans un seul système et ces promes tombent constamment en panne. L'ancienne solution consistait à créer du code.

Vous deviez écrire une passerelle entre l'agent météo et l'agent hôtelier, puis une autre entre l'agent hôtelier et l'agent aérien, et encore une autre pour l'agent de calendrier. Cela fonctionne au début, mais à chaque fois que vous ajoutez un nouvel agent, vous devez construire une nouvelle intégration. Très vite vous vous retrouvez avec un cauchemar de connexion point à point où le moindre changement casse tout le système. Les gains de productivité que votre IA était censé apporter sont dévorés par le travail de maintenance, examinant la véritable difficulté pour les entreprises. Votre organisation possède déjà des processus avec des transferts de tâches. Un ticket est créé, quelqu'un le trie, quelqu'un le résout, quelqu'un l'enregistre et chaque étape est un transfert. Dans l'ancien monde, vous automatisiez chaque étape avec un agent distinct, puis vous passiez des semaines à les relier entre eux.

Mais que se passerait-il s'il existait un protocole permettant aux agents de se découvrir et de coopérer sans aucune passerelle personnalisée ? C'est exactement ce que fait A2A. En termes simples, A2A est une méthode standard permettant aux agents de communiquer, de se répartir le travail et d'accomplir des tâches en équipe. Qu'est-ce que A2A ? La définition simple. A2A signifie agent à agent. C'est un protocole ouvert qui permet aux agents IA de communiquer directement entre eux, peu importe qui les a créés. Vous pouvez le voir comme le protocole HTTP appliqué aux agents. Le HTTP est le langage utilisé par les navigateurs web et les serveurs pour communiquer et A2A fait de même pour les agents. Un agent créé par votre équipe informatique sur Microsoft Copilot Studio peut parler à un agent créé par une autre entreprise sur Google Cloud tant qu'ils utilisent A2A. Ce n'est pas un petit projet non plus.

A2A est parrainé par 8 grandes entreprises, dont Google, Microsoft, Cisco, Salesforce, SAP et d'autres, et il est hébergé par la fondation Linux. La version 1.0 est stable et prête pour une utilisation réelle, ce qui signifie qu'aucun fournisseur ne contrôle seul le protocole. Ce n'est pas une initiative propre à Google ou à Microsoft. C'est une initiative industrielle. La conception est volontairement simple. A2A s'appuie sur des standards web existants comme HTTP et JSON-RPC, des technologies que tout développeur connaît déjà. Rien d'exotique ou de propriétaire ici. Cela facilite l'adoption par les entreprises sans avoir à remplacer leur infrastructure existante. Vous avez peut-être entendu parler d'un autre protocole appelé MCP, ou modèle contexte-protocole. Voici la différence. MCP concerne la relation agent-outil, ce qui signifie qu'il connecte un agent à des sources de données et des API externes.

A2A concerne la relation agent-agent connectant directement les agents entre eux. Ils ne sont pas concurrents, ils sont complémentaires. Considérez MCP comme la connexion verticale d'un agent vers ses outils et A2A, comme la connexion horizontale entre agents côte à côte. Un autre choix de conception. A2A traite les agents comme des boîtes au pain. Ainsi, lorsqu'un agent communique avec un autre, il ne voit pas le raisonnement interne, les outils ou les données privées de l'autre agent. Il ne voit que la tâche qu'il a envoyée et le résultat qu'il reçoit en retour. Cela préserve la confidentialité et la propriété intelligente. Un agent météo n'a pas besoin de savoir comment l'agent d'un hôtel réserve des chambres et doit simplement transmettre les prévisions. Regardons maintenant la première pièce du puzzle. La carte d'agent. La carte d'agent ou CV. Chaque agent compatible A2A publie ce qu'on appelle une carte d'agent.

Cette carte est un document lisible par machine qui se trouve à une URL standard sur le domaine de l'agent, spécifiquement au chemin Well-known Agent Card, Jason XAigwe. Si vous savez où se trouve un agent, vous pouvez récupérer sa carte et apprendre tout ce dont vous avez besoin pour travailler avec lui. Considérez la carte d'agent comme un CV ou une carte de visite. Elle indique aux autres agents qui vous a été ce que vous pouvez faire. La carte contient le nom de l'agent, une description en texte simple de ses capacités et des balises de compétences qui facilitent sa découverte. Il liste également l'URL de points de terminaison où il accepte les requêtes, ses exigences d'authentification ainsi que les formats d'entrée et de sortie acceptés. Voici un exemple concret. Disons que vous avez un agent spécialiste. Sa carte d'agent indique « je peux fournir » la météo actuelle et les prévisions sur 5 jours pour n'importe quelle ville.

Il liste ses points de terminaison API car il accepte le nom d'une ville et renvoie la température et les conditions au format JSON. C'est tout. C'est simplement une déclaration claire de ce qu'il peut faire sans aucun secret ni logique interne exposée. La découverte fonctionne comme suit. Un agent orchestrateur possède une liste d'URL d'agents connus où vous pouvez les configurer manuellement. Lorsqu'une tâche arrive, l'orchestrateur récupère les cartes d'agents, en lit les descriptions et décide quel agent est le plus adapté. La carte météo indique la météo, ils sont envoyés. La carte hôtel indique les hôtels, donc les tâches liées aux hôtels y sont envoyées. Remarquez qu'aucun registre central n'est requis. Les agents n'ont pas besoin de s'inscrire dans un répertoire mondial. Ils publient simplement leur carte à un emplacement connu et tout autre agent connaissant l'URL peut les trouver.

C'est un choix de conception délibérée qui maintient le système décentralisé et flexible. Vous pouvez ajouter un nouveau spécialiste à votre réseau en donnant son URL à l'orchestrateur et la découverte se fait automatiquement. Ainsi l'orchestrateur sait qui est disponible. Mais comment transmettent-ils réellement le travail ? Comment fonctionne la communication A2A ? Donc l'orchestrateur sait quels agents sont disponibles grâce à la carte d'agent. Mais comment ces agents se transmettent-ils réellement le travail ? La réponse est simple. Toute communication se fait via HTTP en utilisant des messages JSON-RPC, le même protocole qui alimente la plupart des services web actuels. Rien de personnalisé ou de complexe, juste du trafic web standard circulant entre deux agents. Voici le point important. Toutes les tâches ne sont pas identiques. A2A prend en charge trois modèles d'interactions différents selon vos besoins.

La réponse instantanée gère les recherches rapides où l'agent distant peut répondre immédiatement. Vous envoyez une requête, il répond tout de suite et c'est terminé. Demander les prévisions du jour à un agent météo fonctionne exactement comme cela. Réponse rapide, entrée et sortie. Le streaming gère les tâches plus longues. Peut-être que l'agent spécialiste doit interroger plusieurs bases de données ou effectuer une analyse complexe. Complexe. Au lieu de vous faire attendre une réponse unique, l'agent envoie des mises à jour de statut pendant qu'il travaille, via des événements envoyés par le serveur. Vous recevez des rapports de progression en cours de route, puis le résultat final arrive à la fin. Le suivi de la livraison d'un colis fonctionne de la même manière. Il y a chaque étape au fur et à mesure qu'elle se produit. La notification asynchrone gère les tâches de longue durée où l'agent distant peut prendre des minutes, des heures, voire des jours.

L'intégration des nouveaux employés en est un bon exemple. Un spécialiste configure les comptes informatiques tandis qu'un autre gère l'inscription aux avantages sociaux sur plusieurs jours. L'agent client soumet une requête, reçoit un identifiant de tâche en retour et poursuit son travail. Plus tard, l'agent distant envoie le résultat via un webbook. Le client peut également vérifier l'avancement à tout moment en interrogeant cet identifiant de tâche. Chaque interaction suit la même structure, tout étant organisé sous forme de tâche. Lorsqu'un client envoie une requête, l'agent distant crée une tâche et renvoie un identifiant. Cet identifiant devient la référence de suivi pour tout ce qui suit. Les messages au sein de cette tâche possèdent un rôle indiquant l'expéditeur et des composants, qui peuvent être du texte brut, des données binaires comme des images ou documents, des charges utiles JSON ou des URL pointant vers des fichiers stockés ailleurs.

L'authentification suit les conventions web standards O-ROT, clé API, jetons porteurs. Les suspects habituels rien ne nous voient apprendre ici. La carte d'agent indique au client quelle méthode d'authentification utiliser et le client la gère comme pour tout autre appel API. Voici à quoi cela ressemble en pratique. Disons que l'orchestrateur a besoin de données météorologiques pour un voyage. Il envoie une tâche au spécialiste météo. Le spécialiste météo accuse réception de la requête, commence le traitement et transmet les mises à jour en continu. Récupération des données. Analyse des résultats. Terminé. Ensuite, il envoie les prévisions finales. L'orchestrateur ne voit jamais les outils internes de l'agent météo, ses clés API ou son processus de raisonnement. Il ne voit que le résultat. C'est le principe de conception clé, des frontières nettes entre les agents et aucune fuite d'état interne.

Mais l'A2 à pas seul ne suffit pas. Faut un responsable intelligent pour coordonner tous ses spécialistes. Cela nous amène au modèle orchestrateur spécialiste. Le modèle orchestrateur spécialiste. C'est là que tout se connecte. Le modèle orchestrateur spécialiste est l'architecture la plus courante dans les systèmes multi-agents en production aujourd'hui. Voyez cela comme une entreprise avec ses départements. Informatique, RH, Finance, chacun gérant son propre domaine. Vous avez un décideur central qui achemine le travail vers des équipes spécialisées et chaque équipe se concentre sur ce qu'elle fait de mieux. L'orchestrateur possède une vision d'ensemble. Il reçoit la requête de l'utilisateur, détermine ce qui doit être fait et décide quel spécialiste peut gérer chaque partie. Si un utilisateur demande, prévois un voyage à Seattle la semaine prochaine. L'orchestrateur ne réserve pas lui-même les vols ou les hôtels.

Il sait qu'il existe un spécialiste des vols, un spécialiste des hôtels et un spécialiste météo. Il décompose la requête en ses parties et délègue chacune d'elles. Chaque spécialiste a un champ d'action limité. Un agent gère la réservation de vol, un autre la recherche d'hôtels et un troisième le tri des incidents-incidents. Ils n'ont pas besoin de connaître les domaines des uns et des autres. Le spécialiste des vols connaît les compagnies, les itinéraires et les prix. Il n'a rien besoin de savoir sur les types de chambres d'hôtels ou les politiques d'annulation. Cette spécialisation rend chaque agent simple, facile à maintenir et à tester. Voici le point important. L'orchestrateur n'exécute pas les tâches. Il achemine le travail et fusionne les résultats. C'est sa seule fonction. Le rôle de l'orchestrateur est d'être un répartiteur intelligent, pas un super agent qui tente de tout faire.

Si vous laissez l'orchestrateur effectuer le travail des spécialistes, vous perdez tout l'intérêt du modèle. Cela redevient un chaos monolithique. Faites attention à une erreur courante. Certaines équipes créent des domaines de spécialisation qui se chevauchent. Deux agents prétendent gérer le support client ou la recherche de données, ce qui crée une confusion de routage. L'orchestrateur ne sait pas lequel choisir et les utilisateurs obtiennent des résultats incohérents. La solution est simple. Chaque spécialiste possède un domaine clairement délimité sans aucun chevauchement. Si deux agents font la même chose, fusionnez-les ou divisez le domaine plus proprement. Copilot Studio de Microsoft utilise ce modèle de façon native. Votre copilot principal agit comme orchestrateur, tandis que les agents enfants et connectés agissent comme spécialistes. Lorsqu'un utilisateur demande quelque chose couvrant plusieurs domaines, le copilot principal délègue au bon spécialiste via A2A.

C'est intégré à la plateforme, vous n'avez donc pas à coder la logique d'orchestration depuis zéro. Le grand avantage ici, c'est la modularité. Besoin de changer de fournisseur de réservation d'hôtel ? Remplacez le spécialiste de l'hôtellerie sans toucher à l'orchestrateur ni aux autres agents. Vous ajoutez une nouvelle fonctionnelle ? Créez un nouveau spécialiste, enregistrez-le auprès de l'orchestrateur et c'est terminé. Chaque agent reste petit, gérable et déployable indépendamment. C'est tout l'intérêt de passer d'agent monolithique à un système multi-agent A. Nous avons donc le protocole, les fiches d'agent et le modèle. Voyons cela en action avec des scénarios Ré. Exemple concret d'A2A part en action. À quoi ressemble A2A dans le monde réel ? Commençons par un exemple simple. Vous dites à votre assistant IA, organise un voyage à Seattle la semaine prochaine. À l'ancienne, cet assistant unique devrait tout savoir.

Météo, vol, hôtel, restaurant, tout à la fois, tout à la fois. C'est beaucoup demandé pour une seule requête. Avec A2A, l'orchestrateur décompose la dœuf. Il envoie une demande à un spécialiste météo pour obtenir les prévisions sur ses jours précis. En même temps, il demande à un spécialiste des vols de trouver des arrivées le mardi matin et des retours le jeudi soir et à un spécialiste des hôtels de chercher des logements près du centre-ville de Seattle pour trois nuits de... Chaque spécialiste travaille indépendamment et n'a pas besoin de communiquer avec les autres agents car ils disposent chacun de leurs propres sources de données, outils et expertises. L'orchestrateur collecte tous les résultats et les fusionne en une seule réponse. L'utilisateur envoie une réponse unique. Voici les prévisions. Voici vos options de vol et trois hôtels à proximité du bureau. En coulisses, trois agents distincts ont travaillé ensemble sans aucun code d'intégration personnalisé.

Passons à un scénario professionnel. Imaginons qu'un ticket arrive, mon ordinateur portable ne se connecte pas au VPN. L'orchestrateur identifie qu'il s'agit d'un problème réseau. Il transmet le ticket à un spécialiste des procédures qui connaît les étapes standards. Vérifier l'état du client VPN, valider les identifiants en réseau, redémarrer le service. Ce spécialiste renvoie les étapes à suivre. L'orchestrateur transmet le résultat à un spécialiste de la rédaction de tickets qui envoie juste la résolution dans le système. Tout cela se produit en quelques secondes sans intervention humaine. Et l'équipe informatique n'intervient que si les étapes automatisées ne règlent pas le problème. L'intégration des employés est un autre exemple, mais celui-ci prend des jours, pas des secondes. Une nouvelle recrue rejoint l'entreprise. L'orchestrateur sollicite un spécialiste informatique

pour les formulaires d'avantages sociaux, puis un spécialiste des installations pour le bureau et l'accès par badge. Chaque spécialiste exécute sa propre tâche longue durée indépendamment et l'orchestrateur suit la progression à l'aide des ID de tâches dont nous avons parlé plus tôt. Ainsi, si le spécialiste informatique termine, l'orchestrateur le sait et si le spécialiste des installations a du retard, il peut effectuer un suivi. L'utilisateur voit un processus d'intégration fluide, mais en coulisses, il s'agit d'une équipe coordonnée travaillant sur plusieurs jours. Ce n'est pas que de la théorie. Coca-Cola Beverages Africa utilise déjà des agents copilotes studio avec Dynamics 365 pour automatiser ses cycles de planification. Leur planificateur consacré auparavant jusqu'à une heure et demie par jour à des tâches répétitives. Grâce à l'orchestration multi-agents, ces cycles s'exécutent désormais de manière autonome.

L'orchestrateur délègue aux spécialistes qui gèrent différentes parties du processus de planification de la chaîne logistique de la chaîne logistique. Le résultat est un gain de plus d'une heure par personne et par jour simplement en laissant les agents communiquer entre eux au lieu de faire transférer les informations manuellement entre les systèmes.

Un homme qui maîtrise son domaine et possède ses propres outils sans avoir besoin de connaître les autres agents Sahara et Roser. A2A fournit une couche de communication simple pour qu'il puisse coopérer sans code personnalisé. Vous bénéficiez d'un protocole standard et d'un orchestrateur intelligent. Sans pont, sans intégration point à point et sans casse-tête de maintenance. Microsoft est totalement investi dans ce domaine. Voyons où s'intègrent Copilot Studio et Azure AI. L'écosystème de Microsoft Copilot Studio et Azure AI. Alors quelle est la place de Microsoft dans tout cela ? Pilo Center. Copilot Studio prend désormais en charge la 2A appuyée de manière native et est disponible pour tous depuis avril 2026. Il ne s'agit ni d'une préversion bêta. C'est prêt pour la production et tout client éligible peut l'utiliser dès aujourd'hui. Voici le point important. Vous pouvez connecter des agents externes à votre orchestrateur Copilot Studio.

Quand je dis externe, je veux dire vraiment externe. Des agents créés sur Google Cloud, AWS ou toute autre plateforme prenant en charge le protocole A2A. L'orchestrateur se moque de savoir où réside l'agent ou avec quel framework il a été conçu. Tant qu'il parle A2A, il peut rejoindre l'équipe. La configuration est simple. Dans Copilot Studio, vous créez ce qu'on appelle un agent connecté. Vous collez l'URL de point de terminaison de l'agent. Copilot Studio récupère automatiquement la carte de l'agent à partir de cette URL, c'est-à-dire le fameux fichier JSON dont nous avons parlé. Il lit les capacités de l'agent, les exigences d'authentification ainsi que les formats d'entrée et de sortie. Ensuite, il crée un connecteur personnalisé en arrière-plan et votre orchestrateur peut commencer à déléguer des tâches immédiatement. Vous n'avez besoin d'aucun travail d'intégration manuelle ni de code personnalisé.

Fondry Agent Service prend également en charge l'A2A. Il dispose d'un point de terminaison API A2A dédié qui permet aux orchestrateurs open source comme Autogen, Longchain et Sémantic Kernel d'invoquer des agents Fondry. Ainsi, si vous avez créé des agents en utilisant ces frameworks, vous pouvez les brancher sur l'écosystème Microsoft sans rien réécrire. C'est une voie à double sens. Microsoft suit le même modèle orchestrateur spécialiste que nous avons décrit. L'agent principal dans Copilot Studio agit comme l'orchestrateur, tandis que les agents enfants et les agents connectés sont les spécialistes. Chacun gère son propre domaine et l'orchestrateur effectue le routage et la fusion. C'est la même architecture, mais exécutée sur la plateforme Microsoft. Mais attention, il y a certaines limites que vous devez connaître. Premièrement, chaque saut d'orchestration supplémentaire ajoute de la latence.

Si votre agent principal appelle un agent connecté et que cet agent connecté en appelle un autre à chaque saut, ajoute un temps de réseau. Pour les conversations en temps réel, un trop grand nombre de sauts peut rendre l'expérience lente. Deuxièmement, une délégation excessive crée un chaos de routage. Si vous avez trop de spécialistes avec des domaines qui se chevauchent, l'orchestrateur commence à prendre de mauvaises décisions de routage. Gardez donc un nombre de spécialistes gérables et des domaines clairement séparés. Troisièmement, il existe une limitation spécifique avec les agents de données fabriques. Il ne fonctionne pas lorsque l'agent principal est déployé sur Microsoft 365 au pilote. Si votre déploiement cible M365 planifie en conséquence, ces contraintes sont réelles mais elles sont gérables. La plateforme est suffisamment mature pour une utilisation en production et Microsoft travaille activement à combler ses lacunes.

Maintenant, relions les points et voyons la situation dans son ensemble. Section connexion, comment tout cela s'articule. Prenons du recul et voyons comment ces pièces se connectent. A2A est le système téléphonique que les agents utilisent pour s'appeler entre eux. Les cartes d'agent, c'est votre annuaire téléphonique. Elles vous indiquent qui appeler, ce que chaque agent gère. L'orchestrateur est le standardiste qui achemine chaque appel vers le bon service. Aucune de ces pièces ne fonctionne seule. Vous avez besoin des trois. Sans annuaire, vous ne savez pas qui appeler. Sans standardiste, personne ne dirige le trafic. Et sans système téléphonique, un standardiste ne peut connecter personne. Il ne fonctionne qu'en équipe. C'est là qu'intervient la modularité. Lorsque vos spécialistes sont modulaires, vous pouvez ajouter de nouvelles capacités sans casser ce qui fonctionne déjà. Disons que vous voulez ajouter un spécialiste de location de voiture à votre assistant de voyage, vous le créez, vous publiez sa carte d'agent, vous donnez son URL à l'orchestrateur, vous donnez son URL à l'orchestrateur.

Le spécialiste des vols et celui des hôtels restent exactement les mêmes. L'orchestrateur ne change pas non plus. Vous branchez simplement une nouvelle pièce et le système s'adapte. Comme le protocole est ouvert, vous n'êtes jamais coincé avec un seul fournisseur. Votre orchestrateur peut tourner sur Copilot Studio, votre agent météo sur Google Cloud, votre agent d'hôtel sur AWS, vos systèmes internes peuvent rester sur Azure. Ils parlent tous la même langue. C'est la beauté d'un standard ouvert. Il évite l'enfermement propriétaire et vous permet de choisir le meilleur outil pour chaque tâche. A2A ne consiste pas à construire un agent super intelligent qui sait tout. Il s'agit de constituer une main d'oeuvre flexible de spécialistes que vous pouvez réorganiser selon l'évolution de vos modes. Vous ne remplacez pas vos agents, vous les réorganisez. Vous en ajoutez de nouveaux. Vous remplacez les anciens.

Le système grandit avec vous au lieu de devenir un goulot d'étranglement. Alors que pouvez-vous faire avec ces connaissances dès aujourd'hui ? Des points à retenir explaires. Commencez petit. Choisissez un processus répétitif dans votre organisation qui implique plusieurs systèmes. La résolution de tickets, l'intégration des employés ou les notes de frais, par exemple. Quelque chose avec des transferts clairs entre les états. Ensuite, construisez un prototype avec un orchestrateur et deux spécialistes. Vous n'avez pas besoin d'une architecture renduance. Vous avez juste besoin d'un exemple fonctionnel dont vous pouvez tirer des leçons. Utilisez les outils qui prennent déjà cela en charge. Copilot Studio intègre le support A2A, tout comme Azure AI Fondry. Pas besoin de créer le protocole de zéro ou d'écrire du code d'intégration personnalisé. Collez une URL, configurez vos agents et commencez à déléguer.

Surveillez les pièges courants. Évitez le chevauchement de vos domaines de spécialité. Si deux agents peuvent faire la même chose, fusionnez-les ou divisez mieux le domaine. Laissez l'orchestrateur gérer le routage, pas l'exécution. Et attention à la latence

La meilleure première étape est simple. Tartographiez les transferts dans votre flux de travail existant. Où l'information est-elle transmise entre les personnes ou entre les systèmes ? Ce sont les endroits où les agents peuvent prendre le relais. Chaque transfert est une opportunité. Voilà donc le système A2A en résumé. Trois éléments simples qui fonctionnent ensemble. Les agents ne sont plus isolés et commencent à agir comme une vraie équipe. Choisissez un flux de travail avec des transferts clairs et construisez à partir d'encore. Abonnez-vous pour plus d'explications simples et laissez un commentaire si cela vous a aidé.