---
title: "Shared memory vs message passing dans les systèmes multi-agents"
description: "La mémoire partagée et le passage de messages sont les deux paradigmes fondamentaux de la coordination entre agents."
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/systemes-multi-agents/shared-memory-vs-message-passing-dans-les-systemes-multi-agents"
category: "Agents IA"
topic: "Systèmes multi-agents"
updated: "2026-10-28T13:26:21.349Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Shared memory vs message passing dans les systèmes multi-agents

La mémoire partagée et le passage de messages sont les deux paradigmes fondamentaux de la coordination entre agents. Avec la mémoire partagée (pattern Blackboard), tous les agents lisent et écrivent dans un état commun. Avec le passage de messages, les agents communiquent exclusivement par messages et ne partagent aucun état. Ce choix détermine la cohérence, le couplage, la scalabilité et la débogabilité d'un système multi-agents.

## L’essentiel

- La mémoire partagée (Blackboard) désigne un état commun dans lequel tous les agents lisent et écrivent ; le passage de messages encapsule chaque agent et ne le laisse communiquer que par messages.
- La règle de cohérence critique est la suivante : les lectures peuvent s'exécuter en parallèle en fan-out, les écritures doivent rester mono-thread. Selon Cognition, les écritures concurrentes sur un état partagé entraînent des décisions implicites contradictoires et des résultats fragiles.
- Le passage de messages domine les standards de 2026 : A2A définit un cycle de vie des tâches où le fonctionnement interne des agents reste opaque, l'OpenAI Agents SDK utilise des handoffs, l'Anthropic Claude Agent SDK l'outil Agent (anciennement outil Task) avec des retours compressés.
- La mémoire partagée reste débogable avec des topologies à rédacteur unique, mais s'effondre dès que les écritures sont libres ; le passage de messages exige un traçage distribué de bout en bout avec des ID de corrélation.
- En pratique, les systèmes en production combinent les deux : un état partagé en interne (p. ex. l'objet d'état de LangGraph avec checkpointing) et, vers l'extérieur, le passage de messages via A2A.

