Architectures multi-agents : patterns et design

Introduction

Les architectures multi-agents distribuent des responsabilités entre plusieurs agents isolés, puis définissent comment tâches, contexte et droits circulent. Ce découpage aide quand les rôles ont des outils, des données ou des niveaux de confiance différents. Il faut l’éviter pour un flux simple où chaque handoff ajoute latence et ambiguïté. Ce guide présente supervisor, pipeline, pool et message-passing, puis les traduit dans OpenClaw sans inventer de SDK Python : OpenClaw est un assistant self-hosted dont le Gateway route des canaux vers des agents configurés. Pour un graphe applicatif codé étape par étape, LangGraph reste souvent plus adapté.

Résumé rapide

Pattern	Coordination	Cas adapté	Risque principal
Supervisor	Un coordinateur délègue et arbitre	Tâches variables, validation centrale	Goulot d’étranglement
Pipeline	Étapes ordonnées et contrats fixes	Recherche → rédaction → revue	Échec en cascade
Pool	Workers équivalents en parallèle	Lots indépendants	Doublons et contention
Message-passing	Événements et files	Système distribué durable	Débogage et cohérence
Routage OpenClaw	Bindings canal/compte → agent isolé	Plusieurs personas et canaux	Confondre isolation logique et sécurité forte

Concevoir le bon périmètre multi-agents

Un agent n’est pas seulement un prompt. Il réunit un modèle, des instructions, des outils, un workspace, un état de session et une politique d’accès. Passer au multi-agents est pertinent lorsque ces dimensions doivent diverger durablement.

Les bons signaux sont concrets : propriétaires distincts, schémas de sortie différents, exécution parallèle rentable, contexte trop volumineux pour un seul rôle ou nécessité d’un contrôle indépendant. « Donner une personnalité à chaque étape » n’est pas un motif suffisant. Plus d’agents signifie plus de sessions, de permissions, de reprises et de coûts LLM.

Dans OpenClaw, plusieurs agents peuvent vivre dans un même Gateway. Chacun possède son workspace, son agentDir et son historique SQLite. Des bindings associent un compte ou un canal entrant au bon agent. Cette architecture est utile pour un assistant personnel multi-personas ou une équipe de confiance. Elle n’est pas une plateforme d’exécution Python et ne remplace pas automatiquement une queue, un moteur de graphe ou une transaction métier.

L’isolation par workspace n’est pas un sandbox : elle définit le répertoire de travail par défaut, mais des chemins absolus peuvent atteindre l’hôte si les outils ne sont pas sandboxés. Le modèle mental correct sépare donc routage, orchestration et sécurité.

Patterns, communication et implémentation

Pattern supervisor

Un coordinateur reçoit l’objectif, choisit un spécialiste, contrôle la réponse et décide de la suite. Il convient aux demandes où l’ordre n’est pas connu à l’avance. Le contrat doit limiter le nombre de délégations, définir un résultat terminal et prévoir une sortie si aucun spécialiste n’est adapté.

Dans OpenClaw, un handoff passe par les fonctions de sessions et d’agent-à-agent autorisées, pas par une classe openclaw.Agent. Le Gateway doit connaître les agents et la politique doit restreindre les paires autorisées. Un exemple de configuration conceptuelle et actuelle ressemble à ceci :

{
  agents: {
    entries: [
      { id: "main", workspace: "~/.openclaw/workspace-main" },
      { id: "research", workspace: "~/.openclaw/workspace-research" },
      { id: "review", workspace: "~/.openclaw/workspace-review" },
    ],
  },
  tools: {
    sessions: { visibility: "agent" },
    agentToAgent: {
      enabled: true,
      allow: ["main:research", "main:review"],
    },
  },
}

Validez les chemins exacts du schéma avec votre version : OpenClaw refuse les clés inconnues. Une allowlist explicite évite qu’un agent secondaire contacte tous les autres.

Pattern pipeline

Le pipeline impose un ordre stable : collecte, transformation, validation, livraison. Chaque étape reçoit un artefact structuré plutôt que l’intégralité de la conversation. Il est plus prévisible qu’un supervisor, plus facile à rejouer et souvent moins coûteux.

Définissez pour chaque transition : schéma d’entrée, schéma de sortie, délai, nombre de retries, clé d’idempotence et responsable du rejet. Stockez les artefacts durables hors du prompt. Si la rédaction échoue, la recherche validée doit rester réutilisable.

