Conception de systèmes multi-agents sur A2A : nœuds, mémoire et gouvernance
Une architecture de référence pour les systèmes multi-agents basés sur le protocole A2A, couvrant les modules d’agent, les types de mémoire, l’orchestration, les risques de sécurité et une liste de contrôle de conception.
Lorsqu’une entreprise dispose de plusieurs agents IA en production, les problèmes difficiles ne concernent plus les prompts mais plutôt l’architecture : la manière dont les agents communiquent entre eux, l’endroit où se trouve leur état, qui les coordonne et comment vérifier ce qu’ils ont fait. Cet article présente un plan de référence pour un tel système, en utilisant le protocole Agent-to-Agent (A2A) comme fondement de la communication. À la fin, vous devriez être en mesure de comprendre les éléments constitutifs d’un agent unique, les couches de mémoire et d’orchestration qui relient plusieurs agents, les contrôles de gouvernance nécessaires à un réseau multi-agents, ainsi que les compromis à prendre en compte avant d’effectuer une expansion.
De l’IA générative à l’IA agente
Le changement fondamental réside le passage des systèmes génératifs à ceux d’agents. L’IA générative est pilotée par des prompts : une personne pose une question, le modèle produit du contenu, et l’interaction s’arrête. L’IA d’agents est pilotée par des objectifs : le système reçoit un objectif de haut niveau, le divise en sous-objectifs plus petits et les traite avec peu d’intervention humaine. La conséquence pratique pour les architectes concerne l’étendue des tâches. Les modèles génératifs automatisent des tâches individuelles, tandis que les systèmes d’agents peuvent automatiser des flux de travail entiers, transformant l’IA d’un outil réactif en un délégué capable d’agir. C’est ce qui permet d’échelonner les opérations qui nécessitaient auparavant une surveillance à chaque étape. Si vous souhaitez une explication plus approfondie du vocabulaire, consultez l’explication de l’IA d’agents, des modèles de langage aux agents autonomes.
Moteurs probabilistiques et raisonneurs formels
Au cœur de chaque agent se trouve un modèle de prise de décision, généralement un grand modèle de langage ou un grand modèle d’images pour les charges de travail visuelles. Ces modèles sont probabilistes. Ils produisent des résultats fluides et convaincants, mais ils peuvent halluciner, et la fluidité n’est pas synonyme de justesse. Les systèmes formels tels que les raisonneurs d’ontologie OWL ou les réseaux bayésiens se comportent différemment : leurs conclusions découlent de règles et de probabilités explicites, ce qui les rend mathématiquement fiables dans leur domaine. Une conception robuste utilise chacun d’eux là où il est le plus performant.
Celui même pragmatisme s’applique à la profondeur du raisonnement. Des techniques comme les prompts de type « chain-of-thought » améliorent la précision en obligeant le modèle à effectuer des étapes intermédiaires, mais chaque étape supplémentaire entraîne un retard et une consommation de ressources plus élevée. Un raisonnement plus profond n’est pas gratuit, et la profondeur idéale dépend de la vitesse à laquelle le système doit répondre. Lorsque l’on dispose de nombreux agents de ce type, chacun avec son propre modèle et son propre style de raisonnement, il devient nécessaire d’exister un moyen de communication commun entre eux. C’est là le rôle d’A2A.
A2A en tant que couche d’interopérabilité
A2A a été proposé en 2025 comme un protocole ouvert permettant aux agents développés avec des frameworks différents et par des fournisseurs variés de collaborer. Son objectif est d’empêcher les systèmes multi-agents de se fragmenter en silos propres à chaque fournisseur : les agents créés avec des frameworks différents ou hébergés par des fournisseurs distincts peuvent échanger des informations contextuelles et coordonner leurs actions via une interface commune. Son adoption est encore en cours d’évolution, il convient donc de consulter la spécification actuelle avant de se décider pour des détails précis.
Les cinq principes de conception
- Considérer les agents comme tels. Le protocole part du principe que les participants sont capables de raisonner et d’agir de leur propre initiative, et non seulement de répondre à une demande unique. Cela ouvre la voie à une collaboration orientée vers des objectifs à long terme, plutôt qu’à des échanges simples de demandes et de réponses.
Le respect de ces principes permet d’éviter deux modes de défaillance classiques : l’échec de coordination, où les agents ne parviennent pas à agir ensemble, et le désalignement entre agents, où les participants décentralisés s’éloignent progressivement de l’objectif commun. Ces principes se concrétisent au sein de chaque agent grâce à un cycle modulaire de perception, de raisonnement et d’action.
Dans un seul nœud d’agent
Chaque nœud exécute un cycle fermé comprenant l’entrée, le traitement, l’action et l’apprentissage. Comme ce cycle renvoie les résultats à l’état interne de l’agent, le nœud reste conscient de son environnement et s’adapte, au lieu d’exécuter mécaniquement un script fixe.
Les quatre sous-systèmes
- Perception. Cette couche reçoit des signaux de toutes sortes : des requêtes en langage naturel, des flux d’événements API, des images. Elle utilise la génération augmentée par récupération d’informations (RAG) pour ancrer ces entrées dans des faits réels avant qu’elles n’atteignent la couche de raisonnement.
- Répresentation des connaissances et raisonnement (KRR). Ici, l’intention est interprétée à l’aide d’une combinaison de méthodes statistiques et symboliques. Le modèle linguistique gère les nuances et les ambiguïtés, tandis que des vérifications formelles permettent de s’assurer que le plan résultant est logiquement cohérent.
- Sélection et exécution des actions. Les décisions se transforment en résultats concrets grâce à un catalogue défini d’appels API ou de messages envoyés. C’est là que le raisonnement de l’agent entre en contact avec le monde numérique ou physique.
Le principal schéma d’exécution est ReAct, abréviation de reasoning plus acting. L’agent alterne entre la réflexion sur la prochaine étape et l’observation du résultat d’une action, ce qui permet à sa réflexion de rester ancrée dans ce qui s’est réellement produit. Le inconvénient est que chaque étape de réflexion représente une nouvelle appel au modèle, ce qui augmente la consommation de ressources informatiques et le temps de réponse, facteurs qu’il faut prendre en compte. Ce qui assure leur cohérence d’une étape à l’autre et d’une session à l’autre, c’est la mémoire.
Mémoire persistante dans le temps
Les modèles de langage sont sans état : chaque appel ne connaît que ce qui se trouve dans son contexte. Pour la planification à long terme, c’est la mémoire persistante qui relie les différentes étapes. Sans elle, les agents oublient leurs progrès lors de tâches à plusieurs étapes ou lorsque le travail est transféré entre sessions, ce qui entraîne des tâches répétées et des systèmes fragiles.
Trois types de mémoire
- Mémoire épisodique : elle enregistre ce qui s’est passé au cours d’une tâche particulière, y compris les étapes de raisonnement suivies et les tentatives qui ont échoué, tout au cours d’une seule session.
- Mémoire sémantique : elle stocke des faits durables et des connaissances organisationnelles structurées que toute tâche peut utiliser.
- Mémoire basée sur des vecteurs : conçue pour la recherche de similarités, elle permet à un agent de récupérer un contexte pertinent à partir de très grandes collections grâce au RAG.
Il est important de les garder séparés car ils ont des durées de vie et des modes d’accès différents. La mémoire épisodique est de courte durée et liée à une tâche spécifique, la mémoire sémantique est de longue durée et soigneusement organisée, tandis que les bases de données vectorielles sont optimisées pour des recherches floues plutôt que pour des recherches exactes.
Contexte partagé pour les transferts
À grande échelle, les agents ont également besoin de buffers de contexte partagés. Lorsqu’un agent transmet une sous-tâche à un autre, le buffer contient tous les éléments contextuels et l’état actuel, permettant ainsi à l’agent destinataire de ne pas partir de zéro. La distribution de cet état exige en retour une couche de coordination au-dessus des agents individuels.
Orchestration et décomposition des objectifs
Au fur et à mesure que les systèmes se développent, un seul modèle polyvalent cède la place à un ensemble d’agents spécialisés. L’affectation de rôles, par exemple un agent qui planifie comme un PDG, un autre qui écrit du code et un troisième qui le vérifie, permet généralement d’obtenir une plus grande précision et une meilleure profondeur que de demander à un seul modèle de faire tout le travail.
Quel est le rôle d’un méta-agent
- Affecter chaque sous-tâche à l’agent le plus adapté.
- Gérer les dépendances afin que les résultats soient transmis au bon endroit dans le bon ordre.
- Résoudre les conflits lorsque des agents produisent des résultats contradictoires ou se disputent les mêmes ressources.
Planification avec l’Arbre des Pensées
L’orchestration consiste à décomposer un objectif en sous-objectifs. Des approches de planification telles que l’Arbre des Pensées examinent plusieurs branches de raisonnement au lieu de s’en tenir à une seule chaîne, ce qui aide à résoudre l’incertitude et réduit la fragilité ainsi que les hallucinations auxquelles sont sujets les plans à voie unique. L’examen de plusieurs branches multiplie également les appels au modèle, ce qui accentue le compromis lié à la latence évoqué précédemment.
Il existe un risque supplémentaire : le comportement émergent. Lorsque de nombreux agents autonomes interagissent de manière non linéaire, le système peut produire des résultats que personne n’a conçus ni prédits. L’orchestration diminue ce risque mais ne l’élimine pas, c’est pourquoi la gouvernance doit faire partie de l’architecture et non être une considération ultérieure.
Sécurité et gouvernance
Un réseau d’agents présente une grande surface d’attaque, et un nœud compromis ou confus peut déclencher une cascade d’erreurs dans toute la chaîne. L’approche sûre consiste à considérer chaque interaction entre agents comme une source potentielle de risque.
Les principaux risques
- Cascades d’erreurs. Une hallucination ou une erreur apparue tôt dans la chaîne se propage et corrompt la décision finale. L’article sur la prévention de l’aggravation des hallucinations dans les graphes d’agents explore en profondeur ce mode de défaillance.
- Attaques adversariales. L’injection de prompts ou le « poisoning » du modèle peuvent perturber les actions que tente d’effectuer un agent.
- Propagation des biais. Les agents peuvent amplifier des schémas biaisés dans les données et produire des résultats systématiquement injustes.
Architecture consciente de la gouvernance
Trois mécanismes permettent de faire face à la plupart de ces risques :
- Isolement des rôles : il limite l’autorité de chaque agent ainsi que les API qu’il peut appeler, de sorte qu’un agent compromis ne puisse causer que des dommages limités.
- Enregistrement traçable des décisions : il consigne chaque étape du raisonnement afin que les pannes puissent être auditées et attribuées.
- Authentification des agents : elle vérifie l’identité de chaque participant au flux de travail.
En plus de cela, une couche de vérification formelle permet de distinguer ce qui semble logique de ce qui l’est réellement. C’est la réponse architecturale à la nature persuasive mais peu fiable des modèles de langage décrits au début.
Où cela mène : l’intelligence proactive et AZR
Au fur et à mesure que les agents modulaires et les systèmes agents orchestrés convergent, la prochaine étape est l’intelligence proactive : des systèmes capables de détecter des signaux dans leur environnement et de lancer des workflows avant même qu’on ne le demande.
Une direction de recherche pertinente est le paradigme du Zéro Absolu (AZR). Plutôt que d’apprendre à partir d’exemples étiquetés par des humains, il s’améliore grâce à un auto-jeu renforcé, générant ses propres problèmes et raisonnements sans données d’entraînement externes. Ce qui le maintient ancré dans la réalité, c’est un retour d’information vérifiable, comme l’exécution du code généré ou la vérification de preuves formelles, qui remplace l’annotation humaine en tant que source de vérité. Considérez-le comme un domaine de recherche actif plutôt que comme une technique prête à l’emploi.
Liste de contrôle de conception
Au préalable de mettre à l’échelle un système multi-agents, vérifiez la conception en répondant aux questions suivantes :
- Vérification formelle : Existe-t-il une couche logique permettant de distinguer les résultats générés par le modèle des résultats réellement valides ?
- Partitionnement de la mémoire : Les stockages épisodiques, sémantiques et vectoriels sont-ils clairement séparés ?
- Standard de protocole : Toute communication entre frameworks ou fournisseurs différents passe-t-elle par A2A ?
- Contrôles de gouvernance : L’isolation des rôles et l’enregistrement traçable des décisions sont-ils activés pour chaque nœud autonome ?
- Budget de latence : Avez-vous mesuré et ajusté l’équilibre entre la profondeur du raisonnement, comme dans l’arbre des pensées, et le temps de réponse ?
Points clés
- Les systèmes multi-agents transforment le problème en passant de la création d’outils permettant de répondre à des questions à celle de l’élaboration d’écosystèmes capables de résoudre des problèmes par eux-mêmes, et ce changement est d’ordre architectural.
Lectures complémentaires
- Agent = Modèle + Harness : D’où provient réellement un comportement fiable de l’IA — Découvrez ce qu’est un harness d’agent IA, pourquoi l’état, l’autorité et la vérification relèvent de domaines extérieurs au modèle, et quels outils deviendront obsolètes à mesure que les modèles s’améliorent.
- Concevoir une mémoire agente en quatre niveaux avec LangGraph et Amazon Bedrock — Apprenez à doter les agents LLM d’une mémoire épisodique, sémantique et procédurale fonctionnelle sur Bedrock et LangGraph, ainsi qu’à les protéger contre le poisonage, les fuites de PII et les problèmes liés aux utilisateurs.
- Échelonner les nœuds, pas les tâches : un escalier en six niveaux pour limiter le coût des flux de travail LLM — Pourquoi choisir entre un DAG et un agent par tâche entraîne une augmentation des coûts LLM, et comment un escalier d’échelonnement par nœud, accompagné de contrats, de périmètres et de budgets, permet de les maintenir sous contrôle.
- Interface de chat ou boucle d’agent ? Décider des besoins de votre fonctionnalité IA — Apprenez à distinguer un chatbot conversationnel d’un agent orienté objectif, ce que la boucle d’agent apporte, et comment déterminer lequel votre fonctionnalité IA a réellement besoin.
- Les registres d’agents vous indiquent ce qui existe, pas s’on peut encore en faire confiance — Un cadre de quatre questions pour les registres de capacités des agents couvrant l’existence, la pertinence, le statut et l’origine, ainsi qu’un test simple de dernière vérification que vous pouvez exécuter dès aujourd’hui.