La mémoire partagée et le passage de messages sont les deux paradigmes fondamentaux qui permettent de coordonner plusieurs agents [IA](https://blckalpaca.at/fr/glossaire/ia). Avec la **mémoire partagée** (dans sa variante classique, le **pattern Blackboard**), tous les agents lisent et écrivent dans un état commun. Avec le **passage de messages**, chaque agent est encapsulé et communique exclusivement par messages, sans état partagé. Le choix entre les deux détermine quatre propriétés d'un [système multi-agents](https://blckalpaca.at/fr/glossaire/systeme-multi-agents) : cohérence, couplage, scalabilité et débogabilité. Cet article compare les paradigmes selon ces axes et montre lequel convient dans quel cas.

- **Mémoire partagée / Blackboard :** état commun (scratchpad, base vectorielle, objet d'état) dans lequel tous les agents lisent et écrivent. Fortement couplé, échange de contexte simple, mais délicat en cas d'écritures parallèles.
- **Passage de messages :** agents isolés, échanges uniquement par messages. Découplé, passe à l'échelle au-delà des frontières de processus et de fournisseurs, c'est le standard derrière A2A, l'OpenAI Agents SDK et l'[Anthropic Claude](https://blckalpaca.at/fr/glossaire/anthropic-claude) [Agent](https://blckalpaca.at/fr/glossaire/agent) SDK.
- **La règle décisive :** la lecture peut s'exécuter en parallèle en fan-out, l'écriture devrait rester mono-thread, quel que soit le paradigme choisi.

## La mémoire partagée et le pattern Blackboard

Dans l'approche par mémoire partagée, tous les agents se partagent une mémoire centrale. Le [**pattern Blackboard**](https://blckalpaca.at/fr/glossaire/coordination-dagents) classique est issu de la recherche en IA : un « blackboard » commun contient l'état actuel d'une tâche, et des agents spécialisés l'observent, en lisent les parties qui les concernent, y inscrivent leurs résultats partiels et réagissent aux modifications provoquées par d'autres agents. Il n'y a pas de plan d'exécution fixe ; l'ordre dépend de l'agent qui peut apporter quelque chose d'utile à un moment donné.

Dans les [systèmes multi-agents](https://blckalpaca.at/fr/glossaire/systemes-multi-agents) modernes, la mémoire partagée prend plusieurs formes. Quatre couches de stockage externes sont répandues :

- **Bases vectorielles** (pgvector, Pinecone, Weaviate, Qdrant) pour le contexte augmenté par récupération.
- **Bases de données structurées** (Postgres, BigQuery, SAP HANA, Snowflake) pour les faits.
- **Scratchpads**, des blocs-notes partagés et éphémères que les agents lisent et écrivent, généralement avec une sémantique append-only ou compare-and-swap.
- **Mémoire d'agent persistante** (style Letta/MemGPT, store inter-threads de LangGraph, outil Memory d'Anthropic).

Le pattern peer-to-peer ou swarm relève aussi en partie de cette catégorie : des agents de même rang sur un bus de messages partagé et/ou une mémoire partagée, sans orchestrateur fixe. [OpenAI Swarm](https://blckalpaca.at/fr/blog/ai-agent-swarms-quand-les-agents-ia-travaillent-ensemble) en est la référence : un framework expérimental publié en octobre 2024 et [remplacé](https://github.com/openai/swarm) en mars 2025 par l'[OpenAI](https://blckalpaca.at/fr/glossaire/openai) Agents SDK, prêt pour la production. Dans le contexte des entreprises européennes, ce modèle libre convient toutefois rarement, car la débogabilité et la traçabilité des responsabilités en pâtissent.

**Le point faible, c'est la cohérence.** Dès que deux agents lisent la même mémoire et qu'au moins l'un d'eux écrit, il faut une stratégie claire. Trois options sont courantes : (a) la concurrence optimiste, (b) un seul rédacteur avec plusieurs lecteurs ou (c) une sémantique de verrouillage explicite. La plupart des systèmes en production choisissent (b), ce qui correspond à la [règle de Cognition](https://cognition.com/blog/multi-agents-working) « Writes stay single-threaded ».

## Le passage de messages et la communication entre agents par messages

Avec le passage de messages, chaque agent possède son propre état et sa propre fenêtre de contexte. Les informations circulent uniquement par des messages explicites, jamais par un accès direct à l'état d'un autre agent. Cela découple les agents : un agent n'a besoin de rien savoir du fonctionnement interne, du modèle ou de la mémoire d'un autre, il lui suffit de connaître le format des messages.

C'est précisément l'idée de conception du [**protocole Agent-to-Agent (A2A)**](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/protocole-agent-to-agent-a2a/orchestration-multi-fournisseurs-coordonner-des-agents-issus-de-differents-frame), publié par Google en avril 2025 lors de Cloud Next et confié à la Linux Foundation le 23 juin 2025. A2A définit *comment* les agents se parlent, pas *comment* ils pensent : chaque agent publie une **AgentCard** (un document JSON avec endpoint, capacités, skills, modalités et schémas d'authentification). Une collaboration suit un **cycle de vie des tâches** :

`submitted -> working -> input-required -> completed | failed | canceled`

Le fonctionnement interne de l'agent distant reste **opaque**. C'est justement ce qui permet à un agent Salesforce d'appeler un agent SAP sans que l'un révèle à l'autre ses prompts, sa mémoire ou son modèle. Tandis qu'A2A couvre le niveau d'agent à agent, le [**Model Context Protocol (MCP)**](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/model-context-protocol-mcp) régit le niveau d'agent à outil. La règle empirique répandue dans le secteur (état 2026) : [MCP](https://blckalpaca.at/fr/glossaire/mcp) pour les capacités (de l'agent vers l'outil), A2A pour la collaboration (d'agent à agent).

D'autres stacks mettent en œuvre le passage de messages avec leur propre sémantique :

| Stack | Sémantique du passage de messages |
| --- | --- |
| A2A | Cycle de vie des tâches, messages en plusieurs parties, artefacts comme output, fonctionnement interne opaque entre agents |
| OpenAI Agents SDK | Handoffs explicites : un agent termine son tour, le suivant prend le relais, l'historique de conversation est transmis |
| AutoGen ([en mode maintenance](https://github.com/microsoft/autogen), successeur : Microsoft Agent Framework) | Chat de groupe avec prise de parole à tour de rôle, historique de conversation partagé, adressage par mentions |
| LangGraph | Objet d'état typé transmis de nœud en nœud, doté de checkpoints, durable après les redémarrages du serveur |
| Anthropic Claude Agent SDK | L'agent principal lance des sous-agents via l'[outil Agent](https://code.claude.com/docs/en/agent-sdk/subagents) (anciennement outil Task), les sous-agents renvoient des outputs structurés et compressés |
| Bedrock Multi-Agent Collaboration | Superviseur plus agents collaborateurs, mode routage ou [orchestration](https://blckalpaca.at/fr/glossaire/orchestration) complète |
| Agentforce | Atlas Reasoning Engine assure le routage, les agents spécialisés renvoient leurs résultats, le contexte de conversation est conservé |

[LangGraph](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/frameworks-dagents-ia-comparatif-langgraph-crewai-autogen/langgraph-des-agents-avec-etat-sous-forme-de-graphe-oriente) est ici un cas limite intéressant : l'objet d'état typé est de fait un état partagé, mais il est transmis de manière contrôlée de nœud en nœud et sauvegardé par checkpoints, donc pas écrit librement. C'est la forme hybride courante en pratique.

## Les compromis en comparaison directe

| Dimension | Mémoire partagée / Blackboard | Passage de messages |
| --- | --- | --- |
| Couplage | Élevé : tous les agents connaissent le schéma d'état | Faible : seul le format des messages est partagé |
| Cohérence | Délicate : situations de compétition en cas d'écritures concurrentes, nécessite un rédacteur unique ou des verrous | Plus simple : aucun état partagé susceptible d'être corrompu |
| Scalabilité | Limitée par la contention en écriture sur la mémoire partagée | Passe à l'échelle au-delà des frontières de processus, d'équipes et de fournisseurs |
| Échange de contexte | Très direct : l'état complet est visible immédiatement | Explicite : uniquement ce qui est envoyé délibérément |
| Débogabilité | Bonne avec un rédacteur unique, s'effondre avec des écritures libres | Nécessite un traçage distribué avec des ID de corrélation sur tous les messages |
| Auditabilité | Snapshots d'état, mais « qui a décidé quoi » reste souvent flou | Chaque message est une donnée pertinente pour l'audit |
| Usage typique | Sous-tâches étroitement couplées dans un même processus | Workflows inter-systèmes et inter-fournisseurs |
| Protocole standard en 2026 | propriétaire / interne au framework | A2A (Linux Foundation), MCP pour les outils |

Deux modes de défaillance méritent une attention particulière. Premièrement, la **fragmentation du contexte** : les sous-agents prennent des décisions implicites incompatibles. [Cognition](https://cognition.com/blog/dont-build-multi-agents) le formule comme un principe : les actions portent des décisions implicites, et des décisions contradictoires mènent à de mauvais résultats. Les remèdes sont le partage des traces complètes en cas de couplage fort, des écritures mono-thread et des contrats de décision explicites. Deuxièmement, l'**effondrement de la débogabilité** : avec le passage de messages, aucune trace unique ne couvre l'ensemble de l'exécution ; on obtient N trajectoires de sous-agents plus la synthèse. Le remède est un [traçage distribué](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/systemes-multi-agents/gestion-des-erreurs-dans-les-systemes-multi-agents-retries-fallbacks-circuit-bre) de bout en bout, avec des ID de corrélation propagés à chaque tâche A2A et à chaque appel MCP.

## Exemple concret : fan-out en lecture avec un rédacteur unique

Le Research Agent d'Anthropic (juin 2025) est la référence pour une bonne répartition. Un agent principal (Claude Opus 4) décompose la requête et lance N sous-agents en parallèle (Claude Sonnet 4). Chaque sous-agent dispose de sa propre fenêtre de contexte d'environ 200k tokens, effectue ses recherches de façon indépendante et renvoie un **résumé compressé** (pas la transcription complète) à l'agent principal, qui en fait la synthèse. C'est du passage de messages pur, avec des contextes isolés. Résultat selon l'[évaluation interne de recherche d'Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system) : le système multi-agents a obtenu des résultats **supérieurs de 90,2 %** à ceux d'un agent unique avec Claude Opus 4. Le prix à payer est une **consommation de tokens environ 15 fois supérieure à celle d'une interaction de chat normale** ; un agent unique se situe à environ 4 fois. Cette économie ne se justifie que pour des tâches à forte valeur et parallélisables.

Un pendant issu de l'assurance est **Allianz Project Nemo** : sept agents spécialisés (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) pour les sinistres liés à la détérioration de denrées alimentaires après des catastrophes naturelles. Dans le cas présenté par Allianz, il s'écoule moins de cinq minutes entre la déclaration de sinistre et la vérification finale. Cette vérification reste du ressort d'un humain : un gestionnaire de sinistres lit le résumé d'audit et prend la décision finale d'indemnisation (human-in-the-loop comme exigence explicite). Allianz a développé le système en moins de 100 jours et l'a lancé en juillet 2025 en Australie. [Résultat documenté](https://www.allianz.com/en/mediacenter/news/articles/251103-when-the-storm-clears-so-should-the-claim-queue.html) : **80 % de temps de traitement et de règlement en moins** pour les sinistres légitimes inférieurs à AUD 500.

En pseudocode, la topologie fan-out en lecture avec un seul rédacteur se présente ainsi :

1. `fragmente = parallel_map(sub_agent.recherchiere, teilaufgaben)` : les lectures s'exécutent en parallèle en fan-out, avec des contextes isolés.
2. `ergebnis = lead.synthetisiere(fragmente)` : un seul et unique rédacteur fusionne les fragments.
3. `commit(ergebnis)` : l'écriture reste mono-thread.

À l'inverse, il faut éviter les écritures concurrentes de plusieurs agents sur le même état, car des agents qui écrivent en parallèle prennent des décisions implicites qui se contredisent.

## Quel paradigme choisir, et quand

- **Choisis le passage de messages** lorsque les agents collaborent au-delà des frontières de processus, d'équipes ou de fournisseurs, lorsque le fonctionnement interne doit rester encapsulé et lorsqu'un audit message par message est nécessaire. C'est le choix par défaut pour les workflows inter-systèmes (d'Agentforce à Joule puis à Copilot via A2A) et pour le fan-out principalement en lecture (recherche, récupération d'informations, classification, revue).
- **Choisis la mémoire partagée** lorsque des sous-tâches étroitement couplées s'exécutent au sein d'un même processus, que l'état commun est petit, que la fréquence d'écriture est faible et qu'un rédacteur unique peut être établi. Le blackboard convient aux tâches sans plan d'exécution fixe.
- **Combine les deux**, ce qui correspond à la réalité de la production : un flux LangGraph interne avec un objet d'état durable et du checkpointing, exposé à l'extérieur comme endpoint A2A avec une AgentCard. En interne, un état partagé de manière contrôlée ; à l'extérieur, un passage de messages propre.

## Pour les agences et les décideurs B2B

La question du paradigme est une question de risque opérationnel. Si tu mets en place des workflows multi-agents en Europe, tu devrais choisir par défaut le passage de messages via la combinaison standard convergente MCP plus A2A, et limiter délibérément la mémoire partagée aux sous-tâches internes étroitement couplées avec un rédacteur unique. Pour les agences marketing, cela signifie concrètement que les pipelines de contenu, de recherche et de relecture profitent d'un fan-out en lecture parallèle, tandis que l'étape d'écriture finale (publication, saisie dans le [CRM](https://blckalpaca.at/fr/glossaire/crm)) reste mono-thread. Si tu prévois une architecture d'agents auditable et prête pour la production, pour tes clients ou pour ta propre entreprise, tu devrais fixer tôt le profil de couplage, la stratégie de cohérence et l'infrastructure de traçage, avant que la première ligne d'orchestration ne soit écrite. C'est précisément là qu'intervient l'accompagnement de Blck Alpaca.

## Questions fréquentes

### Quelle est la différence entre mémoire partagée et passage de messages pour les agents ?

Avec la mémoire partagée, tous les agents partagent un état commun (blackboard, scratchpad, base vectorielle) dans lequel ils lisent et écrivent. Avec le passage de messages, chaque agent dispose d'un état isolé et n'échange des informations que par des messages explicites. La mémoire partagée crée un couplage plus fort et simplifie le partage de contexte ; le passage de messages découple, passe à l'échelle au-delà des frontières de processus et de fournisseurs et constitue le modèle dominant du standard multi-agents de 2026 (A2A, MCP).
### Qu'est-ce que le pattern Blackboard pour les agents ?

Le pattern Blackboard est une variante de mémoire partagée : une mémoire commune (le blackboard) contient l'état de la tâche, et plusieurs agents spécialisés en lisent les parties pertinentes, y inscrivent leurs résultats partiels et réagissent aux modifications des autres. Il convient aux tâches sans plan d'exécution fixe. Le point critique est la cohérence des écritures : en production, on le met généralement en œuvre avec un seul rédacteur et plusieurs lecteurs, ou avec une sémantique append-only ou compare-and-swap.
### Quand devrais-je choisir le passage de messages plutôt que la mémoire partagée ?

Le passage de messages est le bon choix lorsque les agents collaborent au-delà des frontières de processus, d'équipes ou de fournisseurs, lorsque le fonctionnement interne (prompts, modèles, mémoire) doit rester encapsulé et lorsqu'une auditabilité message par message est requise. C'est précisément ce que couvre le protocole A2A. La mémoire partagée est plutôt intéressante au sein d'un même processus, pour des sous-tâches étroitement couplées avec une faible fréquence d'écriture et un seul rédacteur clairement identifié.
### Pourquoi les écritures parallèles sur un état partagé posent-elles problème ?

Les écritures concurrentes de plusieurs agents sur le même état provoquent des situations de compétition et des décisions implicites contradictoires. Cognition le résume en un principe : les actions portent des décisions implicites, et des décisions contradictoires mènent à de mauvais résultats. La solution standard consiste à paralléliser les lectures et à garder les écritures mono-thread, c'est-à-dire qu'un seul agent ou une seule étape du pipeline valide l'état final.
### Quel paradigme utilisent les frameworks courants en 2026 ?

En 2026, la plupart des stacks misent sur le passage de messages, avec des sémantiques différentes : A2A utilise un cycle de vie des tâches avec des artefacts et un fonctionnement interne opaque, l'OpenAI Agents SDK des handoffs explicites, AutoGen (désormais en mode maintenance, successeur : Microsoft Agent Framework) un chat de groupe avec prise de parole à tour de rôle, l'Anthropic Claude Agent SDK l'outil Agent (anciennement outil Task) avec des retours compressés. LangGraph utilise entre les nœuds un objet d'état typé et doté de checkpoints, un état partagé en pratique, mais transmis de manière contrôlée.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/systemes-multi-agents/shared-memory-vs-message-passing-dans-les-systemes-multi-agents). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.