OpenClaw peut déclencher et piloter un tel flux avec un agent, des skills, des tools et ses automations, mais les transactions applicatives complexes restent mieux placées dans un service ou moteur de workflow externe. L’article sur les workflows agentiques détaille cette frontière.

Pattern pool

Un pool distribue des unités indépendantes à des workers équivalents. Il convient au classement de documents ou à l’analyse de sources, à condition que deux workers ne produisent pas le même effet externe. Une file durable avec visibilité, accusé de réception et dead-letter queue est préférable à une liste en mémoire.

Ne créez pas vingt personas OpenClaw pour simuler des workers : la concurrence de calcul relève d’un scheduler ou d’une queue. Mesurez le Gateway avant d’augmenter le parallélisme.

Pattern message-passing

Les agents ou services publient des événements immuables. Le consommateur ne connaît pas l’émetteur, seulement le contrat du message. Ce pattern améliore le découplage et le replay, mais exige corrélation, déduplication et observabilité.

Un message exploitable contient au minimum :

{
  "event": "research.completed",
  "version": 1,
  "traceId": "veille-2026-09-06",
  "artifact": "s3://bucket/research/veille-2026-09-06.json",
  "attempt": 1,
  "createdAt": "2026-09-06T08:00:00Z"
}

Évitez de transporter un transcript complet. L’événement référence un artefact validé et versionné.

Shared memory ou messages ?

La shared memory réduit la latence, mais introduit des conflits d’écriture et rend l’origine d’une décision plus difficile à prouver. Réservez-la aux données de coordination simples : statut, verrou, pointeur d’artefact. Pour les décisions et résultats, préférez un journal append-only ou des messages versionnés.

Dans OpenClaw, chaque agent possède ses sessions. Ne contournez pas cette séparation en copiant des bases SQLite. Utilisez les outils de session bornés ou des artefacts transmis.

Partager le contexte sans saturer les prompts

Le bon paquet de contexte contient l’objectif, les contraintes, les preuves nécessaires et les références d’artefacts. Il exclut le raisonnement intermédiaire et les documents non pertinents. Une étape de retrieval doit renvoyer des extraits cités, pas une base vectorielle entière.

Résumez à chaque frontière, conservez la source hors prompt et attribuez un budget de contexte à chaque rôle.

Choisir la stack

Besoin	Outil adapté	Rôle
Assistant multi-canal self-hosted	OpenClaw	Gateway, sessions, canaux, agents, skills, tools, automations
Graphe d’état applicatif	LangGraph	Transitions, checkpoints, reprise
Équipe d’agents guidée par rôles	CrewAI	Tâches et processus applicatifs
Déclencheurs SaaS et intégrations	n8n	Webhooks, connecteurs, opérations déterministes
Queue durable	Redis Streams, RabbitMQ, Kafka	Distribution, replay, backpressure

OpenClaw peut être la façade conversationnelle et le plan de contrôle, mais pas « l’orchestrateur Python principal ». Comparez les outils pour agents IA selon la responsabilité réelle.

Définir les skills sans les confondre avec des agents

Un skill enseigne à un agent comment utiliser des tools. Il vit dans un dossier contenant SKILL.md. Un skill de revue peut formaliser les critères sans créer un nouveau runtime :

 ---
 name: review-report
 description: Vérifie un rapport de veille avant sa livraison.
 ---

 # Revue du rapport

1. Lire l'artefact transmis.
2. Vérifier que chaque affirmation importante cite une source.
3. Refuser si une date, une URL ou un propriétaire manque.
4. Retourner `PASS` ou `FAIL` avec les écarts.

Placez-le dans <workspace>/skills/review-report/SKILL.md, puis vérifiez son chargement avec openclaw skills list. Les skills d’un workspace sont propres à son agent ; des racines gérées peuvent être partagées.

Concevoir pour les pannes

Chaque frontière doit répondre à cinq questions : l’appel est-il idempotent, où est le checkpoint, qui possède le timeout, combien de retries sont permis et comment l’humain reprend-il ? Une écriture externe doit utiliser une clé d’idempotence ; un retry ne doit jamais republier ou facturer deux fois.

Ajoutez une trace commune à chaque artefact et mesurez réussite, latence, handoffs, tokens et interventions humaines par étape.

Exemple concret

Une rédaction automatise une veille hebdomadaire. Le Gateway OpenClaw expose deux agents : main, relié au canal de l’équipe, et research, limité à la recherche et à un workspace dédié. Le canal Slack est bindé à main. Celui-ci peut déléguer à research, mais l’inverse est interdit et aucun des deux ne dispose d’outils élevés.

Le déclenchement vient d’une automation OpenClaw :

openclaw automations add \
  --name "Veille hebdomadaire" \
  --cron "0 8 * * 1" \
  --tz "Europe/Paris" \
  --session isolated \
  --message "Produis la veille hebdomadaire selon le skill veille-marche."

Le skill veille-marche impose quatre sorties : liste de sources, synthèse factuelle, incertitudes et recommandations. L’agent de recherche écrit un artefact daté. main ne reçoit que ce fichier et les références, puis demande une approbation avant livraison. L’historique se contrôle avec :

openclaw automations list
openclaw automations runs --id <job-id>
openclaw health --json

Le test de régression supprime une source, simule un timeout et relance avec la même clé de rapport. Le résultat attendu est un rapport unique, marqué incomplet plutôt qu’une double livraison. Ce cas prouve l’intérêt d’une architecture à deux agents ; un troisième agent ne serait ajouté que si la revue exige un périmètre d’outils ou un propriétaire indépendant.

Bonnes pratiques

• Commencez par un agent et extrayez un rôle seulement lorsqu’une frontière stable apparaît.
• Donnez à chaque agent un workspace et un agentDir distincts ; ne réutilisez jamais un répertoire d’état.
• Ne confondez pas persona, skill, worker et service. Un nouveau prompt n’exige pas forcément un nouvel agent.
• Remplacez les transcripts partagés par des artefacts structurés, cités et versionnés.
• Limitez explicitement tools.sessions.visibility et tools.agentToAgent.allow lorsque les agents ne doivent pas tout voir.
• Activez le sandboxing pour les tools exposés à du contenu non fiable. Un workspace seul n’est pas une barrière de sécurité.
• Bornez les retries, les délégations et le parallélisme. Une boucle supervisor non bornée peut multiplier coûts et effets externes.
• Testez les chemins de refus, timeout, résultat vide et double livraison, pas seulement le scénario nominal.

La bonne architecture multi-agent est celle dont on peut dessiner les frontières de données et d’autorité sans parler du modèle. Si ce dessin reste flou, simplifiez avant d’ajouter un framework.

Questions fréquentes

Comment concevoir une architecture multi-agents ?

Commencez par les responsabilités, données, outils et niveaux de confiance. Choisissez ensuite un pattern : pipeline pour un ordre stable, supervisor pour un routage variable, pool pour des lots indépendants, messages pour un système distribué. Définissez enfin contrats, timeouts, idempotence, checkpoints et observabilité avant d’implémenter.

OpenClaw est-il un framework multi-agents Python ?

Non. OpenClaw est un assistant IA self-hosted avec un Gateway Node/TypeScript. Il peut héberger plusieurs agents isolés, router des canaux par bindings et fournir sessions, skills, tools et automations. Il ne s’installe pas avec pip et ne fournit pas les classes Python imaginaires souvent montrées dans d’anciens exemples.

Quelle différence entre shared memory et communication inter-agents ?

La shared memory permet à plusieurs acteurs de lire et écrire le même état, avec des risques de conflits. La communication par messages transmet des événements ou artefacts immuables, plus faciles à tracer et rejouer. En production, gardez l’état partagé minimal et privilégiez des contrats versionnés pour les résultats.

Combien d’agents faut-il pour commencer ?

Un ou deux suffisent souvent. Ajoutez un agent lorsqu’il faut isoler durablement un workspace, des credentials, des outils, un canal ou une fonction de contrôle. Si la séparation ne change ni l’autorité ni le contrat de sortie, un skill ou une étape déterministe est probablement plus simple.

Comment sécuriser plusieurs agents dans OpenClaw ?

Séparez workspaces et agentDir, activez des sandboxes adaptées, réduisez les tools, limitez la visibilité des sessions et autorisez seulement les paires agent-à-agent nécessaires. Un Gateway reste une frontière de confiance unique : des utilisateurs adversariaux doivent être placés sur des Gateway ou hôtes distincts.

Articles liés

Une architecture multi-agents devient rentable quand ses frontières réduisent la complexité plus qu’elles n’ajoutent de coordination. Utilisez OpenClaw pour le routage multi-canal et les agents isolés, puis un moteur de workflow ou une queue lorsque la logique applicative exige checkpoints et replay. La prochaine étape est de formaliser un premier flux avec des contrats testables.

• Comprendre les systèmes multi-agents
• Structurer des workflows agentiques
• Construire un système multi-agent en production
• Découvrir OpenClaw
• Gérer l’état avec LangGraph
• Organiser les rôles avec CrewAI